(SMTP) هو معيار للبريد الإلكتروني. تم توثيقه في الأصل في RFC 821 (1982)، وتم تحديثه آخر مرة في عام 2008 مع إضافات موسعة من SMTP إلى RFC 5321 (بروتوكول يستخدم على نطاق واسع اليوم).

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

صفات

يستخدم اتصال SMTP بين خوادم البريد منفذ TCP 25. غالبًا ما يرسل عملاء البريد رسائل البريد الإلكتروني الصادرة إلى خادم البريد على المنفذ 587. على الرغم من أن موفري البريد القديم ما زالوا يسمحون باستخدام المنفذ غير القياسي 465 لهذا الغرض.

يمكن إجراء اتصالات SMTP المحمية بواسطة TLS، والمعروفة باسم SMTPS، باستخدام تقنية STARTTLS.

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

وجهة SMTP

أصبح كل شيء تقريبًا على الإنترنت ممكنًا بفضل البروتوكولات — قواعد برامج الشبكة الخاصة التي تسمح لجهاز الكمبيوتر بالاتصال بجميع الشبكات حتى يتمكن المستخدمون من التسوق وقراءة الأخبار وإرسال البريد الإلكتروني. تعد البروتوكولات أمرًا حيويًا للشبكات اليومية، فهي مدمجة في برامج الشبكات ويتم استخدامها بشكل افتراضي.

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

المصطلحات الفنية

SMTP هو بروتوكول TCP/IP يستخدم للتعامل مع البريد الإلكتروني. ومع ذلك، نظرًا لأنه يقتصر على القدرة على إرسال الرسائل إلى قائمة الانتظار على الطرف المتلقي، يتم استخدامه عادةً مع POP3 أو IMAP، مما يسمح بتخزين البيانات على الخادم وتنزيلها عند الضرورة. بمعنى آخر، يستخدمون عادةً تطبيقًا يحدد SMTP لإرسال البريد الإلكتروني وPOP3 أو IMAP لتلقي المراسلات. في الأنظمة المستندة إلى Unix، يعد sendmail هو خادم SMTP الأكثر استخدامًا للبريد الإلكتروني. تتضمن حزمة Sendmail التجارية خادم POP3. يتضمن Microsoft Exchange خادم SMTP ويمكن تهيئته أيضًا لدعم POP3.

يُستخدم SMTP عادةً للعمل عبر منفذ الإنترنت 25. البديل لـ SMTP المستخدم على نطاق واسع في أوروبا هو X.400. تدعم العديد من خوادم البريد الإلكتروني الآن بروتوكول نقل البريد البسيط الممتد (ESMTP)، والذي يسمح لك بنقل ملفات الوسائط المتعددة كبريد إلكتروني.

قصة

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

تشمل التطبيقات الإضافية بروتوكول بريد FTP، بدءًا من عام 1973. استمرت أعمال التطوير خلال السبعينيات حتى أصبحت ARPANET هي الإنترنت الحديث في عام 1980. ثم اقترح جون بوستل بروتوكولًا لنقل بيانات البريد.

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

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

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

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

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

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

منافذ البريد SMTP ومعناها

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

بدء قائمة انتظار الرسائل الفارغة

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

عنوان البريد الإلكتروني الدولي

المستخدمون الذين ليس نصهم لاتينيًا، أو الذين يستخدمون علامات التشكيل غير الموجودة في مجموعة أحرف ASCII، واجهوا صعوبة في طلب عنوان بريد إلكتروني لاتيني (منفذ mail.ru SMTP). تم إنشاء RFC 6531 لمعالجة هذه المشكلة من خلال توفير إمكانات التدويل لـ SMTP، وامتدادًا لـ SMTPUTF8، ودعم الأحرف متعددة البايت وغير ASCII في عناوين البريد الإلكتروني. أمثلة: علامات التشكيل ورموز اللغة الأخرى (اليونانية والصينية). مناسب أيضًا لمنفذ Yandex SMTP.

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

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

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

القيود المفروضة على الوصول إلى خادم البريد الصادر

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

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

تقدم خوادم SMTP الحديثة عادةً نظامًا بديلاً يتطلب من العملاء المصادقة باستخدام بيانات الاعتماد قبل السماح بالوصول.

SMTP - ما هو المنفذ المستخدم؟

عادةً ما يستخدم الاتصال بين خوادم البريد دائمًا قيمة منفذ TCP الافتراضية البالغة 25، والتي يتم تعيينها لـ SMTP. ومع ذلك، عادةً ما يستخدم عملاء البريد الإلكتروني منافذ SMTP SSL محددة بدلاً من ذلك. يقوم معظم مزودي خدمة الإنترنت الآن بحظر كل حركة مرور المنفذ الصادرة من عملائهم كإجراء لمكافحة البريد العشوائي. لنفس السبب، تقوم الشركات عادةً بتكوين جدار الحماية الخاص بها للسماح بالمنافذ الصادرة من خوادم البريد المعينة.

مثال النقل SMTP

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

ملحقات إضافية

يتعرف العملاء على الخيارات التي يدعمها الخادم باستخدام تحية EHLO بدلاً من HELO الأصلية. يعود العملاء إلى HELO فقط إذا كان الخادم لا يدعم امتدادات SMTP.

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

طرق مكافحة البريد العشوائي ومصادقة البريد الإلكتروني

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

يتم تقديم مقترحات خاصة لتغيير SMTPs أو استبدالها بالكامل. يعد Internet Mail 2000 أحد الأمثلة على ذلك، ولكن لم يحقق هو ولا أي شخص آخر الكثير من النجاح قبل تأثير الشبكة لقاعدة SMTP الكلاسيكية المثبتة الضخمة. وبدلاً من ذلك، تستخدم خوادم البريد الآن مجموعة من الأساليب، بما في ذلك DomainKeys، وDomainKeys Identified Mail، و Policy Framework و DMARC، و DNSBLs، والقائمة الرمادية لرفض رسائل البريد الإلكتروني المشبوهة أو عزلها.

