مصادقة SMTP

مصادقة SMTP ، والتي تُختصر غالبًا إلى SMTP AUTH ، هي امتداد لبروتوكول نقل البريد البسيط (SMTP) حيث يمكن للعميل تسجيل الدخول باستخدام أي آلية مصادقة يدعمها الخادم. وتُستخدم بشكل أساسي من قِبل خوادم الإرسال ، حيث تكون المصادقة إلزامية. ^{[ 1 ]}

لم يسمح بروتوكول SMTP، كما حدده جون بوستل في سبعينيات القرن الماضي، باستخدام كلمات المرور لإرسال رسائل البريد الإلكتروني؛ فقد كان كل خادم مصممًا ليكون خادمًا مفتوحًا لإعادة توجيه البريد . ونتيجة لذلك، تحولت الرسائل المزعجة والفيروسات ، التي لم تكن مشكلة في البداية، إلى آفة بحلول أواخر التسعينيات. ^{[ 2 ]} قبل بروتوكول SMTP AUTH، كان يجب تحديد هوية عميل إعادة التوجيه بواسطة عنوان IP ، وهو أمر عملي فقط لخدمات البريد الإلكتروني التي يقدمها نفس مزود خدمة الإنترنت (ISP) الذي يوفر الاتصال، أو باستخدام ثغرات محددة، مثل استخدام بروتوكول POP قبل SMTP .

نشر جون غاردينر مايرز المسودة الأولى لبروتوكول SMTP AUTH عام 1995، ^{[ 3 ]} وقد جرى تطويره ومناقشته تباعًا في فريق عمل هندسة الإنترنت (IETF) جنبًا إلى جنب مع بروتوكول إرسال البريد، وبروتوكول SMTP الموسع (ESMTP)، وطبقة المصادقة والأمان البسيطة (SASL). وتُعد آلية CRAM-MD5 إحدى آليات SASL القديمة لمصادقة ESMTP (ESMTPA) ، ولا يزال استخدام خوارزمية MD5 في رموز مصادقة الرسائل القائمة على التجزئة ( HMACs ) يُعتبر سليمًا. ^{[ 4 ]}

أفاد اتحاد البريد الإلكتروني (IMC) أن 55٪ من خوادم البريد كانت عبارة عن خوادم مفتوحة في عام 1998، ^{[ 5 ]} ولكن أقل من 1٪ في عام 2002. ^{[ 6 ]}

استخدام وكيل إرسال البريد (MSA)، عادةً على المنفذ 587، يستلزم مصادقة SMTP. يدعم معظم البرامج استخدام MSA ^{[ 7 ]} ، ويُنصح به، خاصةً لدعم المستخدمين المتنقلين، حيث أن العديد من مراكز الشبكة إما تحظر المنفذ 25 أو تستخدم خوادم بروكسي SMTP . يتولى MSA مسؤولية ضمان احتواء مغلف الرسالة على عناوين صحيحة، وقد يفرض سياسات محلية لحقل Fromالترويسة. يُعد التحقق من تطابق مُرسِل المغلف ( المعروف أيضًا باسم SPFReturn-Path ) وعنوان " من " مع مُعرّف المستخدم المُصادق عليه أمرًا بالغ الأهمية للنطاقات التي تُوقّع الرسائل باستخدام DKIM .

تُستخدم الكلمات المفتاحية التي تنتهي بالحرف "A"، مثل " ESMTPAو "، في قسم حقول الترويسة عند استلام الرسائل باستخدام بروتوكول SMTP AUTH. ^{[ 8 ]} "تُستخدم هذه الكلمات المفتاحية لأغراض إحصائية أو تشخيصية" (RFC 3848)؛ ويتم التحقق منها بواسطة بعض العملاء، مثل Spamassassin .ESMTPSAwithReceived

كما هو الحال مع جميع امتدادات SMTP، يتم الإعلان عن SMTP AUTH في استجابة EHLO، إلى جانب قائمة بطرق المصادقة المدعومة. قد تتغير هذه الطرق بعد إصدار STARTTLS ، وعادةً ما تسمح بكلمات المرور النصية فقط في الحالة الأخيرة. يقدم RFC 4954 المثال التالي ("C:" و"S:" ليسا جزءًا من البروتوكول، بل يشيران إلى الخطوط المرسلة من العميل والخادم، على التوالي):

S: 220 smtp.example.com خادم ESMTP ج: EHLO client.example.com S: 250-smtp.example.com مرحباً client.example.com S: 250-AUTH GSSAPI DIGEST-MD5 S: 250-ENHANCEDSTATUSCODES S: 250 STARTTLS ج: STARTTLS S: 220 جاهز لبدء TLS ... تستمر عملية التفاوض على بروتوكول TLS. الأوامر الإضافية محمية بواسطة طبقة TLS ... ج: EHLO client.example.com S: 250-smtp.example.com مرحباً client.example.com S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN C: AUTH PLAIN aWxvdmV3aWtpcGVkaWE= S: 235 2.7.0 تم المصادقة بنجاح

