Solution de serveur de courrier électronique auto-hébergé (partie 5) : Aller plus loin avec Exim4 sous Debian.

Introduction:

Nous avons maintenant un MTA et un serveur IMAPS. Il nous reste plusieurs opérations à terminer sur Exim4. En effet, nous avons laissé le système dans un état certes stable mais où il manque de nombreuses fonctionnalités. Parmi celles-ci, nous allons étudier comment chiffrer les connexions par défaut ainsi que la gestion de l'authentification...

Gestion du chiffrement:

Par défaut, comme on peut le voir dans les indications précédentes, Exim4 n'est pas configuré pour gérer STARTLS. du moins, c'est vrai du côté serveur: en envoi, Exim4 se connecte préférentiellement par cette méthode pour déposer un message. Un coup d'oeil à la documentation officielle d'Exim4 sur le sujet nous présente quelques variables de configuration.

La méthode Debian est plus simple: jetez un coup d'oeil au fichier /etc/exim4/conf.d/main/03_exim4-config_tlsoptions et comptez les macros... Voici le résultat:

  • MAIN_TLS_ENABLE: indique qu'on gère les connexions TLS
  • MAIN_TLS_CERTIFICATE: nom du fichier de certificat du serveur
  • MAIN_TLS_PRIVATEKEY: nom du fichier de clef privée du serveur
  • MAIN_TLS_VERIFY_CERTIFICATES: emplacement des certificats d'AC pour la vérification des certificats des clients
  • MAIN_TLS_VERIFY_HOSTS: liste de machines qui doivent fournir un certificat vérifiable par les AC de la macro sus-citée
  • MAIN_TLS_TRY_VERIFY_HOSTS: liste de machines dont la vérification de certificat n'est pas bloquant pour la livraison des emails.

Pour notre action, il nous suffit de renseigner les 3 premières macros avec les bons fichiers. A noter qu'Exim4 doit pouvoir accéder en lecture à la clef privée. J'avais déjà une clef privée/publique pour ma machine et je l'ai réutilisée. Néanmoins, pour la clef privée, j'ai dû faire une copie accessible aux processus d'exim4 dans /etc/exim4:

chgrp Debian-exim medspx.fr.key
chmod 640 medspx.fr.key

Ensuite, il reste à renseigner nos trois macros et de redémarrer notre serveur.

# on active TLS:
MAIN_TLS_ENABLE = true

# Emplacements des fichiers de clef pour TLS:
MAIN_TLS_CERTIFICATE = /etc/ssl/certs/medspx.fr.crt
MAIN_TLS_PRIVATEKEY = /etc/exim4/medspx.fr.key

