Solution de serveur de courrier électronique auto-hébergé (partie 3) : Une installation de Dovecot sous Debian🔗

Nous avons un MTA à moitié configuré: il permet de recevoir des emails et d'en envoyer uniquement depuis le serveur. Pour consulter les emails il est, pour l'instant, obligatoire de le faire sur la machine locale. Si l'accès via SSH est permis, c'est très facile. Néanmoins, vous avez peut-être d'autres boîtes email à gérer et votre MUA (mutt/Thunderbird) est un outil dédié qui permet de concentrer tout ce courrier électronique en un seul endroit. Donc, l'accès par SSH limite cette faculté de concentration… Il faut donc pouvoir lire ces courriels à distance, sans être connecté directement sur le serveur. Qui dit distance dit Internet, ce qui aboutit à nous faire penser à connexion chiffrée.

Ce que nous voulons est finalement assez simple: pouvoir accéder via un MUA (mutt/Thunderbird) à un compte IMAP sur une connexion chiffrée. L'authentification se fera avec un autre compte que le compte système (donc, un autre nom d'utilisateur et un mot de passe différent). L'intérêt de cette méthode est de ne pas compromettre le compte de l'utilisateur local en exposant, d'une manière ou d'une autre le couple login/password.

En termes de connexion chiffrée, nous allons opter pour l'utilisation unique du port 993 (protocole IMAP sur TLS). Il est possible d'utiliser le mécanisme STARTTLS sur le port standard (143) mais il arrive parfois que le client n'implémente pas cette méthode ou qu'une attaque en man-in-the-middle vienne modifier l'annonce STARTTLS et récupère le login/mot de passe en clair.

Lors de mon dernier article sur le sujet, j'avais mis en place une "livraison locale" (la traduction le plus proche, à mon sens, de local delivery) dans le format mbox. Mais, pour des raisons pratiques, en IMAP, c'est mieux d'avoir ça sous forme de fichiers parce qu'on peut gérer une sorte d'arborescence. Nous allons donc modifier ça, non pas en rappelant dpkg-reconfigure exim4-config mais en lisant et trifouillant dans le fichier de configuration d'exim4. Cela nous permettra de nous familiariser un peu plus avec la complexe configuration d'exim.

Une petite recherche dans le fichier /var/lib/exim4/autogenerated.config nous apprend qu'il existe une macro nommée LOCAL_DELIVERY qui par défaut vaut mail_spool. Un petit tour du côté de mail_spool nous indique les élements suivants:

mail_spool:
  debug_print = "T: appendfile for $local_part@$domain"
  driver = appendfile
  file = /var/mail/$local_part
  delivery_date_add
  envelope_to_add
  return_path_add
  group = mail
  mode = 0660
  mode_fail_narrower = false

Il s'agit d'un transport, car cette directive est présente après l'instruction begin transports du fichier de configuration. Sans rentrer trop dans les détails, on voit que ce transport utilise le pilote (driver) appendfile et on se doute bien que, vu son nom, il doit servir à ajouter du contenu à la fin d'un fichier. Ce fichier est nommé /var/mail/$local_part et on se doute également que $local_part doit correspondre à un truc du genre le login de l'utilisateur.

Si on continue l'exploration, on voit juste en dessous une autre directive nommée maildir_home et qui contient des paramètres qui semblent indiquer une sauvegarde en mode maildir dans le répertoire home. Ainsi, pour modifier le mode de livraison locale, il faut requalifier notre macro LOCAL_DELIVERY à maildir_home. Pour faire ça simplement, vous pouvez modifier le fichier /etc/exim4/update-exim4.conf.conf et indiquer maildir_home dans la directive dc_localdelivery.

Redémarrez exim4 et envoyez-vous des courriels, ça devrait marcher.

Pour configurer Mutt avec une boîte en Maildir, lisez le Wiki de Mutt. Pour notre part, nous allons aller plus loin et autoriser une consultation déportée du serveur.

Ok, nous disposons de messages au format Maildir, celui-ci nous permet de mettre en place un service IMAP(S pour secure). Exim4 n'est qu'un MTA, il ne sait parler autre chose que le SMTP. Du coup, il nous faut un serveur IMAP qui fera le job de récupérer nos emails déposés dans ~/Maildir et les mettre à disposition de notre client IMAP (genre mutt).

Parmi les serveurs IMAP disponibles sur la distribution Debian, on peut distinguer Dovecot qui se dégage des autres par sa popularité et par le fait qu'il passe tous les tests de conformité IMAP. Notre objectif va donc être d'installer Dovecot sur le serveur et de faire en sorte qu'il utilise les emails stockés au format maildir.

