بروتوكول نقل البريد البسيط

الموسوعة الحرة

بروتوكول نقل البريد البسيط ( SMTP ) هو بروتوكول اتصال قياسي على الإنترنت لنقل البريد الإلكتروني . تستخدم خوادم البريد الإلكتروني وغيرها من وكلاء نقل الرسائل بروتوكول SMTP لإرسال واستقبال رسائل البريد. عادةً ما تستخدم برامج البريد الإلكتروني الخاصة بالمستخدمين بروتوكول SMTP فقط لإرسال الرسائل إلى خادم البريد لإعادة توجيهها، وعادةً ما ترسل رسائل البريد الإلكتروني الصادرة إلى خادم البريد عبر المنفذ 465 أو 587 وفقًا للمعيار RFC 8314. أما لاسترجاع الرسائل، فيُستخدم بروتوكولا IMAP وPOP على نطاق واسع، ولكن غالبًا ما تُطبّق الخوادم الخاصة أيضًا بروتوكولات خاصة بها ، مثل Exchange ActiveSync . 

بدأ تطوير بروتوكول SMTP في عام 1980، استنادًا إلى مفاهيم طُبقت على شبكة ARPANET منذ عام 1971. وقد خضع للتحديث والتعديل والتوسيع عدة مرات. يتميز الإصدار الشائع الاستخدام اليوم من البروتوكول ببنية قابلة للتوسيع مع إضافات متنوعة للمصادقة والتشفير ونقل البيانات الثنائية وعناوين البريد الإلكتروني الدولية . تستخدم خوادم SMTP عادةً بروتوكول التحكم بالنقل (TCP) على المنفذ 25 (بين الخوادم) والمنفذ 587 (لإرسال الرسائل من العملاء المصادق عليهم)، سواءً مع التشفير أو بدونه، والمنفذ 465 مع التشفير للإرسال.

تاريخ

أسلاف بروتوكول SMTP

استُخدمت أشكالٌ مختلفة من المراسلة الإلكترونية الفردية في ستينيات القرن الماضي. وكان المستخدمون يتواصلون باستخدام أنظمةٍ طُوّرت لأجهزة حاسوب مركزية مُحددة. ومع ازدياد ترابط أجهزة الحاسوب، لا سيما في شبكة أربانت التابعة للحكومة الأمريكية ، وُضعت معاييرٌ تسمح بتبادل الرسائل بين أنظمة التشغيل المختلفة.

يعود تاريخ البريد على شبكة أربانت إلى عام 1971: بروتوكول صندوق البريد، الذي لم يُنفذ [ 1 ] ولكنه مُناقش في RFC 196 ؛ وبرنامج SNDMSG ، الذي عدّله راي توملينسون من شركة BBN في ذلك العام لإرسال الرسائل بين جهازَي كمبيوتر على شبكة أربانت. [ 2 ] [ 3 ] [ 4 ] وقُدِّم اقتراح آخر لبروتوكول بريد في RFC 524 في يونيو 1973، [ 5 ] والذي لم يُنفذ أيضًا. [ 6 ] 

تم اقتراح استخدام بروتوكول نقل الملفات (FTP) للبريد الإلكتروني الشبكي على شبكة أربانت في RFC 469 في مارس 1973. [ 7 ] ومن خلال RFC 561 وRFC 680 وRFC 724، وأخيرًا RFC 733 في نوفمبر 1977، تم تطوير إطار عمل موحد للبريد الإلكتروني باستخدام خوادم بريد FTP. [ 8 ] [ 9 ]

نشأ بروتوكول SMTP من هذه المعايير التي وُضعت خلال سبعينيات القرن العشرين. ناقش راي توملينسون البريد الشبكي ضمن فريق العمل الدولي للشبكات (INWG) في مذكرة بروتوكول INWG رقم 2 ، التي كُتبت في سبتمبر 1974. [ 10 ] ناقش فريق العمل الدولي للشبكات بروتوكولات البريد الإلكتروني في عام 1979، [ 11 ] والتي استشهد بها جون بوستل في أعماله المبكرة حول البريد الإلكتروني على الإنترنت. اقترح بوستل لأول مرة بروتوكول رسائل الإنترنت في عام 1979 كجزء من سلسلة مذكرات تجارب الإنترنت (IEN). [ 12 ] [ 13 ] [ 14 ]

SMTP الأصلي

في عام ١٩٨٠، نشر بوستل وسوزان سلويزر RFC ٧٧٢ الذي اقترح بروتوكول نقل البريد كبديل لاستخدام بروتوكول نقل الملفات (FTP) للبريد. وفي مايو ١٩٨١، أزال RFC ٧٨٠ جميع الإشارات إلى FTP وخصص المنفذ ٥٧ لبروتوكولي TCP و UDP ، [ ١٥ ] وهو تخصيص ألغته هيئة IANA لاحقًا . وفي نوفمبر ١٩٨١، نشر بوستل RFC ٧٨٨ بعنوان "بروتوكول نقل البريد البسيط".   

تم تطوير معيار SMTP في نفس الوقت تقريبًا الذي تم فيه تطوير Usenet ، وهي شبكة اتصالات من واحد إلى متعدد ذات بعض أوجه التشابه. [ 15 ]

انتشر استخدام بروتوكول SMTP على نطاق واسع في أوائل ثمانينيات القرن العشرين. في ذلك الوقت، كان مكملاً لبرنامج نسخ يونكس إلى يونكس (UUCP)، الذي كان أكثر ملاءمةً لنقل البريد الإلكتروني بين الأجهزة المتصلة بالشبكة بشكل متقطع. من ناحية أخرى، يعمل SMTP بكفاءة عالية عندما يكون كل من جهاز الإرسال وجهاز الاستقبال متصلين بالشبكة باستمرار. يستخدم كلا البروتوكولين آلية التخزين والتوجيه ، وهما مثالان على تقنية الدفع . على الرغم من أن مجموعات أخبار يوزنت كانت لا تزال تُنشر باستخدام UUCP بين الخوادم، [ 16 ] إلا أن UUCP كوسيلة لنقل البريد قد اختفى تقريبًا [ 17 ]، إلى جانب " مسارات الإيقاع " التي كان يستخدمها كعناوين لتوجيه الرسائل. [ 18 ]

كان برنامج Sendmail ، الذي صدر مع نظام التشغيل 4.1cBSD عام 1983، من أوائل برامج نقل البريد ( MTA ) التي طبقت بروتوكول SMTP. [ 19 ] ومع مرور الوقت، ومع انتشار نظام التشغيل BSD Unix ليصبح النظام الأكثر شيوعًا على الإنترنت، أصبح Sendmail برنامج نقل البريد الأكثر استخدامًا. [ 20 ]

كان بروتوكول SMTP الأصلي يدعم فقط اتصالات نصية غير مشفرة وغير موثقة من نوع ASCII مكونة من 7 بتات، مما جعله عرضة لهجمات الوسيط البسيطة ، وانتحال الهوية ، وإرسال البريد العشوائي ، كما كان يتطلب تشفير أي بيانات ثنائية إلى نص قابل للقراءة قبل إرسالها. ونظرًا لغياب آلية مصادقة مناسبة، كان كل خادم SMTP، بحكم تصميمه، خادمًا مفتوحًا لإعادة توجيه البريد . أفاد اتحاد بريد الإنترنت (IMC) أن 55% من خوادم البريد كانت خوادم مفتوحة لإعادة التوجيه في عام 1998، [ 21 ] ولكن أقل من 1% في عام 2002. [ 22 ] وبسبب مخاوف البريد العشوائي، يقوم معظم مزودي خدمة البريد الإلكتروني بحظر الخوادم المفتوحة لإعادة التوجيه، [ 23 ] مما يجعل بروتوكول SMTP الأصلي غير عملي للاستخدام العام على الإنترنت.

بروتوكول SMTP الحديث

في نوفمبر 1995، حددت وثيقة RFC 1869 بروتوكول نقل البريد البسيط الموسع (ESMTP)، الذي وضع بنية عامة لجميع الامتدادات الحالية والمستقبلية التي تهدف إلى إضافة الميزات المفقودة من بروتوكول SMTP الأصلي. يحدد بروتوكول ESMTP وسائل متسقة وقابلة للإدارة يمكن من خلالها تحديد عملاء وخوادم ESMTP، كما يمكن للخوادم الإشارة إلى الامتدادات المدعومة. 

