Bien configurer son serveur mail – comment bien se faire voir par le réseau

Cet article n’est pas un article qui explique comment mettre en place un serveur mail de A à Z, mais plutôt un article qui vous explique les trucs et astuces à faire pour être bien considéré, notamment par les serveurs mails type Outlook (anciennement Hotmail) ou Gmail. On parle aussi dans le jargon de réputation email ou d’e-réputation mail.

Mes exemples de configurations sont basés sur Debian 7 et Postfix. Ils sont aisément adaptables à toute autre configuration.

Je pars du principe que vous êtes déjà en mesure d’envoyer et de recevoir des e-mails depuis votre serveur.

1 – Utiliser un champ MX

Ça parait peut-être idiot, mais beaucoup de gens utilisent simplement le champ A et mettent le serveur mail directement. Utiliser un champ MX permet plus de flexibilité dans la configuration, comme placer son serveur mail sur une autre IP ou offrir un système de load balancing dans le cas d’une charge email plus importante.

 

2 – Avoir une adresse IP fixe

Beaucoup de serveurs mails vérifiant la liste des IP’s des RBL (Real-time Blackhole List soit une liste liste publique répertoriant les IPs envoyant régulièrement du SPAM) référencent même les IP de type « dynamique » afin d’en limiter voir en interdire la réception d’e-mails.

Il est donc conseillé de faire tourner son serveur mail sur un serveur dédié / VPS en datacenter ou encore sur une connexion professionnelle qui possède une adresse IP fixe et dédiée de préférence.

En effet, placer plusieurs services sur la même IP peut engendrer une chute de réputation d’un des services dans le cas où un autre service se fait blacklister par une liste anti-SPAM. Par exemple, il est très difficile d’obtenir une note de réputation maximale sur les comptes Google Apps. En effet, les IPs de Google étant utilisées par de nombreuses personnes, dont certaines malhonnêtes, la réputation de votre mail va dépendre de du score de l’ensemble des utilisateurs dans sa globalité.

3 – Avoir un DNS et un reverse DNS (champ PTR) valide

Le champ MX ne peut pas rediriger directement sur une adresse IP. Il vous faut donc un champ A ou AAAA dans votre domaine qui redirige sur cette IP. La correspondance inverse existe (reverse DNS ou PTR), il faut aussi la paramétrer pour rediriger sur le champ A / AAAA. Vous pouvez faire cela en vous rendant sur le manager de votre fournisseur de serveur ou en contactant votre ISP.

Ce critère est aussi regardé dans la lutte contre le SPAM, il permet de signaler que vous êtes bien propriétaire de l’adresse IP mentionnée. L’idéal quand vous n’avez qu’un domaine est de créer ce champ A et ce champ PTR directement sur le nom de domaine qui hébergera vos e-mails.

Note: n’utilisez pas des éléments de type « dynamic » ou encore « dsl » dans votre reverse. Certains antispams recherchent ce détail pour vous repérer en tant qu’utilisateur final.

4 – Avoir un champ SPF

Un champ SPF, c’est un champ TXT se trouvant à la racine de votre domaine. Celui-ci est lu par le serveur distant pour savoir si l’IP qui le contacte est autorisée à envoyer en votre nom.

v=spf1 +mx all

C’est une version simplifiée du SPF, celle-ci autorise uniquement votre champ MX à envoyer du courrier. Il est possible d’y ajouter d’autre paramètres pour autoriser d’autres serveurs.

Il existe 4 caractères de conditionnement qu’on peut placer avant les éléments :

  • + = autorisé (pass)
  • ? = neutre (neutral)
  • ~ = suspect (soft fail)
  • – = interdit (fail).

Et voici la liste des éléments :

  • a = Autorise votre champ A à envoyer du courrier.
  • ptr = Autorise toutes les ip’s dont le reverse est sur votre domaine à envoyer du courrier
  • ip4/ip6 = Autorise une ip / un bloc d’ip (format X.X.X.X/Y) à envoyer en votre nom
  • all = Désigne tout le monde
  • include = Inclut un autre domaine (le champs SPF est obligatoire pour inclure un domaine)

Voici un petit exemple dans lequel j’autorise mon serveur MX, l’IP 1.2.3.4 et j’inclus le SPF de example.com.

v=spf1 +mx +ip4:1.2.3.4 +include:example.com all

Il existe des outils en ligne permettant de tester sa syntaxe avant de la mettre en place.

Vérifier son champ SPF

Enfin, renseignez-le dans un champ TXT sur la racine de votre domaine. Vous pouvez vérifier le tout via la commande dig

dig netsh.be TXT | grep spf

Si la commande vous retourne votre champ spf, c’est bon. Celui-ci est publié dans votre domaine.

 

5 – Signer ses e-mails via DKIM