Si tout se passe bien, vous pouvez faire un test de connexion (telnet ou nc via le port 25) et vérifier que l'extension STARTTLS est bien activée. Ensuite, pour être vraiment sûr, lancez une procédure STARTTLS. En cas de problème, n'hésitez pas à consulter le fichier /var/log/exim4/mainlog qui remonte les erreurs TLS (bien souvent, exim n'arrive pas à lire la clef privée).

Mode Debug:

Parfois, lorsqu'on veut voir un peu ce qui cloche, il est bon de mettre exim4 en mode debug. Voici une ligne de commande adaptée pour voir ce qui se passe en dynamique:

exim4 -C /var/lib/exim4/config.autogenerated -d+all -bd -q30m

Pour l'utiliser, vous devez avoir arrêté le service exim4 (/etc/init.d/exim4 stop) Ainsi, vous pourrez mieux noter les problèmes de login/mot de passe lors de la partie suivante... en cas de problème bien sûr !

Gestion de l'envoi authentifié:

Par défaut, Exim4 ne permet pas l'envoi distant. Ainsi, il est impossible d'envoyer un message ayant comme adresse d'origine, celle d'un utilisateur valide du serveur sur lequel est installé Exim, depuis une machine distante par le protocole SMTP. En modifiant la configuration, il est toutefois possible de faire en sorte qu'Exim mette en oeuvre des mécanismes de vérification (authentification) qui permettent cette fonctionnalité bien intéressante. S'il est possible d'envoyer un message par SSH en direct sur la machine, c'est une tâche assez pénible et, bien souvent, on souhaite pouvoir envoyer des courriers électroniques depuis son MUA préféré (qui bien souvent est distant).

Les mécanismes de vérification sont gérés dans la section authenticators du fichier de configuration. Ils bénéficient d'éléments de configuration bien particuliers qui sont très différents et très nombreux. N'oublions pas que cette partie d'authentification est une extension du protocole SMTP (extension AUTH) et que cette dernière décrit plusieurs méthodes distinctes. On peut souhaiter s'authentifier par login/mot de passe en clair, ou bien en utilisant des fonctions de hashage (MD5) ou bien encore SASL. Tout dépend du contexte, du niveau de sécurité, de la capacité de gestion de la complexité, etc...

Dans notre cas qui est appliqué à mon environnement, nous souhaitons:

  • Mettre en oeuvre une authentification d'un utilisateur factice (celui utilisé pour Dovecot dans notre dernier article serait bien).
  • Si l'authentification ne se fait pas sur un canal chiffré, elle doit échouer.
  • L'authentification, même chiffrée, se basera sur au moins une fonction de hashage.
  • L'authentification ne se fera que sur un réseau local (celui de votre maison ou de votre structure de travail par exemple).

Généralité sur la configuration:

Nous ne devons pas oublier qu'Exim est également un client SMTP qui envoie (des emails) vers d'autres serveurs SMTP. La gestion de l'authentification joue donc dans les deux sens:

  • lorsqu'Exim est un serveur qui attend un client SMTP qui désire s'authentifier
  • lorsqu'Exim est un client qui tente d'envoyer un courriel vers un autre serveur imposant l'authentification (c'est le cas si vous utilisez par exemple Exim pour relayer des emails vers le service de courrier électronique de votre FAI.

Dans la suite, nous ne gèrerons que la partie "Exim serveur".

Restriction de l'authentification au réseau local:

Nous voulons restreindre l'authentification aux machines de notre réseau local (192.168.0.0/24). Ainsi, avec cette configuration, il sera impossible d'envoyer des emails en dehors de votre réseau local, même si votre serveur Exim est présent sur Internet. Pour mettre en place cette règle, il suffit de modifier la variable auth_advertise_hosts dans la partie générale de la configuration. Attention, n'oublions pas que nous souhaitons également masquer l'extension AUTH lorsqu'on est en dehors d'un canal chiffré.

En tenant compte du système de configuration éclaté de Debian, le plus simple consiste à ajouter un fichier /etc/exim4/conf.d/main/10_exim4-config_auth contenant:

auth_advertise_hosts = ${if eq{$tls_cipher}{}{}{192.168.0.0/24}}

La directive auth_advertise_hosts permet de définir quelles sont les machines qui se verrons présenter l'extension AUTH. La valeur de la directive indique que seules les machines dont l'adresse IP est dans le réseau local (192.168.0.0/24) et qui communiquent sur un canal chiffré (tls_cipher) se verrons présenter l'extension AUTH lors du dialogue SMTP avec le serveur Exim4.

Authentification serveur par CRAM-MD5:

On veut ici mettre en place un mécanisme d'authentification par CRAM-MD5 en réutilisant le hash du mot de passe contenu dans le fichier de mot de passe de Dovecot... Avant de lire plus avant et pour faire simple, je tiens à vous dire que c'est impossible ! En effet, le pilote cram-md5 d'Exim fonctionne de la manière suivante:

  • le client indique AUTH CRAM-MD5 pour lancer la procédure d'authentification par CRAM-MD5.
  • le serveur retourne une châine (le challenge).
  • le client compute le mot de passe donné, ajoute le challenge et redonne un hash MD5 codé en Base64.
  • le serveur récupère le mot de passe en suivant les commandes indiquées dans la variable server_secret.
  • ce mot de passe est un vrai mot de passe: ce n'est pas un hash !
  • ensuite, le serveur utilise le challenge, le mot de passe, fabrique un hash avec tout ça et compare avec le résultat renvoyé par le client.

Dans ce mécanisme, Exim a donc besoin du mot de passe en clair. On ne peut PAS le stocker sous forme de hash ! Ce n'est pas ce que nous voulons...

Il va nous falloir choisir entre stocker un mot de passe en clair et utiliser un autre mécanisme d'authentification. Les autres solutions qui restent simples sont les authentifications PLAIN et LOGIN. Elles ont le défaut de montrer les mots de passe en clair sur le réseau. Mais on peut s'assurer qu'elles passent sur un tunnel chiffré. Pour "améliorer" un peu notre solution et faire en sorte que rien ne soit stocké en clair, nous pouvons utiliser un hash MD5 et le comparer avec le Hash du mot de passe récupéré en clair. Dans ces conditions, il n'y a, à priori, rien qui est exposé en clair quelque part.

Nous devons également gérer le fait que c'est un compte non système qui doit servir à l'étape d'authentificaton. Il faut donc ne pas oublier cet élément dans notre configuration. Pour ma part, voici ce que j'ai ajouté en créant le fichier /etc/exim4/conf.d/auth/20_exim4-config_virtual et qui reprend ces critères:

Pour cela, vous devez

plain_server:
  driver = plaintext
  public_name = PLAIN
  server_condition = "${if crypteq{$auth3}{\\\{md5\\\}${extract{1}{:}{${lookup{$auth2}lsearch{CONFDIR/passwd}{$value}{fail}}}}}{1}{0}}"
  server_set_id = $auth2
  server_prompts = :
  server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}}

La directive server_condition fait tout le travail: elle compare le hash md5 du mot de passe de la session SMTP du client (stocké dans la variable $auth3) avec la chaîne correspondant au compte de l'utilisateur ($auth2) renseignée dans le fichier CONFDIR/passwd. Ce dernier est un alias pour /etc/exim4/passwd et contiendra une ligne du type: login_utilisateur:hash_md5_mot_de_passe. Pour gérer l'alias, il suffit d'ajouter une ligne dans le fichier /etc/aliases qui reprend votre nom d'utilisateur non système et qui le lie à vrai compte système.

Autre solution: il existe un mécanisme d'authentification basé sur Dovecot. C'est un mécanisme SASL et il implique une petite modification de la configuration de Dovecot. De plus, sous Debian, il n'est disponible qu'avec le démon "lourd" d'exim (exim4-daemon-heavy). Pour bénéficier de ce traitement, un petit coup d'aptitude install exim4-daemin-heavy fera l'affaire. A noter que ce démon n'est pas très lourd (500Ko de binaires en plus rapport au client léger). Mais je n'ai pas testé cette solution...

cram_md5_dovecot:
  driver = dovecot
  public_name = CRAM-MD5
  server_socket = /var/run/dovecot/auth-client
  # notre utilisateur est virtuel, 
  server_set_id = $auth1

Vérification des champs Sender:

Maintenant que nous pouvons envoyer un email depuis un MUA distant, il nous manque une dernière étape de vérification. Celle du champ Sender:. En effet, à ce stade, il n'y a aucune raison pour vous interdire, alors que vous êtes authentifié, de mettre n'importe quoi dans le champ Sender: (adresse email de l'émetteur). Vous pouvez donc vous faire passer pour n'importe qui...

Sur un serveur avec peu d'utilisateurs, ce n'est pas crucial ! Mais, dans de nombreuses situations, il faut veiller à respecter l'adéquation client autorisé-champ Sender:.

Tout ceci se passe dans une ACL, ce qui va nous permettre de parler un peu plus de ces éléments de configuration. Vous pouvez lire le chapitre 40 de la spécification d'Exim4 pour obtenir des informations complètes...

Pour faire simple, une ACL est un mécanisme qui intervient à des moments divers du processus de gestion des courriers électroniques. Par exemple, une ACL est déclenchée lorsqu'un client envoie une commande SMTP (genre AUTH ou MAIL FROM ou RCPT, etc...). Comme dans les autres morceaux de configuration d'Exim, les ACL sont définis par un nom (libre) et sont affectées manuellement aux commandes SMTP évoquées plus haut, dans la partie principale de la configuration (main). Vous pouvez par exemple créer une ACL nommée ma_super_acl et l'affecter à la commande AUTH en écrivant:

acl_smtp_auth = ma_super_acl

En ce qui concerne le contenu d'une ACL, voici quelques règles à retenir:

  • Une ACL est formée de plusieurs "instructions"
  • Chaque instruction est formée par un et un seul verbe
  • chaque verbe est soumis à une ou plusieurs conditions et à un ou plusieurs modificateurs

Exemple d'ACL complète:

# on commence par définir le nom de l'ACL
ma_super_acl:

  # Début de la première instruction:
  # dont le verbe est accept (accept si toutes les conditions sont vérifiées)
  accept 
      # condition n°1: la liste des hôtes est vide (donc l'email est envoyé en local)
      hosts = :
  # modificateur n° 1:
  control = dkim_disable_verify

  # Début de la deuxième instruction:
  # dont le verbe est également accept
  accept
      # condition n°1: l'hôte fait partie de la liste des clients autorisés
      hosts = +relay_from_hosts
      control = submission/sender_retain
      control = dkim_disable_verify

Dans notre cas, on souhaite faire échouer tous les envois de messages dont le champ Sender: contient un nom d'utilisateur différent du login authentifié. Si l'authentification s'est déroulée correctement, le login de l'utilisateur est présent dans la variable globale $authenticated_id. Si le champ FROM ou Sender contient autre chose que cette variable complétée du domaine, alors il y a tentative d'usurpation d'identité. Du coup on rejete...

Pour faire simple, il faut modifier le fichier /etc/exim4/conf.d/acl/30_exim4-config_check_rcpt et y ajouter l'instruction deny suivante (dans la partie qui contient déjà l'instruction accept authenticated = * ):

# on rejete lorsqu'il y a différence
deny
   message = Champ Sender différent du login authentifié
   authenticated = *
   !senders = ${authenticated_id}@my_domain.org

 # s'il n'y a pas eu rejet, on continue (principe du verbe deny)
 # et on procède à l'envoi normalement
 accept
   authenticated = *
   control = submission
   control = dkim_disable_verify

J'ai mis le domaine en dur mais on peut bricoler grâce aux options de gestion des chaînes sous Exim...

Conclusion:

Nous disposons maintenant d'une véritable configuration fonctionnelle d'Exim4 qui nous permet de faire les choses "classiques" du courrier électronique. Dans la pratique, on voit bien qu'Exim4 est assez complexe "à pénétrer": il vous faudra bien en comprendre les concepts. Je n'ai indiqué ici qu'une partie de ces concepts: seuls ceux qui nécéssitaient une configuration différente de celle offerte par Debian ont été abordés. Sachez qu'il en existe d'autres qui sont sans doute plus importants: les routers et les transports. Ces éléments gèrent toute la chaîne de distribution du courrier électronique et permettent un très haut niveau de "customisation". Pour tout cela, il n'y a pas le choix: il faut lire la documentation officielle d'Exim (alias /usr/share/doc/exim4-base/spec.txt.gz ) !

Pour la prochaine fois, il nous reste à mettre en place le webmail...

Posted dim. 05 juin 2011 18:47:33 Tags:

Solution de serveur de courrier électronique auto-hébergé (partie 6) : Installation de roundcube

Introduction:

Toujours dans ma série d'articles sur le courrier électronique, nous allons maintenant voir une partie émergée de l'iceberg: le webmail. Je sais, c'est à la mode en ce moment (et depuis quelques années déjà): pour l'utilisateur lambda, envoyer un email passe le plus souvent par le web. Si l'idée n'est pas stupide au départ, on voit qu'elle a pris une grande part des habitudes des utilisateurs. Ceci n'est pas sans conséquence sur les flux sur Internet et également sur leur vie privée. En effet, en règle générale, un service de webmail est proposé par différentes sociétés, souvent gratuitement.

L'ennui c'est que souvent, ces sociétés vont jusqu'à lire votre correspondance privée et ceci à des fins non techniques. Par exemple, les comptes GMail sont lus (par des programmes certes) pour mieux vous cibler afin de vous envoyer un tas de publicités (j'ajoute "à la con" même si c'est un pléonasme). Dans le monde réel, LaPoste n'ouvre pas vos lettres sauf en cas de problème technique ! Si votre employeur se met à lire vos emails non professionnels reçus sur votre boîte professionnelle, il viole le secret de la correspondance privée et est passible de poursuites ! Mais, dans le cas des fournisseurs de webmail que je cite plus haut, la règle n'est pas la même: les utilisateurs vendent le contenu de leur vie privée contre un hébergement.

Néanmoins Madame Michu se doute bien qu'héberger un service de courrier électronique, c'est compliqué et qu'il faut bien que ces entreprises se rémunèrent... Ce n'est pas tout à fait faux mais à quel prix ! Pour ma part, l'aspect technique ne me fait pas peur et cette série d'articles représente mon effort pour régler ce problème: se passer de GMail ! Et on va voir que mettre en place un webmail, après avoir configuré un vrai serveur SMTP, c'est hyper-simple...

Installation:

Roundcube est packagé pour Debian. C'est un paquet qui semble assez bien maintenu car la version 0.5 a été backportée pour Squeeze. Pour pouvoir en profiter, vous devez avoir configuré le dépôt de rétroportage officiel de Debian en ajoutant la ligne suivante dans votre fichier /etc/apt/sources.list:

# Dépôt Backport officiel:
deb http://backports.debian.org/debian-backports squeeze-backports main

Ensuite, un simple aptitude update && aptitude -t squeeze-backports install roundcube vous permettra d'installer la bête. Attention, roundcube est développé en PHP et il repose sur quelques autres paquets. Compter environ 40Mo d'occupé pour un serveur web sans PHP5 déjà installé. Sur une machine comme un SheevaPlug, ce n'est pas rien ! Cette taille (plus le fait qu'il faille PHP) m'a fait longuement hésité avant d'installer roundcube. Mais comme ce logiciel semble être un poil au dessus des autres, j'ai cédé pour voir...

De plus, roundcube a besoin d'une base de données. C'est aussi un truc qui me dépasse, surtout pour mes besoins (qui sont quasi monoutilisateurs): avoir besoin d'un SGBD pour gérer des fichiers en Maildir... Mais bon, pas le choix !

L'installation vous demande si vous désirez configurer roundcube avec dbconfig-common. Pour ma part, j'ai répondu oui à cette question et j'ai choisi une base de données en SQLite, quand même moins lourde que MySQL ou PostgreSQL ! L'intérêt de dbconfig-common est qu'il créé la base de données avec le bon schéma pour vous.

Configuration:

Une fois le paquet installé, il faut le configurer. Pour ma part, voici mes exigences:

  • le webmail doit être accessible via l'url https://serveur/email.
  • il ne doit être accessible que par HTTPS (forcément chiffré).
  • il doit s'adapter à la configuration de mon serveur IMAP (dont les identifiants de connexion sont virtuels).

