میل مک، دو حساب و یک قاعده VPN که نمی‌تواند آن‌ها را جدا کند
قاعده‌ای در سطح برنامه Mail را نام می‌برد، نه یکی از حساب‌هایش را. پیش از درخواست تونلی که ایمیل کار را دنبال کند، برنامه، سرور و ورود را جدا کنید.
Mail باز می‌شود، صندوق کار همگام می‌شود و حساب شخصی شروع به تمام شدن زمان می‌کند. یا هر دو همگام می‌شوند، اما سرور کار فقط تا وقتی تونل بالاست پاسخ می‌دهد، و Mail نمی‌داند کدام حساب کدام است. نشانه همیشه یک شکل دارد: یک برنامه، دو حساب و قاعده‌ای که برنامه را شناسایی می‌کند. اصلاح با پذیرش این شروع می‌شود که برنامه یک ظرف است، نه یک مرز.
سه انتخاب‌گر اینجا در کارند و قابل تعویض نیستند. یکی فرایندی است که اتصال را می‌سازد، دیگری میزبان رسیده، و سومی هویتی است که برای ورود از طریق آن میزبان استفاده می‌شود. هر کدام را که سیاست شما بتواند نام ببرد، همان مرزی است که واقعاً می‌توانید بسازید.
چرا برنامه واحد اشتباهی است
Mail یک فرایند است که به هر حساب پیکربندی‌شده سرویس می‌دهد. قاعده‌ای که علیه برنامه نوشته شود همه اتصال‌های آن را می‌گیرد، پس حساب شخصی تونل کار و مسیر پیش‌فرضش را به ارث می‌برد. این ممکن است پذیرفتنی باشد، اما یک تصمیم است، نه عارضه‌ای که بی‌بررسی رها شود.
پیش از اصلاح هر چیز ببینید کاربر واقعاً از چه شکایت دارد. صندوقی که همگام می‌شود اما نمی‌تواند بفرستد معمولاً به سرور ارسال اشاره دارد نه به صندوق ورودی، و هر دو می‌توانند در آدرس‌های متفاوت در همان محدوده خصوصی باشند. بپرسید خرابی در دریافت است، در ارسال یا در هر دو. پاسخ تعیین می‌کند قاعده شما کدام نقطه پایانی را باید بپوشاند، و یک رفت‌وبرگشت با مدیر سرور را صرفه‌جویی می‌کند.
وقتی دو حساب از سرورهای متفاوت استفاده می‌کنند
اگر ایمیل کار با میزبانی در محدوده شرکتی صحبت کند و ایمیل شخصی با ارائه‌دهنده عمومی، آرایشی مبتنی بر مقصد می‌تواند الزام را بیان کند. به آدرس‌های واقعی سرورهای ایمیل، DNSی که آن‌ها را حل می‌کند، و هر نقطه پایانی ارسال یا احراز هویتی که با همان سرویس می‌آید نیاز دارد. هر سه را پیش از نوشتن سیاست جمع کنید، چون قاعده‌ای که فقط صندوق ورودی را بپوشاند در نخستین ارسال شکست می‌خورد.
از آدرس‌ها استفاده کنید، نه بخش بعد از علامت @. دامنه در آدرس ایمیل یک گزاره مسیریابی نیست، و رفتار کردن با آن به این شکل قاعده‌ای می‌سازد که برای میزبان اشتباه فعال می‌شود یا هرگز فعال نمی‌شود. نقاط پایانی واقعی را از تنظیمات حساب یا از مدیر تأیید کنید.
وقتی هر دو حساب یک سرور را شریک می‌شوند
دو حساب روی یک آدرس میزبان انتخاب مبتنی بر مقصد را کاملاً خنثی می‌کند. مسیر به آن آدرس به هر کسی که وصل شود سرویس می‌دهد و نمی‌تواند بررسی کند کدام صندوق بعداً وارد می‌شود. جابه‌جا کردن مسیر، مسیر را برای هر دو حساب جابه‌جا می‌کند، و این دقیقاً همان نتیجه‌ای است که کاربر می‌خواست از آن دوری کند.
در آن نقطه گزینه‌های صادقانه یک سیاست حساب‌آگاه است اگر بستر و کلاینت از آن پشتیبانی کنند، یک کلاینت ایمیل تأییدشده جداگانه برای حساب کار تا مرز برنامه واقعی شود، یا پذیرش اینکه هر دو حساب با هم سفر می‌کنند. یکی را آگاهانه انتخاب کنید و بگویید کدام را انتخاب کردید.
راه‌اندازی تونل همان پوشاندن آن نیست
بار مفید App Layer VPN اپل تنظیمی به نام MailDomains را مستند می‌کند: دامنه‌های فهرست‌شده باعث می‌شوند Mail در استقرارهای مدیریت‌شده پشتیبانی‌شده اتصال VPN را راه‌اندازی کند. این قابلیت مفیدی است و باریک‌تر از آن است که به نظر می‌رسد. تونل را وقتی Mail با آن دامنه‌ها صحبت می‌کند شروع می‌کند؛ هر مسیر، هر پیوند برنامه یا آنچه هنگام پایین بودن تونل رخ می‌دهد را توصیف نمی‌کند.
همچنین یک ویژگی مدیریت‌شده است، نه یک جعبه انتخاب برای هر حساب در رابط Mail. اگر استقرار مدیریت‌شده نباشد، تنظیم برای شما در دسترس نیست و هیچ مقدار ویرایش نمایه آن را تولید نمی‌کند.
با همگام‌سازی تازه آزمایش کنید، نه با صندوق ورودی کش‌شده
آزمون پذیرش یک همگام‌سازی تازه برای هر حساب زیر سیاست موردنظر است، به‌همراه وضعیت در دسترس نبودن برای حساب محافظت‌شده. صندوق ورودی کش‌شده درباره درخواست بعدی چیزی ثابت نمی‌کند، و نماد VPN متصل فقط می‌گوید تونلی وجود دارد.
نقاط پایانی حساب کار و رفتاری که برای ایمیل شخصی می‌خواهید را به مدیر بدهید، سپس بپرسید کدام سیاست پشتیبانی‌شده حساب‌آگاه، دامنه‌محور یا برنامه‌محور آن را پیاده می‌کند. تماشای همگام شدن دو حساب در هر شرایط تنها مدرکی است که مرز طراحی‌شده شما همان مرزی است که ماشین اعمال می‌کند.