Postfix « Relay access denied » : corriger le relais sans créer un relais ouvert

octobre 21, 2025 • février 3, 2026 • Lecture : 26 min • Views: 10

Cet article vous a aidé ?

Ça arrive toujours au pire moment : votre application tente d’envoyer un email de réinitialisation de mot de passe, et Postfix répond Relay access denied. Les développeurs disent : « Mais ça marche sur mon portable. » Votre supervision indique que la file augmente. Votre boîte de réception montre que le métier est en colère.

La solution n’est généralement pas « activer le relais ». La solution est « activer le relais pour les bonnes choses ». Postfix fait son travail : refuser d’être utilisé comme canon à spam. Votre travail est de lui expliquer qui peut relayer, dans quelles conditions, avec le moins d’ambiguïté possible.

Ce que signifie réellement « Relay access denied »

« Relay access denied » veut dire que Postfix déclare : « J’ai reçu un message d’un client, mais je ne suis pas disposé à le transférer vers cette destination selon la politique actuelle. » C’est un échec de politique, pas un échec de connectivité. Le serveur peut accepter la conversation SMTP, mais il refuse d’agir comme intermédiaire.

Cela apparaît généralement sous une de ces formes :

Pendant RCPT TO : 554 5.7.1 <user@remote.tld>: Relay access denied (classique)
Dans les logs Postfix : NOQUEUE: reject: RCPT from ...: 554 5.7.1 ... Relay access denied; from=<...> to=<...>
Trace de pile d’une application : « SMTP 554 Relay access denied »

Postfix décide s’il doit relayer en se basant sur quelques concepts :

Domaines destinataires locaux : choses que ce serveur livre localement (via mydestination et virtual_mailbox_domains).
Domaines relay : choses pour lesquelles ce serveur accepte de relayer (via relay_domains).
Confiance du client : réseaux ou identités autorisés à relayer (via mynetworks, authentification SASL, certificats client TLS, etc.).
Restrictions sur le destinataire : la chaîne de règles qui décide oui/non au moment du RCPT (souvent dans smtpd_recipient_restrictions ou, plus récent, smtpd_relay_restrictions).

La posture par défaut de Postfix est conservatrice : il acceptera le courrier pour les domaines locaux, et il refusera de relayer vers des domaines distants arbitraires sauf si le client est de confiance. L’erreur est agaçante, mais c’est un bon signe que votre MTA n’est pas en train de faire du « outreach communautaire » aux spammeurs.

Une citation à garder sur un post‑it : « Hope is not a strategy. » — Gene Kranz. La politique SMTP, c’est pareil : définissez-la, ne l’espérez pas.

Guide de diagnostic rapide (vérifiez ceci en priorité)

C’est la partie à exécuter pendant un appel d’incident quand quelqu’un demande : « On peut juste tout ouvrir ? » Non. Voici le chemin le plus rapide pour savoir « ce qui a cassé » sans ouvrir les vannes du relais.

1) Confirmer où la rejette se produit

Si le rejet a lieu au RCPT TO avec 5.7.1, c’est la politique (permissions de relais).
Si c’est à la connexion ou au MAIL FROM, vous êtes dans un autre mode d’échec (pare‑feu, exigences TLS, restrictions d’expéditeur).

2) Identifier l’IP du client et le domaine destinataire

Vous avez besoin de l’IP du client et du domaine vers lequel on veut relayer. Avec ces deux éléments, vous pouvez décider si le client doit être de confiance (mynetworks / SASL) et si le destinataire est local/relayable.

3) Vérifier trois paramètres Postfix, dans cet ordre

smtpd_relay_restrictions (ou smtpd_recipient_restrictions sur les configs anciennes) : avez‑vous permit_mynetworks et/ou permit_sasl_authenticated avant reject_unauth_destination ?
mynetworks : inclut‑il le client ?
mydestination, virtual_mailbox_domains, relay_domains : le domaine destinataire est‑il censé être local, virtuel ou relayé ?

4) Si c’est un cas de soumission, cessez d’utiliser le port 25

Pour les utilisateurs/applications qui doivent s’authentifier, utilisez le service submission sur 587 (ou 465) avec authentification SASL et TLS. Le port 25 est pour SMTP serveur‑à‑serveur. Vous pouvez l’utiliser en interne, mais il faut le faire volontairement.

5) Validez que vous n’êtes pas accidentellement un relais ouvert

Avant de déclarer victoire, testez le relais depuis un réseau non fiable. Vous visez : « les clients de confiance peuvent relayer ; les clients non fiables de l’internet ne le peuvent pas. »

