Mac Mail، دو اکاؤنٹس اور ایک VPN قاعدہ جو انہیں الگ نہیں کر سکتا
ایپ کی سطح کا قاعدہ Mail کا نام لیتا ہے، اس کے کسی ایک اکاؤنٹ کا نہیں۔ کام کی میل کی پیروی کرنے والی سرنگ مانگنے سے پہلے ایپ، سرور اور سائن اِن الگ کریں۔
Mail کھلتا ہے، کام کا اِن باکس ہم آہنگ ہوتا ہے، اور ذاتی والا وقت سے گزرنے لگتا ہے۔ یا دونوں ہم آہنگ ہوتے ہیں، مگر کام کا سرور صرف اُس وقت جواب دیتا ہے جب سرنگ چل رہی ہو، اور Mail نہیں جانتا کہ کون سا اکاؤنٹ کون سا ہے۔ علامت کی شکل ہمیشہ ایک جیسی ہوتی ہے: ایک ایپ، دو اکاؤنٹس اور ایک قاعدہ جو ایپ کی شناخت کرتا ہے۔ اصلاح اِس اقرار سے شروع ہوتی ہے کہ ایپ ایک برتن ہے، حد نہیں۔
یہاں تین منتخب کنندے کام کر رہے ہیں، اور وہ ایک دوسرے کی جگہ نہیں لے سکتے۔ ایک وہ عمل ہے جو رابطہ بناتا ہے، دوسرا وہ میزبان جس تک پہنچتا ہے، اور تیسرا وہ شناخت جو اُس میزبان کے ذریعے سائن اِن کرنے کے لیے استعمال ہوتی ہے۔ آپ کی پالیسی جن میں سے کسی کا نام لے سکتی ہے، وہی وہ حد ہے جو آپ واقعی بنا سکتے ہیں۔
ایپ غلط اکائی کیوں ہے
Mail ایک ہی عمل ہے جو ہر ترتیب شدہ اکاؤنٹ کی خدمت کرتا ہے۔ ایپ کے خلاف لکھا گیا قاعدہ اُس کے تمام رابطے پکڑ لیتا ہے، اِس لیے ذاتی اکاؤنٹ کام کی سرنگ اور اُس کا طے شدہ راستہ ورثے میں پاتا ہے۔ یہ قابلِ قبول ہو سکتا ہے، مگر یہ ایک فیصلہ ہے، ایسا ضمنی اثر نہیں جسے بغیر جانچے چھوڑا جا سکے۔
کچھ بھی ٹھیک کرنے سے پہلے دیکھیں کہ صارف اصل میں کس چیز کی شکایت کر رہا ہے۔ جو اِن باکس ہم آہنگ ہوتا ہے مگر بھیج نہیں سکتا، وہ عام طور پر اِن باکس کی بجائے جمع کرانے والے سرور کی طرف اشارہ کرتا ہے، اور دونوں ایک ہی نجی حدود میں مختلف پتوں پر ہو سکتے ہیں۔ پوچھیں کہ ناکامی وصولی میں ہے، بھیجنے میں ہے یا دونوں میں۔ جواب طے کرتا ہے کہ آپ کے قاعدے کو کون سا آخری مقام ڈھانپنا ہے، اور یہ سرور کے منتظم کے ساتھ ایک چکر بچاتا ہے۔
جب دونوں اکاؤنٹس مختلف سرور استعمال کرتے ہیں
اگر کام کی میل کورپوریٹ حدود کے اندر کسی میزبان سے بات کرتی ہے اور ذاتی میل کسی عوامی فراہم کنندہ سے، تو منزل پر مبنی ترتیب تقاضا بیان کر سکتی ہے۔ اُسے میل سرورز کے حقیقی پتے، اُنہیں حل کرنے والا DNS، اور اُسی خدمت کے ساتھ چلنے والے کسی بھی جمع کرانے یا تصدیق کے آخری مقامات درکار ہیں۔ پالیسی لکھنے سے پہلے تینوں جمع کریں، کیونکہ صرف اِن باکس ڈھانپنے والا قاعدہ پہلی بار بھیجنے پر ناکام ہو گا۔
پتے استعمال کریں، @ نشان کے بعد والا حصہ نہیں۔ میل پتے میں ڈومین راستہ بتانے کا بیان نہیں ہے، اور اُسے ایسا سمجھنے سے ایسا قاعدہ بنتا ہے جو غلط میزبان کے لیے چلتا ہے یا کبھی نہیں چلتا۔ حقیقی آخری مقامات اکاؤنٹ کی ترتیبات یا منتظم سے تصدیق کریں۔
جب دونوں اکاؤنٹس ایک سرور شیئر کرتے ہیں
ایک ہی میزبان پتے پر دو اکاؤنٹس منزل پر مبنی انتخاب کو مکمل طور پر بے اثر کر دیتے ہیں۔ اُس پتے تک راستہ جو بھی جڑتا ہے اُس کی خدمت کرتا ہے، اور بعد میں کون سا اِن باکس سائن اِن ہوتا ہے یہ جانچ نہیں سکتا۔ راستہ ہٹانے سے دونوں اکاؤنٹس کا راستہ ہٹتا ہے، اور یہی وہ نتیجہ ہے جس سے صارف بچنے کی کوشش کر رہا تھا۔
اُس وقت ایماندار انتخاب یہ ہیں: اکاؤنٹ سے واقف پالیسی اگر پلیٹ فارم اور کلائنٹ اِس کی حمایت کریں، کام کے اکاؤنٹ کے لیے الگ منظور شدہ میل کلائنٹ تاکہ ایپ کی حد حقیقی ہو، یا یہ مان لینا کہ دونوں اکاؤنٹس ساتھ سفر کرتے ہیں۔ جان بوجھ کر ایک چنیں اور بتائیں کہ کون سا چنا۔
سرنگ شروع کرنا اُسے ڈھانپنا نہیں ہے
Apple کا App Layer VPN پے لوڈ MailDomains ترتیب کو دستاویز کرتا ہے: فہرست شدہ ڈومینز Mail کو معاون منتظم شدہ تعیناتیوں میں VPN رابطہ شروع کرنے پر مجبور کرتے ہیں۔ یہ مفید صلاحیت ہے، اور سننے سے زیادہ تنگ ہے۔ یہ سرنگ اُس وقت شروع کرتا ہے جب Mail اُن ڈومینز سے بات کرتا ہے؛ یہ ہر راستہ، ہر ایپ تعلق یا سرنگ کے نیچے ہونے پر کیا ہوتا ہے بیان نہیں کرتا۔
یہ منتظم شدہ خصوصیت بھی ہے، Mail انٹرفیس میں فی اکاؤنٹ چیک باکس نہیں۔ اگر تعیناتی منتظم شدہ نہیں ہے، ترتیب آپ کے لیے دستیاب نہیں، اور پروفائل کی کتنی ہی تدوین اُسے پیدا نہیں کرے گی۔
کیش شدہ اِن باکس سے نہیں، نئی ہم آہنگی سے جانچیں
قبولیت کا امتحان یہ ہے کہ مطلوبہ پالیسی کے تحت ہر اکاؤنٹ کے لیے نئی ہم آہنگی، اور محفوظ اکاؤنٹ کے لیے عدم دستیابی کی حالت۔ کیش شدہ اِن باکس اگلی درخواست کے بارے میں کچھ ثابت نہیں کرتا، اور منسلک VPN آئیکن صرف یہ بتاتا ہے کہ کوئی سرنگ موجود ہے۔
منتظم کو کام کے اکاؤنٹ کے آخری مقامات اور ذاتی میل کے لیے مطلوبہ رویہ دیں، پھر پوچھیں کہ کون سی معاون اکاؤنٹ سے واقف، ڈومین پر مبنی یا ایپلیکیشن پالیسی اُسے نافذ کرتی ہے۔ ہر حالت میں دونوں اکاؤنٹس کا ہم آہنگ ہوتے دیکھنا ہی واحد ثبوت ہے کہ آپ نے جو حد رچی ہے وہی حد مشین نافذ کرتی ہے۔