Mac Mail, दोन खाती आणि त्यांना वेगळे करू न शकणारा एक VPN नियम
अ‍ॅप-स्तरीय नियम Mail चे नाव घेतो, त्याच्या एका खात्याचे नाही. कामाच्या मेलचा मागोवा घेणारा बोगदा मागण्यापूर्वी अ‍ॅप, सर्व्हर आणि साइन-इन वेगळे करा.
Mail उघडतो, कामाचा इनबॉक्स सिंक होतो, आणि वैयक्तिकची वेळ संपू लागते। किंवा दोन्ही सिंक होतात, पण कामाचा सर्व्हर बोगदा वर असेपर्यंतच उत्तर देतो, आणि Mail ला कोणते खाते कोणते ते माहीत नसते। लक्षणाचा आकार नेहमी एकच असतो: एक अ‍ॅप, दोन खाती आणि अ‍ॅपची ओळख करणारा एक नियम। दुरुस्ती अ‍ॅप ही सीमा नाही, पात्र आहे हे मान्य केल्यापासून सुरू होते।
इथे तीन निवडक काम करतात, आणि ते एकमेकांच्या जागी वापरता येत नाहीत। एक जोडणी करणारी प्रक्रिया, दुसरा ती ज्या होस्टपर्यंत पोहोचते तो, आणि तिसरा त्या होस्टद्वारे साइन इन करण्यासाठी वापरली जाणारी ओळख आहे। तुमचे धोरण ज्याला नाव देऊ शकते, तीच खरी सीमा तुम्ही बांधू शकता।
अ‍ॅप चुकीचे एकक का आहे
Mail ही प्रत्येक संरचित खात्याला सेवा देणारी एकच प्रक्रिया आहे। अ‍ॅपविरुद्ध लिहिलेला नियम त्याच्या सर्व जोडण्या पकडतो, त्यामुळे वैयक्तिक खात्याला कामाचा बोगदा आणि त्याचा डीफॉल्ट मार्ग वारसा मिळतो। ते स्वीकारार्ह असू शकते, पण तो निर्णय आहे, तपासल्याशिवाय सोडता येणारा दुष्परिणाम नाही।
काहीही दुरुस्त करण्यापूर्वी वापरकर्ता खरंच कशाबद्दल तक्रार करतो ते पाहा। सिंक होणारा पण पाठवू न शकणारा इनबॉक्स सहसा इनबॉक्सऐवजी सबमिशन सर्व्हरकडे निर्देश करतो, आणि दोन्ही एकाच खाजगी श्रेणीतल्या वेगळ्या पत्त्यांवर असू शकतात। अपयश प्राप्तीत आहे, पाठवण्यात आहे की दोन्हीत, असे विचारा। उत्तरावर ठरते की तुमच्या नियमाने कोणता अंतिम बिंदू झाकायचा, आणि सर्व्हरचा प्रशासक याच्याशी एक फेरी वाचते।
दोन्ही खाती वेगळे सर्व्हर वापरतात तेव्हा
कामाचा मेल कॉर्पोरेट श्रेणीतल्या होस्टशी बोलत असेल आणि वैयक्तिक मेल सार्वजनिक पुरवठादाराशी, तर गंतव्य-आधारित रचना आवश्यकता व्यक्त करू शकते। तिला मेल सर्व्हरचे खरे पत्ते, ते सोडवणारा DNS, आणि त्याच सेवेसोबत येणारे कोणतेही सबमिशन किंवा प्रमाणीकरण अंतिम बिंदू लागतात। धोरण लिहिण्यापूर्वी तिन्ही गोळा करा, कारण फक्त इनबॉक्स झाकणारा नियम पहिल्या पाठवणीत अपयशी ठरेल।
पत्ते वापरा, @ चिन्हानंतरचा भाग नाही। मेल पत्त्यातील डोमेन हे राउटिंगचे विधान नाही, आणि तसे वागल्यास चुकीच्या होस्टसाठी चालणारा किंवा कधीच न चालणारा नियम तयार होतो। खरे अंतिम बिंदू खाते सेटिंग्ज किंवा प्रशासकाकडून पुष्टी करा।
दोन्ही खाती एक सर्व्हर सामायिक करतात तेव्हा
एकाच होस्ट पत्त्यावरील दोन खाती गंतव्य-आधारित निवड पूर्णपणे हरवतात। त्या पत्त्याकडचा मार्ग जो जोडतो त्याला सेवा देतो, आणि नंतर कोणता इनबॉक्स साइन इन होतो हे तपासू शकत नाही। मार्ग हलवल्याने दोन्ही खात्यांचा रस्ता हलतो, आणि हाच तो निकाल जो वापरकर्त्याला टाळायचा होता।
त्या टप्प्यावर प्रामाणिक पर्याय म्हणजे प्लॅटफॉर्म आणि क्लायंटना समर्थन असेल तर खाते-जाणीव धोरण, अ‍ॅपची सीमा खरी होण्यासाठी कामाच्या खात्यासाठी स्वतंत्र मंजूर मेल क्लायंट, किंवा दोन्ही खाती एकत्र प्रवास करतात हे स्वीकारणे। जाणीवपूर्वक एक निवडा आणि कोणते निवडले ते सांगा।
बोगदा सुरू करणे म्हणजे तो झाकणे नाही
Apple चे App Layer VPN पेलोड MailDomains सेटिंगचे दस्तऐवजीकरण करते: सूचीबद्ध डोमेन समर्थित व्यवस्थापित तैनातीत Mail ला VPN जोडणी सुरू करायला लावतात। ही उपयुक्त क्षमता आहे, आणि ऐकायला वाटते त्यापेक्षा अरुंद आहे। Mail त्या डोमेनशी बोलतो तेव्हा ती बोगदा सुरू करते; ती प्रत्येक मार्ग, प्रत्येक अ‍ॅप-संबंध किंवा बोगदा खाली असताना काय होते याचे वर्णन करत नाही।
हे व्यवस्थापित वैशिष्ट्यही आहे, Mail इंटरफेसमधील प्रति-खाते चेकबॉक्स नाही। तैनाती व्यवस्थापित नसेल तर सेटिंग तुम्हाला उपलब्ध नाही, आणि कितीही प्रोफाइल संपादन केले तरी ती तयार होणार नाही।
कॅश केलेल्या इनबॉक्सने नाही, नवीन सिंकने तपासा
स्वीकृती चाचणी म्हणजे इच्छित धोरणाखाली प्रत्येक खात्यासाठी नवीन सिंक, आणि संरक्षित खात्यासाठी अनुपलब्ध स्थिती। कॅश केलेला इनबॉक्स पुढील विनंतीबद्दल काहीही सिद्ध करत नाही, आणि जोडलेले VPN चिन्ह फक्त काहीतरी बोगदा अस्तित्वात आहे असे सांगते।
प्रशासकाला कामाच्या खात्याचे अंतिम बिंदू आणि वैयक्तिक मेलसाठी इच्छित वर्तन द्या, मग विचारा की कोणते समर्थित खाते-जाणीव, डोमेन-आधारित किंवा अ‍ॅप्लिकेशन धोरण ते अंमलात आणते। प्रत्येक स्थितीत दोन्ही खाती सिंक होताना पाहणे हाच तुम्ही रचलेली सीमा मशीन लादते ही सीमा आहे याचा एकमेव पुरावा आहे।