اصطلاح · پورت SMTP

یک اپلیکیشن برای ایمیل از کدام پورت SMTP باید استفاده کند؟

بیشتر اپلیکیشن‌ها باید از endpoint و پورت submission مستندشده توسط ارائه‌دهنده ایمیل خود استفاده کنند. پورت 587 پورت استاندارد ارسال پیام است و معمولاً در SMTP ساده پیش از ارتقای STARTTLS آغاز می‌شود. پورت 465 ارسال پیام با TLS ضمنی است، پس handshake ‏TLS بلافاصله آغاز می‌شود. پورت 25 عمدتاً برای SMTP relay سروربه‌سرور است، نه ارسال معمول احرازشده اپلیکیشن. یک پیکربندی کارا باید چهار چیز را با هم مطابقت دهد: hostname، پورت، حالت TLS و روش احراز هویت.

پورت SMTP نقش پروتکل و حالت اتصال را تعیین می‌کند

شماره پورت صرفاً دری جایگزین‌پذیر به همان سرویس نیست. کمک می‌کند مشخص شود سرور کدام نقش SMTP را ارائه می‌دهد و اتصال چگونه آغاز می‌شود. ارسال پیام (submission) نخستین تحویل از یک اپلیکیشن یا user agent به یک سرویس submission است. relay انتقال ایمیل میان سرورهای ایمیل است. استانداردها این دو کار را جدا می‌کنند، زیرا submission ممکن است به احراز هویت، مجوز فرستنده و بررسی‌های سیاست پیام نیاز داشته باشد که به همان شکل برای relay عمومی ایمیل اعمال نمی‌شوند. پورت همچنین می‌تواند نشان دهد که آیا کلاینت با فرمان‌های SMTP شروع می‌کند و بعداً با STARTTLS ارتقا می‌یابد یا بلافاصله با handshake مربوط به TLS آغاز می‌کند. نام هاست، پورت، حالت TLS و دستورالعمل‌های احراز هویت ارائه‌دهنده را یک مجموعه پیکربندی واحد بدانید. کپی کردن پورت از یک ارائه‌دهنده نامرتبط، یا تغییر فقط پورت پس از یک خطا، می‌تواند یک مشکل شبکه را به خطای TLS یا احراز هویت تبدیل کند، بدون اینکه علت اصلی برطرف شود.

پورت 25 عمدتاً برای relay میان سرورهای ایمیل است

پورت 25 پورت متعارف relay در SMTP است که وقتی یک Message Transfer Agent ایمیل را به دیگری تحویل می‌دهد استفاده می‌شود. RFC 6409 relay را روی پورت 25 نگه می‌دارد و ارسال پیام‌های جدید را به پورت 587 منتقل می‌کند. بنابراین اپلیکیشن نباید فرض کند که اتصال مستقیم به سرورهای ایمیل گیرنده روی پورت 25 روش عادی ارسال ایمیل محصول است. relay مستقیم به صف‌بندی، مسیریابی DNS، مدیریت برگشت، کنترل‌های سوءاستفاده، مدیریت اعتبار و رفتار تلاش مجدد مطابق استانداردها نیاز دارد. شبکه‌ها و ارائه‌دهندگان میزبانی نیز ممکن است پورت 25 خروجی را محدود کنند. برای نمونه، AWS مستند کرده است که ترافیک ایمیل Amazon EC2 روی پورت 25 به‌طور پیش‌فرض محدود (throttle) می‌شود. پورت 25 همچنان می‌تواند گزینه‌ای مستند نزد یک ارائه‌دهنده یا درون زیرساخت کنترل‌شده باشد، اما در دسترس بودنش آن را به انتخاب ترجیحی برای submission تبدیل نمی‌کند. فقط زمانی از آن استفاده کنید که سرویس مسئول صراحتاً آن endpoint، حالت امنیتی و مدل عملیاتی را مستند کرده باشد.

پورت 587 پورت استاندارد ارسال پیام است

