Les adresses électroniques utilisées dans cette organisation correspondent aux comptes des utilisateurs de la machine UNIX mail.dom.com. Ces adresses sont les suivantes :
postmaster@mail.dom.com
jc.charles@mail.dom.com
a.pierre@mail.dom.com

Au vue de l’organisation du système de messagerie, on suppose que la machine dispose d’un serveur POP pour les clients du réseau local 192.168.1.0/24.
Pour une telle configuration, nous avons besoin des fichiers suivants dans /etc/mail :
· sendmail.mc
· sendmail.st, créé grâce à # touch sendmail.st
· aliases
· access
· local-host-names ou sendmail.cw

Le fichier sendmail.mc sert à construire le fichier de configuration de Sendmail. Il comporte les éléments suivants :
divert(-1)
dnl
dnl Configuration élémentaire SMTP
dnl
dnl
divert(0)
include(`/usr/share/sendmail-cf/m4/cf.m4′)dnl
VERSIONID(`Sendmail pour mail.dom.com’)dnl
OSTYPE(`linux’)dnl
define(`confMAX_MESSAGE_SIZE’, `5000000′)dnl
define(`STATUS_FILE’, `/etc/mail/sendmail.st’)dnl
define(`confDOMAIN_NAME’, `mail.dom.com’)dnl
define(`ALIAS_FILE’, `/etc/mail/aliases’)dnl
FEATURE(use_cw_file)dnl
FEATURE(`access_db’,`hash -o /etc/mail/access’)dnl
FEATURE(always_add_domain)dnl
FEATURE(local_procmail)dnl
MAILER(smtp)dnl

Note : A partir de la version 8.12, vous devez utiliser la syntaxe suivante pour le dispositif access :
FEATURE(`access_db’,`hash -T -o /etc/mail/access.db’)dnl

A partir du fichier sendmail.mc, vous construisez la configuration de Sendmail comme suit :
# cd /etc/mail
# m4 sendmail.mc >sendmail.cf

L’ordre des instructions M4 a son importance. Terminez toujours par l’instruction MAILER. Le divert(-1) ignore toutes les lignes qui le suivent, tandis que le divert(0) rétablit le flux standard des sorties. L’instruction include inclut les macros utilisatrices M4 nécessaires au fonctionnement élémentaire de Sendmail.VERSIONID définit un texte d’identification, et OSTYPE précise Linux comme système d’exploitation du serveur. La valeur confMAX_MESSAGE_SIZE est mise à 5 millions. Elle définit la taille maximale des messages transitant sur le relais. Cette valeur est exprimée en octets. Il s’agit de la taille globale des messages, en-têtes et enveloppes MIME incluses. N’espérez donc pas transporter une pièce jointe d’une taille de 5 Mo, et coontentez-vous d’un peu plus de 4 Mo pour la capacité maximale d’une pièce jointe.STATUS_FILE précise l’emplacement du fichier des statistiques de courrier. Ce fichier est utilisable via la commande mailstats. La variable confDOMAIN_NAME définit le nom du serveur. Elle n’est normalement utilisée que lorsque la machine ne sait pas résoudre son propre nom d’hôte. Nous ne l’indiquons que par précaution.

ALIAS_FILE indique l’emplacement du fichier des aliases. Comme vous trouverez souvent ce fichier dans /etc/, il est préférable de le mettre dans /etc/mail de façon à tout regrouper dans le même répertoire. L’instruction use_cw_file précise qu’il faut utiliser le fichier local-host-names pour référencer les nom de domaines locaux.

Le dispositif access_db incorpore les autorisations de relayage à la configuration de Sendmail. Cette base comprend les machines et réseaux autorisés à utiliser le serveur SMTP. Il est donc nécessaire de construire une base de données access.db à partir d.un fichier texte access. Des explications détaillées à ce sujet sont fournies plus loin dans ce chapitre. L’instruction always_add_domain ajoute le nom du domaine à une adresse, même si celle-ci est livrée localement. Cela se révèle particulièrement pratique pour le courrier généré directement depuis le serveur. FEATURE(local_procmail) demande l’utilisation de procmail comme agent de livraison local, qui est normalement la configuration par défaut.

MAILER(smtp) indique que vous utilisez le gestionnaire de courrier SMTP. Cette commande doit être la dernière du fichier mc car elle contient des instructions qui remplacent le contenu de certaines des commandes précédentes.

Le fichier aliases sert à faire la correspondance entre les adresses électroniques et le compte UNIX. Il contient les éléments suivants :
postmaster: root
MAILER-DAEMON: root
postmaster@mail.dom.com: root
jc.charles@mail.dom.com: charles
a.pierre@mail.dom.com: pierre
tous: root,charles,pierre

La base aliases.db est construite grâce à /usr/sbin/sendmail -bi -v ou la commande newaliases. A partir du moment où un utilisateur dispose d’un compte sur la machine, il dispose d’une adresse électronique de la forme login@fqdn. Par exemple, root@mail.dom.com.

Il est intéressant de créer des aliases, ou synonymes, pour des raisons de clarté ou de simplicité. Les messages système sont toujours redirigés vers le compte superutilisateur root. L’utilisateur charles dispose de deux adresses e-mail, charles@mail.dom.com, correspondant à sa boîte aux lettres physique, et son synonyme jc.charles@mail.dom.com, plus précis. L’utilisateur pierre obéit au même schéma.

Finalement, l’alias tous pointe vers tous les comptes utilisateur du serveur. Cela simplifie grandement l’envoi groupé. Un message envoyé à tous@mail.dom.com est reçu par l’ensemble des utilisateurs du serveur.

Le fichier local-host-names définit le domaine de messagerie local, ici mail.dom.com. L’entrée ci-dessous est insérée dans le fichier local-host-names :
mail.dom.com

Les messages à destination de ce domaine sont délivrés localement via l’agent de livraison procmail. Pour utiliser ce fichier, il faut disposer de l’instruction FEATURE(use_cw_file) dans le fichier mc.
Si vous souhaitez gérer la totalité du domaine dom.com, il vous suffit d’ajouter l’entrée suivante dans local-host-names :
dom.com

Lorsque vous modifiez ce fichier, vous devez faire relire à Sendmail sa configuration :

# kill -HUP `head -1 /var/run/sendmail.pid`

Les anciennes versions de Sendmail utilisent à la place de local-host-names le nom de fichier suivant : sendmail.cw

Pour des raisons de compatibilité, il est parfois utile de conserver ce nom. Il suffit pour cela d’insérer l’instruction suivante dans le fichier mc :
define(`confCW_FILE’,`/etc/mail/sendmail.cw’)dnl

N’oubliez pas de reconstruire le fichier sendmail.cf après modification du fichier mc ni de faire relire à Sendmail sa configuration.

Le fichier access contient la liste des machines et réseaux autorisés à utiliser le serveur SMTP comme relais. Les entrées ci-dessous sont insérées dans ce fichier :
127.0.0.1 RELAY
192.168.1 RELAY
localhost RELAY
localhost.localdomain RELAY

Ce fichier permet de construire la base à accès calculé access.db :
# makemap -v hash access.db <access

Dans le fichier access, vous trouvez la machine locale sous ses trois formes : l’adresse IP, le nom d’hôte et le FQDN (Fully Qualified Domain Name). La plupart du temps, il est recommandé d’autoriser la machine locale à utiliser le serveur SMTP.

A côté traînaient deux autres ouvrages dont j’ai oublié le nom mais comme d’habitude, rien en français. C’est sur ce constat que j’ai commencé à jeter les bases de mon livre ; un logiciel qui transporte plus de la moitié des emails sur Internet se devait d’avoir un minimum de documentation en français.

Il m’a fallu plus d’un an et demie pour y arriver, avec ces hauts et ces bas, ses interminables relectures avec mon éditeur, ces passages que personne ne comprenaient, la difficulté à y inculquer un peu de marketing, etc.

Une partie a été écrite dans le TGV entre Lyon et Paris, alors que je me rendais à ma réunion mensuelle des responsables techniques dans un des datacenters parisiens. Je ne remercierai jamais assez la SNCF pour cela :-)

Après des mois d’efforts, le livre est sorti en février 2003 à 2000 exemplaires. 3 ans plus tard, il continue de se vendre, certes modestement, mais finalement ce genre d’ouvrage étant réservé à un public de spécialistes, il ne connaîtra jamais un succès immense.

Ecrire un livre est une expérience fabuleuse, mais très difficile : il faut être tenace, se plier aux directives d’un éditeur et finalement, cela ne rapporte pas beaucoup d’argent ; mais peu importe, c’est un grand projet dans une vie, une fierté aussi pour ses proches et c’est amusant d’entendre quelqu’un vous dire qu’il vous a trouvé un homonyme sur Internet « qui a écrit un livre sur Sendmail. »

Voici ce fameux livre:

Remarque:
Les chemins et numéros de version peuvent varier d’un environnement à un autre.
Installez maintenant Sendmail au moyen de l’instruction « sh Build install » :
# sh Build install
Making all in:
/tmp/sendmail-8.13.7/libsmutil
Configuration: pfx=, os=Linux, rel=2.4.18-3, rbase=2, rroot=2.4, arch=i686, sfx=, variant=optimized
Making in ../obj.Linux.2.4.18-3.i686/libsmutil
make[1]: Entre dans le répertoire `/tmp/sendmail-8.13.7/obj.Linux.2.4.18-3.i686/libsmutil’
cc -O -I. -I../../sendmail -I../../include -DNOT_SENDMAIL -c -o debug.o debug.c

Les programmes sont installés. Il vous reste à construire une configuration minimale qui vous permettra de faire fonctionner Sendmail. Cette configuration se place dans le répertoire /etc/mail :
# mkdir /etc/mail

Des fichiers de configuration préconstruits sont fournis avec l’archive de Sendmail. Ils sont placés dans le répertoire /cf/cf. Prenez, par exemple, le fichier generic-linux.cf, puis placez-le dans le répertoire /etc/mail, et renommez-le sendmail.cf de façon qu’il soit interprété par Sendmail :
# cd cf/cf
# cp generic-linux.cf /etc/mail/
# cd /etc/mail
# mv generic-linux.cf sendmail.cf

Toujours dans le répertoire /etc/mail, créez un fichier aliases élémentaire :
mailer-daemon: postmaster
posmaster : root

Indexez ce fichier de la façon suivante :
# /usr/sbin/sendmail -bi -v

Créez la file d’attente dans laquelle seront déposés tous les messages de Sendmail :
# mkdir /var/spool/mqueue

Démarrez Sendmail comme suit :
# /usr/sbin/sendmail -bd -q15m

Sendmail est désormais prêt à fonctionner, avec un minimum de fonctionnalités.

Sendmail va tourner dans le sous-environnement que vous allez créer dans le répertoire /sendmail, et aucun autre répertoire ne sera visible à l’extérieur de ce dernier.
Il vous faut maintenant fournir les éléments vitaux au logiciel (bibliothèques, répertoires, fichiers, etc.). Vous devez pour cela créer des fichiers physiques, car les liens symboliques sont proscrits car ils ne peuvent sortir du répertoire prison /sendmail :
# cd /sendmail
# mkdir usr
# mkdir usr/sbin

Sendmail est enfermé dans sa prison, avec des droits restreints :
# cp /usr/sbin/sendmail /sendmail/usr/sbin
# chown 0:0 /sendmail/usr/sbin/sendmail
# chmod 500 /sendmail/usr/sbin/sendmail

Des applications, telles que les serveurs Web, utilisent divers raccourcis pour accéder à Sendmail. Vous devez donc créer ces raccourcis :
# mkdir /sendmail/lib # cd /sendmail/lib
# ln -s ../sbin/sendmail sendmail
# mkdir /sendmail/bin
# cd /sendmail/bin
# ln -s ../sbin/sendmail sendmail

Fournissez maintenant à Sendmail les programmes annexes dont il a besoin, en commençant par extraire les bibliothèques dynamiques qu’il utilise :
# ldd /sendmail/usr/sbin/sendmail
libdb.so.3 => /lib/libdb.so.3 (0×40016000)
libresolv.so.2 => /lib/libresolv.so.2 (0x4004f000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4005d000)
libnsl.so.1 => /lib/libnsl.so.1 (0×40060000)
libdl.so.2 => /lib/libdl.so.2 (0×40075000)
libc.so.6 => /lib/libc.so.6 (0×40078000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0×40000000)

Le résultat peut varier suivant les options de compilation et les versions des noyaux :
# cd /sendmail/lib
# cp /lib/libdb.so.3 .
# cp /lib/libresolv.so.2 .
# cp /lib/libcrypt.so.1 .
# cp /lib/libnsl.so.1 .
# cp /lib/libdl.so.2 .
# cp /lib/libc.so.6 .
# cp /lib/ld-linux.so.2 .

Créez la file d’attente :
# mkdir /sendmail/var
# mkdir /sendmail/var/spool
# mkdir /sendmail/var/spool/mqueue
# chmod 700 /sendmail/var/spool/mqueue

Créez le répertoire /var/run pour que Sendmail y place son numéro de processus (sendmail.pid) :
# mkdir /sendmail/var/run

# touch /sendmail/var/run/sendmail.pid

Ajoutez l’unité /dev/null, dont Sendmail a besoin en interne :
# mkdir /sendmail/dev
# mknod /sendmail/dev/null c 1 3
# chown 0:0 /sendmail/dev/null
# chmod 666 /sendmail/dev/null

La définition du noeud (c 1 3) n’est valable que sous Linux.
Pour écrire ses historiques, Sendmail communique avec syslog via un socket. Vous devez donc créer ce dernière dans l’environnement chroot :
# /usr/sbin/syslogd -m 0 -p /sendmail/dev/log

L’emplacement de syslogd peut différer d’un système à un autre. Prenez garde à n’avoir qu’une seule instance de syslogd dans le système.

A ce stade, vous devez régler le délicat problème de la résolution de noms. Sendmail ne peut fonctionner correctement sans cette résolution. Cette configuration s’effectue dans le répertoire /etc :
# mkdir /sendmail/etc

Créez le fichier d’aiguillage des services (etc/nsswitch.conf) de façon à renseigner l’emplacement des fichiers, indispensables à la résolution de noms. Le contenu du fichier /sendmail/etc/nsswitch.conf est le suivant :
services: files

La ligne services renseigne le fichier etc/services, lequel contient la corrélation entre un numéro de port TCP ou UDP et le nom usuel du service.
Pour utiliser ce dispositif, vous devez pouvoir accéder à la bibliothèque libnss_files-2.2.2.so :
# cd /sendmail/lib
# cp /lib/libnss_files-2.2.2.so .

Cette bibliothèque est généralement appelée via un autre nom, libnss_files.so.2 :
# ln -s libnss_files-2.2.2.so libnss_files.so.2

Voici la bibliothèque nécessaire à la résolution de noms (DNS) :
# cp /lib/libnss_dns.so.2 .
/
et le fichier /sendmail/etc/services :
smtp 25/tcp mail

Puisque le chroot concerne uniquement SMTP, seule cette ligne est nécessaire.
Voici enfin le fichier du client DNS etc/resolv.conf :
nameserver 127.0.0.1

Nous supposons ici que vous disposez d’un serveur DNS local (127.0.0.1). Il est recommandé de mettre celui de votre FAI, car cela simplifie grandement la configuration de votre serveur.
Pour le répertoire /etc/mail contenant les données de configuration, vous disposez d.une alternative :
· Placer les bases de données et le fichier de configuration dans /sendmail/etc/mail par le biais d’un petit script exécuté à chaque modification du paramétrage. De cette façon, vous isolez et sécurisez les fichiers source (alias, access, etc.) et le fichier mc dans l’environnement primaire.
· Créer un lien de /etc/mail vers /sendmail/etc/mail, exposant ainsi les fichiers source dans l’environnement chroot.
Choisissez ici la seconde possibilité, la plus commode :
# mkdir /sendmail/etc/mail
# ln -s /sendmail/etc/mail /etc/mail

Voici le fichier d’état de Sendmail, sendmail.st :
# touch /etc/mail/sendmail.st

et un très simple fichier mc :
include(`/usr/lib/sendmail-cf/m4/cf.m4′)
VERSIONID(`Sendmail chrooté ‘)dnl
OSTYPE(`linux’)dnl
define(`confMAX_MESSAGE_SIZE’, `5000000′)dnl
define(`STATUS_FILE’, `/etc/mail/sendmail.st’)dnl
define(`confDOMAIN_NAME’, `monserveur.com’)dnl
define(`ALIAS_FILE’, `/etc/mail/aliases’)dnl
define(`SMART_HOST’,`smtp.monfai.com’)dnl
define(`confLOG_LEVEL’,`14′)dnl
define(`confSEPARATE_PROC’,`true’)dnl
FEATURE(`access_db’,`hash -o /etc/mail/access’)dnl
FEATURE(always_add_domain)dnl
MAILER(smtp)dnl

qui vous permet de construire votre sendmail.cf :
# m4 sendmail.mc >sendmail.cf

Le niveau d’enregistrement des événements a été fixé à 14 (define(`confLOG_LEVEL’,`14′)). Cette valeur est particulièrement élevée afin de repérer les éventuelles erreurs. Dans cette configuration, tout le courrier est expédié vers le serveur de votre FAI, smtp.fai.com.
Voici le fichier /etc/mail/aliases :
MAILER-DAEMON: postmaster
postmaster: root
bin: root
daemon: root
nobody: root
system: root
root: monemail@monadresse.com

que vous créez de la façon suivante :
# chroot /sendmail /usr/sbin/sendmail -bi -v

Le root est en fait un alias vers une autre adresse e-mail. Sur le serveur chrooté, vous n’acceptez, par commodité, aucune livraison de courrier (voir plus haut).
Voici le fichier /etc/mail/access correspondant, qui contrôle les adresses autorisées à utiliser le relais :
127.0.0.1 RELAY
10 RELAY
localhost RELAY
localhost.localdomain RELAY

que vous créez de la manière suivante :
# makemap -v hash access.db <access

Seule la machine locale et le réseau IP 10.0.0.0 sont autorisés à utiliser le relais SMTP.
Démarrez Sendmail :
# chroot /sendmail /usr/sbin/sendmail -bd -q15m

Le serveur doit maintenant fonctionner correctement.
L’utilitaire strace est recommandé pour la mise au point d’un Sendmail chrooté. Il permet notamment de déterminer les fichiers et bibliothèques manquants.
Désormais, vous disposez d’un Sendmail parfaitement sécurisé, enfermé dans une prison logique.

Question. Lorsque je lance Sendmail en ligne de commandes, j’obtiens le message ci-dessous. Pourquoi ?
daemon invoked without full pathname; kill -1 won’t work

Réponse. Sendmail est exécuté sans précision de chemin d’accès. En conséquence, il n’est pas possible de lui faire déterminer l’emplacement de son fichier de configuration sendmail.cf. Une tentative de relecture de sa configuration échoue donc. Pour résoudre ce problème, il faut exécuter Sendmail en lui précisant son chemin d’accès absolu :
# /usr/sbin/sendmail -bd -q15m

Question. Sendmail affiche le message ci-dessous. Pourquoi ?
Jun 21 01:00:47 localhost sendmail[28920]: gethostbyaddr(192.168.1.2) failed: 1

Réponse. Sendmail n’arrive pas à résoudre l’adresse locale. Si vous disposez d’un DNS local, il suffit de renseigner cette adresse :
mon-serveur-smtp IN A 192.168.1.2

Sinon, codez l’adresse dans le fichier /etc/hosts avec le nom de la machine locale :
192.168.1.2 localhost.localdomain

Question. Sendmail affiche le message ci-dessous. Pourquoi ?
Feb 9 04:04:57 s5b sendmail[31844]: h1934vO31844: ruleset=check_rcpt, arg1=<toto@toto.com>, relay=192.168.0.2 [195.242.86.240], reject=550 5.7.1 <toto@toto.com>… Relaying denied

Réponse. L’utilisateur n’est pas autorisé à utiliser Sendmail comme relais. Pour l’autoriser, il suffit de renseigner le fichier /etc/mail/access:
192.168.0.2 RELAY
10.1 RELAY
toto.com RELAY

Question. Sendmail affiche le message ci-dessous. Pourquoi ?
Aug 24 19:13:17 localhost sendmail[4653]: poststats: /etc/mail/sendmail.st: No such file or directory

Réponse. Ce message apparaît lorsque le niveau d’enregistrement des événements défini par l’option LogLevel est assez élevé (par exemple 14). Il signifie que Sendmail n’a pas trouvé le fichier contenant ses statistiques de trafic. Il suffit de baisser le niveau d’enregistrement des événements en insérant dans le fichier sendmail.mc la directive :
define(`confLOG_LEVEL’,`9′)dnl
Vous pouvez également créer le fichier manuellement :
# touch sendmail.st
L’emplacement de ce fichier est défini par l’instruction M4 suivante :
define(`STATUS_FILE’, `/etc/mail/sendmail.st’)dnl

Question. L’enregistrement des événements présente la ligne ci-dessous. Pourquoi ?
Aug 22 09:43:51 s5b sendmail[17292]: g7M7hp917292: … Invalid route address
Le domaine s1.fr est local, et l’adresse est présente dans la virtusertable.

Réponse. Il s’agit vraisemblablement d’un problème dans la virtusertable.
Commencez par détruire la base :
# cd /etc/mail
# rm virtusertable.db
Puis reconstruisez la base :
# make
Si le problème persiste, c’est que la syntaxe n’est pas correcte dans la virtusertable. Celle-ci doit être utilisée comme suit :
adresse locale adresse distante ou alias
Par exemple :
moi@ici.com toi@labas.com
Une erreur commune est d’insérer les deux points (« : ») entre les deux éléments, comme pour les alias.
L’adresse locale doit correspondre à un domaine de messagerie géré localement par Sendmail. Cela signifie que le domaine doit exister dans le fichier local-host-names. En aucun cas, il ne peut y avoir plusieurs adresses distantes ou aliases, contrairement aux enregistrements contenus dans le fichier des aliases.

Question. Sendmail est très long lorsqu’il envoie ses messages. Pourquoi ?

Réponse. Il s’agit sans doute du problème le plus courant qui surgit dans l’exploitation de Sendmail. Il peut s’agir d’un problème de requête DNS inversée. Lors d’une connexion SMTP sur Sendmail, ce dernier tente d’identifier son client en effectuant une requête DNS inversée. Contrairement à une requête DNS standard, par laquelle on cherche à récupérer une adresse IP à partir d’un nom DNS (s1.d0.com –> 192.168.1.2), cette opération consiste à chercher un nom DNS depuis l’adresse IP (192.168.1.2 –> s1.d0.com) dans le but d’identifier le client. Pour résoudre ce problème, il faut être sûr que le client dispose d’une résolution inversée. Les enregistrement DNS suivantes vous montrent comment créer une zone de résolution inversée suivant les recommandations de la RFC 2317 :
$ORIGIN 1.168.192.IN-ADDR.ARPA.
1 IN PTR routeur.d0.com.
2 IN PTR s1.d0.com.
Il peut aussi s’agir d’un problème d’IDENT. Lors de l’envoi d’un message, Sendmail génère des requêtes IDENT vers le serveur de destination. Le protocole d’identification IDENT obéit à la RFC 1413. Il fournit un moyen de déterminer l’identité d’un utilisateur sur une connexion TCP. Suivant le port TCP utilisé, le protocole retourne une chaîne de caractères qui identifie le propriétaire de la connexion sur le serveur.
Si Sendmail ne réussit pas à récupérer cette information, il tente plusieurs fois la même opération jusqu’à ce qu’il dépasse le délai qui lui est imparti pour réussir. Ce délai est fourni par l’option Timeout.ident. Pour accélérer ce délai, il suffit de lui indiquer une valeur basse ou, plus radicalement, de le désactiver. Cela s’effectue facilement au moyen de l’instruction M4 suivante :
define(`confTO_IDENT’,`0s’)dnl
Si vous disposez d’un firewall, mieux vaut rejeter les requêtes TCP IDENT plutôt que de les ignorer. Un rejet implique l’émission d’une réponse ICMP en direction du demandeur. Si le firewall ignore les requêtes IDENT, l’émetteur tente plusieurs fois l’envoi de ces requêtes. Ce n’est qu’une fois qu’il a dépassé un certain nombre de tentatives qu’il considère que l’opération a échoué. Le nombre de tentatives varie d’un système à un autre.
Sous Linux, il faut utiliser le filtrage suivant :
/sbin/iptables -A INPUT -p tcp –dport $113 -j REJECT

Question. Depuis que j’utilise Sendmail, j’ai remarqué qu’un service TCP s’est installé sur le port 587. Pourquoi ?

Réponse. Il s.agit de l’agent de soumission de message, ou MSA (Message Submission Agent), de Sendmail, défini par la RFC 2476. Il sert généralement aux utilisateurs locaux protégés par un firewall. Une transaction sur le MSA se veut beaucoup moins contraignante par rapport à ce qui se fait habituellement sur le MTA. Ce dernier autorise que le format des adresses soit simplifié, que certains en-têtes de messages soient outrepassés, etc.
Les soumissions sur le MSA sont différentes des opérations sur le MTA. Elles utilisent d’autres dispositifs, n’autorisent pas la commande ETRN et peuvent demander une authentification de l’utilisateur.
Si vous ne souhaitez pas utiliser cet agent, il suffit de le désactiver via la commande M4 suivante :
FEATURE(`no_default_msa’)dnl

Question. Sendmail affiche le message ci-dessous. Pourquoi ?
<moi@toufaux.com>… Sender domain must resolve

Réponse. Sendmail est incapable de résoudre le nom de domaine employé dans l’adresse électronique, ici toufaux.com. Cela signifie que ce nom n’existe pas sur Internet ou qu’il a été fabriqué de toute pièce. Pour vérifier l’intégrité d’un domaine, il faut employer la commande suivante :
# dig ns toufaux.com
Si vous souhaitez malgré tout que Sendmail autorise la gestion des domaines non résolus, vous devez employer les commandes M4 suivante :
FEATURE(`accept_unresolvable_domains’)
FEATURE(`accept_unqualified_senders’)

Question. Sendmail affiche le message ci-dessous. Pourquoi ?
Jan 4 18:10:41 s2 sendmail[9204]: h04HAfP09204: h04HAfQ09204: DSN: Too many hops 26 (25 max): from s1.d0.com, to <moi@labas.com>

Réponse. Le message boucle et n’arrive jamais à destination. Chaque fois qu’un message est géré par Sendmail ou par tout autre MTA, ce dernier ajoute dans l’en-tête du message le champ SMTP Received:. Ce dernier est apparenté à un TTL (Time-To-Live), ou durée de vie d’une information réseau. Cela évite qu’un message boucle, c’est-à-dire qu’il transite plusieurs fois par le même tronçon. Lorsque le TTL attend 25 (dans l’exemple donné), le message est rejeté.
Ce problème provient généralement d’un mauvais routage du courrier. Il passe bien une première fois par Sendmail mais revient par la suite, d’où le message d’erreur. Pour corriger le problème, il faut s’assurer que le domaine est bien routé en sortie, via la mailertable ou un SMART_HOST, ou qu’il est présent dans le fichier des domaines locaux (fichier local-host-names). En l’absence de l’un de ces fichiers, Sendmail effectue une requête MX et réexpédie le message vers le MX de poids fort.

Question. Sendmail affiche le message ci-dessous. Pourquoi ?
relay=s1.d0.com [10.1.1.2] (may be forged)

Réponse. Sendmail constate qu’il n’y a pas de concordance entre le nom DNS de l’expéditeur (s1.d0.com) et son adresse IP (10.1.1.2). Sendmail considère que l’émetteur a fabriqué l’adresse de toute pièce. Pour contourner ce problème, il faut que l’adresse IP du relais et son nom DNS concordent.

Question. Que signifie le message suivant ?
NOQUEUE: Null connection from <NULL>.

Réponse. Cela signifie qu’une machine s’est bien connectée sur Sendmail mais qu’elle n’a initié aucune transmission de message (via la commande MAIL). Cela peut correspondre à d’éventuels problèmes réseau. Il peut aussi s’agir d’un plaisantin qui tente des connexions sur le port 25 du serveur.

Question. Sendmail affiche le message ci-dessous. Pourquoi ?
dec 29 19:52:14 s1 sendmail[29024]: gBTIqEA29024: SYSERR: putoutmsg ([210.204.118.194]): error on output channel sending « 220 s1.d0.com ESMTP Sendmail 8.11.1/8.11.1; Sun, 29 Dec 2002 19:52:14 +0100″: Broken pipe

Réponse. Lors de la transmission de l’en-tête SMTP de bienvenue, et après que l’émetteur a envoyé la commande HELO, la communication s’interrompt. Il s’agit d’un problème réseau.

Question. Que signifient les messages suivants ?

« MX list for hostname points back to hostname »
ou :
« config error: mail loops back to myself »

Réponse. Le message boucle. Il ne peut être livré à destination et revient toujours sur la même machine, le MX du domaine de messagerie. Cela signifie que ce dernier existe bien dans le fichier access mais qu’aucun routage, via la mailertable ou la directive SMART_HOST, n’est défini.
Pour résoudre ce problème, il faut router correctement le domaine de messagerie vers le serveur de destination ou créer le domaine localement en l’entrant dans le fichier local-host-names.

Question. Sendmail n’envoie pas sur les MX lorsque l’adresse de destination est un sous-domaine

Réponse. Sendmail doit considérer le domaine comme local, sans doute par le fait qu’il a trouvé sur une de ses interfaces réseau, une référence au domaine. Dans ce cas, le mieux est de désactiver la recherche de référence sur les interfaces. Ceci se fait au moyen de l’instruction M4 confDONT_PROBE_INTERFACES. Si cette instruction est vraie alors Sendmail ne va pas insérer les noms et adresses des interfaces locales dans la classe {w} ; le sous-domaine sera alors considéré comme distant et routé via une requête MX, une mailertable, un SMART_HOST, ou tout autre dispositif de sortie.
Utilisez donc l’instruction suivante :
define(`confDONT_PROBE_INTERFACES’,`true’)

Question. Lorsque j’appelle Sendmail au moyen d’un script PHP, il utilise toujours l’adresse d’expédition « apache@localhost.localdomain »

Réponse. Sendmail ne sait pas déterminer automatiquement l’adresse d’expédition et utilise donc une adresse par défaut : l’utilisateur apache sur la première interface d’écoute de Sendmail, ici la boucle locale (127.0.0.1). La façon la plus facile est de préciser à Sendmail une adresse d’expédition via le paramètre « -f ».
Exécutez votre script PHP en appelant Sendmail comme ceci :
/usr/sbin/sendmail -ftoto@tutu.com

Question. J’ai modifié la configuration de Sendmail et rien n’a changé

Réponse. C’est vraisemblablement le mauvais fichier sendmail.cf qui a été reconstruit. Ce fichier est généralement placé dans /etc/mail, mais on peut aussi le trouver dans /etc. Pour savoir quel est le bon fichier à utiliser, il suffit d’employer la commande suivante:
# strings /usr/sbin/sendmail | grep sendmail.cf

Surveiller la partition /var d’un serveur Sendmail
Le petit script PERL ci-dessous récupère la taille maximale de la partition /var (index 3) ainsi que l’espace utilisé. Il calcule le pourcentage utilisé et prépare les résultats pour les passer à MRTG :
#!/usr/bin/perl
# getdisk.pl
$max=`snmpget 192.168.10.2 mdp host.hrStorage.hrStorageTable.hrStorageEntry.hrStorageSize.3`;
$used=`snmpget 192.168.10.2 mdp host.hrStorage.hrStorageTable.hrStorageEntry.hrStorageUsed.3`;
$max =~ s/.*\:(.*)/$1/g;
$used =~ s/.*\:(.*)/$1/g;
if($max==0)
{
$pct=0;
}
else
{
$pct = ($used * 100) / $max;
}
$pct =~ s/(.*)\..*/$1/g;
print « $pct\n$pct\n\n\n »;

Le chapitre MRTG ci-dessous crée un graphique du pourcentage de l’espace utilisé sur la partition /var :
Target[sendmail.diskvar]: `/home/mrtg/bin/getdisk.pl`
Directory[sendmail.diskvar]: sendmail
MaxBytes[sendmail.diskvar]: 100
Unscaled[sendmail.diskvar]: dwmy
Options[sendmail.diskvar]: gauge
Title[sendmail.diskvar]: Charge du disque /var
XSize[sendmail.diskvar]: 580
YSize[sendmail.diskvar]: 100
YLegend[sendmail.diskvar]: %
ShortLegend[sendmail.diskvar]: %
PageTop[sendmail.diskvar]:<H1> Charge du disque /var </H1>
Legend1[sendmail.diskvar]: Espace disque utilisé en pourcentage
LegendI[sendmail.diskvar]: Volumetrie
LegendO[sendmail.diskvar]: Volumetrie

Surveiller le nombre de connexions sur un serveur Sendmail
Le petit script PERL ci-dessous extrait le nombre de connexions sur le serveur Sendmail et le prépare dans un format compréhensible par MRTG :
# !/usr/bin/perl
# gestestab.pl
$cnx=` snmpget 192.168.10.2 mdp tcp.tcpCurrEstab.0`;
chomp($cnx);
($cnx) = ($cnx =~ /= Gauge32: (.+)/);
if($cnx eq «  »)
{
print « 0\n0\n »;
}
else
{
print « $cnx \n$cnx \n »;
}

Voici le chapitre MRTG servant à afficher le nombre de connexions :
Target[sendmail.estab]: `/home/mrtg/bin/getestab.pl`
Directory[sendmail.estab]: sendmail
Options[sendmail.estab]: gauge,nopercent
MaxBytes[sendmail.estab]: 50
Unscaled[sendmail.estab]: d
XSize[sendmail.estab]: 580
YSize[sendmail.estab]: 100
YLegend[sendmail.estab]: Nombre de connexions
ShortLegend[sendmail.estab]: Connexions
Title[sendmail.estab]: Connexions sur Sendmail
PageTop[sendmail.estab]: <H1>Nombre de connexions sur le serveur Sendmail</H1>

Surveiller la charge moyenne d’un serveur Sendmail
Le petit script PERL ci-dessous récupère la charge sur la dernière minute, l’arrondit et affiche le résultat sous une forme compréhensible par MRTG :
#!/usr/bin/perl
# getlat.pl
$charge=`snmpget 192.168.10.2 mdp enterprises.ucdavis.laTable.laEntry.laLoad.1`;
chomp($charge);
($charge) = ($charge =~/= (.+)/);
$charge=int($charge);
if($charge eq «  »)
{
print « 0\n0\n »;
}
else
{
print « $charge\n$charge\n »;
}

Voici le chapitre MRTG utilisé pour tracer la charge moyenne du serveur Sendmail : Target[sendmail.charge]: `/home/mrtg/bin/getlat.pl`
Directory[sendmail.charge]:sendmail
Options[sendmail.charge]: gauge,nopercent
MaxBytes[sendmail.charge]: 5
Unscaled[sendmail.charge]: dwmy
XSize[sendmail.charge]: 580
YSize[sendmail.charge]: 100
YLegend[sendmail.charge]: Charge
ShortLegend[sendmail.charge]: Charge
Title[sendmail.charge]: Charge du serveur Sendmail
PageTop[sendmail.charge]: <H1> Charge du serveur Sendmail </H1>

Surveiller la quantité de messages passant sur un serveur Sendmail
Tout d’abord voici un petit script Perl permettant la récupération des informations du fichier sendmail.st via la commande mailstats:
open (FD, »mailstats | »);
while (my $li = )
{
if($li =~ /===/)
{
$li=<FD>;
$li=~ s/ +/ /g;
@l0= split (/ /,$li);
($l0[3])=($l0[3] =~ /(.+)K/);
($l0[5])=($l0[5] =~ /(.+)K/);
if($l0[2] eq «  »)
{
print « 0 « ;
}
else
{
print « $l0[2] « ;
}
if($l0[4] eq «  »)
{
print « 0 « ;
}
else
{
print « $l0[4] « ;
}
}
}
close (FD);

Il ne faut pas oublier de supprimer le fichier /etc/mail/sendmail.st pour réinitialiser les informations de statistiques.
Le résultat du script est appelé au moyen d’une requête SNMP via la définition suivante dans le fichier snmpd.conf (exemple ucd-snmp) :
exec .1.3.6.1.4.1.2021.61 msg_geres /usr/bin/perl /usr/bin/pl/mlstat.pl

Le script ci-dessous reprend l’ensemble de la requête ainsi que le formatage pour MRTG :
#!/usr/bin/perl
# getmsg.pl
$etat=`snmpget 192.168.10.2 mdp enterprises.ucdavis.61.101.1`;
chomp($etat);
($etat, $etat2) = ($etat =~ /= « (.+) (.+) »/);
if($etat eq «  »)
{
print « 0\n »;
}
else
{
print « $etat\n »;
}
if($etat2 eq «  »)
{
print « 0\n »;
}
else
{
print « $etat2\n »;
}

Voici le chapitre MRTG permettant de tracer la volumétrie des messages :
Target[sendmail.msg]: `/home/mrtg/bin/getmsg.pl`
Directory[sendmail.msg]: sendmail
Options[sendmail.msg]: gauge,nopercent
MaxBytes[sendmail.msg]: 250
Unscaled[sendmail.msg]: d
XSize[sendmail.msg]: 580
YSize[sendmail.msg]: 100
YLegend[sendmail.msg]: Nbre de messages
ShortLegend[sendmail.msg]: msg
Legend1[sendmail.msg]: Messages entants
Legend2[sendmail.msg]: Messages sortants
LegendI[sendmail.msg]: Messages entants
LegendO[sendmail.msg]: Messages sortants
Title[sendmail.msg]: Volumétrie de la messagerie
PageTop[sendmail.msg]: <H1>Messages entrants / sortants Sendmail</H1>

fixera à 15 minutes le délai entre deux tentatives de livraison. Idéalement, une file d’attente devrait être toujours vide ; mais bien entendu, cela n’est pas possible : le serveur de destination n’est pas disponible, la charge moyenne du serveur est trop importante, il n’y a pas assez de place sur le disque, etc.

Il est intéressant de surveiller le nombre de messages contenus dans la file d’attente ; ceci permet d’anticiper les pannes et aussi d’isoler certains problèmes récurrents tels que les serveurs en difficulté. Lorsqu’une file d’attente croît régulièrement sans se stabiliser alors il arrive un moment où il faut se poser des questions : est-ce que mon serveur est suffisamment bien calibré, ai-je assez de bande passante, etc.

Pour surveiller cette file, nous allons utiliser une combinaison de scripts que nous passerons à MRTG via SNMP.

Tout d’abord, nous devons extraire le nombre de requêtes contenues dans la file. Ceci se fait via la commande « mailq ». Les informations résultantes de cette dernière ressemblent à ceci :
h9GFItZ2020003 95399 Thu Oct 16 17:18
8BITMIME (host map: lookup (toulouse.xyz.fr): deferred)
<123@toulouse.xyz.fr>
h9GEvdZ2017358 95399 Thu Oct 16 16:57
8BITMIME (host map: lookup (xyz.fr): deferred)
<5432@xyz.fr>
h9GEEgZ2012871 4567 Thu Oct 16 16:14 <>
8BITMIME (Deferred: Connection refused by m5.labas.com.)

h9GCYYZ2007297 13646 Thu Oct 16 14:34 <>
8BITMIME (Deferred: Connection refused by newton.vanpiperzen.fr.)

Total requests: 708

La dernière ligne nous intéresse directement; ici, il y a donc 708 messages bloqués dans la file d’attente. Afin d’extraire le nombre, une simple combinaison de commandes et un script Awk suffit :
# /usr/bin/mailq | /usr/bin/tail -1 | /usr/bin/awk ‘BEGIN {} { j= $3} END {printf « %s « ,j }’

* La première instruction (mailq) déclenche l’affichage de la file d’attente
* La deuxième passe le résultat dans la commande « tail » qui n’affiche que la dernière ligne ( Total requests: 708)
* Le script awk n’affiche que le dernier mot (708)

Ceci fait, nous allons désormais passer ces informations à MRTG; la façon la plus commode est d’utiliser SNMP.
Pour ce faire, il faut rajouter un OID propriétaire dans le snmpd.conf ; ici, nous travaillons avec ucd-snmp. Voici cet OID :
exec .1.3.6.1.4.1.2021.61 queue /home/s/queue.sh

Avec le script queue.sh contenant:
# !/bin/sh
# /usr/bin/mailq | /usr/bin/tail -1 | /usr/bin/awk ‘BEGIN {} { j= $3} END {printf « %s « ,j }’

Ceci terminé, il faut relancer le SNMP : # service snmpd restart (Sous RedHat)
# /etc/init.d/snmpd restart (Autre)

Essayons d’extraire les différents OID depuis la NMS (Network Management Server) :
# snmpwalk serveur-sendmail communaute enterprises.ucdavis.61
enterprises.ucdavis.61.1.1 = 1
enterprises.ucdavis.61.2.1 = « queue »
enterprises.ucdavis.61.3.1 = « /home/s/queue.sh »
enterprises.ucdavis.61.100.1 = 0
enterprises.ucdavis.61.101.1 = « 522″
enterprises.ucdavis.61.102.1 = 0

Ca fonctionne, et nous allons donc travailler avec l’OID enterprises.ucdavis.61.101.1
La prochaine étape est de créer une entrée MRTG afin de grapher régulièrement les entrées obtenues par notre script. La seule difficulté est que notre script Awk renvoie l’information sous forme de caractères; MRTG, quand à lui, attend un nombre. Nous allons donc devoir encore développer un script pour convertir la chaîne de caractères en nombre. Voici ce script, écrit en PERL, nous l’appellerons queue.pl :
#!/usr/bin/perl
$ip = shift @ARGV;
$com = shift @ARGV;
$mib1 = shift @ARGV;
$etat=`snmpget $ip $com $mib1`;
chomp($etat);
($etat) = ($etat =~ /= « (.+) »/);
if($etat eq «  »)
{
print « 0\n0\n »;
}
else
{
print « $etat\n$etat\n »;
}

Le script commence par récupérer l’OID au moyen de l’instruction « snmpget », puis il nettoie la chaîne des guillemets et finalement affiche le nombre en deux exemplaires, car MRTG attend toujours un minimum de deux nombres.
Pour utiliser notre script, il faudra donc taper :
# ./queue.pl
522
522

Il ne nous reste plus qu’à créer le chapitre MRTG :
Target[sendmail.queue]: `/home/s/queue.pl 192.168.0.2 com enterprises.ucd avis.61.101.1`
Directory[sendmail.queue]: sendmail
Options[sendmail.queue]: gauge,nopercent
MaxBytes[sendmail.queue]: 3500
XSize[sendmail.queue]: 580
YSize[sendmail.queue]: 100
YLegend[sendmail.queue]: Nbre de messages en attente
ShortLegend[sendmail.queue]: msg
Legend1[sendmail.queue]: Messages en attente
Legend2[sendmail.queue]: Messages en attente
LegendI[sendmail.queue]: Messages en attente
LegendO[sendmail.queue]: Messages en attente
Title[sendmail.queue]:Messages dans la file d’attente
PageTop[sendmail.queue]: <H1>Messages dans la file d’attente sur Sendmail</H1>

Note: des problèmes peuvent survenir avec SNMP et la commande mailq en cas de surcharge du serveur ; il est tout à fait envisageable que MRTG soit dans l’incapacité de récupérer les informations. Pour pallier à ce problème, le mieux est de faire tourner le script qui va chercher le nombre de messages dans la file d’attente directement sur le serveur SMTP ; ce script devra être lancé régulièrement via une entrée dans la crontab et le résultat placé dans un fichier. Après, ce nombre pourra être récupéré par SNMP par un simple « cat ».

Sendmail offre un dispositif standard de réécriture d’adresses: la genericstable.
Ce dispositif est destiné à transformer une adresse en une autre durant l’expédition d’un message. Malheureusement, ceci ne fonctionne qu’avec les domaines locaux, ceux qui sont gérés via le local-host-name. Le problème se pose donc lorsque l’on veut modifier une adresse distante, celle d’un FAI par exemple.

Heureusement, la grande force de Sendmail est justement de pouvoir réécrire n’importe quelle adresse. Il suffit donc de créer une nouvelle règle et de l’insérer dans le fichier sendmail.mc. Néanmoins pour des raisons de clarté, il est préférable de mettre la règle dans un fichier satellite.

J’ai appelé celui-ci « rewrite », et en voici son contenu:

LOCAL_RULE_3
D{DOMAINE}mon-domaine.com #` mon-domaine.com’
D{WANAGOO}wanagoo.fr #`wanagoo.fr’
Rlaurent<@${DOMAINE}>$* laurent.baloche<@${WANAGOO}>$1
Rcharles<@${DOMAINE}>$* charles.vanpiperzen<@${WANAGOO}>$1

Et en voici les explications:

Tout d’abord, la règle sera placée dans le groupe numéro 3 (LOCAL_RULE_3) en charge du prétraitement des adresses.
La lettre D définit la macro « DOMAINE » et y affecte le domaine, ici mon-domaine.com.
La lettre D définit la macro « WANAGOO » et y affecte le domaine distant, ici wanagoo.fr.
L’instruction suivante utilise la réécriture, la lettre « R » pour transformer l’adresse initiale lauren@mon-domaine.com en laurent.baloche@wanagoo.fr.
Idem pour charles@mon-domaine.com qui est transformée en charles.vanpiperzen@wanagoo.fr

Ceci fait, il suffit d’inclure les règles dans le fichier sendmail.mc:

include(`/etc/mail/rewrite’)

Puis de reconstruire le sendmail.cf:

#m4 sendmail.mc >sendmail.cf

et enfin faire relire à sendmail sa configuration:

#kill -HUP `head -1 /var/run/sendmail.pid’

Attention, cette opération doit être exécutée à chaque fois que l’on insère une nouvelle entrée dans le fichier rewrite.

Celui qui utilise une connexion intermittente se retrouve généralement face à la problématique suivante: Comme la connexion n’est pas permanente, il n’est à priori pas possible d’avoir son propre serveur SMTP gérant la réception du courrier en provenance de l’Internet. On doit alors laisser la gestion de tout le courrier électronique au FAI (Fournisseur d’Accès Internet), ce qui est somme toute dommage, surtout si l’on dispose d’un service informatique capable de gérer les services Internet.

Il est toutefois possible de contourner ce problème grâce aux extensions du protocole SMTP, défini par le ESMTP (Extended Simple Mail Protocol).

L’idée est la suivante:
- le courrier arrive sur le serveur SMTP du FAI,
- le FAI stocke le courrier dans une file d’attente,
- le client récupère toute la file d’attente lorsqu’il se connecte.

Attention, ici il n’est nullement question d’accéder à des boites aux lettres via POP mais bien de récupérer toute la file d’attente SMTP d’un domaine sans se soucier d’éventuelles erreurs de destinataires. Ces mêmes erreurs seront gérées par la suite par le serveur SMTP de destination; le FAI n’a qu’un rôle d’intermédiaire: il est serveur-relais, tout simplement.

Le mécanisme de récupération de la file d’attente SMTP se fait via la commande ETRN; c’est cette même commande qui sera étudiée plus tard et un petit programme en C illustrera son utilisation.

Voici la trame d’un message transitant depuis l’émetteur du message jusqu’au destinataire final, au-delà de la connexion intermittente:

Le client envoie son message vers son serveur de courrier via une transaction SMTP. Ce même serveur extrait le MX (Mail Exchanger) de son DNS et l’expédie via une autre requête SMTP sur le serveur relais. Ce dernier se contente de stocker le message dans la file d’attente; à ce stade, il n’y a plus aucune notion de délai de livraison: c’est le client lui même qui va récupérer le courrier quand bon lui semble. Lorsque la connexion intermittente monte, le serveur SMTP de destination exécute la commande ETRN et toute la file d’attente est récupérée. Le destinataire du message n’a plus qu’à récupérer son courrier via POP.

Une commande ETRN consiste en fait à accéder au port 25 d’un serveur SMTP, et à envoyer cette même commande. Le serveur SMTP tente alors d’accéder au port 25 de l’émetteur de la transaction et déclenche un dialogue SMTP entre les deux serveurs.
Le dialogue suivant vous montre comment se passe une transaction ETRN:
telnet mx.mondomaine.fr 25
220 mx.mondomaine.fr ESMTP Sendmail 8.10.0/8.10.0;
ehlo mx.tondomaine.fr
250-mx.mondomaine.fr Hello mx.tondomaine.fr [192.168.0.1] (may be forged),
etrn @tondomaine.fr
250 2.0.0 Queuing for node @tondomaine.fr started
quit
221 2.0.0 mx.mondomaine.fr closing connection

La commande « etrn @mx.tondomaine.fr » déclenche la transaction SMTP entre les deux serveurs. Il y a deux façons d’utiliser la commande ETRN:
soit par domaine (@tondomaine.fr), soit par file d’attente (#file), cela dépend du fournisseur et de sa façon de procéder.
Attention, la commande ETRN ne fonctionne qu’avec des serveurs ESMTP, d’où le « ehlo » qui est là pour tester la nature du serveur.

Dans la plupart des cas, le serveur utilisé est un Sendmail 8.10 ou plus doté d’une mailertable pour rediriger le courrier grâce à un mailer particulier appelé DSMTP.
Ci-dessous, un exemple de configuration pour sendmail:
Sendmail.mc
divert(-1)
dnl
dnl Configuration sendmail côté FAI
dnl
divert(0)
include(`/usr/lib/sendmail-cf/m4/cf.m4′)
VERSIONID(`Sendmail pour mx0.d0.com’)dnl
OSTYPE(`linux’)dnl
define(`confMAX_MESSAGE_SIZE’, `5000000′)dnl
define(`STATUS_FILE’, `/etc/mail/sendmail.st’)dnl
define(`confDOMAIN_NAME’, `mx0.d0.com’)dnl
define(`ALIAS_FILE’, `/etc/mail/aliases’)dnl
define(`confTO_QUEUEWARN’, `72h’)dnl
define(`confTO_QUEUERETURN’, `7d’)dnl
FEATURE(`access_db’,`hash -o /etc/mail/access’)dnl
FEATURE(`mailertable’,`hash -o /etc/mail/mailertable’)dnl
FEATURE(always_add_domain)dnl
MAILER(smtp)dnl

Mailertable
d1.com dmstp:[mail.d0.com]
d2.com dmstp:[mail.d0.com]
d3.com dmstp:[mail.d0.com]
d4.com dmstp:[mail.d0.com]

Sendmail.mc
divert(-1)
dnl
dnl Configuration sendmail sur une ligne RNIS/ISDN
dnl
divert(0)
include(`/usr/lib/sendmail-cf/m4/cf.m4′)
VERSIONID(`Sendmail pour mail.d0.com’)dnl
OSTYPE(`linux’)dnl
define(`confMAX_MESSAGE_SIZE’, `5000000′)dnl
define(`STATUS_FILE’, `/etc/mail/sendmail.st’)dnl
define(`confDOMAIN_NAME’, `mail.d0.com’)dnl
define(`SMART_HOST’,`esmtp:[mx0.d0.com]‘)dnl
define(`confCON_EXPENSIVE’, `true’)dnl
define(`ALIAS_FILE’, `/etc/mail/aliases’)dnl
define(`confTO_QUEUEWARN’, `72h’)dnl
define(`confTO_QUEUERETURN’, `7d’)dnl
MODIFY_MAILER_FLAGS(`SMTP’,`+e’)dnl
FEATURE(`access_db’,`hash -o /etc/mail/access’)dnl
FEATURE(`virtusertable’,`hash -o /etc/mail/virtusertable’)dnl
FEATURE(always_add_domain)dnl
FEATURE(local_procmail)dnl
FEATURE(use_cw_file)dnl
MAILER(smtp)dnl

Pour lancer l’ETRN, placez ce petit programme dans votre crontab sur la machine au delà de la connexion intermittente.