الأوامر هي سلاسل نصية تنتهي بتسلسل. الأمر، على هذا النحو، عبارة عن سلسلة من الأحرف (عادةً 4 أحرف) تنتهي بمسافة (في حالة وجود معلمات) أو. يُنصح مستلمو SMTP بالتسامح مع المسافات قبل التسلسل اللاحق.

قائمة أوامر بروتوكول SMTP:

الأوامر المحددة مباشرة في RFC 5321:

• EHLO (أو قياسي - HELO) يفتح دعوة من العميل. يتم استخدام هذه الأوامر لتقديم عميل SMTP إلى خادم SMTP. يحتوي حقل الوسائط على اسم المجال المؤهل بالكامل لعميل SMTP، إذا كان هذا الاسم متاحًا. في الحالات التي لا يكون لدى عميل SMTP اسم مجال ذي معنى (على سبيل المثال، عندما يتم تخصيص العناوين ديناميكيًا ولا تتوفر الترجمة العكسية)، يجب على العملاء تمرير العنوان الكامل. على الرغم من أن الخوادم يجب أن تستجيب لكلا الأمرين، فمن الأفضل استخدام أمر EHLO، نظرًا لأن الخوادم التي لا تدعم خدمات SMTP المتقدمة ستُرجع دائمًا رسالة خطأ استجابةً لـ EHLO.

مثال:
مرحبا orsi1.rsmc.ru

• البريد - يحدد مرسل الرسالة. يحتوي حقل الوسائط على مسار الإرجاع وقد يتضمن معلمات إضافية. في الواقع، هذا الأمر يحدد مرسل الرسالة (MAIL FROM)

مثال:
البريد من:

• RCPT - يحدد مستلمي الرسائل. يمكن لعدة مستخدمين تلقي نفس الرسالة. عادةً، يتم تحديد كل مستلم على سطر منفصل باستخدام أمر RCPT.

مثال:
RCPT إلى: root@site

• البيانات - تحدد بداية الرسالة. لا يدعم المعلمات. بعد معالجة أوامر MAIL وRCPT، يتم استخدام أمر DATA لنقل جزء المعلومات من الرسالة. كل ما يتبع هذا الأمر يتم تفسيره على أنه رسالة ليتم إرسالها. ها هي رسالتنا! 

مثال:
بيانات

• RSET - إعادة تعيين اتصال SMTP سنويًا. لا يدعم المعلمات. إرجاع الجلسة إلى اللحظة التي تلت إصدار أمر HELO (EHLO)، مع اعتبار جميع أوامر MAIL وRCPT وDATA التي تم إرسالها مسبقًا غير صالحة.
• VRFY - يتحقق من اسم مستخدم النظام. إذا كان هناك مستخدم محلي بالاسم المحدد على خادم البريد، فسيقوم الخادم بإرجاع عنوان بريده الكامل. إذا لم يكن هناك مثل هذا المستخدم المحلي، فسيتم إرجاع رسالة خطأ، أو رسالة تفيد بأن الخادم سوف يعيد توجيه الرسائل بشكل أكبر. إذا تم استخدام الاسم الوارد في المثال، فمن المرجح أن نتلقى رسالة خطأ.

مثال:
VRFY كيريش

• EXPN - يطلب قائمة بالقوائم البريدية والأسماء المستعارة للبريد.

مثال:
القائمة البريدية EXPN

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

مثال:
مساعدة VRFY

• NOOP - لا توجد عملية - لا تفعل شيئًا.

مثال:
لا

• QUIT - إنهاء جلسة SMTP. لا يدعم المعلمات.

مثال:
يترك

أوامر أخرى:

• إرسال - يرسل رسالة إلى محطة المستخدم المسجل. يتم تنفيذ هذا الأمر فقط إذا قام المستخدم بتسجيل الدخول ويظهر عادةً كرسالة منبثقة. ليس الفريق الأكثر شعبية.
• SOML - إذا كان مستلمو الرسالة متصلين بالنظام، فإن SOML يعمل مثل أمر الإرسال. إذا لم يكن متصلا، ثم كأمر البريد. نظرًا لعدم أمان هذا الأمر، نادرًا ما يتم تنفيذه على الخادم.
• SAML - ينقل رسالة إلى محطة المستخدم إذا قام بتسجيل الدخول ويضع هذه الرسالة في صندوق البريد الخاص به في نفس الوقت.
• TURN - عكس الدور في SMTP (يصبح العميل خادمًا). عادةً ما يقوم SMTP بإعادة توجيه الرسائل في اتجاه واحد فقط عبر اتصال TCP واحد. الغرض من أمر TURN هو تنظيم تبادل ثنائي الاتجاه لرسائل البريد الإلكتروني بين جهازي كمبيوتر عبر اتصال TCP موجود. نظرًا لشعبية هذا الأمر بين المهاجمين، لا يمكن العثور على تنفيذه غالبًا على الخادم.
• AUTH - يعرض للخادم آلية المصادقة. RFC 4954 (تم استبدال RFC 2554).

• إلى الأمام

اضف تعليق

• القياس عن بعد في نظام التشغيل Windows 10. قم بتعطيله، ولا تقم بتعطيله، وستظل تحصل على الحل الأفضل
• يذهب. تمكن الكمبيوتر من التغلب على بطل بطل أوروبا ثلاث مرات في لعبة Go
• "هدايا" جديدة من مايكروسوفت - "الاستقرار" و"الخصوصية"

مقالات جديدة

• لا يتم تشغيل اكتشاف الشبكة في نظام التشغيل Windows 7/8/2008/2012
• خطأ: فشل هذا التطبيق في بدء التشغيل لأنه لم يتمكن من العثور على "windows" المكون الإضافي لمنصة Qt أو تحميله.

  لذلك، بعد التثبيت عن طريق النسخ المباشر لتطبيق مكتوب بلغة C++ باستخدام مكتبة Qt، نحصل على الخطأ التالي: فشل هذا التطبيق في البدء...

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

قصة

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

