diff options
Diffstat (limited to 'content/operations')
| -rw-r--r-- | content/operations/email.md | 34 |
1 files changed, 34 insertions, 0 deletions
diff --git a/content/operations/email.md b/content/operations/email.md index 89378cf..6299d97 100644 --- a/content/operations/email.md +++ b/content/operations/email.md @@ -66,6 +66,10 @@ _dmarc TXT "v=DMARC1; p=reject; sp=reject; adkim=s; fo=1; aspf=s; ruf=mailto:p ### L'enregistrement DKIM +Le mécanisme DKIM permet au serveur d'ajouter une signature sur les messages qui sortent de Deuxfleurs, pour que les destinataires puissent en attester la validité. +Il s'agit d'une signature RSA basée sur une paire de clefs privée/publique. La clef publique est donée dans l'enregistrement DNS DKIM, et la clef privée est connue +uniquement du serveur Postfix. La signature de chaque message est ajoutée dans un en-tête spécifique. + Référence : <https://www.cloudflare.com/learning/dns/dns-records/dns-dkim-record/> **Exemple de valeurs :** @@ -116,13 +120,43 @@ Cette signature contient les champs suivants : ### L'enregistrement SPF +L'enregistrement SPF sert à aider le serveur de destination à déterminer si le message reçu est légitime ou non, en vérifiant des contraintes sur l'addresse IP par laquelle il a été reçu. +Normalement, c'est l'addresse IP du serveur SMTP de Deuxfleurs, donc on sait qu'on doit rejeter tous les messages venant d'autres addresses. + +Références : <https://fr.wikipedia.org/wiki/Sender_Policy_Framework> + **Exemple de valeurs :** ``` deuxfleurs.fr. 300 IN TXT "v=spf1 mx:out.deuxfleurs.fr ip4:82.66.80.201 -all" adnab.me. 3600 IN TXT "v=spf1 mx mx:adnab.me include:mx.ovh.com -all" +ietf.org. 1794 IN TXT "v=spf1 ip4:50.223.129.192/26 ip6:2001:559:c4c7::/48 a:ietf.org mx:mail.ietf.org ip4:192.95.54.32/27 ip6:2607:5300:60:9ccf::/64 ip4:158.69.166.0/27 ip6:2607:5300:203:1b26::/64 ip4:4.31.198.32/27 ip6:2001:1900:3001:11::/64 include:_spf.google.com ~all" + ``` +**Structure :** + +L'enregistrement commence par `v=spf1`, puis contient un ensemble de directives formées de la manière suivante: + +- Un préfixe pouvant être `+` (résultat favorable), `?` (résultat neutre/aucune règle), `~` (entre le neutre et l'échec, utile pour déboguer), `-` (échec/défavorable). Le préfixe peut être omis, ce qui est interprété comme le préfixe `+`. +- Une paire type/valeur, avec les types suivants: + - `mx` : utiliser un enregistrement DNS de type MX. L'enregistrement `MX` donne un ou plusieurs noms d'hôtes, qui sont eux-même des noms DNS. Ces noms sont ensuite résolus en `A` ou `AAAA` pour trouver les addresses correspondantes. Des `CNAME` peuvent être présents, ce qui donnerait au plus long la chaîne de résolution suivante : `MX -> CNAME -> ... -> CNAME -> A/AAAA`. + - `ip4` : contient directement une plage d'addresses IPv4 + - `ip6` : contient directement une plage d'addresses IPv6 + - `a` : contient un nom d'hôte à résoudre en `A` ou `AAAA` (pouvant utiliser des `CNAME`) + - `include` : contient un nom de domaine ayant une autre règle SPF à inclure + - `ptr` : désuet +- Ou bien le mot `all`, qui correspond à tous les expéditeurs dont l'addresse ne correspond pas aux autres règles + +Par exemple, dans les exemples ci-dessous, voici comment interpréter les différentes règles: + +- `mx:out.deuxfleurs.fr` : accepter le message si l'IP de l'expéditeur est trouvable en suivant les enregistrements `MX` associés à `out.deuxfleurs.fr`. +- `ip4:82.66.80.201` : accepter le message si l'IP de l'expéditeur est `82.66.80.201` +- `include:mx.ovh.com` : accepter le message si il serait accepté par la règle du domaine `mx.ovh.com` (consultable en faisant `dig TXT mx.ovh.com`) +- `a:ietf.org` : accepter le message si il vient de l'addresse IP de `ietf.org` (consultable en faisant `dig A ietf.org`) +- `-all` : rejeter strictement tous les messages venant d'une autre addresse IP + + ### L'enregistrement DMARC |