Garantir la réputation d'un serveur de mail

La réputation d'un serveur de mail n'est pas uniquement basée sur la qualité¹⁾ des mails qu'il expédie (ou relaie). Pour que les filtres anti-spam du récepteur entrent en jeux, encore faut-il que le mail ait été accepté parce que le serveur expéditeur aura été jugé suffisamment fiable. Cette réputation sera particulièrement importante²⁾ si le serveur héberge des listes.

Au delà d'une bonne configuration du host-serveur lui-même (notamment IPv6) et du logiciel-serveur de courrier, trois principaux protocoles de contrôle tendent à se généraliser : SPF³⁾, DKIM⁴⁾ et DMARC⁵⁾.

L'objectif des ces protocoles est de répondre à la question : “Est-il légitime que ce serveur m'envoie un mail prétendument expédié par expeditrice@domain.tld ? Si oui, ça vaut la peine de décacheter le mail et de voir ce qu'il contient. Sinon, le serveur-récepteur refuse le mail sans même l'ouvrir.

Les trois protocoles utilisent le DNS pour échanger des informations.

Pour des raison de concision, cette fiche décrit la mise en place des outils et la configuration sur une serveur équipé de l'outil d'administration Webmin/Virtualmin sous Debian.

SPF sert à estimer la légitimité d'un serveur à envoyer du mail pour un nom de domaine (par ex. : riseup.net). Autrement dit, il ne s'intéresse pas l'existence d'une adresse mail adossée à ce domaine (par ex. : moi@riseup.net).

SPF permet de déclarer des choses très précises comme : “ce serveur est le seul autorisé à envoyer des mails pour pour <mondomaine.net>”. Mais il permet aussi de déclarer explicitement : “n'importe quel serveur peut envoyer des mail pour <mondomaine.org>”. Chaque récepteur tirera ses propres conclusions de déclarations. Dans le premier cas, le comportement à adopter semble évident. Dans le second, on ne sait que dire ; en tout cas, le protocole ne donne pas la réponse.

Pour des raisons éditoriales, la configuration de SPF pour un serveur est déportée dans une autre fiche.

La principale amélioration apportée par DKIM est l'utilisation d'une signature électronique permettant d'authentifier le serveur expéditeur⁶⁾. Indépendamment de SPIF, cela permet de savoir si le prétendu serveur-expéditeur d'un courriel est bien qui il prétend être⁷⁾. Conjointement à SPIF, il permet au récepteur de savoir que les déclarations SPIF peuvent légitimement être appliquées aux mails qu'il reçoit.

Sous Debian, on commence par installer les paquets nécessaires au traitement des signatures (clés).

# apt-get install opendkim opendkim-tools

Sous Virtualmin, la configuration pour l'intégralité des domaines autorisés à gérer du mail se fait tout simplement en activant DKIM (Signing of outgoing mail enabled? yes) sur la page générale : Email settings > DomainKeys Identified email.

Par défaut, dans Virtualmin, le champ «Extra domains to sign for» contient le hostname du serveur : host.domain.tld, host.

En appliquant la configuration (Save), les clés sont automatiquement générées, les déclarations sont ajoutées au DNS et le serveur d'expédition est configuré pour signer les messages sortants.

À tout moment, la liste des clés ajoutées est alors consultable dans Email Settings > DomainKeys Identified Mail > Domains currently signed.

On remarque que le hostname y figure. Si le hostname n'est pas géré par la machine hôtesse, ce hostname n'est pas porteur d'un lien. C'est normal car la fonctionnalité de gestion du mail host.domain.tld n'est pas activée dans Virtualmin et ne doit pas l'être !

Par défaut, postfix/virtualmin gère le mail de la machine hôtesse répondant au nom de host.domain.tld. Si Virtualmin ne gère pas le DNS pour ce nom de domaine, la clé publique DKIM doit être déclarée manuellement dans la zone où le hostname est défini, c'est-à-dire sur le serveur gérant cette zone¹⁰⁾. Par exemple :

202310._domainkey.host.domain.tld. 10800 IN TXT "v=DKIM1; k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz5mhQcqD/SqyCz2FKjHCY/6CnqQe9q3BvHRScIW0XFq5DmvwGlMZ2zUUGbiINusInqdmdwg3mltDeynsaJ5" "kNZZm6HytM9KgE81YrJfcBV/BUZ0Cs7oizAwGKdsiCJ0DRiDXOKmUeOIOiSSQXoNh6wftOP1pnuLZgMQKechp9UQr654zMkHpOOxO6Byvysciv/Rz5tY5FcKGGVuy8wWDUnFeV57nrMwHyVp6GD6XJ" "7QtfcdCmdOsNI2f7Tzv8sD1ssIw4f/X/+/xCH5+Orrzwxui41jFze87lp1JD70hX8LpJWegp74rDfS08A8Or8n1ImuXesKgmWn0rgbeQG9GRwIDAQAB"