تم تقديم بروتوكول إرسال الرسائل ( RFC 2476 ) وبروتوكول SMTP-AUTH ( RFC 2554 ) في عامي 1998 و1999، وكلاهما يصفان اتجاهات جديدة في توصيل البريد الإلكتروني. في البداية، كانت خوادم SMTP عادةً داخلية في المؤسسة، تستقبل البريد نيابةً عنها من الخارج ، وتعيد توجيه الرسائل من المؤسسة إلى الخارج . ولكن مع مرور الوقت، توسعت أدوار خوادم SMTP (وكلاء نقل البريد) عمليًا لتصبح وكلاء إرسال رسائل لوكلاء مستخدمي البريد ، الذين أصبح بعضهم يعيد توجيه البريد من خارج المؤسسة (على سبيل المثال، يرغب أحد المديرين التنفيذيين في إرسال بريد إلكتروني أثناء سفره باستخدام خادم SMTP الخاص بالشركة). هذه المشكلة، نتيجةً للتوسع السريع وانتشار شبكة الإنترنت العالمية ، استلزمت تضمين بروتوكول SMTP قواعد وأساليب محددة لإعادة توجيه البريد والتحقق من هوية المستخدمين لمنع إساءة الاستخدام، مثل إعادة توجيه البريد الإلكتروني غير المرغوب فيه ( البريد العشوائي ). بدأ العمل على آلية إرسال الرسائل ( RFC 2476 ) في الأصل لأن خوادم البريد الشائعة كانت غالبًا ما تعيد كتابة الرسائل في محاولة لإصلاح مشاكلها، كإضافة اسم نطاق إلى عنوان غير مؤهل. يُعد هذا السلوك مفيدًا عندما تكون الرسالة المراد إصلاحها هي الرسالة المرسلة لأول مرة، ولكنه خطير وضار عندما تكون الرسالة من مصدر آخر ويتم إعادة توجيهها. وقد اعتُبر الفصل التام بين إرسال الرسائل وإعادة توجيهها وسيلةً للسماح بإعادة كتابة الرسائل المرسلة وتشجيعها، مع منع إعادة كتابة الرسائل المعاد توجيهها. ومع ازدياد انتشار البريد العشوائي، اعتُبر هذا الفصل أيضًا وسيلةً لتوفير التفويض للرسائل المرسلة من المؤسسة، بالإضافة إلى إمكانية تتبعها. وسرعان ما أصبح هذا الفصل بين إعادة التوجيه والإرسال أساسًا لممارسات أمن البريد الإلكتروني الحديثة.   

بما أن هذا البروتوكول بدأ قائمًا على نصوص ASCII فقط، لم يكن يتعامل بكفاءة مع الملفات الثنائية أو الأحرف في العديد من اللغات غير الإنجليزية. ولذلك، طُوّرت معايير مثل MIME (امتدادات البريد الإلكتروني متعددة الأغراض ) لترميز الملفات الثنائية لنقلها عبر SMTP. كما أن وكلاء نقل البريد (MTAs) الذين طُوّروا بعد Sendmail كانوا يميلون إلى استخدام ترميز 8 بت النظيف ، مما يسمح باستخدام استراتيجية "إرسال ثمانية بتات فقط" لنقل أي بيانات نصية (بأي ترميز أحرف شبيه بـ ASCII ذي 8 بتات) عبر SMTP. ومع ذلك، ظلت مشكلة Mojibake قائمة بسبب اختلاف مجموعات الأحرف بين الموردين، على الرغم من أن عناوين البريد الإلكتروني نفسها كانت لا تزال تسمح فقط باستخدام ASCII . أما اليوم، فتميل وكلاء نقل البريد (MTAs) ذات ترميز 8 بت النظيف إلى دعم امتداد 8BITMIME، مما يسمح بنقل بعض الملفات الثنائية بسهولة تكاد تضاهي سهولة نقل النصوص العادية (مع وجود قيود على طول السطر وقيم البايتات المسموح بها، مما يجعل ترميز MIME ضروريًا لمعظم البيانات غير النصية وبعض تنسيقات النصوص). في عام 2012، SMTPUTF8تم إنشاء الامتداد لدعم نص UTF-8 ، مما يسمح بالمحتوى الدولي والعناوين المكتوبة بأحرف غير لاتينية مثل السيريلية أو الصينية .

ساهم العديد من الأشخاص في وضع المواصفات الأساسية لبروتوكول SMTP، ومن بينهم جون بوستيل ، وإريك ألمان ، وديف كروكر، ونيد فريد ، وراندال جيلينز، وجون كلينسين ، وكيث مور .

نموذج معالجة البريد

تشير الأسهم الزرقاء إلى تطبيق اختلافات بروتوكول SMTP.

يُرسل البريد الإلكتروني من عميل البريد ( وكيل مستخدم البريد ، MUA) إلى خادم البريد ( وكيل إرسال البريد ، MSA) باستخدام بروتوكول SMTP على منفذ TCP رقم 465 أو 587. ولا تزال معظم شركات البريد الإلكتروني تسمح بالإرسال عبر المنفذ التقليدي 25. يقوم وكيل إرسال البريد (MSA) بتسليم البريد إلى وكيل نقل البريد (MTA). في كثير من الأحيان، يكون هذان الوكيلان نسختين من البرنامج نفسه، يتم تشغيلهما بخيارات مختلفة على الجهاز نفسه. يمكن إجراء المعالجة المحلية إما على جهاز واحد، أو توزيعها على عدة أجهزة؛ إذ يمكن لعمليات وكيل البريد على جهاز واحد مشاركة الملفات، ولكن في حال إجراء المعالجة على عدة أجهزة، فإنها تنقل الرسائل فيما بينها باستخدام بروتوكول SMTP، حيث يتم تكوين كل جهاز لاستخدام الجهاز التالي كمضيف ذكي . كل عملية هي وكيل نقل بريد (خادم SMTP) بحد ذاتها.

يستخدم خادم البريد الحدودي نظام أسماء النطاقات (DNS) للبحث عن سجل MX (خادم تبادل البريد) الخاص بنطاق المستلم (الجزء من عنوان البريد الإلكتروني على يمين @). يحتوي سجل MX على اسم خادم البريد المستهدف. بناءً على المضيف المستهدف وعوامل أخرى، يختار خادم البريد المرسل خادم المستلم ويتصل به لإتمام عملية تبادل البريد.

يمكن نقل الرسائل عبر اتصال واحد بين خادمَي نقل رسائل (MTA)، أو عبر سلسلة من المحطات الوسيطة. قد يكون خادم SMTP المُستقبِل هو الوجهة النهائية، أو مُرحِّلًا وسيطًا (أي أنه يخزن الرسالة ويُعيد توجيهها)، أو بوابة (أي أنه قد يُعيد توجيه الرسالة باستخدام بروتوكول آخر غير SMTP). وفقًا للقسم 2.1 من RFC 5321 ، تُمثل كل محطة وسيطة تسليمًا رسميًا لمسؤولية الرسالة، حيث يجب على الخادم المُستقبِل إما تسليم الرسالة أو الإبلاغ بشكل صحيح عن فشل ذلك. 

بمجرد أن يستقبل الخادم الأخير الرسالة الواردة، يُسلمها إلى وكيل تسليم البريد (MDA) لتسليمها محليًا. يقوم وكيل تسليم البريد بحفظ الرسائل بتنسيق صندوق البريد المناسب . وكما هو الحال مع الإرسال، يمكن إجراء هذا الاستقبال باستخدام جهاز كمبيوتر واحد أو عدة أجهزة، ولكن في الرسم التوضيحي أعلاه، يظهر وكيل تسليم البريد كصندوق واحد بجوار صندوق مُبادل البريد. قد يقوم وكيل تسليم البريد بتسليم الرسائل مباشرةً إلى وحدة التخزين، أو إعادة توجيهها عبر الشبكة باستخدام بروتوكول SMTP أو بروتوكول آخر مثل بروتوكول نقل البريد المحلي (LMTP)، وهو بروتوكول مشتق من SMTP مصمم لهذا الغرض.

بمجرد وصول البريد إلى خادم البريد المحلي، يُخزَّن لاسترجاعه دفعةً واحدةً بواسطة برامج البريد الإلكتروني المعتمدة. تسترجع تطبيقات المستخدم النهائي، المعروفة ببرامج البريد الإلكتروني، البريد باستخدام بروتوكول الوصول إلى رسائل الإنترنت (IMAP)، وهو بروتوكول يُسهِّل الوصول إلى البريد ويُدير البريد المُخزَّن، أو بروتوكول مكتب البريد (POP) الذي يستخدم عادةً تنسيق ملف البريد mbox التقليدي أو نظامًا خاصًا مثل Microsoft Exchange/Outlook أو Lotus Notes / Domino . قد تستخدم برامج البريد الإلكتروني عبر الويب أيًّا من الطريقتين، ولكن غالبًا ما لا يكون بروتوكول الاسترجاع معيارًا رسميًا.

