Mac Mail, दुई खाता र तिनलाई छुट्याउन नसक्ने एउटा VPN नियम

Mail खुल्छ, कामको इनबक्स सिङ्क हुन्छ, र व्यक्तिगतको समय सकिन थाल्छ। वा दुवै सिङ्क हुन्छन्, तर कामको सर्भर सुरुङ माथि हुँदासम्म मात्र जवाफ दिन्छ, र Mail लाई कुन खाता कुन हो थाहा हुँदैन। लक्षणको आकार सधैं एउटै हुन्छ: एउटा एप, दुई खाता र एप पहिचान गर्ने एउटा नियम। सुधार एप सीमा होइन, भाँडो हो भनी स्वीकार गरेबाट सुरु हुन्छ।

यहाँ तीन चयनकर्ता काम गरिरहेका छन्, र तिनीहरू एकआपसमा बदल्न मिल्दैन। एउटा जडान बनाउने प्रक्रिया हो, अर्को पुग्ने होस्ट हो, र तेस्रो त्यो होस्टमार्फत साइन इन गर्न प्रयोग हुने पहिचान हो। तपाईंको नीतिले जसलाई नाम दिन सक्छ, त्यही नै तपाईंले साँच्चै बनाउन सक्ने सीमा हो।

एप किन गलत एकाइ हो

Mail प्रत्येक कन्फिगर गरिएको खातालाई सेवा दिने एउटै प्रक्रिया हो। एपविरुद्ध लेखिएको नियमले त्यसका सबै जडान समात्छ, त्यसैले व्यक्तिगत खाताले कामको सुरुङ र त्यसको पूर्वनिर्धारित मार्ग पाउँछ। त्यो स्वीकार्य हुन सक्छ, तर त्यो निर्णय हो, जाँच नगरी छोड्न सकिने साइड इफेक्ट होइन।

केही सुधार्नुअघि प्रयोगकर्ता वास्तवमा केको गुनासो गरिरहेको छ हेर्नुहोस्। सिङ्क हुने तर पठाउन नसक्ने इनबक्सले सामान्यतया इनबक्सको सट्टा सबमिशन सर्भरतर्फ संकेत गर्छ, र दुवै एउटै निजी दायराभित्रका फरक ठेगानामा हुन सक्छन्। असफलता प्राप्तिमा छ, पठाउनमा छ वा दुवैमा भनी सोध्नुहोस्। जवाफले तपाईंको नियमले कुन अन्तिम बिन्दु ढाक्नुपर्ने निर्धारण गर्छ, र सर्भर प्रशासकसँग एक फेरो बचाउँछ।

दुवै खाताले फरक सर्भर प्रयोग गर्दा

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

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

दुवै खाताले एउटै सर्भर साझा गर्दा

एउटै होस्ट ठेगानामा दुई खाताले गन्तव्य-आधारित चयन पूर्ण रूपमा हराउँछन्। त्यो ठेगानातर्फको मार्ग जो जोडिन्छ त्यसलाई सेवा दिन्छ, र पछि कुन इनबक्स साइन इन हुन्छ जाँच्न सक्दैन। मार्ग सार्दा दुवै खाताको बाटो सर्छ, र त्यही नै प्रयोगकर्ताले टार्न खोजेको नतिजा हो।

त्यो बिन्दुमा इमानदार विकल्पहरू हुन् प्लेटफर्म र क्लाइन्टले समर्थन गरे खाता-सचेत नीति, एपको सीमा वास्तविक बनाउन कामको खाताका लागि छुट्टै स्वीकृत मेल क्लाइन्ट, वा दुवै खाता सँगै यात्रा गर्छन् भनी स्वीकार गर्नु। जानाजानी एउटा छान्नुहोस् र कुन छान्नुभयो भन्नुहोस्।

सुरुङ सुरु गर्नु त्यसलाई ढाक्नु होइन

Apple को App Layer VPN पेलोडले MailDomains सेटिङको दस्तावेजीकरण गर्छ: सूचीबद्ध डोमेनले समर्थित व्यवस्थापित परिनियोजनमा Mail लाई VPN जडान सुरु गराउँछन्। यो उपयोगी क्षमता हो, र सुन्दा लाग्नेभन्दा साँघुरो छ। Mail ती डोमेनसँग बोल्दा यसले सुरुङ सुरु गर्छ; यसले प्रत्येक मार्ग, प्रत्येक एप-सम्बन्ध वा सुरुङ तल हुँदा के हुन्छ वर्णन गर्दैन।

यो व्यवस्थापित सुविधा पनि हो, Mail इन्टरफेसमा प्रति-खाता चेकबक्स होइन। परिनियोजन व्यवस्थापित छैन भने सेटिङ तपाईंका लागि उपलब्ध हुँदैन, र जतिसुकै प्रोफाइल सम्पादन गरे पनि त्यसले बनाउने छैन।

क्यास गरिएको इनबक्सले होइन, नयाँ सिङ्कले परीक्षण गर्नुहोस्

स्वीकृति परीक्षण भनेको इच्छित नीतिअन्तर्गत प्रत्येक खाताका लागि नयाँ सिङ्क, साथै संरक्षित खाताका लागि अनुपलब्ध अवस्था हो। क्यास गरिएको इनबक्सले अर्को अनुरोधबारे केही प्रमाणित गर्दैन, र जोडिएको VPN प्रतिमाले कुनै सुरुङ अवस्थित छ भन्ने मात्र बताउँछ।

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