Direktu Postfix al retpoŝta relajso, ne al la reta prokuro

relayhost = proxy.example.net:3128 ŝajnas kredebla ĝis la du flankoj komencas paroli. Postfix atendas SMTP-partneron. Reta prokuro sur 3128 atendas HTTP-prokuran peton. Neniu ricevas la konversacion, kiun ĝi atendis.

Se la reto provizas aprobitan retpoŝtan relajson, agordu tiun SMTP-servon anstataŭe. Tipa formo estas:

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

La gastignomo kaj la pordo estas ekzemploj. Krampoj subpremas la MX-serĉon por tiu relajsa nomo. Ili ne aldonas HTTP CONNECT, TLS aŭ aŭtentikigon. Agordu la postulatajn submission, SASL kaj TLS-agordojn de la relajso aparte.

La du kontoj ankaŭ povas malsami. Pasvorto akceptita de la reta prokuro ne aŭtomate estas retpoŝta submission-identigilo, kaj la relajso povas malakcepti sendanton eĉ post akcepti la konekton.

Kio se la sola aprobita vojo estas tunelo?

Reta prokuro povas porti SMTP per CONNECT kiam ĝi permesas la celon kaj la pordon. Tio ne igas arbitran SMTP-klienton krei CONNECT. Ilo kiel curl havas eksplicitan prokuran tunel-agordon; agordi la relayhost de Postfix estas alia interfaco.

Fiksa SSH-plusendo aŭ celkonstruita loka transporta adaptilo povas elmeti unu aprobitan SMTP-servon kiel lokan TCP-finpunkton. En tiu dezajno Postfix parolas SMTP kun la finpunkto, kaj la adaptilo provizas la alian transporton. Tenu ĝin limigita kaj konservu la TLS-identecon de la celata retpoŝta servilo: ŝanĝi la konektan adreson al loopback povas influi nom-bazitan atestilan politikon.

Prefere uzu la retpoŝtan relajson kiam tio estas la servo, kiun provizas la reta operatoro. Ĝi donas al atendovico, sendanta politiko kaj liveraj eraroj SMTP-komprenan hejmon. Nur reta prokura agordo provizas neniun el tiuj retpoŝtaj funkcioj.