Filtrer les mails selon le résultat SPF

Quand on gère un serveur de messagerie, le SPF (Sender Policy Framework) est l'un des premiers remparts contre l'usurpation d'identité. Concrètement, il permet à un domaine de déclarer dans son DNS quelles adresses IP ont le droit d'envoyer des mails en son nom. À la réception, le serveur vérifie cette correspondance et écrit le résultat dans un en-tête : Received-SPF.

Reste à savoir quoi faire de ce résultat. Tous les verdicts SPF ne se valent pas, et rejeter trop large revient vite à perdre des mails légitimes.

Les codes de retour SPF

Voici les sept valeurs qu'on peut rencontrer dans Received-SPF, et ce qu'il faut en faire :

Les deux candidats évidents au rejet automatique sont Fail et Permerror. Le premier dit clairement « cette IP n'a rien à faire ici » ; le second signale un enregistrement cassé, ce qui est rare chez un expéditeur sérieux.

Softfail est plus délicat : beaucoup de domaines mal configurés y atterrissent, donc rejeter sur ce critère seul génère des faux positifs. Mieux vaut l'utiliser comme un signal parmi d'autres (typiquement via un score SpamAssassin) plutôt que comme motif de rejet sec.

Temperror ne doit jamais déclencher un rejet définitif : le problème vient d'un DNS qui ne répond pas, pas du mail lui-même. Un rejet temporaire (code 4xx) est en revanche acceptable, le serveur émetteur réessaiera.

Mise en pratique avec Postfix

Postfix permet de filtrer sur les en-têtes via la directive header_checks. Dans main.cf :

header_checks = regexp:/etc/postfix/header_checks

Puis dans /etc/postfix/header_checks :

/^Received-SPF: Fail/      REJECT SPF Fail - IP non autorisee
/^Received-SPF: Permerror/ REJECT SPF Permerror - enregistrement SPF invalide

Après modification, recharger Postfix :

postfix reload

À noter : header_checks agit sur les en-têtes déjà présents. Si on veut que la vérification SPF soit faite par Postfix lui-même au moment de la réception, le bon outil est plutôt policyd-spf (paquet postfix-policyd-spf-python sous Debian), qui s'intègre via smtpd_recipient_restrictions et permet de rejeter avant même que le mail soit accepté.

L'approche par scoring avec SpamAssassin

Plutôt que de couper net, on peut intégrer SPF à un score global. SpamAssassin expose plusieurs règles dédiées :

• SPF_FAIL : ajoute un score significatif
• SPF_SOFTFAIL : score modéré
• SPF_PERMERROR : signale une config cassée
• SPF_HELO_FAIL : échec sur l'identité HELO

L'intérêt du scoring, c'est de combiner SPF avec d'autres signaux (DKIM, DMARC, listes noires, contenu). Un mail qui échoue uniquement à SPF mais passe tout le reste mérite peut-être un passage en spam plutôt qu'un rejet pur. Inversement, un cumul SPF_FAIL + DKIM cassé + IP sur une RBL ne laisse pas beaucoup de doute.

Quelques précautions avant de mettre en production

Avant d'activer un rejet sur Fail, deux réflexes utiles :

D'abord, regarder les logs en mode passif pendant quelques jours. Loguer les verdicts SPF sans rejeter permet de mesurer le volume concerné et de repérer les expéditeurs légitimes mal configurés (il y en a toujours, y compris des prestataires connus).

Ensuite, vérifier que les mails forwardés ne sont pas pénalisés. Un mail transféré perd souvent son alignement SPF puisque l'IP de réémission n'est pas celle déclarée par le domaine d'origine. C'est précisément le problème que DKIM et ARC sont censés résoudre, mais tous les serveurs ne les implémentent pas correctement.

Le SPF est un bon premier filtre, pas une solution complète. Combiné à DKIM et DMARC, il forme la base de l'authentification mail moderne ; isolé, il reste utile mais imparfait.