Blague #1 : Un relais ouvert, c’est comme laisser votre imprimante de badges dans le hall — techniquement pratique, spirituellement catastrophique.

Principes fondamentaux : autoriser le relais sans devenir un relais ouvert

Principe A : « Client de confiance » est une catégorie étroite

mynetworks ne devrait contenir que les réseaux que vous contrôlez et qui sont autorisés à envoyer du courrier vers l’internet par votre machine. En général, ce sont :

Loopback (127.0.0.0/8, [::1]/128)
Subnet privés où seuls vivent des serveurs (pas le Wi‑Fi du café, pas tout le LAN de l’entreprise sauf si vous aimez les appels d’incident)
Un subnet VPN dédié au trafic serveur

N’incluez pas 0.0.0.0/0. N’incluez pas « tous les RFC1918 » sauf si vous aimez déboguer l’ordinateur portable infecté du CFO.

Principe B : Les utilisateurs authentifiés relaient ; les inconnus non

Le relais pour les utilisateurs mobiles, les runners CI et les conteneurs d’apps aléatoires se résout par l’authentification SASL sur submission (587/465). Activez TLS, exigez l’auth, et permettez le relais pour les identités authentifiées.

Principe C : `reject_unauth_destination` est le filet de sécurité

Dans la chaîne de restrictions, reject_unauth_destination empêche le relais ouvert. Le supprimer n’est pas un « contournement ». C’est une confession.

Postfix évalue couramment le relais en utilisant smtpd_relay_restrictions (moderne) et/ou smtpd_recipient_restrictions (style ancien). Le schéma sûr ressemble à :

Permettre les réseaux de confiance
Permettre les clients authentifiés
Refuser les destinations non autorisées

Principe D : Décidez ce que votre Postfix est censé être

« Relay access denied » survient souvent parce que personne n’a décidé si la machine est :

Serveur MX / entrant (accepte le courrier pour vos domaines)
Relais sortant / smarthost (accepte des clients internes et relaye vers l’internet)
Les deux (possible, mais exige une séparation attentive des politiques)

Si c’est les deux, séparez la politique par écoute : port 25 pour le comportement MX entrant ; port 587 pour la soumission authentifiée ; restrictions différentes par service si nécessaire.

Principe E : Debugguez en pensant à la transaction SMTP

Les décisions de relais se prennent au moment du RCPT. Si vous ne savez pas ce que Postfix pense du client (IP, nom SASL, état TLS) et ce qu’il pense du domaine destinataire (local/virtuel/relay), vous devinez. Deviner, c’est comment on met en production un relais ouvert.

Scénarios réels courants et correctifs appropriés

Scénario 1 : Une application interne envoie via le port 25 et obtient relay denied

Symptôme : Le serveur d’application à 10.0.2.15 se connecte à Postfix et tente d’envoyer à user@gmail.com ; Postfix refuse le relais.

Correctifs :

Préféré : Faire passer l’application sur la soumission (587) avec authentification SASL ; ne pas compter sur la confiance par IP.
Acceptable dans des réseaux contrôlés : Ajouter seulement ce serveur (ou son subnet) à mynetworks.

Scénario 2 : Votre Postfix est un MX, et quelqu’un s’attend à ce qu’il relaie en sortie

Symptôme : Le MX reçoit l’entrée correctement. Les sorties depuis des hôtes internes échouent avec relay denied.

Fix : Décidez : le MX doit‑il être votre relais sortant ? Si oui, traitez‑le comme tel : activez submission, SASL et une politique sortante. Si non, déployez un relais distinct (recommandé) et gardez le MX verrouillé.

Scénario 3 : Vous avez mal configuré `mydestination` et Postfix pense qu’un domaine distant est local

Symptôme : le mail vers user@partner.tld est accepté puis rebondit localement, ou atterrit dans des tentatives de livraison locale.

Fix : Retirez les domaines qui ne sont pas à vous de mydestination. Utilisez relay_domains ou des transport maps si vous avez l’intention de relayer certains domaines spécifiquement.

Scénario 4 : Vous utilisez un relay SMTP d’un fournisseur cloud et voyez des relay denied en interne

Symptôme : Postfix est configuré avec relayhost = [smtp.provider.tld]:587 et fonctionne en test local, mais les clients internes obtiennent relay denied.

Fix : Votre Postfix ne relaye pas pour ces clients. Soit ajoutez leur réseau à mynetworks (de manière étroite), soit exigez l’auth SASL pour eux via la soumission.

Scénario 5 : Kubernetes/containers : l’IP source n’est pas celle que vous pensez

Symptôme : Vous avez ajouté le subnet des nœuds à mynetworks, mais le relay denied persiste ; les logs montrent une IP différente (NAT, réseau overlay).

Fix : Faites confiance à l’IP que vous voyez réellement dans les logs. Mieux : exigez l’auth sur submission et arrêtez de jouer à « deviner le CIDR overlay ».

Tâches pratiques : commandes, sorties, décisions (12+)

Voici ce que vous faites sur une machine en direct. Chaque tâche inclut : une commande, ce que signifie la sortie, et la décision suivante.

Task 1: Confirm the exact rejection in logs

cr0x@server:~$ sudo tail -n 50 /var/log/mail.log
Jan 03 10:14:22 mx1 postfix/smtpd[18422]: NOQUEUE: reject: RCPT from app1.internal[10.0.2.15]: 554 5.7.1 <user@gmail.com>: Relay access denied; from=<noreply@corp.example> to=<user@gmail.com> proto=ESMTP helo=<app1.internal>
Jan 03 10:14:22 mx1 postfix/smtpd[18422]: disconnect from app1.internal[10.0.2.15] ehlo=1 mail=1 rcpt=0/1 quit=1 commands=3/4

Ce que cela signifie : L’IP client est 10.0.2.15. Le rejet a lieu au RCPT. C’est un problème de politique.

Décision : Déterminez si 10.0.2.15 doit être de confiance via mynetworks ou forcé à s’authentifier (submission).

Task 2: See Postfix’s effective configuration for relay restrictions

cr0x@server:~$ sudo postconf -n | egrep '^(smtpd_relay_restrictions|smtpd_recipient_restrictions|mynetworks|mydestination|relay_domains|virtual_mailbox_domains|inet_interfaces|smtpd_tls_security_level|smtpd_sasl_auth_enable)'
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost
mynetworks = 127.0.0.0/8 [::1]/128
relay_domains = $mydestination
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination
smtpd_relay_restrictions =
smtpd_sasl_auth_enable = no
smtpd_tls_security_level = may
virtual_mailbox_domains =

Ce que cela signifie : Seul localhost peut relayer (mynetworks est loopback). Pas de SASL. Les restrictions incluent reject_unauth_destination (correct).

Décision : Si vous voulez que les applications internes relaient, agrandissez mynetworks ou activez submission + SASL et gardez mynetworks restreint.

Task 3: Check whether the client IP is in mynetworks (without guessing)

cr0x@server:~$ postconf mynetworks
mynetworks = 127.0.0.0/8 [::1]/128

Ce que cela signifie : 10.0.2.15 n’est pas de confiance.

Décision : N’ajoutez pas « juste 10.0.0.0/8 » à moins de pouvoir défendre ce choix. Préférez la submission avec auth pour tout ce qui n’est pas un subnet serveur étroitement contrôlé.

Task 4: Inspect the service-level configuration (submission vs smtp)

cr0x@server:~$ sudo postconf -M | egrep '^(smtp/inet|submission/inet|smtps/inet)'
smtp/inet = smtpd
submission/inet = submission smtpd
smtps/inet = smtps smtpd

Ce que cela signifie : Les services submission et smtps existent. C’est bien — assurez‑vous maintenant qu’ils requièrent l’auth et permettent le relais pour les clients authentifiés.

Décision : Configurez submission avec smtpd_tls_security_level=encrypt et smtpd_sasl_auth_enable=yes, plus des restrictions adaptées.

Task 5: Verify port listeners (don’t assume systemd did it)

cr0x@server:~$ sudo ss -lntp | egrep ':(25|587|465)\s'
LISTEN 0      100          0.0.0.0:25        0.0.0.0:*    users:(("master",pid=812,fd=13))
LISTEN 0      100          0.0.0.0:587       0.0.0.0:*    users:(("master",pid=812,fd=18))
LISTEN 0      100          0.0.0.0:465       0.0.0.0:*    users:(("master",pid=812,fd=19))

Ce que cela signifie : Postfix écoute sur 25, 587, 465. L’exposition compte.

Décision : Si cette machine n’est pas censée servir l’internet sur les ports de soumission, restreignez via le pare‑feu ou inet_interfaces / binding de service.

Task 6: Configure a safe baseline relay policy (modern Postfix)

Éditez /etc/postfix/main.cf et mettez :

cr0x@server:~$ sudo postconf -e 'smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination'
cr0x@server:~$ sudo postconf -e 'smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination'
...output...

Ce que cela signifie : Vous avez placé les deux autorisations sûres avant le refus crucial.

