تیم محصول چگونه باید برگشت ایمیل را با خیال راحت عیب‌یابی و مدیریت کند؟

مشخص کنید خطا در کجا مشاهده شده است

محصول ممکن است از عدم تحویل در حین تراکنش زنده SMTP، از طریق یک اعلان وضعیت تحویل (DSN) بعدی یا از طریق یک رویداد احرازهویت‌شده ارائه‌دهنده باخبر شود. این مشاهدات شواهد متفاوتی دارند. رد فوری در مرحله RCPT TO پیش از پذیرش داده پیام، فقط به همان گیرنده مربوط است. رد شدن در مرحله DATA ممکن است به کل تراکنش ارسال‌شده مربوط باشد. DSN بعدی گزارش می‌دهد که سیستمی مسئولیت پیام را پذیرفته و سپس نتوانسته آن را تحویل یا relay کند. مرحله، سرور، دامنه گیرنده، تلاش، زمان، پاسخ SMTP، کد وضعیت پیشرفته، پیام عیب‌یابی و شناسه‌های همبستگی اصلی را ثبت کنید. همه موارد را در یک وضعیت bounced خلاصه نکنید. payload خام ارائه‌دهنده یا DSN استاندارد را فقط تا زمانی که نیازهای عملیاتی و سیاستی اقتضا می‌کند و با دسترسی محدود نگه دارید. اسکرین‌شات پشتیبانی یا بازگویی انسانی، شاهد کافی برای تلاش مجدد خودکار، توقف ارسال یا وضعیتی که به مشتری نمایش داده می‌شود نیست.

نتایج موقت و دائمی را از هم جدا کنید

SMTP برای تکمیل منفی گذرا از پاسخ‌های 4yz و برای تکمیل منفی دائمی از پاسخ‌های 5yz استفاده می‌کند. کدهای وضعیت پیشرفته یک کلاس اضافه می‌کنند که با 4 برای خطای گذرای پایدار یا با 5 برای خطای دائمی شروع می‌شود و پس از آن مقادیر subject و detail می‌آیند. هر دو کد پایه و پیشرفته را نگه دارید، چون متن به‌تنهایی مختص ارائه‌دهنده است و ممکن است تغییر کند. نتیجه موقت می‌تواند تلاش مجدد همان پیام منطقی را پس از تأخیر توجیه کند؛ حلقه‌های فوری یا ماندن نامحدود در صف را توجیه نمی‌کند. خطای دائمی گیرنده باید اجرای مجدد خودکار را برای آن گیرنده و تلاش متوقف کند تا زمانی که نشانی یا سیاست از طریق یک فرایند مجاز تغییر کند. hard یا soft بودن را فقط از برچسب‌های غیررسمی ارائه‌دهنده استنتاج نکنید. سیاست را بر اساس وضعیت دقیق، مرحله، پیام عیب‌یابی، کلاس پیام، گیرنده و مستندات فعلی ارائه‌دهنده بسازید. پاسخ‌های ناشناخته یا نادرست باید به‌صورت ایمن (fail closed) به بازبینی یا dead-letter بروند، نه اینکه به‌طور پیش‌فرض دوباره ارسال شوند.

اعلان‌های وضعیت تحویل را با احتیاط parse کنید

RFC 3464 یک قالب ماشین‌خوان برای اعلان وضعیت تحویل تعریف می‌کند که در multipart/report با فیلدهای message/delivery-status منتقل می‌شود. فیلدهای مفید می‌توانند شامل Reporting-MTA، Final-Recipient، Action، Status، Remote-MTA، Diagnostic-Code و زمان دریافت یا آخرین تلاش باشند. هر فیلد را ورودی غیرقابل‌اعتماد در نظر بگیرید، حتی اگر ساختار MIME درست parse شود. اندازه پیام، تعداد هدرها، تعداد بخش‌ها، عمق تودرتویی، decode کاراکترها و طول پیام عیب‌یابی ذخیره‌شده را محدود کنید. هرگز پیوست‌ها را اجرا نکنید، لینک‌های داخل پیام عیب‌یابی را خودکار دنبال نکنید و نشانی گیرنده را به‌عنوان هویت tenant نپذیرید. با استفاده از شناسه پایدار پیام ارائه‌دهنده، فراداده envelope اصلی یا یک هدر همبستگی امن از نظر حریم خصوصی، آن را با تلاشی که متعلق به اپلیکیشن است همبسته کنید. DSN ممکن است بخش‌هایی از پیام اصلی و داده‌های گیرنده را در بر داشته باشد؛ پس لاگ‌ها و مدت نگهداری را محدود کنید. اگر همبستگی مبهم است، شواهد را نگه دارید بدون اینکه نشانی نامرتبطی را در فهرست توقف ارسال قرار دهید یا سابقه پیام‌های tenant دیگری را افشا کنید.

