Наладзьце 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-арыентаванае месца. Адна толькі наладка веб-праксі не забяспечвае ніводнай з гэтых паштовых функцый.