يمكن استخدام مصادقة SMTP أيضًا على المنفذ 25. عادةً، ترفض الخوادم أوامر RCPT TO التي تتضمن إعادة التوجيه ما لم يتم قبول بيانات اعتماد المصادقة. توصي المواصفات بأن تُصدر الخوادم رسالة 530 5.7.0 "المصادقة مطلوبة" استجابةً لمعظم الأوامر في حال تم تكوين الخادم لطلب المصادقة ولم يقم العميل بذلك بعد. يجب تكوين الخوادم التي تستمع على المنفذ 587 فقط، أو الخوادم الخاصة، بهذه الطريقة، وليس خادم تبادل الرسائل (MX). مع ذلك، فإن السمة التاريخية المتمثلة في عدم مصادقة SMTP افتراضيًا تؤدي إلى سلوك مختلف فيما يتعلق ببروتوكولات الوصول، في بعض الحالات؛ على سبيل المثال، عند استخدام AUTH EXTERNAL بعد STARTTLS. ^{[ 9 ]}

إلى جانب أمر AUTH ، يوفر هذا الملحق أيضًا مُعامل AUTH لأمر MAIL FROM ، مما يسمح بالتمييز بين المصادقة والتفويض. وبهذه الطريقة، يمكن للمرسل تعريف نفسه وإرسال عدة رسائل خلال الجلسة نفسها. مع أن المصادقة لا تتطلب تغييرًا، إلا أنه بمجرد إنشائها، يمكن إرسال رسائل مختلفة وفقًا لاتفاقيات مختلفة، وبالتالي تتطلب تفويضات مختلفة. على سبيل المثال، يمكن إعادة توجيه الرسائل نيابةً عن مستخدمين مختلفين. يُعد استخدام هذا المُعامل أقل شيوعًا بكثير من استخدام الأمر لمنح صلاحيات إعادة التوجيه.

يُعدّ توثيق SMTP "امتدادًا" في مصطلحات SMTP، لذا فهو يتطلب من الخادم والعميل استخدام فعل EHLO للتحية للإشارة إلى دعم الامتدادات، بدلًا من تحية HELO القديمة. ^{[ 10 ]} ولضمان التوافق مع الإصدارات السابقة، يمكن قبول تحية HELO حتى في حال عدم استخدام أي امتداد .

النص المكتوب بأحرف كبيرة بعد أمر AUTH هو قائمة بأنواع التفويض التي سيقبلها خادم SMTP.

تتضمن بعض الأمثلة على بروتوكولات التفويض ما يلي:

• عادي (يستخدم ترميز Base64)
• تسجيل الدخول (يستخدم ترميز Base64) ^{[ 11 ]} (تم استبداله بـ PLAIN)
• GSSAPI ( واجهة برمجة تطبيقات خدمات الأمان العامة )
• DIGEST-MD5 ( مصادقة الوصول باستخدام الملخص )
• MD5
• CRAM-MD5
• OAUTH10A ( رموز OAuth 1.0a HMAC-SHA1 كما هو محدد في RFC 5849)
• OAUTHBEARER ( رموز حامل OAuth 2.0 كما هو محدد في RFC 6750)
• XOAUTH2 ^{[ 12 ]}

• RFC 3207 ، امتداد خدمة SMTP لبروتوكول SMTP الآمن عبر أمان طبقة النقل ، بول هوفمان، فبراير 2002. 
• RFC 3848 ، تسجيل أنواع الإرسال ESMTP وLMTP ، كريس نيومان، يوليو 2004. 
• RFC 6409 ، إرسال الرسائل للبريد ، راندال جيلينز وجون سي. كلينسين ، نوفمبر 2011 (يلغي RFC 4409، من عام 2006، والذي بدوره حل محل RFC 2476، من ديسمبر 1998). 
• RFC 4422 ، طبقة المصادقة والأمان البسيطة (SASL) ، أليكسي ميلنيكوف وكورت د. زيلينغا، يونيو 2006. 
• RFC 4616 ، آلية PLAIN SASL ، ك. زيلينغا، محرر، أغسطس 2006. 
• RFC 4954 ، امتداد خدمة SMTP للمصادقة ، روبرت سيمبورسكي وأليكسي ميلنيكوف، يوليو 2007. 
• RFC 7628 ، مجموعة من آليات طبقة المصادقة والأمان البسيطة (SASL) لـ OAuth ، دبليو ميلز، تي شوالتر وإتش تشوفينيج، أغسطس 2015. 

• إروين هوفمان، مصادقة SMTP [ شرح ] ، آخر تعديل 2017-01-10.

• التحقق من البريد الإلكتروني
• بروتوكول نقل البريد البسيط
• وكيل استلام البريد
• أرقام منافذ عميل البريد الإلكتروني
• طبقة مصادقة وأمان بسيطة
• خدمة البريد المفتوحة
• POP قبل SMTP