En préambule de ce dossier, je crois qu’il est intéressant de planter le décor. A priori, et pour tout administrateur système ou autre informaticien, il semble relativement trivial d’installer un serveur mail Postfix sous un système d’exploitation comme Ubuntu. C’est du moins à peu près ce que disent – dans de grandes lignes – la plupart des petits tutos (des how-tos) que l’on peut trouver sur Internet, à l’instar de la documentation officielle d’Ubuntu à ce sujet. Fait intéressant, avec l’avènement de l’IP v6, Postfix le privilégierait par rapport à de l’IP v4. Élémentaire me direz-vous, le plus récent gagne plus que régulièrement la mise.

Mais voilà, force est de constater que le domaine de l’envoi de mail a quelque peu changé durant ces dernières années, et sans aucun doute la lutte anti-spam n’y est-elle pas étrangère. C’est ainsi que l’on remarque que des gros providers tels que Google (avec GMail) commencent à mettre en oeuvre des méthodes drastiques pour éliminer le spam de leurs boîtes. C’est ainsi que, sans le vouloir et sans être blacklisté par les instances de contrôle du spam, votre pauvre petit serveur va se retrouver à envoyer des emails considérés comme SPAM et rejetés, purement et simplement.

C’est le sujet de ce dossier consacré à l’installation d’un serveur Postfix sous Ubuntu, en IP v6, et aux nouvelles normes de sécurité imposées par le géant de la recherche sur Internet.

 Les pré-requis à ce dossier

Je n’ai pas comme envie de « polluer » ce blog avec des méthodes éprouvées et déjà évoquées maintes fois sur Internet. En lieu et place, je préfère documenter la partie qui l’est mal (ou est carrément absente) afin d’essayer d’aider les personnes qui pourraient être dans le même cas que moi à un moment donné. Ainsi, pour la suite de ce dossier, nous partirons de quelques postulats tels que:

• Vous voulez installer un serveur de mail Postfix/Courier pour votre propre compte, mais vous envisagez d’étendre son utilisation à plusieurs domaines
• Vous disposez déjà d’un serveur dédié/virtuel avec au minimum 512Mo de RAM et 1Go de stockage; il est installé sous Ubuntu Server 12.04.3 LTS (32 ou 64bits) au minimum

De plus, vous devrez avoir suivi, reproduit ou du moins compris et assimilé les tutoriels suivants, basés sur l’excellent tutoriel (en anglais) de Ivar Abrahamsen (flurdy.com):

• La mise en place d’une base de données d’authentification: http://flurdy.com/docs/postfix/#config-simple-database
• L’installation d’un serveur Postfix (ce tuto décrit comment mettre en oeuvre des boîtes « virtuelles », c’est-à-dire ne pas avoir besoin de créer un utilisateur linux par compte email): http://flurdy.com/docs/postfix/#config-simple-mta
• L’installation d’un serveur Courier-IMAP: http://flurdy.com/docs/postfix/#config-simple-imap
• La mise en oeuvre d’une authentification orientée base de données à l’aide de SASL: http://flurdy.com/docs/postfix/#config-secure-auth

De manière générale, vous pouvez suivre le tutoriel d’Ivar Abrahamsen pour le reste, c’est le plus complet et le plus à jour que j’ai pu trouver à ce jour. Et c’est là-dessus qu’est basé ce dossier.

Pour la suite du dossier, vous verrez que je me suis beaucoup basé sur des tutoriels proposés par Christian Skala et un certain « Max » sur Tjitjing.com. N’hésitez pas à vous rendre à la fin du document pour consulter les sources et progresser à votre rythme !

Le problème de fond, mis en évidence par GMail

En cherchant à filtrer le spam pour éviter à ses utilisateurs d’en souffrir, Google a pris une décision assez drastique: pour les serveurs mail qui communiquent avec lui au travers du protocole IPv6, une authentification particulière et un contrôle minutieux seraient mis en place.

Je suis tombé sur ce constat lorsque, juste après avoir configuré mon nouveau serveur tout neuf et en communiquant avec ma boîte GMail, je me suis retrouvé avec un message de MAILER-DAEMON. Oui, vous savez, celui qui vous avertit lorsqu’un email n’est pas arrivé à destination ! Et bien ce message ressemblait à cela:

This is the mail system at host MaMachine.localdomain.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

<monadresse@gmail.com>: host
gmail-smtp-in.l.google.com[2a00:1450:4001:c02::1a] said: 550-5.7.1
[2001:4b98:dc2:41:216:3eff:fe23:9014 16] Our system has detected
550-5.7.1 that this message does not meet IPv6 sending guidelines regarding
PTR 550-5.7.1 records and authentication. Please review 550-5.7.1
https://support.google.com/mail/?p=ipv6_authentication_error for more 550
5.7.1 information. z9si779477eeo.136 - gsmtp (in reply to end of DATA
command)

