Greylisting des e-mails : quand il aide et quand il ne fait que retarder le courrier réel

novembre 25, 2025 • février 3, 2026 • Lecture : 31 min • Views: 6

Cet article vous a aidé ?

Le point douloureux : Vous êtes de garde. Un client dit : « Votre système n’a jamais envoyé ma réinitialisation de mot de passe. » Les journaux de votre application indiquent le contraire. Les logs de votre MTA montrent un 451. Et quelque part entre « sécurité » et « e-mail », le greylisting fait silencieusement ce pour quoi il a été conçu : ralentir les envois — parfois le mauvais courrier, parfois celui qui paie votre salaire.

Le greylisting est l’un de ces outils opérationnels qui semblent délicieusement low-tech : demander aux expéditeurs inconnus de revenir plus tard. La plupart des spams ne le font pas. Les MTA légitimes le font. Super. Jusqu’à ce que votre équipe finance rate des factures, que vos alertes d’observabilité arrivent après l’incident, et que votre prestataire marketing vous envoie une capture d’écran de son réglage « retries disabled » comme si c’était votre problème.

Ce que fait réellement le greylisting sur le fil

Le greylisting n’est pas une détection de spam. C’est un pari sur le comportement de l’expéditeur.

Le pari : les serveurs de mail légitimes vont retenter la livraison après un échec temporaire ; beaucoup d’infrastructures de spam, historiquement, n’en prenaient pas la peine. Vous traitez donc les expéditeurs vus pour la première fois comme « peut-être », vous renvoyez une erreur temporaire (généralement 451 4.7.1 ou similaire), et vous attendez que l’expéditeur essaie de nouveau. Au retry, vous acceptez.

Le mécanisme : un triplet et un minuteur

Le greylisting classique suit un « triplet » :

Adresse IP de l’expéditeur
MAIL FROM (expéditeur d’enveloppe)
RCPT TO (destinataire d’enveloppe)

La première fois que vous voyez un triplet, vous le rejetez temporairement. S’il revient après un « délai minimum » (disons 5–15 minutes), vous acceptez et souvent vous le mettez en liste blanche pour une période (« auto-whitelist »).

Les variantes modernes modifient la clé. Certaines n’utilisent que l’IP de l’expéditeur, d’autres IP + domaine expéditeur, ou incluent le HELO, ou exploitent la réputation. Ça compte, parce que la livraison d’e-mails en 2026 inclut des pools sortants partagés, des NAT, des relais SaaS, IPv6 et des « domaines d’envoi » qui ne correspondent pas proprement à des IP stables.

Sémantique SMTP : ce que vous pouvez faire

Le greylisting repose sur le contrat SMTP : une réponse 4xx est temporaire ; l’expéditeur doit retenter. Un 5xx est définitif ; l’expéditeur doit générer un bounce. Le greylisting vit dans la plage 4xx.

Une bonne réponse de greylist est précise sans être verbeuse :

451 4.7.1 Try again later
450 4.2.0 Temporarily deferred

Vous voulez que le MTA de l’expéditeur retente, pas qu’il décide que vous êtes cassé.

Où il se place dans la chaîne de mail

Le greylisting est généralement appliqué pendant la connexion SMTP, avant d’accepter les données du message. Sur Postfix, il est couramment implémenté comme service de politique dans smtpd_recipient_restrictions ou smtpd_data_restrictions, selon le démon et le plugin. Sur Exim, cela peut être fait via des ACL. Sur les appliances, il est souvent caché derrière une case à cocher nommée « Aggressive anti-spam », ce qui est un bon indicateur du plaisir à venir.

La position compte. Si vous greylistez trop tôt et trop largement, vous retarderez beaucoup de mails qui auraient autrement passé les filtres de contenu. Si vous le faites trop tard (après DATA), vous aurez déjà consommé bande passante et CPU sur du spam que vous cherchiez à dissuader à bas coût.

Pourquoi ça a marché (et pourquoi ça marche moins maintenant)

L’attrait initial du greylisting était son asymétrie : ça vous coûtait presque rien et ça coûtait du temps à l’expéditeur. Les moteurs de spam étaient optimisés pour le volume et la rapidité, pas pour la persistance. Beaucoup ne retentaient pas. Les MTA légitimes le faisaient. Boom : le spam chutait.

Mais les attaquants lisent les mêmes RFC que vous. Aujourd’hui, beaucoup de spams sortent d’« infrastructures réelles » (machines compromises, IP cloud, comptes ESP abusés) qui retentent correctement. Le greylisting est toujours utile, mais ce n’est plus la guillotine anti-spam qu’il était au milieu des années 2000.

En d’autres termes : le greylisting a vieilli comme un videur excellent pour repérer de fausses pièces d’identité, mais moins bon quand les fausses pièces ressemblent aux vraies. Toujours utile à l’entrée, pas un programme de sécurité complet.

Quand le greylisting aide en 2026

Le greylisting aide lorsque votre modèle de menace inclut une portion significative d’expéditeurs qui ne retentent pas ou retentent mal, et lorsque quelques minutes de délai sont acceptables pour la plupart des courriels entrants.

1) Petites et moyennes organisations subissant beaucoup de spam direct-to-MX