تغییر وضعیت‌ها را در سطح گیرنده مدل کنید

یک پیام ممکن است چند گیرنده داشته باشد و نتایج متفاوتی بگیرد. وضعیت را به ازای هر گیرنده و هر تلاش ذخیره کنید، نه فقط در ردیف پیام. ارائه‌دهنده ممکن است برخی فرمان‌های RCPT را بپذیرد و برخی را رد کند، یا بعداً برای یک گیرنده تحویل و برای دیگری خطا گزارش کند. تغییر وضعیت‌های یک‌طرفه (monotonic) تعریف کنید تا یک رویداد accepted یا deferred تأخیری نتواند خطای دائمی تأییدشده، گزارش اسپم یا لغو اشتراک بعدی را بازنویسی کند. دفتر رویدادها را نگه دارید و وضعیت فعلی نمایشی را با قوانین اولویت صریح از آن استخراج کنید. وضعیت‌های ارسال‌شده، پذیرفته‌شده توسط ارائه‌دهنده، پذیرفته‌شده توسط سرور گیرنده، موقتاً به تعویق افتاده، به‌طور دائم ناموفق، در فهرست توقف ارسال، گزارش اسپم‌شده، لغو اشتراک‌شده و نامعلوم را از هم جدا کنید. پذیرش توسط سرور مقصد همچنان پوشه نهایی صندوق ایمیل یا خوانده شدن توسط انسان را نشان نمی‌دهد. کاری کنید که تلاش‌های مجدد، تلاش‌های مرتبطی زیر همان کلید رویداد منطقی بسازند تا خطر تکرار و شواهد قابل‌مشاهده بمانند. تلاش مجدد برنامه‌ریزی‌شده را اقدام جدید مشتری علامت نزنید.

خطاهای گذرا را با محدودیت‌های سخت‌گیرانه دوباره امتحان کنید

برای نتایج گذرای واجد شرایط، exponential backoff همراه با jitter، تعداد تلاش محدود و حداکثر عمر صف تعیین کنید. از رفتار مستند تلاش مجدد ارائه‌دهنده استفاده کنید و روی relayی که خودش دوباره تلاش می‌کند، یک حلقه تهاجمی در سطح اپلیکیشن اضافه نکنید. برای هر تلاش، هویت منطقی پیام و بررسی فهرست توقف ارسال را یکسان نگه دارید. وقتی گیرنده در فهرست توقف ارسال قرار می‌گیرد، رضایت تغییر می‌کند، رویداد منقضی می‌شود، هویت فرستنده باطل می‌شود یا یک پاسخ دائمی بعدی می‌رسد، تلاش مجدد را متوقف کنید. نرخ را به تفکیک tenant، دامنه مقصد، فرستنده و کلاس خطا محدود کنید تا قطعی یک گیرنده نتواند صف را در انحصار بگیرد. در صورت وجود، Retry-After یا راهنمای مستند تعویق را رعایت کنید، اما هرگز به محتوای دلبخواهی پیام به‌عنوان دستور تلاش مجدد اعتماد نکنید. برای افزایش عمر صف، تکرار کدهای موقت، دامنه‌های غیرعادی و تلاش‌های نزدیک به انقضا هشدار تنظیم کنید. یک کد گذرا ممکن است یک مشکل پایدار سیاست یا اعتبار را پنهان کند؛ تلاش‌های مجدد محدود برای بازیابی زمان می‌خرند، نه مجوزی برای نادیده گرفتن علت.

خطاهای دائمی تأییدشده گیرنده را در فهرست توقف ارسال قرار دهید

