Pointez Postfix vers un relais de messagerie, pas vers le proxy web

relayhost = proxy.example.net:3128 semble plausible jusqu'à ce que les deux extrémités commencent à parler. Postfix attend un pair SMTP. Un proxy web sur 3128 attend une requête de proxy HTTP. Aucun ne reçoit la conversation qu'il attendait.

Si le réseau fournit un relais de messagerie approuvé, configurez ce service SMTP à la place. Une forme typique est :

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

Le nom d'hôte et le port sont des exemples. Les crochets suppriment la recherche MX pour ce nom de relais. Ils n'ajoutent ni HTTP CONNECT, ni TLS, ni authentification. Configurez séparément les paramètres submission, SASL et TLS exigés par le relais.

Les deux comptes peuvent aussi être différents. Un mot de passe accepté par le proxy web n'est pas automatiquement un identifiant de soumission de courrier, et le relais peut encore rejeter un expéditeur après avoir accepté la connexion.

Et si le seul chemin approuvé est un tunnel ?

Un proxy HTTP peut transporter du SMTP via CONNECT lorsqu'il autorise la destination et le port. Cela ne fait pas générer CONNECT à un client SMTP quelconque. Un outil comme curl dispose d'une option explicite de tunnel proxy ; définir le relayhost de Postfix est une autre interface.

Une redirection SSH fixe ou un adaptateur de transport local dédié peut exposer un service SMTP approuvé comme point de terminaison TCP local. Dans ce schéma, Postfix parle SMTP au point de terminaison et l'adaptateur fournit l'autre transport. Gardez-le restreint et préservez l'identité TLS du serveur de messagerie prévu : changer l'adresse de connexion en loopback peut affecter la politique de certificats basée sur le nom.

Préférez le relais de messagerie lorsque c'est le service fourni par l'opérateur réseau. Il donne à la file d'attente, à la politique d'expéditeur et aux erreurs de remise un foyer qui comprend SMTP. Un réglage de proxy web seul ne fournit aucune de ces fonctions de messagerie.