Copyright © 2000 Jim Dennis
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.
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.