DKIM est un système de signature des e-mails. Il utilise une clé privée se situant sur votre serveur mail pour signer vos e-mails.
Ensuite, le serveur distant récupère la clé publique publiée dans vos DNS pour vérifier que la signature est correcte.
Dans l’exemple suivant, nous allons mettre en place ce mécanisme sur un serveur postfix avec le logiciel « opendkim » (os: debian)

Installation d’opendkim

apt-get install opendkim opendkim-tools

 

Fichier de configuration opendkim

Ensuite, nous allons changer quelques éléments de base dans le fichier de configuration (/etc/opendkim.conf)
LogWhy yes : Cette option vous donnera un peu plus de détail sur le statut d’un mail.
Canonicalization relaxed/simple : Il existe plusieurs algo de vérification de la signature d’un e-mail. Nous autorisons les 2.
Mode sv : Permet d’indiquer a opendkim qu’on veut qu’il signe, mais qu’il vérifie aussi le trafic entrant. (s = sign, v = verify)
Subdomains yes : Signe également les sous-domaines lié aux domaines présent dans la whitelist.

Les paramètres suivants permettent de déporter la configuration des domaines dans des fichiers externes. (plusieurs domaines)
KeyTable /etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
ExternalIgnoreList /etc/opendkim/TrustedHosts
InternalHosts /etc/opendkim/TrustedHosts

Socket inet:8891@localhost : Socket serveur

Voici a quoi ressemble mon fichier une fois configuré :

# Log to syslog
Syslog yes
LogWhy yes
# Required to use local socket with MTAs that access the socket as a non-
# privileged user (e.g. Postfix)
UMask 002

# Sign for example.com with key in /etc/mail/dkim.key using
# selector ‘2007’ (e.g. 2007._domainkey.example.com)
#Domain example.com
#KeyFile /etc/mail/dkim.key
#Selector 2007

# Commonly-used options; the commented-out versions show the defaults.
Canonicalization relaxed/simple
Mode sv
SubDomains yes
#ADSPDiscard no

# Always oversign From (sign using actual From and a null From to prevent
# malicious signatures header fields (From and/or others) between the signer
# and the verifier. From is oversigned by default in the Debian pacakge
# because it is often the identity key used by reputation systems and thus
# somewhat security sensitive.
OversignHeaders From

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

Socket inet:8891@localhost

 

Création des fichiers et dossiers de base utile à notre configuration

Ensuite, il faut créer les dossiers dans lesquels nous allons placer la configuration de chaque domaine.

mkdir /etc/opendkim
touch /etc/opendkim/KeyTable
touch /etc/opendkim/SigningTable
touch /etc/opendkim/TrustedHosts
mkdir /etc/opendkim/keys

 

Modification du fichier de démarrage afin d’y ajouter notre socket

Maintenant, nous allons éditer le fichier de lancement (/etc/default/opendkim) afin d’ajouter l’écoute du socket.

SOCKET= »inet:8891@localhost »

Nb: on garde le même socket que spécifier dans le fichier de config plus haut.

 

Ajout de vos domaines / réseaux dans la configuration générale

Ensuite, ajoutons la liste des domaines et des ip’s pour lequel le serveur signera plutôt que de vérifier la signature
Cela se passe dans le fichier /etc/opendkim/TrustedHosts (créer plus tôt)

Voici un exemple de mon fichier (vous pouvez mettre des IP, des IP au format CIDR et vos domaines)

127.0.0.1
localhost
10.192.0.0/16

 

Configurons postfix pour fonctionner avec OpenDKIM

Éditez le fichier /etc/postfix/main.cf afin d’y ajouter la configuration suivant

milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

Pour conclure avec Postfix, redémarrez-le via

/etc/init.d/postfix restart

 

Ajoutons nos domaines

Notre serveur est désormais configuré, il nous reste à générer les paires de clés et de les associés à nos domaines.
Dans les étapes ci-dessous remplacées mondomaine.com par votre nom de domaine.
Recommencez les étapes ci-dessous autant de fois que vous possédez de noms de domaines.

Pour commencer, éditez le fichier /etc/opendkim/TrustedHosts et ajoutez-y votre domaine à la fin.

Ensuite, créons notre clé privée.

cd /etc/opendkim/keys/
mkdir mondomaine.com
cd mondomaine.com
opendkim-genkey -r -d mondomaine.com

N’oubliez pas de protéger votre clé privée via

chown opendkim:opendkim default.private

On édite le fichier /etc/opendkim/SigningTable pour y ajouter le domaine à la fin du fichier.

*@mondomaine.com default._domainkey.mondomaine.com

Déclarons l’endroit ou se trouve la clé privée via le fichier /etc/opendkim/KeyTable en y ajoutant à la fin

