Page suivante Page précédente 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 : le « kit jussieu », disponible à ftp://ftp.jussieu.fr/jussieu/sendmail/kit propose une génération automatique du sendmail.cf via un script de configuration qui utilise le préprocesseur du langage C. Ce kit comprend un document expliquant tout ce qu'il est nécessaire de savoir pour l'utiliser. Toutefois, il est plus dédié à des sites de type campus qu'à notre pauvre petite machine reliée par téléphone... les macros m4 permettent de préciser la configuration voulue dans une syntaxe relativement claire. Le fichier de macros est ensuite traité par le préprocesseur m4 pour produire un sendmail.cf. 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 : écriture de courriers off-line ; connexion au F.A.I. ; expédition, sur l'Internet, des courriers écrits off-line avec sendmail ; récupération des nouveaux courriers, auprès du serveur POP du F.A.I., avec fetchmail ; déconnexion ; 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 la ligne « poll » demande à fetchmail de scruter le serveur pop.fai.fr en utilisant le protocole POP3 ; la ligne suivante indique que votre compte sur le serveur POP est ego avec le mot de passe xxxxx et que les messages reçus venant de ce serveur et de ce compte sont pour le compte moi de votre machine. 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 : La ligne include(`../m4/cf.m4') demande l'inclusion dans le fichier des macros m4, nécessaires au traitement. La ligne OSTYPE(`...') provoque l'inclusion des spécificités d'un système d'exploitation particulier (ce qui se trouve entre ` et ' doit être un nom de fichier ayant l'extension .m4 et présent dans /usr/lib/sendmail-cf/ostypes/ : notamment le fichier linux.m4 définit le chemin permettant à sendmail de retrouver le programme procmail, utilisé pour délivrer localement le courrier. Si vous ne disposez pas d'un fichier linux.m4, créez-en un contenant  divert(-1) VERSIONID(`@(#)linux.m4 8.2 (Berkeley) 8/21/93') define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail')dnl define(`STATUS_FILE', `/var/log/sendmail.st')dnl mais ce ne sera normalement pas nécessaire car l'installation de sendmail vous en aura probablement fourni un. Vérifiez quand même que le chemin indiqué pour procmail est correct. Les lignes define servent à affecter des valeurs sous formes de chaînes à des variables qui seront prises en compte par sendmail. Ici, nous utilisons les variables : SMTP_MAILER_FLAGS. contient e (expensive) pour indiquer que les courriers envoyés par smtp sont « coûteux » car destinés à l'extérieur (exactement comme une lettre destinée à l'étranger coûte plus cher à affranchir qu'un courrier local..). On peut aussi combiner les options : `e9' rajoute l'option 9 qui force la conversion 8 vers 7 bits sur le contenu du texte. confCF_VERSION. contient des informations sur la version du sendmail.cf qui sera généré (habituellement l'auteur, pour flatter son ego, et la date). confSMTP_MAILER. contient le protocole utilisé : ici, on indique qu'on utilise un protocole (SMTP = Simple Mail Transfer Protocol) permettant d'envoyer des courriers contenant des caractères codés sur 8 bits. confCON_EXPENSIVE. est ici mis à vrai pour forcer la mise en file d'attente des mails considérés comme « coûteux » (donc de tous les courriers destinés à une autre machine que la nôtre, voir SMTP_MAILER_FLAGS plus haut). confME_TOO. est positionné pour que les messages envoyés à une liste de diffusion dont on fait partie nous soient aussi expédiés. confCOPY_ERRORS_TO. indique à qui les messages d'erreurs doivent être copiés. Normalement, sur une machine isolée, le Postmaster est root (voir le fichier /etc/aliases), c'est donc lui qui recevra ces messages. confDEF_CHAR_SET. indique au destinataire comment est codé notre courrier, ce qui lui permettra de le décoder correctement. ISO-8859-1 est le standard pour la France : appelé aussi ISO-LATIN-1, il utilise les 128 dernières combinaisons du code ASCII sur 8 bits pour coder les accents nationaux. confMIME_FORMAT_ERRORS. est mis à vrai pour que les courriers d'erreurs (destinataire non trouvé, par exemple) soient au format Mime. SMART_HOST. donne le protocole et le serveur qui sera utilisé pour résoudre les adresses. Ici on utilise SMTP8 (Simple Mail Transfer Protocol) permettant d'envoyer à mail.fai.fr des courriers contenant des caractères codés sur 8 bits TO_QUEUEWARN. modifie le temps que mettra sendmail pour envoyer un message prévenant que des messages sont en attente d'envoi dans la file d'attente. Par défaut, ce délai est de 4 heures ce qui peut s'avérer trop court dans le cas d'une connexion épisodique par PPP. Nous la fixons ici à 24 heures car nous nous connectons au moins une fois par jour. Les lignes FEATURE servent à fixer certaines caractéristiques du fonctionnement de sendmail. Ici, nous utilisons les suivantes : redirect. automatise l'émission d'indication de redirection (vous ne comprenez pas ? moi non plus : ce n'est pas grave !). nocanonify. pour que sendmail ne tente pas de transformer l'adresse du destinataire en « adresse canonique » (de la forme dupont@truc.fr). Ceci suppose que vous fournirez toujours les adresses canoniques à sendmail. Cette caractéristique permet d'éviter les « name lookup » que sendmail génèrerait du fait qu'il ne connaît pas le domaine truc.fr puisque notre machine n'a pas de serveur DNS. always_add_domain. pour que toutes les adresses locales soient suffixées par le nom de notre domaine. local_procmail. pour que sendmail utilise procmail. masquerade_envelope. pour que le champ From de l'enveloppe soit correct. En fait, pour que l'enveloppe elle-même soit masqueradisée. Cette caractéristique est employée de concert avec la caractéristique genericstable qui la précède. Toute cette « mascarade » n'a qu'un but : cacher à l'extérieur le nom rigolo qu'on a mis tant de temps à trouver pour baptiser notre machine... En effet, certains destinataires suspicieux (et on les comprend) rejettent systématiquement tout message en provenance de domaines dont ils ne peuvent vérifier l'existence, et ils ne pourront jamais prouver l'existence de votre machine, cachée à l'autre bout de votre connexion ppp. Ces rejets sont une première forme de réaction contre les messages non sollicités (souvent des publicités !), dits « UCE ». Cela dit, certains, plus suspicieux que les autres, ne s'en tiennent pas là : ils rejettent aussi tous les messages venant de domaines connus (généralement des fai), considérés par eux comme vecteurs possibles de messages fâcheux. Dans ce dernier cas, la masqueradisation n'aura pas d'effet... Les lignes MAILER servent à spécifier les protocoles utilisés pour transporter notre courrier. Ici, on indique que l'on utilise le transport local et via smtp. À 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 : il vérifie que l'adresse de l'expéditeur appartient à l'un des domaines spécifiés par la macro GENERICS_DOMAIN si c'est le cas, il recherche une entrée correspondant à cet expéditeur dans la table générée à partir de /etc/genericstable. 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 suivante Page précédente Table des matières