RFC 6409 پورت 587 را برای ارسال پیام رزرو می‌کند و سرویس submissionی را توصیف می‌کند که می‌تواند ایمیل غیرمجاز را رد کند، احراز هویت را الزامی کند و پیش از پذیرش پیام جدید سیاست را اعمال کند. یک نشست رایج روی پورت 587 به‌صورت SMTP آغاز می‌شود، پس از `EHLO` افزونه STARTTLS را اعلام می‌کند، اتصال را به TLS ارتقا می‌دهد، دوباره `EHLO` می‌فرستد، احراز هویت می‌کند و سپس پیام را ارسال می‌کند. واژه «رایج» مهم است: سازوکارها و الزامات دقیق احراز هویت از مستندات فعلی ارائه‌دهنده و قابلیت‌های سرور می‌آیند. یک کلاینت امن باید ارتقای موردانتظار TLS را الزامی کند و گواهی سرور را اعتبارسنجی کند، نه اینکه پس از شکست مذاکره با متن آشکار ادامه دهد. خوشامدگویی اولیه و رمزنگاری‌نشده پروتکل را با نشست احراز هویت‌شده بدون محافظت اشتباه نگیرید؛ STARTTLS طراحی شده تا آن اتصال را پیش از ارسال اعتبارنامه‌ها و داده‌های پیام ارتقا دهد. پورت 587 سرویس submission را مشخص می‌کند، در حالی که اعمال موفق TLS به سیاست درست کلاینت بستگی دارد.

پورت 465 برای submission از TLS ضمنی استفاده می‌کند

پورت 465 برای ارسال پیام روی TLS ضمنی ثبت شده است. در TLS ضمنی، کلاینت به محض باز شدن اتصال TCP، handshake مربوط به TLS را انجام می‌دهد و فرمان‌های SMTP را فقط درون کانال محافظت‌شده می‌فرستد. این با پورت 587 همراه STARTTLS فرق دارد که در آن کلاینت ابتدا خوشامدگویی SMTP را دریافت می‌کند و سپس ارتقا را درخواست می‌کند. RFC 8314 برای submission، TLS ضمنی را توصیه می‌کند و در عین حال دوره‌ای انتقالی را توصیف می‌کند که در آن ارائه‌دهندگان و کلاینت‌ها می‌توانند هم از پورت 465 با TLS ضمنی و هم از پورت 587 با STARTTLS پشتیبانی کنند. این RFC یادآوری می‌کند که وقتی TLS الزامی باشد، کلاینت‌ها و سرورهایی که درست پیاده‌سازی شده‌اند با هر دو حالت می‌توانند امنیت عملاً معادلی فراهم کنند. قاعده عملی این است که یک پورت را در همه‌جا درست اعلام نکنید. از endpoint و حالتی که ارائه‌دهنده دقیقاً پشتیبانی می‌کند استفاده کنید. پیکربندی STARTTLS در برابر listener با TLS ضمنی، یا TLS ضمنی در برابر listener با STARTTLS، معمولاً پیش از احراز هویت شکست می‌خورد.

پورت‌های جایگزین مخصوص ارائه‌دهنده قراردادهایی صریح‌اند

برخی ارائه‌دهندگان برای دور زدن محدودیت‌های شبکه پورت‌های جایگزین ارائه می‌دهند، اما این شماره‌ها استاندارد جهانی SMTP برای همه سرویس‌ها نیستند. Amazon SES در حال حاضر STARTTLS را روی پورت‌های 25، 587 و 2587 و TLS Wrapper، اصطلاح خودش برای TLS ضمنی، را روی پورت‌های 465 و 2465 مستند کرده است. SES اتصال رمزنگاری‌شده را الزامی می‌کند و endpointهای SMTP مخصوص هر region را منتشر می‌کند. این نشان می‌دهد چرا پورت باید از مستندات ارائه‌دهنده انتخاب‌شده گرفته شود، نه از یک فهرست عمومی. پورت 2587 به معنای STARTTLS در همه‌جا نیست و پورت 2465 سرویس TLS ضمنی را روی هاست‌های دلخواه مشخص نمی‌کند. پورت‌های جایگزین همچنین تأیید فرستنده، دامنه دسترسی اعتبارنامه، سهمیه‌ها یا سیاست ارائه‌دهنده را دور نمی‌زنند. نشانی منبع و تاریخ تأیید را همراه پیکربندی محیط عملیاتی ثبت کنید تا اپراتور بتواند یک تنظیم عمدی ارائه‌دهنده را از عددی جادویی و بی‌توضیح که سال‌ها پیش در یک متغیر محیطی کپی شده تشخیص دهد.

نام هاست، پورت، TLS و احراز هویت را با هم پیکربندی کنید

