پیش‌نویس:احراز هویت SMTP

احراز هویت SMTP، که اغلب به‌اختصار SMTP AUTH نامیده می‌شود، افزونه‌ای برای پروتکل ساده ایمیل‌رسانی (SMTP) است که به‌وسیلهٔ آن یک کارخواه می‌تواند با استفاده از هر سازوکار احراز هویتی که کارساز پشتیبانی می‌کند، وارد سامانه شود. این افزونه عمدتاً توسط کارسازهای ارسال نامه استفاده می‌شود؛ جایی که احراز هویت الزامی است.RFCهای مرتبط برای مراجعه در بخش استانداردها مشخص شده‌اند.

 تاریخچه 
SMTP، آن‌گونه که جان پاستل در دههٔ ۱۹۷۰ مشخص کرده بود، امکان استفاده از گذرواژه برای ارسال پیام‌های رایانامه‌ای را فراهم نمی‌کرد؛ هر کارساز بنا بر طراحی یک رلهٔ باز رایانامه بود.

در نتیجه، هرزنامه و کرم‌های رایانه‌ای، با اینکه در ابتدا مشکلی محسوب نمی‌شدند، تا اواخر دههٔ ۱۹۹۰ به معضلی فراگیر تبدیل شده بودند. پیش از SMTP AUTH، یک کارخواه رله باید از طریق نشانی آی‌پی شناسایی می‌شد. این کار تنها برای خدمات رایانامه‌ای که همان رساننده خدمات اینترنتی تأمین‌کنندهٔ اتصال ارائه می‌کرد، عملی بود؛ در غیر این صورت باید از ترفندهای خاصی مانند پاپ پیش از SMTP استفاده می‌شد.

جان گاردینر مایرز نخستین پیش‌نویس SMTP AUTH را در سال ۱۹۹۵ منتشر کرد، و این افزونه پس از آن، همراه با پروتکل ارسال نامه، SMTP توسعه‌یافته یا ESMTP و لایه ساده احراز هویت و امنیت یا SASL، به‌طور پیوسته در کارگروه مهندسی اینترنت توسعه یافت و مورد بحث قرار گرفت.

یکی از سازوکارهای قدیمی SASL برای احراز هویت ESMTP که ESMTPA نیز نامیده می‌شود، CRAM-MD5 است و استفاده از الگوریتم ام‌دی۵ در HMACها یا کدهای احراز هویت پیام مبتنی بر درهم‌سازی، همچنان معتبر تلقی می‌شود.Sean Turner و Lily Chen، Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms، کارگروه مهندسی اینترنت، مارس ۲۰۱۱، ، RFC 6151.

کنسرسیوم رایانامه اینترنتی یا IMC گزارش کرد که در سال ۱۹۹۸، ۵۵ درصد از کارسازهای رایانامه، رلهٔ باز بودند، اما این میزان در سال ۲۰۰۲ به کمتر از یک درصد رسیده بود.

 نقش در سامانهٔ انتقال رایانامه 
استفاده از یک عامل ارسال نامه یا MSA، که معمولاً روی درگاه ۵۸۷ فعالیت می‌کند، مستلزم استفاده از SMTP AUTH است.

استفاده از MSA توسط بیشتر نرم‌افزارها پشتیبانی می‌شود و به‌ویژه برای پشتیبانی از کاربران سیار توصیه می‌شود؛ زیرا چندین گرهٔ شبکه، درگاه ۲۵ را مسدود می‌کنند یا از پراکسی‌های SMTP استفاده می‌کنند.

MSA مسئول اطمینان از این است که پاکت پیام حاوی نشانی‌های معتبر باشد و ممکن است سیاست‌های محلی مربوط به فیلد سرآیند From را نیز اعمال کند. بررسی اینکه فرستندهٔ پاکت، که با عنوان Return-Path نیز شناخته می‌شود و برای SPF به کار می‌رود، و نشانی From با شناسهٔ کاربری احراز هویت‌شده مطابقت داشته باشند، به‌ویژه برای دامنه‌هایی که پیام‌ها را با استفاده از DKIM امضا می‌کنند اهمیت دارد.

