Un tour d'horizon des logiciels de messageries sous linux

Gazette Linux n°56 — Août 2000

Encolpe Dégoute

Adaptation française  

Frédéric Marchal

Correction du DocBook 

Article paru dans le n°56 de la Gazette Linux de août 2000.

Cet article est publié selon les termes de la Open Publication License. La Linux Gazette n'est ni produite, ni sponsorisée, ni avalisée par notre hébergeur principal, SSC, Inc.


Il existe de nombreux paquets qui fournissent les services standards de messagerie sous linux. À la base, le modèle de des UNIX et de Linux pour la messagerie électronique utilise les MTA (Agents de Transports de Messages), les MSA (Agents de Stockage et d'accès aux Messages) et les MUA (Agents Utilisateurs de Messageries). Mais il existe aussi un tas d'utilitaires qui ne correspondent pas réellement avec l'une de ces catégories.

Sous linux, il existe quelques MTAs dont sendmail, le plus courant dans la plupart des UNIX, ou qmail de D.J. Bernstein ou encore Postfix de Wietse Venema. Ceux-ci valident et relaient les messages. Cela semble couler de source, mais cela peut devenir très complexe dans la pratique. Il existe de nombreuses options de routage et de translation d'adresse (masquerading) qui peuvent être configurées comme politique d'administration — et ceci revient à programer des langages qui filtrent et modifient les entêtes de chaque message comme s'il était envoyé tel quel. De plus le processus de routage des messages et de recherche des boites aux lettres des utilisateurs (pour le stockage des messages) peut créer arbitrairement des interactions complexes avec divers services de répertoriation (DNS, fichier de mots de passe, NIS, alias LDAP et fichier dbm, plus tant d'autres bases de données personnalisées).

Aujourd'hui, les MTAs doivent aussi être implémentés avec des spécificités anti-spam, ce qui revient à utiliser des listes de contrôle d'accès et des règles sur les formats d'adresse (pour les champs To et From des entêtes) qui sont autorisés depuis des domaines et des classes d'adresse spécifiques. Ce qui revient aussi à des requêtes dans des tableaux ou des répertoires de services en incluant dans ceux-ci tout les équivalents du RBL de Paul Vixie (Real-time Blackhole List, Liste Noire Temps-réel) ou de MAPS (Mail Abuse Prevention System) avec ses clones, comme Dorkslayer/ORBS. Il y a peu de temps, les MTAs ont été largement sollicités pour renforcer d'autres politiques et pour être impléméntés avec des spécificités anti-virus et anti-intrusion.