Pour commencer, un simple aptitude install dovecot-imapd suffit à installer la partie serveur IMAP de dovecot. Attention, sous Debian Squeeze (l'objet de ce document), la version de Dovecot est 1.2. Dovecot est passé depuis à la version 2.0 qui apporte quelques modifications importantes. Ensuite, le reste se passe dans le fichier de configuration qui est bien monolithique (un seul fichier de 1200 lignes mais bien documenté): /etc/dovecot/dovecot.conf.

Dovecot est installé avec une documentation de qualité (présente dans le paquet dovecot-common): il s'agit d'un export du wiki de Dovecot. Dans notre cas, il est donc préférable de nous reporter aux éléments en ligne. Rendez-vous donc sur le wiki dédié à la version 1.x, celle qui est installée sous Debian Squeeze: http://wiki1.dovecot.org/ . Je vous recommande de lire une bonne partie de cette documentation. Elle vous permettra de vous familiariser avec le fichier de configuration de Dovecot.

Sous Debian, un certificat et une clef privée sont automatiquement générées lors de l'installation de Dovecot. Cela permet de disposer d'un serveur sous TLS par défaut. Néanmoins, vous voulez peut-être générer ces fichiers vous-même pour, par exemple, les signer avec votre propre CA.

Pour ma part, pour aller au plus simple, j'ai réutilisé le même certificat que pour la configuration TLS du serveur Web (après tout, on identifie mieux ce qu'on connaît déjà). Vous pouvez toutefois re-générer un certificat x509 auto-signé avec la commande suivante (et en répondant correctement aux questions):

openssl req -new -x509 -nodes -out /etc/ssl/certs/dovecot.pem -keyout /etc/ssl/private/dovecot.pem
chmod 0600 /etc/ssl/private/dovecot.pem

Note: je ne maîtrise sans doute pas suffisamment TLS pour prétendre que cette configuration sera adaptée à votre utilisation.

Nous allons voir dans la suite, où modifier nos paramètres de configuration pour indiquer quels certificats utiliser.

Le fichier de configuration global est /etc/dovecot/dovecot.conf. Il est très complet. Par défaut, très peu de valeurs sont renseignées et toutes les variables de configuration sont présentes sous forme de commentaires. Dovecot n'a pas besoin de grand-chose pour fonctionner car toutes les variables de configuration ont une valeur par défaut en dur dans le code…

Néanmoins, comparativement à nos besoins, nous pouvons apporter quelques modifications de notre cru:

# Nous ne voulons que du imaps
protocols = imaps

# Nous écoutons uniquement en IPv4 (pas bien) sur l'adresse de notre serveur
listen = 192.168.0.4
ssl_listen = 192.168.0.4

# Nous voulons supprimer toute authentification en clair:
disable_plaintext_auth = yes

# Nous ne voulons que du TLS:
ssl = required
# Voici les directives pour indiquer quels certificats utiliser
ssl_cert_file = /etc/ssl/certs/dovecot.pem
ssl_key_file = /etc/ssl/private/dovecot.pem

## Emplacement des boîtes email:
mail_location = maildir:~/Maildir

Je vous invite à lire le fichier de configuration par vous-même, c'est très instructif. Sinon, vous pouvez lire la référence sur le wiki. Pour la suite, je n'indiquerai que les éléments de configuration en rapport avec l'action ciblée.

Avant de poursuivre, il faut bien retenir que Dovecot est un logiciel serveur. Son but est de servir potentiellement plusieurs utilisateurs. Or, rien dans notre fichier de configuration ne fait référence à ces utilisateurs. C'est pourquoi Dovecot propose la gestion des particularités des utilisateurs selon le concept de base de données utilisateur. C'est dans ces bases qu'on peut configurer finement les éléments de configuration pour chaque compte. Les bases de données utilisateur peuvent être de vrai SGBD(R) comme MySQL mais aussi du LDAP et, bien entendu, des fichiers plats.

Cette gestion se fait par deux plugins spécifiques:

• quota pour la gestion interne des limites.
• imap_quota pour tout ce qui concerne la présentation des quotas aux clients.

Pour activer ces deux plugins, il suffit de modifier la variable mail_plugins dans la partie protocol imap:

protocol imap {
 mail_plugins = quota imap_quota
}

Ensuite, il reste à configurer ces plugins. Tout se passe dans la partie plugin.

plugin {
  quota = maildir:Quota utilisateur
  quota_rule = *:storage=500M
  quota_rule2 = Trash:storage=100M
  quota_rule3 = *:messages=3000
  quota_exceeded_message = Bordel ! fais donc le ménage dans tes mails, yapu2place…
}

