وجّه Postfix إلى مرحّل بريد، لا إلى وكيل الويب

relayhost = proxy.example.net:3128 يبدو معقولاً حتى يبدأ الطرفان بالحديث. يتوقع Postfix نظيرًا عبر SMTP. أما وكيل الويب على 3128 فيتوقع طلب وكيل HTTP. فلا يحصل أي منهما على المحادثة التي كان ينتظرها.

إذا كانت الشبكة توفر مرحّل بريد معتمدًا، فاضبط خدمة SMTP تلك بدلاً منه. الشكل المعتاد هو:

relayhost = [smtp-relay.example.net]:587

اسم المضيف والمنفذ مجرد مثالين. الأقواس المعقوفة تمنع البحث عن سجل MX لاسم المرحّل ذلك. وهي لا تضيف HTTP CONNECT ولا TLS ولا المصادقة. اضبط إعدادات الإرسال وSASL وTLS التي يتطلبها المرحّل بشكل منفصل.

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

ماذا لو كان المسار المعتمد الوحيد نفقًا؟

يمكن لوكيل HTTP نقل SMTP عبر CONNECT عندما يسمح بالوجهة والمنفذ. لكن ذلك لا يجعل أي عميل SMTP يولّد CONNECT. فأداة مثل curl لديها خيار صريح لنفق الوكيل؛ أما ضبط relayhost في Postfix فهو واجهة مختلفة.

يمكن لتحويل SSH ثابت أو محوّل نقل محلي مخصص أن يعرض خدمة SMTP معتمدة واحدة كنقطة نهاية TCP محلية. في هذا التصميم يتحدث Postfix بـ SMTP إلى نقطة النهاية، ويوفر المحوّل النقل الآخر. أبقِه مقيّدًا وحافظ على هوية TLS لخادم البريد المقصود: فتغيير عنوان الاتصال إلى loopback قد يؤثر على سياسة الشهادات القائمة على الاسم.

فضّل مرحّل البريد عندما تكون هذه هي الخدمة التي يوفرها مشغّل الشبكة. فهو يمنح الانتظار في القائمة وسياسة المرسل وأخطاء التسليم موطنًا واعيًا بـ SMTP. أما إعداد وكيل الويب وحده فلا يوفر أيًا من وظائف البريد تلك.