يُحدد بروتوكول SMTP آلية نقل الرسائل ، وليس محتواها . فهو يُحدد غلاف البريد الإلكتروني ومعاييره، مثل مُرسِل الغلاف ، ولكنه لا يُحدد رأس الرسالة (باستثناء معلومات التتبع ) ولا نص الرسالة نفسه. يُحدد كل من معيار STD 10 و RFC 5321 بروتوكول SMTP (غلاف البريد الإلكتروني)، بينما يُحدد كل من معيار STD 11 و RFC 5322 الرسالة (رأس الرسالة ونصها)، والتي يُشار إليها رسميًا باسم تنسيق رسائل الإنترنت .  

نظرة عامة على البروتوكول

بروتوكول SMTP هو بروتوكول نصي موجه للاتصال ، حيث يتواصل مرسل البريد مع مستقبل البريد عبر إصدار سلاسل أوامر وتوفير البيانات اللازمة عبر قناة تدفق بيانات منظمة وموثوقة، وعادةً ما تكون اتصال بروتوكول التحكم بالنقل (TCP). تتكون جلسة SMTP من أوامر صادرة من عميل SMTP ( الوكيل المُبادر ، أو المُرسِل) وردود مقابلة من خادم SMTP (الوكيل المُستقبِل، أو المُستقبِل) لفتح الجلسة وتبادل معلمات الجلسة. قد تتضمن الجلسة صفرًا أو أكثر من معاملات SMTP. تتكون معاملة SMTP من ثلاث سلاسل أوامر/ردود:

  1. أمر MAIL ، لتحديد عنوان الإرجاع، ويسمى أيضًا مسار الإرجاع، [ 24 ] المسار العكسي، [ 25 ] عنوان الارتداد ، mfrom، أو مرسل المغلف.
  2. يُستخدم أمر RCPT لتحديد مُستلم الرسالة. يمكن إصدار هذا الأمر عدة مرات، مرة لكل مُستلم. وتُعدّ هذه العناوين جزءًا من مُغلِق الرسالة.
  3. يشير DATA إلى بداية نص الرسالة ؛ أي محتوى الرسالة، وليس غلافها. ويتكون من رأس الرسالة وجسمها ، يفصل بينهما سطر فارغ. في الواقع، DATA عبارة عن مجموعة من الأوامر، ويستجيب الخادم مرتين: الأولى على أمر DATA نفسه، للتأكيد على استعداده لاستقبال النص، والثانية بعد انتهاء تسلسل البيانات، إما لقبول الرسالة أو رفضها.

إلى جانب الرد الوسيط للبيانات، يمكن أن يكون رد كل خادم إيجابيًا (رموز الرد 2xx) أو سلبيًا. قد تكون الردود السلبية دائمة (رموز 5xx) أو مؤقتة (رموز 4xx). يُعد الرفض فشلًا دائمًا، ويتعين على العميل إرسال رسالة ارتداد إلى الخادم الذي استلمها منه. أما الإسقاط فهو رد إيجابي يتبعه تجاهل الرسالة بدلًا من تسليمها.

يمكن أن يكون المضيف المُرسِل، وهو عميل SMTP، إما برنامج بريد إلكتروني خاص بالمستخدم النهائي ، ويُعرف وظيفيًا باسم وكيل مستخدم البريد (MUA)، أو وكيل نقل البريد (MTA) الخاص بخادم الترحيل، وهو خادم SMTP يعمل كعميل SMTP في الجلسة المعنية، وذلك لإعادة توجيه البريد. تحتفظ خوادم SMTP كاملة الإمكانيات بقوائم انتظار للرسائل لإعادة محاولة إرسال الرسائل التي نتج عنها فشل مؤقت.

يتعرف برنامج البريد الإلكتروني (MUA) على خادم SMTP للبريد الصادر من خلال إعداداته. عادةً ما يحدد خادم الترحيل الخادم الذي سيتصل به من خلال البحث عن سجل MX (تبادل البريد) في نظام أسماء النطاقات (DNS ) لاسم نطاق كل مستلم . إذا لم يتم العثور على سجل MX، يقوم خادم الترحيل المتوافق (ليست جميعها متوافقة) بالبحث عن سجل A. يمكن أيضًا تهيئة خوادم الترحيل لاستخدام مضيف ذكي . يبدأ خادم الترحيل اتصال TCP بالخادم على المنفذ المعروف لبروتوكول SMTP: المنفذ 25، أو على المنفذ 465 أو 587 للاتصال بخادم خدمة البريد (MSA). الفرق الرئيسي بين خادم نقل البريد (MTA) وخادم خدمة البريد (MSA) هو أن الاتصال بخادم خدمة البريد يتطلب مصادقة SMTP .

SMTP مقابل استرجاع البريد

بروتوكول SMTP هو بروتوكول توصيل فقط. في الاستخدام العادي، تُرسل الرسائل إلى خادم البريد الوجهة (أو خادم البريد التالي) فور وصولها. ويتم توجيه الرسائل بناءً على خادم الوجهة، وليس على المستخدمين المُرسَل إليهم. أما البروتوكولات الأخرى، مثل بروتوكول مكتب البريد (POP) وبروتوكول الوصول إلى رسائل الإنترنت (IMAP)، فهي مُصممة خصيصًا لاستخدام المستخدمين الأفراد لاستلام الرسائل وإدارة صناديق البريد . وللسماح لخادم بريد متصل بشكل متقطع بسحب الرسائل من خادم بعيد عند الطلب، يحتوي SMTP على ميزة لبدء معالجة قائمة انتظار البريد على خادم بعيد (انظر بدء قائمة انتظار الرسائل عن بُعد أدناه). يُعدّ كل من POP وIMAP بروتوكولين غير مناسبين لإعادة توجيه البريد بواسطة الأجهزة المتصلة بشكل متقطع؛ فهما مُصممان للعمل بعد التسليم النهائي، عندما تُزال المعلومات الضرورية لتشغيل عملية إعادة توجيه البريد بشكل صحيح (أي "مغلف البريد").

بدء تشغيل قائمة انتظار الرسائل عن بُعد

يُمكّن بدء تشغيل قائمة انتظار الرسائل عن بُعد مضيفًا بعيدًا من بدء معالجة قائمة انتظار البريد على خادم، بحيث يمكنه استقبال الرسائل المُوجّهة إليه عن طريق إرسال أمر مُناسب. TURNاعتُبر الأمر الأصلي غير آمن، وتمّ توسيعه في RFC 1985 بأمر يعمل بشكل أكثر أمانًا باستخدام طريقة مصادقة تعتمد على معلومات نظام أسماء النطاقات (DNS) . [ 26 ] ETRN

خادم SMTP للبريد الصادر

يحتاج برنامج البريد الإلكتروني إلى معرفة عنوان IP لخادم SMTP الأولي، ويجب تحديد هذا العنوان ضمن إعداداته (عادةً ما يُحدد كاسم DNS ). يقوم هذا الخادم بتسليم الرسائل الصادرة نيابةً عن المستخدم.

قيود الوصول إلى خادم البريد الصادر

يحتاج مديرو الخوادم إلى فرض بعض الضوابط على العملاء المسموح لهم باستخدام الخادم. وهذا يمكّنهم من التعامل مع إساءة الاستخدام، مثل الرسائل المزعجة . وقد شاع استخدام حلّين:

  • في السابق، كانت العديد من الأنظمة تفرض قيودًا على الاستخدام بناءً على موقع العميل، حيث لا تسمح بالاستخدام إلا للعملاء الذين يقع عنوان IP الخاص بهم ضمن نطاق تحكم مسؤولي الخادم. ويُمنع الاستخدام من أي عنوان IP آخر.
  • توفر خوادم SMTP الحديثة عادةً نظامًا بديلاً يتطلب مصادقة العملاء بواسطة بيانات الاعتماد قبل السماح بالوصول.

تقييد الوصول حسب الموقع

في هذا النظام، لن يسمح خادم SMTP الخاص بمزود خدمة الإنترنت بالوصول للمستخدمين خارج شبكة مزود الخدمة. وبشكل أدق، قد يسمح الخادم بالوصول فقط للمستخدمين الذين لديهم عنوان IP مُقدم من مزود الخدمة، وهو ما يُعادل اشتراط اتصالهم بالإنترنت عبر نفس مزود الخدمة. قد يكون مستخدم الهاتف المحمول متصلاً بشبكة مختلفة عن شبكة مزود خدمة الإنترنت المعتاد، وبالتالي سيجد أن إرسال البريد الإلكتروني يفشل لأن خادم SMTP المُختار لم يعد متاحًا.

