| Introduction à qmail | ||
|---|---|---|
| Précédent | Chapitre 5. Configuration : pour aller plus loin | Suivant |
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 |
./pppdir/ |
mondomaine.amoi: .mondomaine.amoi: :alias-ppp |
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 |
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 |
| Précédent | Page principale | Suivant |
| Contrôle de relayage | Niveau précédent | Fetchmail |