Décision : Si vous utilisez les deux paramètres, gardez‑les cohérents. Préférez smtpd_relay_restrictions pour la logique de relais et réservez les recipient restrictions pour des contrôles additionnels, mais dans de nombreuses configurations réelles vous verrez les deux.

Task 7: Add a tightly scoped internal network to mynetworks

cr0x@server:~$ sudo postconf -e 'mynetworks=127.0.0.0/8 [::1]/128 10.0.2.0/24'
cr0x@server:~$ postconf mynetworks
mynetworks = 127.0.0.0/8 [::1]/128 10.0.2.0/24

Ce que cela signifie : Seul le subnet 10.0.2.0/24 peut relayer sans auth. Pas tout le datacenter. Pas tout l’univers de l’entreprise.

Décision : Si vous ne pouvez pas définir un petit subnet en toute confiance, ne faites pas confiance basée sur l’IP. Utilisez la soumission + auth.

Task 8: Enable SASL auth (server side) for submission

En pratique cela utilise souvent Dovecot SASL. Vérifiez d’abord que Postfix pense que SASL est activé :

cr0x@server:~$ sudo postconf -e 'smtpd_sasl_auth_enable=yes'
cr0x@server:~$ sudo postconf -e 'smtpd_sasl_type=dovecot'
cr0x@server:~$ sudo postconf -e 'smtpd_sasl_path=private/auth'
cr0x@server:~$ sudo postconf smtpd_sasl_auth_enable smtpd_sasl_type smtpd_sasl_path
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth

Ce que cela signifie : Postfix demandera à Dovecot d’authentifier les clients.

Décision : Si vous n’avez pas Dovecot, ne copiez pas ces valeurs aveuglément. Utilisez Cyrus SASL ou la pile d’auth que votre plateforme supporte. La décision est : « l’auth existe et fonctionne » avant d’en dépendre.

Task 9: Require encryption and auth on submission service

Éditez /etc/postfix/master.cf pour l’override du service submission (exemple) :

cr0x@server:~$ sudo postconf -P 'submission/inet/smtpd_tls_security_level=encrypt'
cr0x@server:~$ sudo postconf -P 'submission/inet/smtpd_sasl_auth_enable=yes'
cr0x@server:~$ sudo postconf -P 'submission/inet/smtpd_client_restrictions=permit_sasl_authenticated,reject'
...output...

Ce que cela signifie : Submission exige TLS et l’auth (ou rejette). Cela réduit fortement les abus.

Décision : Si vos clients ne peuvent pas faire TLS, corrigez les clients. Ne dégradez pas le serveur pour accommoder des bibliothèques obsolètes à moins d’aimer vivre dangereusement.

Task 10: Reload Postfix safely and watch for config errors

cr0x@server:~$ sudo postfix check
postfix/postfix-script: warning: /etc/postfix/main.cf: unused parameter: smtpd_relay_restrictions
cr0x@server:~$ sudo systemctl reload postfix
...output...

Ce que cela signifie : L’avertissement suggère que votre version de Postfix ou votre chemin de config n’utilise peut‑être pas ce paramètre comme prévu, ou qu’il est surchargé par des paramètres de service.

Décision : N’ignorez pas les avertissements. Confirmez la version de Postfix et confirmez quel ensemble de restrictions est effectivement appliqué. Si nécessaire, utilisez le paramètre que votre version supporte (smtpd_recipient_restrictions sur les builds plus anciens).

Task 11: Confirm Postfix version and feature expectations

cr0x@server:~$ postconf mail_version
mail_version = 3.5.23

Ce que cela signifie : Ceci est assez récent pour utiliser smtpd_relay_restrictions normalement. Si vous avez vu « unused parameter », quelque chose d’autre cloche (typo, mauvais fichier, chroot, defaults packagés).

Décision : Validez le chemin du fichier de config actif et assurez‑vous d’éditer la bonne instance (containers, multiples installations Postfix, etc.).

Task 12: Test SMTP policy from a trusted host (positive test)

cr0x@server:~$ swaks --to user@gmail.com --from noreply@corp.example --server mx1 --port 25
=== Trying mx1:25...
=== Connected to mx1.
<-  220 mx1 ESMTP Postfix
 -> EHLO app1.internal
<-  250-mx1
<-  250 PIPELINING
 -> MAIL FROM:<noreply@corp.example>
<-  250 2.1.0 Ok
 -> RCPT TO:<user@gmail.com>
<-  250 2.1.5 Ok
...output...

Ce que cela signifie : Le relais fonctionne maintenant depuis l’environnement client testé.

