Postfix auf ein Mail-Relay zeigen lassen, nicht auf den Webproxy

relayhost = proxy.example.net:3128 klingt plausibel, bis beide Seiten zu sprechen beginnen. Postfix erwartet einen SMTP-Peer. Ein Webproxy auf 3128 erwartet eine HTTP-Proxy-Anfrage. Keiner bekommt das Gespräch, auf das er gewartet hat.

Stellt das Netzwerk ein genehmigtes Mail-Relay bereit, konfigurieren Sie stattdessen diesen SMTP-Dienst. Eine typische Form ist:

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

Hostname und Port sind Beispiele. Die Klammern unterdrücken die MX-Suche für diesen Relaynamen. Sie fügen weder HTTP CONNECT noch TLS oder Authentifizierung hinzu. Konfigurieren Sie die vom Relay geforderten Submission-, SASL- und TLS-Einstellungen getrennt.

Die beiden Konten können sich ebenfalls unterscheiden. Ein vom Webproxy akzeptiertes Passwort ist nicht automatisch ein Anmeldedatum für Mail-Submission, und das Relay kann einen Absender auch nach Annahme der Verbindung noch ablehnen.

Was, wenn der einzige genehmigte Weg ein Tunnel ist?

Ein HTTP-Proxy kann SMTP über CONNECT tragen, wenn er Ziel und Port erlaubt. Das veranlasst aber keinen beliebigen SMTP-Client, CONNECT zu erzeugen. Ein Werkzeug wie curl hat eine ausdrückliche Proxy-Tunnel-Option; relayhost in Postfix zu setzen ist eine andere Schnittstelle.

Eine feste SSH-Weiterleitung oder ein eigens gebauter lokaler Transportadapter kann einen genehmigten SMTP-Dienst als lokalen TCP-Endpunkt bereitstellen. In diesem Entwurf spricht Postfix SMTP mit dem Endpunkt, und der Adapter liefert den anderen Transport. Halten Sie ihn beschränkt und wahren Sie die TLS-Identität des vorgesehenen Mailservers: Ändert man die Verbindungsadresse auf loopback, kann das die namensbasierte Zertifikatrichtlinie beeinflussen.

Bevorzugen Sie das Mail-Relay, wenn es der Dienst ist, den der Netzbetreiber bereitstellt. Es gibt Warteschlange, Absenderrichtlinie und Zustellfehlern ein SMTP-kundiges Zuhause. Eine reine Webproxy-Einstellung liefert keine dieser Mailfunktionen.