خطای دائمی تأییدشده نشانی یا صندوق ایمیل باید پیش از ارسال هر job بعدی، یک رکورد توقف ارسال متعلق به محصول را به‌روز کند. tenant، کلید نرمال‌شده گیرنده، دامنه اعمال، رویداد منبع، دسته وضعیت و پیام عیب‌یابی، زمان اعمال و ارجاع به شواهد را بدون افشای گسترده نشانی ذخیره کنید. فهرست توقف ارسال را در زمان ارسال اعمال کنید، نه فقط هنگام وارد کردن فهرست. نشانی نامعتبر، دامنه ناموجود، رد به دلیل سیاست، رد به دلیل محتوای پیام، خطای احراز هویت، سهمیه و اعتبار فرستنده را از هم تفکیک کنید، چون راه‌حل ایمن هر کدام متفاوت است. گیرنده نامعتبر توقف ارسال در سطح گیرنده را توجیه می‌کند؛ رد شدن به دلیل احراز هویت فرستنده باید پیکربندی فرستنده را متوقف کند، نه اینکه همه گیرندگان را در فهرست توقف ارسال قرار دهد. حذف دستی از فهرست را با مجوزدهی قوی، ذکر دلیل و سابقه ممیزی محافظت کنید. تأیید مجدد یا اصلاح باید یک تصمیم تأییدشده جدید ایجاد کند، نه اینکه شواهد قدیمی را پاک کند. فهرست‌های توقف ارسال ارائه‌دهندگان مفیدند، اما جایگزین دفتر رضایت و ایمنی اپلیکیشن نمی‌شوند، به‌ویژه در زمان مهاجرت بین ارائه‌دهندگان.

از حلقه‌های برگشت و backscatter پرهیز کنید

SMTP برای اعلان‌های وضعیت تحویل از reverse path تهی (null) استفاده می‌کند تا خطا در تحویل خود اعلان، برگشت دیگری تولید نکند. این رفتار را در relayها حفظ کنید و به DSNها، پاسخ‌های خودکار یا پیام‌هایی که نشانه تولید خودکار دارند پاسخ خودکار نفرستید. RFC 3834 توصیه‌هایی برای پاسخ‌های خودکار ایمیل، از جمله نگرانی‌های مربوط به حلقه و تشدید (amplification)، ارائه می‌دهد. هرگز پس از پذیرفتن یک پیام مشکوک، برای نشانی From قابل‌مشاهده و تأییدنشده برگشت تولید نکنید، چون هویت‌های جعلی فرستنده می‌توانند سیستم را به منبع backscatter تبدیل کنند. به‌جای پذیرفتن و سپس اطلاع دادن به یک نشانی جعلی، تا حد امکان گیرندگان نامعتبر را در حین SMTP رد کنید. پاسخ‌های خودکار را به ازای هر فرستنده و مکالمه محدود کنید و از هویت‌های پاسخ کنترل‌شده استفاده کنید. یک وب‌هوک محصول یا رویداد خطای داخلی اغلب ایمن‌تر از تولید ایمیل جدید در اینترنت است. From جعلی، فرستنده envelope تهی، DSN تکراری، هدرهای auto-submitted، ترافیک فهرست‌های پستی و گزارش‌های نادرست را در fixtureهای ایزوله آزمایش کنید.

پیش از اعمال رویدادهای ارائه‌دهنده، آن‌ها را احراز هویت کنید

اگر ارائه‌دهنده رویدادهای برگشت را از طریق وب‌هوک تحویل می‌دهد، پیش از parse کردن فیلدهای کسب‌وکاری، امضا یا سازوکار احراز هویت مستند را روی درخواست دقیق اعتبارسنجی کنید. تازگی مهر زمانی، محافظت در برابر replay، محدودیت اندازه بدنه و همبستگی با tenant را اعمال کنید. رویداد احرازهویت‌شده را پیش از برگرداندن پاسخ موفق ذخیره یا در صف قرار دهید و سپس بر اساس یک شناسه رویداد پایدار ارائه‌دهنده یا یک کلید ترکیبی محافظه‌کارانه که گیرندگان یا تلاش‌ها را با هم ادغام نکند، موارد تکراری را حذف کنید. زمان وقوع را جدا از زمان پردازش ذخیره کنید، چون رویدادها ممکن است با تأخیر و خارج از ترتیب برسند. رویدادهایی را که دامنه فرستنده، حساب، فضای کاری، شناسه پیام یا دامنه گیرنده آن‌ها به tenant موردانتظار قابل ربط نیست رد کنید. رازهای وب‌هوک را جدا از اعتبارنامه‌های SMTP یا API بچرخانید. خطاهای امضا، نرخ تکرار، تأخیر، dead-letterها و انواع ناشناخته رویداد را پایش کنید. وب‌هوک احرازهویت‌شده منشأ را با راز پیکربندی‌شده ثابت می‌کند؛ تا زمانی که همبستگی موفق نشده، ثابت نمی‌کند که رویداد به job داخلی درست نگاشت شده است.

