صفحه معرفی · سرویس SMTP relay

یک تیم محصول هنگام انتخاب سرویس SMTP relay چه چیزهایی را باید ارزیابی کند؟

سرویس SMTP relay را یک سیستم کنترل‌شده برای ارسال پیام و عملیات ارزیابی کنید، نه صرفاً یک نام هاست و پورت. TLS اجباری، پورت‌های submission پشتیبانی‌شده، کنترل‌های SMTP AUTH، جداسازی اعتبارنامه‌ها، تأیید دامنه فرستنده، پایداری صف، رفتار مستند 4xx و 5xx، سهمیه‌ها، محدودیت اندازه پیام، رویدادهای وضعیت تحویل، مدیریت برگشت و گزارش اسپم، دامنه فهرست توقف ارسال، جداسازی tenantها، مشاهده‌پذیری و قابلیت خروجی گرفتن را بررسی کنید. کلاینت‌ها و شبکه‌هایی را که دقیقاً متصل خواهند شد آزمایش کنید. پاسخ 250 یک relay مسئولیت رسیدگی بعدی را منتقل می‌کند؛ تحویل به سرور گیرنده یا رسیدن به صندوق ورودی را ثابت نمی‌کند.

submission را از relay میان سرورها جدا کنید

تیم‌های محصول اغلب «SMTP relay» را به معنای سرویسی احراز هویت‌شده به کار می‌برند که پیام‌های خروجی را از یک اپلیکیشن می‌پذیرد و به سمت سرورهای ایمیل گیرنده منتقل می‌کند. استانداردها این نقش submission را از relay میان سرورهای ایمیل متمایز می‌کنند. RFC 6409 پورت 587 را برای ارسال پیام رزرو می‌کند و به سرورهای submission اجازه می‌دهد قواعد احراز هویت، سیاست و اصلاح پیام را اعمال کنند که با relay روی پورت 25 فرق دارد. از هر ارائه‌دهنده بپرسید کدام رابط را می‌خرید: submission احراز هویت‌شده برای اپلیکیشن‌ها، relay ورودی میان سرورها یا هر دو. نام هاست، پورت‌ها، حالت‌های رمزنگاری، سازوکارهای احراز هویت، قواعد فرستنده و افزونه‌های SMTP پشتیبانی‌شده را ثبت کنید. سرویسی که برای یک کلاینت دسکتاپ کار می‌کند ممکن است برای یک صف پرحجم مناسب نباشد، و یک relay سروری ممکن است احراز هویت اپلیکیشن را رد کند. به‌جای اینکه فرض کنید همه endpointهای SMTP یکسان رفتار می‌کنند، دقیقاً همان نقش را آزمایش کنید.

submission محافظت‌شده و احراز هویت امن را الزامی کنید

اعتبارنامه‌ها یا محتوای پیام را روی اتصال بدون محافظت ارسال نکنید. RFC 8314 ارسال با متن آشکار را منسوخ می‌داند، برای ترافیک submission نسخه TLS 1.2 یا بالاتر را توصیه می‌کند و در صورت پشتیبانی، TLS ضمنی را ترجیح می‌دهد. RFC 4954 سازوکار SMTP AUTH را تعریف می‌کند و سرورها را ملزم می‌کند پیکربندی‌ای ارائه دهند که سازوکارهای رمز عبور متن آشکار را بدون TLS یا محافظت معادل مجاز نکند. در ارزیابی، اعتبارسنجی گواهی، نسخه‌های پشتیبانی‌شده TLS، پورت‌های TLS ضمنی و STARTTLS، رفتار downgrade و اینکه آیا احراز هویت پیش از رمزنگاری رد می‌شود را تأیید کنید. اعتبارنامه‌های relay را در مخزن اسرار سمت سرور نگه دارید، برای محیط‌ها و اپلیکیشن‌ها هویت‌های جداگانه بسازید و آن‌ها را بدون قطعی بچرخانید. مشخص کنید آیا مجوزها می‌توانند دامنه‌های فرستنده یا دسته‌های پیام را محدود کنند. یک اعتبارنامه مشترک میان tenantهای محیط عملیاتی، ابطال، انتساب و مهار رخداد را بی‌جهت گسترده می‌کند.

