Puntate Postfix a un relay di posta, non al proxy web

relayhost = proxy.example.net:3128 sembra plausibile finché i due estremi non iniziano a parlare. Postfix si aspetta un peer SMTP. Un proxy web sulla 3128 si aspetta una richiesta di proxy HTTP. Nessuno dei due riceve la conversazione che attendeva.

Se la rete fornisce un relay di posta approvato, configurate invece quel servizio SMTP. Una forma tipica è:

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

Il nome host e la porta sono esempi. Le parentesi quadre sopprimono la ricerca MX per quel nome di relay. Non aggiungono HTTP CONNECT, TLS o autenticazione. Configurate separatamente le impostazioni submission, SASL e TLS richieste dal relay.

Anche i due account possono essere diversi. Una password accettata dal proxy web non è automaticamente una credenziale di invio della posta, e il relay può comunque rifiutare un mittente dopo aver accettato la connessione.

E se l'unico percorso approvato è un tunnel?

Un proxy HTTP può trasportare SMTP tramite CONNECT quando consente la destinazione e la porta. Questo non fa generare CONNECT a un client SMTP qualsiasi. Uno strumento come curl ha un'opzione esplicita di tunnel proxy; impostare il relayhost di Postfix è un'altra interfaccia.

Un inoltro SSH fisso o un adattatore di trasporto locale appositamente realizzato possono esporre un servizio SMTP approvato come endpoint TCP locale. In quel progetto Postfix parla SMTP con l'endpoint e l'adattatore fornisce l'altro trasporto. Mantenetelo limitato e preservate l'identità TLS del server di posta previsto: cambiare l'indirizzo di connessione in loopback può influire sulla policy dei certificati basata sul nome.

Preferite il relay di posta quando è il servizio fornito dall'operatore di rete. Dà alla coda, alla policy del mittente e agli errori di consegna una casa che capisce SMTP. La sola impostazione del proxy web non fornisce nessuna di queste funzioni di posta.