لهذا النظام عدة أشكال. على سبيل المثال، قد يقتصر خادم SMTP الخاص بالمؤسسة على تقديم الخدمة للمستخدمين على نفس الشبكة، مع فرض ذلك عبر جدار الحماية لمنع وصول المستخدمين من الإنترنت. أو قد يُجري الخادم فحوصات نطاق على عنوان IP الخاص بالعميل. كانت هذه الأساليب شائعة الاستخدام لدى الشركات والمؤسسات، مثل الجامعات، التي كانت توفر خادم SMTP للبريد الصادر للاستخدام الداخلي فقط. مع ذلك، تستخدم معظم هذه الجهات الآن أساليب مصادقة العميل، كما هو موضح أدناه.

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

مصادقة العميل

تتطلب خوادم SMTP الحديثة عادةً مصادقة العملاء باستخدام بيانات الاعتماد قبل السماح بالوصول، بدلاً من تقييد الوصول حسب الموقع كما ذُكر سابقًا. هذا النظام الأكثر مرونةً يُسهّل على مستخدمي الأجهزة المحمولة، ويُمكّنهم من اختيار خادم SMTP مُحدد مسبقًا. تُعدّ مصادقة SMTP ، والتي تُختصر غالبًا إلى SMTP AUTH، امتدادًا لبروتوكول SMTP لتسجيل الدخول باستخدام آلية مصادقة.

الموانئ

يستخدم الاتصال بين خوادم البريد بشكل عام منفذ TCP القياسي رقم 25 المخصص لبروتوكول SMTP.

لكن برامج البريد الإلكتروني لا تستخدم هذا عادةً، بل تستخدم منافذ "إرسال" محددة. تقبل خدمات البريد الإلكتروني عمومًا إرسال رسائل البريد الإلكتروني من العملاء عبر أحد المنافذ التالية:

  • 465 تم إيقاف استخدام هذا المنفذ بعد RFC 2487 ، حتى إصدار RFC 8314 .  
  • 587 (تقديم)، كما هو موضح في RFC 6409 (سابقًا RFC 2476 )  

قد يتم استخدام المنفذ 2525 وغيره من قبل بعض مزودي الخدمة الأفراد، ولكن لم يتم دعمها رسميًا أبدًا.

تقوم العديد من شركات تزويد خدمة الإنترنت الآن بحظر جميع حركة البيانات الصادرة عبر المنفذ 25 من عملائها. ويعود ذلك أساسًا إلى مكافحة البريد العشوائي، [ 27 ] وأيضًا لتعويض التكلفة المرتفعة التي تتكبدها عند تركه مفتوحًا.

مثال على نقل SMTP

يُعرض في تبادل الجلسة التالي مثال نموذجي لإرسال رسالة عبر بروتوكول SMTP إلى صندوقي بريد ( alice و theboss ) يقعان ضمن نفس نطاق البريد ( example.com ). (في هذا المثال، تُسبق أجزاء المحادثة بـ S: و C:، للدلالة على الخادم والعميل على التوالي ؛ وهذه التسميات ليست جزءًا من التبادل).

بعد أن يُنشئ مُرسِل الرسالة (عميل SMTP) قناة اتصال موثوقة مع مُستقبِل الرسالة (خادم SMTP)، يبدأ الخادم الجلسة برسالة ترحيب، تحتوي عادةً على اسم نطاقه المؤهل بالكامل (FQDN)، وفي هذه الحالة smtp.example.com . يبدأ العميل حواره بالرد بأمر HELOيُعرّف نفسه فيه باستخدام اسم نطاقه المؤهل بالكامل (أو عنوانًا حرفيًا إذا لم يكن هناك اسم نطاق مؤهل بالكامل). [ 28 ]

S: 220 smtp.example.com ESMTP Postfix C: HELO relay.example.org S: 250 مرحبًا relay.example.org، يسعدني لقاؤك C: MAIL FROM:<bob@example.org> S: 250 OK C: RCPT TO:<alice@example.com> S: 250 OK C: RCPT TO:<theboss@example.com> S: 250 OK C: DATA S: 354 End data with <CR><LF>.<CR><LF> C: C : C: C: C: C: C: مرحبًا أليس. C: هذه رسالة اختبار تحتوي على 5 حقول رأس و4 أسطر في نص الرسالة. C: صديقك، C: بوب C: . S: 250 OK: queued as 12345 C: QUIT S: 221 Bye {يغلق الخادم الاتصال}From:"BobExample"<bob@example.org>To:"AliceExample"<alice@example.com>Cc:theboss@example.comDate:Tue, 15 Jan 2008 16:02:43 -0500Subject:Testmessage

يُعلم العميل المُستلِم بعنوان البريد الإلكتروني الأصلي للرسالة في MAIL FROMأمرٍ ما. ويُستخدم هذا العنوان أيضًا كعنوان رد أو عنوان ارتداد في حال تعذّر تسليم الرسالة. في هذا المثال، تُرسَل رسالة البريد الإلكتروني إلى صندوقي بريد على خادم SMTP واحد: صندوق لكل مُستلِم مُدرج في حقلي رأس To:الرسالة Cc:. أمر SMTP المُناسب هو RCPT TO. يُؤكّد الخادم استلام وتنفيذ كل أمر بنجاح برمز نتيجة ورسالة استجابة (مثلاً، 250 Ok).

تبدأ عملية إرسال نص الرسالة الإلكترونية بأمر، DATAثم تُرسل الرسالة حرفيًا سطرًا سطرًا، وتنتهي بتسلسل بيانات. يتكون هذا التسلسل من سطر جديد ( )، ونقطة<CR><LF> واحدة ( )، متبوعة بسطر جديد آخر ( ). بما أن نص الرسالة قد يحتوي على سطر يتضمن نقطة فقط، يرسل العميل نقطتين في كل مرة يبدأ فيها السطر بنقطة؛ وبالمثل، يستبدل الخادم كل تسلسل من نقطتين في بداية السطر بنقطة واحدة. تُسمى هذه الطريقة " حشو النقاط" ..<CR><LF>

يشير رد الخادم الإيجابي على رسالة نهاية البيانات، كما هو موضح، إلى أن الخادم قد تولى مسؤولية إيصال الرسالة. يمكن مضاعفة الرسالة في حال حدوث عطل في الاتصال في هذه المرحلة، مثلاً بسبب انقطاع التيار الكهربائي: إلى أن يتلقى المرسل هذا 250 Okالرد، يجب عليه افتراض أن الرسالة لم تُسلّم. من جهة أخرى، بعد أن يقرر المُستقبِل قبول الرسالة، يجب عليه افتراض أنها قد سُلّمت إليه. بالتالي، خلال هذه الفترة الزمنية، يمتلك كلا الطرفين نسختين نشطتين من الرسالة سيحاولان إيصالها. [ 29 ] يتناسب احتمال حدوث عطل في الاتصال تحديداً في هذه المرحلة تناسباً طردياً مع مقدار التصفية التي يُجريها الخادم على محتوى الرسالة، وغالباً ما يكون ذلك لأغراض مكافحة البريد العشوائي. تم تحديد مهلة زمنية قصوى تبلغ 10 دقائق. [ 30 ]

يُنهي هذا QUITالأمر الجلسة. إذا كان للبريد الإلكتروني مُستلمون آخرون في مواقع أخرى، فسيتصل العميل QUITبخادم SMTP مناسب للمُستلمين اللاحقين بعد وضع الوجهة (الوجهات) الحالية في قائمة الانتظار. تُضاف المعلومات التي يُرسلها العميل في الأمرَين HELO( MAIL FROMغير الموضحة في مثال التعليمات البرمجية) كحقول رأس إضافية إلى الرسالة بواسطة الخادم المُستقبِل. ويُضيف Receivedحقلَي Return-Pathرأس، على التوالي.

بعض البرامج مصممة لإغلاق الاتصال بعد قبول الرسالة 250 Ok: queued as 12345، لذا قد يتم حذف السطرين الأخيرين. هذا يُسبب خطأً على الخادم عند محاولة إرسال 221 Byeالرد.

ملحقات SMTP

آلية اكتشاف الامتدادات

يتعرف العملاء على الخيارات المدعومة من الخادم باستخدام EHLOرسالة الترحيب، كما هو موضح أدناه، بدلاً من الرسالة الأصلية HELO. ويلجأ العملاء إلى الرسالة الأصلية HELOفقط في حال عدم دعم الخادم EHLOلرسالة الترحيب. [ 31 ]

قد تستخدم البرامج الحديثة كلمة ESMTP الإضافية SIZEللاستعلام من الخادم عن الحد الأقصى لحجم الرسالة المقبولة. أما البرامج والخوادم القديمة فقد تحاول نقل رسائل ذات أحجام كبيرة جدًا، مما يؤدي إلى رفضها بعد استهلاك موارد الشبكة، بما في ذلك وقت الاتصال بروابط الشبكة الذي يُدفع ثمنه بالدقيقة. [ 32 ]

يمكن للمستخدمين تحديد الحد الأقصى لحجم الملفات التي تقبلها خوادم ESMTP يدويًا مسبقًا. يقوم العميل باستبدال HELOالأمر بالأمر EHLO.

