par Dans cette avant dernière partie de ma série d’articles sur la mise en place d’un serveur mail, (la dernière sera la conclusion), nous allons mettre le coup final à notre configuration en mettant à jour nos enregistrements DNS.
Dans l’idéal, vous gérez vous même votre DNS, sinon, faites les modifications indiquées dans l’interface de votre registar.
Ces trois enregistrements s’appuient sur de simples champss TXT, afin que tous les resolvers les comprennent.
Il fut un temps ou on trouvait un champ SPF mais celui ci a été abandonné car pas vraiment de RFC pour cela. Il est conseillé maintenant de ne faire qu’un enregistrement TXT.
Bref, c’est tout simple, mais c’est vital, du moins, pour votre système de messagerie !
I – SPF
Cet enregistrement va stipuler une ou plusieurs IP(s) que l’ont autorise à envoyer des mails en notre nom.
Dans votre fichier de zone, indiquez :
domaine1.fr. IN TXT "v=spf1 ip4:ipserveurmail mx -all"
On indique d’accepter les mails venant de notre IP et de refuser strictement les autres.
II – DKIM
Cet enregistrement indique la clé publique correspondant à la clé privée utilisée par Rspamd pour signer les mails.
Un serveur distant pourra alors vérifier l’authenticité du mail en vérifiant si la clé privée utilisée pour la signature correspond à la clé publique publiée dans le DNS.
Reprenez la clé publique que vous aviez gardé sous le coude dans la partie VI :
dkim._domainkey IN TXT ( "v=DKIM1; k=rsa; " "p=plein de caracteres eventuellement sur plusieurs lignes" ) ;
Insérez tout cela dans votre fichier de zone, tout simplement.
III – DMARC
Ce n’est pas à proprement parlé un système de protection, mais plus une façon de dire ce qu’il faut faire avec des mails qui ne passe pas votre politique SPF et/ou DKIM.
Une consigne pour le SMTP qui reçoit en quelque sorte. A ne pas négliger, car l’absence de ce champ peut compromettre la livraison de vos mails.
Insérez une ligne semblable à la suivante :
_dmarc.domaine1.fr. IN TXT "v=DMARC1; p=none; rua=mailto:postmaster@domaine1.fr;ruf=mailto:postmaster@domaine1.fr"
le p indique la politique à appliquer chez le SMTP si un mail reçu en votre nom (de domaine) ne passe ni SPF, ni DKIM.
Il est possible de spécifier :
- none, ne rien faire, mais juste le consigner dans les rapports envoyés à postmaster@domaine1.fr
- quarantine : mettre le mail en spam.
- reject : le rejeter
rua indique à quelle adresse recevoir les reports agrégés, ruf indique où recevoir les reports détaillés (envoyés à chaque fois qu’un mail en votre nom est refusé)
Pour plus d’informations : https://dmarc.org/wiki
Au début, disons le premier mois, utilisez un p=none et une fois qu’on voit que tout est OK (les mails refusés le sont à juste titre et non pas du à une boulette de votre côté), vous pouvez passer sur p=quarantine, ou p=reject.
Bien sur, une fois ces ajouts faits, on pense à incrémenter le sérial du fichier de zone, puis on recharge bind :
# rndc reload
IV – Tests
Pour tester, on va utiliser dig et au passage, l’interrogation se fera auprès du DNS de Google pour être sur que la propagation DNS est bonne.
# dig domaine1.fr TXT @8.8.4.4 +short
Va vous renvoyer les enregistrements TXT, dont le SPF.
# dig dkim._domainkey.domaine1.fr TXT @8.8.4.4 +short
Va vous renvoyer votre DKIM.
# dig _dmarc.debugo.fr TXT @8.8.4.4 +short
Bah, le Dmarc hein…
On peut aussi utiliser des outils en ligne : http://www.appmaildev.com, https://mxtoolbox.com, etc…Il en existe plein d’autres…
V – Conclusion
Bah voila, ce n’était pas la partie la plus compliquée, mais à partir de maintenant, vous pouvez envoyer des messages en étant clean et reconnu par vos pairs !
Il existe aussi le système ARC, mais nous en parlerons dans un article complémentaire.
Et voila, plus qu’à faire une petite conclusion générale et on en aura fini avec notre serveur de mails.
