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

📅 آخر تحديث: ٥ أغسطس ٢٠٢٦
✍️ نُشر في: ٥ أغسطس ٢٠٢٦
📷 يحتوي على 2 صور
الموسوعة الحرة

مجموعة بروتوكولات الإنترنت
طبقة التطبيق
طبقة النقل
طبقة الانترنت
طبقة الارتباط
  • ف
  • ت
  • هـ

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

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

تاريخ

أسلاف SMTP

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

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

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

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

SMTP الأصلي

في عام 1980، نشر بوستل وسوزان سلايزر RFC  772 الذي اقترح بروتوكول نقل البريد كبديل لاستخدام FTP للبريد. أزال RFC  780 الصادر في مايو 1981 جميع الإشارات إلى FTP وخصص المنفذ 57 لـ TCP و UDP ، [ بحاجة لمصدر ] وهو التخصيص الذي أزالته IANA منذ ذلك الحين . في نوفمبر 1981، نشر بوستل RFC  788 "بروتوكول نقل البريد البسيط".

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

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

كان Sendmail ، الذي تم إصداره مع 4.1cBSD في عام 1983، أحد أول وكلاء نقل البريد الذين طبقوا بروتوكول SMTP. [18] بمرور الوقت، ومع تحول BSD Unix إلى نظام التشغيل الأكثر شيوعًا على الإنترنت، أصبح Sendmail هو وكيل نقل البريد الأكثر شيوعًا . [ 19]

كان بروتوكول SMTP الأصلي يدعم فقط اتصالات نصية ASCII غير مصدقة وغير مشفرة مكونة من 7 بتات، وعرضة لهجمات الوسيط التافهة ، والاحتيال ، والرسائل العشوائية ، ويتطلب تشفير أي بيانات ثنائية إلى نص قابل للقراءة قبل الإرسال. ونظرًا لعدم وجود آلية مصادقة مناسبة، كان كل خادم SMTP عبارة عن مرحل بريد مفتوح . أفاد اتحاد بريد الإنترنت (IMC) أن 55٪ من خوادم البريد كانت مرحلًا مفتوحًا في عام 1998، [20] ولكن أقل من 1٪ في عام 2002. [21] ونظرًا لمخاوف البريد العشوائي، فإن معظم مزودي البريد الإلكتروني يحظرون المرحل المفتوح، [22] مما يجعل بروتوكول 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 . تميل وكلاء نقل البريد الإلكتروني النظيف 8 بت اليوم إلى دعم امتداد 8BITMIME، مما يسمح بنقل بعض الملفات الثنائية بسهولة تقريبًا مثل النص العادي (لا تزال الحدود المفروضة على طول السطر وقيم الثمانية المسموح بها سارية، بحيث يكون ترميز MIME مطلوبًا لمعظم البيانات غير النصية وبعض تنسيقات النص). في عام 2012، SMTPUTF8تم إنشاء الامتداد لدعم نص UTF-8 ، مما يسمح بالمحتوى والعناوين الدولية في النصوص غير اللاتينية مثل السيريلية أو الصينية .

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

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

تُظهِر الأسهم الزرقاء تنفيذ الاختلافات في SMTP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الموانئ

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

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

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

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

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

مثال على نقل SMTP

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

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

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: مرحبًا Alice.
 C: هذه رسالة اختبار بها 5 حقول رأس و4 أسطر في نص الرسالة.
 C: صديقك،
 C: Bob
 C: .
 S: 250 Ok: تم وضعها في قائمة الانتظار كـ 12345 C: QUIT
 S: 221 Bye {يغلق الخادم الاتصال}From: "Bob Example" <bob@example.org>
 To: "Alice Example" <alice@example.com>
 Cc: theboss@example.com
 Date: Tue, 15 Jan 2008 16:02:43 -0500
 Subject: Test message

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

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

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

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

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

ملحقات SMTP

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

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

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

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

S:  220 smtp2.example.com ESMTP Postfix 
C: EHLO bob.example.org
 S:  250-smtp2.example.com مرحبًا 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 [32] وهو يسهل التبادل الشفاف لرسائل البريد الإلكتروني التي تحتوي على ثماني بتات خارج مجموعة أحرف ASCII المكونة من سبعة بتات من خلال ترميزها كأجزاء محتوى MIME ، والتي يتم ترميزها عادةً باستخدام Base64 .

