Par JC Pollman jpollman@bigfoot.com et Bill Mote
bill.mote@bigfoot.com
De prime abord, cela semble un projet assez simple, et pourtant relativement ambitieux : si vous n'êtes pas en terrain connu, dites adieu à toute votre petite famille pour pas loin d'une semaine. Soyez cependant assurés que le jeu en vaut la chandelle.
Cet article fournit des renseignements glanés à la faveur de la lecture de livres, de HOWTOs, de pages de man, de forums de discussion Usenet et d'un nombre d'heures incalculable passées à frapper au clavier. Il n'est pas censé être l'étude définitive sur la question, mais plutôt, un marchepied permettant à l'utilisateur novice de gagner ses galons d'initié. Tous les exemples sont tirés directement de nos réseaux domestiques, par conséquent, nous savons qu'ils fonctionnent.
[Entrée] indiquent un
appui sur une touche du clavier ou un bouton de la souris
[Souris1].{votre nom ici}
indiquent des données auxquelles on doit/devra en substituer de
"vraies".
Ce guide suppose que vous avez installé les choses suivantes :
Avant de foncer tête baissée dans les arcanes de ce projet, voyons ce que nous en attendons :
Le courrier électronique domestique a l'air simple de prime abord, d'autant que beaucoup de programmes de gestion et consultation du courrier, comme Netscape, semblent en prendre en charge toutes les fonctions de base par eux-mêmes. Malheureusement, il y a une grande différence entre un "système" de courrier orienté utilisateur et le même système orienté réseau. Pour fonctionner correctement, le vôtre devra comporter au moins cinq programmes :
Avant de commencer, assurez-vous que tout le nécessaire est
installé. Le plus simple est de lancer la commande whereis :
whereis sendmail [Entrée]
Les utilisateurs de RedHat peuvent taper :
rpm -qa|grep sendmail [Entrée]
procmail : Peu importe la version fournie avec votre distribution.
ipop3d : Idem. Note : la plupart des distributions placent ipop3d dans le paquetage imap.
fetchmail : Fetchmail est insaisissable et de nouvelles versions sortent fréquemment. Nous vous suggérons d'utiliser une version au moins égale à la 5.0, bien que celle qui vous a été fournie convienne probablement.
sendmail : Dans la plupart des distributions, on trouve trois paquetages sendmail : sendmail, sendmail-cf, et sendmail-doc. Installez-les tous. Dans cet article, nous utiliserons la version 8.9.3 de sendmail. Si vous avez toute version inférieure à la 8.9.2, nous vous engageons vivement à procéder à une mise à jour, à la fois pour des raisons de sécurité et parce que la plupart des données présentées ici ne seront pas appliquables à des versions plus anciennes.
m4 : Toute version fournie fera l'affaire.
Allons-y ! Faîtes 10 séries d'exercices avec les doigts, remplacez le CD de Led Zeppelin par du Mozart et cliquez sur les liens ci-dessous. Note : suivez-les DANS L'ORDRE, quelques programmes dépendant d'autres.
Dans l'article du mois dernier, nous avons configuré le dns, programme qui assure la fonction de serveur de noms. Sendmail, comme la plupart des autres agents de transport de courrier ont recours au dns pour déterminer où envoyer les messages, aussi devons nous en adapter quelque peu la configuration. Le fichier de correspondance nom-vers-IP doit comporter une ligne MX pour chaque machine, qui dit en gros : pour cet ordinateur, utiliser cet autre pour stocker le courrier.
Le fichier du mois dernier ressemble à ceci :
@ IN SOA master.kulai.org. jpollman.kulai.org. (
1;
10800;
3600;
604800;
86400 );
IN NS master.kulai.org.
master IN A 192.168.124.10
mail IN A 192.168.124.10
www IN A 192.168.124.10
news IN A 192.168.124.10
localhost IN A 127.0.0.1
fserver IN A 192.168.124.11
jc IN A 192.168.124.1
phillip IN A 192.168.124.20
Que nous modifions pour inclure les lignes MX. A présent, il ressemble à ceci :
@ IN SOA master.kulai.org. jpollman.kulai.org. (
1;
10800;
3600;
604800;
86400 );
IN NS master.kulai.org.
IN MX 10 master
master IN A 192.168.124.10
master IN MX 10 master
mail IN A 192.168.124.10
www IN A 192.168.124.10
news IN A 192.168.124.10
localhost IN A 127.0.0.1
fserver IN A 192.168.124.11
fserver IN MX 10 master
jc IN A 192.168.124.1
jc IN MX 10 master
phillip IN A 192.168.124.20
phillip IN MX 10 master
Maintenant, le serveur de courrier de chaque machine (master, fserver,
jc, phillip) est master.kulai.org (en fait on l'appelle un
"distributeur de courrier", mais comme nous n'avons qu'un seul
ordinateur faisant office de serveur, il fonctionne comme un serveur
de courrier). Nous avons également une ligne sans nom qui pointe vers
master.kulai.org en tant que serveur de courrier, c'est pour le
courrier destiné au domaine kulai.org. Vous aurez remarqué un
"10" à chaque ligne. Le nombre, 10 dans le cas présent, est une valeur
relative, et est utilisé lorsqu'on a plusieurs distributeurs de
courrier, chose que nous n'abordons pas ici. Notez que le fait
d'omettre ce nombre sera la cause d'une erreur dans named.
A présent, relancez named et contrôlez
/var/log/messages pour d'éventuelles erreurs.
Vous devez ajouter une ligne pour chaque machine : kulai.org tout seul ne marchera pas.
Pour les besoins de cet article, tout ce que nous voulons que
procmail fasse est de placer le courrier dans les comptes des
utilisateurs dans /var/spool/mail. De ce fait, vous devrez
supprimer tous fichiers ~/.procmailrc et ~/.forward
de leur répertoire d'accueil. Procmail méritant un article
entier à lui seul, nous n'en parlerons pas ici. Pour ce que nous en
faisons, il suffit qu'il soit installé sur votre serveur pour que cela
fonctionne.
C'est un programme très puissant. Une fois votre système de courrier électronique domestique entièrement configuré, voici ce qu'il pourra faire pour vous :
Sendmail traîne une mauvaise réputation en raison de vieux problèmes de sécutité et parce que son fichier de configuration, sendmail.cf, est une véritable horreur, vicieuse, infestée de verrues et quasi-impossible à comprendre et à modifier. Aimeriez-vous, par exemple, apporter des changements à ce morceau :
# localize and dispose of route-based addresses R@ $+ : $+ $@ $>96 < @$1 > : $2 handle <route-addr>
Sendmail est un programme basé sur des règles : elles déterminent sa façon de réagir. O'Reilly a publié le "Bat Book", arborant une chauve-souris sur sa couverture, au sujet de sendmail : il fait 1021 pages ! Nous n'aborderons pas les règles ici, nous voulons juste le faire tourner. Une fois que êtes satisfait de la configuration de base, sendmail se révèlera une mine très profonde de laquelle vous pourrez extraire toutes les pépites que vous voudrez. Afin de pouvoir le faire fonctionner, vous devrez éditer un certain nombre de fichiers. Nous allons les passer en revue un par un.
Pré-requis : pour commencer, créez un utilisateur avec le même nom
de login que le compte email chez votre FAI, par exemple, le
mien étant jpollman@deniz.com, sur mon serveur j'ai un
compte : jpollman@kulai.org. Une fois que sendmail
fonctionne avec ces paramètres, vous pouvez aller voir
Sendmail-Address_Rewrite Howto pour pouvoir utliser un autre
nom local.
/etc/mail/aliases : selon votre distribution, ce fichier peut être /etc/aliases. Il a deux grandes raisons d'être : permettre à tous les démons de niveau administrateur comme utilisateur d'expédier des rapports à quelqu'un et créer des listes de groupes. Si ce dernier point vous intéresse, veuillez consulter la page de man de sendmail. Par défaut, les démons envoient leurs rapports à root, mais vu que vous ne vous loguez PAS en tant que root de façon régulière (si si, je sais que vous ne le faites pas !), il est préférable que tout le courrier de root vous parvienne. En éditant le fichier, vous trouverez normalement ces deux lignes à la fin :
# Person who should get root's mail root: jpollman@kulai.org
En principe, il y a un # au commencement de la deuxième ligne (avec
root: au début). Enlevez le # et ajoutez votre adresse email
domestique à la droite du ":". Après avoir sauvegardé le fichier,
tapez : newaliases [Entrée]
Newaliases va convertir le fichier aliases sous une
forme que sendmail peut lire efficacement et le sauver sous
aliases.db. A peu près tous ceux qui se sont amusés avec
sendmail en sont venus, tôt ou tard, à éditer le fichier
aliases, puis à relancer sendmail et s'arracher les cheveux
parce que les nouveaux alias n'étaient pas pris en compte. N'oubliez
pas de lancer newaliases !
/etc/mail/relay-domains : là encore, ce peut être /etc/relay-domains. Ce fichier dit à sendmail que s'il reçoit du courrier de machines qui y sont énumérées, il devrait le traiter. S'il est vide, vous ne pouvez pas utiliser sendmail comme hôte SMTP pour votre réseau car il n'acceptera aucun courrier venant d'autres ordinateurs. Il faut que chaque machine qui utilisera votre serveur y soit référencée. Il y a probablement sur le groupe comp.mail.sendmail plus d'articles sur les problèmes de relais que sur aucun autre sujet. D'après la FAQ de sendmail :
Vous devez ajouter le nom d'hôte complet et/ou l'adresse IP
pour chaque client de la classe R, le jeu de domaines autorisés à
faire du relais. Pour 8.9.X, c'est typiquement
etc/mail/relay-domains. NB : si votre DNS pose des problèmes,
il se peut que vous ayez à indiquer les adresses IP entre crochets
(par exemple, [1.2.3.4]) pour que la macro ${client_name} fonctionne
correctement. Mais d'une façon générale, cela ne devrait pas être
nécessaire.
Mon fichier relay_domains ressemble à ceci :
jc.kulai.org phillip.kulai.org fserver.kulai.org
/etc/sendmail.cw : ce fichier sert à sendmail à
prendre connaissance de l'endroit où il se trouve et des alias du
serveur sur lequel il tourne. Le mien a la simple ligne : kulai.org.
/etc/sendmail.cf : à présent, le monstre lui-même !
Heureusement pour nous, les choses sont considérablement plus simples
qu'elles ne l'ont été. Voici l'essentiel de ce que nous allons faire :
modifier un fichier sendmail.mc générique, le donner en
pâture à m4, en faire une copie sous le nom de
/etc/sendmail.cf, et relancer sendmail. En fait,
c'est assez facile.
Allez en /usr/lib/sendmail-cf/cf. Vous devriez y trouver un
fichier d'extension mc. Si ce n'est pas le cas, il se peut
qu'il y en ait un nommé redhat.mc. Et s'il est manquant à
l'appel, copiez
ce fichier dans
ce répertoire. Comme nous savons qu'il marche, nous vous recommandons
vivement de démarrer avec notre fichier :^) . A présent copiez ce
fichier sous un autre nom, comme, par exemple, celui de votre
serveur : master.mc. Il est plus prudent de conserver le fichier
originel en l'état, ainsi, si vous mettez la panique à bord, vous
pourrez au moins tout recommencer à zéro. Editez votre fichier
mc. Beaucoup de règles sont déjà définies par défaut, et
elles fonctionnent bien comme tel. Pour que cela marche avec votre
serveur, ajoutez ces lignes à la fin du fichier. NB : mon serveur SMTP
est ix.deniz.com et mon FAI deniz.com, les vôtres
sont différents, donc ne vous contentez pas de copier ces lignes sans
les modifier !
define(`SMART_HOST',`smtp:[ix.deniz.com]') MASQUERADE_AS(`deniz.com') FEATURE(`masquerade_envelope') define(RELAY_MAILER, TCP) FEATURE(`accept_unqualified_senders')
SMART_HOST : c'est l'hôte SMTP de votre FAI et c'est là que sendmail enverra le courrier qui n'est pas destiné au domaine kulai.org, c'est à dire, ix.deniz.com pour moi.
MASQUERADE_AS(`deniz.com') : va ré-écrire une partie de la
ligne d'en-tête "From:" de vos emails de façon à ce qu'ils semblent
venir de deniz.com, là où se trouve mon adresse email sur
Internet. NB : remplacez deniz.com par votre FAI -
deniz.com pourraient prendre ombrage du fait que d'autres
personnes (des spammers ?) tentent d'utiliser leurs
services. Autrement dit, deniz.com n'autorisera aucun
courrier depuis jpollman@kulai.org, seulement depuis
jpollman@deniz.com. Ceci est dû à leur fichier
relay-domains.
masquerade_envelope : va ré-écrire une partie de l'en-tête du courrier afin qu'il ait l'air de venir de chez deniz.com.
RELAY_MAILER, TCP : ce n'est pas réellement nécessaire, mais ça ne mange pas de pain.
accept_unqualified_senders : dans le cas où vous avez
jpollman@deniz.com dans la ligne d'en-tête From: de votre
MUA, sendmail acceptera le courrier. En principe, il attend
kulai.org comme domaine.
Notez aussi que sendmail fait usage des deux apostrophes : ` et '.
Maintenant, pour rendre ce fichier relativement facile à lire en sabir sendmail, tapez :
m4 master.mc > _master.cf [Entrée]
où master.mc est le fichier que vous avez édité et
_master.cf le nom que m4 doit donner à celui qu'il
va créer. C'est très rapide : sur mon Pentium II 266, cela prend à peu
près 2 secondes. _master.cf correspond au fichier
sendmail.cf en bonne et due forme. Nous aurions pu tout
aussi bien taper : m4 master.mc > /etc/sendmail.cf, mais il
est préférable de garder une copie de plus sous la main. A présent,
copiez _master.cf en /etc/sendmail.cf, ce qui
écrasera votre version précédente de sendmail.cf : vous
devriez peut-être faire une copie de l'original avant, au cas
où. Relancez sendmail par un : killall -HUP
sendmail (sous Redhat : /etc/rc.d/init.d/sendmail restart).
Au démarrage, sendmail dispose de nombreuses options. Cliquez ici pour les voir. Pour résumer :
cp /etc/sendmail.cf /etc/sendmail.original
m4 master.mc > _master.cf
cp _master.cf /etc/sendmail.cf
killall -HUP sendmail
Si tout s'est bien passé, il ne vous reste plus que les essais à faire. Envoyez un courrier à quelqu'un de votre réseau et un autre sur l'adresse email de votre FAI. Si tout ceci fonctionne, vous pouvez référencer les autres machines de votre réseau, y compris celles qui tournent sous l'un des systèmes d'exploitation de Microsoft, sur votre serveur de courrier pour les services SMTP.
Dans le cas où tout n'irait pas comme vous le voulez, il y a 3 modifications que vous pouvez faire à la main :
1. Si sendmail ne peut pas "trouver" votre serveur de courrier :
Editez votre fichier /etc/sendmail.cf, recherchez cette ligne :
#Dj$w.Foo.COM
et changez-la en :
Djmaster.kulai.org
où master.kulai.org est le nom de votre serveur. NB :
retirez le # au début de la ligne, car c'est la marque d'un
commentaire. C'est une des règles de sendmail et elle lui
donne le nom du serveur de courrier, au cas où il n'aurait pas ce
qu'il veut via le dns ou par d'autres biais.
2. La traduction d'adresses fondée sur la destination :
J'ai eu le plus grand mal à obtenir de sendmail qu'il
camoufle seulement le courrier envoyé sur Internet, et pas celui
destiné au réseau local. Par exemple, je voulais que le courrier local
indique l'expéditeur sous la forme : bmote@kulai.org et non
bmote@deniz.com, mais qu'évidemment celui expédié sur
Internet comporte : bmote@deniz.com. Pour remédier à ce
problème, vous devez éditer le fichier
/etc/sendmail.cf. Trouvez-y les définitions des règles
locales 10 et 30 (astuce : cherchez S10 et S30), et effacez ces 2
lignes ou mettez-les en commentaire avec un #.
# Envelope sender rewriting
#
S10
R<@> $n #errors to mailer-daemon
R@ <@ $*> $n #temporarily bypass Sun bogosity
R$+ $: $>50 $1 #add local domain if needed
R$* $: $>94 $1 #do masquerading <-- delete this line
#
# Header sender rewriting
#
S30
R<@> $n #errors to mailer-daemon
R@ <@ $*> $n #temporarily bypass Sun bogosity
R$+ $: $>50 $1 #add local domain if needed
R$* $: $>93 $1 #do masquerading~ <-- delete this line
Il n'y a pas de solution faisant appel à m4 pour ceci, vous devrez
donc modifier sendmail.cf directement. Bien sûr, il faudra aussi relancer
sendmail juste après.
NB : comme j'ai jpollman@kulai.org dans la ligne
From: de mon MUA, sendmail ne camouflera que le
courrier sortant. Mes vifs remerciements à : Achim Löbbert pour
la solution.
3. L'utilisation de noms non-canoniques échoue :
Si vous vous contentez d'entrer le nom de l'utilisateur dans le
champ To: de l'email, et qu'il se perd dans l'Internet, il se
peut que vous deviez dire à sendmail où placer le courrier
adressé avec des noms non-canoniques. Ajoutez ceci à la fin de votre
fichier master.mc :
define(`LOCAL_RELAY',`mail.kulai.org')
LOCAL_RELAY : ici encore : en lieu et place de
mail.kulai.org, indiquez le nom de votre serveur. Cette ligne
permettra à sendmail de lui envoyer des noms simplifiés
(non-canoniques), comme "bmote", c'est à dire qu'il ajoutera
"kulai.org" à "bmote" pour vous. De ce fait, il vous suffira de taper
"bmote" dans le champ To: de votre MUA au lieu de
"bmote.kulai.org". Bien sûr, il vous faudra en passer encore par la
séquence m4, copie, redémarrage, pour que cela prenne effet.
Je n'ai pas la moindre idée du nombre de fois que j'ai passé mes
fichiers sendmail.mc à la moulinette m4, puis lancé la suite
copie/redémarrage. J'ai écrit un script de shell pour le faire à ma
place. A présent, tout ce que j'ai à faire est d'éditer le fichier
master.mc et taper : ./newsendmail (le nom du
script). Le voici :
#!/bin/sh m4 master.mc > _master.cf cp _master.cf /etc/sendmail.cf /etc/rc.d/init.d/sendmail restart
/usr/lib/sendmail-cf/cf et rendez-le exécutable
chmod 700 newsendmail [Entrée]
Configurer un serveur pop3 est très simple. Il faut commencer par le serveur lui-même, puis les comptes.
Editez le fichier /etc/services, assurez-vous que ces deux
lignes y sont et enlevez tout # par lesquels elles pourraient
commencer :
pop-3 110/tcp # PostOffice V.3 pop 110/tcp # PostOffice V.3
Ensuite, faites de même avec le fichier /etc/inetd.conf et la ligne qui suit :
pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
et enfin, relancez inetd en tapant :
killall -HUP inetd [Entrée]
Maintenant, votre serveur pop3 est totalement opérationnel. Simple comme bonjour.
Il distribuera du courrier à tout utilisateur y ayant un compte en
se servant du nom de login et du mot de passe. Si certains d'entre eux
ne doivent s'y connecter que pour du courrier, il conviendra, pour des
raisons de sécurité, d'interdire leur accès aux autres services. Pour
rendre un compte inutilisable en login, il suffit de mettre un * dans
le champ mot de passe du fichier /etc/passwd, et de spécifier
un shell bidon - comme /bin/false - dans le dernier champ de
l'entrée. Ils pourront toujours recevoir et envoyer du courrier, de
même qu'utiliser le modem si la translation d'adresses est validée,
mais ils ne pourront plus faire de telnet, de ftp ou
lancer à distance des programmes sur le serveur de courrier lui-même.
Beaucoup d'entre vous pourraient vouloir utiliser imap, au lieu de pop3. Pour les besoins de cet article, commencez donc par configurer pop3, et une fois que tout fonctionnera, essayez imap. Bien que celui-ci apporte de nombreux avantages à l'utilisateur, en particulier, si vous naviguez entre les systèmes d'exploitation et les MUA, nous avons de fortes réticences à son sujet. Presque à chaque fois que quelqu'un a tenté de s'introduire par effraction sur mon serveur, cela a été par le truchement de imap. Il y a eu quelques problèmes de sécurité avec les premières versions, mais ils sont à présent réglés et nous vous encourageons vivement à n'utiliser que la toute dernière si vous tenez à le faire tourner sur votre serveur.
Fetchmail a pour but de récupérer du courrier se trouvant dans une boîte à lettre chez votre FAI ou sur quelqu'autre compte vous appartenant, pour le transmettre au procmail qui tourne sur votre serveur lequel le placera dans votre boîte aux lettres locale.
Il peut traiter un grand nombre de serveurs de courrier, notamment POP3 et IMAP, mais pas Exchange.
Bien qu'il puisse être configuré pour s'acquitter d'une grande
variété de tâches, nous nous limiterons ici à des choses simples. Pour
chaque utilisateur disposant d'un compte email sur Internet, créez un
fichier ~/.fetchmailrc. Sur notre serveur, pour
jpollman, le fichier /home/jpollman/.fetchmailrc
ressemble à ceci :
poll www.deniz.com with proto POP3
user "jpollman" there with password "mypassword" is jpollman here
Expliquons-en chaque partie :
poll www.deniz.com : contacter www.deniz.com qui est
le serveur pop3 de mon FAI.
with proto POP3 : utiliser le protocole pop3 pour récupérer le courrier.
user "jpollman" there : mon nom de login courrier électronique chez mon FAI.
with password "mypassword" : Mon mot de passe chez mon FAI.
is jpollman here : jpollman est le nom
d'utilisateur sur notre serveur domestique.
Placez un fichier .fetchmailrc dans le répertoire d'accueil
de chaque utilisateur qui doit recevoir du courrier depuis
Internet. NB : chaque .fetchmailrc sera légèrement
différent car chacun a une adresse différente sur Internet.
fetchmail est très pointilleux quant aux droits d'accès et de
propriété, ce qui est une bonne chose, attendu que les mots de passe
de comptes doivent rester confidentiels. Pour s'assurer que le
.fetchmailrc est correct, utilisez l'exemple précédent pour
jpollman :
chown jpollman /home/jpollman/.fetchmailrc [Entrée]
chmod 700 /home/jpollman/.fetchmailrc [Entrée]
Si un utilisateur dispose de plusieurs comptes sur Internet,
contentez-vous d'ajouter le bloc de lignes commençant par
poll.
Nous aurions pu faire en sorte que fetchmail tourne en tant
que démon et qu'il interroge le FAI de temps en temps, mais cela
provoquerait un appel par le modem de diald lorsqu'on n'est
pas connecté. Au lieu de cela, nous avons un simple script, que
j'appelle getmail, et qui est invoqué à la fois par
cron et par
ip-up.local - voir ci-dessous pour des exemples. Le
voici :
#!/bin/sh
if [ -f /var/lock/LCK..ttyS3 ]; then
su jpollman -c fetchmail
su bmote -c fetchmail
fi
Quand il tourne, il commence par vérifier si nous sommes en ligne
(diald place un fichier appelé LCK..ttyS3 dans mon
répertoire /var/lock lors d'une connexion, et le retire quand
il se déconnecte). NB : vous pouvez avoir configuré diald
d'une façon différente, utiliser un démon pppd ou un autre port série,
par conséquent, le fichier de verrouillage peut porter un autre nom.
En l'absence de ce dernier, ce script se termine aussitôt. En présence
d'une connexion, il se sert de su pour devenir
jpollman et exécuter fetchmail. Le -c
signifie : exécuter la commande qui suit. Une fois le courrier de
jpollman récupéré, le script prend l'identité de
bmote via su et lance fetchmail pour
rapatrier son courrier. NB : jpollman et bmote
sont des noms d'utilisateurs sur notre serveur, pas ceux des comptes
email chez le FAI.
Cron : voici un didacticiel très rapide et succint sur
cron. Crond est le démon qui est lancé au démarrage
de votre machine, et qui, de ce fait, tourne en permanence en tâche de
fond. Il lit les fichiers crontab chaque minute pour voir si
quelque chose doit être lancé. Vous devez créer une crontab
pour l'utilisateur "root". Pour ce faire, en tant que root,
tapez :
crontab crontab [Entrée]
crontab, qui est identique à
celle du système. Pour l'éditer, tapez :
crontab -e [Entrée]
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin HOME=/ MAILTO="root"
0 1 * * * getmail
Les champs heure et date sont~: champ valeurs permises ----- ---------------- minutes 0-59 heures 0-23 quantième 0-31 mois 0-12 (ou les noms, voir plus bas) jour de la semaine 0-7 (0 ou 7 pour Sun (Dim), ou alors utilisez les noms)
Par conséquent, dans l'exemple ci-dessus, (0 1 * * * getmail)
getmail sera lancé à 1 heure du matin tous les jours. Je
préfèrerais qu'il démarre toutes les 5 minutes, donc, mon entrée de
crontab aura cette allure :
0-59/12 * * * * /usr/local/bin/getmail
crontab, tapez :
man 5 crontab [Entrée]
ip-up.local : pour que le script soit lancé à chaque
connexion, ajoutez-le dans votre fichier /etc/ppp/ip-up.local
(ou à ip-up si c'est ce que vous avez). Pour ce faire, il
suffit de le saisir comme une simple ligne avec un chemin absolu. Le
mien ressemble à ceci :
/usr/local/bin/getmail
Où donc sendmail met-il le courrier au départ ? Dans le
répertoire /var/spool/mqueue. Tous les messages sont stockés
sous la forme de deux fichiers, l'un nommé dfXXXnnnnn,
l'autre qfXXXnnnnn, où XXX est une suite de trois lettres et
nnnnn une séquence de 5 chiffres. Ils servent à donner à chaque
message une identification unique. Le "qf", ou fichier de contrôle de
file (queue control file), contient l'en-tête de l'email
ainsi que diverses données de traitement, et le "df", ou fichier de
données (data file), le corps du message. Il y a d'autres
fichiers, mais qui ne concernent que sendmail.
En particulier, allez voir le fichier /var/log/maillog. Sa
lecture est assez ardue, mais c'est votre seule chance de trouver la
cause d'une erreur.
Quelques-uns d'entre vous peuvent se loguer sur leur machine locale avec un nom différent de celui utilisé avec le FAI. Bien évidemment, fetchmail prendra et mettra votre courrier à l'endroit qui convient, mais sendmail, lui, nécessite un coup de pouce supplémentaire. Voyez le Howto Sendmail-Address_Rewrite. Si vous avez pu suivre cet article jusqu'ici, ce document est assez simple.
Ne vous découragez pas si cela ne marche pas du premier coup ! J'utilise sendmail depuis 4 ans, avec plus ou moins de succès. C'est un gros bestiau qui a bien évolué au cours du temps. Dans la mesure où la grande majorité du courrier sur Internet transite par sendmail à un moment ou à un autre, cela vaut la peine de le faire tourner sur votre machine.
Pour conclure : Nous vous avons donné une recette de cuisine pour mettre en place un système de courrier électronique domestique simple. Comme le succès est source d'intérêt, voici quelques sites où vous pourrez en apprendre davantage :
Copyright 1999, JC Pollman et Bill Mote. Publié dans le numéro 45 de la Linux Gazette, septembre 1999.
Traduction française de Joël Sagnes.