Page précédente Page suivante Table des matières

2. Passons aux choses sérieuses...

2.1 Présentation du problème

Le lecteur attentif aura sûrement remarqué la facilité de configuration des programmes de courrier « tous faits » comme le module courrier de Netscape ou Xfmail. Alors, pourquoi, se demandera-t'il, vouloir se compliquer la vie avec des usines à gaz comme sendmail ?

Le lecteur un peu curieux aura parcouru le chapitre concernant sendmail dans le livre « Administration réseau sous Linux » d'Olaf Kirch et n'aura pas manqué de lire avec effroi les lignes suivantes : « On dit souvent que celui qui n'a jamais édité un fichier standard sendmail.cf n'est pas un véritable administrateur UNIX. La légende dit aussi qu'il ne faut pas le faire deux fois, sous peine de devenir fou.  ». Olaf a sûrement raison (on peut lui faire confiance, quoique certains articles de comp.mail.sendmail prouvent que l'on peut vivre avec la folie...). Pour rassurer ceux qui n'ont pas encore fui, j'insisterai sur le fait qu'il n'est pas question ici de manipuler ce fameux fichier sendmail.cf : les fichiers de configuration d'UNIX sont quelquefois abscons, mais celui-là tient le pompon !

À moins de maîtriser parfaitement sendmail (ce qui ne doit pas concerner grand monde...), il est fortement déconseillé de modifier directement quoi que ce soit dans ce fichier ! D'ailleurs, si vous vous en sentez capable, merci de m'expédier vos commentaires sur cette doc...

Face à la complexité de cette syntaxe, plusieurs solutions ont vu le jour. Pour ma part, j'en connais au moins deux :

Pourquoi passer à sendmail alors que tout fonctionne bien avec des solutions comme Netscape ou Xfmail ? Sur une machine n'ayant qu'un seul utilisateur, moi, est-ce bien la peine d'utiliser un programme dont la vocation est de distribuer le courrier sur un campus universitaire ayant des centaines de machines ?

La réponse est, évidemment, oui. Pas par snobisme ou pour « jouer dans la cour des grands », mais d'abord parce qu'il s'agit d'un beau petit défi, ensuite parce que les 2 solutions que sont Netscape et Xfmail présentent un grave défaut : elles sont fermées. Vous devez récupérer, envoyer et consulter les messages avec un unique produit, en général incompatible avec les autres.

Avec sendmail, vous envoyez les messages en attente et récupérez les nouveaux dans votre boîte aux lettres et tout cela en utilisant le programme d'écriture/lecture de votre choix. Ici, le transport du courrier est séparé de sa création et de sa consultation. Ceci garantit que vous pourrez utiliser tous les logiciels UNIX écrits pour le mail car sendmail est le standard de facto (quoique certains utilisateurs lui préfèrent qmail). Alors, certes, c'est un peu d'effort, mais pas plus que d'arriver au bout d'un tableau de Quake... Et c'est sûrement plus rigolo.

2.2 Survol du fonctionnement de sendmail

Je disais ci-dessus que sendmail délivrait les nouveaux messages dans votre boîte aux lettres. En fait, c'est faux : sendmail utilise un autre programme pour délivrer le courrier qui lui est arrivé. Sous Linux, ce programme est, le plus souvent, procmail. Sauf lors de la configuration, on n'a pas à se soucier de ce dernier.

De plus, étant coupé du monde, il faut bien « alimenter » sendmail avec les nouveaux messages qui sont sur le serveur POP de notre F.A.I. : là encore, un autre programme entre en jeu, il s'agit de fetchmail qui remplace maintenant l'ancien programme popclient qu'il ne faut plus employer pour des raisons de sécurité. Le Guide du Rootard cite un autre programme de récupération : gwpop. fetchmail, dans ses versions récentes, dispose de nombreuses fonctionnalités et est capable de gérer d'autres protocoles que POP, mais nous ne l'utiliserons qu'à son minimum.

En résumé, une utilisation typique sera :

  1. écriture de courriers off-line ;
  2. connexion au F.A.I. ;
  3. expédition, sur l'Internet, des courriers écrits off-line avec sendmail ;
  4. récupération des nouveaux courriers, auprès du serveur POP du F.A.I., avec fetchmail ;
  5. déconnexion ;
  6. lecture des nouveaux courriers off-line.