Décision : Faites ensuite le test négatif depuis un réseau non fiable. Réussir sans cela n’est pas une victoire.

Task 13: Test that you are not an open relay (negative test)

cr0x@server:~$ swaks --to victim@remote.tld --from attacker@remote.tld --server mx1 --port 25 --ehlo evil.remote.tld
=== Trying mx1:25...
=== Connected to mx1.
<-  220 mx1 ESMTP Postfix
 -> EHLO evil.remote.tld
<-  250-mx1
 -> MAIL FROM:<attacker@remote.tld>
<-  250 2.1.0 Ok
 -> RCPT TO:<victim@remote.tld>
<-  554 5.7.1 <victim@remote.tld>: Relay access denied
...output...

Ce que cela signifie : Un client non fiable ne peut pas relayer vers un domaine distant. C’est ce que vous voulez.

Décision : Si ce test réussit (c.-à-d. que ça relaie), vous avez un incident, pas une fonctionnalité.

Task 14: Confirm recipient domain classification (local vs relay)

cr0x@server:~$ postconf mydestination relay_domains virtual_mailbox_domains
mydestination = $myhostname, localhost.$mydomain, localhost
relay_domains = $mydestination
virtual_mailbox_domains =

Ce que cela signifie : Ce serveur ne considère comme locaux que son hostname/localhost. Il ne relaie pas pour des domaines spécifiques par politique.

Décision : Si vous vous attendez à ce qu’il accepte le courrier pour corp.example, vous devez l’ajouter à mydestination (livraison locale) ou configurer des domaines virtuels. Si vous attendez qu’il relaie pour corp.example vers un autre backend, utilisez relay_domains plus un transport.

Task 15: Inspect the queue to distinguish “rejecting” from “accepting but failing later”

cr0x@server:~$ mailq
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
B3C2A1D4F9      1249 Fri Jan  3 10:18:01  noreply@corp.example
                                         user@gmail.com

-- 1 Kbytes in 1 Request.

Ce que cela signifie : Ce message a été accepté et mis en file ; le problème peut maintenant être la livraison sortante (DNS, port 25 bloqué, auth relayhost), pas la permission de relais.

Décision : Si le courrier est en file, vous êtes passé de la phase « relay access denied ». Passez au dépannage des logs de livraison sortante et de l’egress réseau.

Task 16: Trace one queued message end-to-end

cr0x@server:~$ sudo postcat -q B3C2A1D4F9 | sed -n '1,40p'
*** ENVELOPE RECORDS ***
message_size:            1249            1249
message_arrival_time:    Fri Jan  3 10:18:01 2026
sender: noreply@corp.example
*** MESSAGE CONTENTS ***
Received: from app1.internal (app1.internal [10.0.2.15])
        by mx1 (Postfix) with ESMTP id B3C2A1D4F9
        for <user@gmail.com>; Fri,  3 Jan 2026 10:18:01 +0000 (UTC)
Subject: test
...output...

Ce que cela signifie : Confirme l’identité du client et le destinataire, utile pour les audits et pour prouver quel hôte envoie.

Décision : Si vous voyez un hôte expéditeur inattendu, votre frontière de confiance est incorrecte. Corrigez mynetworks et le pare‑feu, puis enquêtez sur cet hôte.

Trois mini-récits des tranchées du courrier d’entreprise

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Ils avaient une VM « mail relay » que tout le monde considérait comme de la plomberie : elle existait, donc elle fonctionnait. Une équipe applicative a déployé un nouveau service dans un subnet différent après une réorganisation réseau. Même datacenter, même entreprise, CIDR différent.

Le déploiement s’est bien passé jusqu’au premier email de réinitialisation. Postfix a répondu « Relay access denied », et le service a décliné d’une manière qui ressemblait à une panne d’auth. L’ingénieur de garde de l’app a regardé son code parce que « SMTP, c’est juste un autre appel HTTP, non ? » Ce n’est pas le cas.

L’hypothèse erronée était simple : que mynetworks incluait « tous les réseaux internes ». Ce n’était pas le cas. Il incluait exactement un /24 d’il y a des années, et la seule documentation était un commentaire dans un fichier de config que personne ne lisait.

Ils ont corrigé en ajoutant le nouveau subnet à mynetworks. Le correctif de deuxième ordre — celui qui importait vraiment — a été de déplacer les apps vers la soumission authentifiée sur 587 et réduire mynetworks à seulement quelques machines d’infrastructure. Moins d’exceptions basées sur l’IP, moins de surprises à l’avenir.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre société voulait « réduire la complexité » en utilisant une seule instance Postfix pour tout : MX entrant, relais sortant et notifications internes. Une machine, une IP, un endroit pour patcher. Le diagramme était superbe.