default._domainkey.mondomaine.com mondomaine.com:default:/etc/opendkim/keys/mondomaine.com/default.private

N’oubliez pas de redémarrer opendkim via la commande suivante

/etc/init.d/opendkim restart

Il nous reste une dernière chose à faire.
C’est de publier l’enregistrement dkim sur son nom de domaine.
On va d’abord récupérer notre clé publique déjà préformaté dans le fichier

/etc/opendkim/keys/mondomaine.com/default.txt

Qui contient le contenu suivant

default._domainkey IN TXT « v=DKIM1; k=rsa; p=malonguecleenbase64 » ; —– DKIM key default for mondomaine.com

Ensuite, nous allons le publier en créant un champ TXT dans son nom de domaine.

Comme sous-domaines, indiquez

default._domainkey

Et comme valeur, indiquez le contenu du fichier situé entre doubles quote (« ). Ce qui donnera dans mon exemple

v=DKIM1; k=rsa; p=malonguecleenbase64

 

Votre serveur dkim est prêt à fonctionner.

Pour vérifier cela, vous pouvez utiliser mail-tester (dont le lien se trouve en fin d’article). Celui-ci vous indiquera si votre signature dkim est valide.

N’oubliez pas également qu’il faut attendre la publication du champ TXT sur votre DNS. Patientez donc quelques minutes avant de tester.

6 – Publier une politique DMARC

DMARC est une politique permettant de dire aux autres serveurs quoi faire quand ils reçoivent un mail de votre part. Par exemple, vous pouvez leurs dire de bloquer les e-mails venant de chez vous quand le SPF ou le DKIM échoue.

Vous pouvez également demander des rapports sur l’utilisation de votre domaine afin de repérer un usage non autorisé de votre domaine. (utilisateur qui forgerait votre domaine lors de l’envoi de spam par exemple)

La politique dmarc se publie aussi dans votre domaine via un champ txt, mais cette fois-ci sur l’entrée _dmarc

Champ dmarc minimum :

v=DMARC1; p=quarantine;

Voici la liste des paramètres disponible pour un champ dmarc:

v = Version du dmarc, plus simplement: DMARC1
adkim = Politique dkim à appliquer r = Relaxed, s = Stricte
aspf = Politique spf à appliquer r = Relaxed, s = Stricte
p = Politique à appliquer: quarantine = Spam, none= aucune action, reject = Rejet de l’e-mail
pct = Pourcentage d’e-mails à valider via dmarc.
ri = Délais entre l’envoi de 2 rapports
rua = E-mail ou envoyer le rapport dmarc (mailto:email@example.com)

Voici un petit exemple: rejet des e-mails non signés, validation de tout le trafic et envoi des rapports journalier sur dmarc@example.com

v=DMARC1; p=quarantine; pct=100; ri=86400; rua=mailto:email@example.com;

Une fois votre champ terminé, publiez le sous-forme de champ TXT sur l’entrée _dmarc.votredomaine.com

 

7 – Ne pas changer d’IP et du temps !

Au départ, votre réputation IP sera faible, certains providers (Outlook, Gmail, …) vous redirigeront donc directement dans le dossier SPAM. Garder son IP dans le temps permet donc de finir par se faire accepter.

A force de vous voir et de voir que leurs utilisateurs lisent vos courriers, ils finiront par vous augmenter votre réputation au sein de leurs réseaux respectifs.

 

8 – Respecter les règles d’emailing

Tout comme en SEO, il existe certaines règles à adopter quant au contenu des e-mails. Si vous forgez des e-mails via vos sites web, il est très important de les respecter.

Dans mon cas, j’utilise les rapports deSpamAssassin pour analyser la situation. Ils sont disponibles dans les headers si votre e-mail traverse un SpamAssassin. Il existe d’autres sites spécialisée dans la validation des règles en emailing.

Voici quelques exemples de critères que j’ai pu lister:

  • Avoir des liens valides (aucun lien cassé)
  • Respecter un ratio taille de l’e-mail / images
  • Avoir obligatoirement l’équivalent texte de ses messages html. (multipart)
  • Ne pas utiliser certains mots tels que « cliquez-ici »

9 – Tester

C’est très important, vu que vous avez mis toute une série de paramètres pour valider votre identité, il est important que ceux-ci soient corrects. Dans l’autre cas, vous serez abaissé au même rang que les spammeurs vis-à-vis des serveurs distants.

Personnellement, j’utilise l’excellent mail-tester pour cela. Il analyse votre configuration réseau ainsi que le contenu de vos e-mails. S’il détecte un rapport SpamAssassin, il le prendra également en compte.

Une autre technique consiste à s’envoyer un e-mail vers une boite Gmail et ensuite de regarder la source de celui-ci. Vous retrouverez dans les headers de statut de la validation.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *