Configuration de PTR, SPF et DKIM

Soumis par ldonnadieu le mer 15/02/2023 - 19:23

Dans l'article précédent, nous avons couvert le fait d'apprendre à votre installation Drupal à envoyer du courrier aux utilisateurs. Mais ce n'est que la moitié de la bataille, maintenant nous devons nous assurer que le courrier que nous envoyons atteint la boîte de réception et non le dossier Spam. Cet article décrit quelques options qui vous offrent des solutions pertinentes. Malheureusement, personne ne peut garantir un taux de réception de 100 %, mais il est tout à fait possible de réduire au minimum le nombre de messages filtrés dans le dossier Spam.

Vous disposez des outils suivants pour rendre votre courrier plus digne de confiance et ainsi le garder hors du dossier Spam :

Enregistrement PTR ;
Enregistrement SPF ;
DKIM.

1. PTR

Un enregistrement de pointeur DNS (pointer record - PTR) fournit le nom de domaine associé à une adresse IP. Un enregistrement PTR est exactement l'inverse de l'enregistrement « A », qui fournit l'adresse IP associée à un nom de domaine. Certains appellent PTR le "Reverse DNS".

Pour lutter contre le spam, la plupart des services de messagerie vérifient le PTR des serveurs qui envoient du courrier entrant. En fonction des résultats de cette vérification, ils placent les lettres dans la boîte de réception ou les filtrent dans les spams. Ainsi, lorsque vous avez un PTR pour votre serveur, et qu'il correspond au nom de domaine figurant après @ dans l'adresse occupant le champ From, le serveur de messagerie récepteur a davantage confiance en votre courrier.

Sans l'enregistrement PTR, votre message électronique n'atteindra pas votre destinataire. En effet, la plupart des serveurs de messagerie rejettent les courriels qui n'en possèdent pas.

En fin de compte, sans enregistrement PTR, les serveurs de messagerie ne savent pas si un message électronique entrant est du spam - et c'est leur travail de garder les messages de spam hors de votre boîte de réception. Donc, s'il n'y a pas d'enregistrement PTR, le courrier électronique ne fonctionnera pas correctement.

Comment ajouter un enregistrement PTR

L'enregistrement PTR peut être ajouté par le propriétaire de l'IP du serveur qui héberge votre site. Cet enregistrement n'a de sens que si vous utilisez un serveur dédié ou un VPS. Si vous occupez un simple compte d'hébergement mutualisé, vous n'en avez probablement pas besoin, car dans la plupart des cas, l'enregistrement est déjà présent et il pointe vers le nom du serveur de l'hébergeur.

Comment vérifier un enregistrement PTR

Il existe un certain nombre de commandes que vous pouvez exécuter pour vérifier le PTR :

commande nslookup

$ nslookup -type=PTR adresse_IP

# Vérifier si free.fr (212.27.48.10) a un PTR
$ nslookup  -type=PTR 212.27.48.10

Server:        127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
10.48.27.212.in-addr.arpa    name = www.free.fr.

Authoritative answers can be found from:

commande dig

$ dig -x adresse-IP

# Vérifier si free.fr (212.27.48.10) a un PTR
$ dig -x 212.27.48.10 PTR +noall +answer

10.48.27.212.in-addr.arpa. 6099    IN    PTR    www.free.fr.

2. Enregistrement SPF

SPF signifie Sender Policy Framework. Il s'agit d'une extension pour SMTP qui permet d'ajouter un enregistrement DNS de type TXT à un nom de domaine et de spécifier les adresses IP à partir desquelles vous pouvez envoyer du courrier.

SPF est un facteur qui contribue à rendre votre courrier plus digne de confiance et moins vu dans les spams. La réputation du domaine que SPF aide à protéger est également importante : lors de l'envoi de spam ou de lettres de phishing, les traceurs peuvent mettre n'importe quelle adresse dans le champ From, ce qui peut entraîner des problèmes pour les propriétaires de noms de domaine qui ont été utilisés à cette fin. Mais l'adresse IP du serveur de messagerie ne peut pas être falsifiée de la sorte. Ainsi, lorsque vous disposez d'un enregistrement SPF, le serveur récepteur le vérifie et agit en conséquence.

Comment ajouter un enregistrement SPF

L'enregistrement SPF est un texte préparé d'une manière spécifique. En voici un exemple :

"v=spf1 +a +mx -all"

Cet enregistrement indique qu'il est autorisé à accepter le courrier provenant des adresses IP spécifiées dans les enregistrements A et MX du domaine pour lequel le SPF a été ajouté. Si les adresses ne correspondent pas, il est préférable de refuser de recevoir le courrier. L'enregistrement peut être plus court, "v=spf1 a mx -all", et produire le même effet.

Syntaxe de l'enregistrement SPF

"v=spf1"   => version SPF utilisée.
"+"        => accepte le courrier. Vous pouvez omettre ce signe.
"-"        => refuse le courrier.
"~"        => accepter le courrier mais le filtrer en Spam.
" ?"       => appliquer des règles régulières au courrier.
"mx"       => adresses IP de tous les serveurs spécifiés dans les enregistrements MX du domaine.
"ip4"      => c'est là que vont les adresses IPv4.
"ip6"      => c'est ici que l'on trouve les adresses IPv6.
"a"        => adresses IP spécifiées dans l'enregistrement A du domaine.
"include"  => permet d'appliquer l'enregistrement SPF d'un autre domaine.
"all"      => règles pour tous les autres domaines qui n'ont pas d'enregistrement SPF.

Exemple d'enregistrement SPF

Examinons l'enregistrement SPF suivant :

"v=spf1 mx a ip4:154.56.125.94 a:example.com mx:example.com include:example.com ~all"

mx => accepte le courrier provenant de ses propres serveurs de messagerie.
a => accepte le courrier des serveurs qui sont listés dans les enregistrements A de son propre domaine.
ip4:154.56.125.94 => accepte le courrier envoyé depuis l'adresse IP 154.56.125.94. Ici, vous pouvez également spécifier des sous-réseaux comme suit : 154.56.125.0/24.
a:example.com => accepte le courrier provenant des serveurs spécifiés dans les enregistrements A de example.com. Ici, vous pouvez spécifier les sous-réseaux comme suit : exemple.com/24.
mx:example.com => accepte le courrier des serveurs spécifiés dans les enregistrements MX de example.com. Les sous-réseaux peuvent être spécifiés de la même manière que pour les enregistrements A.
include:example.com => accepte le courrier suivant les règles dictées par SPF de example.com.
~all => tous les courriers provenant de domaines qui ne sont pas explicitement spécifiés dans le SPF seront filtrés dans le Spam. Remplacez le tilde par un moins (-all) pour refuser purement et simplement ces courriers.

3. DKIM

DKIM signifie DomainKeys Identified Mail. Il s'agit d'une méthode d'authentification qui permet de vérifier si la lettre a réellement été envoyée depuis le domaine spécifié dans le champ From. Cette méthode permet de signer un e-mail avec un identifiant de domaine émetteur, utile pour savoir qui est responsable de l'envoi en cas de réclamations.DKIM est une mesure anti-spam et anti-phishing efficace.

Créer des clés DKIM avec opendkim-tool

Installation d'OpenDKIM

Tout d'abord, vous devez installer opendkim et opendkim-tools. Faites-le en exécutant la commande suivante :

$ apt-get install opendkim opendkim-tools

Configuration d'OpenDKIM

La configuration d'OpenDKIM s'effectue au travers de deux fichiers : /etc/opendkim.conf et /etc/default/opendkim

/etc/opendkim.conf est le fichier principal de configuration d'OpenDKIM. Éditer le fichier et ajouter les lignes suivantes ; si certaines sont déjà présentes les commenter pour éviter tout problème.

$ vi /etc/opendkim.conf

AutoRestart             Yes
AutoRestartRate         10/1h
UMask                   002
Syslog                  yes
SyslogSuccess           Yes
LogWhy                  No

Canonicalization        relaxed/simple

ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts
InternalHosts           refile:/etc/opendkim/TrustedHosts
KeyTable                refile:/etc/opendkim/KeyTable
SigningTable            refile:/etc/opendkim/SigningTable

Mode                    sv
PidFile                 /var/run/opendkim/opendkim.pid
SignatureAlgorithm      rsa-sha256

UserID                  opendkim:opendkim

Socket                  inet:17789@localhost

Voici à quoi correspondent les différents paramètres :

AutoRestart	(booléen) Redémarrage automatique en cas de défaillance. A utiliser avec précaution ; si le filtre tombe en panne instantanément après son démarrage, cela peut provoquer une boucle de fourche serrée (tight fork loop).
AutoRestartRate	Définit la vitesse maximale de redémarrage automatique. Si le filtre commence à redémarrer plus vite que le taux défini ici, il abandonnera et se terminera. Il s'agit d'une chaîne de la forme n/t[u] où n est un entier limitant le nombre de redémarrages dans l'intervalle donné et t[u] définit l'intervalle de temps à travers lequel le taux est calculé ; t est un entier et u définit les unités ainsi représentées ("s" ou "S" pour les secondes, la valeur par défaut ; "m" ou "M" pour les minutes ; "h" ou "H" pour les heures ; "d" ou "D" pour les jours). Par exemple, une valeur de "10/1h" limite les redémarrages à 10 en une heure. Il n'y a pas de valeur par défaut, ce qui signifie que le taux de redémarrage n'est pas limité.
UMAsk	indique les permissions et ID utilisateur/groupe. Accorder les permissions totales pour l'utilisateur défini par son userID, et accorder des permissions en lecture et exécution pour les autres utilisateurs. Demande un masque de permissions spécifique à utiliser pour la création de fichiers. Cela ne s'applique réellement qu'à la création de la socket lorsque Socket spécifie une socket de domaine UNIX, et au PidFile (s'il y en a un) ; les fichiers temporaires sont créés par la fonction mkstemp qui impose un mode de fichier spécifique à la création, indépendamment de l'umask du processus.
Syslog / SyslogSuccess / LogWhy	(booléen) Activer les journaux détaillés pour le service. - Syslog : Enregistrer via des appels à syslog toute activité intéressante - SyslogSuccess : Enregistrer via des appels à syslog des entrées supplémentaires indiquant la signature ou la vérification réussie des messages. - LogWhy : Si la journalisation est activée, elle émet une journalisation très détaillée sur la logique derrière la décision du filtre de signer ou de vérifier un message. La logique derrière la décision n'est pas triviale et peut être déroutante pour les administrateurs qui ne sont pas familiers avec son fonctionnement. Une description de la façon dont la décision est prise peut être trouvée dans la section OPERATIONS de la page de manuel opendkim. Cela provoque une augmentation importante de la quantité de données de journal générées pour chaque message, donc cela devrait être limité à une utilisation de débogage et ne pas être activé pour un fonctionnement général.
Canonicalization	(string) méthode de canonicalisation (mise à la forme canonique) à utiliser lors de la signature des messages : - simple : autorise aucune modification - relaxed : autorise des modificiations mineures comme changer les espaces. - relaxed/simple : L’en-tête du mail utilisera la méthode relaxed et le corps du message utilisera la méthode simple. Sélectionne la ou les méthodes de canonicalisation (mise à la forme canonique) à utiliser lors de la signature des messages. Lors de la vérification, le champ d'en-tête DKIM-Signature : du message spécifie la méthode de canonicalisation. Les valeurs reconnues sont relaxed et simple, telles que définies par la spécification DKIM. La valeur par défaut est simple. La valeur peut inclure deux canonicalisations différentes séparées par une barre oblique ("/"), auquel cas la première sera appliquée à l'en-tête et la seconde au corps du message.
ExternalIgnoreList	(dataset) La liste des des hôtes par lequel les mails peuvent passer sans signature. Identifie un ensemble d'hôtes "externes" qui peuvent envoyer du courrier par l'intermédiaire du serveur en tant que l'un des domaines de signature sans avoir de justificatifs d'identité en tant que tel. Cela a pour effet de supprimer les messages de log "external host (hostname) tried to send mail as (domain)". Les entrées de l'ensemble de données doivent être de la même forme que celles de l'option PeerList. L'ensemble est vide par défaut.
InternalHosts	(dataset) Liste des hôtes à ne pas vérifier et signer : signature sans vérification. Identifie un ensemble d'hôtes internes dont le courrier doit être signé plutôt que vérifié. Les entrées de cet ensemble de données suivent la même forme que celles de l'option PeerList. Si elle n'est pas spécifiée, la valeur par défaut de "127.0.0.1" est appliquée. Naturellement, fournir une valeur ici remplace la valeur par défaut, donc si le courrier de 127.0.0.1 doit être signé, la liste fournie ici doit inclure cette adresse explicitement.
KeyTable	(dataset) Assure la liaison des noms de clés avec les fichiers de clé. Donne l'emplacement d'un fichier de correspondance entre les noms de clés et les clés de signature. S'il est présent, il remplace tout paramètre KeyFile dans le fichier de configuration. L'ensemble de données nommé ici fait correspondre chaque nom de clé à trois valeurs : - (a) le nom du domaine à utiliser dans la valeur "d=" de la signature ; - (b) le nom du sélecteur à utiliser dans la valeur "s=" de la signature ; - et (c) une clé privée ou un chemin vers un fichier contenant une clé privée. Si la première valeur consiste uniquement en un signe de pourcentage ("%"), elle sera remplacée par le domaine apparent de l'expéditeur lors de la génération de la signature. Si la troisième valeur commence par une barre oblique ("/"), ou "./" ou "../", on suppose qu'elle fait référence à un fichier à partir duquel la clé privée doit être lue, sinon il s'agit d'une clé privée codée PEM ou d'une clé privée DER codée en base64 ; dans ce cas, un "%" dans la troisième valeur sera remplacé par le nom de domaine apparent de l'expéditeur. La SigningTable (voir ci-dessous) est utilisée pour sélectionner les enregistrements de cette table à utiliser pour ajouter des signatures en fonction de l'expéditeur du message.
SigningTable	(dataset) La liste des signatures qui seront utilisées pour un message. Le choix se base sur l'adresse expéditrice. Définit une table utilisée pour sélectionner une ou plusieurs signatures à appliquer à un message en fonction de l'adresse trouvée dans le champ d'en-tête From :. Les clés de cette table varient selon le type de table utilisé ; les valeurs de cet ensemble de données doivent inclure un champ contenant un nom trouvé dans la KeyTable qui identifie la clé à utiliser pour générer la signature, et un second champ facultatif nommant le signataire du message qui sera inclus dans la balise "i=" de la signature générée. Notez que la valeur "i=" ne sera pas incluse dans la signature si elle entre en conflit avec le domaine de signature (la valeur "d="). Si le premier champ ne contient qu'un caractère "%", il sera remplacé par le domaine trouvé dans le champ d'en-tête From :. De même, dans le deuxième champ facultatif, tout caractère "%" sera remplacé par le domaine trouvé dans le champ d'en-tête From :. Si cette table spécifie un fichier d'expressions régulières ("refile"), les clés sont des motifs joker qui sont comparés à l'adresse trouvée dans le champ d'en-tête From :. Les entrées sont vérifiées dans l'ordre dans lequel elles apparaissent dans le fichier. Pour tous les autres types de bases de données, le nom complet user@host est vérifié en premier, puis simplement host, puis user@.domain (avec tous les superdomaines vérifiés en séquence, ainsi "foo.example.com" vérifierait d'abord "user@foo.example.com", puis "user@.example.com", puis "user@.com"), puis .domain, puis user@, et enfin . Dans tous les cas, seule la première correspondance est appliquée, sauf si MultipleSignatures est activé, auquel cas toutes les correspondances sont appliquées.
Mode	(string) Le mode opératoire d'OpenDKIM. (s) signature et (v) vérification. Sélectionne les modes de fonctionnement. La chaîne est une concaténation de caractères qui indiquent le ou les modes de fonctionnement souhaités. Les modes valides sont s (signataire) et v (vérificateur). La valeur par défaut est sv, sauf en mode test (voir la page de manuel opendkim), auquel cas la valeur par défaut est v. Lorsque le mode signature est activé, l'une des combinaisons suivantes doit également être définie : - (a) Domain, KeyFile, Selector, no KeyTable, no SigningTable ; - (b) KeyTable, SigningTable, no Domain, no KeyFile, no Selector ; - (c) KeyTable, SetupPolicyScript, no Domain, no KeyFile, no Selector.
PidFile	(string) Emplacement du fichier de pid contenant l'identifiant processus du service. Spécifie le chemin d'accès à un fichier qui doit être créé au début du processus et qui contient l'ID du processus.
SignatureAlgorithm	(string) L'algorithme de chiffrement choisi pour encoder les signatures. Sélectionne l'algorithme de signature à utiliser lors de la génération des signatures. Utilisez 'opendkim -V' pour voir la liste des algorithmes supportés. La valeur par défaut est rsa-sha256 si elle est disponible, sinon ce sera rsa-sha1.
UserID	(string) L'utilisateur et son groupe qui exécutera le service OpenDKIM. Tente de devenir le userid spécifié avant de commencer les opérations. La valeur est de la forme userid[:group]. Le processus se verra attribuer tous les groupes et l'ID du groupe primaire de l'utilisateur nommé, sauf si un autre groupe est spécifié.
Socket	(string) Le port d'écoute sur lequel Postifx et OpenDKIM échangeront les messages. Pour écouter en local sur le port 17789: 17789@localhost. Spécifie le socket qui doit être établi par le filtre pour recevoir les connexions de sendmail afin de fournir le service. socketspec est sous l'une des deux formes suivantes : - local:path, qui crée un socket de domaine UNIX au chemin spécifié, - ou inet:port[@host] ou inet6:port[@host] qui crée un socket TCP sur le port spécifié et dans la famille de protocole spécifiée. Si l'hôte n'est pas donné sous la forme d'un nom d'hôte ou d'une adresse IP, la socket écoutera sur toutes les interfaces. Une adresse IP littérale doit être placée entre crochets. Cette option est obligatoire dans le fichier de configuration ou sur la ligne de commande.

Éditer ensuite le fichier /etc/default/opendkim et ajouter la ligne suivante :

$ vi /etc/default/opendkim
    
     SOCKET="inet:17789@localhost"

Il faut modifier le port si celui-ci est différent dans le fichier de configuration précédent. Il faut être attentif sur le port défini précédemment afin de conserver le même à travers les différents fichiers de configuration.

Création des dossiers

Nous allons à présent créer les dossiers qui vont contenir toutes les données d'Open DKIM comme les hôtes, les signatures, etc.

# Créer la structure
$ mkdir /etc/opendkim
$ mkdir /etc/opendkim/keys

Autoriser les hôtes

Nous allons maintenant spécifier les hôtes autorisés à signer les e-mails avec OpenDKIM.

Créer le fichier /etc/opendkim/TrustedHosts

$ vi /etc/opendkim/TrustedHosts

Nous pouvons, afin de déclarer les domaines, utiliser des wildwards (*)

 #Ne pas toucher les 3 premieres lignes
127.0.0.1
localhost
192.168.0.1/24

# Exemple de configuration pour le domaine *.example.tld
*.example.tld

Dictionnaire de clés

Le fichier dictionnaire est là pour assurer la liaison de chaque domaine à sa clé correspondante.

Créer le dictionnaire de clé :

$ vi /etc/opendkim/KeyTable

Ajouter la ligne suivante :

mail._domainkey.example.tld example.tld:mail:/etc/opendkim/keys/example.tld/mail.private

Dans cet exemple, le domaine example.tld devra aller chercher sa clé dans /etc/opendkim/keys/example.tld/mail.private.

Il est important que vous adaptiez cette configuration à votre domaine.

Dictionnaire de signature

Le fichier dictionnaire de signature est là pour assurer la liaison de chaque adresse e-mail vers son domaine correspondant.

Créer le dictionnaire de signature

$ vi /etc/opendkim/SigningTable

Ajouter la ligne suivante ( l'utilisation des wildcards est autorisée ) :

 *@example.tld mail._domainkey.example.tld

Dans cet exemple les adresse en @example.tld devront être redirigées vers le sélecteur mail._domainkey.example.tld.

Il est important que vous adaptiez cette configuration à votre domaine.

Génération des clés publiques et privées

Nous allons à présent générer nos paires de clés publiques et privées.

Se déplacer dans le dossier qui recevra les clés

$ cd /etc/opendkim/keys

Créer un dossier pour notre nouveau domaine example.tld :

$ mkdir example.tld

Se déplacer dans le dossier du domaine :

$ cd example.tld

Générer les clés pour notre domaine example.tld :

# D - répertoire pour les clés générées ;
# d - domaine pour lequel les clés seront utilisées ;
# s - nom du sélecteur, identificateur de ligne, qui peut être n'importe quoi.
$ opendkim-genkey -D . -d example.tld -s mail

Cette commande va créer deux fichiers : mail.private la clé privée et mail.txt la clé publique.

Changer le propriétaire de la clé privée :

$ chown opendkim:opendkim mail.private

2. Ensuite, créez un répertoire dkim. C'est là que les clés seront stockées :

mkdir /etc/exim4/dkim

3. Changez les permissions sur ce répertoire de root à Debian-exim :

chown -R Debian-exim:Debian-exim /etc/exim4/dkim

5. Maintenant vous devez aller dans /etc/exim4/dkim/ et renommer mail.private en example.com.key :

cd /etc/exim4/dkim/
mv mymail .private mydomain.com.key

6. Changez les permissions sur example.com.private (fichier de clé privée) de root à Debian-exim :

chown -R Debian-exim:Debian-exim /etc/exim4/dkim/mydomain.com.key
chmod 640 /etc/exim4/dkim/mydomain.com.key
C'est fait !

Configuration du DNS

mail.txt (cat /etc/exim4/dkim/mymail.txt) devrait avoir ce qui suit :

mymail. _domainkey IN TXT ("v=DKIM1 ; k=rsa ; " "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC57fv+meeGTF2gtQ/FO1WAT7hYrPTnKir06k3YR6ZBCLhAVbfEOAZ9OkVTAEf67T61eRY8w8hojnN9dxd07XIZ8KyatNXajWfYo3g0YDWopTfVfoaI4XFXqQH8V6iXyobArpSe3MSTqNFuS+w498JoHAkeXXhcl6kmjdSGkPtwIDAQAB" ) ;

---- Clé DKIM mymail pour mydomain.com

Cette information doit être ajoutée à l'enregistrement TXT de la zone DNS. Le champ du nom reçoit :

mymail._domainkey

Le champ de contenu reçoit :

v=DKIM1 ; k=rsa ; " "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC57fv+meeGTF2gtQ/FO1WAT7hYrPTnKir06k3YR6ZBCLhAVbfEOAZ9OkVTAEf67T61eRY8w8hojnN9dxd07XIZ8KyatNXajWfYo3g0YDWopTfVfoaI4XFXqQH8V6iXyobArpSe3MSTqNFuS+w498JoHAkeXXhcl6kmjdSGkPtwIDAQAB

Maintenant, vous pouvez simplement supprimer mymail.txt.

Pour vérifier si tout va bien, exécutez la commande suivante :

dig txt mymail._domainkey.mydomain.com | grep DKIM

La réponse devrait ressembler à ceci :

mymail._domainkey.mydomain.com. 2214 IN TXT "v=DKIM1\ ; k=rsa\...

Configuration des pratiques de signature de domaine d'auteur DKIM (DKIM ADSP)

Pour spécifier DKIM Author Domain Signing Practices (DKIM ADSP), vous devez ajouter un enregistrement supplémentaire à TXT DNS :

_adsp._domainkey.mydomain.com IN TXT "dkim=all"

où :

all - aucune lettre non signée ne peut être envoyée ;
discardable - toutes les lettres non signées doivent être verrouillées du côté du destinataire ;
unknown - le domaine peut signer tout ou partie des lettres.