Lorsqu'on a l'habitude d'utiliser sendmail, la multiplicité des files
d'attente de postfix a tendance à dérouter. En effet, en lieu et place du
classique et unique /var/spool/mailq/, on se retrouve avec
l'arborescence suivante :
alex:~# tree /var/spool/postfix/
/var/spool/postfix/
|-- active
...
|-- deferred
| |-- 048ED779D1
| |-- 09085779E0
| |-- 17101779D6
| |-- 31DE0779DA
| |-- 3D15D779D4
| |-- 4D2BD779D7
| |-- 7BFA6779D3
| |-- 7C65D779CF
| |-- B10C3779D0
| `-- C3272779D2
...
|-- incoming
...
|-- maildrop
...
Nous avons abrégé la sortie de cette commande pour ne retenir que les répertoires qui nous intéressent ici.
Postfix utilise quatre files d'attentes :
maildrop contient les messages locaux ;
incoming contient les messages qui ont été prélevés dans
maildrop par le démon pickup, puis qui ont été traités par le démon
cleanup. Cette file contient aussi les messages venant de l'extérieur. En
bref, elle contient les messages qui n'ont pas encore été traités par le
gestionnaire de file d'attente qmgr ;
active est une file contenant les messages en cours de délivrance
par qmgr ;
deferred contient les messages qui n'ont pas pu être délivrés (il y
en a 10 dans notre exemple).La documentation de la distribution postfix dispose d'un schéma présentant
clairement les interactions entre les différentes files d'attente et les
différents démons.
Le contenu de la file d'attente peut être consulté avec la commande
mailq : normalement celle-ci ne doit produire que les messages dont
la délivrance n'a pas encore eu lieu (dans notre cas, les 10 messages contenus
dans la file deferred.
postfixNous avons déjà vu que postfix s'invoquait en lui passant une commande qui
précisait l'action à entreprendre. Ainsi, les commandes stop et start
arrêtent et démarrent le serveur, respectivement. D'autres commandes
existent :
reload force postfix à relire ses fichiers de
configuration : cette commande s'avère donc nécessaire après la
modification du fichier /etc/postfix/main.cf, par exemple ;
check permet de vérifier la configuration du système de
courrier. Cette commande permet aussi de surveiller les différentes permissions
des répertoires utilisés par postfix, et de créer ces répertoires s'ils
n'existent pas. Si la configuration est correcte, et si l'option -v n'a
pas été utilisée, cette commande ne produit aucune sortie ;
flush force postfix à tenter de vider la file deferred,
donc à envoyer les messages en attente de délivrance.Enfin, last but not least, la distribution postfix fournit le
programme /usr/sbin/postconf pour afficher les paramètres modifiés par
notre configuration (postconf -n), les valeurs par défaut du logiciel
(postconf -d) et l'ensemble des valeurs courantes des paramètres
(postconf. Voici, à titre d'exemple, ce que donne la première commande sur
ma configuration personnelle :
alex:/etc/postfix# /usr/lib/postfix/postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_at_myorigin = yes
default_destination_concurrency_limit = 10
default_transport = smtp
defer_transports = smtp
local_destination_concurrency_limit = 2
mail_owner = postfix
mailbox_command = /usr/bin/procmail
masquerade_domains = $mydomain
mydestination = $myhostname, localhost
mydomain = linux-france.com
myhostname = alex.linux-france.com
mynetworks = 192.168.2.0/24, 127.0.0.0/8
myorigin = $myhostname
program_directory = /usr/lib/postfix
queue_directory = /var/spool/postfix
relayhost = [smtp.dial.oleane.com]
Nous n'avons pas encore vu certains de ces paramètres ? C'est normal. Nous allons maintenant nous en occuper...
Bien, nous savons maintenant que postfix fonctionne correctement avec les
adresses locales à notre machine (si ce n'est pas le cas, n'allez pas plus loin
et revenez nous voir lorsque le problème sera réglé...). Allons maintenant à la
conquête du monde.
La meilleure chose à faire, tant que tous nos tests n'ont pas donné satisfaction, est d'utiliser un « écho » : ie une adresse où nous pourrons envoyer un courrier qui nous sera retourné tel qu'il a été reçu. Ceci nous permettra de vérifier au moins deux choses :
Une telle adresse est echo@cnam.fr et c'est celle que nous utiliserons
ici.
Tout le courrier sortant de notre machine est d'abord envoyé au serveur de
courrier de notre fournisseur d'accès qui se chargera ensuite de l'envoyer sur
l'Internet. Dans la terminologie classique, cela s'appelle un hôte relais
(ou relayhost) en anglais. Il faut donc indiquer à postfix le nom de
cet hôte relais. Si l'on suppose que nous sommes abonné au fournisseur d'accès
bien connu fai.fr et que la machine s'occupant du courrier s'appelle
mail.fai.fr, il faut modifier le fichier /etc/postfix/main.cf,
rechercher les lignes contenant relayhost et mettre :
relayhost = [mail.fai.fr]
Puis, comme à chaque modification de ce fichier, il faut faire postfix
reload.
Essayons maintenant la commande suivante :
$ mail echo@cnam.fr -s test
essai d'envoi de courrier via postfix
.
Cc:
$
Puis, examinons la file d'attente :
$ mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
9C26D779D0 351 Wed Jan 20 21:23:55 babe@alex.linux-france.com
(Name service error for domain mail.fai.fr: Host not found, try again)
N'étant relié à l'Internet qu'épisodiquement, via une connexion PPP à un
fournisseur d'accès (F.A.I.), le domaine cnam.fr ne pourra être connu que
lorsque nous sommes connectés, par consultation du serveur de noms de notre
F.A.I. Ce n'était pas le cas ici, et ce ne le sera pas souvent : pour
économiser sur la facture téléphonique, on a tout intérêt à composer son
courrier en étant déconnecté et à tout poster d'un seul coup lors de la
prochaine connexion.
postfix nous prévient de cet état de fait grâce au message Name
service error for domain cnam.fr de la commande mailq. Lors de notre
prochaine connexion, il suffira simplement d'appeler la commande postfix
flush (ou sendmail -q pour les nostalgiques...) pour que le courrier en
attente soit à nouveau délivré. Attention : sur ma machine, par exemple, seul
root a le droit de faire postfix flush, un utilisateur normal devra
utiliser /usr/sbin/sendmail -q pour envoyer les messages.
Lorsqu'on est, comme moi, connecté épisodiquement, le mieux est d'indiquer à
postfix de déférer la délivrance des courriers. Ceux-ci seront alors
placés dans la file d'attente et postfix ne tentera plus de les envoyer
sauf si on le lui demande explicitement via un sendmail -q. Ce type de
fonctionnement est tout à fait adapté aux connexions épisodiques (on peut
mettre le sendmail -q dans un script post-connexion) et est piloté par le
paramètre defer_transports :
defer_transports = smtp
En attendant de nous connecter, on peut encore vérifier certains
points. postfix laisse des traces de ses activités dans les fichiers
/var/log/mail.*. Les erreurs sont rapportées dans mail.err, les
simples avertissements le sont dans mail.warn, toutes les activités de
délivrance des courriers sont inscrites dans mail.info et mail.log
est un fichier fourre-tout reprenant le contenu des trois précédents.
Analysons tour à tour les trois premiers fichiers :
postfix flush à partir du
compte babe... la commande nous indique qu'il faut être root pour
l'exécuter. Cette information est reprise dans mail.err :
alex:/var/log# tail -1 mail.err
Jan 20 21:48:05 alex postfix[1081]: fatal: must be run by the superuser,\
not by userid 1000
mail.warn, mail.info et mail.log reprennent cette
information.
mail.info pour voir ce qu'il raconte au sujet
de notre courrier en attente de délivrance :
alex:/var/log# grep 9C26D779D0 mail.info
Jan 20 21:23:55 alex postfix/pickup[424]: 9C26D779D0: uid=1000
Jan 20 21:23:55 alex postfix/cleanup[1056]: 9C26D779D0: \
message-id=<19990120202355.9C26D779D0@alex.linux-france.com>
Jan 20 21:23:55 alex postfix/qmgr[157]: 9C26D779D0: \
from=<babe@alex.linux-france.com>, size=351 (queue active)
Jan 20 21:23:55 alex postfix/smtp[1058]: 9C26D779D0: \
to=<echo@cnam.fr>, relay=none, delay=0, \
status=deferred (Name service error for domain cnam.fr: \
Host not found, try again)
mailq nous donne ces 4 lignes qui nous renseignent sur le
cheminement de notre message : il a d'abord été récupéré par pickup,
qui lui a donné un message-id, puis par cleanup (via
trivial-rewrite ) qui a rempli le champ from. qmgr l'a transmis
au service de transport smtp qui n'a pu résoudre l'adresse de destination
et l'a donc placé en attente, dans la file deferred. On notera ici les
informations qui nous intéressent : le contenu des adresses de
l'expéditeur et du destinataire qui apparaissent être correctes.Le dernier message ici aurait été produit si nous n'avions pas utilisé le
paramètre defer_transports évoqué plus haut. Si nous l'avions fait, le
message aurait été :
Jan 20 21:23:55 alex postfix/smtp[1058]: 9C26D779D0: \
to=<echo@cnam.fr>, relay=none, delay=0, \
status=deferred (deferred transport)
Nous pouvons aussi aller directement inspecter le contenu des files d'attente
de postfix avec la commande tree utilisée plus haut. Vous noterez
alors que le numéro 9C26D779D0 apparaît en deux endroits :
/defer/9/C/ : si vous regardez le
contenu de ce fichier, vous noterez qu'il contient simplement le message
indiquant le problème de résolution de l'adresse de destination.deferred : l'édition du contenu du fichier
vous permettra de constater que toutes les informations y sont, mais formatées
d'une façon peu lisible...