سازگاری کلاینت و شبکه را بررسی کنید

پیش از انتخاب relay همه فرستندگان را فهرست کنید: کتابخانه‌های اپلیکیشن، workerهای صف، دستگاه‌های پایش، نرم‌افزارهای کسب‌وکار، دستگاه‌های چندکاره و سیستم‌های قدیمی. برخی از پورت 587 با STARTTLS پشتیبانی می‌کنند، برخی TLS ضمنی را الزامی می‌کنند و برخی نمی‌توانند گواهی‌های مدرن را اعتبارسنجی کنند یا به‌طور امن احراز هویت کنند. این محدودیت دلیلی برای جدا کردن یا جایگزین کردن کلاینت است، نه تضعیف سراسری حساب relay. resolve کردن DNS، IPv4 و IPv6، قوانین فایروال خروجی، timeoutهای اتصال، رفتار proxy، مذاکره TLS، AUTH، افزونه‌های EHLO، محدودیت اندازه پیام و در صورت نیاز نشانی‌های بین‌المللی را آزمایش کنید. محیط‌های ابری ممکن است پورت 25 را محدود کنند، پس پورت‌های جایگزین submission ارائه‌دهنده از نظر عملیاتی اهمیت دارند. آزمون سازگاری را از هر شبکه محیط عملیاتی اجرا کنید، نه از لپ‌تاپ یک توسعه‌دهنده. یک پیکربندی پشتیبانی‌شده را مستند کنید و بازگشت به متن آشکار یا نام هاست تأییدنشده را مسدود کنید.

پذیرش، صف‌ها و تلاش‌های مجدد را بشناسید

پاسخ‌های SMTP بخشی از قرارداد اپلیکیشن‌اند. پاسخ تکمیلی 2xx موفقیت آن فرمان را نشان می‌دهد؛ پس از پذیرش نهایی پیام، relay طبق قواعد SMTP مسئولیت تحویل یا اعلان شکست بعدی را بر عهده می‌گیرد. پاسخ 4xx گذراست و می‌تواند تلاش مجدد را توجیه کند، در حالی که پاسخ 5xx برای فرمان تلاش‌شده دائمی است و معمولاً به اصلاح نیاز دارد، نه تکرار. بپرسید سرویس پیام‌ها را تا چه مدت در صف نگه می‌دارد، کدام خطاها را دوباره امتحان می‌کند، برنامه backoff آن چیست، چه زمانی اعلان وضعیت تحویل تولید می‌کند و آیا ایمیل‌های صف در شکست یک region باقی می‌مانند. اپلیکیشن شما همچنان به شناسه job پایدار، تلاش‌های مجدد محدود برای اتصال و محافظت در برابر نتایج مبهم نیاز دارد. اگر اتصال پس از DATA قطع شود، ساختن کورکورانه یک job جدید می‌تواند ایمیل تکراری ایجاد کند. شناسه پیام relay را در صورت وجود ذخیره کنید و پیش از ارسال مجدد تطبیق دهید.

ظرفیت را با واحدهای درست اندازه بگیرید