يمكن إرجاع جذور SMTP إلى تطبيقين تم وصفهما في عام 1971 - بروتوكول صندوق البريد وSNDMSG، اللذين "اخترعهما" راي توملينسون من شركة BBN Technologies لأجهزة الكمبيوتر TOPS-20/TENEX التي ترسل الرسائل عبر ARPANET (في ذلك الوقت كانت تستخدم متصل بأقل من 50 مضيفًا).

تشمل التطبيقات الأخرى بروتوكول FTP للبريد والبريد، الذي تم تطويره في عام 1973. واستمر التطوير طوال السبعينيات حتى تطورت ARPANET إلى الإنترنت الحديث حوالي عام 1980. وفي نفس العام، اقترح جون بوستل بروتوكول نقل البريد، والذي بفضله توقف FTP عن كونه بروتوكول نقل البريد أساس إرسال البريد. تم نشر SMTP في RFC 821 (الذي كتبه Postel أيضًا) في أغسطس 1982.

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

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

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

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

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

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

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

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

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

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

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

تتكون عملية SMTP من ثلاثة تسلسلات للأوامر/الاستجابة (انظر المثال أدناه). وصف التسلسلات:

• البريد من - يضبط عنوان المرسل (أي مسار الإرجاع، 53121.من، mfrom). هذا هو عنوان الرسائل المرتجعة.

• RCPT TO - يضبط مستلم هذه الرسالة. يمكن إعطاء هذا الأمر عدة مرات، مرة واحدة لكل مستلم. هذه العناوين هي أيضًا جزء من الصدفة.

• البيانات - لإرسال نص الرسالة. هذا هو محتوى الرسالة نفسها، وليس غلافها. يتكون من رأس الرسالة ونص الرسالة مفصولين بسطر فارغ. البيانات هي في الأساس مجموعة من الأوامر، ويستجيب الخادم مرتين: أولاً لأمر البيانات نفسه، للإشارة إلى أنه جاهز لقبول النص؛ ومرة ثانية بعد انتهاء تسلسل البيانات لقبول أو رفض الرسالة بأكملها.

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

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

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

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

SMTP واسترجاع الرسائل

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

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

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

ترحيل البريد عند الطلب

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

تدويل

يواجه العديد من المستخدمين الذين تختلف مجموعة أحرفهم عن الأبجدية اللاتينية متطلب عنوان بريد إلكتروني باللغة اللاتينية. لحل هذه المشكلة، تم إنشاء RFC 6531، مما يوفر إمكانات التدويل لـ SMTP - وهو امتداد لـ SMTPUTF8. يوفر RFC 6531 دعمًا للأحرف متعددة البايت وغير ASCII في عنوان البريد، على سبيل المثال: δοκιμή@παράδειγμα.δοκιμή أو 测试@测试.测试. الدعم الحالي محدود، ولكن هناك اهتمام كبير بالاعتماد على نطاق واسع لـ RFC 6531 وRFCs ذات الصلة في البلدان ذات قواعد المستخدمين الكبيرة والتي لا تعد اللاتينية أبجدية أصلية لها.

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

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

القيود المفروضة على الوصول إلى خادم البريد الصادر

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

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

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

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

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

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

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

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

افتح رايلي

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

الموانئ

يختار مسؤولو الخادم المنفذ الذي سيستخدمه العملاء لترحيل البريد الصادر - 25 أو 587. تدعم المواصفات والعديد من الخوادم كلا المنفذين. على الرغم من أن بعض الخوادم تدعم المنفذ 465 لـ SMTP الآمن، فمن الأفضل استخدام المنافذ القياسية وأوامر ESMTP إذا كانت هناك حاجة لجلسة آمنة بين العميل والخادم.

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

يعترض بعض موفري خدمة الإنترنت المنفذ 25، ويعيدون توجيه حركة المرور إلى خادم SMTP الخاص بهم، بغض النظر عن عنوان الوجهة. وبالتالي، لا يمكن لمستخدميهم الوصول إلى الخادم خارج شبكة الموفر على المنفذ 25.

تدعم بعض الخوادم الوصول المصادق عليه على منفذ إضافي غير 25، مما يسمح للمستخدمين بالاتصال بها حتى إذا كان المنفذ 25 محظورًا.

مثال على جلسة SMTP بسيطة

ج: - العميل، س: - الخادم

S: (في انتظار الاتصال) C: (يتصل بمنفذ الخادم 25) S:220 mail.company.tld ESMTP CommuniGate Pro 5.1.4i سعيد برؤيتك! يجب أن يكون اسم المجال C:HELO S:250 مؤهلاً C:MAIL FROM: S:250 [البريد الإلكتروني محمي]تم قبول المرسل C:RCPT TO:S:250 [البريد الإلكتروني محمي]موافق C:RCPT إلى:S:550 [البريد الإلكتروني محمي]حساب مستخدم غير معروف C:DATA S:354 أدخل البريد، وانتهى بـ "." على سطر بمفرده C:from: [البريد الإلكتروني محمي]// إلى الحرف ج:إلى: [البريد الإلكتروني محمي]// لم تتم إضافته C:subject: tema //إلى فئة البريد العشوائي C: //C:Hi! ج:. S:250 769947 تم قبول الرسالة للتسليم C:QUIT S:221 mail.company.tld CommuniGate Pro SMTP إغلاق الاتصال S: (يغلق الاتصال)

ونتيجة لهذه الجلسة، سيتم تسليم الرسالة إلى المرسل إليه [البريد الإلكتروني محمي]ولكن لن يتم تسليمها إلى المستلم [البريد الإلكتروني محمي]، لأن مثل هذا العنوان غير موجود.

ملحقات إضافية

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

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

يعلن smtp2.example.com أنه سيقبل رسالة لا يزيد حجمها عن 14,680,064 ثماني بتات (8 بايت بايت). اعتمادًا على الاستخدام الفعلي للخادم، قد لا يقبل حاليًا رسالة بهذا الحجم. في أبسط الحالات، سيعلن خادم ESMTP فقط عن الحد الأقصى للحجم عند التفاعل مع المستخدم عبر EHLO.

