Le système qmail peut posséder une liste d'alias compilée au format CDB stockée dans le fichier /var/qmail/users/cdb et dont la version ASCII est stockée dans le fichier /var/qmail/users/assign. La commande qmail-newu permet de transformer la version ASCII en version compilée CDB. Cette dernière est lue par qmail-lspawn avant l'appel à qmail-local. La version ASCII ressemble à un fichier passwd. Voir la page de manuel qmail-users pour une description de son format. La commande qmail-pw2u permet d'ailleurs de fabriquer la base de données /var/qmail/users/assign à partir de votre fichier /etc/passwd : root$ qmail-pw2u < /etc/passwd > /var/qmail/users/assign root$ qmail-newu Le fichier d'alias compilé est lu par qmail-lspawn. Ce dernier s'en sert pour déterminer l'utilisateur qui recevra la livraison d'un courriel par qmail-local en mode utilisateur. qmail-local se charge de la lecture et de l'interprétation des fichiers .qmail*. Il faut bien comprendre que la liste d'alias est lue par qmail-lspawn alors que les .qmail* sont lus par qmail-local. Les deux mécanismes ne sont pas mutuellement exclusifs mais successifs. L'un opère en UID 0 et l'autre en mode utilisateur. Considérons par exemple un courriel à destination locale sortant de la file d'attente. Il est transmis à qmail-lspawn par son père le daemon qmail-send. qmail-lspawn, qui opère en UID 0, détermine en lisant le fichier d'alias compilé le login login, l'UID uid, le GID gid et le fichier ~login/.qmail* en vertu desquels il faut faire la livraison par qmail-send. qmail-send est donc executé en UID uid et effectue la livraison conformément au fichier ~login/.qmail* et aux règles expliquées dans . qmail-send \_ qmail-lspawn UID 0 \_ qmail-local UID uid Voici un exemple de fichier /var/qmail/users/assign : =root:alias:70:65534:/var/qmail/alias:-:postmaster: =abuse:alias:70:65534:/var/qmail/alias:-:postmaster: =operator:alias:70:65534:/var/qmail/alias:-:postmaster: =uucp:alias:70:65534:/var/qmail/alias:-:postmaster: =anonymous:alias:70:65534:/var/qmail/alias:-:postmaster: =hostmaster:alias:70:65534:/var/qmail/alias:-:postmaster: =mailer-daemon:alias:70:65534:/var/qmail/alias:-:postmaster: =manager:alias:70:65534:/var/qmail/alias:-:postmaster: =warnings:alias:70:65534:/var/qmail/alias:-:postmaster: =webmaster:alias:70:65534:/var/qmail/alias:-:postmaster: =ftpmaster:alias:70:65534:/var/qmail/alias:-:postmaster: =FaxMaster:alias:70:65534:/var/qmail/alias:-:postmaster: +djalil:djay:1000:1000:/home/djay::: . Chaque ligne correspond à une directive de livraison. Voir la page de manuel qmail-users pour une description des champs. Les alias habituels sont tous redirigés vers alias-postmaster, à charge du .qmail-postmaster de router les messages vers un autre utilisateur. Le fichier doit toujours se terminer par une ligne ne contenant qu'un point. La dernière ligne demande à qmail-lspawn de livrer tout courriel à destination d'une adresse commençant par djalil vers djay. La commande qmail-getpw permet d'obtenir la ligne du fichier d'alias correspondant à l'adresse courriel qu'on lui passe en argument. Lisez pour commencer sur le fichier de contrôle rcpthosts. On associe souvent le contrôle de relayage par rcpthosts à un contrôle de connexion TCP par un «wrapper» TCP. Le cas typique est l'utilisation de tcpd via inetd pour lancer qmail-smtpd. Le contrôle TCP est alors effectué par les fichiers /etc/hosts.allow et /etc/hosts.deny. Voici par exemple ce que l'on peut mettre dans /etc/inetd.conf : smtp stream tcp nowait.200 qmaild /usr/sbin/tcpd smtp et dans /etc/hosts.allow : smtp: .mondomaine.amoi 127.0.0.1: \ setenv RELAYCLIENT:\ twist { { /usr/bin/tcp-env /usr/sbin/qmail-smtpd 1>&3;} \ 2>&1|splogger qmail;} 3>&1 smtp: ALL: \ twist { { /usr/bin/tcp-env /usr/sbin/qmail-smtpd 1>&3;} \ 2>&1|splogger qmail;} 3>&1 Ainsi, le contrôle de relayage par rcpthosts ne sera actif que pour les courriels provenants de connexions SMTP avec des machines extérieures au domaine mondomaine.amoi. Bien sûr, il ne faudra pas oublier de faire un root:bash$ kill -HUP $(pidof inetd) pour que inetd relise son fichier de configuration. Voir les pages de manuel inetd.conf(5), tcpd(8), hosts_access(5) et hosts_options(5). Lorsque la machine n'est connectée à l'Internet que de façon intermittante en PPP par modem par exemple, les courriels à destination de l'extérieur restent dans la file d'attente de qmail jusqu'à la prochaine connexion. Il est alors utile d'envoyer un signal ALRM à qmail-send à l'établissement de la lisaison IP (par exemple dans le script /etc/ppp/ip-up.local ou équivalent) pour qu'il traite les courriels présents dans la file d'attente immédiatement. J'en profite au passage pour signaler que sur la Debian GNU/Linux, les fichiers /etc/ppp/ip-up.local et /etc/ppp/ip-down.local de PPP sont remplacés par des répertoires /etc/ppp/ip-up.d/ et /etc/ppp/ip-down.d/ destinés à accueillir des scripts lancés automatiquement par run-parts respectivement à l'établissement et à la chute de la lisaison IP via PPP). Cette méthode a cependant un inconvénient. Supposons qu'aucune connexion n'est lieu pendant une période assez longue, les courriels en question seront alors tout bètement renvoyés à l'expéditeur, c'est un mécanisme présent dans toute gestion de file d'attente. La variable qmail queuelifetime represéente la durée de vie en seconde d'un courriel dans la file d'attente. Elle vaut par défaut 604800 secondes, soit une semaine. Une solution élégante à ce problème consiste à faire en sorte que tous les courriels devant transiter par PPP soit livrés dans une boite aux lettres spécialement prévue à cet effet. Il suffira ensuite dès l'établissement de la liaison IP par PPP de vider cette BAL sur le port SMTP de la passerelle courriel de notre FAI. Ce n'est pas sans rappeler le mecanisme «store-and-forward» d'UUCP. On peut éditer cette BAL avec n'importe quel MUA, ce qui est tout de même mieux que de toucher à la file d'attente de qmail. Nous créons donc une BAL nommée ~alias/ppp par : root$ maildirmake ~alias/pppdir root$ chown -R alias ~alias/pppdir Il nous faut ensuite créer le fichier ~alias/.qmail-ppp-default qui doit contenir la ligne ./pppdir/ Enfin il faut ajouter une ligne à la fin du fichier /var/qmail/control/virtualdomains : mondomaine.amoi: .mondomaine.amoi: :alias-ppp ainsi, la livraison vers notre BAL se fera pour les courriels à destination des adresses extérieures au domaine mondomaine.amoi. Voir la . Reste maintenant à trouver un moyen pour vider cette BAL sur le port 25 de notre FAI. C'est là qu'intervient serialmail, que l'on trouve sur http://pobox.com/~djb/serialmail.html. serialmail existe aussi sous forme de paquetage source Debian, je recommande fortement cette méthode à ceux qui possèdent une Debian GNU/Linux. serialmail est un ensemble de petits programmes écrits par Dan Bernstein dont maildirsmtp qui permet justement de vider une BAL au format maildir sur un port SMTP. maildirsmtp fait appel à tcpclient lui même faisant partie de UCSPI-TCP (voir http://pobox.com/~djb/ucspi-tcp.html). Un paquetage source Debian GNU/Linux est disponible. Voici ce qu'il faut rajouter dans votre script /etc/ppp/ip-up.local ou équivalent : maildirsmtp ~alias/pppdir \ alias-ppp- mail.monfai.amoi \ mamachine.mondomaine.amoi 2>> /var/log/maildir2smtp.log où mail.monfai.amoi désigne la passerelle courriel de votre FAI. La principale critique que l'on pourrait porter à ce système est que serialmail vide les messages sur le port SMTP séquentiellement. Le moindre bloquage empêche le traitement du reste de la BAL. Avant de terminer cette section, je vous rappelle que le fichier de contrôle /var/qmail/control/smtproutes permet de spécifier à qmail-remote les relais de courriels à contacter (cf. la page de manuel). L'idéal pour une machine isolée, connectée de façon intermittante à l'Internet par PPP, est de demander à qmail-remote de transmettre tout les courriels sortants à la passerelle de courriel du FAI (un «smarthost» pour parler le langage de sendmail). Cela évite à qmail-remote de contacter lui même les machines destinataires et de faire des requettes DNS. La ligne PPP est donc moins sollicitée. On peut par exemple mettre ceci dans le fichier smtproutes : :mail.monfai.amoi Voir la . Pour récupérer votre courriel sur le port POP3 de votre FAI, je vous conseille d'utiliser l'exellent fetchmail. Voici un exemple de ~/.fetchmailrc possible : poll mail.monfai.amoi protocol pop3: username monpseudo password monsesame fetchall batchlimit 1 # utile si le FAI utilise qmail is loginlocal here mda "env -u QMAILINJECT qmail-inject -f%F %T" fetchmail fera donc appel à qmail-inject pour insérer les courriels dans la file d'attente de votre qmail. qmail se chargera ensuite de livrer le courriel dans votre BAL via le MDA qmail-local. Vous pouvez aussi décider d'utiliser plutôt votre propre port SMTP pour l'insertion dans la file d'attente de votre qmail. Voici le ~/.fetchmailrc correspondant : poll mail.monfai.amoi protocol pop3: username monpseudo password monsesame fetchall batchlimit 1 # utile si le FAI utilise qmail forcecr # RFC 822 strict is loginlocal here En fait, l'insertion dans la file d'attente de votre qmail ne sert pas à grand chose. Autant faire appel directement à un MDA qui va directement livrer le courriel dans votre BAL. Le plus simple est par exemple d'utiliser procmail. On courcircuite qmail car il ne sert à rien ici ! Voici le ~/.fetchmailrc correspondant : poll mail.monfai.amoi protocol pop3: username monpseudo password monsesame fetchall batchlimit 1 # utile si le FAI utilise qmail is loginlocal here mda "procmail -d loginlocal" Si vous désirez modifier votre identité apparente dans les courriels que vous envoyez, il vous suffit d'utiliser les variables d'environnement QMAILHOST, QMAILUSER et QMAILNAME. Ces variables sont prises en considération par qmail-inject lors de l'injection de vos courriels dans la queue (cf. la page de manuel). Les champs From: et Return-Path: de vos courriels sont alors modifiés automatiquement. Celà s'avère très pratique lorsque votre machine n'est pas en permanence sur l'Internet et ne s'y connecte que de façon intermittante via une adresse IP dynamique. On peut contrôler les modifications qu'apporte qmail-inject aux entêtes en utilisant la variable d'environnement QMAILINJECT. Voir la page de manuel de qmail-inject pour les détails. Voici par exemple ce que j'ai rajouté à mon fichier .bashrc : export QMAILHOST="mail.dotcom.fr" export QMAILUSER="dchafai" export QMAILNAME="Djalil Chafai" export QMAILINJECT=f Ainsi, les messages que j'envoie apparaissent comme provenant de dchafai@mail.dotcom.fr (Djalil Chafai). Cette solution est interressante car elle marche avec tous les MUA faisant appel au wrapper sendmail de qmail, lui même appelant qmail-inject. De plus, cela permet de se débarrasser des problèmes de paranoïa des passerelles de courriels de certains FAI. En fait, pour déterminer le nom d'utilisateur, qmail-inject utilise les variables d'environnement suivantes par ordre décroissant de préférence : QMAILUSER, MAILUSER, USER et LOGNAME. Pour le nom de machine, qmail-inject utilise la variable qmail defaulthost. Elle peut être cependant forcée par les variables d'environnement QMAILHOST et MAILHOST. Le nom personnel est quant à lui donné par les variables d'environnement QMAILNAME, MAILNAME et NAME. L'idée est un peu la même que celle utilisée pour le PPP. Elle consiste à mettre une ligne dans virtualdomains (voir la ) .uucp:alias-uucp qui routera les courriels devant transiter par UUCP vers alias-uucp. Le fichier ~alias/.qmail-uucp-default devra alors contenir un tube appelant le binaire qui injecte le courriel dans le spool UUCP (uux par exemple). |preline -df /usr/bin/uux - -r -a "$SENDER" relaisuucp!rmail "($EXT2@$HOST)" Voir les pages de manuel de preline, qmail-local et qmail-command pour les détails. Ainsi tout courriel à destination de nom@machine.uucp sera envoyé par UUCP au relais relaisuucp. ezmlm est un gestionnaire de listes de diffusions écrit pas Dan Berstein spécialement étudié pour qmail. ezmlm est beaucoup plus sophistiqué que le gestionnaire de listes minimal qlist que contient qmail nativement. Le site http://www.ezmlm.org/ est dédié à ezmlm. qmailanalog est un ensemble de scripts awk écrits par Dan Bernstein qui fabriquent des statistiques sur le courriel en analysant les fichiers d'audit (logs) de qmail. En général, qmailanalog est lancé par une crontab hébdomadaire ou mensuelle. Vous trouverez un pointeur sur qmailanalog dans sur site de qmail. Dan Bernstein compte réécrire tout ou partie des scripts awk en langage C. Les prochaines versions de qmailanalog seront donc plus performantes.