محدودیت‌های relay ممکن است بر گیرندگان در هر روز غلتان، پیام در ثانیه، اتصال‌های هم‌زمان، گیرندگان در هر تراکنش، بایت در هر پیام، اندازه پیوست پس از کدگذاری و عمق صف ذخیره‌شده اعمال شوند. پلنی که مجموع ماهانه بزرگی را تبلیغ می‌کند همچنان ممکن است جهش ترافیک هنگام راه‌اندازی یا failover را محدود کند. محدودیت‌های فعلی را برای هر حساب و Region درخواست کنید، سپس ترافیک عادی، اوج، تلاش مجدد و failover کامل را بر اساس گیرنده مدل کنید، نه فقط نشست‌های SMTP. مشخص کنید آیا relay هنگام throttle پاسخ گذرا برمی‌گرداند و آیا کلاینت شما بدون باز کردن اتصال‌های بیش از حد آن را رعایت می‌کند. backpressure را زیر سقف تأییدشده آزمایش کنید و برای سهمیه باقی‌مانده، اشباع اتصال، سن صف و پاسخ‌های throttle هشدار تعریف کنید. تا زمانی که ارائه‌دهنده و اکوسیستم گیرندگان نتوانند ترافیک را پشتیبانی کنند، هم‌زمانی را افزایش ندهید. ظرفیت یک مرز سوءاستفاده هم هست، پس کنترل‌های هر اعتبارنامه و هر tenant را ارزیابی کنید، نه فقط یک حداکثر در سطح کل حساب.

احراز هویت فرستنده و فعال‌سازی دامنه را تأیید کنید

یک relay باید روند فعال‌سازی دامنه دقیق و قابل‌بازبینی ارائه دهد. تأیید کنید مالکیت را چگونه تأیید می‌کند، selectorهای DKIM را چگونه تولید می‌کند، دامنه envelope MAIL FROM را چگونه پیکربندی می‌کند و وضعیت احراز هویت را چگونه گزارش می‌دهد. SPF به هویت‌های SMTP مجوز می‌دهد و باید در یک رکورد معتبر موجود ادغام شود، نه اینکه به‌صورت رکورد SPF دوم قابل‌انتخاب منتشر شود. DKIM یک دامنه امضاکننده را با امضای رمزنگاری‌شده مرتبط می‌کند. DMARC ارزیابی می‌کند که آیا شناسه موفق SPF یا DKIM با دامنه From قابل‌مشاهده هم‌راستاست و به مالک دامنه اجازه می‌دهد سیاست منتشر کند و گزارش دریافت کند. بپرسید کلیدهای امضا، چرخش selector، هم‌راستایی return-path و تغییرات DNS در طول مهاجرت در کنترل چه کسی است. پیش از محیط عملیاتی پیام‌های کنترل‌شده بفرستید و هدرهای دریافت‌شده را بررسی کنید. داشبوردی که «تأییدشده» نشان می‌دهد ثابت نمی‌کند همه جریان‌های مشروع هم‌راستا هستند و احراز هویت رسیدن به صندوق ورودی را تضمین نمی‌کند.

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

SMTP submission به‌تنهایی فقط پاسخ فرمان‌ها را می‌دهد، در حالی که عملیات محصول به نتایج بعدی نیاز دارد. ارزیابی کنید آیا سرویس رویدادهای تحویل به سرور گیرنده، برگشت، گزارش اسپم، رد شدن، تأخیر و توقف ارسال را از طریق وب‌هوک‌های احراز هویت‌شده، صف‌ها یا APIها در اختیار می‌گذارد. شناسه‌های رویداد، رفتار تلاش مجدد، تضمین‌های ترتیب، نگهداری، تأیید امضا و امکان حذف جزئیات گیرنده را مشخص کنید. RFC 3461 یک افزونه SMTP برای درخواست اعلان‌های وضعیت تحویل در شرایط انتخاب‌شده تعریف می‌کند، اما سیستم‌های رویداد ارائه‌دهندگان می‌توانند داده‌های عملیاتی ساخت‌یافته‌تری ارائه دهند. شناسه job اپلیکیشن را هنگام پذیرش به شناسه پیام relay نگاشت کنید و سپس رویدادها را به‌صورت idempotent دریافت کنید. پذیرش، تحویل به سرور ایمیل گیرنده، گزارش اسپم، برگشت و رسیدن به صندوق ورودی را مفاهیمی جداگانه نگه دارید. مشاهده باز شدن و کلیک به بازبینی جداگانه حریم خصوصی نیاز دارد و نباید واقعیت انتقال را بازنویسی کند.