Ils ont trop optimisé la politique. Quelqu’un a jugé la chaîne de restrictions « trop stricte » pour les apps internes et a saupoudré des règles permit partout jusqu’à ce que les emails circulent. Ça a été mis en production un vendredi, parce que bien sûr.

Le weekend, la machine a commencé à envoyer beaucoup de mail. Pas leur mail. Certains messages passaient depuis des IP sources bizarres qui étaient « internes » grâce à un pool client VPN et une entrée mynetworks trop large. Une fois que les spammeurs trouvent un relais ouvert, ils ne le gardent pas secret.

Le lundi matin a été une parade : réputation IP en chute, mail légitime différé, files de sortie explosées. Ils se sont « optimisés » en incident réputation. La correction était peu glamour : séparer inbound et outbound, resserrer mynetworks, exiger SASL sur submission, et remettre reject_unauth_destination exactement où il faut.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande entreprise avait une couche de relais mail qui faisait rarement la une. C’était intentionnel. Ils la traitaient comme tout autre système de production : contrôle des changements, gestion de config, et un runbook ennuyeux mais efficace.

Un jour, l’équipe sécurité a poussé un changement ACL réseau qui a forcé involontairement un chemin NAT pour certains subnets. Soudain, les logs Postfix ont montré des IP clients venant d’une plage différente. Le relais a échoué pour une poignée de services, mais l’ampleur est restée limitée parce que rien ne reposait sur « tout le réseau interne » comme zone de confiance.

Le on‑call a suivi le runbook : vérifier les logs pour l’IP client, confirmer si elle est dans mynetworks, vérifier que l’auth submission fonctionne, puis décider d’ajouter temporairement un CIDR étroit. Ils ont ajouté un /28 en solution provisoire et ouvert un ticket pour corriger le NAT.

Comme ils avaient un test négatif de relais dans le runbook, ils ont aussi vérifié que la machine rejetait toujours le relais depuis l’extérieur. Pas de relais ouvert, pas de dégâts de réputation, pas de panique. L’ennuyeux a gagné.

Faits intéressants et contexte historique (8 points)

Les relais ouverts étaient autrefois courants. La culture du courrier primitif supposait un comportement de bonne foi ; les abus ont forcé les MTA à durcir leurs défauts.
Postfix a été conçu comme une alternative plus sûre à Sendmail. Wietse Venema l’a construit avec une architecture axée sur la sécurité : processus multiples, moindre privilège et limites de confinement.
La position de l’industrie a changé au début des années 2000. Les grands fournisseurs ont commencé à bloquer ou lister agressivement les relais ouverts, poussant les admins à adopter des contrôles stricts.
reject_unauth_destination est devenu central. C’est effectivement « ne pas relayer sauf autorisation explicite », le seul défaut sensé sur l’internet d’aujourd’hui.
Le port 587 existe parce que le port 25 est devenu chaotique. Submission a été standardisé pour que les utilisateurs finaux puissent s’authentifier et soumettre du courrier sans mélanger la politique serveur‑à‑serveur.
Les RBL ont changé les comportements opérationnels. Les listes de blocage en temps réel ont permis aux récepteurs de punir rapidement les mauvais envois — parfois trop rapidement.
NAT et containers ont compliqué la « confiance par IP ». Les infrastructures modernes rendent « cette IP = cet hôte » moins fiable ; l’authentification sur submission évolue mieux.
« Relay denied » est souvent un signal de succès. Cela signifie que votre MTA a refusé d’être instrumentalisé — jusqu’à ce que vous le configuriez mal.

Erreurs courantes : symptôme → cause racine → fix

Cette section est volontairement spécifique. Si vous reconnaissez votre symptôme, vous obtenez un correctif qui n’implique pas de transformer votre serveur mail en service communautaire.

Mistake 1: “It works locally but not from other servers”

Symptôme : sendmail depuis l’hôte Postfix fonctionne ; les serveurs applicatifs distants obtiennent Relay access denied.
Cause racine : mynetworks ne contient que le loopback, ou les restrictions n’autorisent pas votre CIDR interne.
Fix : Ajouter un CIDR étroit à mynetworks ou exiger l’auth submission. N’élargissez pas à « tout ce qui est privé ».

Mistake 2: “We removed reject_unauth_destination and it fixed it”

