Ted écrit des trucs

C'est pas toujours très intéressant, mais il fait ce qu'il peut.

De la configuration d'un serveur mail

posté le
modifié pour la dernière fois le

Introduction

J'ai récemment installé un serveur mail sur mon serveur. Je voulais que tout soit autohébergé : les mails eux-mêmes, le moyen d'y accéder, ainsi que le serveur SMTP qui envoie les mails vers l'extérieur. Bien sûr, je tenais aussi à ce que tout ce qui pouvait être chiffré le soit, en particulier que je ne risque pas de me faire intercepter quoi que ce soit lorsque je me connecte au serveur. Ça m'a pris un temps vraiment long, j'ai perdu pas mal de temps sur quelques problèmes, et je n'ai trouvé nulle part une liste de toutes les choses qu'il fallait que je fasse pour arriver à mes fins.

Ce billet est donc une tentative d'établir cette liste, de mentionner chacun des problèmes embêtants que j'ai rencontré, et la façon dont j'en suis venu à bout. Ça ne sera pas un tutoriel détaillé, ça prendrait trop de temps de le faire, il aurait fallu que je note tout ce que j'ai fait au fur et à mesure pour ça. Info potentiellement utile : j'ai fait tout ça sur une machine qui tourne sous Debian Wheezy, avec un noyau 3.2.0-4-amd64.

Liste de trucs qu'il a fallu que je fasse

  1. Installer les bons paquets Debian :
    • postfix, le serveur mail ;
    • dovecot-imapd, le serveur IMAP ;
    • opendkim et opendkim-tools, qui sert ajouter le protocole DKIM à ses mails sortants, ce qui évite de passer pour un spammeur aux yeux de certains grands serveurs mails comme Yahoo! ;
    • postfix-tls, pour que le serveur mail sache utiliser TLS ;
    • et enfin, cyrus-common-2.2 et sasl2-bin, pour faire de l'authentification sécurisée au serveur SMTP.
  2. Configurer ma zone DNS (sur le manager de la société qui me fournit mon nom de domaine, ici OVH) pour :
    • rajouter un champ MX pour le serveur mail pour dire quel sous-domaine utiliser pour le SMTP sur desfontain.es (ici, smtp.desfontain.es) ;
    • et ajouter deux champs (un de type A et un de type AAAA, respectivement pour l'IPv4 et pour l'IPv6) pour lier smtp.desfontain.es à la bonne IP.
  3. Changer mon hostname en smtp.desfontain.es.
  4. Ajouter un utilisateur par boîte mail que je veux créer.
  5. Configurer Postfix et dovecot pour envoyer mes premiers mails.
  6. Configurer les alias Postfix qui vont bien : j'ai envie que toutes les adresses du type ,se.niatnofsed@retsamtsop ,se.niatnofsed@retsamtsoh etc., atterrissent dans ma boîte mail, mais sans créer un utilisateur par adresse.
  7. En profiter pour mettre des regex dans les alias en question : je veux que n'importe quelle adresse de la forme se.niatnofsed@iouqetropmin.maps soit reconnue comme valide et redirigée vers une adresse spam maître. Ça permet de donner une adresse différente à chaque fournisseur de serveur ou site marchand sur Internet, et si jamais des spammeurs la récupèrent, on peut savoir qui a vendu mon adresse (et lancer des œufs sur leur maison) et la bloquer.
  8. Rajouter un champ SPF dans ma zone DNS pour ne pas passer pour un spammeur.
  9. Configurer OpenDKIM pour encore moins passer pour un spammeur.
  10. Rajouter un champ DKIM dans ma zone DNS pour que mes signatures DKIM puissent être vérifiées par les destinataires de mes messages.
  11. Ajouter un reverse DNS IPv4 et IPv6 pour ne pas passer pour un spammeur aux yeux de Google, qui vérifie spécifiquement (pour une raison qui m'échappe, mais alors, complètement) que le DNS et que le reverse DNS correspondent. C'est un truc qui se configure dans les options de mon hébergeur, pas sur mon serveur lui-même.
  12. Créer et mettre en place un certificat SSL signé par une autorité externe (StartSSL) sur desfontain.es. (Non, ça n'a aucun rapport avec le reste.)
  13. Créer un certificat SSL pour smtp.desfontain.es, ici sur CAcert : autant c'est important d'avoir un certificat signé par une autorité reconnue par tout le monde pour mon site Web (je ne veux pas que les visiteurs de mon site reçoivent un message d'erreur lorsqu'ils essaient de s'y connecter en HTTPS), autant ça l'est beaucoup moins pour mon serveur SMTP où je suis a priori le seul à me connecter.

Normalement, avec ça, trouver les mots à googler pour chaque détape ne devrait pas être difficile. Comme d'habitude, si vous trouvez que quelque chose n'est pas clair et que vous avez des questions, n'hésitez pas à m'envoyer un mail.

Problèmes rencontrés

  • À l'étape d'ajout du champ SPF, j'ai mis du temps à comprendre qu'il fallait impérativement cliquer sur « Type SPF » dans le manager d'OVH, parce que même si en théorie ça Devrait Marcher™, ça ne fonctionnait pas lorsque je rajoutais un champ TXT comme l'indiquait mon tutoriel.

  • Exactement la même chose à l'étape d'ajout du champ DKIM. C'est très foireux parce qu'en plus, lorsque ça ne marche pas directement lorsqu'on change le DNS, c'est normal, il faut le temps que ça se propage, du coup on ne s'alarme pas, et on perd plein de temps.

  • La plus grosse prise de tête que j'ai eue était probablement pour établir une communication entre Postfix (qui forme et envoie les messages) et OpenDKIM (qui les signe avec la clé globale du serveur). Dans la majorité des tutoriaux que j'ai trouvé sur le sujet, les deux communiquent en passant par un port particulier de localhost. Pour une raison qui m'échappe toujours (un ami m'a après suggéré que c'était potentiellement parce qu'il y avait peut-être un localhost IPv4 et un localhost IPv6 ?), ça ne fonctionnait désespérément pas, alors même que les deux démons tournaient : netstat renvoyait bien opendkim qui écoutait sur le bon port, et les logs de postfix indiquaient désespérément « Connection refused ». Je m'en suis sorti en les faisant communiquer par un fichier de socket :

    • dans /etc/defaults/opendkim :

      SOCKET="local:/var/spool/postfix/var/run/opendkim/opendkim.sock"
      
    • et dans /etc/postfix/main.conf :

      smtpd_milters = unix:/var/run/opendkim/opendkim.sock
      non_smtpd_milters = unix:/var/run/opendkim/opendkim.sock
      

    Ah oui, et évidemment, au début, j'avais mis le même chemin dans les deux cas et ça ne marchait pas, parce que postfix est lancé dans un chroot.

  • Au moment où je voulais faire des tests d'authentification à mon serveur SMTP par SASL, la majorité des tutoriels utilisent la commande :

    telnet smtp.serveur.ext 25
    

    et il m'a fallu un certain temps pour piger que si ça ne fonctionnait pas, ça n'était pas à cause de mon serveur mais de mon fournisseur d'accès à Internet local qui bloquait le port 25. Pour pouvoir non seulement faire des tests mais aussi utiliser msmtp (mon client smtp local) depuis chez moi au quotidien, j'ai dû utiliser le port 465 à la place. Il a fallu que j'indique ça dans la configuration de msmtp en utilisant l'option port (incroyable), et que je décommente la ligne commençant par smtps dans /etc/postfix/master.cf.

Liens

J'ai pas noté au fur et à mesure ce que j'ai fait, j'aurais pu écrire un tutoriel bien mieux foutu si j'y avais pensé. Par contre, j'ai quand même l'habitude de mettre des liens en commentaire de mes fichiers de configuration, pour me souvenir de l'origine d'un bout de code. En général, le lien comporte des explications, donc ça aide à se souvenir de ce que telle ligne fait à cet endroit-là. Voilà donc la liste des liens présents dans mes fichiers de config' :

  • un article sur le site de StartSSL pour faire fonctionner nginx (mon serveur Web) avec SSL ;
  • un tutorial pour l'installation de OpenDKIM ;
  • une page de wiki pour la configuration « de base » du serveur mail - c'est en français, ce qui vaut la peine d'être mentionné ;
  • et un tutorial pour la configuration d'une authentification chiffrée via TLS au serveur SMTP.

Conclusion

C'était vraiment long de faire tout ça, de l'ordre de quelques dizaines d'heures. Une partie importante du travail que j'ai eu (et des soucis que j'ai rencontrés) vient du fait que je voulais avoir mon propre serveur SMTP, donc non seulement héberger le stockage de mes mails et la gestion de mon nom de domaine, mais aussi leur envoi vers l'extérieur. Il aurait probablement été plus simple d'utiliser un SMTP externe, par exemple celui de l'ENS. Mais j'ai appris plein de choses sur le fonctionnement du système d'e-mails, donc je ne regrette pas d'y avoir passé du temps.

J'ai fait tout ça dans le but de me rendre aussi indépendant que possible des services centralisés qui s'occupaient des mails auparavant, et pour avoir plus de contrôle sur le caractère privé de mes données. En pratique, l'immense majorité de mes mails est toujours interceptable (et, selon toute probabilité, interceptée) car une part infime de mes contacts utilise des méthodes de chiffrement comme GPG. Et comme le protocole d'envoi d'e-mails n'est clairement pas conçu pour la sécurité, les métadonnées sont toujours interceptables au moment où elles passent sur le réseau.

Néanmoins, je vois quelques différences importantes : d'une part, le contenu de mes correspondances n'est pas utilisé pour faire des statistiques ou de la publicité ciblée. D'autre part, si quelqu'un veut lire et surveiller mes mails, il faut qu'il intercepte ce que j'envoie et reçois en permanence, ça devient impossible d'aller juste voir mon fournisseur de messagerie électronique pour lui dire « tiens, fais-nous une copie des messages dans la boîte aux lettres de telle personne ». Ça me semble être une amélioration significative qui valait le coup d'y passer autant de temps.

En revanche, il faut admettre que le gain en terme de vie privée entre « avoir son propre serveur SMTP » et « utiliser un serveur SMTP externe de confiance (celui d'une université, par exemple) » est quasi-nul, et c'est pourtant ça qui m'a pris le plus de temps. Le seul avantage que je vois, c'est qu'on ne peut jamais être sûr qu'un serveur SMTP que l'on ne contrôle pas n'est pas compromis (c'est évident si on parle de ceux de multinationales américaines, mais après tout, ça n'est pas délirant d'imaginer que ceux des universités, points stratégiquement importants s'il en est, aient des backdoors de services de renseignements divers).

Merci à a3nm pour sa relecture et ses propositions d'améliorations.

Je n'ai pas de système de commentaires sur ce blog, mais je serai ravi de recevoir des réactions, des critiques ou des demandes de précisions sur ce que j'ai pu écrire. Vous pouvez m'envoyer ce qui vous chante à l'adresse :
se.niatnofsed@neimad.