La variable quota indique la méthode de gestion du quota (ici maildir mais il en existe d'autres) ainsi que le message qui sera présenté au client. quota_rule est un nom de règle de quota qui indique la taille par défaut du quota (ici, l'utilisateur a droit à 500M maxi). S'il utilise le répertoire Trash, il obtiendra 100Mo de plus. La règle n°3 indique que la boîte de l'utilisateur ne peut pas dépasser 3000 messages. Enfin, la variable quota_exceeded_message est self-explicit !

À noter que ces paramètres seront ceux par défaut qui seront appliqués aux utilisateurs. Une directive userdb peut modifier ces valeurs par défaut (voir la suite).

(inspirée de ça: http://wiki1.dovecot.org/HowTo/SimpleVirtualInstall ).

Voici le topo:

• Nous voulons nous authentifier sur le serveur Dovecot avec un login qui n'existe pas dans /etc/passwd, c'est à dire un utilisateur qui n'existe pas sur le système. Cet utilisateur aura pour login not_toto
• Nous voulons que cet utilisateur virtuel dispose d'un mot de passe créé par nos soins. Comme c'est mal de stocker les passwords en clair, nous ne garderons ce mot de passe que sous forme d'un hash en utilisant la fonction CRAM-MD5 (d'autres fonctions sont implémentées). Nous choisissons cette implémentation car mutt la supporte très bien.
• Nous voulons que cet utilisateur virtuel accède en lecture-écriture via Dovecot aux emails du compte système toto qui est servi directement par le MTA Exim4 dans le répertoire /home/toto/Maildir. Le compte système toto a pour uid et gid: 1000 et 1010
• Nous voulons limiter la taille totale des messages à 300Mo.

Nous devons d'abord créer un fichier nommé /etc/dovecot/dovecot.passwd qui contiendra nos fausses références. Ce fichier contiendra un hash CRAM-MD5 de notre mot de passe. Voici comment le générer à l'aide de l'outil dédié (sous root): dovecotpw

dovecot -s cram-md5 -u no_toto
Enter new password: foo
Retype new password: foo
{CRAM-MD5}TOPHASHDNODS3ZrOq1bu2MasNk79LxHhlU9iI03

Il nous reste à inclure ce mot de passe et les élements cités plus haut dans notre fichier /etc/dovecot/dovecot.passwd:

not_toto:{SCRAM-MD5}TOPHASHDNODS3ZrOq1bu2MasNk79LxHhlU9iI03:1000:1010::/home/toto/::userdb_mail=maildir:/home/toto/Maildir userdb_quota_rule=*:storage=300M

Il reste à modifier la configuration de Dovecot pour prendre en compte ce fichier:

# dans la partie auth
auth default {
  mechanisms = cram-md5
  # notre méthode de vérification de mot de passe sera un fichier passwd
  passdb passwd-file {
    args = scheme=cram-md5 /etc/dovecot/dovecot.passwd
  }
  # notre méthode de récupération des infos utilisateur sera également un fichier passwd
  userdb passwd-file {
   args = /etc/dovecot/dovecot.passwd
  }
}

Vous pouvez maintenant tenter la consultation avec Mutt. Attention à votre configuration (.muttrc): par défaut, il semble que Mutt utilise l'authentification LOGIN et PLAIN. si vous êtes affectés par ce problème, vous ne pourrez pas vous connecter (connexion échouée). Vous devrez configurer la directive imap_authenticators de votre fichier .muttrc de telle manière que le mode d'authentification requis par votre configuration dovecot soit géré. Dans mon cas, l'ajout de set imap_authenticators="gssapi:cram-md5:login" règle le problème !

Comme indiqué ici, il faut veiller à ce que vous puissiez générer des index de répertoires dans votre sysfs. Sous Debian, c'est généralement le cas… mais on ne sait jamais !

Voilà, avec ces éléments, vous devriez être capable de monter un vrai service IMAP sur votre machine et consulter vos emails à distance. Dans notre projet de mise en place d'un service de courrier électronique complet, nous avons vu comment mettre en place la poste (Exim4), notre boîte aux lettres (fichiers locaux) et comment lire notre courrier sans être directement sur le serveur (Dovecot). Bien entendu, les fichiers dans Maildir restent disponibles pour d'autres programmes. Il nous reste à voir comment envoyer des emails depuis notre MTA, comment mettre en place du chiffrement au niveau de notre MTA.

Tout cela implique de se focaliser à nouveau sur Exim4 et fera l'objet d'un futur article…