Wijs Postfix naar een mailrelay, niet naar de webproxy

relayhost = proxy.example.net:3128 lijkt plausibel tot beide kanten beginnen te praten. Postfix verwacht een SMTP-tegenpartij. Een webproxy op 3128 verwacht een HTTP-proxyverzoek. Geen van beide krijgt het gesprek waarop het wachtte.

Als het netwerk een goedgekeurde mailrelay biedt, configureer dan die SMTP-dienst in plaats daarvan. Een typische vorm is:

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

De hostnaam en poort zijn voorbeelden. Vierkante haken onderdrukken de MX-lookup voor die relaynaam. Ze voegen geen HTTP CONNECT, TLS of authenticatie toe. Configureer de vereiste submission-, SASL- en TLS-instellingen van de relay apart.

De twee accounts kunnen ook verschillen. Een wachtwoord dat de webproxy accepteert is niet automatisch een inloggegeven voor mailverzending, en de relay kan een afzender alsnog weigeren nadat de verbinding is geaccepteerd.

Wat als het enige goedgekeurde pad een tunnel is?

Een HTTP-proxy kan SMTP via CONNECT dragen wanneer hij de bestemming en poort toestaat. Dat zorgt er niet voor dat een willekeurige SMTP-client CONNECT genereert. Een hulpmiddel als curl heeft een expliciete proxy-tunneloptie; de relayhost van Postfix instellen is een andere interface.

Een vaste SSH-doorsturing of een speciaal gebouwde lokale transportadapter kan één goedgekeurde SMTP-dienst als lokaal TCP-eindpunt aanbieden. In dat ontwerp spreekt Postfix SMTP met het eindpunt en levert de adapter het andere transport. Houd het beperkt en behoud de TLS-identiteit van de beoogde mailserver: het verbindingsadres naar loopback wijzigen kan naamgebaseerd certificaatbeleid beïnvloeden.

Geef de voorkeur aan de mailrelay wanneer dat de dienst is die de netwerkbeheerder levert. Die geeft wachtrij, afzenderbeleid en bezorgfouten een SMTP-begrijpende thuisbasis. Alleen een webproxy-instelling levert geen van die mailfuncties.