On notera que les points 2 à 5 peuvent être regroupés en un seul script. D'autre part, il faut bien comprendre que sendmail n'intervient pas seulement au point 3, mais à chaque fois qu'il y a transport de courrier sur notre machine. Ainsi, lorsque vous écrivez du courrier destiné à l'extérieur et que vous l'envoyez tout en étant déconnecté, c'est sendmail qui se charge de le mettre dans une file d'attente. C'est le contenu de cette file qui sera envoyée au point 3. Lorsque fetchmail récupère les nouveaux courriers au point 4, c'est sendmail qui les dirige vers votre boîte aux lettres en utilisant procmail.

2.3 Fichiers utilisés par sendmail

Hormis le trop fameux /etc/sendmail.cf déjà évoqué, sendmail utilise un certain nombre de fichiers. En fait, dans le cas qui nous préoccupe, ce nombre a été réduit à la portion congrue : 6 fichiers suffisent, et encore, on pourrait s'en sortir avec 4... À ces 6 fichiers, il convient d'ajouter le fichier des macros m4 qui nous permettront de générer le fichier /etc/sendmail.cf, mais cette opération réalisée, il n'est plus utilisé. Je vous conseille cependant de le garder précieusement.

Bien sûr, les différentes pages du manuel ne sont pas comptées ici, ce qui ne veut surtout pas dire qu'il ne faut pas les lire.

Comme tout programme qui se respecte, sendmail utilise des fichiers trace qui permettent de repérer les éventuels disfonctionnement. Traditionnellement, il s'agit de /var/log/mail.err et /var/log/mail.log mais certaines installations les rassemblent en un seul fichier /var/log/maillog.

Le fichier /var/log/sendmail.st permet de consulter les statistiques grâce à la commande mailstats qui fait partie de la distribution.

Le fichier /usr/lib/sendmail.hf contient les messages affichés par sendmail.

Bien qu'il ne fasse pas partie de sendmail à proprement parler, le fichier /etc/hosts est utilisé.

Le fichier /etc/genericstable permet de préciser les réécritures des adresses locales.

Le fichier /etc/nsswitch.conf sera utilisé ici pour résoudre le problème des « DNS lookup » lors du dépôt des messages dans la file d'attente.

Si vous lisez des documents traitant de sendmail, vous verrez aussi évoqué des fichiers portant les noms de sendmail.dw, sendmail.ct, etc. Ils ne nous sont pas utiles ici.

Maintenant la bonne nouvelle : vous n'avez que sendmail.cf et /etc/genericstable à configurer, et, éventuellement, /etc/aliases et /etc/hosts à vérifier.

Enfin, avec sendmail viennent deux programmes : mailstats qui affiche les statistiques (taille des messages reçus et envoyés, etc.) et mailq qui affiche le contenu de la file d'attente des messages à envoyer.

2.4 Commençons par le commencement...

La première chose à faire est de vérifier que l'on puisse bien récupérer les courriers sur le serveur POP distant. On verra après ce qu'il convient de faire de ceux-ci.

Le programme utilisé s'appelle fetchmail, disponible sous forme de rpm dans la distribution Red Hat. De nouvelles versions apparaissent fréquemment : celle que j'utilise est la version 4.5.0 et de nouvelles versions apparaissent régulièrement.

Pour nos besoins, la configuration est très simple : elle consiste à créer un fichier .fetchmailrc dans le répertoire de l'utilisateur. Ce fichier sera lu à chaque exécution du programme et doit donc contenir les options globales d'utilisation. Depuis la version 4.5.0, cette opération de configuration est devenue triviale : le programme fetchmailconf est une interface graphique sous X disposant de deux modes (novice et expert) vous permettant de créer ce fichier sans douleur.

Un fichier .fetchmailrc typique pour notre configuration est :

# Configuration created Sun Jun 21 16:40:53 1998 by fetchmailconf
poll pop.fai.fr with proto POP3
       user "ego" there with password "xxxxx" is moi here

Pour plus d'informations sur la syntaxe de .fetchmailrc, consultez la page du manuel, ainsi que les différentes docs et fichiers exemples fournis avec la distribution (répertoire /usr/doc/fetchmail*).

Étant donné que le mot de passe de votre compte POP est en clair dans ce fichier, vérifiez qu'il ne peut être lu que par vous. D'ailleurs, si ce n'est pas le cas, fetchmail refusera de s'exécuter.

Ce fichier créé, on va tester la récupération en faisant en sorte de laisser les messages récupérés sur le serveur car, par défaut, fetchmail les supprime du serveur distant. Pour ce faire, et comme nous l'avons dit plus haut, nous allons travailler sous le compte root pour nous affranchir des problèmes de droits liés à la connexion. Créez un .fetchmailrc comme indiqué plus haut dans le répertoire /root, connectez-vous et tapez la commande :

fetchmail -k

L'option -k (keep) indique qu'il faut garder les messages lus sur le serveur. fetchmail dispose de nombreuses autres options : cf. le manuel.

Normalement, avec cette commande, vous devriez voir certaines choses s'afficher, notamment si vous avez ou non du courrier, et le nombre de messages qui sont récupérés. Si un message vous indique que la connexion n'a pu s'effectuer avec le serveur, vérifiez le .fetchmailrc, notamment que vous ne vous êtes pas trompés entre le nom d'utilisateur local et distant et que le mot de passe est correct.

Attention, vous risquez fort d'avoir des messages dus au fait que votre sendmail n'est pas installé ou configuré. Les messages qui comptent ici sont ceux vous informant que le courrier est récupéré, pas les messages vous avertissant que ce courrier ne peut être délivré localement.

2.5 Installation des paquetages sendmail et procmail

Ainsi que nous l'avons dit plus haut, sendmail ne fournit pas de programme permettant de délivrer le courrier. Pour cela, il faut utiliser un autre programme : le plus courant s'appelle procmail. Ces deux programmes sont disponibles pour toutes les distributions Linux : sous formes de paquetages rpm, deb ou tarballs. Utilisez la méthode préconisée par votre distribution (rpm, dpkg ou tar). Vérifiez aussi que le paquetage mailx est installé car c'est lui qui contient le programme mail vous permettant d'envoyer du courrier au moyen de shells scripts ou en ligne de commande.

Normalement, sendmail s'installe sous /usr/sbin/ en suid, il appartient à root et au groupe mail. Les programmes mailstats et mailq s'installent dans /usr/bin/ et appartiennent tous deux à root avec droits d'exécution pour tous. En fait, mailq n'est pas un programme mais un lien vers sendmail -bp. Enfin, procmail se trouve aussi dans ce répertoire et est suid.

Attention : Le paquetage rpm de sendmail pour la Red Hat a été divisé en trois : l'un contient les programmes, l'autre tous les fichiers permettant de le reconfigurer et le troisième contient la documentation(j'ignore la situation pour les autres distributions). Dans tous les cas, assurez-vous qu'un répertoire /usr/lib/sendmail-cf a été créé et qu'il contient plusieurs sous-répertoires. Parmi eux, /usr/lib/sendmail-cf/cf est celui qui nous intéresse au premier chef. Bien sûr, de nombreuses documentations sont placées dans /usr/doc/sendmail et les pages du manuel de sendmail et de procmail sont dans leurs emplacements habituels. Si /usr/lib/sendmail-cf n'existe pas, installez le paquetage correspondant aux fichiers de configuration (sendmail-cf*.rpm pour la Red Hat). De même, avec cette distribution Linux, la documentation ne sera présente que si vous avez installé le paquetage sendmail-doc*.rpm.

Normalement, l'installation aura aussi modifié vos fichiers de démarrage afin de lancer le démon sendmail lors du boot de votre machine (vérifiez les messages qui s'affichent). Selon les distributions, des outils existent pour préciser quels démons doivent être lancés au démarrage (par ex. tksysv ou linuxconf avec Red Hat) : pour utiliser sendmail, vous devez vous assurer que les démons network et sendmail tournent.

Vérifiez que le préprocesseur m4 est bien intallé sur votre machine (normalement dans /usr/bin) car il sera nécessaire pour créer le fichier /etc/sendmail.cf.

Le répertoire /usr/lib/sendmail-cf/ostype doit contenir un fichier linux.m4 qui définit des constantes propres à Linux, notamment celles indiquant le chemin de l'emplacement de procmail. Ne modifiez pas ce fichier ! Au pire, s'il n'existe pas, nous pourrons redéfinir ces variables dans notre fichier de configuration.

2.6 Création du fichier /etc/sendmail.cf

Nous y voilà ! La démarche est plutôt simple : sous root, nous allons créer un fichier config.mc dans le répertoire /usr/lib/sendmail-cf/cf.

Ce fichier se bornera à donner des valeurs à certaines constantes et à définir certaines options.

Enfin, nous compilerons ce fichier pour qu'il génère /etc/sendmail.cf.

Sous le compte root, mettez vous dans le répertoire /usr/lib/sendmail-cf/cf et, à l'aide de votre éditeur de texte favori, créez le fichier config.mc suivant :

