veilletech.fr
6 sept. Feed du jour
#05 DEVOPS Article

Le démon qui tourne et ne signe rien

Le silence n'est pas l'absence de panne. C'est une panne qui se tait.

Post-mortem d'un relais de courrier dont Gmail rejetait tout : pas d'enregistrement SPF valide (seulement un vieux SenderID), un PTR dont la résolution directe ne revenait pas sur l'IP d'envoi, et un OpenDKIM qui ne signait rien sans écrire la moindre ligne de journal. La cause finale tenait en un mot de configuration : refile: au lieu de file:.

3 min de lectureintermédiairevidéo 1:09
Partager
Sommaire4 sections
  1. Ce qui se passe
  2. Les trois pannes, et ce qui les prouve
  3. La méthode, qui est le vrai sujet
  4. À retenir

Ce qui se passe

Un relais sortant voit Gmail refuser tout ce qu'il envoie. Trois mécanismes d'authentification étaient cassés en même temps, et c'est ce qui a rendu le diagnostic pénible : réparer l'un d'eux ne produisait aucun changement visible.

Les trois pannes, et ce qui les prouve

Un SPF qui n'en était pas un. Le domaine portait bien un enregistrement TXT, mais au format SenderID, commençant par spf2.0/mfrom,pra. La RFC 7208 §4.5 est sans ambiguïté : un vérificateur écarte tout ce qui ne commence pas exactement par v=spf1. Pour Gmail, le domaine n'avait donc aucun SPF. Un enregistrement qui ressemble à du SPF pour un humain et n'existe pour aucune machine est pire qu'une zone vide : il empêche d'aller chercher plus loin.

Un PTR qui existait mais ne bouclait pas. Le message de rejet le disait, dans sa seconde moitié :

TEXT
550-5.7.25 [203.0.113.51] The IP address sending this message does not have a PTR
550-5.7.25 record setup, or the corresponding forward DNS entry does not match the sending IP

C'est la deuxième clause qui compte. La RFC 1912 §2.1 demande que PTR et A se correspondent ; l'auteur a repointé le PTR vers un nom dont l'enregistrement A résolvait déjà vers l'IP d'envoi — plutôt que de modifier un A en production — et aligné myhostname de Postfix dessus.

Un OpenDKIM parfaitement silencieux. Les tables étaient déclarées en type refile: alors que leur contenu était au format à deux colonnes. Sous refile:, la clé de recherche est traitée comme une expression régulière comparée à l'adresse complète du champ From: — donc example.org ne correspond jamais à noreply@example.org. Aucune clé trouvée, aucune ligne de journal, et le courrier part sans signature.

Diff
-KeyTable refile:/etc/opendkim/KeyTable
-SigningTable refile:/etc/opendkim/SigningTable
+KeyTable file:/etc/opendkim/KeyTable
+SigningTable file:/etc/opendkim/SigningTable

Sous file:, la recherche essaie user@host, puis l'hôte seul — où example.org correspond enfin.

La méthode, qui est le vrai sujet

La première vérification employée était grep -c "DKIM-Signature" dans /var/log/mail.log. Elle renvoyait 0. Elle renvoie toujours 0 : Postfix n'écrit pas les en-têtes dans son journal. Un instrument qui rend le même verdict que le signeur fonctionne ou non ne prouve rien, et il a servi de base à l'heure suivante de travail.

La vérification qui tranche : envoyer un message vers une boîte locale et lire les en-têtes du fichier livré. Chaque changement devient alors un oui ou un non en une minute.

Deux pièges annexes ont été corrigés au passage, tous deux nécessaires et aucun suffisant : la clé privée appartenait à _apt:uuidd en 0600 alors que le démon tourne en opendkim — à tester avec su -s /bin/sh opendkim -c "head -c 20 …" — et InternalHosts couvrait trois fois moins d'hôtes que mynetworks de Postfix. OpenDKIM ne signe que le courrier venu de InternalHosts ; le reste, il le vérifie. Un test lancé depuis le relais lui-même part de 127.0.0.1, donc il passe, pendant que les serveurs applicatifs envoient en clair.

À retenir

Authentifier n'est pas être accepté. Une fois SPF, DKIM et DMARC au vert, six messages sur dix continuaient de rebondir : le domaine mitraillait depuis des années des adresses inexistantes, dont une centaine par jour vers @iclaud.com, faute de frappe pour @icloud.com. Les rapports de non-distribution étaient détruits à l'arrivée par le serveur lui-même, la boucle de retour coupée aux deux bouts. À titre de repère, Google demande aux envoyeurs en masse de rester sous 0,30 % de signalements en spam dans Postmaster Tools.

Source : DEV Community