S: 220 smtp2.example.com ESMTP Postfix C: EHLO bob.example.org S: 250-smtp2.example.com Hello bob.example.org [192.0.2.201] S: 250-SIZE 14680064 S: 250-PIPELINING S: 250 HELP

وبالتالي فإن smtp2.example.com يعلن أنه يمكنه قبول حجم رسالة أقصى ثابت لا يزيد عن 14,680,064 بايت (8 بت).

في أبسط الحالات، يُعلن خادم ESMTP عن حد أقصى SIZEفور استلامه رسالة EHLO. مع ذلك، ووفقًا لـ RFC 1870 ، فإن المعامل العددي للامتداد في الاستجابة اختياري. بدلًا من ذلك، يمكن للعملاء، عند إصدار أمر، تضمين تقدير عددي لحجم الرسالة التي ينقلونها، بحيث يتمكن الخادم من رفض استلام الرسائل ذات الأحجام الكبيرة جدًا. SIZEEHLOMAIL FROM

نقل البيانات الثنائية

يدعم بروتوكول SMTP الأصلي نصًا واحدًا فقط من نوع ASCII، لذا يجب ترميز أي بيانات ثنائية كنص في هذا النص قبل الإرسال، ثم فك ترميزها من قِبل المُستلِم. وكانت تُستخدم عادةً ترميزات تحويل البيانات الثنائية إلى نص ، مثل uuencode و BinHex .

تم تطوير أمر 8BITMIME لمعالجة هذه المشكلة. وقد تم توحيده في عام 1994 تحت مسمى RFC 1652 [ 33 ]. وهو يسهل التبادل الشفاف لرسائل البريد الإلكتروني التي تحتوي على وحدات ثمانية بت خارج مجموعة أحرف ASCII ذات السبعة بتات عن طريق ترميزها كأجزاء محتوى MIME ، والتي يتم ترميزها عادةً باستخدام Base64 . 

خدمة إعادة توجيه البريد عند الطلب

ترحيل البريد عند الطلب ( ODMR ) هو امتداد SMTP موحد في RFC 2645 يسمح لخادم SMTP المتصل بشكل متقطع باستقبال البريد الإلكتروني الموجود في قائمة الانتظار الخاصة به عندما يكون متصلاً. 

توسيع نطاق التدويل

يدعم بروتوكول SMTP الأصلي عناوين البريد الإلكتروني المكونة من أحرف ASCII فقط، وهو ما يمثل عائقًا للمستخدمين الذين لا تعتمد لغتهم الأم على اللاتينية، أو الذين يستخدمون علامات تشكيل غير موجودة في مجموعة أحرف ASCII. وقد تم التغلب على هذا القيد من خلال إضافات تُمكّن استخدام UTF-8 في أسماء العناوين. قدّم RFC 5336 أمرًا تجريبيًا [ 32 ] ، ثم استُبدل لاحقًا بـ RFC 6531 الذي قدّم أمرًا آخر. توفر هذه الإضافات دعمًا للأحرف متعددة البايتات والأحرف غير ASCII في عناوين البريد الإلكتروني، مثل تلك التي تحتوي على علامات تشكيل وأحرف لغات أخرى كاليونانية والصينية . [ 34 ] UTF8SMTP SMTPUTF8

الدعم الحالي محدود، ولكن هناك اهتمام قوي بالتبني الواسع لـ RFC 6531 و RFCs ذات الصلة في دول مثل الصين التي لديها قاعدة مستخدمين كبيرة حيث تعتبر اللاتينية (ASCII) نصًا أجنبيًا. 

الإضافات

مثل بروتوكول SMTP، يُعدّ ESMTP بروتوكولاً يُستخدم لنقل البريد الإلكتروني عبر الإنترنت. ويُستخدم كبروتوكول نقل بين الخوادم، وكبروتوكول لإرسال البريد (مع فرض قيود على السلوك).

تتمثل الميزة الرئيسية لتعريف عملاء ESMTP في بدء الإرسال باستخدام الأمر EHLO(Extended HELLO)، بدلاً من HELO(Hello، وهو المعيار الأصلي RFC 821 ). سيرد الخادم بنجاح (الرمز 250)، أو فشل (الرمز 550)، أو خطأ (الرمز 500، أو 501، أو 502، أو 504، أو 421)، وذلك حسب إعداداته. يُعيد خادم ESMTP الرمز 250 OK في رد متعدد الأسطر يتضمن نطاقه وقائمة بالكلمات المفتاحية للإشارة إلى الامتدادات المدعومة. يُعيد الخادم المتوافق مع RFC 821 رمز الخطأ 500، مما يسمح لعملاء ESMTP بتجربة أي من الخيارين . HELOQUIT

يُعرَّف كل امتداد خدمة بتنسيق معتمد في وثائق RFC اللاحقة، ويُسجَّل لدى هيئة الأرقام المخصصة للإنترنت (IANA). كانت التعريفات الأولى هي خدمات RFC 821 الاختيارية: SEND( SOMLإرسال أو بريد)، SAML(إرسال وبريد)، EXPNو HELP. TURNوتم تحديد تنسيق أفعال SMTP الإضافية، بالإضافة إلى معلمات جديدة في MAILو RCPT.

بعض الكلمات المفتاحية الشائعة نسبياً (ليست جميعها مطابقة للأوامر) المستخدمة اليوم هي:

تمت إعادة صياغة تنسيق ESMTP في RFC 2821 (الذي حل محل RFC 821) وتم تحديثه إلى أحدث تعريف في RFC 5321 في عام 2008. أصبح دعم الأمر في الخوادم إلزاميًا، وتم تحديده كخيار احتياطي مطلوب.  EHLOHELO

يمكن استخدام امتدادات الخدمة غير القياسية وغير المسجلة بموجب اتفاق ثنائي، ويتم الإشارة إلى هذه الخدمات بواسطة EHLOكلمة رئيسية للرسالة تبدأ بـ "X"، مع أي معلمات أو أفعال إضافية مميزة بشكل مماثل.

أوامر بروتوكول SMTP غير حساسة لحالة الأحرف. وقد عُرضت هنا بأحرف كبيرة للتأكيد فقط. يُعدّ خادم SMTP الذي يتطلب طريقة كتابة محددة للأحرف الكبيرة مخالفة للمعيار. [ 28 ]

8BITMIME

تُعلن الخوادم التالية على الأقل عن امتداد 8BITMIME:

يمكن تهيئة الخوادم التالية للإعلان عن 8BITMIME، ولكنها لا تقوم بتحويل البيانات ذات 8 بت إلى 7 بت عند الاتصال بخوادم إعادة توجيه غير 8BITMIME:

  • لا يقوم برنامجا Exim و qmail بترجمة الرسائل ذات 8 بت إلى 7 بت عند محاولة إعادة توجيه بيانات 8 بت إلى نظراء لا يستخدمون بروتوكول 8BITMIME، كما هو مطلوب في RFC. [ 38 ] لا يسبب هذا مشاكل عملية، لأن جميع برامج إعادة توجيه البريد الحديثة تقريبًا تستخدم بيانات 8 بت نظيفة . [ 39 ]
  • يُعلن خادم مايكروسوفت إكستشينج 2003 عن استخدام بروتوكول 8BITMIME افتراضيًا، ولكن إعادة التوجيه إلى نظير لا يستخدم هذا البروتوكول تؤدي إلى ارتداد. هذا مسموح به بموجب RFC 6152. [ 40 ] 

SMTP-AUTH

يوفر ملحق SMTP-AUTH آلية للتحكم في الوصول. ويتألف من خطوة مصادقة يقوم العميل من خلالها بتسجيل الدخول إلى خادم البريد أثناء عملية إرسال البريد. ويمكن عادةً تهيئة الخوادم التي تدعم SMTP-AUTH لإلزام العملاء باستخدام هذا الملحق، مما يضمن معرفة هوية المرسل الحقيقية. وقد تم تعريف ملحق SMTP-AUTH في RFC 4954 . 

يمكن استخدام SMTP-AUTH للسماح للمستخدمين المصرح لهم بإعادة توجيه البريد مع منع خدمة إعادة التوجيه للمستخدمين غير المصرح لهم، مثل مرسلي البريد العشوائي . ولا يضمن هذا بالضرورة صحة مُرسِل مغلف SMTP أو رأس "From:" في RFC 2822. على سبيل المثال، يظل انتحال الهوية ، حيث ينتحل مُرسِل هوية شخص آخر، ممكنًا مع SMTP-AUTH ما لم يتم تكوين الخادم لتقييد عناوين "من" الرسائل بالعناوين المصرح بها لهذا المستخدم المُصرَّح له. 

