Ce petit guide vous propose de résoudre sous forme de FAQ quelques problèmes fréquents rencontrés lors de l’utilisation de Sendmail.

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