أمان SMTP والبريد العشوائي

لم تتضمن مواصفات SMTP الأصلية أي وسيلة لمصادقة المرسلين. وفي وقت لاحق، تم تقديم ملحق في RFC 2554. يوفر ملحق SMTP (ESMTP) آلية لعملاء البريد الإلكتروني لتحديد آلية أمان للخادم والمصادقة وملف تعريف أمان SASL (المصادقة البسيطة وطبقة الأمان) لعمليات نقل الرسائل اللاحقة.

تطبق منتجات Microsoft البروتوكول الخاص بها - SPA (مصادقة كلمة المرور الآمنة) باستخدام ملحق SMTP-AUTH.

ومع ذلك، فإن عدم جدوى التنفيذ والإدارة على نطاق واسع لـ SMTP-AUTH يعني أنه لا يمكن حل مشكلة البريد العشوائي بمساعدته.

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

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

هناك العديد من المقترحات للبروتوكولات الجانبية لمساعدة SMTP في العمل. تعمل مجموعة أبحاث مكافحة البريد العشوائي (ASRG)، وهي أحد أقسام مجموعة أبحاث تكنولوجيا الإنترنت، على مصادقة البريد ومقترحات أخرى لتوفير مصادقة بسيطة تتسم بالمرونة وخفيفة الوزن وقابلة للتطوير. يتضمن العمل الأخير لفريق عمل هندسة الإنترنت (IETF) MARID (2004)، الذي أدى إلى تجربتين معتمدتين من قبل IETF في عام 2005، والبريد المحدد بمفاتيح المجال في عام 2006.

ملحقات ESMTP

يتطلب RFC 1869 أن تبدأ الجلسة باستخدام الأمر EHLO بدلاً من الأمر HELO. إذا كان الخادم لا يدعم الامتدادات، فسوف يستجيب لـ EHLO بخطأ؛ في هذه الحالة، يجب على العميل إرسال أمر HELO وعدم استخدام امتدادات البروتوكول.

إذا كان الخادم يدعم ESMTP، فبالإضافة إلى الترحيب، فإنه سيوفر قائمة بامتدادات بروتوكول SMTP المدعومة، على سبيل المثال:

Ehlo office.company1.tld 250-mail.company2.tld يسره مقابلتك 250-DSN 250-SIZE 250-STARTTLS 250-AUTH تسجيل دخول عادي CRAM-MD5 DIGEST-MD5 GSSAPI MSN NTLM 250-ETRN 250-TURN 250-ATRN 250-عدم التماس 250-مساعدة 250-خط الأنابيب 250 EHLO

معايير RFC

• ملحق خدمة RFC 1870 SMTP لإعلان حجم الرسالة (يحل محل RFC 1653)
• ملحق خدمة RFC 2034 SMTP لإرجاع رموز الخطأ المحسنة
• توصيات RFC 2505 لمكافحة البريد العشوائي لـ SMTP MTAs (BCP 30)
• RFC 4954 ملحق خدمة SMTP للمصادقة (يحل محل RFC 2554)
• RFC 2822 تنسيق رسائل الإنترنت (يحل محل RFC 822 المعروف أيضًا باسم STD 11)
• ملحق خدمة RFC 2920 SMTP لخطوط توجيه الأوامر (STD 60)
• ملحقات خدمة RFC 3030 SMTP لنقل رسائل MIME الكبيرة والثنائية
• ملحق خدمة RFC 3207 SMTP لـ SMTP الآمن عبر أمان طبقة النقل (يحل محل RFC 2487)
• ملحق خدمة RFC 3461 SMTP لإشعارات حالة التسليم (يحل محل RFC 1891)
• RFC 3462 نوع المحتوى متعدد الأجزاء/التقرير للإبلاغ عن الرسائل الإدارية لنظام البريد (يحل محل RFC 1892)
• RFC 3463 رموز الحالة المحسنة لـ SMTP (يحل محل RFC 1893)
• RFC 3464 تنسيق رسالة قابل للتوسيع لإشعارات حالة التسليم (يحل محل RFC 1894)
• إرشادات RFC 3552 لكتابة نص RFC بشأن الاعتبارات الأمنية
• توصيات RFC 3834 للردود التلقائية على البريد الإلكتروني
• RFC 4409 إرسال الرسائل للبريد (يحل محل RFC 2476)
• RFC 5321 بروتوكول نقل البريد البسيط (يحل محل RFC 821 المعروف أيضًا باسم STD 10، RFC 974، RFC 1869، RFC 2821)
• RFC 5336 ملحق SMTP لعناوين البريد الإلكتروني الدولية
• ترجمة RFC 2505 - إرشادات منع البريد العشوائي لـ SMTP MTAs
• ترجمة RFC 2554 - ملحق خدمة SMTP للمصادقة
• ترجمة RFC 5321 - بروتوكول نقل البريد البسيط (SMTP)

الأدب

• هيوز لبروتوكولات البريد الإلكتروني عبر الإنترنت والمعايير والتنفيذ. - دار آرتك للنشر، 1998. - ISBN 0-89006-939-5
• هانت جإرسال كتاب الطبخ. - أو رايلي ميديا، 2003. - ISBN 0-596-00471-0
• جونسون كبروتوكولات البريد الإلكتروني عبر الإنترنت: دليل المطور – أديسون ويسلي بروفيشنال، 2000. – ISBN 0-201-43288-9.
• لوشين بمعايير البريد الإلكتروني الأساسية: RFCs والبروتوكولات أصبحت عملية. - جون وايلي وأولاده، 1999. - ISBN 0-471-34597-0
• روتون جدليل المبرمج لبريد الإنترنت: SMTP، POP، IMAP، وLDAP - إلسفير، 1999.

SMTP (بروتوكول نقل البريد البسيط) هو بروتوكول شبكة مصمم لنقل البريد الإلكتروني عبر شبكات TCP/IP. ESMTP (الإنجليزية الموسعة SMTP) هو امتداد قابل للتوسع لبروتوكول SMTP. حاليًا، يشير "بروتوكول SMTP" عادةً إلى ESMTP وامتداداته. يستخدم SMTP منافذ TCP 25.

