هل يجب على عميل SMTP تزويد MTA باسم مضيف قابل للحل عالميًا في HELO؟[مغلق]

Question

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

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

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

بعد ذلك قمت بفحص طلبات RFC - يقول RFC 821 "قد يتحقق مستقبل HELO من أن معلمة HELO تتوافق بالفعل مع عنوان IP الخاص بالمرسل.ومع ذلك، يجب ألا يرفض المتلقي قبول الرسالة، حتى لو فشل أمر HELO الخاص بالمرسل في التحقق." مما يوحي لي بأنني في الواقع الشخص الذي ينتهك RFC.

هل تم استبدال هذا الجزء من RFC 821 بـ RFC مستقبلي يمكنني الإشارة إليه؟أو هل يجب على خوادم البريد قبول البريد الذي يحتوي على HELOs الزائفة؟هل هناك أي سلطات محترمة يمكنني الإشارة إليها والتي تنص على أن اسم مضيف HELO يجب أن يكون صالحًا، كمرجع للاتصال بمسؤول البريد الخاص بهم؟

Answer 1

لا تتطلب طلبات SMTP RFC ذلك، لكن الكثير من الأنظمة الشائعة سترفض البريد الذي يحتوي على HELOs الزائفة.لاحظ أن كلاً من RFC 1033 وRFC 1912 يتطلبان أن يكون لجميع المضيفين الذين يمكن الوصول إليهم عبر الإنترنت اسم صالح؛سيؤدي مجرد إدراج هذا الاسم في HELO إلى حل العديد من المشكلات.لسوء الحظ، ترفض بعض عوامل تصفية البريد العشوائي أيضًا البريد من أسماء المضيفين التي تحتوي على سلاسل تشير ضمنًا إلى وجودها في مجموعات عناوين ديناميكية (على سبيل المثال."ديناميكي" أو "dsl" أو عنوان IP مفصول بشرطة كما هو شائع لدى العديد من مزودي خدمات الإنترنت).

أحد الخيارات إذا لم يكن لدى صديقك التحكم في DNS العكسي الخاص به هو استخدام جهاز مناسب كمضيف ذكي للبريد الصادر؛على سبيل المثالخادم البريد الخاص بمزود خدمة الإنترنت (ISP) الخاص بهم.

Answer 2

بدقة، أنت كلاهما انتهاك RFC.

أقسام المذكرة هي:

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

و

قد يتحقق مستقبل HELO من أن معلمة HELO تتوافق بالفعل مع عنوان IP الخاص بالمرسل.ومع ذلك، يجب ألا يرفض المتلقي قبول الرسالة، حتى لو فشل أمر HELO الخاص بالمرسل في التحقق.

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

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

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

Answer 3

كما ذكرت، فإن معيار RFC 822 يترك السلوك لـ MTA.في هذه الأيام، يعد رفض الاتصالات في مرحلة HELO إذا تعذر حل الاسم (والتحقق منه مقابل قائمة سوداء مثل البريد العشوائي) هو الطريقة الوحيدة لـ MTAs لمواكبة طوفان البريد العشوائي الناتج عن شبكات الروبوت.

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

Answer 4

نعم يجب عليهم.سترفض الكثير من الأنظمة الأخرى، بما في ذلك ياهو، البريد من أسماء المضيفين التي لا يمكنها عكس تعيينها إلى عنوان IP المتصل، أو التي لا يمكنها حلها.

Answer 5

إيه، أنا لا أوافق.يمكنه توفير القمامة الكاملة داخل EHLO/HELO إذا أراد ذلك.طالما أنه يقول شيئا، و طالما أستطيع حل عنوان IP الذي يأتي منه، فأنا سعيد.

غالبًا ما يوجد داخل EHLO اسم مضيف قصير، وليس FQDN.