A Postfixet levélrelére irányítsa, ne a webproxyra

relayhost = proxy.example.net:3128 hihetőnek tűnik, amíg a két fél el nem kezd beszélgetni. A Postfix SMTP-partnert vár. A 3128-as webproxy HTTP-proxykérést vár. Egyik sem kapja meg a várt beszélgetést.

Ha a hálózat jóváhagyott levélrelét biztosít, inkább azt az SMTP-szolgáltatást állítsa be. A szokásos forma:

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

A gépnév és a port példák. A szögletes zárójelek elnyomják az MX-keresést ehhez a relé névhez. Nem adnak hozzá HTTP CONNECT-et, TLS-t vagy hitelesítést. A relé által megkövetelt submission, SASL és TLS beállításokat külön állítsa be.

A két fiók is különbözhet. A webproxy által elfogadott jelszó nem automatikusan levélküldési hitelesítő adat, és a relé a kapcsolat elfogadása után is elutasíthatja a feladót.

Mi van, ha az egyetlen jóváhagyott útvonal egy alagút?

Egy HTTP-proxy továbbíthat SMTP-t CONNECT-en keresztül, ha engedélyezi a célt és a portot. Ez nem késztet tetszőleges SMTP-klienst CONNECT létrehozására. Egy curlhez hasonló eszköznek külön proxyalagút-opciója van; a Postfix relayhost beállítása más felület.

Egy rögzített SSH-továbbítás vagy egy célra készített helyi átviteli adapter egy jóváhagyott SMTP-szolgáltatást helyi TCP-végpontként tehet elérhetővé. Ebben a kialakításban a Postfix SMTP-ben beszél a végponttal, az adapter pedig a másik átvitelt biztosítja. Tartsa korlátozottan, és őrizze meg a tervezett levelezőszerver TLS-azonosságát: a kapcsolati cím loopbackre változtatása befolyásolhatja a névalapú tanúsítvány-szabályzatot.

Ha a hálózat üzemeltetője levélrelét biztosít, azt részesítse előnyben. Ez a várakozási sor, a feladószabályzat és a kézbesítési hibák számára SMTP-t értő otthont ad. Önmagában a webproxy-beállítás e levélfunkciók egyikét sem nyújtja.