En terme de fichiers, voici comment roundcube est configuré:

  • /etc/roundcube/apache.conf: contient un exemple de configuration pour Apache2. Attention, ce fichier est la cible de l'alias de /etc/apache2/conf.d/roundcube. Pensez à supprimer ce lien si vous voulez faire une configuration précise pour Apache.
  • /etc/roundcube/htaccess: fichier htaccess pour gérer l'accès à l'interface web.
  • /etc/roundcube/debian-db.php: contient le paramétrage de l'accès à la base de données (SQLite) de roundcube.
  • /etc/roundcube/main.inc.php: fichier de configuration principal de roundcube.
  • /etc/roundcube/db.inc.php: fichier de paramétrage de la base de données de roundcube.

En ce qui concerne l'accès par Apache, voici une rapide configuration (à adapter à votre installation spécifique) à base d'alias que j'ai ajouté à ma configuration de site web SSL (et non à celui par défaut):

# Installation de Roundcube:
Alias /email/program/js/tiny_mce/ /usr/share/tinymce/www/
Alias /email /var/lib/roundcube

# Access to tinymce files
<Directory "/usr/share/tinymce/www/">
  Options Indexes MultiViews FollowSymLinks
  AllowOverride None
  Order allow,deny
  Allow from all
</Directory>

<Directory /var/lib/roundcube/>
  Options +FollowSymLinks
  # This is needed to parse /var/lib/roundcube/.htaccess. See its
  # content before setting AllowOverride to None.
  AllowOverride All
  Order allow,deny
  Allow from all
</Directory>

# Protecting basic directories:
<Directory /var/lib/roundcube/config>
  Options -FollowSymLinks
  AllowOverride None
</Directory>

<Directory /var/lib/roundcube/temp>
  Options -FollowSymLinks
  AllowOverride None
  Order allow,deny
  Deny from all
</Directory>

<Directory /var/lib/roundcube/logs>
  Options -FollowSymLinks
  AllowOverride None
  Order allow,deny
  Deny from all
</Directory>

Le fichier /etc/roundcube/debian-db.inc.php est généré par dbconfig-common. Vous n'avez pas besoin d'y toucher. Idem pour le fichier db.inc.php. Celui-ci configure les noms de tables à interroger pour récupérer les éléments spécifiques à chaque utilisateur.

Reste donc le fichier principal main.inc.php. Il est assez long et on y trouve de nombreux éléments. Voici quelques-uns de ceux que j'ai modifié pour que ça fonctionne:

// Vous devez mettre le nom de votre serveur IMAP
// Vous pouvez mettre plusieurs serveurs (cf: http://trac.roundcube.net/wiki/Howto_Config)
// Dans mon cas, la connexion se fait sur localhost
// J'ai utilisé ssl:// et non tls:// car ça ne fonctionnait pas !
$rcmail_config['default_host'] = 'ssl://localhost';

// Port TCP utilisé par défaut. Comme on est sur du ssl, j'ai mis 993.
$rcmail_config['default_port'] = 993;

// Vous ne voulez pas permettre la configuration en ligne:
$rcmail_config['enable_installer'] = false;

// Aucun intérêt à mettre en cache (dans la DB) du contenu local !
$rcmail_config['enable_caching'] = false;

// On impose l'utilisation du HTTPS:
$rcmail_config['force_https'] = true;

// Permet l'enregistrement du login/password dans le navigateur web:
$rcmail_config['login_autocomplete'] = 2;

// Le nom des titres de page web affichées
$rcmail_config['product_name'] = 'Poste électronique sur medspx.fr';

// Ne permettre aux utilisateurs de n'avoir qu'une seule identité:
$rcmail_config['identities_level'] = 3;

A noter que je n'ai rien configuré au niveau du serveur SMTP, roundcube semble utiliser la commande sendmail par défaut. Comme cette dernière est configurée pour utiliser notre serveur Exim4, il n'y a aucun problème. Finalement, le système global du courrier électronique séparé en parties uniques avec chacune son rôle est plutôt intéressant. Si cette organisation avait été monolithique, il aurait fallu configurer roundcube plus finement, voire qu'il dispose de son propre serveur SMTP.