هنگامی که پیام‌ها با SMTP AUTH دریافت می‌شوند، کلیدواژه‌هایی که به حرف «A» ختم می‌شوند، مانند ESMTPA و ESMTPSA، برای عبارت with در فیلدهای سرآیند Received در نظر گرفته شده‌اند. طبق RFC 3848، «این کلیدواژه‌ها برای مقاصد آماری یا تشخیصی ارائه شده‌اند»؛ برخی کارخواه‌ها، برای نمونه اسپم‌اساسین، آن‌ها را بررسی می‌کنند.

 جزئیات 
همانند همهٔ افزونه‌های SMTP، پشتیبانی از SMTP AUTH در پاسخ EHLO و همراه با فهرستی از روش‌های احراز هویت پشتیبانی‌شده اعلام می‌شود. این روش‌ها ممکن است پس از اجرای STARTTLS تغییر کنند؛ معمولاً تنها پس از اجرای آن، گذرواژه‌های متن ساده مجاز می‌شوند.

RFC 4954 نمونهٔ زیر را ارائه می‌کند («C:» و «S:» بخشی از پروتکل نیستند و به‌ترتیب خطوط ارسال‌شده توسط کارخواه و کارساز را نشان می‌دهند):

S: 220 smtp.example.com ESMTP Server
C: EHLO client.example.com
S: 250-smtp.example.com Hello client.example.com
S: 250-AUTH GSSAPI DIGEST-MD5
S: 250-ENHANCEDSTATUSCODES
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
... TLS negotiation proceeds.
Further commands protected by TLS layer ...
C: EHLO client.example.com
S: 250-smtp.example.com Hello client.example.com
S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN
C: AUTH PLAIN aWxvdmV3aWtpcGVkaWE=
S: 235 2.7.0 Authentication successful

SMTP AUTH را می‌توان روی درگاه ۲۵ نیز استفاده کرد. کارسازها معمولاً فرمان‌های RCPT TO را که مستلزم رله‌کردن پیام هستند، تا زمانی که اطلاعات احراز هویت پذیرفته نشده باشند، رد می‌کنند.

مشخصات توصیه می‌کند اگر کارساز به‌گونه‌ای پیکربندی شده باشد که احراز هویت را الزامی بداند و کارخواه هنوز احراز هویت نکرده باشد، در پاسخ به بیشتر فرمان‌ها پیام 530 5.7.0 Authentication required را صادر کند. فقط کارسازهایی که روی درگاه ۵۸۷ گوش می‌دهند یا کارسازهای خصوصی باید به این صورت پیکربندی شوند، نه یک کارساز تبادل پیام یا MX.

با این حال، ویژگی تاریخی SMTP که بر اساس آن احراز هویت به‌طور پیش‌فرض انجام نمی‌شود، در برخی موارد موجب رفتاری متفاوت در مقایسه با پروتکل‌های دسترسی می‌شود؛ برای نمونه، هنگام استفاده از AUTH EXTERNAL پس از STARTTLS.

افزون بر فرمان AUTH، این افزونه یک پارامتر AUTH نیز برای فرمان MAIL FROM فراهم می‌کند تا بتوان احراز هویت را از مجوزدهی متمایز کرد.

به این ترتیب، یک فرستنده می‌تواند خود را شناسایی کند و در طول یک نشست چندین پیام را انتقال دهد. پس از برقراری احراز هویت، لازم نیست هویت تغییر کند؛ با این حال، پیام‌های مختلف ممکن است بر اساس توافق‌های متفاوتی ارسال شوند و در نتیجه به مجوزهای متفاوتی نیاز داشته باشند. برای نمونه، ممکن است پیام‌ها از طرف کاربران مختلف رله شوند.

استفاده از این پارامتر بسیار کمتر از استفاده از فرمان AUTH برای اعطای امتیاز رله رایج است.