Si votre domaine reçoit beaucoup de pourriels envoyés directement vers votre MX, le greylisting peut encore éliminer les acteurs les plus bas de gamme. Surtout si vous n’avez pas un stack de filtrage à gros budget. Le meilleur avantage n’est pas le « blocage parfait ». C’est la réduction de la charge que doit traiter le reste de votre pipeline.

2) Serveurs de mail limités en CPU pour le scanning de contenu

Si vous exécutez SpamAssassin, Rspamd, antivirus, sandboxing d’attachement ou DLP, alors tout ce qui réduit le nombre de messages atteignant ces étapes peut être un gain. Le greylisting repousse les expéditeurs inconnus avant que vous n’ayez dépensé des cycles.

3) MX entrants dédiés avec expéditeurs légitimes prévisibles

Certaines domaines reçoivent des mails principalement de gros fournisseurs et d’un ensemble de partenaires connus. Le greylisting avec une whitelist sensée (gros fournisseurs, partenaires, votre prestataire de tickets, votre fournisseur de paie, etc.) peut apporter des bénéfices avec moins de tickets « pourquoi l’itinéraire de vol du CEO est en retard ».

4) Comme ralentisseur pendant un pic d’abus

Le greylisting peut servir de throttle temporaire. Si vous êtes sous un déluge de spam, activer ou renforcer le greylisting peut vous acheter du temps pendant que vous mettez en place des contrôles plus ciblés (ajustement DNSBL, limites de débit, décisions DMARC, etc.). Ce n’est pas joli, mais remplir une boîte aux lettres de malware non plus.

Blague #1 : Le greylisting, c’est comme dire à votre e-mail « Laisse un message après le bip », sauf que le bip est un RFC et le message, ce sont 40 000 arnaques crypto identiques.

Quand le greylisting nuit (et comment il échoue)

Le greylisting nuit quand le courrier important est sensible au temps, quand les expéditeurs ne retentent pas comme prévu, ou quand votre propre configuration transforme « première fois » en situation répétée.

Le courrier sensible au temps n’est plus optionnel

Réinitialisations de mot de passe, codes MFA, liens de vérification de compte, alertes de fraude, notifications pager, escalades on-call, confirmations d’achat, invitations de calendrier—ces messages sont souvent utilisés dans des flux où des humains attendent devant l’écran.

Un délai de 10 minutes n’est pas « une petite gêne ». C’est un flux cassé. Les utilisateurs n’interprètent pas cela comme « l’anti-spam fonctionne ». Ils l’interprètent comme « votre produit est peu fiable ». Ils n’ont pas tort.

Le comportement de retry est moins uniforme que vous ne le pensez

SMTP dit de retenter. Il ne précise pas à quelle vitesse, à quelle fréquence ou depuis quelle IP.

Certains systèmes retentent après 1 minute ; d’autres après 30.
Certains retentent depuis une adresse IP différente (pools larges).
Certains utilisent un expéditeur d’enveloppe différent (schémas VERP).
Certaines plateformes SaaS frontent le SMTP par des API HTTP puis livrent via un relais qui se comporte « presque comme SMTP » mais avec des bizarreries de politique.

Si votre clé de greylisting est trop stricte (par ex. IP + MAIL FROM complet + RCPT TO), un expéditeur qui retente depuis une IP différente ou avec une adresse d’enveloppe différente ne correspondra peut-être jamais au triplet initial. Vous venez d’inventer une machine de report infinie.

NAT, adresses de confidentialité IPv6 et pools sortants

Le greylisting suppose une certaine stabilité de l’identité de l’expéditeur. Les pools sortants sont conçus pour l’opposé : répartir le trafic et assurer la bascule. IPv6 fait souvent tourner les adresses (privacy extensions) et les gros fournisseurs peuvent utiliser des sous-réseaux massifs.

En conséquence, « première fois que nous voyons cette IP » peut devenir « première fois à chaque fois ». Si vous greylistez sur l’IP seule, vous pénaliserez les expéditeurs avec de gros pools. Si vous greylistez sur trop de champs, vous pénaliserez ceux qui les font varier.

Le greylisting casse la supervision et la réponse aux incidents

Les e-mails d’alerte sont généralement les plus sensibles à la latence. Et ce sont souvent des mails provenant d’IP à l’apparence aléatoire (fournisseurs de monitoring cloud, systèmes multi-locataires). Le greylisting rend la réponse aux incidents pire d’une façon qui n’apparaît qu’en situation d’incident. C’est justement quand votre patience est la plus faible et les attentes de vos parties prenantes les plus élevées.

Le greylisting au niveau de la politique peut masquer de vrais problèmes de délivrabilité

Si un partenaire se plaint « nous recevons sans cesse des 451 », vous pouvez en incriminer le greylisting et le mettre en whitelist. Parfois c’est juste. Parfois votre propre MX limite le débit, votre DNS est lent, votre politique TLS est trop stricte, ou vos vérifications reverse DNS rejettent. Le greylisting peut être le symptôme le plus bruyant alors que le goulot réel est ailleurs.

Blague #2 : Rien ne vous fait sentir vivant comme expliquer « le rejet temporaire est normal » à un cadre qui ne comprend que « avons-nous perdu de l’argent ».

Faits intéressants et contexte historique