يُتيح امتداد SMTP-AUTH أيضًا لخادم بريد إلكتروني إبلاغ خادم آخر بأن المُرسِل قد تم التحقق من هويته عند إعادة توجيه البريد. ويتطلب هذا عمومًا أن يثق خادم المُستقبِل بخادم المُرسِل، مما يعني أن هذا الجانب من SMTP-AUTH نادر الاستخدام على الإنترنت. [ 41 ]

SMTPUTF8

تشمل الخوادم الداعمة ما يلي:

ملحقات الأمان

يمكن أن يتم تسليم البريد عبر كل من النصوص العادية والاتصالات المشفرة، ومع ذلك قد لا تعرف الأطراف المتصلة مسبقًا قدرة الطرف الآخر على استخدام قناة آمنة.

STARTTLS أو "بروتوكول أمان طبقة النقل الانتهازي"

تُمكّن امتدادات STARTTLS خوادم SMTP الداعمة من إخطار العملاء المتصلين بدعمها للاتصال المشفر بتقنية TLS ، وتتيح للعملاء فرصة ترقية اتصالهم عبر إرسال أمر STARTTLS. ولا تُحقق الخوادم التي تدعم هذه الامتدادات أي فوائد أمنية تلقائية من تطبيقها، إذ أن الترقية إلى جلسة مشفرة بتقنية TLS تعتمد على قرار العميل المتصل بتفعيل هذا الخيار، ومن هنا جاء مصطلح TLS الانتهازي .

لا يكون بروتوكول STARTTLS فعالاً إلا ضد هجمات المراقبة السلبية، إذ تتم عملية التفاوض عليه كنص عادي، ويمكن للمهاجم النشط إزالة أوامر STARTTLS بسهولة. يُشار أحيانًا إلى هذا النوع من هجمات الوسيط باسم STRIPTLS ، حيث لا تصل معلومات التفاوض على التشفير المرسلة من أحد الطرفين إلى الطرف الآخر. في هذه الحالة، يعتبر كلا الطرفين الاستجابات غير الصالحة أو غير المتوقعة مؤشرًا على أن الطرف الآخر لا يدعم STARTTLS بشكل صحيح، فيلجأ إلى نقل البريد التقليدي كنص عادي. [ 50 ] تجدر الإشارة إلى أن STARTTLS مُعرّف أيضًا لبروتوكولي IMAP و POP3 في وثائق RFC أخرى، لكن هذه البروتوكولات تخدم أغراضًا مختلفة: يُستخدم SMTP للتواصل بين وكلاء نقل الرسائل، بينما يُستخدم IMAP وPOP3 للتواصل بين العملاء النهائيين ووكلاء نقل الرسائل.

في عام 2014، أطلقت مؤسسة الحدود الإلكترونية مشروع "STARTTLS Everywhere" الذي، على غرار قائمة " HTTPS Everywhere "، مكّن الأطراف المعتمدة من اكتشاف جهات أخرى تدعم الاتصالات الآمنة دون الحاجة إلى التواصل المسبق. توقف المشروع عن قبول المشاركات في 29 أبريل 2021، وأوصت المؤسسة بالتحول إلى DANE وMTA-STS لاكتشاف معلومات حول دعم النظراء لبروتوكول TLS. [ 51 ]

أعلن RFC 8314 رسميًا أن النص العادي قديم ويوصي دائمًا باستخدام TLS لإرسال البريد والوصول إليه، وإضافة المنافذ مع TLS الضمني. 

DANE لـ SMTP

أتاح RFC 7672 إمكانية استخدام سجلات نظام أسماء النطاقات (DNS) لتحديد قدرات التشفير لخادم البريد. وباستخدام DNSSEC ، يستطيع مشغلو خوادم البريد نشر تجزئة لشهادة TLS الخاصة بهم، مما يقلل من احتمالية الاتصالات غير المشفرة. [ 52 ] 

تتوقع مايكروسوفت تمكين دعم SMTP DANE الكامل لعملاء Exchange Online بحلول نهاية عام 2024. [ 53 ]

بروتوكول SMTP، هيئة النقل الحضري (MTA) - إجراءات أمنية مشددة للنقل

يهدف معيار RFC 8461 الأحدث لعام 2018 ، والمعروف باسم "أمان النقل الصارم لخادم SMTP (MTA-STS)"، إلى معالجة مشكلة الخصوم النشطين من خلال تحديد بروتوكول لخوادم البريد الإلكتروني لإعلان قدرتها على استخدام قنوات آمنة في ملفات محددة على الخادم وسجلات DNS TXT محددة. يقوم الطرف المعتمد بالتحقق بانتظام من وجود هذا السجل، وتخزينه مؤقتًا للمدة الزمنية المحددة فيه، ولا يتصل أبدًا عبر قنوات غير آمنة حتى انتهاء صلاحية السجل. [ 50 ] تجدر الإشارة إلى أن سجلات MTA-STS تنطبق فقط على حركة مرور SMTP بين خوادم البريد، بينما تتم حماية الاتصالات بين عميل المستخدم وخادم البريد بواسطة أمان طبقة النقل ( TLS) باستخدام SMTP/MSA أو IMAP أو POP3 أو HTTPS، بالإضافة إلى سياسة تنظيمية أو تقنية. باختصار، يُعد MTA-STS وسيلة لتوسيع نطاق هذه السياسة لتشمل أطرافًا ثالثة. 

في أبريل 2019، أعلنت خدمة البريد الإلكتروني من جوجل عن دعمها لبروتوكول MTA-STS. [ 54 ]

تقارير SMTP TLS

قد تفشل البروتوكولات المصممة لتوصيل الرسائل بشكل آمن نتيجةً لأخطاء في التكوين أو تدخل متعمد، مما يؤدي إلى عدم وصول الرسائل أو وصولها عبر قنوات غير مشفرة أو غير موثقة. يصف RFC 8460 "تقارير SMTP TLS" آليةً وتنسيقًا للإبلاغ عن حالات الفشل المحتملة ومشاركتها مع نطاقات المستلمين، وذلك لمشاركة الإحصائيات والمعلومات المحددة حول هذه الحالات. وبذلك، تستطيع نطاقات المستلمين استخدام هذه المعلومات للكشف عن الهجمات المحتملة وتشخيص أخطاء التكوين غير المقصودة. 

في أبريل 2019، أعلنت خدمة Gmail عن دعمها لتقارير SMTP TLS. [ 54 ]

انتحال الهوية وإرسال الرسائل المزعجة

لم يكن التصميم الأصلي لبروتوكول SMTP يحتوي على آلية للتحقق من هوية المرسلين، أو التحقق من أن الخوادم مخولة بالإرسال نيابة عنهم، مما أدى إلى إمكانية انتحال البريد الإلكتروني ، وهو أمر شائع الاستخدام في البريد العشوائي والتصيد الاحتيالي .

تُطرح بين الحين والآخر مقترحات لتعديل بروتوكول SMTP بشكل جذري أو استبداله بالكامل. ومن الأمثلة على ذلك برنامج Internet Mail 2000 ، إلا أنه لم يحقق، ولا أي برنامج آخر، تقدماً يُذكر في مواجهة الانتشار الواسع لبروتوكول SMTP الكلاسيكي.

بدلاً من ذلك، تستخدم خوادم البريد الآن مجموعة من التقنيات، مثل تطبيق أكثر صرامة للمعايير مثل RFC 5322 ، [ 55 ] [ 56 ] وDomainKeys Identified Mail ، و Sender Policy Framework ، و DMARC ، و DNSBLs، والقوائم الرمادية لرفض أو عزل رسائل البريد الإلكتروني المشبوهة. [ 57 ] 

التطبيقات

انظر أيضاً