Ma première réaction a été de me gratter les cheveux tout en prenant un air ahuri, puis je me suis ressaisi et j’ai fait une recherche sur Internet. Le premier résultat trouvé a été: GMail n’accepte pas ce mail parce qu’il est envoyé par un serveur en IPv6 et que celui-ci ne respecte pas des normes de communication. La solution donnée, très basique, simpliste et qui ne me plaisait absolument pas, était de router les communication de Postfix en IPv4 uniquement… pas génial !

J’ai continué à chercher, et j’ai fini par trouver – non sans efforts et après quelques heures tout de même – une solution bien mieux: le couple SPF et DKIM. Kézako ?

DKIM – Domain Key Identified Mail

DKIM signifie DomainKey Identified Mail. Il s’agit d’une norme d’authentification qui fait son chemin sur Internet et qui permet de réduire, semble-t-il et à juste raison selon moi, le spam et le hameçonnage (phishing). En y pensant, la technique est très simple et je me demande pourquoi on y a pas pensé plus tôt, puisque c’est depuis 2004 que c’est dans les boîtes.

Le principe est de faire signer numériquement, grâce à des méthodes cryptographiques, un email sortant. De ce fait, on authentifie le serveur comme étant l’émetteur légitime du mail, puisque c’est lui qui le signe. En définitive, pour chaque mail reçu par un hôte, il y a un responsable de l’envoi qui l’a signé. Le retrouver et lui indiquer qu’il envoie du spam est donc très aisé. Tout envoi de mail sera donc concerné par cette signature.

SPF – Sender Policy Framework

SPF est le deuxième moyen mis en oeuvre au niveau sécurité pour éviter le spam et le hameçonnage. Il s’agit du Sender Policy Framework, qui vérifie que le domaine expédiant un email autorise bien un serveur à le faire. Chaque domaine va donc avoir un (ou plusieurs) enregistrement SPF pour désigner le ou les serveurs légitimes qu’il autorise à envoyer des emails. Si un serveur destinataire obtient un email dont l’IP émettrice n’est pas renseignée par l’enregistrement SPF du domaine pourra être considéré comme spam. Magnifique, non ?

Mise en oeuvre de SPF

Tout ragaillardi par la découverte d’une solution viable à moyen/long terme et que, visiblement tout le monde utiliserait tôt ou tard, je me suis documenté sur la manière de mettre en oeuvre ces techniques.

Commençons par la mise en oeuvre de SPF. Pourquoi ? Parce que cette manipulation touche directement la zone DNS de votre nom de domaine, et donc que la propagation des changements pourra être assez longue. (entre 3 et 12h en principe) On va donc tenter de gagner un peu de temps en commençant par le plus facile mais celui qui prendra le plus de temps à s’appliquer. Première chose, connectez-vous au panel qui vous permettra de gérer les DNS de votre nom de domaine:

• Si vous êtes, comme moi, chez Gandi ou un prestataire identique, vous pouvez utiliser ses DNS et modifier votre zone directement chez eux.
• Si vous hébergez vos DNS sur des serveurs tiers ou sur votre propre serveur… débrouillez-vous, ça sort du cadre de ce dossier 🙂

Quoi qu’il en soit, la création d’un enregistrement SPF se fait de manière très simple. Premièrement, commencez par localiser les adresses IP de votre serveur (IPv4 et IPv6). Une fois que c’est fait, vous pourrez créer les enregistrements DNS suivants dans votre zone, en veillant à adapter ce qui convient (MONIPV4 et MONIPV6), bien sûr:

@ 10800 IN SPF "v=spf1 ip4:MONIPV4 ip6:MONIPV6 ptr ?all"
@ 10800 IN TXT "v=spf1 ip4:MONIPV4 ip6:MONIPV6 ptr ?all"

Si vous avez uniquement la possibilité de paramétrer votre zone DNS à l’aide d’un assistant, veuillez créer un enregistrement de type SPF et un de type TXT, d’un TTL (Time To Live) de 3h et dont la valeur serait à chaque fois « v=spf1 ip4:MONIPV4 ip6:MONIPV6 ptr ?all". (sans les guillemets)

Une fois que c’est fait, enregistrez votre zone et… patientez un moment que les serveurs DNS du monde prennent en compte celles-ci. Vous pouvez, pendant ce temps, passer à la partie DKIM !

Mise en oeuvre de DKIM

La mise en oeuvre de DKIM va passer par un peu de paramétrage sur votre serveur. Pour commencer, connectez-vous y à l’aide d’une connexion SSH, si vous en possédez une, puis procédez à l’installation des paquets suivants, pour Ubuntu:

sudo apt-get install opendkim opendkim-tools

Cela va installer l’implémentation open-source de DKIM, à savoir OpenDKIM. Si vous le souhaitez, vous pouvez bien entendu installer le tout à la main en compilant les sources. Je trouve que ça a moins de charme, mais bon, certains préféreront sans doute.