مرزهای فهرست توقف ارسال و اعتبار را ارزیابی کنید

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

multi-tenant، مشاهده‌پذیری و بازیابی از خطا را آزمایش کنید

دو tenant آزمایشی بسازید و ثابت کنید هر اعتبارنامه فقط می‌تواند از دامنه‌های تأییدشده خودش ارسال کند، فقط پیام‌های خودش را ببیند و فقط محدودیت‌های خودش را مصرف کند. نشانی From غیرمجاز، اعتبارنامه ابطال‌شده، پیام بیش از حد بزرگ، گیرنده نامعتبر، عبور از محدودیت نرخ، خطای TLS، timeout شبکه، ارسال تکراری، گیرنده برگشت‌خورده، گزارش اسپم، تحویل با تأخیر و وب‌هوک تکراری را امتحان کنید. تأیید کنید که لاگ‌ها شناسه پیام پایدار، tenant، دسته پاسخ پاک‌سازی‌شده، تعداد تلاش و زمان‌بندی را بدون کپی اعتبارنامه‌ها یا بدنه پیام‌ها دارند. از ارائه‌دهنده تاریخچه وضعیت، اطلاع‌رسانی رخدادها، رفتار failover منطقه‌ای، محل نگهداری داده، نگهداری، قالب‌های خروجی و مسیر ارجاع پشتیبانی را بخواهید. ادعای سطح سرویس فقط زمانی مفید است که اپلیکیشن بتواند نقض آن را تشخیص دهد و بازیابی کند. یک تمرین failover با پیام‌های در صف اجرا کنید و ثابت کنید پیکربندی جایگزین دامنه‌های تأییدشده، اعتبارنامه‌ها، سهمیه‌ها، رویدادها و وضعیت فهرست توقف ارسال را دارد.

SMTP relay را با API ایمیل مقایسه کنید

ارسال SMTP زمانی ارزشمند است که نرم‌افزار موجود از پیش SMTP صحبت می‌کند یا رابط انتقال ایمیل مستقل از ارائه‌دهنده اهمیت دارد. یک API ایمیل HTTPS می‌تواند اعتبارسنجی ساخت‌یافته، شناسه‌های منبع، semantics دسته‌ای و منابع رویداد مستقیم فراهم کند که کنترلشان برای یک اپلیکیشن جدید آسان‌تر است. تیم‌هایی که به سازگاری SMTP قدیمی نیاز دارند باید یک relay مستندشده انتخاب کنند یا یک adapter با کنترل سخت‌گیرانه بسازند. تیم‌هایی که گردش‌کارهای محصول جدید می‌سازند می‌توانند لایه API را بر اساس مجوزدهی، صف‌ها، رویدادها، مرزهای tenant، هزینه مهاجرت و مالکیت عملیاتی مقایسه کنند، نه اینکه فرض کنند SMTP خودبه‌خود قابل‌انتقال‌تر است.

یک ارزیابی امتیازدهی‌شده از relay اجرا کنید

پیش از درخواست پیشنهاد، یک ماتریس الزامات بسازید. امنیت submission، سازگاری کلاینت، فعال‌سازی دامنه، هم‌راستایی احراز هویت، پایداری صف، معنای تلاش مجدد، سهمیه‌ها، کامل بودن رویدادها، تأیید وب‌هوک، دامنه فهرست توقف ارسال، جداسازی tenantها، مشاهده‌پذیری، مدیریت داده، طراحی منطقه‌ای، پشتیبانی، قابلیت خروجی گرفتن و هزینه کل عملیات را وزن‌دهی کنید. شکست‌های قطعی را جدا از ترجیحات علامت بزنید: بازگشت به متن آشکار، نبود مسیر برگشت یا گزارش اسپم، رویدادهای غیرقابل‌تأیید، اعتبارنامه‌های مشترک، نبود بررسی مالکیت دامنه یا محدودیت‌های کمتر از تقاضای اوج نباید با یک قیمت پایین میانگین‌گیری و محو شوند. همان مجموعه آزمون کنترل‌شده را روی همه نامزدهای نهایی اجرا کنید و رونوشت‌ها را با حذف اسرار نگه دارید. رفتار مستند فعلی را امتیاز دهید، نه وعده‌های نقشه راه. پیش از مهاجرت، ارسال دوگانه با حجم کم، تغییرات DNS، تطبیق رویدادها، انتقال فهرست توقف ارسال، چرخش اعتبارنامه، بازگشت و ابطال نهایی relay قدیمی را تمرین کنید.

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

