Peka Postfix mot en mailrelay, inte mot webbproxyn

relayhost = proxy.example.net:3128 verkar rimligt tills de två ändarna börjar prata. Postfix väntar sig en SMTP-motpart. En webbproxy på 3128 väntar sig en HTTP-proxybegäran. Ingen av dem får det samtal de väntade på.

Om nätverket tillhandahåller en godkänd mailrelay konfigurerar du den SMTP-tjänsten i stället. En typisk form är:

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

Värdnamnet och porten är exempel. Hakparenteserna undertrycker MX-sökning för det relaynamnet. De lägger inte till HTTP CONNECT, TLS eller autentisering. Konfigurera relayens nödvändiga submission-, SASL- och TLS-inställningar separat.

De två kontona kan också skilja sig. Ett lösenord som webbproxyn accepterar är inte automatiskt en inloggningsuppgift för mailutskick, och relayen kan fortfarande avvisa en avsändare efter att ha accepterat anslutningen.

Tänk om den enda godkända vägen är en tunnel?

En HTTP-proxy kan bära SMTP via CONNECT när den tillåter målet och porten. Det får inte en godtycklig SMTP-klient att generera CONNECT. Ett verktyg som curl har ett uttryckligt proxy-tunnelval; att ställa in Postfix relayhost är ett annat gränssnitt.

En fast SSH-vidarebefordran eller en specialbyggd lokal transportadapter kan exponera en godkänd SMTP-tjänst som en lokal TCP-slutpunkt. I den konstruktionen talar Postfix SMTP med slutpunkten och adaptern tillhandahåller den andra transporten. Håll den begränsad och bevara den avsedda mailserverns TLS-identitet: att ändra anslutningsadressen till loopback kan påverka namnbaserad certifikatpolicy.

Föredra mailrelayen när det är tjänsten som nätoperatören tillhandahåller. Den ger kö, avsändarpolicy och leveransfel ett SMTP-förstående hem. En webbproxyinställning ensam ger ingen av dessa mailfunktioner.