یک پیکربندی مستحکم SMTP یک مجموعه است: نام هاست ارائه‌دهنده، پورت، حالت امنیت انتقال، سیاست اعتبارسنجی گواهی، سازوکار احراز هویت، نام کاربری، راز، timeout اتصال و هویت ارسال. نام هاست اهمیت دارد، زیرا گواهی TLS در برابر آن اعتبارسنجی می‌شود و ارائه‌دهندگان ممکن است endpointهای منطقه‌ای متفاوتی ارائه دهند. پورت و حالت TLS باید با هم سازگار باشند. احراز هویت باید فقط پس از برقراری کانال محافظت‌شده موردنظر انجام شود و اسرار باید در یک مدیر اسرار بمانند، نه در کد منبع، bundleهای مرورگر، لاگ‌ها یا خروجی عیب‌یابی. اعتبارنامه‌ها و پیکربندی را بر اساس محیط جدا کنید تا یک آزمون محلی نتواند به‌اشتباه از طریق محیط عملیاتی ارسال کند. timeoutهای محدود برای اتصال و فرمان‌ها تعیین کنید، اما بگذارید یک صف پایدار در اپلیکیشن تلاش‌های مجدد پیام را کنترل کند. گزینه‌ای به نام `secure` در یک SDK ممکن است به معنای TLS ضمنی باشد و در SDK دیگر فقط STARTTLS را الزامی کند، پس تعریف کتابخانه را بررسی کنید و رفتار مذاکره‌شده را آزمایش کنید، نه اینکه به نام گزینه تکیه کنید.

اتصال را لایه‌به‌لایه و بدون افشای اسرار آزمایش کنید

با resolve کردن DNS و دسترسی‌پذیری TCP از همان شبکه اجرایی اپلیکیشن شروع کنید. timeout پیش از اتصال به مسیریابی، فایروال، سیاست خروجی ارائه‌دهنده، نام هاست اشتباه یا پورت بسته اشاره دارد. سپس حالت موردانتظار TLS را آزمایش کنید. در TLS ضمنی، یک کلاینت TLS باید گواهی و سپس خوشامدگویی SMTP را دریافت کند. در STARTTLS، یک کلاینت آشنا با SMTP باید خوشامدگویی را دریافت کند، `EHLO` بفرستد، اعلام STARTTLS را ببیند، ارتقا را درخواست کند، گواهی را اعتبارسنجی کند و پس از TLS دوباره `EHLO` بفرستد. RFC 3207 الزام می‌کند کلاینت و سرور دانسته‌های پیش از handshake را کنار بگذارند و به همین دلیل `EHLO` دوم اهمیت دارد. فقط پس از آن احراز هویت را با یک حساب کنترل‌شده آزمایش کنید. پیش از اشتراک‌گذاری لاگ‌ها، نام‌های کاربری، توکن‌ها، نشانی گیرندگان، رونوشت کامل سرور و محتوای پیام را حذف کنید. یک آزمون اتصال به ارسال در محیط عملیاتی یا نشانی واقعی مشتری نیاز ندارد.

خطاها را بر اساس مرحله‌ای که واقعاً شکست خورده دسته‌بندی کنید

connection refused یعنی مقصد TCP فعالانه اتصال را رد کرده است؛ timeout یعنی هیچ پاسخ قابل‌استفاده‌ای در مهلت تعیین‌شده نرسیده است. خطای handshake در TLS به عدم تطابق حالت، مشکل گواهی، ناسازگاری پروتکل، رهگیری یا endpoint اشتباه اشاره دارد. خطای احراز هویت در مرحله‌ای بعدتر رخ می‌دهد و باید به‌عنوان مشکل پیکربندی اعتبارنامه، سازوکار، حساب یا مجوز بررسی شود، نه اینکه با تغییر تصادفی پورت رفع شود. کدهای پاسخ SMTP در `MAIL FROM`، `RCPT TO` یا `DATA` تصمیم‌های بعدی سیاست و پیام را توصیف می‌کنند. مرحله، زمان، endpoint، تعداد تلاش، پاسخ عددی و پاسخ فیلترشده از نظر حریم خصوصی را نگه دارید. پاسخ 4xx در SMTP معمولاً گذراست و پاسخ 5xx معمولاً برای همان فرمان دائمی است، اما تلاش‌های مجدد باید محدود و آگاه از گیرنده باشند. اگر ارائه‌دهنده داده پیام را پذیرفته است، صرفاً به این دلیل که یک درخواست بعدی اپلیکیشن دچار timeout شده، کورکورانه نسخه تکراری ارسال نکنید؛ با شناسه ارائه‌دهنده و تاریخچه رویدادها تطبیق دهید.

موفقیت پورت به معنای تحویل پیام یا رسیدن به صندوق ورودی نیست