Le greylisting s’est popularisé au début et au milieu des années 2000 comme contre-mesure légère quand les moteurs de spam ne retentaient souvent pas après des réponses 4xx.
Il repose sur le modèle store-and-forward original du SMTP : les échecs temporaires sont attendus, et les files d’attente font partie du fonctionnement normal du courrier.
Le RFC 5321 ne mandate pas le timing des retries ; les expéditeurs choisissent leur propre stratégie de backoff, d’où l’imprévisibilité du délai de greylisting entre fournisseurs.
L’auto-whitelisting a été introduit pour réduire les délais répétés, en stockant les triplets réussis pendant des jours ou des semaines pour éviter les re-greylistings.
Les gros expéditeurs utilisent de larges pools d’IP sortantes pour la capacité et la gestion de réputation ; le greylisting strict basé sur l’IP heurte ce modèle.
Certaines opérations de spam se sont adaptées en implémentant des retries, réduisant l’efficacité du greylisting comme unique contrôle anti-spam.
Le greylisting peut agir comme un limiteur primitif, réduisant indirectement le churn de connexions entrantes pendant les rafales de spam en forçant des retries.
Un mauvais choix de clé de greylisting peut créer des boucles « jamais accepté » quand les expéditeurs retentent avec un expéditeur d’enveloppe différent (VERP) ou une IP différente à chaque tentative.
Les grands fournisseurs préchauffent parfois ou valident des flux (comme des livraisons « probe ») ; le greylisting peut retarder ou compliquer ces vérifications de santé.

Mode opératoire de diagnostic rapide

Voici le playbook à exécuter quand quelqu’un dit « le mail est retardé », et que vous devez trouver le goulot avant que l’invitation à la réunion n’expire.

Première étape : confirmer qu’il s’agit bien de greylisting, pas d’une file ou d’un problème DNS

Cherchez des déferrals 4xx avec des marqueurs « greylist » dans les logs du MTA (service de politique Postfix, message ACL Exim, tag d’appliance).
Vérifiez si l’expéditeur a retenté et si le retry correspondait à la clé greylist (même IP ? même expéditeur d’enveloppe ?).
Contrôlez la distribution d’âge de la file mail : si tout est différé, vous pourriez avoir un blocage général entrant/sortant non lié au greylisting.

Deuxième étape : déterminer l’étendue et le rayon d’impact

Est-ce un seul domaine expéditeur (partenaire/prestataire) ou plusieurs ?
Est-ce du mail sensible au temps (auth, monitoring, facturation) ou à faible enjeu (newsletters) ?
Seuls certains destinataires sont affectés (par ex. des alias routés différemment) ?

Troisième étape : effectuer un changement immédiat et sûr

Mettre temporairement l’expéditeur de confiance en whitelist (domaine/plage IP, avec expiration si l’outil le permet).
Réduire la fenêtre de délai minimum si elle vous pénalise globalement (mais ne la ramenez pas à presque zéro ; vous n’ennuierez que les expéditeurs sans filtrer grand-chose).
Corriger la clé si vous détectez un mismatch de pool IP : utilisez un tuple moins fragile (souvent IP + domaine expéditeur, ou exploiter SPF/HELO avec précaution).

Quatrième étape : capturer des preuves pour le postmortem

Extraire une chronologie : première tentative, rejet greylist, tentatives de retry, heure d’acceptation.
Enregistrer les IP des expéditeurs utilisées lors des retries.
Noter si vos MX utilisaient plusieurs frontends et si l’état du greylist est partagé.

Une citation sur la fiabilité appartient ici parce que c’est tout l’objet de l’exploitation du mail : « L’espoir n’est pas une stratégie. » — idée paraphrasée souvent utilisée en exploitation et ingénierie.

Tâches pratiques : commandes, sorties et décisions

Voici des tâches pratiques à exécuter sur un MX Linux basé sur Postfix (ou à adapter à votre stack). Chaque tâche inclut : commande, sortie réaliste, ce que ça signifie, et la décision suivante.

Tâche 1 : Trouver des déferrals de greylisting dans les logs Postfix

cr0x@server:~$ sudo grep -E "greylist|Greylist|4\.7\.1|temporar" /var/log/mail.log | tail -n 6
Jan 03 09:41:12 mx1 postfix/smtpd[22107]: NOQUEUE: reject: RCPT from mail-ot1-f45.google.com[209.85.210.45]: 451 4.7.1 Service unavailable - try again later; from=<alerts@partner.example> to=<oncall@example.com> proto=ESMTP helo=<mail-ot1-f45.google.com>
Jan 03 09:41:12 mx1 postfix/smtpd[22107]: warning: greylist: triplet blocked (209.85.210.45, alerts@partner.example, oncall@example.com)
Jan 03 09:48:58 mx1 postfix/smtpd[22301]: NOQUEUE: accept: RCPT from mail-ot1-f45.google.com[209.85.210.45]: 250 2.1.5 Ok; from=<alerts@partner.example> to=<oncall@example.com> proto=ESMTP helo=<mail-ot1-f45.google.com>

Sens : C’est un greylisting classique : première tentative rejetée avec 451, acceptée plus tard.

Décision : Si le délai est acceptable et limité aux expéditeurs inconnus, conserver. Si cela concerne les mails d’alerte ou d’authentification, mettre en whitelist cet expéditeur ou bypasser le greylisting pour ce groupe de destinataires.

Tâche 2 : Confirmer quels services de politique sont actifs (Postfix)

cr0x@server:~$ sudo postconf -n | grep -E "smtpd_(recipient|data)_restrictions|check_policy_service"
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023, permit

Sens : Un service de politique est consulté au stade recipient ; c’est probablement là que le greylisting est implémenté.

Décision : Pour le dépannage, déplacez temporairement la politique plus tard/plus tôt ou ajoutez des exceptions (par ex. bypass pour certains clients) plutôt que de la retirer à l’aveugle.

Tâche 3 : Tester la réponse de la politique greylist directement (netcat vers le port de politique)

cr0x@server:~$ printf "request=smtpd_access_policy\nprotocol_state=RCPT\nprotocol_name=SMTP\nclient_address=209.85.210.45\nsender=alerts@partner.example\nrecipient=oncall@example.com\n\n" | nc -w 2 127.0.0.1 10023
action=defer_if_permit 451 4.7.1 Greylisted, please try again later

Sens : Le service de politique greyliste effectivement et différerait ce triplet maintenant.

Décision : Si cet expéditeur est critique pour l’activité, ajoutez-le au mécanisme de whitelist du service de politique (domaine/IP) et retestez.

Tâche 4 : Vérifier si l’état du greylist est partagé entre les frontends MX

cr0x@server:~$ sudo postconf -n | grep -E "proxy_read_maps|smtpd_policy_service"
proxy_read_maps =

Sens : Cela ne prouve pas le partage d’état, mais indique que vous ne proxyfiez peut‑être pas les lookups. Beaucoup de démons greylist utilisent SQLite local. Si vous avez plusieurs nœuds MX derrière un load balancer, chaque nœud peut « apprendre » séparément.

Décision : Si vous avez plusieurs MX, confirmez que le backend greylist est centralisé (Redis/SQL) ou utilisez un hashing cohérent / stickiness par expéditeur. Sinon vous aurez des déferrals répétés quand les retries tombent sur un nœud différent.

Tâche 5 : Inspecter la file mail pour les messages différés (Postfix)

cr0x@server:~$ sudo postqueue -p | head -n 18
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2C21A0B7*    2190 Fri Jan  3 09:38:02  alerts@partner.example
                                         oncall@example.com
                                         (host mx1[127.0.0.1] said: 451 4.7.1 Greylisted, please try again later (in reply to RCPT TO command))
9A77F1B9CC     1046 Fri Jan  3 09:37:11  billing@vendor.example
                                         ap@corp.example
                                         (connect to mx.remote.example[203.0.113.40]:25: Connection timed out)

Sens : Vous avez au moins un message différé à cause du greylisting et un autre à cause de problèmes réseau sortants. Tout retard n’est pas du greylisting.

Décision : Scindez l’incident : corrigez la politique de greylisting pour les déferrals entrants ; réparez réseau/DNS/routage pour les timeouts sortants. Ne blâmez pas un seul mécanisme pour tout.

Tâche 6 : Identifier les messages différés les plus anciens pour jauger l’impact utilisateur

cr0x@server:~$ sudo postqueue -p | awk 'BEGIN{RS="";FS="\n"} {print $0 "\n---"}' | grep -E "Arrival Time|Greylist|Queue ID" | head -n 30
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2C21A0B7*    2190 Fri Jan  3 09:38:02  alerts@partner.example
(host mx1[127.0.0.1] said: 451 4.7.1 Greylisted, please try again later (in reply to RCPT TO command))
---

Sens : Les timestamps de la file vous indiquent si c’est une gêne de 5 minutes ou une panne d’une heure.

Décision : Si les âges des messages différés dépassent votre latence acceptable (pour les alertes/auth, cela peut être 1–2 minutes), vous devez contourner le greylisting pour ces flux immédiatement.

Tâche 7 : Vérifier la latence de résolution DNS (un DNS lent ressemble à un retard mail)

cr0x@server:~$ time dig +tries=1 +timeout=2 mx partner.example
;; ANSWER SECTION:
partner.example.        300     IN      MX      10 mx.partner.example.

real    0m0.412s
user    0m0.018s
sys     0m0.010s

Sens : La résolution DNS est rapide ici. Si vous voyez des temps de plusieurs secondes ou des timeouts, vous pouvez bloquer les sessions SMTP, ce qui se combine mal avec le greylisting et les limites de connexion.

Décision : Si le DNS est lent, corrigez le chemin/resolvant/caching avant de tuner le greylisting. Sinon vous attribuerez les retards à tort.

Tâche 8 : Vérifier si postscreen ou le throttling de connexion est aussi en jeu

cr0x@server:~$ sudo postconf -n | grep -E "^postscreen|smtpd_client_connection_rate_limit"
postscreen_greet_action = enforce
smtpd_client_connection_rate_limit = 30

Sens : Vous utilisez des contrôles au niveau connexion en plus du greylisting. Bien. Mais l’effet combiné peut être « l’expéditeur légitime est ralenti deux fois ».

Décision : Si le mail légitime est retardé, envisagez d’exempter les expéditeurs connus du postscreen/greeting delay et du greylisting, plutôt que d’assouplir tout globalement.

Tâche 9 : Confirmer que vos fichiers d’exception/whitelist sont réellement chargés