Dans les cas les plus courants, c'est assez facile à installer et à configurer. En revanche, cette puissance à un prix : lorsque votre organisation a choisi de tailler sur mesure son MTA à vos besoins spécifiques de routage, de nomenclature, de sécurité et anti-spam, vous aurez besoin de plus d'options de configution sophistiquées et beaucoup d'entre elles provoqueront une chorégraphie d'interactions complexes entre votre MTA et divers autres sous-services (tel que n'importe quel serveur LDAP et DNS que vous utilisez).

Une fois que vous avez sélectionné, installé et configuré un MTA, vous avez généralement besoin de faire de même avec un MSA. De nos jours, la plupart des organisations ne délivrent pas les messages directement sur le bureau des systèmes clients. Elles stockent les messages sur des serveurs et les utilisateurs doivent relever leur courrier avec POP ou IMAP. Il existe d'autres protocoles pour gérer le stockage des messages, mais les deux seuls qui comptent réellement sont POP3 et IMAP4 (il y a aussi les anciennes versions de ces protocoles, bien sûr). Comme avec les MTAs, il existe de nombreux programmes (daemons) qui peuvent fournir ces services. La plupart des MSAs peuvent aller de paire avec n'importe lequel des MTAs. En supplément, ces systèmes utilisent habituellement le vérouillage et/ou d'autres mécanismes qui permettent à plusieurs MSAs d'être utiliser de concert sans conflits.

Cela veut dire que vous pouvez avoir des utilisateurs qui accèdent à leurs messages via POP, pendant que d'autres utilisent IMAP et que les derniers soient connectés en local et peuvent utiliser un MUA local (comme mutt, pine ou elm). Les utilisateurs individuels peuvent passer d'une méthode d'accès à sa messagerie à une autre, le plus souvent sans avoir besoin d'une intervention d'un administrateur système. Les utilisateurs intelligents peuvent souvent se passer des outils MSA/MUA standards et utilisent des commandes UNIX standard (comme cp et mv), et FTP ou rsync pour expatrier leurs messages aux alententours. C'est généralament trop rustre pour une utilisation normale, mais c'est très pratique pour réparer des boites aux lettres corrompues, etc.

La première fois que je fus appelé pour configurer un serveur POP sur un serveur Linux dédié général, je fus surpris de voir qu'il n'y avait pas de travail à effectuer. Un daemon POP avait été installé et mis en route quand j'eus installé le système de base ; je l'avais éteinds par la suite (en commentant une ligne dans le fichier /etc/inetd.conf) durant mes routines systèmes habituelles. Donc « configurer » ce service m'a simplement demander de décommenter une ligne dans un fichier, et de redémarrer un service/daemon.

IMAP est similaire. Quand POP transfert généralement les messages au système client, et les efface du serveur, IMAP permet à une personne de stocker la messagerie dans un répertoire coté serveur, et les copies des systèmes client sont essentiellement un cache, ou une copie de travail — ceci demande habituellementplus d'espace de stockage sur le serveur, mais cela permet à l'équipe de maintenance de se focaliser sur la sauvegarde/récupération du serveur et permet de considérer les sytèmes clients comme plus ou moins jetable. IMAP peut-être utilisé juste comme POP (Quand la messagerie est purgée du serveur après avoir été délivrée. Du point de vue opératoire, il n'y a pas beaucoup de différences. Ces deux services sont habituellement démarré par inetd (le service de répartition réseau ; le réceptionniste de linux si vous préférez).

Un serveur POP ou IMAP peut tourner pendant des années, servir des centaines, et même des milliers de boites aux lettres et d'utilisateurs sans demander d'attention particulière. Habituellement, vos utilisateurs ou leurs correspondants électroniques vont occasionellement faire quelque chose de stupide, ou un logiciel qu'ils utilisent va montrer un bogue (;-)), qui vont demander à l'administrateur système d'aller voir et soit de faire du nettoyage, soit de règler le problème.

Par exemple, prenons un jour lors duquel j'avais reçu des plaintes comme quoi la messagerie POP était cassée. Je me suis aperçu qu'un de ces utilisateurs s'était envoyé un petit message avec 100Mo en fichier attaché ! C'était une image mémoire d'un plantage Netware. C'était surtout bousculer l'espace disque et les vitesse/capacité du vieux 486 avec 32Mo que nous utilisions pour délivrer les messages à lui et aux cinquante autres personnes du département. J'ai réparé cela en quelques minutes avec des commandes shell, et j'ai utilisé quelques outils en ligne de commande pour uuencoder l'attachement dans un fichier que j'ai posé dans le répertoire racine de l'utilisateur. J'ai craché rapidement un script jetable pour extraire le reste de ses messages électroniques en lui construisant un nouvelle boite aux lettres. Les boites aux lettres sont de simples fichiers texte sous UNIX. Qmail les stockent dans des répertoitres avec de petits fichiers texte individuels, un par message. N'importe quel administrateur système compétent aurait fait la même chose.

Donc la majorité des problèmes que vous devriez rencontrer avec les MSAs et les MTAs peuvent être réparés avec un éditeurs de texte et les utilitaires et les commandes UNIX de courants.

Il existe de nombreux MUAs qui acceptent les serveurs POP et IMAP, en incluant Outlook de Microsoft. Sous Linux, beaucoup de personnes utilisent fetchmail pour relever leurs messages vers la file locale des messages (boites aux lettres). Alors ils peuvent utiliser n'importe quel MUA (elm, mutt, rmail d'emacs, pine, vmail, mh-e, gnus, et la pléthore de clients graphiques comme balsa, Mahogany, etc). Beaucoup d'autres utilisateurs de Linux choisissent le client de messagerie inclus dans Netscape Communicator.

Sous linux, et sous UNIX, il existe d'autres outils comme procmail, vacation, biff et fetchmail qui, comme je l'ai déjà dit, n'appartiennent à aucune de ces catégories classiques (MTA, MSA, MUA) que je vous ai décrites.

Habituellement, procmail est utilisé comme un agent de poste local (facteur). Il sert généralement à filtrer une partie du contenu final d'un message à son dernier destinataire. cela permet aux utilisateurs d'écrire des scripts pour sauvegarder, rejeter, répondre, transférer, et bien d'autres choses, avec une sélection des octets des messages qu'ils recoivent. Cela peut aussi servir à poster le contenu de la file d'une boite aux lettres et dans un cadre plus général comme langage/bibliothèque de programmation des messageries électroniques.

Vacation est un vieux programme qui peut-être utilisé pour fournir simplement une réponse automatique aux messages électroniques allant être reçus. A l'origine, il était utilisé pour prévenir les correspondants que le destinataire était « on vacation », en vacances. Ceci peut aussi être fait avec une recette procmail de deux ligne.

Biff est un utilitaire qui prévient un utilisateur qu'un message est arrivé. Il existe divers utilitaires équivalents pour faire cela dans les Interfaces Graphique Utilisateurs (GUI), affichant des icones, des animations, jouant de la « musique » or une annonce vocale, relayant les notifications de biff sur un réseau et utilisant divers modules de gestion principaux des protocoles MSA, etc.

Adaptation française de la Gazette Linux

L'adaptation française de ce document a été réalisée dans le cadre du Projet de traduction de la Gazette Linux.

Vous pourrez lire d'autres articles traduits et en apprendre plus sur ce projet en visitant notre site : http://www.traduc.org/Gazette_Linux.

Si vous souhaitez apporter votre contribution, n'hésitez pas à nous rejoindre, nous serons heureux de vous accueillir.