امتدادات آلية تسليم البريد

خدمة نقل البريد حسب الطلب

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

تمديد التدويل

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

إن الدعم الحالي محدود، ولكن هناك اهتمام قوي بالتبني الواسع النطاق لـ 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

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

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

  • 8BITMIME - نقل البيانات 8 بت، RFC  6152
  • ATRN - تم المصادقة عليه TURNلخدمة البريد عند الطلب ، RFC  2645
  • AUTH - SMTP معتمد، RFC  4954
  • CHUNKING - التجزئة، RFC  3030
  • DSN - إشعار حالة التسليم، RFC  3461 (انظر مسار إرجاع المغلف المتغير )
  • ETRN – إصدار موسع من أمر بدء قائمة انتظار الرسائل عن بعد TURN، RFC  1985
  • HELP - تقديم معلومات مفيدة، RFC  821
  • PIPELINING - خط أنابيب الأوامر، RFC  2920
  • SIZE - إعلان حجم الرسالة، RFC  1870
  • STARTTLS - أمان طبقة النقل ، RFC  3207 (2002)
  • SMTPUTF8 - السماح بترميز UTF-8 في أسماء صناديق البريد وحقول الرأس، RFC  6531
  • UTF8SMTP – السماح بترميز UTF-8 في أسماء صناديق البريد وحقول الرأس، RFC  5336 (غير مستخدم [34] )

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

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

أوامر SMTP لا تفرق بين حالة الأحرف وحالة الأحرف. يتم تقديمها هنا بأحرف كبيرة للتأكيد فقط. إن خادم SMTP الذي يتطلب طريقة معينة لكتابة الأحرف الكبيرة يعد انتهاكًا للمعيار. [35]

8 بت مايم

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

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

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

مصادقة SMTP

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

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

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

SMTPUTF8

تتضمن الخوادم الداعمة ما يلي:

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

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

STARTTLS أو "TLS الانتهازية"

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

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

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

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

DANE لـ SMTP

قدمت RFC  7672 القدرة على أن تعلن سجلات DNS عن قدرات التشفير لخادم البريد. باستخدام DNSSEC ، يتمكن مشغلو خادم البريد من نشر تجزئة لشهادة TLS الخاصة بهم، وبالتالي التخفيف من احتمالية الاتصالات غير المشفرة. [50]

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

إجراءات أمنية صارمة لنقل SMTP MTA

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

في أبريل 2019، أعلن Google Mail عن دعمه لـ MTA-STS. [52]

إعداد التقارير حول بروتوكول SMTP TLS

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

في أبريل 2019، أعلن Google Mail عن دعمه لتقارير SMTP TLS. [52]

التزييف والرسائل غير المرغوب فيها

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

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

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

التنفيذات

انظر أيضا