Symptôme : Le mail circule, puis la réputation s’effondre. Ou votre supervision montre un volume sortant inhabituel.
Cause racine : Vous avez créé un relais ouvert (ou quasi).
Fix : Remettez reject_unauth_destination. Ajoutez permit_mynetworks et permit_sasl_authenticated avant lui. Testez le relais négatif depuis des réseaux non fiables.

Mistake 3: “We put our domain into mydestination so it would relay”

Symptôme : Le mail pour un domaine est accepté mais livré localement, rebondit, ou est dirigé vers le mauvais mécanisme de boîte.
Cause racine : Confusion entre « livraison locale » et « relai pour un domaine ».
Fix : Utilisez relay_domains et une transport map si vous relayez vers un autre système ; utilisez mydestination uniquement pour la livraison locale.

Mistake 4: “We trusted the whole VPN subnet”

Symptôme : Des endpoints aléatoires peuvent envoyer du mail sortant sans auth ; la sécurité s’inquiète pour de bonnes raisons.
Cause racine : Les pools clients VPN ne sont pas des « serveurs ». La confiance par IP est une mauvaise frontière.
Fix : Exigez l’auth SASL pour les utilisateurs distants ; retirez les plages clients VPN de mynetworks.

Mistake 5: “We enabled submission, but relaying still denied”

Symptôme : Le client s’authentifie (ou croit l’avoir fait) sur 587, mais RCPT reçoit toujours relay denied.
Cause racine : Absence de permit_sasl_authenticated dans la chaîne de restriction de relais pour ce service, ou le service submission ne requiert pas réellement l’auth.
Fix : Ajoutez permit_sasl_authenticated à smtpd_relay_restrictions et/ou aux overrides du service submission ; confirmez que SASL fonctionne dans les logs (sasl_username=).

Mistake 6: “We added the subnet, but Postfix still says relay denied”

Symptôme : Vous avez ajouté 10.0.2.0/24 mais les logs montrent le client comme 10.244.3.18 ou une IP NATée.
Cause racine : NAT, proxy, réseaux overlay, ou l’app ne vient pas d’où vous pensez.
Fix : Faites confiance à ce que montrent les logs Postfix. Ajustez mynetworks en conséquence — ou cessez la confiance par IP et passez à la soumission auth.

Mistake 7: “We used relayhost and assumed clients can relay”

Symptôme : Postfix peut envoyer en sortie quand il est exécuté localement, mais les clients internes obtiennent relay denied.
Cause racine : La config relayhost affecte la livraison sortante depuis Postfix lui‑même ; elle n’autorise pas automatiquement les clients entrants à relayer à travers lui.
Fix : Configurez l’autorisation des clients entrants (mynetworks ou auth submission) séparément.

Blague #2 : SMTP est simple jusqu’à ce que les humains s’en mêlent, moment auquel il devient une danse interprétative avec les logs.

Listes de vérification / plan étape par étape

Étape par étape : Corriger relay denied pour des serveurs internes (modèle confiance IP)

Identifier l’IP client depuis les logs (tail -n 50 /var/log/mail.log).
Décider si le client doit être de confiance (est‑ce un serveur que vous contrôlez, patché et supervisé ?).
Ajouter un CIDR étroit à mynetworks (préférez /32 ou /28–/24, pas /8).
Vérifier que les restrictions incluent : permit_mynetworks, puis reject_unauth_destination.
Recharger et tester depuis un hôte de confiance (test positif).
Tester depuis un hôte non fiable (test négatif) pour confirmer qu’il n’y a pas de relais ouvert.
Documenter le CIDR et le propriétaire (le vous du futur vous remerciera).

Étape par étape : Corriger relay denied pour utilisateurs/apps (modèle auth sur submission)

Activer la submission (587) et s’assurer qu’elle n’écoute que là où prévu (pare‑feu/bind).
Exiger TLS sur la submission (smtpd_tls_security_level=encrypt pour ce service).
Activer SASL auth (Dovecot ou Cyrus) et vérifier l’authentification dans les logs.
Permettre le relais aux authentifiés (permit_sasl_authenticated avant reject_unauth_destination).
Optionnellement restreindre les identités expéditrices par user/app pour réduire le potentiel d’abus.
Tester avec un client réel qui s’authentifie et envoie vers un domaine distant.
Faire le test négatif open‑relay sur le port 25 depuis des réseaux non fiables.

Étape par étape : Séparer les rôles MX entrant et relais sortant (bonne pratique)

