Postfix را به یک رلهٔ ایمیل وصل کنید، نه به پروکسی وب

relayhost = proxy.example.net:3128 منطقی به نظر می‌رسد تا وقتی دو طرف شروع به گفتگو کنند. Postfix انتظار یک همتای SMTP دارد. یک پروکسی وب روی 3128 انتظار درخواست پروکسی HTTP دارد. هیچ‌کدام گفتگویی را که منتظرش بودند دریافت نمی‌کنند.

اگر شبکه یک رلهٔ ایمیل تأییدشده فراهم می‌کند، به‌جای آن همان سرویس SMTP را پیکربندی کنید. شکل معمول چنین است:

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

نام میزبان و پورت نمونه‌اند. کروشه‌ها جست‌وجوی MX را برای آن نام رله سرکوب می‌کنند. آن‌ها HTTP CONNECT، TLS یا احراز هویت را اضافه نمی‌کنند. تنظیمات submission، SASL و TLS موردنیاز رله را جداگانه پیکربندی کنید.

دو حساب نیز می‌توانند متفاوت باشند. رمز عبوری که پروکسی وب می‌پذیرد به‌طور خودکار اعتبارنامهٔ ارسال ایمیل نیست، و رله می‌تواند پس از پذیرش اتصال هم فرستنده را رد کند.

اگر تنها مسیر تأییدشده یک تونل باشد چه؟

یک پروکسی HTTP می‌تواند SMTP را از طریق CONNECT حمل کند، وقتی مقصد و پورت را مجاز بداند. این باعث نمی‌شود هر کلاینت SMTP دلخواهی CONNECT تولید کند. ابزاری مانند curl گزینهٔ صریح تونل پروکسی دارد؛ تنظیم relayhost در Postfix رابط دیگری است.

یک هدایت ثابت SSH یا یک آداپتور انتقال محلی هدفمند می‌تواند یک سرویس SMTP تأییدشده را به‌عنوان نقطهٔ پایانی TCP محلی در معرض دید قرار دهد. در این طراحی Postfix با نقطهٔ پایانی SMTP صحبت می‌کند و آداپتور انتقال دیگر را تأمین می‌کند. آن را محدود نگه دارید و هویت TLS سرور ایمیل موردنظر را حفظ کنید: تغییر نشانی اتصال به loopback می‌تواند سیاست گواهی مبتنی بر نام را تحت تأثیر قرار دهد.

وقتی سرویسی که اپراتور شبکه فراهم می‌کند رلهٔ ایمیل است، همان را ترجیح دهید. این رله به صف، سیاست فرستنده و خطاهای تحویل خانه‌ای می‌دهد که SMTP را می‌فهمد. تنظیم پروکسی وب به‌تنهایی هیچ‌یک از این کارکردهای ایمیل را فراهم نمی‌کند.