يستخدم بروتوكول SMTP أوامر نصية بسيطة ASCII ويقوم بإرجاع استجابات الرسائل النصية المشفرة المكونة من ثلاثة أحرف. تم وصف بروتوكول SMTP في طلب الإنترنت للتعليق (RFC) رقم 821، والذي تم تطويره بواسطة فريق عمل هندسة الإنترنت (IETF) وتم نشره في 21 أغسطس 1982. ومنذ ذلك الحين، خضع للعديد من التعديلات، ولكن بشكل عام لم تتغير الأوامر الأساسية للبروتوكول.

أوامر عميل SMTP الأساسية أمر HELO

حسب التعريف، تتكون أوامر بروتوكول SMTP من أربعة أحرف. التحية الصادرة عن العميل للخادم هي أمر HELO. تنسيق الأمر كما يلي:

HELO اسم النطاق

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

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

أمر المصادقة

تم وصف توسيع محادثة SMTP باستخدام أمر AUTH في RFC 4954.

عادي (يستخدم ترميز Base64.)

تسجيل الدخول (يستخدم ترميز Base64.)

GSSAPI (واجهة برنامج تطبيقات خدمات الأمان العامة)

DIGEST-MD5 (مصادقة الوصول إلى الملخص)

الفرق الوحيد بين PLAIN وLOGIN هو أنه في الخيار الأول يتم إرسال تسجيل الدخول + كلمة المرور في سطر واحد، وفي الخيار الثاني - أولاً تسجيل الدخول، ثم كلمة المرور. لكن جميعها مشفرة بالضرورة في Base64.

أمر البريد

يتم استخدام أمر MAIL لتأسيس جلسة بريد إلكتروني مع الخادم بعد إرسال أمر HELO. إنه يشير إلى من تأتي الرسالة. تنسيق الأمر MAIL كما يلي:

MAIL المسار العكسي

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

البريد من: [البريد الإلكتروني محمي]

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

فريق RCPT

يحدد أمر RCPT مستلمي الرسائل. يمكن لعدة مستخدمين تلقي نفس الرسالة. عادةً، يتم تحديد كل مستلم على سطر منفصل باستخدام أمر RCPT. تنسيق أمر RCPT كما يلي:

مسار RCPT إلى الأمام

تحدد وسيطة المسار الأمامي مكان إعادة توجيه البريد الإلكتروني. عادةً ما يتضمن هذا عنوان البريد الإلكتروني بالكامل، ولكنه قد يتضمن أيضًا اسم مستخدم خادم SMTP المحلي. خذ بعين الاعتبار على سبيل المثال الأمر التالي:

RCPT إلى: هالي

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

RCPT إلى: [البريد الإلكتروني محمي]

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

يمكن لمضيف shardrach إعادة توجيه الرسالة إلى المستلم وإرجاع الرد الإيجابي إلى المرسل (موافق). في هذه الحالة، يقوم بإضافة اسمه إلى حقل أمر البريد بحيث يمكن تضمينه في مسار الرسالة عندما يحتاج إلى إعلام المرسل.

يتعذر على المضيف shardrach إعادة توجيه الرسالة وإعلام المرسل، مع التأكد من صحة عنوان المضيف Meshach.smallorg.org. لذلك يمكن للمرسل محاولة إعادة إرسال الرسالة مباشرة إلى Meshach.smallorg.org.

لا يمكن للمضيف shardrach إعادة توجيه الرسالة ويرسل إشعارًا بأنه لا يمكن إجراء هذه العملية مع هذا الخادم. ثم يجب تحليل أسباب ما حدث من قبل مسؤول النظام.

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

أمر البيانات

هذا الأمر هو الأمر الرئيسي في بروتوكول SMTP. بعد معالجة أوامر MAIL وRCPT، يتم استخدام أمر DATA لنقل جزء المعلومات من الرسالة. تنسيق أمر البيانات كما يلي:

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

.

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

إرسال الأمر

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

أمر RSET

أمر RSET قصير لإعادة التعيين. إذا أصبح العميل مرتبكًا بشأن الاستجابات التي يتلقاها من الخادم، أو قرر فقدان الاتصال، فيمكنه إصدار أمر RSET وإعادة الجلسة إلى نقطة بدايتها - تنفيذ أمر HELO. في هذه الحالة، سيتم إلغاء جميع الأوامر المرسلة مسبقًا - MAIL وRCPT وDATA. في كثير من الأحيان يتم استخدام هذا الأمر "كحل أخير" عندما يفقد العميل تسلسل الأوامر أو يتلقى استجابة غير متوقعة من الخادم.

VRFY

الأمر VRFY هو اختصار للتحقق. يمكن استخدامه لتحديد ما إذا كان الخادم يمكنه تسليم البريد إلى مستلم معين قبل تنفيذ أمر RCPT. تنسيق هذا الأمر كما يلي:

اسم المستخدم VRFY

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

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

1 [riley@ shadrach riley] $ telnet localhost 25 2 محاولة 127.0.0.1... 3 متصل بالمضيف المحلي. 4 حرف الهروب هو "^]" . 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/ 8.9.3؛ الخميس، 26 أغسطس 1999 19:20:16 -050 6 HELO localhost 7 250 shadrach.smallorg.org مرحبًا المضيف المحلي [127.0.0.1]، يسرني مقابلتك 8 VRFY rich 9 250< rich@ shadrach,smallorg.org>10 VRFY [email protected] 11 252< prez@ mechach.smallorg.org>12 VRFY jessica 13 550 jessica... المستخدم غير معروف 14 QUIT 15 221 shadrach.smallorg.org إغلاق الاتصال 16 تم إغلاق الاتصال بواسطة -مضيف أجنبي. 17 [رايلي @ شادراش رايلي] $