ملحوظات

  1. ↑ تاريخ البريد الإلكتروني، مؤرشف في 2 ديسمبر 2017، على موقع Wayback Machine ، توم فان فليك : " ليس من الواضح ما إذا كان هذا البروتوكول قد تم تنفيذه على الإطلاق "
  2. ↑ البريد الإلكتروني الأول للشبكة ، راي توملينسون ، بي بي إن
  3. ↑ صورة لـ " أول حاسوب بريد إلكتروني " من تصميم دان مورفي، وهو جهاز PDP-10
  4. ↑ أوراق دان مورفي حول TENEX وTOPS-20، مؤرشفة في 18 نوفمبر 2007، على موقع Wayback Machine
  5. ↑ RFC 524 – بروتوكول بريد مقترح 
  6. ↑ كروكر، ديفيد هـ. (ديسمبر 1977). "إطار عمل ووظائف نظام الرسائل الشخصية "MS"" (ملف PDF) . مؤسسة راند . مؤرشف (ملف PDF) من الأصل في 13 مايو 2022. تم الاطلاع عليه في 17 أبريل 2022 .
  7. ↑ RFC 469 – ملخص اجتماع البريد الشبكي 
  8. ↑ RFC 733، 21 نوفمبر 1977، معيار تنسيق رسائل نصية لشبكة ARPA
  9. ↑ "تاريخ البريد الإلكتروني: التعاون والابتكار ونشأة النظام" . صحيفة واشنطن بوست . 20 مايو 2023. الرقم الدولي الموحد للدوريات 0190-8286 . تاريخ الاطلاع: 7 يوليو 2024 . 
  10. ↑ ماكنزي، ألكسندر (2011). "مجموعة عمل الإنترنت الدولية ومفهوم الإنترنت: رواية شاهد عيان". حوليات معهد مهندسي الكهرباء والإلكترونيات لتاريخ الحوسبة . 33 (1): 66-71 . رمز Bibcode : 2011IAHC...33a..66M . doi : 10.1109/MAHC.2011.9 . ISSN 1934-1547 . S2CID 206443072 .  
  11. ↑ باربر، د.، وج. لوز، "مخطط بريد أساسي لرقم تعريف صاحب العمل"، INWG 192، فبراير 1979.
  12. ↑ IEN 85 . IETF .
  13. ↑ IEN 113 . IETF .
  14. ↑ "فهرس ملاحظات تجارب الإنترنت" . www.rfc-editor.org . تم الاطلاع عليه في 7 يوليو 2024 .
  15. 1 2 بوستل، ج. (أغسطس 1982). بروتوكول نقل البريد البسيط (تقرير). محرر RFC. doi : 10.17487/rfc0821 .
  16. ↑ "Tldp.org" . مؤرشف من الأصل في 17 أغسطس 2007. تم الاطلاع عليه في 25 أغسطس 2007 .
  17. ↑ باربر، ستان أو. (19 ديسمبر 2000). "مسودة باربر - خاتمة مشروع رسم خرائط UUCP - 05 - خاتمة مشروع رسم خرائط UUCP" . مؤرشف من الأصل في 13 أكتوبر 2007. تم الاطلاع عليه في 25 أغسطس 2007 .
  18. ↑ تحتوي المقالة المتعلقة بإعادة كتابة المرسل على معلومات أساسية تقنية حول تاريخ SMTP المبكر وتوجيه المصدر قبل RFC 1123 . 
  19. ↑ إريك ألمان (1983)، Sendmail - موجه بريد للشبكات (PDF) ، مجموعة وثائق BSD UNIX، بيركلي: جامعة كاليفورنيا، مؤرشف (PDF) من الأصل في 20 مايو 2013 ، تم استرجاعه في 29 يونيو 2012
  20. ↑ كريج بارتريدج (2008)، التطور التقني للبريد الإلكتروني عبر الإنترنت (ملف PDF) ، حوليات IEEE لتاريخ الحوسبة، المجلد 30، جمعية IEEE للحاسبات، الصفحات 3-29 ، Bibcode : 2008IAHC...30b...3P ، doi : 10.1109/MAHC.2008.32 ، S2CID 206442868 ، مؤرشف من النسخة الأصلية (ملف PDF) في 12 مايو 2011   
  21. ↑ بول هوفمان (1 فبراير 1998). "السماح بإعادة التوجيه في بروتوكول SMTP: دراسة استقصائية" . اتحاد بريد الإنترنت . مؤرشف من الأصل في 5 مارس 2016. تم الاطلاع عليه في 30 مايو 2010 .
  22. ↑ بول هوفمان (أغسطس 2002). "السماح بإعادة التوجيه في بروتوكول SMTP: سلسلة من الدراسات الاستقصائية" . اتحاد بريد الإنترنت . مؤرشف من الأصل في 18 يناير 2007. تم الاطلاع عليه في 30 مايو 2010 .
  23. ↑ "في نظام يونكس، ما هو خادم البريد المفتوح؟ - قاعدة المعرفة" . ١٧ يونيو ٢٠٠٧. مؤرشف من الأصل في ١٧ يونيو ٢٠٠٧. تم الاطلاع عليه في ١٥ مارس ٢٠٢١ .
  24. ↑ "أفعال البريد، والمراسلة، والبيانات" مؤرشفة في 22 فبراير 2014، في آلة Wayback Machine ، [دي جي بيرنشتاين]
  25. ↑ RFC 5321 القسم 7.2 
  26. ↑ أنظمة الرسائل. "أنظمة الرسائل تُطلق أحدث إصدار من Momentum بإمكانيات جديدة تعتمد على واجهة برمجة التطبيقات" . www.prnewswire.com (بيان صحفي). مؤرشف من الأصل بتاريخ 19 يوليو 2020. تم الاطلاع عليه بتاريخ 19 يوليو 2020 .
  27. ↑ كارا غاريتسون (2005). "مزودو خدمة الإنترنت يساهمون في وقف البريد العشوائي" . بي سي وورلد . مؤرشف من الأصل في 28 أغسطس 2015. تم الاطلاع عليه في 18 يناير 2016. في الشهر الماضي، أصدر التحالف التقني لمكافحة البريد العشوائي، الذي تم تشكيله العام الماضي من قبل ياهو، وأمريكا أونلاين، وإيرث لينك، ومايكروسوفت، قائمة بتوصيات مكافحة البريد العشوائي تتضمن تصفية المنفذ 25.
  28. 1 2 ج. كلينسين (أكتوبر 2008). بروتوكول نقل البريد البسيط . مجموعة عمل شبكة IETF . doi : 10.17487/RFC5321 . RFC 5321 .مسودة معيار. تم تحديثها بواسطة RFC 7504. تلغي RFC 2821. تُحدّث RFC 1123 .   
  29. ↑ RFC 1047 
  30. ↑ كلينسين، جون سي. (أكتوبر 2008). "إنهاء البيانات: 10 دقائق" . بروتوكول نقل البريد البسيط . IETF . القسم 4.5.3.2.6. doi : 10.17487/RFC5321 . RFC 5321. تم الاطلاع عليه في 7 يونيو 2010 . 
  31. ↑ جون كلينسين؛ نيد فريد؛ مارشال تي. روز؛ إينار أ. ستيفيرود؛ ديف كروكر (نوفمبر 1995). ملحقات خدمة SMTP . IETF . doi : 10.17487/RFC1869 . RFC 1869 .
  32. 1 2 "معلمات البريد" . هيئة الأرقام المخصصة للإنترنت (IANA). 14 فبراير 2020. مؤرشف من الأصل في 28 مايو 2019. تم الاطلاع عليه في 28 مايو 2019 .
  33. ↑ والذي تم إلغاؤه في عام 2011 بموجب RFC 6152 الذي يتوافق مع STD 71الجديد آنذاك 
  34. ↑ جيانكانغ ياو (19 ديسمبر 2014). "عنوان البريد الإلكتروني الصيني" . EAI (قائمة بريدية). IETF . مؤرشف من الأصل في 2 أكتوبر 2015. تم الاطلاع عليه في 24 مايو 2016 .
  35. ↑ "معلمات امتداد خدمة SMTP" . هيئة IANA. مؤرشف من الأصل في 28 مايو 2019. تم الاطلاع عليه في 5 نوفمبر 2013 .
  36. ↑ خادم جيمس - سجل التغييرات مؤرشف في 20 فبراير 2020، على موقع Wayback Machine . James.apache.org. تم الاطلاع عليه في 17 يوليو 2013.
  37. ↑ تم الإعلان عن خدمة 8BITMIME استجابةً لطلب EHLO على gmail-smtp-in.l.google.com المنفذ 25، تم التحقق من ذلك في 23 نوفمبر 2011
  38. ↑ أخطاء وقائمة أمنيات Qmail . Home.pages.de. تم الاطلاع عليه بتاريخ 17-07-2013.
  39. ↑ امتداد 8BITMIME. مؤرشف في 7 يونيو 2011 على موقع Wayback Machine . Cr.yp.to. تم ​​الاطلاع عليه في 17 يوليو 2013.
  40. ↑ "امتداد خدمة نقل MIME ذي 8 بت" . امتداد خدمة SMTP لنقل MIME ذي 8 بت . IETF . مارس 2011. القسم 3. doi : 10.17487/RFC6152 . RFC 6152 . 
  41. ↑ هازل، فيليب (2007). خادم بريد Exim SMTP ( الطبعة الثانية). كامبريدج: UIT Cambridge. ص 418. ISBN   978-0-9544529-7-5.{{cite book}}: تحقق من |isbn=القيمة: المجموع الاختباري ( مساعدة )
  42. ↑ " دعم Postfix SMTPUTF8 مُفعّل افتراضيًا " مؤرشف في 7 أغسطس 2020 على Wayback Machine ، 8 فبراير 2015، postfix.org
  43. ↑ "أنظمة الرسائل تُطلق أحدث إصدار من Momentum مع إمكانيات جديدة تعتمد على واجهة برمجة التطبيقات" (بيان صحفي). مؤرشف من الأصل بتاريخ 15 سبتمبر 2020. تم الاطلاع عليه بتاريخ 17 سبتمبر 2020 .
  44. ↑ "سجل مراجعات الإصدار 6.2" . CommuniGate.com . مؤرشف من الأصل بتاريخ 29 أكتوبر 2020. تم الاطلاع عليه بتاريخ 17 سبتمبر 2020 .
  45. ↑ سام فارشافشيك (18 سبتمبر 2018). "إصدارات جديدة من طرود البريد السريع" . courier-announce (قائمة بريدية). مؤرشف من الأصل في 17 أغسطس 2021. تم الاطلاع عليه في 17 سبتمبر 2020 .
  46. ↑ "سجل تغييرات Halon MTA" . GitHub . 9 نوفمبر 2021. مؤرشف من الأصل في 18 سبتمبر 2020. تم الاسترجاع في 17 سبتمبر 2020. الإصدار 4.0: دعم جديد لـ SMTPUTF8تم التحديث للإصدارات الجديدة
  47. ↑ "MS-OXSMTP: امتدادات بروتوكول نقل البريد البسيط (SMTP)" . 24 يوليو 2018. مؤرشف من الأصل في 16 أغسطس 2021. تم الاطلاع عليه في 17 سبتمبر 2020 .
  48. ↑ "جاهزية تكامل تطبيقات المؤسسات في نطاقات المستوى الأعلى" (ملف PDF) . 12 فبراير 2019. مؤرشف (ملف PDF) من الأصل في 24 يناير 2021. تم الاطلاع عليه في 17 سبتمبر 2020 .
  49. ↑ "ملاحظات إصدار خادم مراسلة الاتصالات" . oracle.com . أكتوبر 2017. مؤرشف من الأصل في 24 نوفمبر 2020. تم الاطلاع عليه في 17 سبتمبر 2020 .
  50. ١ ٢ "تقديم نظام أمن النقل الصارم التابع لهيئة النقل الحضري (MTA-STS) | مدونة هاردنيز" . www.hardenize.com . مؤرشف من الأصل بتاريخ ٢٥ أبريل ٢٠١٩. تم الاطلاع عليه بتاريخ ٢٥ أبريل ٢٠١٩ .
  51. ↑ "STARTTLS Everywhere" . مؤسسة EFF. مؤرشف من الأصل في 9 أغسطس 2019. تم الاطلاع عليه في 4 ديسمبر 2021 .
  52. ↑ v-mathavale (21 يوليو 2023). "كيف يؤمّن بروتوكول SMTP القائم على نظام أسماء النطاقات (DANE) اتصالات البريد الإلكتروني" . learn.microsoft.com . تم الاطلاع عليه في 5 مارس 2024 .
  53. ↑ "تنفيذ بروتوكول SMTP DANE الوارد مع DNSSEC لتدفق البريد في Exchange Online" . techcommunity.microsoft.com . تم الاطلاع عليه في 5 مارس 2024 .
  54. 1 2 سيمبانو، كاتالين. "جيميل تصبح أول مزود بريد إلكتروني رئيسي يدعم MTA-STS وتقارير TLS" . ZDNet . مؤرشف من الأصل في 29 أبريل 2019. تم الاطلاع عليه في 25 أبريل 2019 .
  55. ↑ "الرسالة غير متوافقة مع RFC 5322" . مؤرشفة من الأصل بتاريخ 17 يناير 2023. تم الاطلاع عليها بتاريخ 20 يناير 2021 .
  56. ↑ "تعذر تسليم الرسالة. يُرجى التأكد من توافق الرسالة مع معيار RFC 5322" . مؤرشف من الأصل بتاريخ 28 يناير 2021. تم الاطلاع عليه بتاريخ 20 يناير 2021 .
  57. ↑ "لماذا تُرفض رسائل البريد الإلكتروني المرسلة إلى حساب مايكروسوفت لأسباب تتعلق بالسياسة؟" . مؤرشف من الأصل بتاريخ 14 فبراير 2021. تم الاطلاع عليه بتاريخ 20 يناير 2021 .

