Outils pour utilisateurs

Outils du site


garantir_la_reputation_d_un_serveur_de_mail

Garantir la réputation d'un serveur de mail

Problématique

La réputation d'un serveur de mail n'est pas uniquement basée sur la qualité1) des mails qu'il expédie (ou relaie). Pour les filtres anti-spam du récepteur entrent en jeux, encore faut-il que le mail ait été accepté, que le serveur expéditeur ait été jugé suffisamment fiable. Cette réputation sera particulièrement importante2) 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 : SPF3), DKIM4) et DMARC5).

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.

Mise en place

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

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.

DKIM

La principale amélioration apportée par DKIM est l'utilisation d'une signature électronique permettant d'authentifier le serveur expéditeur6). Indépendamment de SPIF, cela permet de savoir si le prétendu serveur-expéditeur d'un courriel est bien qui il prétend être7). 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.

Mise en place

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.

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.

Sous Virtualmin, si la gestion du mail est activée pour un domaine mais que la zone est gérée par un autre serveur8), les enregistrements DNS devront être ajoutés manuellement dans les zones concernées9),

DMARC

SPF et DKIM doivent avoir été préalablement configurés et amplement testés avant d'activer DMARC.

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”).

Ressources

Mise en place

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

En cours de rédaction…

Sous Virtualmin, l'activation de DMARC et une déclaration minimale s'effectue, serveur par serveur10) : 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.

La réception

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.

1)
Au sens spam/ham.
2)
Pour ne pas dire vitale !
3)
Sender Policy Framework.
4)
DomainKeys Identified Mail.
5)
Domain-based Message Authentication, Reporting and Conformance.
6)
Par défaut, le protocole d'acheminement de mail d'internet ne vérifie pas que le serveur qui prétend être à l'origine de l'envoi est bien qui il prétend être.
7)
En cas de problème, on sait à qui s'adresser.
8)
Registrar ou autre.
9)
C'est pas parce qu'on utilise un outil d'administration qu'on ne doit pas savoir ce qu'on fait ;-)
10)
Domaine pas domaine.
garantir_la_reputation_d_un_serveur_de_mail.txt · Dernière modification: 2018/11/06 14:13 par flaz