ملحوظات

  1. ^ تاريخ البريد الإلكتروني محفوظ في 2 ديسمبر 2017، على موقع واي باك مشين ، توم فان فليك : " ليس من الواضح أن هذا البروتوكول تم تنفيذه على الإطلاق "
  2. ^ أول بريد إلكتروني شبكي، راي توملينسون ، BBN
  3. ^ صورة "أول جهاز كمبيوتر للبريد الإلكتروني" بواسطة دان مورفي، وهو جهاز PDP-10
  4. ^ تم أرشفة أوراق دان مورفي حول TENEX وTOPS-20 في 18 نوفمبر 2007، على موقع Wayback Machine
  5. ^ RFC  524 – بروتوكول بريد مقترح
  6. ^ كروكر، ديفيد هـ. (ديسمبر 1977). "إطار ووظائف نظام الرسائل الشخصية "مايكروسوفت"" (PDF) . مؤسسة راند . مؤرشف من الأصل (PDF) في 13 مايو 2022. تم الاسترجاع في 17 أبريل 2022 .
  7. ^ RFC  469 – ملخص اجتماع البريد الشبكي
  8. ^ RFC 733، 21 نوفمبر 1977، المعيار لتنسيق الرسائل النصية لشبكة ARPA
  9. ^ "تاريخ البريد الإلكتروني: التعاون والابتكار وميلاد نظام". واشنطن بوست . 20 مايو 2023. ISSN  0190-8286 . تم الاسترجاع في 7 يوليو 2024 .
  10. ^ McKenzie, Alexander (2011). "INWG ومفهوم الإنترنت: رواية شاهد عيان". IEEE Annals of the History of Computing . 33 (1): 66–71. doi :10.1109/MAHC.2011.9. ISSN  1934-1547. S2CID  206443072.
  11. ^ باربر، د.، وجيه لوز، "مخطط بريد أساسي لرقم تعريف صاحب العمل"، INWG 192، فبراير 1979.
  12. ^ إيين 85.
  13. ^ إيين 113.
  14. ^ "Internet Experiment Note Index". www.rfc-editor.org . تم الاسترجاع في 7 يوليو 2024 .
  15. ^ "Tldp.org". مؤرشف من الأصل في 17 أغسطس 2007. تم الاسترجاع في 25 أغسطس 2007 .
  16. ^ باربر، ستان أو. (19 ديسمبر 2000). "draft-barber-uucp-project-conclusion-05 – The Conclusion of the UUCP Mapping Project". مؤرشف من الأصل في 13 أكتوبر 2007. تم الاسترجاع في 25 أغسطس 2007 .
  17. ^ تحتوي المقالة حول إعادة كتابة المرسل على معلومات أساسية تقنية حول تاريخ SMTP المبكر وتوجيه المصدر قبل RFC  1123.
  18. ^ Eric Allman (1983)، Sendmail – An Internetwork Mail Router (PDF) ، مجموعة وثائق BSD UNIX، بيركلي: جامعة كاليفورنيا، تم أرشفة (PDF) من الأصل في 20 مايو 2013 ، تم استرجاعه في 29 يونيو 2012
  19. ^ كريج بارتريدج (2008)، التطور التقني للبريد الإلكتروني عبر الإنترنت (PDF) ، حوليات معهد مهندسي الكهرباء والإلكترونيات لتاريخ الحوسبة، المجلد 30، جمعية IEEE للكمبيوتر، ص 3-29، doi :10.1109/MAHC.2008.32، S2CID  206442868، تم أرشفته من الأصل (PDF) في 12 مايو 2011
  20. ^ بول هوفمان (1 فبراير 1998). "السماح بالتتابع في SMTP: دراسة استقصائية". اتحاد البريد الإلكتروني على الإنترنت . مؤرشف من الأصل في 5 مارس 2016. تم الاسترجاع في 30 مايو 2010 .
  21. ^ بول هوفمان (أغسطس 2002). "السماح بالتتابع في SMTP: سلسلة من الاستطلاعات". اتحاد البريد الإلكتروني على الإنترنت . مؤرشف من الأصل في 18 يناير 2007. تم الاسترجاع في 30 مايو 2010 .
  22. ^ "في يونكس، ما هو برنامج إعادة توجيه البريد المفتوح؟ - قاعدة المعرفة". 17 يونيو 2007. مؤرشف من الأصل في 17 يونيو 2007. تم الاسترجاع في 15 مارس 2021 .
  23. ^ "أفعال MAIL وRCPT وDATA" محفوظ في 22 فبراير 2014، على موقع Wayback Machine ، [DJ Bernstein]
  24. ^ RFC  5321 القسم 7.2
  25. ^ Systems, Message. "Message Systems تقدم أحدث إصدار من Momentum مع قدرات جديدة تعتمد على واجهة برمجة التطبيقات". www.prnewswire.com (بيان صحفي). مؤرشف من الأصل في 19 يوليو 2020. تم الاسترجاع في 19 يوليو 2020 .
  26. ^ كارا جاريتسون (2005). "مقدمو خدمات الإنترنت يتدخلون لوقف البريد العشوائي". PC World . مؤرشف من الأصل في 28 أغسطس 2015 . تم الاسترجاع في 18 يناير 2016 . في الشهر الماضي، أصدر التحالف التقني لمكافحة البريد العشوائي، الذي تشكل العام الماضي من قبل ياهو وأمريكا أون لاين وإيرثلنك ومايكروسوفت، قائمة بتوصيات مكافحة البريد العشوائي التي تتضمن تصفية المنفذ 25.
  27. ^ RFC  5321، بروتوكول نقل البريد البسيط ، ج. كلينسين، جمعية الإنترنت (أكتوبر 2008)
  28. ^ طلب التعليق رقم  1047
  29. ^ Klensin, John C. (October 2008). "rfc5321#section-4.5.3.2.6". مؤرشف من الأصل في 16 يناير 2015. تم الاسترجاع في 7 يونيو 2010 .
  30. ^ جون كلينسين؛ نيد فريد؛ مارشال تي روز؛ إينار أ. ستيفيرود؛ ديف كروكر (نوفمبر 1995). ملحقات خدمة SMTP. IETF . doi : 10.17487/RFC1869 . RFC 1869.
  31. ^ ab "MAIL Parameters". IANA. 14 فبراير 2020. مؤرشف من الأصل في 28 مايو 2019. تم الاسترجاع في 28 مايو 2019 .
  32. ^ والتي أصبحت قديمة في عام 2011 بموجب RFC  6152 المقابلة لـ STD 71 الجديد آنذاك
  33. ^ Jiankang Yao (19 ديسمبر 2014). "عنوان البريد الإلكتروني الصيني". EAI (قائمة بريدية). IETF . مؤرشف من الأصل في 2 أكتوبر 2015. تم الاسترجاع في 24 مايو 2016 .
  34. ^ "معلمات امتداد خدمة SMTP". IANA. مؤرشف من الأصل في 28 مايو 2019. تم الاسترجاع في 5 نوفمبر 2013 .
  35. ^ كلينسين، جون سي. (أكتوبر 2008). بروتوكول نقل البريد البسيط (تقرير). فريق عمل هندسة الإنترنت.
  36. ^ James Server - ChangeLog Archived February 20, 2020, at the Wayback Machine . James.apache.org. Retrieved on 2013-07-17.
  37. ^ تم الإعلان عن خدمة 8BITMIME ردًا على EHLO على المنفذ 25 في gmail-smtp-in.l.google.com، وتم فحصها في 23 نوفمبر 2011
  38. ^ أخطاء Qmail وقائمة الرغبات. Home.pages.de. تم الاسترجاع في 2013-07-17.
  39. ^ تم أرشفة ملحق 8BITMIME في 7 يونيو 2011 على موقع Wayback Machine . Cr.yp.to. تم ​​الاسترجاع في 2013-07-17.
  40. ^ "تم تمكين دعم Postfix SMTPUTF8 افتراضيًا" محفوظ في 7 أغسطس 2020، على موقع Wayback Machine ، 8 فبراير 2015، postfix.org
  41. ^ "Message Systems تقدم أحدث إصدار من Momentum مع إمكانيات جديدة تعتمد على واجهة برمجة التطبيقات" (بيان صحفي). مؤرشف من الأصل في 15 سبتمبر 2020. تم الاسترجاع في 17 سبتمبر 2020 .
  42. ^ "سجل مراجعة الإصدار 6.2". CommuniGate.com . مؤرشف من الأصل في 29 أكتوبر 2020 . تم الاسترجاع في 17 سبتمبر 2020 .
  43. ^ Sam Varshavchik (18 سبتمبر 2018). "إصدارات جديدة من حزم البريد السريع". courier-announce (قائمة بريدية). مؤرشف من الأصل في 17 أغسطس 2021. تم الاسترجاع في 17 سبتمبر 2020 .
  44. ^ "Halon MTA changelog". GitHub . 9 نوفمبر 2021. مؤرشف من الأصل في 18 سبتمبر 2020 . تم الاسترجاع في 17 سبتمبر 2020 . v4.0: دعم SMTPUTF8 الجديدتم التحديث للإصدارات الجديدة
  45. ^ "MS-OXSMTP: Simple Mail Transfer Protocol (SMTP) Extensions". 24 يوليو 2018. مؤرشف من الأصل في 16 أغسطس 2021. تم الاسترجاع في 17 سبتمبر 2020 .
  46. ^ "جاهزية EAI في نطاقات المستوى الأعلى" (PDF) . 12 فبراير 2019. مؤرشف (PDF) من الأصل في 24 يناير 2021. تم الاسترجاع في 17 سبتمبر 2020 .
  47. ^ "ملاحظات إصدار خادم المراسلة للاتصالات". oracle.com . أكتوبر 2017. مؤرشف من الأصل في 24 نوفمبر 2020. تم الاسترجاع في 17 سبتمبر 2020 .
  48. ^ "مقدمة عن الأمن الصارم للنقل في MTA (MTA-STS) | مدونة Hardenize". www.hardenize.com . مؤرشف من الأصل في 25 أبريل 2019 . تم الاسترجاع في 25 أبريل 2019 .
  49. ^ "STARTTLS Everywhere". EFF. مؤرشف من الأصل في 9 أغسطس 2019. تم الاسترجاع في 4 ديسمبر 2021 .
  50. ^ v-mathavale (21 يوليو 2023). "كيف تعمل مصادقة SMTP DNS المستندة إلى الكيانات المسماة (DANE) على تأمين اتصالات البريد الإلكتروني". learn.microsoft.com . تم الاسترجاع في 5 مارس 2024 .
  51. ^ "تنفيذ بروتوكول SMTP DANE الوارد مع DNSSEC لتدفق البريد عبر الإنترنت في Exchange". techcommunity.microsoft.com . تم الاسترجاع في 5 مارس 2024 .
  52. ^ من قبل Cimpanu, Catalin. "Gmail becomes first major email provider to support MTA-STS and TLS Reporting". ZDNet . مؤرشف من الأصل في 29 أبريل 2019 . تم الاسترجاع في 25 أبريل 2019 .
  53. ^ "رسالة غير متوافقة مع RFC 5322". مؤرشف من الأصل في 17 يناير 2023. تم الاسترجاع 20 يناير 2021 .
  54. ^ "لم يتم تسليم الرسالة. يرجى التأكد من أن الرسالة متوافقة مع RFC 5322". مؤرشف من الأصل في 28 يناير 2021 . تم الاسترجاع في 20 يناير 2021 .
  55. ^ "لماذا يتم رفض رسائل البريد الإلكتروني المرسلة إلى حساب Microsoft لأسباب تتعلق بالسياسة؟". مؤرشف من الأصل في 14 فبراير 2021 . تم الاسترجاع في 20 يناير 2021 .

