Cedric Abonnel
67 lines
4.3 KiB
Markdown
67 lines
4.3 KiB
Markdown
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 :
|
|
|
|
| Code | Signification | Rejet conseillé |
|
|
|------|---------------|-----------------|
|
|
| `Pass` | L'IP est explicitement autorisée par le domaine | Non |
|
|
| `Fail` | L'IP n'est pas autorisée | Oui |
|
|
| `Softfail` | L'IP n'est probablement pas autorisée | Optionnel |
|
|
| `Neutral` | Le domaine ne se prononce pas | Non |
|
|
| `None` | Pas d'enregistrement SPF publié | Optionnel |
|
|
| `Permerror` | Erreur permanente (syntaxe SPF invalide, boucle…) | Oui |
|
|
| `Temperror` | Erreur temporaire (DNS injoignable, timeout) | Non recommandé |
|
|
|
|
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. |