احراز هویت SMTP در اصطلاح SMTP یک «افزونه» است؛ بنابراین کارساز و کارخواه باید برای اعلام پشتیبانی از افزونه‌ها، به‌جای خوشامدگویی منسوخ‌شدهٔ HELO از فعل EHLO برای خوشامدگویی استفاده کنند.Simple Mail Transfer Protocol، کارگروه مهندسی اینترنت، بخش ۲٫۲٫۱، ، RFC 5321: «با این حال، برای سازگاری با پیاده‌سازی‌های منطبق قدیمی‌تر، کارخواه‌ها و کارسازهای SMTP باید سازوکارهای اصلی HELO را به‌عنوان راهکار بازگشت پشتیبانی کنند.» برای سازگاری با نسخه‌های پیشین، ممکن است خوشامدگویی HELO هنگامی پذیرفته شود که هیچ افزونه‌ای استفاده نمی‌شود.

متن نوشته‌شده با حروف بزرگ پس از فرمان AUTH، فهرستی از انواع مجوزدهی است که کارساز SMTP می‌پذیرد.

برخی از نمونه‌های پروتکل‌های مجوزدهی عبارت‌اند از:

 PLAIN — از کدگذاری Base64 استفاده می‌کند.
 LOGIN — از کدگذاری Base64 استفاده می‌کند.K. Murchison و M. Crispin، The LOGIN SASL Mechanism، ۲۸ اوت ۲۰۰۳، پیش‌نویس منقضی‌شده. LOGIN در سند SASL Mechanisms منسوخ توصیف شده است، اما این سازوکار همچنان مورد استفاده قرار می‌گیرد. این روش به نفع PLAIN منسوخ شده است.
 GSSAPI — رابط برنامه‌نویسی کاربردی خدمات امنیت عمومی
 DIGEST-MD5 — احراز هویت مختصر
 MD5
 CRAM-MD5
 OAUTH10A — توکن‌های HMAC-SHA1 نسخهٔ ۱٫۰a پروتکل OAuth، مطابق تعریف RFC 5849
 OAUTHBEARER — توکن‌های حامل OAuth 2.0، مطابق تعریف RFC 6750
 XOAUTH2Gmail's XOAuth2 SASL protocol

 استانداردها 

 RFC 3207، SMTP Service Extension for Secure SMTP over Transport Layer Security، Paul Hoffman، فوریهٔ ۲۰۰۲.
 RFC 3848، ESMTP and LMTP Transmission Types Registration، Chris Newman، ژوئیهٔ ۲۰۰۴.
 RFC 6409، Message Submission for Mail، Randall Gellens و John C. Klensin، نوامبر ۲۰۱۱. این سند جایگزین RFC 4409 مصوب سال ۲۰۰۶ شده است؛ RFC 4409 نیز جایگزین RFC 2476 مصوب دسامبر ۱۹۹۸ بود.
 RFC 4422، Simple Authentication and Security Layer (SASL)، Alexey Melnikov و Kurt D. Zeilenga، ژوئن ۲۰۰۶.
 RFC 4616، The PLAIN SASL Mechanism، K. Zeilenga، ویراستار، اوت ۲۰۰۶.
 RFC 4954، SMTP Service Extension for Authentication، Robert Siemborski و Alexey Melnikov، ژوئیهٔ ۲۰۰۷.
 RFC 7628، A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth، W. Mills، T. Showalter و H. Tschofenig، اوت ۲۰۱۵.

 دیگر 

 Erwin Hoffmann، SMTP Authentication [Tutorial]، آخرین ویرایش در ۱۰ ژانویهٔ ۲۰۱۷.

 جستارهای وابسته 

 احراز هویت رایانامه
 پروتکل ساده ایمیل‌رسانی
 عامل ارسال نامه
 شماره‌های درگاه رایانامه‌خوان
 لایه ساده احراز هویت و امنیت
 رله باز رایانامه
 پاپ پیش از SMTP

 منابع 

:رده:تأیید هویت پست الکترونیکی
:رده:پروتکل‌های پست الکترونیک اینترنت
:رده:پروتکل‌های کنترل دسترسی رایانه