مراجع

  • هيوز، ل. (1998). البريد الإلكتروني عبر الإنترنت: البروتوكولات والمعايير والتنفيذ . دار أرتيك للنشر. رقم ISBN 978-0-89006-939-4.
  • هانت، سي (2003). كتاب الطبخ sendmail . أوريلي ميديا. رقم ISBN 978-0-596-00471-2.
  • جونسون، ك. (2000). بروتوكولات البريد الإلكتروني عبر الإنترنت: دليل للمطورين . أديسون ويسلي بروفيشنال. رقم ISBN 978-0-201-43288-6.
  • Loshin, P (1999). Essential Email Standards: RFCs and Protocols Made Practical . John Wiley & Sons. ISBN 978-0-471-34597-8.
  • Rhoton, J (1999). دليل المبرمجين للبريد الإلكتروني عبر الإنترنت: SMTP وPOP وIMAP وLDAP . Elsevier. ISBN 978-1-55558-212-8.
  • وود، د. (1999). برمجة بريد الإنترنت . أوريلي. رقم ISBN 978-1-56592-479-6.

قراءة إضافية

  • RFC  1123 – متطلبات مضيفات الإنترنت – التطبيق والدعم (المعيار 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 – نوع المحتوى متعدد الأجزاء/التقرير لإعداد التقارير عن رسائل إدارة نظام البريد (يجعل RFC  3462 قديمًا، وبالتالي RFC  1892)
  • RFC  6531 – ملحق SMTP لعناوين البريد الإلكتروني الدولية (تحديثات RFC  2821 و RFC  2822 و RFC  4952 و RFC  5336)
  • RFC  8314 – اعتبار النص العادي قديمًا: استخدام أمان طبقة النقل (TLS) لإرسال البريد الإلكتروني والوصول إليه
تم الاسترجاع من "https://en.wikipedia.org/w/index.php?title=بروتوكول_نقل_البريد_البسيط&oldid=1249162949#8BITMIME"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate