Mise à jour du 17/12/2021.
Des mécanismes de protection ont été mis en place pour lutter à la fois contre les pourriels et l'usage abusif de la messagerie par un tiers non autorisé. Pour ne pas influer sur les standards établis de longue date par l'IETF en matière de messagerie, ces mécanismes ont leur origine dans le DNS du domaine de chaque serveur de messagerie. Notez que la confiance à leur accorder est la même que celle que vous pouvez accorder à ces DNS. Or nous savons aujourd'hui que les DNS qui constituent une arborescence ouverte sont le talon d'Achille de la plupart des attaques. Si on ne peut pas toujours empecher ces courriels frauduleux, il est quasiment toujours possible, avec un minimum de compétence, de s'assurer de la fiabilité de leurs origines.
SPF pour Sender Policy Framework permet au serveur de messagerie destinataire de vérifier, lors de la livraison du courrier, qu'un courrier prétendant provenir d'un domaine spécifique est soumis par une adresse IP autorisée par les administrateurs de ce domaine. Ce mécanisme a été mis au point pour lutter contre le spoofing (usurpation de provenance).
SPF est un enregistrement dans un DNS du domaine principal de type TXT. il est de la forme :
v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all
La première partie (spf1) est la version de SPF. La seconde partie et la liste des adresses des MTA (serveurs de messagerie) autorisés pour ce domaine. La troisième partie peut prendre plusieurs formes :
a a/<prefix-length> a:<domain> a:<domain>/<prefix-length>
a seul signifie que tous les enregistrements DNS de type Adoivent être parcourus pour ce domaine. Si la connexion a lieu sur IPv6, A devient AAAA. Les autres formes permettent d'autoriser les machines pour les sous-domaines qui suivent le double point.
La quatrième partie peut prendre 3 formes mais nous n'en considérerons que deux : -all et ~all. La forme -all signifie échec brutal. Cela indique que les serveurs qui ne sont pas répertoriés dans l'enregistrement SPF ne sont pas reconnus ou autorisés à envoyer des e-mails pour le domaine, le message doit donc être rejeté par le serveur de réception. ~all est plus permissif. Fondamentalement, cela signifie que le serveur n'est pas répertorié dans l'enregistrement SPF, mais il ne devrait pas être rejeté catégoriquement par le serveur de réception. Au lieu de cela, le message sera marqué comme spam possible.
DKIM ou DomainKeys Identified Mail est encore connue sous le nom de "signature de courriels". Tout comme un enregistrement SPF, DKIM repose sur un enregistrement TXT qui est ajouté au DNS d'un domaine. Si SPF peut être considéré comme l'adresse de l'expéditeur sur un courrier, DKIM peut être vu comme une lettre expédiée en recommandé car ce mécanisme renforce la confiance du transport entre le serveur qui envoi et celui qui reçoit. En effet, le but de DKIM est de prouver que le contenu d'un courriel n'a pas été falsifié, que les en-têtes du message n'ont pas changé (par exemple, en ajoutant une nouvelle adresse from) et que l'expéditeur du courriel appartient au domaine auquel est attaché l'enregistrement DKIM ou, à minima, est autorisé par le propriétaire du domaine à envoyer des courriels en son nom.
DKIM utilise un algorithme de chiffrement pour créer une paire de clefs électroniques (publique et privée) qui gère cette « confiance ». La clé privée reste sur le serveur de messagerie sur lequel elle a été créée. La clé publique est ce qui est placé dans l'enregistrement DNS TXT. Dans cet enregistrement, il y a quelques valeurs indispensables :
Comme tout algorithme de chiffrement (asymétrique comme symétrique), le destinataire peut utiliser la clef publique pour déchiffrer le hash-code du courriel (la fameuse "signature" DKIM dans une des en-têtes du courriel) et recalculer ce dernier à partir du message reçu. Si les deux hash-codes correspondent alors le courriel est réputé "de confiance" sinon le courriel est compromis.
DMARC est l'acronyme de Domain-based Message Authentication, Reporting and Conformance. Il s'agit d'un protocole d'authentification, de politique et de rapport de courrier électronique qui est en fait construit autour de SPF et de DKIM. Il a trois objectifs fondamentaux :
Quel que soit l'outil que vous utilisez, un enregistrement DMARC utilise un certain nombre de « propriétés ». Il n'y a vraiment que 2 propriétés réellement requises : v et p. D'autres propriétés sont purement facultatives et les experts DMARC ne sont pas d'accord sur les propriétés facultatives recommandées et celles qui ne le sont pas. Examinons d'abord les propriétés requises :
Voici à qui ressemble un enregistrement DMARC :
v=DMARC1 ; p=none ; rua=mailto:dmarc@mondomaine.com ; fo=1
Comme on l'aura compris, SPF et DMARC sont de simples enregistrements dans le DNS du domaine. Il s'agit donc d'une fonction d'administration basique. Il n'est est pas de même pour DKIM qui suppose la production d'un bi-clef et la mise en place d'un code de chiffrement/déchiffrement. Fort heureusement, la plate-forme va nous fournir les outils nécessaires. La commande suivante les installe :
apt install opendkim opendkim-tools
Sauvegardez les fichiers /etc/opendkim.conf et /etc/default/opendkim en en faisant une copie sur les mêmes répertoires pourvues de l'extension .bak. Suivez alors la procédure :
[Commentez ce qui devrait être la ligne 37] #Socket local:/run/opendkim/opendkim.sock
puis ajoutez à la fin du fichier :
Domain piapp.fr KeyFile /etc/opendkim/dkim.key Selector dkim Socket inet:12301@localhost
[Commentez ce qui devrait être la ligne 20] #SOCKET=local:$RUNDIR/opendkim.sock
Ajoutez en fin de fichier :
SOCKET=inet:12301@localhost
# Entrées DKIM milter_protocol = 2 milter_default_action = accept smtpd_milters = inet:localhost:12301 non_smtpd_milters = inet:localhost:12301
mkdir /etc/opendkim cd /etc/opendkim opendkim-genkey -t -s dkim -d piapp.fr cp dkim.private dkim.key chmod 660 ./* chmod 770 /etc/opendkim chown -R root:opendkim /etc/opendkim systemctl enable opendkim systemctl restart opendkim systemctl restart postfix
Rédaction par Jean-Marie Piatte (1983-2021)