بر اساس خانواده وضعیت عیب‌یابی کنید، نه با حدس زدن از روی متن

با subject در کد وضعیت پیشرفته شروع کنید: وضعیت نشانی، وضعیت صندوق ایمیل، وضعیت سیستم ایمیل، وضعیت شبکه یا مسیریابی، وضعیت پروتکل تحویل ایمیل، وضعیت محتوا یا رسانه پیام، یا وضعیت امنیت و سیاست. سپس از detail code و پیام عیب‌یابی کامل همراه با مستندات فعلی گیرنده یا ارائه‌دهنده استفاده کنید. برای خطاهای نشانی، نحو گیرنده و DNS دامنه را بررسی کنید؛ برای خطاهای صندوق ایمیل، شواهد وجود صندوق و سهمیه را؛ برای خطاهای انتقال، شواهد MX، مسیریابی، TLS و شبکه را؛ برای خطاهای پیام، اندازه، MIME، کدگذاری و محتوا را؛ و برای خطاهای امنیتی، SPF، DKIM، DMARC، اعتبارنامه‌ها، سیاست فرستنده یا اعتبار را. در هر آزمون مجدد کنترل‌شده فقط یک متغیر را تغییر دهید. برای دور زدن یک تصمیم سیاستی دائمی، IP، دامنه یا ارائه‌دهنده را عوض نکنید. پاسخ اصلی را نگه دارید و هر تغییر پیکربندی را که اختیار فرستنده را گسترده‌تر یا احراز هویت را ضعیف‌تر می‌کند بدون اینکه علت مشاهده‌شده را اصلاح کند، برگردانید.

سلامت برگشت ایمیل را بدون افشای داده‌های گیرنده بسنجید

پذیرش در نخستین تلاش، تعویق موقت، خطای دائمی، بازیابی با تلاش مجدد، نتیجه نامعلوم، گزارش اسپم، توقف ارسال و عمر صف را به تفکیک گروه‌های امن از نظر حریم خصوصی پیگیری کنید. ابعاد مفید شامل دامنه فرستنده، دامنه مقصد در سطح تجمیع تأییدشده، کلاس پیام، نسخه قالب، ارائه‌دهنده، خانواده وضعیت و زمان است. از نشانی‌های کامل، محتوای پیام، متن‌های عیب‌یابی یا هدرهای خام در analytics روزمره پرهیز کنید. نرخ گیرنده نامعتبر را از خطاهای سیاست، احراز هویت، محتوا، اعتبار و زیرساخت گذرا جدا کنید؛ یک نرخ برگشت واحد علت‌های قابل‌اقدام را پنهان می‌کند. از مخرج‌های مبتنی بر تلاش‌های ارسال به گیرنده استفاده کنید و رویدادهای دیررس را در گروه اصلی خودشان گزارش کنید. هشدارها را بر اساس خط پایه تاریخی و ریسک کسب‌وکار تنظیم کنید، نه یک درصد همگانی. اعمال فهرست توقف ارسال و استثناهای دستی را ممیزی کنید. فقط شواهدی را که برای عملیات، امنیت، تعهدات قانونی و اختلافات لازم است نگه دارید و سپس آن‌ها را حذف یا تجمیع کنید. نرخ برگشت پایین، رضایت، تعامل یا رسیدن به صندوق ورودی را ثابت نمی‌کند.

SendHQ چگونه جای می‌گیرد

SendHQ تحویل و ردیابی برگشت و موارد توقف ارسال را مستند می‌کند. برای رفتار پشتیبانی‌شده آن، مستندات کنونی را ببینید.

پرسش‌های متداول

منابع

• RFC 3464: یک قالب پیام توسعه‌پذیر برای اعلان‌های وضعیت تحویل (DSN) — RFC Editor
• RFC 3463: کدهای وضعیت پیشرفته سیستم ایمیل — RFC Editor
• RFC 5321: پروتکل ساده انتقال ایمیل (SMTP) — RFC Editor
• RFC 3834: توصیه‌هایی برای پاسخ‌های خودکار به ایمیل — RFC Editor