تفاوت SMTP submission و relay چیست؟

submission ایمیل خروجی را از یک کلاینت احراز هویت‌شده می‌پذیرد، معمولاً با پورت 587 و سیاست مخصوص submission. relay انتقال میان سرورهای ایمیل را توصیف می‌کند، معمولاً روی پورت 25 و با قواعد اعتماد و مسیریابی متفاوت.

آیا SMTP relay باید TLS را الزامی کند؟

برای submission اپلیکیشن، بله. TLS با اعتبارسنجی گواهی را الزامی کنید و وقتی سطح محرمانگی پیکربندی‌شده در دسترس نیست، از استفاده از اعتبارنامه یا ارسال پیام خودداری کنید. هم پورت پشتیبانی‌شده و هم رفتار downgrade را آزمایش کنید.

آیا SMTP 250 یعنی گیرنده پیام را دریافت کرده است؟

خیر. یعنی سرور مسئولیت فرمان یا پیام SMTP تکمیل‌شده را پذیرفته است. اعلان‌های وضعیت تحویل بعدی یا رویدادهای ارائه‌دهنده، تحویل به سرور گیرنده، برگشت، گزارش اسپم، تأخیر یا رد شدن را توصیف می‌کنند.

اپلیکیشن چگونه باید خطاهای SMTP را دوباره امتحان کند؟

خطاهای گذرای 4xx و خطاهای شبکه را با backoff محدود و هویت پایدار job دوباره امتحان کنید. خطاهای 5xx را پیش از تلاش بعدی اصلاح کنید و خطاهای مبهم پس از DATA را تطبیق دهید تا از پیام‌های تکراری جلوگیری شود.

آیا SMTP relayها DKIM، SPF و DMARC را مدیریت می‌کنند؟

قابلیت‌ها متفاوت است. تأیید کنید چه کسی DKIM را امضا می‌کند، از کدام دامنه MAIL FROM استفاده می‌شود، کدام مکانیزم SPF لازم است و آیا SPF یا DKIM برای DMARC با دامنه From قابل‌مشاهده هم‌راستاست.

چه زمانی API ایمیل بر SMTP relay ارجح است؟

API برای اپلیکیشن‌های جدیدی که به اعتبارسنجی ساخت‌یافته، شناسه‌های منبع، مجوز صریح tenant، نتایج دسته‌ای و منابع رویداد نیاز دارند می‌تواند ارجح باشد. SMTP برای نرم‌افزارهای موجودی که از SMTP پشتیبانی می‌کنند همچنان مفید است.

منابع

ادامه یادگیری

پروتکل ایمیل SMTP: ایمیل اپلیکیشن چگونه جابه‌جا می‌شودبا نحوه تأثیر submission، relay، envelope، کدهای پاسخ، TLS، تلاش‌های مجدد و محتوای پیام در SMTP بر گردش‌کار ایمیل اپلیکیشن آشنا شوید.راهنمای پیاده‌سازی API ایمیل برای تیم‌های محصولیکپارچه‌سازی امنی با API ایمیل طراحی کنید: دامنه‌های تأییدشده، ارسال از طریق صف، شناسه‌های پایدار، تلاش مجدد کنترل‌شده، رویدادهای تحویل، فهرست توقف ارسال و جداسازی tenantها.