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. Само поставката на веб-прокси не обезбедува ниту една од тие поштенски функции.

Поврзани статии