مراجع

  • هيوز، ل. (1998). البريد الإلكتروني عبر الإنترنت: البروتوكولات والمعايير والتنفيذ . دار نشر أرتيك هاوس. رقم ISBN 978-0-89006-939-4.
  • هانت، سي (2003). كتاب طبخ سندميل . دار نشر أورايلي. رقم ISBN 978-0-596-00471-2.
  • جونسون، ك. (2000). بروتوكولات البريد الإلكتروني عبر الإنترنت: دليل للمطورين . أديسون-ويسلي بروفيشنال. ISBN 978-0-201-43288-6.
  • لوشين، ب. (1999). معايير البريد الإلكتروني الأساسية: وثائق وبروتوكولات RFC العملية . جون وايلي وأولاده. ISBN 978-0-471-34597-8.
  • روتون، ج. (1999). دليل المبرمج لبريد الإنترنت: SMTP وPOP وIMAP وLDAP . إلسيفير. ISBN 978-1-55558-212-8.
  • وود، د. (1999). برمجة البريد الإلكتروني عبر الإنترنت . أورايلي. رقم ISBN 978-1-56592-479-6.

للمزيد من القراءة

  • RFC 1123 – متطلبات مضيفي الإنترنت - التطبيق والدعم (STD 3) 
  • RFC 1870 – امتداد خدمة SMTP لإعلان حجم الرسالة (يلغي: RFC 1653 )  
  • RFC 2505 – توصيات مكافحة البريد العشوائي لخوادم SMTP MTAs (BCP 30) 
  • RFC 2821 – بروتوكول نقل البريد البسيط 
  • RFC 2920 – امتداد خدمة SMTP لتقنية توجيه الأوامر (STD 60) 
  • RFC 3030 – امتدادات خدمة SMTP لنقل رسائل MIME الكبيرة والثنائية 
  • RFC 3207 – امتداد خدمة SMTP لبروتوكول SMTP الآمن عبر أمان طبقة النقل (يلغي RFC 2487 )  
  • RFC 3461 – امتداد خدمة SMTP لإشعارات حالة التسليم (يلغي RFC 1891 )  
  • RFC 3463 – رموز الحالة المحسنة لبروتوكول SMTP (يلغي RFC 1893 ، تم تحديثه بواسطة RFC 5248 )   
  • RFC 3464 – تنسيق رسالة قابل للتوسيع لإشعارات حالة التسليم (يلغي RFC 1894 )  
  • RFC 3798 – إشعار التخلص من الرسالة (تحديثات RFC 3461 )  
  • RFC 3834 – توصيات بشأن الردود التلقائية على البريد الإلكتروني 
  • RFC 3974 – الخبرة التشغيلية لبروتوكول SMTP في بيئات IPv4/v6 المختلطة 
  • RFC 4952 – نظرة عامة وإطار عمل للبريد الإلكتروني الدولي (تم تحديثه بواسطة RFC 5336 )  
  • RFC 4954 – امتداد خدمة SMTP للمصادقة (يلغي RFC 2554 ، ويحدث RFC 3463 ، وتم تحديثه بواسطة RFC 5248 )    
  • RFC 5068 – عمليات إرسال البريد الإلكتروني: متطلبات الوصول والمساءلة (BCP 134) 
  • RFC 5248 – سجل لرموز حالة نظام البريد المحسن SMTP (BCP 138) (تحديثات RFC 3463 )  
  • RFC 5321 – بروتوكول نقل البريد البسيط (يلغي RFC 821 المعروف أيضًا باسم STD 10، و RFC 974 ، و RFC 1869 ، و RFC 2821 ، ويحدث RFC 1123 )      
  • RFC 5322 – تنسيق رسائل الإنترنت (عفا عليه الزمن RFC 822 المعروف أيضًا باسم STD 11 و RFC 2822 )   
  • RFC 5504 – آلية تخفيض مستوى تدويل عناوين البريد الإلكتروني 
  • RFC 6409 – إرسال الرسائل للبريد (STD 72) (يلغي RFC 4409 و RFC 2476 )   
  • RFC 6522 – نوع محتوى Multipart/Report لإعداد تقارير رسائل إدارة نظام البريد (يلغي RFC 3462 ، وبالتالي RFC 1892 )   
  • RFC 6531 – امتداد SMTP لعناوين البريد الإلكتروني الدولية (تحديثات RFC 2821 و RFC 2822 و RFC 4952 و RFC 5336 )     
  • RFC 8314 – اعتبار النص الواضح قديمًا: استخدام بروتوكول أمان طبقة النقل (TLS) لإرسال البريد الإلكتروني والوصول إليه