Pek Postfix mot en e-postrelay, ikke mot nettproxyen

relayhost = proxy.example.net:3128 ser rimelig ut helt til de to endene begynner å snakke sammen. Postfix forventer en SMTP-motpart. En nettproxy på 3128 forventer en HTTP-proxyforespørsel. Ingen av dem får samtalen de ventet på.

Hvis nettverket tilbyr en godkjent e-postrelay, konfigurerer du den SMTP-tjenesten i stedet. En typisk form er:

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

Vertsnavnet og porten er eksempler. Klammeparentesene undertrykker MX-oppslag for det relaynavnet. De legger ikke til HTTP CONNECT, TLS eller autentisering. Konfigurer relayens påkrevde submission-, SASL- og TLS-innstillinger separat.

De to kontoene kan også være forskjellige. Et passord som nettproxyen godtar, er ikke automatisk en legitimasjon for e-postinnsending, og relayen kan fortsatt avvise en avsender etter å ha godtatt tilkoblingen.

Hva om den eneste godkjente veien er en tunnel?

En HTTP-proxy kan bære SMTP gjennom CONNECT når den tillater målet og porten. Det får ikke en vilkårlig SMTP-klient til å generere CONNECT. Et verktøy som curl har et eksplisitt proxy-tunnelvalg; å sette Postfix' relayhost er et annet grensesnitt.

En fast SSH-videresending eller en spesialbygd lokal transportadapter kan eksponere én godkjent SMTP-tjeneste som et lokalt TCP-endepunkt. I det designet snakker Postfix SMTP med endepunktet, og adapteren leverer den andre transporten. Hold den begrenset, og bevar den tiltenkte e-postserverens TLS-identitet: å endre tilkoblingsadressen til loopback kan påvirke navnebasert sertifikatpolicy.

Foretrekk e-postrelayen når det er tjenesten nettoperatøren tilbyr. Den gir kø, avsenderpolicy og leveringsfeil et SMTP-forstående hjem. En nettproxyinnstilling alene gir ingen av disse e-postfunksjonene.