Comme dans le billet relatif à la configuration initiale du DNS, j’appelle « new.example » le domaine acheté et « old.dyn.example » le domaine gratuit précédemment utilisé. Pour la configuration du DNS, je donnerai à chaque fois la saisie à faire et le résultat obtenu dans la syntaxe du DNS.
Avant d’entrer dans le vif du sujet, commençons par configurer le DNS pour dire que le serveur qui gère les adresses de type « quelqu-un@new.example » est « new.example ». Cela se fait avec un enregistrement MX :
Name : new.example
Priority : 10
Hostname : new.example
TTL : 86400
⇓
new.example. 86400 IN MX 10 new.example.
Le problème initial
La messagerie souffre d’un important volume de SPAM, souvent malintentionné. Pour le combattre, diverses mesures ont été mises en place au fil du temps. Par respect pour l’interopérabilité, ces mesures sont rarement bloquantes en elles-mêmes ; chaque serveur de messagerie met en œuvre plusieurs techniques et pondère les résultats pour décider si un message est du SPAM ou non.
Avoir un nom de domaine gratuit, une adresse IP résidentielle, et que cette adresse IP puisse changer sont déjà trois mauvais points dans l’évaluation qui est faite des messages envoyés par mon serveur. Les problèmes liés à l’adresse IP peuvent être restreints en configurant le serveur de messagerie pour passer par un « smarthost » lors de l’émission de messages. Dans mon cas, accédant à Internet via SFR, j’utilise comme « smarthost » un serveur SMTP de SFR : pour Exim, dans le fichier /etc/exim4/update-exim4.conf.conf, je m’assure que la ligne suivante est présente :
dc_smarthost='mail.club-internet.fr'
Puis je redémarre Exim après avoir actualisé la configuration avec la commande update-exim4.conf.
Bon, évidemment, elle date un peu, cette ligne… Club-Internet a été acheté par Neuf, qui a été racheté par SFR… Mais ça marche alors je ne touche pas. Du coup, les messages sont envoyés via SFR et semblent provenir de l’adresse IP du serveur SFR, et non de chez moi.
Ce n’est pas à 100% efficace, cependant, puisque l’une des techniques anti-spam consiste à se renseigner sur le domaine de l’expéditeur (ce qui est derrière le signe @) ; là, pas d’échappatoire, on tombe forcément sur mon adresse IP résidentielle.
Le but à atteindre en utilisant un nom de domaine en propre est, d’une part ne plus être étiqueté « nom de domaine dynamique », d’autre part satisfaire au mieux les serveurs tiers lorsqu’ils se renseignent sur le domaine expéditeur de mes messages.
Sender Policy Framework (SPF)
Le mécanisme le plus simple à implanter dans le serveur est SPF. Il consiste à indiquer aux serveurs tiers quels serveurs sont habilités à envoyer des messages dont l’expéditeur appartient à un domaine donné. Attention : un SPF mal configuré peut entraîner la perte de tous les messages envoyés du serveur ! Les règles peuvent être testées avec un outil en ligne avant d’être enregistrées dans le DNS.
La syntaxe de SPF permet de définir les règles de diverses manières. Pour ma part, je désigne directement les serveurs autorisés, à savoir les noms de domaines que j’utilise ; j’inclus aussi les règles associées aux adresses de type « quelqu-un@sfr.fr » étant donné que j’ai configuré mon Exim en mode « smarthost », ce qui fait que mes messages semblent être issus des serveurs SMTP de SFR. Voici en conséquence le paramétrage DNS que j’utilise ; il s’agit de l’enregistrement SPF :
Name : new.example
SPF data : v=spf1 a:new.example a:old.dyn.example include:sfr.fr -all
TTL : 86400
⇓
new.example. 86400 IN SPF "v=spf1 a:new.example a:old.dyn.example include:sfr.fr -all"
Cette expression SPF signifie que :
- si le message provient de l’adresse IP associée à «
new.example», le test SPF réussit ; sinon on passe à l’étape 2 ; - si le message provient de l’adresse IP associée à «
old.dyn.example» (en principe, c’est la même, mais on ne sait jamais…), le test SPF réussit ; sinon on passe à l’étape 3 ; - si le test SPF est concluant en évaluant les règles SPF associées dans le DNS au domaine
sfr.fr, le test SPF réussit ; sinon on passe à l’étape 4 ; - dans tous les autres cas, le test SPF échoue.
Peut-être est-il préférable, dans cette règle, de remplacer « -all » par « ~all » (pour éviter les rejets) du fait du défaut de SPF, qui pourrait empêcher vos correspondant de retransmettre (forward) vos messages… Je ne suis pas sûr…
Historiquement, l’enregistrement SPF n’a pas toujours été disponible, ce qui faisait qu’un enregistrement TXT était utilisé à la place. Par précaution, il est préférable de définir également cet enregistrement :
Name : new.example
Text data : v=spf1 a:new.example a:old.dyn.example include:sfr.fr -all
TTL : 86400
⇓
new.example. 86400 IN TXT "v=spf1 a:new.example a:old.dyn.example include:sfr.fr -all"
Après avoir inséré ces enregistrements dans le DNS, il est préférable de les tester au plus vite pour s’assurer que les règles ne sont pas bloquantes ; il suffit pour cela d’envoyer un message à l’adresse check-auth@verifier.port25.com, qui répond automatiquement avec un diagnostic complet. Astuce : dans un premier temps, il peut être judicieux de créer les enregistrements DNS avec un TTL court (5 minutes par exemple) ; le TTL peut être augmenté après avoir vérifié la validité des règles.
Remarque : Bien que le paramétrage de SPF ne puisse pas faire de mal, il est à noter qu’il ne m’a rien fait gagner dans la note SpamAssassin calculée par port25.com…
DomainKeys Identified Mail (DKIM)
Là, ça devient plus intéressant, mais aussi plus compliqué. Le principe de DKIM est de demander au serveur de messagerie de signer numériquement tous les messages avec une clé privée ; les serveurs tiers vérifient alors les signatures des messages à l’aide de la clé publique correspondante, disponible dans le DNS.
Les explications qui suivent sont prévues pour Exim sur Debian Linux. Le site biapy.com explique très bien les différentes étapes à suivre. Pour les autres serveurs de messagerie, la partie concernant les clés cryptographiques devrait être presque directement utilisable ; le reste est à adapter.
La première étape est de générer une clé privée :
mkdir /etc/exim4/dkim
openssl genrsa -out /etc/exim4/dkim/new.example_dkim.privk.pem 1024
chown root:Debian-exim /etc/exim4/dkim/new.example_dkim.privk.pem
chmod 440 /etc/exim4/dkim/new.example_dkim.privk.pem
(Les espaces supplémentaires sont non significatives et ne servent qu’à la lisibilité)
J’ai choisi une clé de 1024 bits car il semble qu’il soit désormais insuffisant d’utiliser des clés de taille inférieure. Il faut ensuite générer la clé publique dans le format requis :
openssl rsa -in /etc/exim4/dkim/new.example_dkim.privk.pem -out /etc/exim4/dkim/new.example_dkim.pubk.der -pubout -outform DER
base64 -w 0 >/etc/exim4/dkim/new.example_dkim.pubk.der.b64 </etc/exim4/dkim/new.example_dkim.pubk.der
echo >>/etc/exim4/dkim/new.example_dkim.pubk.der.b64
(Les espaces supplémentaires sont non significatives et ne servent qu’à la lisibilité)
Je passe maintenant à la configuration d’Exim, avec la création d’un fichier de configuration /etc/exim4/conf.d/main/00_myconfig :
# The signing method for DKIM
DKIM_CANON = relaxed
# Domain for which DKIM signing is used.
DKIM_DOMAIN = new.example
# private key used for DKIM.
DKIM_PRIVATE_KEY = /etc/exim4/dkim/new.example_dkim.privk.pem
# DKIM selector
DKIM_SELECTOR = myselector
« myselector » étant le nom de machine de mon serveur. C’est un choix personnel, la règle étant d’avoir un « selector » différent sur chaque serveur étant habilité à gérer la messagerie pour mon domaine ; pour ma part, il n’y a qu’un seul serveur de toute façon…
Petite différence par rapport à la page que je référence plus haut : étant donné que je n’ai qu’un seul domaine dont je contrôle le DNS et sur lequel j’active DKIM, je renseigne la variable DKIM_DOMAIN ci-dessus et je n’exécute pas la commande sed suggérée dans l’article.
À ce stade, Exim peut être redémarré, après avoir actualisé la configuration avec la commande update-exim4.conf. Je passe au DNS, dans lequel il faut configurer quatre enregistrements TXT :
Name : myselector._domainkey.new.example
Text data : v=DKIM1; k=rsa; p=CONTENU_EXACT_DE_/etc/exim4/dkim/new.example_dkim.pubk.der.b64
TTL : 86400
⇓
myselector._domainkey.new.example. 86400 IN TXT "v=DKIM1; k=rsa; p=CONTENU_EXACT_DE_/etc/exim4/dkim/new.example_dkim.pubk.der.b64"
Name : _adsp._domainkey.new.example
Text data : dkim=all
TTL : 86400
⇓
_adsp._domainkey.new.example. 86400 IN TXT "dkim=all"
Name : _asp._domainkey.new.example
Text data : dkim=all
TTL : 86400
⇓
_asp._domainkey.new.example. 86400 IN TXT "dkim=all"
Name : _domainkey.new.example
Text data : o=-;
TTL : 86400
⇓
_domainkey.new.example. 86400 IN TXT "o=-\;"
Le premier enregistrement donne la clé publique DKIM associée à mon domaine lorsque c’est mon serveur qui envoie le message (le « selector » est lu dans le message que le serveur tiers souhaite vérifier). Les trois enregistrements suivants indiquent que DKIM est employé pour tous les messages dont l’expéditeur se réclame de mon domaine, donc un message non signé peut être considéré comme frauduleux.
Là encore, DKIM peut être testé en envoyant un message à l’adresse check-auth@verifier.port25.com, qui répond automatiquement avec un diagnostic complet. Astuce : dans un premier temps, il peut être judicieux de créer les enregistrements DNS avec un TTL court (5 minutes par exemple) ; le TTL peut être augmenté après avoir vérifié la validité des règles.
Remarque : Le paramétrage de DKIM me fait gagner 0,1 point sur la note SpamAssassin calculée par port25.com. Du coup, ma note est −2,0 au lieu de −1,9, sachant que plus la note augmente, plus on risque d’être considéré comme du SPAM, 5,0 étant la limite autorisée par port25.com. À titre de comparaison, le fait d’envoyer directement les messages depuis mon adresse résidentielle sans passer par le « smarthost » me fait perdre 3,3 points, amenant ainsi ma note à 1,3 au lieu de −2,0 ! Évidemment, je choisis de passer par le « smarthost »…