cr0x@server:~$ sudo grep -R "whitelist" /etc/postfix | head -n 8
/etc/postfix/main.cf:smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023, permit
/etc/postfix/greylist-whitelist:partner.example
/etc/postfix/greylist-whitelist:203.0.113.0/24

Sens : Vous avez un fichier de whitelist, mais cela ne prouve pas que le démon greylist le lit.

Décision : Trouvez la config du service greylist et assurez-vous qu’il référence ce fichier ; sinon vous éditez un placebo réconfortant.

Tâche 10 : Inspecter le statut systemd du démon greylist

cr0x@server:~$ sudo systemctl status postgrey --no-pager
● postgrey.service - Postgrey greylisting policy server
     Loaded: loaded (/lib/systemd/system/postgrey.service; enabled)
     Active: active (running) since Fri 2026-01-03 07:12:11 UTC; 2h 34min ago
   Main PID: 1189 (postgrey)
     Memory: 42.1M
     CGroup: /system.slice/postgrey.service
             └─1189 /usr/sbin/postgrey --inet=127.0.0.1:10023 --delay=300

Sens : Le délai greylisting est de 300 secondes (5 minutes). Le service est en fonctionnement.

Décision : Si votre activité exige un mail quasi-instantané, 5 minutes peuvent déjà être trop élevées à moins d’avoir des whitelists serrées pour les flux sensibles.

Tâche 11 : Valider le pattern de retry de l’expéditeur depuis les logs (ont-ils retenté ? depuis où ?)

cr0x@server:~$ sudo grep -E "from=.*vendor\.example|client=.*203\.0\.113" /var/log/mail.log | tail -n 8
Jan 03 09:10:01 mx1 postfix/smtpd[21001]: NOQUEUE: reject: RCPT from relay1.vendor.example[203.0.113.10]: 451 4.7.1 Greylisted, please try again later; from=<bounce+ab12@vendor.example> to=<ap@corp.example>
Jan 03 09:25:44 mx1 postfix/smtpd[21477]: NOQUEUE: reject: RCPT from relay2.vendor.example[203.0.113.22]: 451 4.7.1 Greylisted, please try again later; from=<bounce+cd34@vendor.example> to=<ap@corp.example>
Jan 03 09:41:05 mx1 postfix/smtpd[22192]: NOQUEUE: reject: RCPT from relay3.vendor.example[203.0.113.35]: 451 4.7.1 Greylisted, please try again later; from=<bounce+ef56@vendor.example> to=<ap@corp.example>

Sens : L’expéditeur retente, mais chaque retry provient d’une IP différente et d’un expéditeur d’enveloppe différent (VERP). Si votre clé greylist inclut l’IP et le MAIL FROM complet, ils ne passeront jamais.

Décision : Assouplissez la clé (par ex. domaine expéditeur + destinataire) ou whitelistez les domaines/plages IP du fournisseur. C’est un mismatch structurel, pas « laissez-lui plus de temps ».

Tâche 12 : Mesurer si votre base de données greylist grossit hors de contrôle

cr0x@server:~$ sudo ls -lh /var/lib/postgrey
total 96M
-rw------- 1 postgrey postgrey 95M Jan  3 09:30 postgrey.sqlite
-rw-r--r-- 1 root     root     1.2K Dec 12 14:02 whitelist_clients.local

Sens : La DB fait 95 Mo. Ce n’est pas intrinsèquement mauvais, mais la croissance peut affecter les performances si l’hôte est contraint en ressources ou si le stockage est lent.

Décision : Si vous observez une forte croissance plus des I/O élevées, envisagez des réglages de purge/âge, passer à un disque plus rapide, ou changer le backend vers Redis/SQL si vous avez besoin d’un état partagé.

Tâche 13 : Vérifier l’I/O wait et la latence disque (les lookups de politique frappent le disque)

cr0x@server:~$ iostat -xz 1 2
Linux 6.6.0 (mx1) 	01/03/2026 	_x86_64_	(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          3.21    0.00    1.12   18.44    0.00   77.23

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await  aqu-sz  %util
nvme0n1          2.10     64.0     0.00   0.00   1.21    30.5      58.2   2200.0    19.80    1.15   92.4

Sens : Iowait élevé et forte utilisation du périphérique. Si votre politique greylist utilise SQLite sur ce disque, les décisions de politique peuvent ralentir les sessions SMTP, augmenter les timeouts et le churn de connexions.

Décision : Corrigez les performances de stockage (déplacer la DB sur un disque plus rapide, tuner la rétention, ou changer de backend). Le greylisting qui ralentit votre serveur SMTP est une auto‑lésion.

Tâche 14 : Confirmer la réponse SMTP réelle avec une session live

cr0x@server:~$ nc -w 3 mx1.example.com 25
220 mx1.example.com ESMTP Postfix
EHLO test.example
250-mx1.example.com
250-PIPELINING
MAIL FROM:<alerts@partner.example>
250 2.1.0 Ok
RCPT TO:<oncall@example.com>
451 4.7.1 Service unavailable - try again later
QUIT
221 2.0.0 Bye

Sens : C’est au stade RCPT que le rejet temporaire survient. Cela s’aligne avec le placement de la restriction de politique.

Décision : Si vous avez besoin d’exceptions, implémentez-les au même stade (recipient restrictions) pour éviter des interactions surprenantes.

Trois mini-histoires du monde de l’entreprise

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

L’entreprise gérait un portail client avec réinitialisations de mot de passe par e-mail. L’équipe SRE avait hérité d’un MX on‑prem, et un ancien playbook anti-spam recommandait le greylisting parce que « ça coupe le spam de 80 % ». Cette phrase est devenue un talisman. Personne ne posa la deuxième question : « 80 % de quoi, et à quel prix ? »

Pendant un pic de trafic un lundi matin — annonce d’un nouveau produit, beaucoup d’inscriptions — le flux de réinitialisation de mot de passe a commencé à « échouer aléatoirement ». Le support recevait des tickets : les utilisateurs demandaient une réinitialisation, ne la recevaient pas, demandaient à nouveau, toujours rien. L’ingénierie vérifia les logs applicatifs : les réinitialisations étaient générées et envoyées au MTA. Ils incriminèrent le fournisseur d’e‑mail. Ils avaient à moitié raison, dans le sens qui entretient un incident.

Dans les logs mail, chaque réinitialisation était greylistée au premier contact. C’était attendu. La mauvaise hypothèse était que les retries viendraient de la même identité d’expéditeur. Le mail de réinitialisation provenait en fait d’un relais SaaS avec un large pool IP et des expéditeurs d’enveloppe variables. Chaque retry semblait nouveau. Le greylisting ne retardait pas la livraison ; il l’empêchait indéfiniment.

Le dommage opérationnel de l’incident vint du cycle de prise de conscience lent. Les gens attendaient « encore quelques minutes » parce que c’est ce que fait le greylisting. Quand on conçoit un système où l’échec ressemble à un retard normal, on a construit un menteur. Au moment où ils mirent en whitelist la plage de relais du fournisseur et assouplirent le tuple en matching par domaine, la fenêtre d’inscription était passée et l’équipe marketing en vint à blâmer « infra ».

La correction fut peu glamoureuse : un contournement ciblé pour les domaines expéditeurs de réinitialisation et une règle selon laquelle tout mail lié aux flux d’authentification ne doit pas être greylisté. Aussi, un banc de test qui injecte un SMTP réel depuis le pool du fournisseur en staging. La leçon réelle : ne considérez jamais les propriétés de livraison des e‑mails comme stables entre fournisseurs.

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

Une autre organisation avait un projet classique « on peut économiser de l’argent » : consolider deux nœuds MX en une VM plus grosse avec CPU plus rapide, garder les mêmes contrôles anti-spam, et appeler ça un succès. Le greylisting resta. Ils le renforcèrent même : fenêtre de délai plus longue, auto-whitelist plus longue, tuple plus strict. « Réduisons le junk et le CPU de scanning », disaient‑ils.

Pendant une semaine, tout avait l’air bien. Le volume de spam avait chuté. Le CPU aussi. Le rapport hebdomadaire ressemblait à une victoire.

Puis vint la clôture trimestrielle. Les comptes fournisseurs se plaignirent que des factures de plusieurs vendeurs arrivaient avec des heures de retard. Pas de bounce. Pas de perte. Juste assez de retard pour provoquer des frictions dans le flux de paiement et suffisamment d’appels pour justifier une escalade.

L’optimisation avait deux coûts cachés. D’abord, la VM plus grande roulait sur du stockage partagé avec des voisins bruyants ; la base greylist vivait sur ce stockage, et les lookups de politique commencèrent à ramer sous charge. Ensuite, le tuple plus strict signifiait que les fournisseurs utilisant des adresses de bounce style VERP ne correspondaient jamais aux tentatives précédentes. Le courrier arrivait finalement, mais seulement après suffisamment de retries pour coïncider avec une combinaison stable d’IP et d’expéditeur d’enveloppe. Ce n’était pas déterministe ; c’était de la roulette.

Ils revinrent sur le tuple strict et migrèrent le backend greylist vers Redis sur NVMe local. Le CPU de scan grimpait un peu, mais la latence des factures redevint banale. C’est le bon trade‑off dans la plupart des environnements d’entreprise : dépenser du calcul pour que le courrier business reste rapide. Le calcul coûte moins cher que la confiance.

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

Une troisième société exploitait son propre MX comme gateway entrant devant un fournisseur de boîtes hébergées. Ils avaient le greylisting activé, mais le traitaient comme un composant contrôlé par changement, pas comme un paramètre folklorique. L’équipe mail tenait une petite liste « expéditeurs critiques » : monitoring, RH/paie, fournisseur SSO, système de tickets et top vendors. Chaque entrée avait un propriétaire, une raison et une date de revue. Ennuyeux. Efficace.

Un après-midi, un incident réseau régional causa une perte de paquets intermittente vers un de leurs nœuds MX. Le load balancer continuait d’envoyer du trafic vers le nœud défaillant. Normalement, c’est déjà mauvais. Avec le greylisting, ça peut être pire : la première tentative frappe le nœud cassé et est différée pour timeouts, le retry arrive sur le nœud sain et est traité comme « nouveau », se fait greylister, puis les retries rebondissent entre nœuds. Soudain, vous avez amplifié les délais.

Mais comme ils centralisaient l’état du greylist (backend partagé) et avaient des health checks qui éjectaient rapidement le nœud cassé, le rayon d’impact resta limité. Leur diagnostic rapide n’était pas du bricolage : l’âge des files resta dans leur SLA ; les logs montraient un motif propre ; les expéditeurs critiques contournaient complètement le greylisting. Incident résolu avant que quiconque en dehors de l’IT ne le remarque.

La pratique qui « a sauvé la mise » n’était pas un filtre anti-spam ML sophistiqué. C’était : état partagé, whitelists avec propriétaires, et un health check du load balancer qui représentait vraiment l’utilisabilité SMTP, pas juste « port 25 ouvert ». L’ennui est une fonctionnalité.

Erreurs courantes (symptômes → cause racine → correction)

1) Symptom : Les e-mails de réinitialisation arrivent 10–30 minutes en retard (ou jamais)

Cause racine : Greylisting appliqué au mail transactionnel provenant de relais SaaS avec larges pools IP et expéditeurs d’enveloppe variables ; le tuple ne correspond jamais.

Correction : Contourner le greylisting pour les domaines/plages IP émetteurs transactionnels ; assouplir la clé (par domaine) si l’outil le permet ; ou désactiver le greylisting sur le MX qui gère ces flux transactionnels.

2) Symptom : Un partenaire dit « nous recevons des 451 » et fournit des logs de tentatives répétées

Cause racine : Fenêtre de délai minimum plus longue que leur calendrier de retry, ou ils retentent depuis des IP différentes à chaque fois et vous keyez strictement.

Correction : Réduire le délai minimum à 60–180 secondes pour les inconnus ; ajouter le partenaire en whitelist ; ajuster le tuple.

3) Symptom : Retards répétés au premier contact depuis de gros fournisseurs (Gmail, Microsoft)

Cause racine : Le greylisting basé sur IP pénalise les pools sortants ; chaque message provient d’une IP « nouvelle ».

Correction : Whitelister prudemment les plages IP des gros fournisseurs (ou whitelister via signaux authentifiés si votre gateway le supporte). Sinon, ne pas greylister ces fournisseurs ; s’appuyer sur réputation/filtrage de contenu.

4) Symptom : Le mail passe parfois immédiatement, parfois est retardé, avec plusieurs nœuds MX

Cause racine : L’état greylist est local par nœud ; les retries tombent sur un nœud différent et sont traités comme nouveaux.

Correction : Centraliser l’état (DB partagée/Redis) ou utiliser la stickiness du load balancer par IP expéditeur. Mieux : centraliser l’état.

5) Symptom : Les connexions entrantes montent en flèche et les MTAs distants time-out

Cause racine : Greylisting plus backend de politique lent provoque des sessions SMTP longues ; les MTAs distants ouvrent plus de connexions parallèles ; votre serveur atteint les limites de connexion ; chaos.

Correction : Corriger les performances du backend (disk/I/O), réduire le coût des lookups de politique, tuner les limites de concurrence et raccourcir le temps SMTP par session.

6) Symptom : Le spam diminue, mais les plaintes sur factures en retard augmentent

Cause racine : Le greylisting fait son travail, mais vous n’avez pas exempté les expéditeurs business-critiques ; de plus, les fournisseurs AP utilisent souvent des relais particuliers.

Correction : Maintenir une whitelist « business critical » avec un propriétaire, et mesurer la latence de livraison pour ces domaines.

7) Symptom : Le greylisting semble inefficace ; le spam arrive toujours

Cause racine : Les spammers modernes retentent correctement ; votre greylisting n’ajoute que du délai à tout le monde.

Correction : Réduire la dépendance au greylisting ; investir dans contrôles de réputation, filtrage de contenu, décisions DMARC et limites de débit.

Listes de contrôle / plan étape par étape

Checklist A : Décider si vous devez activer le greylisting

Inventorier les flux sensibles au temps : auth, monitoring, ticketing, finance, légal. Si vous ne pouvez pas les lister, supposez qu’ils existent et qu’ils comptent.
Mesurer la composition actuelle du spam entrant : direct-to-MX vs relayé ; combien est arrêté par d’autres contrôles.
Estimer la latence acceptable : définir des objectifs pour différentes classes (alertes : <2 minutes ; réinitialisation mot de passe : <1 minute ; newsletters : sans contrainte).
Évaluer la diversité des expéditeurs : beaucoup de petits expéditeurs avec MTA stables ? Le greylisting peut aider. Plutôt des gros fournisseurs et SaaS ? Le greylisting vous agacera surtout.
Décider de votre politique : « greylister les expéditeurs directs-to-MX inconnus sauf catégories whitelistées » est un compromis raisonnable.

Checklist B : Implémenter le greylisting sans se tirer une balle dans le pied

Choisir un délai minimum conservateur : 60–180 secondes dans un environnement moderne ; 300 secondes est souvent trop pour les flux transactionnels.
Activer l’auto-whitelisting avec un TTL sensé (jours à semaines), pour que les correspondants normaux ne soient pas retardés à répétition.
Centraliser l’état si vous avez plus d’un MX.
Whitelists avec propriétaires : chaque entrée a un propriétaire et une date de revue. Sinon ça devient une décharge.
Contourner pour les flux critiques : monitoring, SSO, fournisseurs de réinitialisation, fournisseurs finance. Règle d’or : le mail d’auth ne doit pas être greylisté.
Instrumenter la latence : logger et grapher « première vue » → « acceptation ». Si vous ne mesurez pas, vous discuterez sur des anecdotes.

Checklist C : Répondre à un incident lié au greylisting

Confirmer : chercher des 451 dans les logs avec un tag greylist.
Vérifier le comportement de retry de l’expéditeur : même IP ? même expéditeur d’enveloppe ? même nœud MX ?
Whitelister immédiatement l’expéditeur business-crucial.
Réduire la fenêtre de délai si l’impact est large.
Corriger le tuple/partage d’état de manière permanente.
Noter : quels mails ont été retardés, pour qui, et combien de temps.

FAQ

1) Le greylisting est-il « sûr » d’un point de vue sécurité ?

Ce n’est pas un contrôle de sécurité au sens classique. C’est un mécanisme de shaping du trafic. Il peut réduire l’exposition aux spams de faible effort, mais il n’arrêtera pas les phishing ciblés ou les expéditeurs légitimes compromis.

2) Combien de temps doit durer le délai de greylisting ?

Pour la plupart des environnements modernes : 60–180 secondes est la plage pratique. Des délais plus longs nuisent aux workflows utilisateurs et n’améliorent pas de manière fiable l’efficacité contre le spam moderne.

3) Pourquoi certains expéditeurs légitimes ne passent-ils jamais ?

Parce que votre clé est trop stricte ou votre état n’est pas partagé. Si l’expéditeur retente depuis des IP différentes ou change l’expéditeur d’enveloppe, le « même triplet » ne se répète jamais, et votre système continue à les traiter comme nouveaux.

4) Dois‑je greylister Gmail/Microsoft ?

Généralement non. Ils retentent correctement, mais utilisent des pools sortants. Vous introduirez surtout du retard sans réduction significative du spam. Whitelistez-les ou fiez‑vous à d’autres couches de filtrage.

5) Le greylisting aide‑t‑il contre les botnets ?

Parfois. Les expéditeurs de botnets de mauvaise qualité peuvent ne pas retenter. Mais beaucoup le font maintenant. Considérez le greylisting comme une couche mineure, pas comme la fondation.

6) Où appliquer le greylisting dans Postfix ?

Typiquement via check_policy_service dans smtpd_recipient_restrictions. Cela rejette avant DATA, économisant des ressources. Mais appliquez des exceptions avec soin, surtout pour les réseaux de confiance et les domaines expéditeurs critiques.

7) Le greylisting peut‑il provoquer des doublons d’e‑mail ?

Indirectement, oui. Si un expéditeur time‑out, retente agressivement, ou si une couche applicative renvoie parce qu’elle n’a pas reçu un signal « livré » rapide, vous pouvez voir des doublons. Le greylisting n’est pas la seule cause, mais il peut y contribuer.

8) Quels indicateurs dois‑je surveiller si j’active le greylisting ?

Suivez : le nombre de déferrals 4xx par raison, le nombre d’acceptations après greylist, la médiane et le p95 du délai du premier essai à l’acceptation, et la concurrence des connexions entrantes. Surveillez aussi la latence du backend de politique et les I/O disque.

9) Le greylisting est‑il adapté au courrier sortant ?

Non. Le greylisting est une politique d’entrée pour votre MX. La délivrabilité sortante dépend de votre réputation, authentification (SPF/DKIM/DMARC) et du traitement des erreurs — c’est un autre domaine.

10) Quelle est la façon la plus propre d’exempter le « mail critique » ?

Séparez‑le par domaine expéditeur/IP, groupe de destinataires, ou faites transiter les flux critiques par un chemin de politique MX différent. L’essentiel : les exemptions doivent être explicites, revues et testées.

Prochaines étapes réalisables cette semaine

Classifiez vos mails : listez les 20 premiers domaines expéditeurs par impact business, pas par volume. Alertes, auth, finance, ticketing, voyages des dirigeants — oui, vraiment.
Exécutez la recherche de logs pour les déferrals 451 et calculez les délais pour ces expéditeurs critiques. Si vous ne pouvez pas le calculer, échantillonnez manuellement via les timestamps.
Corrigez d’abord les problèmes structurels : si vous avez plusieurs nœuds MX et un état greylist local, centralisez-le. Si votre backend de politique est sur un disque lent, migrez‑le.
Fixez un délai sensé : si vous êtes à 300 secondes, envisagez 120 secondes et compensez par de meilleures couches de filtrage.
Créez un processus de whitelist : propriétaire + raison + date de revue. Ce n’est pas de la bureaucratie ; c’est pour éviter au futur vous de fouiller une config vieille de dix ans à 3 h du matin.
Testez avec des retries réels : choisissez un fournisseur connu pour son comportement de pool IP et validez l’acceptation au retry à travers les nœuds MX. Si ça échoue, ajustez le tuple ou la whitelist.

Le greylisting n’est ni héros ni vilain. C’est un instrument brutal qui peut encore être utile lorsque vous comprenez son coût : du temps, de la prévisibilité et la réunion houleuse occasionnelle. Utilisez‑le là où le délai est acceptable, contournez‑le là où le délai fait du dommage, et mesurez‑le comme si vous y teniez vraiment.