تُظهر الأسطر 8-13 إخراج أمر VRFY. يحاول السطر 8 تنفيذ VRFY على المستخدم المحلي الغني. تؤكد استجابة خادم SMTP في السطر 9 وجود مستخدم بهذا الاسم في النظام، ويتم إرجاع عنوان البريد الإلكتروني الكامل للعميل. يعرض السطر 10 خيارًا آخر لتحديد أمر VRFY. هنا يحاول العميل إصدار أمر VRFY لمستخدم على كمبيوتر بعيد. تختلف الاستجابة المستلمة في السطر 11 من نظام shadrach عن النتيجة المستلمة في السطر 9. يناقش قسم استجابات الخادم معنى الرموز التي أرجعها الخادم بمزيد من التفاصيل. في حالتنا، لاحظ أن نظام shadrach يُعلم العميل بأنه سيتم إعادة توجيه البريد إلى المستخدم السابق على الخادم البعيد Meshach.smallorg.org. يُظهر السطر 12 محاولة للتحقق من اسم غير موجود في نظام الميشاخ. تعتبر استجابة خادم SMTP على السطر 13 واضحة بذاتها.

تحقق من وجود المستخدم باستخدام bash وcurl. $ صدى -e "VRFY [البريد الإلكتروني محمي]\n إنهاء" | حليقة telnet:// mail.example.com:25 220 mail.1-talk.com ESMTP Postfix 252 2.0.0 username@ example.com 221 2.0.0 وداعًا

فريق نوب

أمر NOOP قصير يعني عدم وجود عملية. ليس لهذا الأمر أي تأثير على خادم SMTP باستثناء أن الخادم يقوم بإرجاع رمز استجابة إيجابي إليه. يتم استخدامه عند اختبار الاتصال دون إعادة توجيه الرسالة.

أمر إنهاء

الأمر QUIT يفعل بالضبط ما يقوله، أي. يخبر خادم SMTP أن الكمبيوتر العميل قد أنهى جلسته الحالية ويريد إغلاق الاتصال. يجب أن يستجيب خادم SMTP لهذا الأمر ثم يبدأ اتصال TCP ويغلقه. إذا قبل الخادم الأمر QUIT أثناء إرسال البريد، فيجب تدمير جميع البيانات المرسلة أثناء الجلسة ولن تصل إلى المستلم.

تنسيق الرسالة (البريد الإلكتروني)

حقول الرأس القياسية وفقًا لـ RFC 822

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

تنسيق الرسالة وفقًا لـ RFC 822

حقل الرأس المستلم

تنسيق حقل الرأس المستلم: كما يلي:

تم الاستلام: من اسم المضيف حسب اسم المضيف عبر المسار الفعلي مع معرف الرسالة معرف البروتوكول لوجهة البريد الإلكتروني النهائية

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

حقل رأس مسار العودة

تنسيق حقل الرأس هذا هو كما يلي:

مسار العودة: الطريق

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

حقل رأس المنشئ

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

عنوان الرد

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

إعادة إرسال حقل الرأس

يحدد حقل رأس "إعادة الإرسال" رسالة بريد يجب إعادة إرسالها بواسطة العميل لسبب ما. ويكون شكل هذا الحقل كما يلي:

المرسل-الرد-إلى: العنوان

حقول رأس أصلية

تحدد بيانات حقل الرأس مرسل رسالة البريد الإلكتروني. تنسيق الحقول الأصيلة:

من: اسم المستخدم المرسل: اسم المستخدم

يحدد الحقل من: كاتب الرسالة. عادةً ما يكون الحقلان "من:" و"المرسل:" لنفس المستخدم، لذا يلزم وجود حقل واحد فقط من هذه الحقول. في الحالة التي يكون فيها مرسل البريد ليس مؤلف الرسالة، ولكن يتم إرسالها فقط من عنوانه، فلا يزال يتعين تحديد كلا الحقلين - وهذا يضمن إعادة الرسالة إلى المرسل إذا كان تسليمها إلى المرسل إليه مستحيلاً . حقول رأسية أصلية مستاءة

تحدد حقول مصادقة إعادة الإرسال مرسل الرسالة التي تم إعادة إرسالها بواسطة برنامج العميل لسبب ما. ويكون تنسيق هذه الحقول كما يلي:

المرسل من: التاريخ والوقت المرسل-المرسل: التاريخ-الوقت يعمل الحقلان المرسل إليه من: والمرسل المرسل: بشكل مشابه للحقول من: والمرسل:. إنها تعكس فقط أن الرسالة قد تم إعادة إرسالها بواسطة العميل لسبب غير معروف.

حقول رأس التواريخ

تُستخدم حقول رأس التواريخ لوضع طابع زمني على الرسالة عند إرسالها من العميل إلى الخادم. حقول التواريخ لها التنسيق التالي:

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

حقول رأس الوجهة

تشير حقول رأس الوجهة إلى عناوين البريد الإلكتروني لمستلمي الرسالة. هذه الحقول إعلامية بحتة. لن يقوم خادم SMTP بأي حال من الأحوال بإرسال رسالة إلى صندوق بريد المستخدم حتى يتلقى أمر RCPT الصادر لهذا المستخدم (راجع القسم "أوامر عميل SMTP الأساسية"). ويكون تنسيق هذه الحقول كما يلي:

إلى: العنوان المرسل-إلى: العنوان CC: العنوان المرسل-CC: العنوان BCC: العنوان المرسل-BCC: العنوان

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

حقول رأس اختيارية

الحقول الاختيارية هي الحقول التي تحدد الرسالة بمزيد من التفصيل لخادم SMTP، ولكن وفقًا لـ RFC 822، قد لا تكون موجودة في الرسالة. ومع ذلك، أصبحت هذه المجالات الآن منتشرة على نطاق واسع وسيتعين على الكثير منكم التعامل معها. وشكل بعضها كالتالي:

معرف الرسالة: معرف الرسالة معرف الرسالة المرسلة: معرف الرسالة في الرد على: معرف الرسالة المراجع: معرف الرسالة الكلمات الأساسية: نص - قائمة الموضوع: نص التعليقات: نص مشفر: كلمة

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

البيانات الثنائية وMIME

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

حقل رأس إصدار MIME

يحتوي أول حقول الرأس الاختيارية على إصدار MIME الذي استخدمه المرسل عند تشفير الرسالة. حاليًا هذا الحقل هو دائمًا 1.0.

مجال ترميز نقل المحتوى

يحدد حقل رأس Content-Transfer-Encoding كيفية تضمين البيانات الثنائية في رسالة نصية ASCII. توجد حاليًا سبع طرق مختلفة لتشفير البيانات الثنائية، ولكن تشفير Base64 هو الأكثر شيوعًا. تقوم طريقة الترميز هذه بتحويل كتل البيانات الثنائية ذات 6 بتات إلى كتل ذات 8 بتات تتم قراءتها كنص ASCII.

حقل معرف المحتوى

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

حقل وصف المحتوى

يتم استخدام حقل رأس وصف المحتوى لتوفير وصف نصي ASCII للبيانات المضمنة في رسالة البريد. يعد هذا مفيدًا عند إرسال المستندات التي تم إنشاؤها باستخدام معالج النصوص أو الرسومات التي لا تختلف إذا تم تشفيرها باستخدام base64.

حقل رأس نوع المحتوى

حقل رأس نوع المحتوى

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

يحدد نوع البيانات النصية بيانات ASCII التي يجب قراءتها في شكلها الأولي. هناك أيضًا فئتان فرعيتان هنا - نص عادي، أي. نص ASCII غير منسق، والنص المعزز، الذي يتضمن عناصر تنسيق مشابهة لتنسيق النص المعزز. يمكن لأحدث برامج البريد الإلكتروني التعامل مع Rich Text Format (RTF).

يسمح نوع بيانات الرسالة لبرنامج البريد الإلكتروني بإرسال رسائل بسيطة بتنسيق RFC 822، والفئات الفرعية من هذا النوع هي: rfc822، مما يشير إلى أن المرفق عبارة عن رسالة عادية تتوافق مع RFC 822؛ جزئي، والذي يسمح لك بتقسيم الرسائل الطويلة إلى أجزاء متعددة، ونص خارجي، والذي يسمح لك بوضع مؤشر على كائن ليس جزءًا من الرسالة.

يحدد نوع بيانات الصورة إرفاق البيانات الثنائية، التي تمثل صورة رسومية، بالرسالة. يوجد حاليًا فئتان فرعيتان محددتان لهذا النوع - jpeg وgif.

وبالتالي، يحدد نوع بيانات الفيديو أن البيانات المرفقة بالرسالة هي بيانات فيديو. يوجد حاليًا فئة فرعية واحدة محددة لهذا النوع، وهي تنسيق mpeg.

يشير نوع البيانات الصوتية إلى محتوى الرسالة كبيانات صوتية (ملفات صوتية). هنا أيضًا، تم تعريف فئة فرعية أساسية واحدة فقط حتى الآن، والتي تتوافق مع قناة ISDN واحدة بتردد أخذ عينات يبلغ 8 كيلو هرتز.

يتوافق نوع بيانات التطبيق مع البيانات الثنائية المرفقة برسالة تمثل تطبيقًا (على سبيل المثال، جداول بيانات Microsoft Excel أو المستندات التي تم إنشاؤها باستخدام معالج النصوص Microsoft Word). حتى الآن، تم تحديد فئتين فرعيتين من هذا النوع من البيانات - بوستسكريبت ودفق الثماني بتات. في كثير من الأحيان يتم استخدام الفئة الفرعية للتدفق الثماني عند إرفاق بيانات التطبيق برسالة، مثل مستندات Microsoft Word أو جداول بيانات Microsoft Excel.

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

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

1 $ telnet localhost 25 2 جاري تجربة 127.0.0.1... 3 متصل بالمضيف المحلي. 4 حرف الهروب هو "^]". 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; الاثنين، 30 أغسطس 1999 07:36:58 -050 6 HELO localhost 7 258 shadrach.smallorg.org مرحبًا مضيف محلي، يسرني مقابلتك 8 بريد من: rich@localhost 9 250 rich@localhost... المرسل موافق 10 RCPT إلى: غني 11 250 غني... المستلم موافق 12 البيانات 13 354 أدخل البريد، ينتهي بـ "." على سطر بمفرده 14 من: "Rich Blum" 15 إلى: "rich" 16 الموضوع: اختبار الرسائل النصية المنسقة 17 إصدار MIME: 1.0 18 نوع المحتوى: متعدد الأجزاء/بديل؛ الحدود = الحدود 1 19 20 – الحدود 1 21 نوع المحتوى: نص/عادي؛ charset=us-ascii 22 23 هذا هو الجزء النصي العادي من الرسالة الذي يمكن قراءته بواسطة قارئي البريد الإلكتروني البسيطين. 25 26 –-bounds1 27 نوع السياق: نص/مُثرى 28 29 هذا هو الإصدار النصي المنسق للرسالة نفسها. 30 31 –-حدود1-- 32 . 33 250 MAA04305 تم قبول الرسالة للتسليم 34 QUIT 35 221 shadrach.smallorg.org إغلاق الاتصال 36 تم إغلاق الاتصال بواسطة مضيف أجنبي. 37 لديك بريد جديد في /var/spool/mail/rich 38 $

القائمة 5.6. مثال لجلسة SMTP مع مرفقات MIME متعددة (html، txt) رسالة المثال الموضحة في القائمة 5.6 هي رسالة MIME تحتوي على جزأين. يوضح السطر 18 نوع بيانات الرسالة. يشير النوع متعدد الأجزاء/البديل إلى أن الرسالة تحتوي على أنواع مختلفة من البيانات مفصولة بمحدد الحدود 1. يبدأ النوع الأول من البيانات في السطر 21 وهو عبارة عن نص ASCII بسيط يمكن قراءته بواسطة أي برنامج بريد إلكتروني تقريبًا.

يبدأ النوع الثاني من البيانات في السطر 27 وهو عبارة عن نص منسق يستخدم تنسيق نص منسق.

نظرًا لأن نوع MIME المحدد للرسالة متعدد الأجزاء/بديل، فإن الأمر متروك تمامًا لبرنامج البريد الإلكتروني لتحديد إصدار المرفق الذي سيتم عرضه.

بروتوكول SMTP المحسن

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

في عام 1995، تم إصدار RFC 1869، والذي حدد طريقة لتوسيع إمكانيات بروتوكول SMTP، تسمى خدمات SMTP المحسنة.

يتم تطبيق SMTP الموسع على النحو التالي. في بداية جلسة SMTP، تم استبدال أمر HELO بأمر دعوة - ​​EHLO. عندما يتلقى خادم SMTP مثل هذا الأمر، فهذا يعني أنه يمكن للعميل إرسال أوامر SMTP الموسعة إليه. تعرض القائمة 5.7 جلسة نموذجية باستخدام EHLO بالإضافة إلى أوامر إضافية.

1 $ telnet localhost 25 2 جاري تجربة 127.0.0.1... 3 متصل بالمضيف المحلي. 4 حرف الهروب هو "^]". 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; الإثنين، 30 أغسطس 1999 16:36:48 -050 6 EHLO localhost 7 250-shadrach.smallorg.org مرحبًا المضيف المحلي، يسرني مقابلتك 8 250-EXPN 9 250-VERB 10 250-8BITMIME 11 250-SIZE 12 250-DSN 13 250-ONEX 14 250-ETRN 15 250-XUSR 16 250 HELP 17 HELP DSN 18 214-MAIL FROM: [ RET=( FULL || HDRS) ] [ ENVID= ] 19 214-RCPT إلى: [ NOTIFY=(أبدًا، نجاح، فشل، تأخير) ] 20 214- [ ORCPT= ] 21 214- إشعارات حالة تسليم SMTP. 22 214-الأوصاف: 23 214- RET إرجاع إما الرسالة الكاملة أو الرؤوس فقط. 24 214- "معرف مغلف" المرسل ENVID للتتبع. 25 214- إعلام متى يتم إرسال DSN. الخيارات المتعددة مقبولة، بفاصلة - 26 214- محددة. لا يجب أن تظهر بمفردها أبدًا. 27 214- ORCPT المستلم الأصلي. 28 214 نهاية معلومات HELP 29 HELP ETRN 30 214-ETRN [ | |. # ] 31 214- قم بتشغيل قائمة الانتظار المحددة، أو 32 214- جميع المضيفين ضمن 33 214- محددًا أو مسمى خصيصًا 34 214 نهاية معلومات المساعدة 35 إنهاء 36 221 shadrach.smallorg.org إغلاق الاتصال 37 الاتصال مغلق بواسطة مضيف أجنبي 38 دولارًا.

يحدد السطر 6 أمر SMTP EHLO للاتصال بخادم SMTP. تعرض الأسطر من 7 إلى 16 استجابة الخادم. لاحظ أن الخادم يشير إلى توفر المزيد من الأوامر للاستخدام، أي. تتم الجلسة في الوضع "الموسع". إحدى مجموعات الأوامر الجديدة تسمى معلمات إشعار حالة التسليم. يمكن استخدام هذه المعلمات مع أوامر MAIL وRCPT لعرض حالة تسليم رسالة بريد إلكتروني معينة. ومع ذلك، بالنسبة لنا كمسؤولين عن نظام البريد، فإن أمر ETRN هو الأكثر أهمية.

لقد سبق ذكر أمر TURN سابقًا. هذا الأمر فعال جدًا، لكنه للأسف غير آمن. للتعويض عن هذا النقص، يحدد RFC 1985 تطبيقًا جديدًا لأمر TURN الذي يوفر أمانًا أكبر. يسمح أمر ETRN لعميل SMTP بإصدار طلب إلى خادم SMTP لبدء اتصال SMTP آخر مع العميل لإرسال رسائل إليه. والفرق الوحيد بين الأمر ETRN والأمر TURN هو أن الطلب ليس لاستخدام اتصال موجود، ولكن لفتح جلسة SMTP جديدة. بهذه الطريقة، يمكن لخادم SMTP الاتصال بالكمبيوتر العميل باستخدام خوارزميات تحليل اسم DNS العادية. في هذه الحالة، لا يعتمد فتح اتصال جديد على الاسم الذي تم بموجبه تسجيل جهاز الكمبيوتر العميل على الخادم، ولكن على اسم المضيف الحقيقي للعميل. في هذه الحالة، إذا أنشأ أحد المتسللين اتصال SMTP غير مصرح به واستخدم أمر ETRN، فسيقوم خادم SMTP ببساطة بإنشاء اتصال جديد مع العميل الحقيقي وإعادة توجيه البريد الإلكتروني إليه. ونتيجة لذلك، لم تقع إصابات. تنسيق أمر ETRN كما يلي:

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

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

• التحقق من صحة الإعدادات ومنح الإذن للكمبيوتر الذي يحاول إرسال بريد إلكتروني؛
• إرسال رسالة صادرة إلى العنوان المحدد وتأكيد إرسال الرسالة بنجاح. إذا لم يكن التسليم ممكنًا، فسيقوم الخادم بإرجاع استجابة إلى المرسل مع وجود خطأ في الإرسال

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

• تحديد عنوان المرسل (MAILFROM)
• تحديد مستلم رسالة البريد الإلكتروني (RCPT TO)
• إرسال رسالة نصية (بيانات)

إن تحديد عنوان المرسل والمستلم ووجود محتويات الرسالة هي شروط إلزامية، وبدونها لن يتم إرسال الرسالة، حتى بالبريد "الورقي" العادي المألوف. ماذا يمكن أن نقول عن الإلكترونية؟

باختصار حول فوائد خادم SMTP

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

إذا كنت تخطط للقيام بالتسويق المشروع عبر البريد الإلكتروني، ففكر في استخدام خادم SMTP خارجي للأمان وسرعة إرسال حملات البريد الإلكتروني المجمعة.