یک تیم محصول چگونه باید مسیریابی ایمیل Cloudflare را به‌طور امن پیاده‌سازی کند؟

کار ایمیل ورودی و مرز مالکیت را تعریف کنید

ابتدا کار دقیق ایمیل ورودی را مکتوب کنید: کدام دامنه و کدام local partها باید ایمیل بپذیرند، مالک هر مقصد کیست، آیا پیام باید فوروارد شود، با کد پردازش شود یا دور ریخته شود، و شواهد عملیاتی تا چه مدت می‌تواند نگهداری شود. Cloudflare Email Routing یک لایه مسیریابی ایمیل ورودی است. به‌تنهایی تیکت پشتیبانی نمی‌سازد، هویت فرستنده را احراز نمی‌کند، ثابت نمی‌کند ایمیل فورواردشده به دست یک انسان رسیده است و قرار گرفتن در صندوق ایمیل مقصد را تضمین نمی‌کند. این وضعیت‌های بعدی اپلیکیشن را جدا نگه دارید. برای DNS، قوانین مسیریابی، کد Worker، تأیید مقصد، رخدادهای امنیتی و بازگشت یک مالک عملیاتی تعیین کنید. در نخستین مرحله انتشار، به‌جای catch-all از نام‌های مستعار اختصاصی مانند support@ یا invoices@ استفاده کنید. یک مسیر محدود، جمع‌آوری ناخواسته را کاهش می‌دهد، نتایج آزمون را قابل‌تفسیر می‌کند و اثر یک مقصد اشتباه یا شاخه اشتباه Worker را محدود می‌کند.

دامنه را فعال کنید، بدون اینکه DNS را یک گام نصب کورکورانه بدانید

مستندات فعلی Email Service در Cloudflare می‌گوید برای Email Routing دامنه باید از Cloudflare DNS استفاده کند. روند فعال‌سازی می‌تواند رکوردهای MX برای مسیریابی ایمیل ورودی و همچنین رکوردهای TXT مرتبط با SPF و DKIM را که محصول شرح می‌دهد اضافه کند. پیش از اعمال، رکوردهای پیشنهادی دقیق را بازبینی کنید. ابتدا فهرستی از MX، SPF، DKIM، DMARC، صندوق‌های ایمیل، سرویس‌های فوروارد، توکن‌های تأیید و واگذاری‌های زیردامنه موجود تهیه کنید. جایگزین کردن رکوردهای MX مقصد نشست‌های جدید SMTP ورودی را تغییر می‌دهد، پس یک پنجره نگهداری هماهنگ کنید و مقادیر قبلی را به‌عنوان سابقه بازگشت نگه دارید. از ساختن چند رکورد TXT از نوع SPF روی یک نام مالک پرهیز کنید. پس از تغییر، resolverهای معتبر (authoritative) و عمومی را کوئری بگیرید و سپس تحویل را از حسابی نامرتبط با مقصد آزمایش کنید. تخمین‌های انتشار DNS دلیلی بر این نیست که همه فرستندگان اکنون پاسخ یکسانی می‌بینند و داشبورد سبز نیز فوروارد سرتاسری را ثابت نمی‌کند.

پیش از ساختن مسیرهای فعال، مقصدها را تأیید کنید

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

قوانین صریح بسازید و تقدم آن‌ها را بشناسید

هر قانون مسیریابی یک الگوی ایمیل را به یک مقصد تأییدشده یا یک Worker متصل می‌کند. Cloudflare سه کنش را مستند کرده است: ارسال به یک ایمیل، ارسال به یک Worker و drop. ابتدا مشخص‌ترین مسیرهای local part را بسازید، مالک آن‌ها را در سوابق تغییرات ذکر کنید و مطمئن شوید برای هر الگو فقط یک قانون موردنظر وجود دارد. مستندات هشدار می‌دهد که اگر چند قانون از یک الگو استفاده کنند، فقط قانونی که اول فهرست شده ایمیل ورودی را پردازش می‌کند. به ترتیب نمایشی به‌عنوان یک قاعده تجاری غیررسمی تکیه نکنید؛ به‌جای آن ابهام را برطرف کنید. قوانین drop را فقط با توجیه محدود نگه دارید، چون حذف عمداً به معنای عدم تحویل است. catch-all را فقط پس از برشمردن پیامدهای آن برای حریم خصوصی، حجم اسپم، اشتباهات تایپی و ذخیره‌سازی فعال کنید. catch-all ممکن است نشانی‌هایی را جمع کند که هیچ‌کس قصد ساختنشان را نداشته است، پس باید مقصد یا سیاست Worker اختصاصی، هشدارها و مسیر سریع غیرفعال‌سازی داشته باشد، نه اینکه بی‌صدا یک صندوق ایمیل شخصی را به ارث ببرد.

از زیرنشانی (subaddressing) آگاهانه استفاده کنید

Cloudflare نشانی‌دهی اختیاری با علامت + را مطابق RFC 5233 مستند کرده است. وقتی فعال باشد، ایمیل برای نشانی‌ای مانند user+detail@example.com می‌تواند با قانون پایه user@example.com تطبیق یابد و در عین حال بخش detail در گیرنده پیام که در اختیار Worker و لاگ‌ها قرار می‌گیرد حفظ شود. این قابلیت می‌تواند برای برچسب‌های مسیریابی، شناسه‌های آزمایشی یا نام‌های مستعار مخصوص هر گردش‌کار مفید باشد، اما detail متنی است که فرستنده کنترل می‌کند. آن را هویت احراز هویت‌شده tenant، مجوز یا یک راز در نظر نگیرید. پیش از استفاده از آن به‌عنوان کلید پایگاه داده، بُعد متریک یا نام صف، آن را نرمال‌سازی و محدود کنید. Cloudflare همچنین مستند کرده است که یک قانون صریح برای زیرنشانی کامل بر قانون پایه مقدم است. هر دو حالت صریح و پیش‌فرض را آزمایش کنید تا یک قانون مشخص‌تر در آینده بی‌صدا گردش‌کار موجود را تغییر ندهد. داده‌های شخصی یا محرمانه را در برچسب‌های + قرار ندهید، چون ممکن است در هدرها، لاگ‌ها، پیام‌های فورواردشده، خروجی‌های پشتیبانی و analytics ظاهر شوند.

Worker را فقط برای نیازهای واقعی پردازش انتخاب کنید

وقتی نیاز فقط این است که یک نشانی به یک صندوق ایمیل تأییدشده برسد، از فوروارد مستقیم استفاده کنید. وقتی به انشعاب کنترل‌شده، بررسی پیام، ذخیره‌سازی، رد کردن، پاسخ دادن یا چند فوروارد نیاز دارید، به یک Worker مسیریابی کنید. handler ایمیل Cloudflare فرستنده و گیرنده envelope، هدرها، یک جریان MIME خام، اندازه آن و متدهایی برای forward، reply یا reject در اختیار می‌گذارد. handler را کوچک نگه دارید: ابتدا سیاست گیرنده را اعتبارسنجی کنید، محدودیت‌های اندازه پیام و parse را اعمال کنید، فراخوانی‌های خارجی را در صورت امکان از طریق صف‌های دارای محدودیت زمانی انجام دهید و برای هر خطا نتیجه را تعریف کنید. هدرها، موضوع‌ها، نام‌های نمایشی، پیوست‌ها، لینک‌ها و مرزهای MIME در کنترل مهاجم‌اند. به‌طور پیش‌فرض بدنه خام یا نشانی‌های کامل را لاگ نکنید. اگر محتوا باید ذخیره شود، آن را رمزنگاری کنید، دسترسی را بر اساس tenant و job محدود کنید، حذف را تعریف کنید و پیوست‌ها را خارج از مسیر همگام مسیریابی اسکن کنید. یک استثنای parse نباید به فوروارد یا پاسخ ناخواسته منجر شود.

یک مسیر تصمیم صریح پیاده‌سازی کنید

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

فوروارد و پاسخ را نتایجی با دامنه شواهد محدود بدانید

موفقیت فراخوانی یک متد Worker شاهدی درباره عملیات پلتفرم است، نه نتیجه نهایی برای کاربر. SMTP انتقال میان سیستم‌ها را تعریف می‌کند، در حالی که فیلترینگ، فوروارد، قرنطینه، قوانین صندوق ایمیل و خوانده شدن توسط انسان پس از آن، خارج از آن مرحله باقی می‌مانند. وضعیت‌هایی مانند دریافت‌شده توسط Cloudflare، فراخوانی Worker، تلاش برای کنش، پذیرش توسط سرور مقصد، تأخیر یا شکست، و ایجاد رکورد در اپلیکیشن را جداگانه مدل کنید. همه آن‌ها را «تحویل‌شده» برچسب نزنید. لاگ‌های ساخت‌یافته و با حداقل داده‌های شخصی شامل شناسه قانون، نسخه Worker، کنش، زمان، شناسه همبستگی و نتیجه کلی نگه دارید؛ نشانی‌ها یا محتوای کامل را فقط جایی ذخیره کنید که یک نیاز عملیاتی مستند آن را توجیه کند. برای خطاهای فراخوانی، ردشدن‌ها به دلیل اندازه، حجم غیرعادی catch-all، الگوهای تکراری فرستنده، خطاهای مقصد و تغییرات ناگهانی ترافیک هشدار تنظیم کنید. پیام‌های آزمایشی کنترل‌شده را پیوسته نمونه‌برداری کنید، اما هرگز محتوای واقعی مشتری را به‌عنوان داده آزمایشی مشاهده‌پذیری به کار نبرید.