Vous le voyez, il ne faut pas grand chose pour que Roundcube fonctionne: il faut juste configurer le serveur IMAP par défaut (et encore) et ça fonctionne out-of-the-box. Malgrès ça, il est possible de fortement personnaliser le programme ce qui est une bonne chose.

Enregistrement des utilisateurs:

Un des défauts de Roundcube est de se reposer sur une base de données pour fonctionner. Même si nous utilisons SQLite, il faut tout de même créer un compte utilisateur dans la base de données de Roundcube. Comme je n'avais qu'un nombre réduit de comptes à renseigner, voici comment j'ai procédé: j'ai utilisé la fonction d'auto enregistrement.

Si vous activez le paramètre: $rcmail_config['auto_create_user'] = true alors n'importe quel utilisateur ayant un compte valide sur votre serveur IMAP pourra se créer un compte sur Roundcube. Pour ma part, et pour des questions de simplicité, j'ai mis ce paramètre à false une fois que j'ai enregistré mon compte unique de serveur IMAP. Au moins de tout, je sais qu'à priori, personne d'autre ne peut plus se créer de compte Roundcube.

Conclusion:

Après avoir testé le logiciel pendant quelques semaines, voici quelques remarques sur son utilisation:

  • L'interface de base est sobre et bien pensée.
  • Les temps de latence sont quand même un peu longs. Rien à voir avec Mutt qui est quand même plus versatile et plus réactif.
  • Le javascript charge bien ma machine lorsque je souhaite choisir un message ou en supprimer un (50% de CPU pour accéder aux emails).
  • Par défaut, Roundcube recréé les répertoires IMAP dont il a besoin (Corbeille, envoyés).
  • On peut envoyer des emails et c'est plutôt pratique en déplacement même si c'est moins performant que Mutt.
  • Un truc sympathique: l'affichage en HTML. Si c'est le mal pour le courrier électronique, c'est une fonctionnalité intéressante pour la lecture des flux RSS/Atom livrés par feed2imap. Ca permet de les récupérer dans un format lisible avec un peu d'images et comme on est déjà dans un navigateur web, ça ne pose pas de soucis.

Pour terminer, j'ai plutôt un avis positif sur Rouncube. Sa configuration est assez simple et sa prise en charge sous Debian est bien menée. Il est assez simple d'utilisation et, pour mes besoins, il vaut largement GMail !

Posted lun. 13 juin 2011 07:13:58 Tags:

Solution de serveur de courrier électronique auto-hébergé (partie 7) : Concentrer l'information.

Comme de nombreuses personnes, je dispose de plusieurs adresses de courrier électronique. Vous le savez, jongler d'un compte à l'autre est pénible, même avec Mutt. Il existe néanmoins un "truc" qui existe sans doute depuis que le courrier électronique est né: les outils de concentration et de tri. Ces derniers permettent de récupérer des messages depuis de nombreux comptes, sur des machines différentes et d'appliquer des traitements dessus. Parmi ces traitements, il y a évidemment la copie dans un répertoire Maildir.

Je suis sûr que vous avez déjà entendu parler de tels outils: fetchmail et procmail en font partie. En ce qui me concerne, je n'avais pas envie de me mettre à ces deux outils qui sont très puissants mais qui dépassent largement mes moyens. Néanmoins, mes regards ont été attirés par fdm pour plusieurs raisons:

  • Il est très léger et il occupe très peu de place.
  • Il n'est pas en Python ou en Ruby (ce n'est pas un script) et semble robuste.
  • Il fait tout ce dont j'ai besoin (imaps et écriture dans un maildir).

Installation et configuration:

L'installation est très simple: aptitude install fdm. Il dispose de peu de dépendances et normalement, seul le paquet fdm et la libtdb seront installés. En version armel, il occupe environ 440Ko ce qui est vraiment minime.

Le fichier de configuration est personnel et il est situé dans \~/.fdm.conf. Cette configuration par utilisateur est tout à fait normale: la gestion du courrier électronique n'est-elle pas une activité purement privée qui ne concerne que l'utilisateur et non l'administrateur (dans un mesure moindre) ? Par défaut sous Debian, il n'y a pas de fichier central de configuration, normalement situé dans /etc/fdm.conf. Sachant que fdm travaille au niveau de l'utilisateur, autant tout mettre dans le répertoire home !

Ce fichier de configuration est assez complexe à mettre en oeuvre car fdm peut servir à faire de nombreuses choses comme des tris automatiques, des vérifications de spams, d'antivirus, etc... Notre cas d'utilisation est plus simple.

fdm exploite plusieurs "concepts" qu'il faut comprendre avant de se lancer dans la configuration:

  • Les comptes (mot-clef account) qui permettent de récupérer les emails depuis un serveur externe ou un pipe.
  • Les actions (mot-clef action) sont des commandes qui effectuent des traitements sur les messages (suppression, modifications d'en-tête, stockage dans un répertoire, etc...).
  • Les règles (mot-clef match) qui se chargent de lancer les actions sur les messages répondants à la règle.

Globalement, l'action de fdm suit le déroulement suivant:

  • Récupération des messages depuis les comptes décrits.
  • Chaque message se voit assigné une étiquette (tag) qui indique ses caractéristiques (compte, date, etc...).
  • Les règles sont vérifiées sur chacun des messages.
  • Lorsqu'une règle correspond, une action spécifique est lancée sur le message.

Voici un fichier de configuration simpliste pour mieux comprendre:

# Fichier simple de configuration de fdm
# Récupération depuis un compte POPS GMail et envoi
# dans une maildir spécifique

# Définition du compte (il sera référencé comme gmail):
account "gmail" pop3s server "pop.googlemail.com" port 995 
        user "jean.nemard@gmail.com" pass "my_true_password"

# Définition de l'action de stockage dans le bon répertoire maildir:
# Elle sera référencée comme gmailbox
action "gmailbox" maildir "%h/Maildir/.Gmail.inbox"

# Règle pour balancer les emails GMail dans le répertoire
match account "gmail" action "gmailbox"

Attention, ce fichier simpliste videra les messages de votre répertoire Inbox de GMail ! Mais, si vous désirez vous en passer, autant passer par là !

Dernière précision: les droits d'accès ! Fdm est pointilleux: il vous indique lorsque les fichiers sont en lecture par tout le monde. Pour éviter de pourrir trop vos logs, vous devez modifier les droits d'accès du fichier de configuration et des répertoires de Maildir:

chmod 600 ~/.fdm.conf
chmod -R 700 ~/Maildir/

Lancement automatique:

Pour lancer fdm, vous devez indiquer une commande sur les trois suivantes:

  • fetch: lance vraiment l'action de récupération des emails.
  • poll: indique combien de messages vont être traités
  • cache: permet de manipuler le cache.

Ainsi, si vous désirez lancer manuellement fmd, vous devez lancer la commande fdm fetch pour que l'action se lance vraiment.

Après vérification du bon fonctionnement de votre configuration, vous pouvez programmer une crontab:

# Activation de FDM toutes les heures tous les jours:
0 * * * *       /usr/bin/fdm fetch >/dev/null 2>&1

Conclusion:

Voici, rapidement, comment concentrer son courrier électronique dans une seule arborescence Maildir. FDM est vraiment bien pour cette action: il est léger mais puissant. On peut bien entendu aller plus loin avec. La documentation de cet outil se révèlera, dans ce cas, une précieuse alliée.

Posted ven. 17 juin 2011 22:11:07 Tags: