Copyright © 2003 Ben Okopnik
Le système de messagerie est - ou peut être - un des composants les plus complexes du puzzle Linux. En réalité, pour un grand nombre de personnes, il ne présente aucune complication : installation de Netscape, saisie des noms de serveurs POP/SMTP, nom d'utilisateur et mot de passe, c'est tout... sauf, bien sûr, pour toute autre tâche susceptible de faire appel au système de messagerie - comme l'écriture d'un script qui enverra un rapport par courrier électronique lorsque le système de fichiers est presque plein, la décision d'utiliser un autre lecteur de nouvelles Usenet, voire la tentative d'envoi par courrier électronique d'un rapport de « bogue » à l'aide des utilitaires « bug » ou « bashbug ».
Sous Unix, le courrier électronique est étroitement intégré au système d'exploitation lui-même, et le fait qu'il ne fonctionne pas correctement revient à conduire une voiture avec un pneu dégonflé. Les choses se passent plutôt bien tant que vous n'exigez pas de performances. Sinon, les problèmes s'accumulent en masse. Un système de courrier électronique fonctionnel - comme une connexion Internet - est une des hypothèses fondamentales dans tout système de type Unix. Mon souhait ici est de vous présenter au moins un exemple d'un système de courrier électronique applicable en pratique, que vous pourrez ensuite ajuster ou intercaler dans votre propre configuration ; le point important est de prendre conscience des éléments qui devront être opérationnels pour que tout ceci fonctionne.
Le système de courrier électronique consiste en trois éléments définis de façon quelque peu imprécise : le MUA (Mail User Agent, agent utilisateur de courrier), le logiciel que vous utilisez pour lire et rédiger votre courrier, le MTA (Mail Transfer Agent, agent de messagerie), habituellement un serveur SMTP, bien que certains programmes appelés directement s'emploient également, ainsi qu'un programme de récupération (certains serveurs SMTP contiennent aussi une fonctionnalité POP, mais un programme autonome est plus commun). Le MUA peut se présenter sous différentes formes à votre convenance, ce n'est qu'une interface : cela signifie que vous pouvez utiliser celui que vous préférez, dès lors que les deux autres éléments fonctionnent. Vous pouvez même garder Netscape si vous le souhaitez ! Pour les deux autres éléments, j'utiliserai Exim - un MTA bien connu - et le fetchmail d'Eric S. Raymond, probablement l'utilitaire de récupération le plus utilisé au monde.
La configuration de fetchmail ne présente aucune complexité particulière. Il vous suffit de créer un fichier appelé .fetchmailrc dans votre répertoire personnel et de spécifier vos informations de compte POP. À titre d'exemple, voici à quoi ressemble le mien :
# I want to log all retrievals in "/var/log/mail.*" set syslog # Set stuff that's the same for everybody defaults protocol pop3, timeout 300, nokeep, fetchall, mda "procmail -f-" # Get mail from my ISP poll "pop.happybruin.com", user "fuzzybear" password "wouldnt_you_like_to_know"; # Grab it from my other account poll "pop3.bearsden.com", user "ben-fuzzybear", password "shhh_its_a_secret"; |
Juste un rapide survol de ces quelques lignes - tout est très bien décrit dans la page manuel de fetchmail : je récupère mon courrier sur deux comptes différents. Comme j'ai une connexion Internet un peu cahotique (un modem sans fil), j'ai réglé fetchmail pour qu'il abandonne toute connexion au bout de 5 minutes (300 secondes). Je lui ai aussi ordonné de supprimer la totalité du courrier sur le serveur une fois qu'il est récupéré (nokeep), d'ignorer le drapeau « déjà lu », de relever tout le courrier en attente (fetchall) et d'utiliser procmail pour effectuer le traitement des en-têtes pour moi (mda ...). Le dernier paramètre n'est pas nécessaire pour tout un chacun, mais certains serveurs SMTP défectueux « oublient » d'inclure un en-tête appelé « Envelope-from » et celui-ci le corrige. En dehors de cela, je pense que tout est assez explicite.
Il y a généralement deux façons de lancer fetchmail : soit comme un des scripts init (ceci est utile si vous avez une connexion permanente), soit à partir de votre script /etc/ppp/ip-up.d (plus commun pour les connexions par modem). Habituellement, vous faites ce choix au cours de la configuration de fetchmail. Chaque utilisateur peut aussi le démarrer manuellement, comme une exécution unique (en saisissant simplement fetchmail sur la ligne de commande) ou comme un démon qui consultera les boîtes aux lettres à un intervalle fixé (je préfère procéder de cette façon, avec un fetchmail -d 600 qui consulte à des intervalles de 10 minutes. Ce réglage peut aussi être défini dans.fetchmailrc).
fetchmail est beaucoup plus flexible et puissant que ne le montre cette situation simple. Précisons simplement qu'il est capable d'effectuer presque n'importe quel type de récupération de courrier, avec n'importe quel type de protocole de messagerie valide ; à moins que vous n'ayez une configuration extrêmement complexe - et si tel était le cas, vous le sauriez - cela fonctionnera. Bien sûr, si vous préférez votre propre agent de récupération, c'est envisageable également.
La configuration de votre serveur SMTP ne doit pas nécessairement être beaucoup plus complexe que celle ci-dessus - mais devra sans aucun doute exiger nettement plus de réflexion. Le principal aspect à étudier est : où vous situez-vous sur l'Internet ? Pour ceux d'entre vous qui ne se sont jamais imaginés à aussi grande échelle, voici encore une autre pièce du puzzle : la réalité est que la plus grande partie du Net est composée de petits éléments - telles que l'ordinateur devant lequel vous êtes assis actuellement. Votre FAI (fournisseur d'accès Internet) n'est qu'un autre nœud du Net ; en effet, vous vous connectez par le truchement de leurs routeurs mais, dès lors que vous êtes connecté, vous constituez un élément du Net au même titre que lui - et avez, par voie de conséquence, la responsabilité de veiller à ce que votre petite pièce fonctionne en harmonie avec le reste.
Une des RFCs liée à la sécurité que j'ai lue récemment mentionne que peut-être 50 % ou plus des serveurs de messagerie connectés à l'Internet sont mal configurés à un niveau ou à un autre. Une statistique assez effrayante... mais aussi un témoignage de la fiabilité et de la flexibilité du système de messagerie. Tout cela met en évidence la nécessité pour chacun de nous d'apporter notre contribution au bon côté de la force - en jouant notre rôle.
Pour beaucoup d'entre nous, la situation est très simple : une machine de bureau, un seul FAI et aucun besoin de configurer notre propre SMTP - tout au plus est-il nécessaire de retransmettre l'ensemble de notre courrier au serveur SMTP de notre FAI. Dans ce cas, tout MTA ou presque conviendra - sans qu'il soit nécessaire de procéder à des réglages ultérieurs, hormis la réécriture des adresses. Contentez-vous de répondre aux questions qui vous sont posées au moment de la configuration et vous avez terminé, tout fonctionne. Néanmoins, cette partie du système est un peu plus « délicate » lors de modifications : si vous faites appel à plusieurs FAIs ou si vous souhaitez faire quelque chose qui s'écarte un tant soit peu des fonctions essentielles, une petite configuration s'impose et là, les choses se compliquent singulièrement.
<< Le fichier de configuration de sendmail ressemble à un fichier créé par quelqu'un qui se cogne la tête sur son clavier. Et après l'avoir examiné... je comprends pourquoi ! >> (Anonyme).
sendmail.cf est responsable du stress de plus d'un administrateur système et le fichier de configuration qui en ressort n'en est pas plus attrayant. Je l'ai un peu détaillé dans le numéro 58 de la Linux Gazette (Configurer Sendmail sous RedHat 6.2).
Sérieusement, c'est une question de décision. Si la connexion réseau de votre système doit changer dans ses principaux aspects (FAI, nom d'hôte, passage d'une connexion par modem à un hôte Internet permanente) plus d'une ou deux fois, vous devrez envisager la création de votre propre SMTP. À titre d'exemple, je configure mon propre SMTP parce que mon travail m'oblige à voyager et à utiliser un grand nombre de FAIs différents (modem, sans fil, modems câble dans les chambres d'hôtel, etc.) avec beaucoup de configurations système différentes. Procéder de cette manière signifie que je n'ai jamais à me préoccuper de la configuration du système de messagerie des autres, ni à configurer quoi que ce soit lorsque je passe d'un système à l'autre - une grande commodité. En d'autres termes, la création de votre propre configuration n'est pas une opération complexe à mettre en œuvre, mais c'est une décision critique que vous devrez prendre en fonction de vos propres besoins. Je trouve que l'approche « faites-le vous-même » est de loin plus flexible, puissante et sans tracas dans tous les cas où l'environnement est tout sauf statique.
Donc, à ce stade, nous avons défini deux configurations SMTP typiques :
Déléguer tout sauf la réécriture d'adresses (qui doit être réalisée localement). Le serveur SMTP des FAIs (le smarthost, de notre point de vue) veille à la totalité du routage. C'est une bonne façon de faire lorsqu'on a une configuration statique qui a peu de chances de changer, spécialement avec un FAI de première importance bénéficiant d'une bonne réputation de fiabilité.
Tout faire soi-même. Cette méthode a un certain nombre d'avantages, dont le contournement des services de courriers électroniques non fiables d'un FAI et la possibilité de voir instantanément si votre courrier a bien été distribué à l'hôte de l'autre côté (quelques années auparavant, mon FAI a conservé certains de mes courriers pendant plus d'une semaine, et en a annulé un lot sans m'avertir. C'est ce qui m'a poussé initialement à faire cela...).
Généralement, cette décision est prise durant l'installation du MTA. Il ne reste plus grand chose ; dans le cas d'Exim, vous avez cinq choix, dont seuls les deux premiers s'appliquent ici (le programme eximconfig s'exécute pendant l'installation ou peut-être manuellement réexécuté à tout moment) :
You must choose one of the options below: (1) Internet site; mail is sent and received directly using SMTP. If your needs don't fit neatly into any category, you probably want to start with this one and then edit the config file by hand. (2) Internet site using smarthost: You receive Internet mail on this machine, either directly by SMTP or by running a utility such as fetchmail. Outgoing mail is sent using a smarthost. optionally with addresses rewritten. This is probably what you want for a dialup system. ... |
Notez que ces deux choix remplissent les deux conditions ci-dessus : l'approche « faisons-le nous-mêmes » concorde avec le numéro 1 et la version smarthost avec le numéro 2.
... Which user account(s) should system administrator mail go to? Enter one or more usernames separated by spaces or commas. Enter `none' if you want to leave this mail in `root's mailbox - NB this is strongly discouraged. Also, note that usernames should be lowercase! |
Comme vous êtes la personne qui configure le système - je pars du principe que vous serez aussi celle qui l'administrera - redirigez ceci sur votre propre nom d'utilisateur. Si vous utilisez la route smarthost, vous serez invité à saisir le nom du smarthost ; prenez soin de saisir le nom du serveur SMTP de votre FAI correctement.
Une fois cette opération terminée - et nous en arriverons aux tâches à accomplir dans les deux différents cas - il faut configurer la réécriture d'adresses. Finalement, votre adresse électronique, telle qu'elle est perçue par le système est : nom_utilisateur@hote et, sauf si vous possédez votre propre domaine, celle-ci ne sera pas être une adresse Internet valide. Heureusement, avec Exim, ce n'est pas difficile.
Éditons tout d'abord /etc/exim/exim.conf et ajoutons les lignes qui suivent à la 6ème section (« REWRITE CONFIGURATION ») :
*@localhost ${lookup{$1}lsearch{/etc/email-addresses}\ {$value}fail} Ffsr
Ceci recherchera dans tout le fichier l'endroit où les règles de réécriture sont spécifiées et changera les adresses comme nécessaire. Notez que dans certains cas, exim.conf comportera déjà une ligne de ce type ; veillez simplement à ce que tout, et particulièrement les drapeaux Ffsr (qui réécrivent les en-têtes « Envelope-from », « From: », « Sender: » et « Reply-to: ») soit correct. Éditons à présent - surprise ! - /etc/email-addresses et insérons les éléments concernant tous nos utilisateurs.
# Root shouldn't be emailing anyone outside, but just in case... root: happybear@bruins.com ben: happybear@bruins.com rivka: sweetie@here.com linda: babe@westcoast.org jen: saucy@wench.net |
C'est tout. Contrairement à sendmail, il n'y a aucune base de données à reconstruire ; le fichier est lu «à la volée». Une des raisons pour laquelle j'apprécie Exim est que son fichier de configuration est abondammement documenté à l'aide de commentaires. De même, /usr/share/doc/exim/spec.txt.gz est un manuel exhaustif (et très volumineux) qui détaille minutieusement chaque point de la configuration.
Si vous continuez avec l'option smarthost, vous avez fini à ce stade. Passez directement à la section « Tests ». Si vous êtes comme moi un adepte du « faites-le vous-même », cependant, il reste juste quelques lignes à écrire : comme nous sommes dorénavant responsables de faire parvenir le courrier à destination, nous devons aussi faire face à la situation où la remise échoue (c'est-à-dire lorsque l'hôte récepteur ou un routeur intermédiaire est hors service, que nous perdons la connexion réseau pendant un moment, etc.). La majeure partie de ce comportement est déjà bien définie, comme dans tout MTA (Mail Transfer Agent, agent de messagerie) convenable, mais j'ai trouvé un moyen de réduire les «messages en anomalie» provenant d'Exim (qui vous l'enverra en tant qu'administrateur) presque à zéro : dans la première section de /etc/exim/exim.conf, ajoutez la ligne suivante :
auto_thaw = 5m
Lorsqu'un message est marqué « gelé » (non distribuable) par Exim, cette commande le « dégèlera » (tentera une nouvelle remise) au bout de cinq minutes. Du fait que la plupart des échecs ne sont que temporaires, ce paramètre se charge d'« acheminer » le courrier pratiquement en permanence, tant que l'utilisateur et le domaine sont valides.
Autre chose : maintenant que vous êtes un administrateur de messagerie à part entière, qu'êtes-vous exactement supposé faire ? Pas beaucoup plus, en fait : décider du sort à réserver aux messages en anomalie (si Exim vous avise d'un blocage dans la file d'attente, exécutez mailq pour savoir de quoi il s'agit et examinez le fichier journal avec exim -Mvl <message_id>), ajouter de nouveaux utilisateurs dans /etc/email-addresses et répondre à toute notification de problème de messagerie et de spam des autres intervenants. Lisez la page de manuel d'exim, juste pour vous familiariser avec ce monstre. C'est pratiquement tout. Les administrateurs expérimentés de messagerie de gros systèmes peuvent être horrifiés et émettre des mises en garde me concernant, mais pour une seule machine ou un petit réseau local (LAN), la description ci-dessus convient parfaitement à tout ce qui est exigé. Dans la mesure où il est correctement configuré, un système de messagerie est un outil remarquablement stable et en grande partie autocorrecteur.
Exim offre une série de modes de tests intégrés, dont un s'avère être très utile. Le principal point qu'il nous faut tester concerne le fonctionnement de nos règles de réécriture - et cette tâche est simple :
Baldur:~$ exim -brw ben sender: happybear@bruins.com from: happybear@bruins.com to: ben@localhost cc: ben@localhost bcc: ben@localhost reply-to: happybear@bruins.com env-from: happybear@bruins.com env-to: ben@localhost |
Testez-le avec un nom d'utilisateur banal, utilisateur@localhost et utilisateur@votre_nom_hote ; les deux adresses devraient être correctement réécrites. Faites le test en outre avec une adresse électronique arbitraire valide sur Internet pour vous assurer qu'elle ne change pas.
Dès lors que tout cela fonctionne comme il faut, votre système de messagerie devrait être assez bien configuré (les personnes qui mettent en place les diverses distributions font un travail efficace sur les fondementaux, dans tous les que j'ai vus jusqu'ici). Testez-le en vous envoyant quelques messages à vous-même et examinez les en-têtes ; « From: » et « Reply -to: » (si l'un est défini) devraient correspondre à votre adresse valide sur Internet et non uniquement à votre nom d'utilisateur normal. Voici un exemple (les adresses/IPs réelles ont été modifiées, comme dans le reste de cet article, pour éviter les spammeurs). Dans le menu de composition de mutt :
From: "Benjamin A. Okopnik" <ben@localhost> To: Benjamin Okopnik <happybear@bruins.com> Cc: Bcc: Subject: Rewrite test Reply-To: Fcc: =Sentmail Mix: <no chain defined> PGP: Clear |
Notez que dans le client local, l'adresse « From: » est une adresse locale. Vous pourriez aussi - maintenant que vous avez un système de messagerie réel - vous contenter de la saisir ainsi sur la ligne de commande :
mail -s "Rewrite test" happybear@bruins.com
Une autre façon - envoyons-la à présent et lorsque nous la récupérons - vérifions rapidement !
Date: Tue, 30 Apr 2002 03:47:19 -0400 From: "Benjamin A. Okopnik" <happybear@bruins.com> To: Benjamin Okopnik <happybear@bruins.com> Subject: Rewrite test WARNING: Deep Magic in progress. Ben Okopnik -=-=-=-=-=- |
Si nous étudions les en-têtes (dans Mutt, appuyez sur la touche h), nous observons les lignes suivantes :
From ben Tue Apr 30 03:48:15 2002 Return-Path: <happybear@bruins.com> Received: from Baldur (pzw-199-999-99-999.sunbridge.com [199.999.99.999])) by bruins.com (9.10.3/9.10.3) with ESMTP id g3U7lR45008674 for <happybear@bruins.com> Tue, 30 Apr 2002 00:47:32 -0700 (PDT) Received: from ben by Baldur with local (Exim 3.35 #1 (Debian)) id 172SM7-0004nd-00 for <happybear@bruins.com> Tue, 30 Apr 2002 03:47:23 -0400 Date: Tue, 30 Apr 2002 03:47:19 -0400 From: "Benjamin A. Okopnik" <happybear@bruins.com> To: Benjamin Okopnik <happybear@bruins.com> Subject: Rewrite test Message-ID: <20020430074718.GA18398@Baldur> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Status: U X-UIDL: 27862 WARNING: Deep Magic in progress. Ben Okopnik -=-=-=-=-=- |
En lisant les informations de routage du début à la fin, Exim a récupéré le message que j'avais émis, réécrit l'en-tête et bruins.com l'a reçu depuis Exim : donc, toutes ces étapes se sont correctement déroulées - cela signifie que les indications de mon MTA (Mail Transfer Agent, agent de messagerie) sont parfaitement reconnues par les autres. Si le message électronique avait disparu, j'aurais vérifié dans /var/log/exim/mainlog pour savoir exactement ce qu'il en était advenu, voire ma file d'attente pour savoir s'il y est bloqué. Néanmoins, il semble que toute cette magie porte ses fruits, et tout fonctionne.
Si vous avez suivi et êtes arrivé jusqu'ici... félicitations ! Vous êtes maintenant beaucoup plus qu'un «citoyen du Net» participant, un de ceux qui a fait don d'un peu de temps et consenti des efforts pour faire que le Net fonctionne un peut plus harmonieusement - et je suis heureux de partager l'espace IP avec des personnes comme vous.
Bonne continuation et joyeux Linux !
Ben Okopnik -=-=-=-=-=- |
Ben est un auteur qui contribue à la Linux Gazette et un membre du Answer Gang.
Ben est né à Moscou (Russie) en 1962. Il s'est intéressé à l'électricité à l'âge de six ans -- il le démontra rapidement en plantant une fourchette dans une prise électrique et déclenchant ainsi un début d'incendie -- et s'est plongé dans le dédale de la technologie depuis lors. Il travaille sur les ordinateurs depuis le début, lorsqu'il fallait les construire en soudant des composants sur des circuits imprimés, et que les programmes devaient tenir dans 4 ko de mémoire. Il paierait chèrement tout psychanalyste susceptible de le guérir des affreux cauchemars en résultant.
Les expériences ultérieures de Ben comprennent la création de logiciels dans près de douze langages, la maintenance de réseaux et de bases de données à l'approche d'un ouragan, la rédaction d'articles pour des publications allant des magazines consacrés à la voile aux revues sur la technologie. Ayant récemment bouclé une croisière de sept ans dans l'Atlantique et la mer des Caraïbes, il pour l'instant fait escale à Baltimore, Maryland (États-Unis), où il travaille comme instructeur technique pour Sun Microsystems.
Ben travaille avec Linux depuis 1997 et le crédite de sa perte complète d'intérêt pour les campagnes de guerre nucléaire sur les territoires nord-ouest du Pacifique.
Copyright © 2003, Ben Okopnik.
Copying license http://www.linuxgazette.com/copying.html
Paru dans le n°92 de la Linux Gazette de juillet 2003.
Traduction française par Guillaume Lelarge <gleu CHEZ wanadoo POINT fr>.
Relecture de la traduction française par Joëlle Cornavin <jcornavi CHEZ club-internet POINT fr>.