حتى مجرد إلقاء نظرة سريعة على بروتوكول SMTP سوف تلاحظ أنه إلى جانب HELO المعتاد ، هناك أيضًا EHLO ، مما يجعل وسعوا خادم SMTP الإعلان عن قدراته خارج المعيار الأصلي. واحد من هؤلاء هو DSN. DSN؟ هل الحمض النووي والـ دي. دي. تي غير كاف؟
القول بأن البريد الإلكتروني غير موثوق به ، يجب على شخص ما " … إطعام خادمهم بشكل أفضل. أكلت بريدي … "ليس من غير المألوف. ومع ذلك ، ليس هناك سبب كبير لدعم هذه الشكوك.
توصيل S tatus N تم otification حول RFC 821 (من 1982). بمجرد الانتهاء من جزء DATA من بروتوكول SMTP وقد قبل الخادم البريد الإلكتروني للتسليم ، فهو مسؤول عن ذلك. إذا لم تستطع الوصول إلى المستلم لأي سبب من الأسباب ، فيجب إرسالها مرة أخرى مع إخطار الخطأ إلى المرسل الأصلي. هذا أدى إلى بعض البريد الإلكتروني الغامض.
وبصرف النظر عن هذا ، تعني هذه الاتفاقية القديمة إما أنك حصلت على رسالة خطأ أو لديك لا شيئ في هذه الحالة كنت على علم لا شيئ : ربما وصل البريد الإلكتروني أو ربما لا. كانت رسائل الخطأ في العديد من الحالات مفيدة تمامًا مثل عدم وجود رسائل خطأ. مع زيادة أهمية البريد الإلكتروني ، لم يعد هذا الأمر مرضياً (كما لو كان من قبل).
ملحقات DSN إلى SMTP
يقترح RFC 1891 بعض ملحقات بروتوكول SMTP التي يجب أن ينتج نظام DSN أكثر موثوقية وأكثر استخداماً. وهو عبارة عن مجموعة من الملحقات لأوامر MAIL و RCPT.
لا EHLO ، لا المرح
أولاً ، علينا التأكد من أن الخادم يدعم DSN. وبالتالي ، يجب علينا أن نقول EHLO له والاستماع بعناية. إذا كان الرد مع DSN في مكان ما في قائمة الميزات يمكننا افتراض أنه سيكون قادراً على تلبية طلباتنا. إذا لم يكن كذلك ، فلا: يمكننا تجربة خادم آخر أو ببساطة العودة إلى البريد الإلكتروني دون DSN. فمثلا:
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6؛ Sun، 24 Aug 1997 18:23:22 +0200EHLO المضيف المحلي250-larose.magnet.at مرحبا localhost 127.0.0.1 ، سعدت بلقائك250 EXPN250 VERB250-8BITMIME250-SIZE250 DSN250 ONEX250-ETRN250 XUSR250 مساعدة لحسن الحظ ، من بين أمور أخرى نجد DSN. الأمر التالي عادةً هو MAIL FROM. مع DSN ، وهذا لا يختلف. ولكن هناك خياران إضافيان قد تصدرهما: RET و ENVID. تم وضع الخيار RET بشكل تعسفي في الأمر MAIL ، ولكنه يناسب هنا وكذلك في أي مكان آخر. والغرض من ذلك هو تحديد مقدار الرسالة الأصلية التي يجب إرسالها في حالة فشل التسليم. الوسيطات الصحيحة هي FULL و HDRS. يعني السابق أن الرسالة الكاملة يجب أن يتم تضمينها في رسالة الخطأ ، حيث يقوم HDRS بإرشاد الخادم لإرجاع رؤوس البريد الفاشلة فقط. إذا لم يتم تحديد RET ، فالأمر متروك للخادم ما يجب القيام به. في معظم الحالات ، تكون HDRS هي القيمة الافتراضية. تنتمي ENVID حقًا إلى المرسل لأنها أو (بالأحرى) عميل بريدها الإلكتروني سيكون الوحيد الذي يستخدم هذا معرف المغلف . الغرض منه هو إخبار المرسل بالبريد الإلكتروني الذي تتطابق معه رسالة الخطأ المحتمل. يتم ترك تنسيق هذا المعرف في الأساس إلى خيال المرسل. لن نستخدم ENVID في مثالنا: البريد من: [email protected] RET = HDRS250 [email protected] … المرسل حسنًا على ما يبدو ، لا نريد سوى إرجاع العناوين في DSN. RCPT TO: تحصل على نصيبها العادل من الإضافات أيضًا: NOTIFY و ORCPT. NOTIFY هو القلب الحقيقي لـ DSN. يخبر الخادم متى لإرسال إشعار حالة التسليم. أول قيمة ممكنة هي NEVER مما يعني أنه في أي حال من الأحوال يجب إعادة DSN إلى المرسل. هذا لم يكن ممكنا دون DSN. ثم هناك SUCCESS ، والتي سوف يخطرك عندما وصل بريدك إلى وجهتها. الفشل هو نظير النجاح: سوف تصل DSN إذا حدث خطأ أثناء التسليم. الخيار الأخير هو DELAY: سيتم إشعارك إذا كان هناك تأخير غير معتاد في التسليم ، ولكن لم يتم بعد تحديد نتيجة التسليم الفعلي (النجاح أو الفشل). أبدا يجب تكون الحجة الوحيدة إذا تم تحديدها ، قد تظهر الثلاثة الأخرى في قائمة ، مفصولة بفاصلة. النجاح والفشل يعوضان عن فريق قوي جدا معا ، ويقول لك في (تقريبا) أي حالة ما حدث لبريدك. الغرض من ORCPT هو الحفاظ على أصلي مستلم رسالة بريد إلكتروني ، على سبيل المثال ، إذا تمت إعادة توجيهها إلى عنوان آخر. الوسيطة لهذا الخيار هي عنوان البريد الإلكتروني للمستلم الأصلي مع نوع العنوان. يأتي نوع العنوان أولاً ، متبوعًا بفاصلة منقوطة وأخيرًا العنوان. فمثلا: RCPT TO: [email protected] NOTIFY = FAILURE، DELAY ORCPT = rfc822؛ [email protected]250 [email protected] … مستلم موافق (سوف يقف في الصف) يلي ذلك بيانات DATA كما نعرفها ، ونأمل في النهاية ، إعلام حالة التسليم بإعلامك بالنجاح. بالطبع ، كل هذا الجمال وسوف يعمل فقط إذا كان وكلاء نقل البريد من المرسل إلى المستلم يدعم DSN. يوما ما سوف يفعلون. ملحقات DSN المرسل
ملحقات المستلم DSN
هل يعمل DSN؟