Dans mon cas, je voulais pouvoir utiliser plusieurs domaines sur mon serveur, qui sert de serveur web également (enfin, si vous lisez ces lignes, c’est que c’est le cas 🙂 ), j’ai donc cherché et trouvé le moyen de le faire. Ce tutoriel (en anglais) explique les étapes à effectuer pour mettre en oeuvre OpenDKIM. Ce n’est pas expliqué en détail, mais au moins, il y a les lignes de commande à faire et les renseignements à donner. C’est donc suffisant pour le mettre en oeuvre. Au besoin, n’hésitez pas à me poser des questions en commentaire !

Je remarque néanmoins que certaines étapes pourraient être améliorées. Par exemple, le fichier TrustedHosts pourrait comprendre les lignes « localhost » et « 127.0.0.1 » uniquement… ce serait largement suffisant, sauf si vous avez d’autres serveurs, au quel cas vous pourriez les y ajouter. De plus, l’écoute sur le port 12345 n’est pas très représentative pour DKIM. J’ai pour cela suivi le tutoriel de Christian Skala qui privilégie l’utilisation du port 8891 pour cet usage.

Pour en finir avec OpenDKIM et comme aucun des deux tutoriels ne le met en avant, il vous faut impérativement fixer les permissions sur les clés utilisées pour la signature des emails. Pour cela, il vous faut suivre cette procédure, telle qu’expliquée sur SourceForge:

• Localisez le répertoire où sont placées vos clés de chiffrement créées pour DKIM (je les avais personnellement placées dans un répertoire /etc/opendkim/keys)
• Faites un chown -R opendkim:opendkim /etc/opendkim/keys (remplacez le chemin vers votre propre répertoire)
• Puis faites un chmod -R 700 /etc/opendkim/keys (encore une fois, remplacez le chemin si nécessaire)
• Redémarrez le service OpenDKIM à l’aide de la commande service opendkim restart (ou /etc/init.d/opendkim restart)

Et voilà ! Le tour est joué. Il ne vous reste plus qu’à attendre la fin de la propagation de vos modifications sur la zone DNS de votre nom de domaine et c’est fait. Votre serveur de mail ainsi configuré sera (enfin) accepté par tous les fournisseurs de boîtes mails, même les plus exigeants (comme Google). J’espère que ça vous aura aidé ! 🙂

Tester votre configuration

Pour tester ma configuration, j’ai utilisé un site web proposé par un des tutoriels, à savoir le service Mail-Tester. J’ai trouvé cet outil plutôt sympa car, en plus de proposer des résultats pertinents et des conseils éclairés sur les manières d’améliorer votre score, il est plutôt joli. C’est suffisamment rare pour le souligner: voilà un service qui, en plus de bien faire son job, est joli, agréable à utiliser et offre des conseils que (presque) tout le monde peut suivre. Intéressant ! Merci aux fondateurs !

Exemple de configuration DNS (SPF + DKIM)

Comme rien ne vaut un bon exemple concret, je vous met à disposition une capture d’écran de la zone DNS que j’ai configurée pour mon domaine:

Et la version texte serait:

@ 10800 IN MX 50 mail.powerjpm.info.
@ 10800 IN SPF "v=spf1 ip4:46.226.111.38 ip6:2001:4b98:dc2:41:216:3eff:fe23:9014 ptr ?all"
@ 10800 IN TXT "v=spf1 ip4:46.226.111.38 ip6:2001:4b98:dc2:41:216:3eff:fe23:9014 ptr ?all"
mail._domainkey 10800 IN TXT "v=DKIM1; k=rsa; t=y; p=VOTRE-CLE-PUBLIQUE-DKIM-ICI"

Notez que la notion de « Selector » introduite par DKIM est, pour ce domaine: « mail ». Mais vous pourriez choisir une autre valeur tel que proposé par les tutoriels en source de ce dossier, évidemment.

Enfin, vous remarquerez qu’il y a un enregistrement SPF et un enregistrement TXT. Ceci est nécessaire pour des raisons de compatibilité, semble-t-il. Certains DNS ne supportent visiblement pas encore SPF et/ou ne permettent pas à ceux qui définissent des zones de l’utiliser tel quel. Il faut donc un enregistrement TXT pour combler ce manque.

Sources & inspirations

Vous pouvez retrouver l’intégralité des sources utilisées pour la réalisation de ce petit dossier ici. Merci à tous les auteurs qui ont publié de la documentation sur DKIM et SPF car, franchement, leur mise en place n’était pas gagnée d’avance. On aurait attendu quelque chose de plus complet au niveau de la documentation de Google sur le sujet.

Quant à moi, j’espère que ce petit dossier vous aura permis de trouver de la documentation sur DKIM et SPF et qu’il vous aura aidé. Si c’est le cas, je vous remercie d’avance de mettre un petit commentaire pour vous exprimer. C’est toujours sympa d’avoir un retour quand on fait quelque chose, merci 🙂

Source de l’image d’entête: Pixabay