Si l'on souhaite bénéficier de DKIM pour expédier des mail signés pour d'autres noms de domaines que ceux gérés par le serveur, il convient de les ajouter à la listes des «Extra domains to sign for».

On n'oubliera pas de déclarer manuellement la clé dans les zones correspondantes, via un enregistrement TXT, sur les serveurs qui en ont la charge.

Le nom de domaine figurant dans l'enregistrement TXT a une structure particulière :

<selecteur>._domainkey.<nom du domaine de mail>

par exemple:

toto._domainkey.mondomaine.org.

Le nom de domaine sur lequel porte l'enregistrement TXT apparaît bien comme un sous-domaine du nom de domaine pour lequel on valide la signature d'envoi de mail (ici, mondomaine.org.¹²⁾).

La manipulation de la chaîne de caractères constituant la clé est particulièrement délicate, en raison de sa longueur. C'est pourquoi un simple copier/coller est dangereux. En effet, la plupart des interfaces utilisées effectuent un reformatage de cette chaîne de caractères, pour des raisons de présentation ou pour « mâcher le travail » des éditeurs de zone DNS¹³⁾.

Dans un éditeur de texte, on s'assurera donc que l'intégralité de la chaîne de caractères tient en une seule ligne. Si tel n'est pas le cas, on la reformatera pour qu'il en soit ainsi, avant de la copier pour la coller dans l'éditeur de zone DNS.

Une fois la zone enregistrée, on s'assurera que la valeur du champ est bien celle que l'on souhaite. Autrement dit, on s'assure que l'éditeur de zone ne nous a joué de mauvais tour. Plusieurs essais, avec des syntaxes différentes, peuvent être nécessaires pour atteindre le résultat voulu.

Les « ” » ne font pas partie du texte !

1. champ nom de l’enregistrement DNS
   1. on récupère le sélecteur utilisé par le serveur d'envoi de mail (ex : “toto”)
   2. on concatène “._domainkey.”
   3. on concatène le nom du domaine pour lequel on veut valider la signature (ex : “mondomaine.org.”)
2. champ valeur de l'enregistrement DNS
   1. on déclare la version de dkim et le type de signature (ex : “ v=DKIM1; k=rsa; t=s; ”)
   2. on concatène la clé (ex : “ p=MIIBIjANBgkqhkiG9w0B…CmiQIDAQAB ”)

DMARC permet au serveur-expéditeur de préciser au serveur-destinataire comment il souhaite que les informations qu'il a fourni via SPF et DKIM soient interprétées dans les cas ambigus. Sans entrer dans les détails, des déclarations SPF et DKIM strictes, complètes et minimales ne sont pas ambiguës : tout mail non conforme aux déclarations doit finir à la poubelle. Mais ce type de déclaration n'est pas applicable à la majorité des cas.

DMARC permet également au serveur-destinataire de rendre compte au serveur-expéditeur de ce qu'il a fait (le “R” de “reporting”).

• Un éditeur-validateur en ligne d'enregistrement DMARC.
• Serveur dédié : ajouter l'authentification DMARC à Postfix et BIND
• How to eliminate spam and protect your name with DMARC
• Getting DKIM, DMARC and SPF to work with Postfix, OpenDKIM and OpenDMARC
• Build Your DMARC Record in 15 Minutes qui explique clairement qu'est l'“alignement”.

DMARC peut être appliqué de manières progressive.

Sous Virtualmin, l'activation de DMARC et une déclaration minimale s'effectue, serveur par serveur¹⁴⁾ : Server Configuration > DNS Options. Ceci revient à publier, à l'adresse des serveurs de réception, une politique de traitement et des adresses pour recevoir leurs éventuelles notifications. Rien de plus.

Cette configuration minimale ne requiert pas l'installation d'un paquetage supplémentaire (tel opendmarc) car est sans effet sur le comportement du votre serveur à la réception des messages pour les domaines configurés.

Un service en ligne fourni par mail-tester.com permet d'avoir un compte-rendu de la réputation du serveur lorsqu'il expédie un mail pour le compte d'une utilisatrice d'un domaine.

1. pointer son navigateur sur https://www.mail-tester.com/
2. récupérer l'adresse mail indiquée (à laquelle il faudra adressé le mail)
   • NE PAS QUITTER LA PAGE !
3. effectuer l'envoi depuis (via) le serveur qu'on veut tester
4. cliquer sur le lien de vérification

Le service affiche les indications sur la réputation du serveur (pour ce nom de domaine) et donne une bonne idée des choses à améliorer.

Je ne me suis intéressée qu'à la réputation du serveur-expéditeur. La configuration du serveur pour qu'il exploite les protocoles SPF, DKIM et DMARC à la réception des messages sort totalement du périmètre de cette fiche. Il se peut d'ailleurs que votre configuration utilise déjà certains de ces protocoles pour les mails entrants, via des anti-spam tel SpamAssasin.