include(`../m4/cf.m4')dnl
OSTYPE(`linux')dnl
define(`SMTP_MAILER_FLAGS', `e9')dnl
FEATURE(redirect)dnl
FEATURE(nocanonify)dnl
FEATURE(always_add_domain)dnl
FEATURE(local_procmail)dnl
GENERICS_DOMAIN(machine.domaine.fr machine localhost)
FEATURE(genericstable)
FEATURE(masquerade_envelope)dnl
define(`confCF_VERSION', `Eric Jacoboni - 14/01/98')dnl
define(`confCON_EXPENSIVE', `True')dnl
define(`confME_TOO', `True')dnl
define(`confCOPY_ERRORS_TO', `Postmaster')dnl
define(`confDEF_CHAR_SET', `ISO-8859-1')dnl
define(`confMIME_FORMAT_ERRORS',`True')dnl
define(`SMART_HOST', `smtp8:[mail.fai.fr]')dnl
define(`confTO_QUEUEWARN', `24h')
MAILER(local)
MAILER(smtp)

Pendant que vous êtes dans les éditions, créez le fichier /etc/genericstable suivant :

moi:  ego@mail.fai.fr
root: ego@mail.fai.fr
news: ego@mail.fai.fr

où l'espace suivant le « : » est un caractère de tabulation, pas une simple espace.

De même, modifiez, ou créez le fichier /etc/nsswitch.conf pour que chacune de ses entrées ne contienne que l'option files, sauf l'entrée hosts qui contiendra files dns (voir «  man 5 nsswitch » pour plus d'informations sur le système des Name Service Switch).

Vérifiez le fichier /etc/aliases et assurez-vous qu'il contienne au moins les deux entrées suivantes :

MAILER-DAEMON:  postmaster
postmaster:     root

Quelques explications :

À partir de ce fichier, vous pouvez maintenant générer votre fameux fichier /etc/sendmail.cf/ : placez-vous dans le répertoire /usr/lib/sendmail-cf/cf/ (c'est là que se trouve votre fichier config.mc et faites :

m4 config.mc > /etc/sendmail.cf

Assurez-vous que le traitement ne détecte pas d'erreur de syntaxe et vérifiez par un ls -l /etc/sendmail.cf que ce fichier ait les permissions suivantes : -rw-------, qu'il appartient à l'utilisateur et au groupe root.

2.7 La transformation des adresses de l'expéditeur

Passons maintenant au fichier /etc/genericstable : le rôle de celui-ci est lié à la caractéristique genericstable. Celle-ci permet aux adresses d'expéditeur locaux d'être réécrites sous une autre forme : lorsque moi postera un message, l'adresse de l'expéditeur sera moi@machine.domaine.fr et on conçoit que celle-ci risque fort d'être refusée par certains serveurs car il s'agit d'une adresse invalide (machine.domaine.fr n'est pas valide en dehors de chez vous...). Qui plus est, l'utilisateur moi n'existe que sur votre machine, pour l'Internet il s'appelle ego@mail.fai.fr.

Pour effectuer cette transformation de moi.machine.domaine.fr en ego@mail.fai.fr, sendmail procède en deux temps :

Ici, donc, machine.domaine.fr faisant partie des GENERICS_DOMAIN, l'entrée moi est recherchée dans la table et remplacée par ego@mail.fai.fr. On notera que le même effet aurait été obtenu avec une adresse d'expéditeur égale à moi@machine, moi@localhost ou, tout simplement moi... Dans ce dernier cas, un mécanisme supplémentaire à lieu : moi étant une adresse non qualifiée, elle est considérée comme locale et la caractéristique always_add_domain commence par lui rajouter le nom du domaine et on se retrouve donc dans le premier cas...

Nous pourrons vérifier toutes ces transformations lorsque nous testerons plus loin notre configuration.

Pour des raisons d'efficacité, la table de réécriture doit être transformée en un format plus rapidement accessible à sendmail qu'un simple fichier texte. La commande permettant de générer la table au format voulu à partir du fichier texte est la suivante :

/usr/sbin/sendmail -bi -oA/etc/genericstable

Vous pourrez vérifier qu'elle a produit un fichier /etc/genericstable.db dont le contenu vous échappera sans doute...

Bien entendu, cette commande doit être faite après chaque modification du fichier texte original.

De même, si vous avez modifié le fichier /etc/aliases, il faudra alors utiliser la commande newaliases pour regénérer la base des alias.

2.8 Vérification du fichier /etc/hosts

L'étape suivante consiste à vérifier le contenu de votre fichier /etc/hosts qui doit comporter une ligne ressemblant à ça :

127.0.0.1 machine.domaine.fr localhost  machine

Attention : Le nom complet de votre machine doit être le premier de la liste.

2.9 Rechargement de sendmail

Si un démon sendmail tournait déjà sur votre machine, il faut le tuer puis le relancer afin que toutes ces modifications soient prises en compte. Pour cela, faites :

kill `head -1 /var/run/sendmail.pid`
/usr/sbin/sendmail -bd -os


Page précédente Page suivante Table des matières