Mac Mail, दो खाते और एक VPN नियम जो उन्हें अलग नहीं कर सकता

Mail खुलता है, काम का इनबॉक्स सिंक होता है, और निजी वाला समय समाप्त होने लगता है। या दोनों सिंक होते हैं, पर काम का सर्वर केवल तब तक जवाब देता है जब तक टनल चालू है, और Mail नहीं जानता कि कौन-सा खाता कौन-सा है। लक्षण का आकार हमेशा एक ही होता है: एक ऐप, दो खाते और एक नियम जो ऐप की पहचान करता है। सुधार इस स्वीकार से शुरू होता है कि ऐप एक पात्र है, सीमा नहीं।

यहाँ तीन चयनकर्ता काम कर रहे हैं, और वे बदले नहीं जा सकते। एक वह प्रक्रिया है जो कनेक्शन बनाती है, दूसरा वह होस्ट है जिस तक पहुँचती है, और तीसरा उस होस्ट से साइन इन करने के लिए इस्तेमाल की जाने वाली पहचान है। आपकी नीति जिसे भी नाम दे सकती है, वही वह सीमा है जिसे आप वास्तव में बना सकते हैं।

ऐप गलत इकाई क्यों है

Mail एक ही प्रक्रिया है जो हर कॉन्फ़िगर किए गए खाते की सेवा करती है। ऐप के विरुद्ध लिखा नियम उसके सभी कनेक्शन पकड़ लेता है, इसलिए निजी खाते को काम का टनल और उसका डिफ़ॉल्ट रूट विरासत में मिलता है। यह स्वीकार्य हो सकता है, पर यह एक निर्णय है, ऐसा दुष्प्रभाव नहीं जिसे बिना जाँचे छोड़ा जा सके।

कुछ भी सुधारने से पहले देखें कि उपयोगकर्ता वास्तव में किस बात की शिकायत कर रहा है। जो इनबॉक्स सिंक होता है पर भेज नहीं सकता, वह आमतौर पर इनबॉक्स के बजाय सबमिशन सर्वर की ओर इशारा करता है, और दोनों एक ही निजी रेंज के अलग-अलग पतों पर हो सकते हैं। पूछें कि विफलता प्राप्ति में है, भेजने में है या दोनों में। जवाब तय करता है कि आपके नियम को कौन-सा अंतिम बिंदु ढकना है, और यह सर्वर का प्रबंधन करने वाले के साथ एक चक्कर बचाता है।

जब दोनों खाते अलग-अलग सर्वर इस्तेमाल करते हैं

अगर काम का मेल कॉर्पोरेट रेंज के भीतर के होस्ट से बात करता है और निजी मेल किसी सार्वजनिक प्रदाता से, तो गंतव्य-आधारित व्यवस्था आवश्यकता व्यक्त कर सकती है। उसे मेल सर्वरों के वास्तविक पते, उन्हें हल करने वाला DNS, और उसी सेवा के साथ चलने वाले किसी भी सबमिशन या प्रमाणीकरण अंतिम बिंदु चाहिए। नीति लिखने से पहले तीनों इकट्ठा करें, क्योंकि केवल इनबॉक्स ढकने वाला नियम पहली बार भेजने पर विफल होगा।

पते इस्तेमाल करें, @ चिह्न के बाद वाला भाग नहीं। मेल पते में डोमेन राउटिंग का कथन नहीं है, और उसे ऐसा मानने से ऐसा नियम बनता है जो गलत होस्ट के लिए चलता है या कभी नहीं चलता। वास्तविक अंतिम बिंदु खाता सेटिंग्स या प्रशासक से पुष्टि करें।

जब दोनों खाते एक सर्वर साझा करते हैं

एक ही होस्ट पते पर दो खाते गंतव्य-आधारित चयन को पूरी तरह हरा देते हैं। उस पते का मार्ग जो भी जुड़ता है उसकी सेवा करता है, और यह जाँच नहीं सकता कि बाद में कौन-सा इनबॉक्स साइन इन करता है। मार्ग हटाने से दोनों खातों का रास्ता हटता है, और यही वह नतीजा है जिसे उपयोगकर्ता टालना चाहता था।

उस समय ईमानदार विकल्प हैं खाता-सजग नीति यदि प्लेटफ़ॉर्म और क्लाइंट उसे समर्थन दें, काम के खाते के लिए अलग स्वीकृत मेल क्लाइंट ताकि ऐप की सीमा वास्तविक बने, या यह स्वीकार करना कि दोनों खाते साथ यात्रा करते हैं। जानबूझकर एक चुनें और बताएं कि कौन-सा चुना।

टनल शुरू करना उसे ढकने के समान नहीं है

Apple का App Layer VPN पेलोड MailDomains सेटिंग का दस्तावेज़ीकरण करता है: सूचीबद्ध डोमेन Mail को समर्थित प्रबंधित परिनियोजनों में VPN कनेक्शन शुरू करवाते हैं। यह उपयोगी क्षमता है, और यह सुनने में जितनी लगती है उससे संकरी है। Mail जब उन डोमेन से बात करता है तब यह टनल शुरू करता है; यह हर मार्ग, हर ऐप-संबद्धता या टनल बंद होने पर क्या होता है, यह नहीं बताता।

यह प्रबंधित सुविधा भी है, Mail इंटरफ़ेस में प्रति-खाता चेकबॉक्स नहीं। अगर परिनियोजन प्रबंधित नहीं है, तो सेटिंग आपके लिए उपलब्ध नहीं है, और कितनी भी प्रोफ़ाइल संपादन करें वह उसे नहीं बनाएगा।

कैश किए गए इनबॉक्स से नहीं, नए सिंक से परखें

स्वीकृति परीक्षण इच्छित नीति के अंतर्गत हर खाते के लिए नया सिंक है, साथ में संरक्षित खाते के लिए अनुपलब्ध स्थिति। कैश किया गया इनबॉक्स अगली माँग के बारे में कुछ सिद्ध नहीं करता, और जुड़ा हुआ VPN चिह्न केवल यह कहता है कि कोई टनल मौजूद है।

प्रशासक को काम के खाते के अंतिम बिंदु और निजी मेल के लिए चाहा गया व्यवहार दें, फिर पूछें कि कौन-सी समर्थित खाता-सजग, डोमेन-आधारित या एप्लिकेशन नीति उसे लागू करती है। हर स्थिति में दोनों खातों का सिंक होना देखना ही यह एकमात्र प्रमाण है कि आपने जो सीमा रची है वही मशीन लागू करती है।