Garder le MX strict : port 25 exposé, pas de relais général, n’accepte que vos domaines entrants.
Déployer un relais sortant : accepte depuis les réseaux internes et/ou via auth submission, relaie en sortie.
Séparer les réputations IP : l’IP sortante peut être limitée en taux et surveillée indépendamment.
Utiliser un routage explicite : les clients internes ciblent le relais ; le MX ne devient pas un attrape‑tout.
Auditer les deux : logs, comportement de file, et taux de rejets de relais deviennent des signaux clairs.

FAQ (les questions que les gens posent vraiment)

1) Que fait réellement `reject_unauth_destination` ?

Il rejette les destinataires qui ne sont pas dans vos domaines locaux/virtuels/relay sauf si le client est autorisé à relayer. C’est la règle principale de prévention du relais ouvert dans beaucoup de configurations Postfix.

2) Ajouter mon subnet d’app à `mynetworks` est‑il sûr ?

Ça peut être sûr si le subnet contient seulement des serveurs contrôlés (pas des endpoints utilisateurs) et si vous avez une forte sécurité hôte. C’est risqué quand les réseaux sont partagés, dynamiques, ou incluent des clients VPN. L’auth sur 587 évolue mieux.

3) Pourquoi ne pas autoriser le relais pour toutes les plages RFC1918 ?

Parce que les plages RFC1918 apparaissent là où vous ne vous y attendez pas : pools VPN, NAT mal configuré, labos reliés à la prod, et parfois un attaquant avec une présence interne. Les frontières de confiance larges vieillissent mal.

4) Dois‑je corriger ça en mettant `relay_domains = *` ?

Non. C’est un chemin classique vers « nous sommes devenus un relais ouvert en pratique ». Les relay_domains concernent les domaines destinataires que vous allez relayer en tant que service ; ils ne remplacent pas l’autorisation des clients.

5) Mes utilisateurs sont distants. Dois‑je ouvrir le port 25 entrant ?

Pour la soumission utilisateur, non. Utilisez le port 587 (ou 465) avec TLS et auth. Le port 25 sert au courrier serveur‑à‑serveur. Si vous hébergez un MX, vous avez besoin du 25 entrant pour la livraison internet.

6) J’ai activé SASL mais j’obtiens encore relay denied. Que chercher dans les logs ?

Cherchez sasl_username= dans les logs smtpd de Postfix pendant la session. S’il manque, l’auth ne se produit pas. S’il est présent, assurez‑vous que permit_sasl_authenticated figure dans la chaîne de restriction de relais pour ce service.

7) Puis‑je autoriser le relais uniquement vers certains domaines externes ?

Oui. C’est un choix de politique : utilisez des checks de restriction (recipient access maps) pour n’autoriser que des domaines destinataires approuvés pour des clients non authentifiés, et exigez l’auth pour le reste. Prudence : vous créez un jeu de règles qui devra être maintenu sous pression.

8) Comment savoir si j’ai accidentellement créé un relais ouvert ?

Testez depuis un réseau non fiable : tentez d’envoyer d’un expéditeur non local vers un destinataire non local via votre serveur. Le résultat correct est un rejet au RCPT avec Relay access denied (ou similaire). Surveillez aussi les logs pour un volume sortant inhabituel et des IP clients inconnues.

9) Pourquoi Postfix rejette parfois avec « Relay access denied » même pour mon propre domaine ?

Si le domaine n’est pas listé dans mydestination ou virtual_mailbox_domains (ou défini correctement comme domaine relay), Postfix le traite comme non local et applique les règles de relais. Corrigez d’abord la classification du domaine.

10) Dois‑je exécuter inbound et outbound sur la même instance Postfix ?

Vous pouvez, mais vous vous engagez à une complexité politique. Si possible, séparez les rôles : MX entrant et relais sortant ont des profils de risque et des préoccupations opérationnelles différents.

Conclusion : étapes pratiques suivantes

« Relay access denied » n’est pas Postfix qui fait le difficile. C’est Postfix qui refuse de devenir le problème de spam de quelqu’un d’autre. Votre correctif est de définir explicitement qui peut relayer et comment : confiance IP étroite pour les serveurs contrôlés, soumission authentifiée pour tout le reste, et reject_unauth_destination bien en place.

Étapes suivantes que vous pouvez exécuter aujourd’hui :

Récupérez une vraie ligne de log et identifiez l’IP client + le domaine destinataire.
Décidez si ce client doit être de confiance par IP. Si vous hésitez, exigez l’auth.
Mettez en place la chaîne de restrictions sûre et rechargez Postfix avec postfix check d’abord.
Réalisez les deux tests : « le client de confiance peut relayer » et « le client non fiable ne peut pas ».
Rédigez la politique en une phrase et gardez‑la avec la config. Le vous du futur sera fatigué et reconnaissant.