اتصال موفق TCP فقط ثابت می‌کند که یک listener پاسخ داده است. handshake موفق TLS، وقتی اعتبارسنجی گواهی موفق باشد، اتصال محافظت‌شده به endpoint احراز هویت‌شده را ثابت می‌کند. احراز هویت ثابت می‌کند که سرور هویت ارائه‌شده کلاینت را برای آن نشست پذیرفته است. پاسخ SMTP `250` پس از داده پیام یعنی سرور پاسخ‌دهنده طبق پروتکل مسئولیت را پذیرفته است، نه اینکه کسی پیام را دریافت کرده یا خوانده است. یک relay بعدی همچنان ممکن است شکست بخورد و سیستم گیرنده ممکن است ایمیل را بپذیرد اما آن را خارج از صندوق ورودی اصلی دسته‌بندی کند. این وضعیت‌ها را در سوابق و پایش اپلیکیشن جدا نگه دارید. در دسترس بودن شبکه، مذاکره TLS، احراز هویت، پذیرش توسط ارائه‌دهنده، پذیرش توسط سرور مقصد، برگشت، گزارش اسپم و تعامل مشاهدات متفاوتی هستند. این تفکیک مانع می‌شود یک آزمون پورت به‌اشتباه آزمون تحویل گزارش شود و مانع می‌شود پیامی پذیرفته‌شده صرفاً به این دلیل که رسیدن به صندوق ورودی قابل‌اثبات نیست دوباره ارسال شود.

میان SMTP submission و API ایمیل آگاهانه انتخاب کنید

وقتی سامانه از پیش کلاینت SMTP بالغی دارد، پلتفرم موردنیاز SMTP را به‌عنوان یکپارچه‌سازی پشتیبانی‌شده ارائه می‌کند یا کنترل‌های سطح پروتکل به‌طور مشخص ضروری‌اند، از ارسال SMTP استفاده کنید. یک API ایمیل HTTPS می‌تواند هنگامی که درخواست‌های ساخت‌یافته، tokenهای محدودشده، idempotency، منابع دسته‌ای و رکوردهای رویداد machine-readable با workload متناسب‌اند، مرز اپلیکیشن بهتری باشد. ارائه‌دهنده همچنان می‌تواند برای رسیدن به سامانه‌های ایمیل گیرنده از SMTP در پایین‌دست استفاده کند؛ بنابراین API انتقال ایمیل را حذف نمی‌کند. این کار مسئولیت پورت، TLS، احراز هویت و تلاش مجدد برای handoff روبه‌ارائه‌دهنده را از پیکربندی SMTP اپلیکیشن خارج می‌کند.

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

اپلیکیشن من باید از پورت SMTP ‏587 استفاده کند یا 465؟

از پورت و حالت TLS مستند ارائه‌دهنده خود استفاده کنید. پورت 587 معمولاً از STARTTLS استفاده می‌کند، در حالی که پورت 465 از TLS ضمنی استفاده می‌کند. هر دو وقتی درست پیاده‌سازی و الزامی شوند می‌توانند از submission محافظت کنند؛ پیکربندی کلاینت باید با listener سرور منطبق باشد.

چرا پورت SMTP ‏25 مسدود است یا دچار timeout می‌شود؟

پلتفرم میزبانی، ISP، فایروال یا سیاست مقصد ممکن است پورت 25 را محدود کند، زیرا برای relay میان سرورهای ایمیل استفاده می‌شود و اغلب مورد سوءاستفاده قرار می‌گیرد. سیاست شبکه را تأیید کنید و به‌جای دور زدن محدودیت با یک پورت دلخواه، از endpoint ارسال (submission) مستند ارائه‌دهنده استفاده کنید.

آیا می‌توانم بدون تغییر هیچ چیز دیگری از پورت 587 به 465 بروم؟

معمولاً نه. پورت 587 معمولاً با SMTP شروع می‌شود و از طریق STARTTLS ارتقا می‌یابد، در حالی که پورت 465 با handshake فوری TLS آغاز می‌شود. پورت و حالت TLS کلاینت را با هم و طبق مستندات ارائه‌دهنده و کتابخانه تغییر دهید.

آیا پورت 587 به‌طور پیش‌فرض رمزنگاری‌شده است؟

این پورت ارسال پیام را مشخص می‌کند، اما رمزنگاری همچنان به مذاکره STARTTLS و سیاست کلاینت بستگی دارد. کلاینت را طوری پیکربندی کنید که ارتقای موفق را الزامی کند، گواهی را اعتبارسنجی کند و اگر submission محافظت‌شده برقرار نشد، از ارسال اعتبارنامه‌ها یا داده‌های پیام خودداری کند.

خطای SMTP connection refused به چه معناست؟

یعنی مقصد TCP پیش از مذاکره SMTP اتصال را رد کرده است. علت‌های رایج عبارت‌اند از هاست یا پورت اشتباه، سرویسی که گوش نمی‌دهد، رد شدن توسط فایروال یا endpoint ارائه‌دهنده‌ای که از آن شبکه در دسترس نیست.

آیا آزمون موفق پورت SMTP تحویل ایمیل را ثابت می‌کند؟

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

منابع

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

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