Pek Postfix mot ein e-postrelay, ikkje mot nettproxyen

relayhost = proxy.example.net:3128 ser rimeleg ut heilt til dei to endane byrjar å snakke saman. Postfix ventar på ein SMTP-motpart. Ein nettproxy på 3128 ventar på ein HTTP-proxyførespurnad. Ingen av dei får samtalen dei venta på.

Viss nettet tilbyr ein godkjend e-postrelay, konfigurerer du den SMTP-tenesta i staden. Ei typisk form er:

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

Vertsnamnet og porten er døme. Klammeparentesane undertrykkjer MX-oppslag for det relaynamnet. Dei legg ikkje til HTTP CONNECT, TLS eller autentisering. Konfigurer dei påkravde submission-, SASL- og TLS-innstillingane til relayen separat.

Dei to kontoane kan også vere ulike. Eit passord som nettproxyen godtek, er ikkje automatisk ein legitimasjon for e-postinnsending, og relayen kan framleis avvise ein avsendar etter å ha godteke tilkoplinga.

Kva om den einaste godkjende vegen er ein tunnel?

Ein HTTP-proxy kan bera SMTP gjennom CONNECT når han tillèt målet og porten. Det får ikkje ein vilkårleg SMTP-klient til å generere CONNECT. Eit verktøy som curl har eit eksplisitt proxy-tunnelval; å setje relayhost i Postfix er eit anna grensesnitt.

Ei fast SSH-vidaresending eller ein spesialbygd lokal transportadapter kan eksponere éi godkjend SMTP-teneste som eit lokalt TCP-endepunkt. I det designet snakkar Postfix SMTP med endepunktet, og adapteren leverer den andre transporten. Hald han avgrensa, og ta vare på TLS-identiteten til den tiltenkte e-posttenaren: å endre tilkoplingsadressa til loopback kan påverke namnebasert sertifikatpolitikk.

Føretrekk e-postrelayen når det er tenesta nettoperatøren tilbyr. Han gir kø, avsendarpolitikk og leveringsfeil eit SMTP-forståande heim. Ei nettproxyinnstilling åleine gir ingen av desse e-postfunksjonane.