محدودیت‌ها و حالت‌های خطای فعلی پلتفرم را رعایت کنید

Cloudflare در حال حاضر محدودیت‌های Email Routing را از جمله 200 قانون مسیریابی برای هر دامنه، 200 نشانی مقصد برای هر حساب، محدودیت اندازه 25 MiB برای پیام ورودی و محدودیت‌های استاندارد CPU و حافظه Workers برای پیام‌هایی که به Worker مسیریابی می‌شوند مستند کرده است. این‌ها را مستندات فعلی ارائه‌دهنده بدانید، نه ثابت‌های دائمی. در زمان برنامه‌ریزی صفحه محدودیت‌های زنده را بخوانید و مدت‌ها پیش از نزدیک شدن به سقف هشدار تنظیم کنید. پیام‌های MIME بزرگ اگر بی‌احتیاط decode شوند، حتی زیر سقف اندازه خام پلتفرم هم می‌توانند حافظه یا CPU را تمام کنند. محتوای غیرضروری را به‌صورت جریانی پردازش یا رد کنید، تعداد پیوست‌ها را محدود کنید و parse پرهزینه را به کار ناهمگام محدود بسپارید. طبق مستندات مسیریابی Cloudflare، تغییر نام یک Worker می‌تواند اتصال مسیریابی آن را از کار بیندازد، پس بررسی مسیر را در تأیید استقرار بگنجانید. فراخوانی‌های ناموفق باید در لاگ‌های Workers قابل‌مشاهده باشند، اما لاگ‌ها به‌تنهایی امکان اجرای مجدد (replay) فراهم نمی‌کنند. تصمیم بگیرید آیا فرستنده باید از طریق SMTP تلاش مجدد کند، آیا یک اپراتور می‌تواند به‌طور امن یک job اپلیکیشن را دوباره اجرا کند و از رکوردهای تکراری پایین‌دستی چگونه جلوگیری می‌شود.

انتشار و بازگشت را به‌عنوان یک تغییر واحد آزمایش کنید

ابتدا یک مسیر staging یا کم‌ریسک بسازید. پیام‌های کنترل‌شده را از حسابی غیر از مقصد تأییدشده بفرستید و متن ساده، محتوای multipart، پیوست‌های موردانتظار، نشانی‌دهی با +، local partهای ناشناخته و ورودی‌های عمداً بدشکل در محدوده امن را پوشش دهید. پاسخ‌های DNS، پیکربندی داشبورد، نسخه Worker، نتیجه فوروارد، رکورد پایین‌دستی و رفتار حریم خصوصی را تأیید کنید. سپس مسیرهای منفی را آزمایش کنید: مقصد تأییدنشده، قانون غیرفعال، استثنای Worker، پیام بیش از حد بزرگ، تحویل تکراری و قانونی که در غیر این صورت به catch-all می‌افتاد. شواهد موردانتظار هر مرحله را ثبت کنید. پیش از گسترش ترافیک، غیرفعال کردن قانون، بازگرداندن رکوردهای MX قبلی در صورت نیاز، جدا کردن Worker و اطلاع‌رسانی درباره ایمیل‌های تأخیری یا ردشده را تمرین کنید. در صورت از دست رفتن توضیح‌ناپذیر مسیریابی، افشای cross-tenant، نشت محتوا، پاسخ‌های غیرمنتظره، ذخیره‌سازی نامحدود یا خطای پایدار Worker، به حالت قبل برگردید. تصاویر لحظه‌ای پیکربندی و نتایج آزمون را نگه دارید، بدون اینکه محتوای پیام را بیش از حد لازم نگهداری کنید.

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

SendHQ از ایمیل ورودی پشتیبانی می‌کند. این راهنما Cloudflare Email Routing را پوشش می‌دهد؛ برای راه‌اندازی و محدودیت‌های هر سرویس، مستندات همان سرویس را دنبال کنید.

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

منابع

• مسیریابی ایمیل‌ها — Cloudflare
• قوانین و نشانی‌های مسیریابی ایمیل — Cloudflare
• API مربوط به Workers برای ایمیل مسیریابی‌شده — Cloudflare
• محدودیت‌های Cloudflare Email Service — Cloudflare
• RFC 5321: پروتکل ساده انتقال ایمیل (SMTP) — RFC Editor
• RFC 5233: فیلترینگ ایمیل Sieve: افزونه زیرنشانی (Subaddress) — RFC Editor