Fonctionnement du mail : la métaphore postale.
Quand vous écrivez une lettre vous êtes celui qui envoie le message.
Pour un mail, on appelle ça le From du message (RFC5322.From), l’adresse e-mail visible dans votre webmail ou lecteur.
Quand vous glissez votre lettre dans une enveloppe, vous indiquez au dos l’adresse en cas d’erreur de distribution.
Pour un mail, on appelle ça le From de l’enveloppe (RFC5321.MailFrom), cette adresse n’est pas visible mais figure dans les en-têtes masquées,
elle sert à recevoir les erreurs (bounce) mais également à transmettre le mail au serveur d’envoi.
Si vous êtes quelqu’un d’important, vous pouvez tamponner les rabats de l’enveloppe avec votre sceau,
ce qui prouvera que vous en êtes bien l’auteur et que l’enveloppe n’a pas été ouverte.
Pour un mail, on appelle ça la signature DKIM.
SPF
Vous devez indiquer tous vos canaux d’envoi.
Votre site est sur un serveur dédié, l’IP de ce serveur :
v=spf1 ip4:1.2.3.4 ~all
et vos comptes mails sont chez OVH :
v=spf1 ip4:1.2.3.4 include:mx.ovh.com ~all
vous envoyez aussi à partir de Gsuite
v=spf1 ip4:1.2.3.4 include:mx.ovh.com include:_spf.google.com ~all
Le mécanisme « all » à la fin de l’enregistrement, indique que faire si le mail vient d’une adresse non listée.
all absent ou ?all (neutral) = les autres serveurs sont implicitement acceptés.
all ou +all (pass) = les autres serveurs sont explicitement acceptés.
-all (fail) = les autres serveurs sont refusés.
~all (fail) = les autres serveurs sont acceptés mais avec une note négative (spam, quarantaine).
À ce jour, il faut utiliser le mécanisme ~all.
En utilisant -all, le mail va être rejeté au niveau SMTP si son adresse IP n’est pas listée,
ce qui ne permet pas de tester l’authentification DKIM.
C’est le cas pour les redirections (forward) et pour les requêtes DNS sans résultat (délai ou autre) :
avec -all, le mail est rejeté
avec ~all sans DKIM ou DKIM invalide, le mail est en spam ou rejeté
avec ~all et DKIM valide, le mail est accepté.
Erreurs communes produisant un permerror.
Mutliples enregistrements (txt ou spf).
Espace ou guillemet ouvrant ("⠀v=spf1" ""v=spf1"");
Requêtes DNS > 10 (a mx include ptr exists redirect).
Méchanismes inconnus.
Mauvaises implémentations (a:1.2.3.4 mx:1.2.3.4 a: mx: exemple.com).
Méchanismes récursifs (include présent dans un include enfant).
Autres erreurs.
Lettres capitales.
Conformément à la définition de la notation ABNF dans [RFC5234], les noms utilisés ne sont pas sensibles à la casse,
cependant, certains analyseurs n’acceptent aucune capitale.
(RFC7208 Section 4.6.1).
Les requêtes DNS nulles sont limitées à 2,
cette limite est laissée au choix de l’analyseur et certains renvoient un permerror à la première requête sans résultat.
(RFC7208 Section 4.6.4).
Le SPF est relié au From de l’enveloppe,
il indique si le mail a été envoyé par un serveur autorisé ou non.
La signature DKIM est reliée au contenu du message,
elle indique si celui-ci a été modifié ou non.
En cas de redirection, et donc de changement du From de l’enveloppe,
la signature DKIM reste (normalement) puisqu’elle fait partie des en-têtes.
DMARC
La Poste a apporté le courrier, ok,
le sceau était toujours entier, ok,
mais rien ne me dit que c’est bien untel qui a écrit ce courrier et non un usurpateur.
DMARC va ajouté des liens entre ces différentes méthodes d’authentification.
Il va relier le From de l’enveloppe avec le From du message, s’ils sont différents, il y a erreur.
Il va aussi relier le domaine de la signature DKIM avec le From du message, s’ils sont différents, il y a erreur.
Pour l’instant, il suffit qu’un de ces deux liens soit bon pour que le mail soit accepté.
On indique par la règle « p » ce qu’il faut faire en cas d’erreur :
p=none, on accepte le mail
p=quarantine, on met le mail en spam et/ou on le note négativement (peu sûr)
p=reject, on refuse le mail
Importance d’un enregistrement DMARC, d’une politique et de l’analyse des rapports.
Sans enregistrement ou avec une politique à none, certains opérateurs appliquent une politique à quarantine.
La politique déclarée n’est pas permanente, selon les résultats SPF et DKIM (softfail, permerror),
une politique peut être augmentée (de none à quarantine, de quarantine à reject) ou diminuée (de reject à quarantine).
Seule l’analyse des rapports RUA, Reporting URI for Aggregate data, permet de comprendre comment le flux de mails est traité
et comment corriger ou adapter les enregistrements SPF et DKIM selon les canaux d’envoi.
SPOOFING USURPATION
Et voici pourquoi il ne faut pas utiliser les règles p=none ou sp=none de DMARC.
J’écris un mail avec comme From de l’enveloppe xxx@domain1.fr à partir du serveur 1.2.3.4,
le SPF de domain1.fr indique que 1.2.3.4 est autorisé à transmettre ses mails.
1ère authentification réussie.
Je signe le mail avec un DKIM au nom de domain1.fr ou même domain2.fr,
la signature est bonne, le contenu n’a pas été modifié.
2ème authentification réussie.
Enfin, j’utilise president@elysee.fr comme From du message.
Si elysee.fr a une règle DMARC p=none, qui veut dire en clair,
ce n’est pas moi qui ai transmis ce mail, ce n’est pas moi qui l’ai signé,
mais peu m’importe, donc le mail est accepté, et je vais pouvoir spammer à loisir en son nom.
SPF DKIM et DMARC sont généralement interprétés comme étant des mécanismes pour que les mails arrivent bien,
en fait, c’est pour que les spams utilisant votre nom n’arrivent pas.
J’ajoute que si votre règle est p=none et que les spammeurs utilisent votre nom,
votre réputation diminuera, et si vous ne modifiez pas votre politique en quarantine ou reject,
des organisations comme Spamhaus https://www.spamhaus.org/ augmenterons votre note négative,
au risque que la plupart de vos mails soient refusés.
Dit autrement, si on spamme en votre nom mais que vous avez des règles restrictives (quarantine, reject),
vous ne risquez rien vu que vous indiquez ce qu’il y a à faire,
les serveurs de réception savent qu’il faut refuser ces mails,
les spammeurs n’atteignent pas leurs cibles.
CAS DES SOUS-DOMAINES
Il n’y a pas d’héritage du domaine vers le sous-domaine pour SPF et DKIM,
si vous voulez écrire à partir de xxx@info.domain1.fr, il vous faudra
un enregistrement SPF spécifique
une signature DKIM spécifique.
Par contre, il y a un héritage pour DMARC, s’il n’y a pas d’enregistrement spécifique,
la règle « sp= » du domaine parent sera appliquée et en son absence la règle « p= ».
Pour simplifier, il vaut mieux ajouter une règle sp=reject au DMARC du domaine principal,
et créer un enregistrement spécifique au besoin.
Erreur rencontrée sur l’envoi d’un formulaire Hi. This is the mail-send program at ns1.server.com
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<info@siteweb1001.fr> 83.166.143.57 failed after I sent the message.
Remote host said: 550 5.7.1 rejected by DMARC policy for yahoo.fr
--- Below this line is a copy of the message.
Received: from unknown (HELO ns1.server.com) (1.2.3.4)
Return-Path: <postmaster@siteweb1001.fr>
To: info@siteweb1001.fr
Subject: Formulaire de contact
From: siteweb <tagada@yahoo.fr>
L’adresse IP 1.2.3.4 est autorisée par le SPF de siteweb1001.fr
Le mail a une signature DKIM valide pour siteweb1001.fr
Infomaniak (MX de siteweb1001.fr) refuse le mail, puisque
le SPF de yahoo.fr n’autorise pas l’adresse IP 1.2.3.4
le mail n’a pas de signature DKIM pour yahoo.fr
Les paramètres d’envoi du formulaire doivent être
Return-Path: <postmaster@siteweb1001.fr>
To: info@siteweb1001.fr
Subject: Formulaire de contact
From: siteweb <postmaster@siteweb1001.fr>
Reply-To: <tagada@yahoo.fr>