ایمیلی که از طریق VPN فرستاده می‌شود: پاسخ واقعاً کجا می‌رود
پاسخ به یک صندوق پستی نشانه می‌رود، نه به نشانی VPN که از آن فرستادید. ارسال، تحویل و اتصال بعدی که پاسخ را می‌خواند را از هم جدا کنید.
پیامی را از داخل تونل می‌فرستید، قطع می‌کنید و پاسخ صبح روز بعد می‌رسد. هیچ‌چیز در این میان به نشانی قدیمی VPN نیاز ندارد و هیچ‌چیز خراب نمی‌شود. ایمیل پاسخ‌ها را به نشانی‌ای که پیام از آن فرستاده شده هدایت نمی‌کند؛ آن‌ها را به یک صندوق پستی هدایت می‌کند. سه مسیر اینجا در یک پرسش ادغام می‌شوند و جدا کردنشان به بخش بزرگی از نگرانی پاسخ می‌دهد.
سه مسیری که مردم در یکی ادغام می‌کنند
ارسال، تحویل و خواندن سه اتصال جداگانه‌اند و تنها دو تای آن‌ها به دستگاه شما مربوط می‌شود.
Submission: your mail app -> your mail service
Delivery: other mail service -> your mailbox service
Reading: your app now -> your mailbox serviceVPN می‌تواند بر اولی و سومی اثر بگذارد، چون آن‌ها اتصال‌هایی هستند که دستگاه شما برقرار می‌کند. نمی‌تواند بر دومی اثر بگذارد، چون آن مسیر میان دو سرور ایمیل می‌گذرد که شما کنترلشان نمی‌کنید. پاسخ بسته‌ای نیست که به نشانی‌ای که از آن فرستادید بازگردد. پیام تازه‌ای است که سرویس ایمیل طرف مقابل آن را به سرویس صندوق پستی شما تحویل می‌دهد.
وقتی این سه را از هم جدا نگه دارید، این پرسش که آیا پاسخ شما را پیدا می‌کند دیگر مرموز نیست.
فیلد Reply-To یک نشانی است، نه یک مسیر
RFC 5322 فیلد Reply-To را صندوق یا صندوق‌های پستی تعریف می‌کند که پاسخ‌ها باید به آن‌ها فرستاده شوند. بدون آن، پیش‌فرض معمول صندوق From است، مگر اینکه پاسخ‌دهنده چیز دیگری بنویسد. هر دو نشانی‌های پستی در یک سرصفحه‌اند. هیچ‌کدام دستوری برای بازگشایی اتصال شبکه‌ای که پیام اصلی را ارسال کرد نیست.
به همین دلیل نشانی خروجی VPN هرگز در مسیر پاسخ ظاهر نمی‌شود. حتی وقتی سرور ارسال آن نشانی خروجی را جایی ثبت کرده باشد، پاسخ به یک صندوق پستی نشانه می‌رود و سرور فرستنده به‌جای سوکت قدیمی شما، مبدل ایمیل دامنه را جست‌وجو می‌کند.
اگر پاسخی به جایی غیرمنتظره رفت، پیش از بدگمان شدن به تونل، Reply-To و تنظیمات کلاینت خود فرستنده را بخوانید.
سرصفحه‌های ردیابی واقعاً چه چیزی ثبت می‌کنند
هر گام SMTP یک سرصفحه Received به ابتدا می‌افزاید که اتصال پردازش‌شده را توصیف می‌کند و بالاترین مورد، آخرین گام پیش از تحویل است. بنابراین پیام ارسال‌شده می‌تواند جزئیات شبکه‌ای داشته باشد که ارزش بررسی دارد و این جزئیات را سرورها می‌نویسند، نه شما. اینکه چه داشته باشند به معماری ارسال ارائه‌دهنده و نحوه برخوردش با سرصفحه‌ها بستگی دارد.
به‌جای حدس زدن، آن‌ها را از یک پیام ذخیره‌شده بخوانید:
grep -E '^(Received|Return-Path|Reply-To|From):' message.emlانضباط سودمند این است که مشخص کنید کدام سرویس قابل‌اعتماد هر فیلد را افزوده است. متن دلخواه در بخش بالاتر سرصفحه‌ها شاهد قابل‌اعتمادی نیست و نام یک محصول وعده دائمی نیست که نشانی خانه شما همیشه حاضر است یا همیشه غایب.
خواندن ایمیل در زمانی دیگر یک اتصال تازه است
وقتی پاسخ را باز می‌کنید، کلاینت شما از طریق شبکه‌ای که اکنون روی آن هستید به سرویس صندوق پستی‌تان وصل می‌شود. این اتصالی تازه با نشانی مبدأ خودش است، نه ادامه سوکت ارسال دیروز. از سیاست جاری شبکه‌ای که در آن لحظه استفاده می‌کنید پیروی می‌کند.
محتوای راه دور هم سومین چیز است. کلاینت ایمیلی که تصویری راه دور بار می‌کند یا پیوندی را دنبال می‌کند، درخواستی جداگانه با تنظیمات جاری خود می‌فرستد و آن درخواست می‌تواند هر شناسه‌ای را که پیام جاسازی کرده است حمل کند. این پاسخ SMTP نیست که به نشانی قدیمی برسد و برخورد کردن با آن به این شکل، مواجهه واقعی را پنهان می‌کند.
اگر می‌خواهید پیامی را بدون اعلام اینکه بازش کرده‌اید بخوانید، محتوای راه دور را خاموش کنید.
پیش از آنکه آن را نشت بنامید چه چیزی را بررسی کنید
با نمای پیام اصلی و فیلد Reply-To شروع کنید. بعد مشخص کنید کدام سرویس مدخل‌های Received را که نگرانتان می‌کند افزوده است و آن را با مستندات جاری ارائه‌دهنده مقایسه کنید، نه با پاسخ قدیمی یک انجمن.
در پایان، پرسش‌ها را جدا کنید: سرور ارسال چه چیزی را مشاهده کرد، زنجیره تحویل چه چیزی افزود و وقتی پیام را باز کردید کلاینت شما چه چیزی درخواست کرد؟
پاسخ دادن جداگانه به این سه، کاری بیشتر از بررسی یک صفحه IP است و تنها نسخه‌ای است که نتیجه‌ای قابل دفاع می‌دهد. پاسخ دادن به یک نشانی ایمیل، نشانی خانه شما را فاش نمی‌کند و لازم نیست تونل قدیمی باز بماند.