écriture sur l'enregistrement SPF

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