DMARC : toi aussi aide tes petits camarades à vérifier qu’ils n’ont pas merdé (1/2)
Parce que personne n’est parfait, surtout pas toi…
DMARC, c’est le machin qui est imposé maintenant par Google, Microsoft & Co dès que tu veux leur envoyer un message. Et en vrai, c’est pas une si mauvaise idée que ça. Le principe de base est le suivant :
- on t’a obligé à avoir du SPF, sinon on refuse tes messages. Mais le souci, c’est que les redirections (fréquentes dans ce domaine), ça casse tout et on ne peut rien y faire ;
- on t’a du coup obligé à avoir du DKIM. Ça signe tous les messages, et ça permet de s’assurer qu’effectivement, ça vient bien de là où ça prétend venir.
On a donc, d’une certaine manière, résolu une partie du problème : si le SPF merde pour une raison ou pour une autre, DKIM peut permettre de s’assurer que les messages sont bien légitimes. Inversement, si DKIM merde (non-signature, message technique d’un relais, etc…), on peut au moins s’assurer que le message vient du bon endroit.
ais, il manque quand même un élément crucial à tout ça : que faire des messages « non-conformes » ? Qui va décider que les messages non-signés DKIM ou non-provenant de la bonne adresse SPF, faut les jeter à la poubelle ou pas ?
DMARC to the rescue!!
C’est précisément là qu’intervient DMARC : l’idée est de donner une politique générale sur ce qu’il faut faire si le message semble chelou. « Chelou » en DMARC, ça veut dire qu’il vient du mauvais endroit (donc viole la politique SPF) ET qu’il n’est pas signé (donc viole la politique DKIM).
Et quand on y réfléchit bien, un tel message est effectivement tout sauf légitime : aucune raison d’accepter un message non-signé qui vient d’une IP russe^Wchinoise^Wde Google. En plus, DMARC permet de recevoir des rapports qui donnent des indications précieuses sur les messages qui ont été reçus par les destinataires.
Petite précision importante, c’est bien un ET et pas un OU : le protocole prévoit le fait qu’un message peut être redirigé (donc violer sciemment la politique SPF, mais en conservant dans la plupart des cas la signature DKIM d’origine) ou que certains messages de service (abonné absent, mauvaise passerelle, etc…) peuvent ne pas être signés.
Tu vas donc pouvoir indiquer comment tu veux que tes messages soient traités en cas de souci, mais en plus, on va t’informer de ce qui a été fait et pourquoi. Ça peut aussi te permettre de repérer les p’tits malins qui essaient de te barber au passage…
Et la politique DMARC en question, ça ressemble à quoi ? 3 formes possibles :
- ''none'' : tu fais rien, je veux juste avoir les rapports, c’est tout
- ''quarantine'' : tu classes en pourriel
- ''reject'' : pas la peine d’accepter les messages, visiblement, c’est de la merde
Dans les deux derniers cas, tu peux même spécifier un pourcentage de message qui subiront ce traitement. L’idée est ici de permettre à de grosses organisations, qui envoient beaucoup de messages, de progressivement mettre en place le système et de permettre à leurs usagers de se rendre compte qu’ils font de la merde.
Bon, vas-y, tu me l’as vendue ta merde, comment je fais pour ça chez moi ?
La première chose à faire est de s’assurer que tu peux recevoir les rapports DMARC des autres. Pour cela, c’est relativement simple, il suffit d’ajouter un enregistrement de ce type dans ta zone :
_dmarc.tamere.lol. 3600\ IN\ TXT\ "v=DMARC1; p=none; rua=mailto:postmaster@tamere.lol;"\
Avec ça, tu précises :
- tu as une politique DMARC (doh!)
- tu précises qu’il n’y a pas de politique pour le moment ''none''
- tu précises où tu veux recevoir les mails de rapport
Petite précision supplémentaire, si tu veux recevoir les rapports DMARC sur une adresse qui n’est pas dans le domaine à protéger, tu dois rajouter dans le domaine en question un enregistrement de type TXT dans la zone de réception :
youplaboom.com._report._dmarc.tamere.lol. 21600 IN TXT "v=DMARC1;"
Dans cet exemple, à condition d’avoir posé un enregistrement ''_dmarc'' dans la zone youplaboom.com
, tu peux recevoir les rapports avec une adresse en @tamere.lol
.
Ces rapports viennent sous forme de fichiers XML zippés ou gzippés à l’adresse indiquée. Ils ne sont pas bien compliqués à lire « à la main », mais il y a plein de logiciels en ligne qui permettent de visualiser de manière un peu plus simple les choses et de repérer plus facilement les erreurs de configuration.
Pour commencer, il est très fortement recommandé de laisser pendant quelques jours, voire quelques semaines, la politique à ''none''. Pour une raison très simple : ça permet de récupérer des données et de voir si ton serveur de courriels est correctement configuré. On se rend compte de belles conneries parfois en faisant ça : un relais bizarrement fait, des signatures DKIM qui ne correspondent pas, etc…
Une fois que tu es confiant dans ce que tu as dans ton serveur de messagerie, tu peux commencer à changer la politique et mettre quelque chose de plus restrictif. Tu peux même préciser un pourcentage de traitement (avec la commande pct=<chiffre entre 0-100>
) pour dire que tu veux qu’un certain pourcentage de message soit traité de cette manière là. L’idée est toujours la même : aller le plus progressivement possible vers la politique la plus stricte possible, à savoir p=reject;
.
Protéger aussi les autres
Une bonne idée avant de fermer tout ça : si tu as des domaines dont tu ne te sers pas pour envoyer du courriel, tu as probablement grandement intérêt à préciser les élements suivants :
- SPF à
v=spf1 -all
- DMARC à
v=DMARC1; p=reject; rua=mailto:postmaster@tamere.lol;
Cela permet de préciser à tout ceux qui font du DMARC qu’il est TOTALEMENT anormal de recevoir des messages sur ce domaine. De cette manière, non seulement tu te protèges toi (ta réputation, les noms de domain que tu as acheté), mais tu protèges aussi les autres des cyber-squatteurs et autres enfoirés qui pourraient essayer de te barber…
Conclusage
Voilà, t’as déjà de quoi t’amuser un moment et tu vas pouvoir voir non seulement si ta configuration est bonne dans tous les cas, mais en plus voir s’il n’y a pas des enfoirés qui essaient de te la mettre à l’envers.
Dans le prochain épisode, nous verrons comment faire pour envoyer des zolis rapports à tous nos correspondants histoire de rendre service à tout le monde en plus ;)