Par Jan Stumpel JW.Stumpel@inter.nl.net
Expériences avec SMTP (ou : Installation du courrier électronique sur un réseau domestique, suite...)
J'ai reçu beaucoup de réactions à la suite de Installation du courrier électronique sur un réseau domestique avec Exim dans le numéro 43 de Linux Gazette.
La plupart disaient deux choses :
Je me suis donc "remis à la planche à dessin" pour étudier à la loupe ce qui se passe quand un e-mail est envoyé. De ce fait, cet article vous explique ce que vous devez faire pour que la configuration exposée dans celui de LG 43 fonctionne réellement (je crois) ... et aussi pourquoi.
SMTP, comme vous le savez certainement, signifie "Simple Mail Transfer Protocol". C'est la méthode grâce à laquelle le courrier électronique est échangé entre les ordinateurs sur l'Internet. La communication de base entre eux (échange de paquets élémentaires et de flux de données) est l'affaire de TCP/IP. Le protocole SMTP est implémenté "au-dessus de" TCP/IP dans le but de transmettre des messages entre les machines. Livrons-nous à quelques expériences pour voir comment SMTP fonctionne.
Telnet fait partie des outils de base permettant d'établir des
connexions TCP/IP. Si vous tapez : telnet hôte port
votre ordinateur se connecte à celui qui s'appelle
hôte sur le port port. Cela
revient à passer un coup de téléphone au bureau d'une société "hôte"
et à demander à parler à M. Port. Votre appel ne sera couronné de
succès que si M. Port est présent et qu'il accepte de vous
répondre. De la même façon, un programme ("démon") doit être actif sur
l'autre ordinateur, "à l'écoute" des tentatives de connexions sur le
port spécifié, autrement, vous obtiendrez le message "connexion
refusée".
port est un nombre (sur 16 bits). Certains numéros de port
ont été réservés pour certains services. Le courrier électronique
(SMTP) fait appel au port 25, et le démon qui l'écoute est le MTA
(Mail Transport Agent : sendmail, exim, qmail, etc...). Si votre
Linuxette se nomme ciel, vous appelez son service SMTP en
tapant : telnet ciel 25.
Vous pouvez le faire depuis une autre machine ou en passant par un
réseau (LAN ou Internet). En fait, vous n'en avez pas besoin, car
vous pouvez aussi tester ceci en lançant telnet depuis
l'ordinateur même sur lequel tourne le MTA. Il est même possible de
faire :
telnet ciel smtp
car telnet détermine le numéro de port de SMTP en allant voir
dans le fichier /etc/services. Ce qui donnera quelque chose
comme :
Trying 192.168.1.1... Connected to ciel.home. Escape character is '^]'. 220 ciel.home ESMTP Exim 3.03 #1 Sun, 8 Aug 1999 12:47:24 +0200
Ceci indique que j'utilise exim 3.03 (je l'ai récemment mis à
jour depuis la version 2.05 pour une bonne raison, cf la section 5
infra). Si je lance un telnet de la même façon vers le
serveur de mail de mon FAI, je peux voir qu'ils font tourner Sendmail
8.8.8/1.19.
Après la ligne commençant par 220, il n'y a aucune invite ou quoi que
ce soit d'autre ; le MTA attend vos instructions. Alors, que faire
après ? Essayez d'entrer help.
Cela va provoquer cette réaction :
help 214-Commands supported: 214- HELO EHLO MAIL RCPT DATA 214 NOOP QUIT RSET HELP
Ce sont les éléments du langage de commande SMTP, ou "protocole", qui sont gérés par votre site. Pas exactement l'opulence ! SMTP est réellement un protocole "simple". Les commandes sont décrites dans le standard Internet qu'est la RFC821. Quelques "extensions" ont été ajoutées par la suite dans d'autres RFC, par exemple, la RFC1869. On dit des systèmes qui acceptent les commandes étendues qu'ils gèrent le "SMTP étendu", ou ESMTP (Extended SMTP). On en est informé par leur d'accueil comme on l'a vu précédemment avec Exim 3.03. Il n'y a pas de très grandes différences entre SMTP et ESMTP.
Pour terminer la connexion SMTP, envoyez la commande QUIT.
Après la ligne d'accueil (qui commence par 220) du système distant, vous êtes censé envoyer des commandes. La première devrait être HELO, ou, si vous traitez avec un système ESMTP, EHLO, la version plus récente. Elle devrait avoir votre nom de domaine pour argument :
EHLO votre_nom_de_domaine
Si vous êtes à la maison, sans nom de domaine officiel, lequel
allez-vous prendre ? En fait, n'importe quoi fait l'affaire, y compris
celui que vous vous êtes choisi, comme par exemple
ciel.home.
Essayons-le avec le serveur SMTP de notre FAI en
tapant telnet smtp.fai.com 25 ou ce qu'il vous plaira. Après
le message de bienvenue, entrez : EHLO ciel.home
Nous obtenons alors un message d'accueil plus ou moins élaboré, comme :
250-smtp.fai.com Hello customer123.dialin.fai.com [xxx.yyy.zzz.123], pleased to meet you 250-EXPN 250-VERB 250-8BITMIME 250-SIZE
Les salutations démarrent par des "250" : c'est le code "OK" pour
SMTP. Dans le cas présent, on nous accueille également en nous appelant
par notre nom de domaine temporaire
(customer123.dialin.isp.com) ainsi que l'adresse IP
(xxx.yyy.zzz.123) qui nous a été dynamiquement attribuée lors
de l'ouverture de la connexion ppp. L'autre système obtient ces
renseignements de la couche de transport du protocole TCP/IP. Dans le
cas d'une commande EHLO (ESMTP), il envoit aussi quelques lignes "250" pour
annoncer quelles commandes supplémentaires il reconnaît, en
dehors du strict minimum requis par la RFC821.
En règle générale, les serveurs de courrier ne se préoccupent
absolument pas de l'argument des commandes EHLO ou HELO
("ciel.home"). Ce qui revient à dire qu'en pratique, les
transactions EHLO/HELO réussissent toujours. Dans le cas où l'autre
système ne veut pas traiter avec vous, il a déjà refusé la connexion
telnet hôte smtp.
Il est possible d'envoyer un message électronique "à la main" via une
simple connexion telnet hôte smtp sur un serveur,
sans recourrir à un MTA, ni à un MUA, tel que pine. Essayons
cela d'abord (pour des raisons de sécurité) au sein de notre propre
réseau. Bien sûr, dans ce cas, il faudra que tourne un serveur
(MTA). L'utilisateur joe envoit un message à l'utilisateur
emi, ce qui va se dérouler en trois étapes. Tout d'abord la
commande MAIL FROM: (sous SMTP, elle sont insensibles à la
casse, donc vous pourriez tout aussi bien taper mail from:).
MAIL FROM: joe@home 250 <joe@home> is syntactically correct
En guise de réponse, nous avons une ligne "250", donc tout va
bien. Ensuite, la commande RCPT TO:, qui spécifie quel sera
le destinataire.
RCPT TO: emi@home 250 <emi@home> is syntactically correct
Encore 250, bien. Enfin, nous entrons le message lui-même, grâce à
la commande DATA :
DATA 354 Enter message, ending with "." on a line by itself
La réponse "354" nous invite à saisir les données du message. Ce
n'est pas uniquement le texte (ou "corps") du message ! Ces
"données" incluent aussi les champs d'en-tête, comme
Subject:, To:, Cc:, et From:. La
structure d'un message est définie dans un autre standard Internet, la
RFC822. Stricto sensu, cela ne regarde plus SMTP. Tout ce qui
l'intéresse, c'est l'enveloppe du message, à savoir, les
paramètres passés aux commandes MAIL FROM: et RCPT
TO:. Par conséquent, le champ To: inclus dans le
message et l'adresse RCPT TO: inscrite sur
l'enveloppe sont en principe deux choses différentes. On peut
réellement les différencier (n'essayez qu'avec des messages
locaux, s'il vous plaît !). Donc, par exemple, après la
réponse, nous pouvons taper un message avec des "faux en-têtes" :
To: Ma Fille
From: Ton Papa
<--(une ligne vide sépare les en-têtes du corps)
Joyeux Anniversaire~!
. <--(un point au début d'une ligne termine le message)
Il sera rapidement distribué à l'utilisateur emi. Si elle
l'ouvre avec pine, elle verra les adresses To: Ma
Fille et From: Ton Papa.
Les problèmes vont surgir lorsqu'elle tentera d'y
répondre. Les réponses des utilisateurs ne partent pas vers
l'adresse "from de l'enveloppe" (le MAIL FROM: de SMTP), mais
vers l'adresse From: qui fait partie des données du message.
Pour simplifier, pine va penser que "Ton" et "Papa" sont deux
adresses différentes et se plaindre quant au fait qu'ils devraient
être séparés par une virgule, pas par un espace ! Et bien entendu,
aucun compte "Ton" ou "Papa" n'est enregistré sur cette machine, ou
sur n'importe quelle autre. La manipulation ou l'omission des diverses
adresses est un terrain d'action fertile pour les plaisantins et
autres spammeurs.
A présent, nous arrivons à ce qui n'allait pas dans mon article du numéro 43 de Linux Gazette. En dehors du "bug de pine" à propos duquel j'ai publié une note dans le numéro 44, les deux plus gros problèmes rencontrés par les lecteurs étaient :
Le MTA peut ne pas être actif du tout.
J'ai dit qu'on pouvait utiliser le client mail (c'est à dire
pine) du côté Linux "tel qu'il est fourni". C'est vrai, mais
l'ennui, c'est que chez beaucoup d'utilisateurs, le client mail n'est
pas fourni tel quel, mais est déjà installé et utilisé. Cela
signifie souvent que dans sa configuration, on trouvera une
affectation à un "serveur SMTP" pointant vers l'adresse de celui du
FAI. Dans un tel cas, c'est le client mail lui-même qui s'occupera des
transactions SMTP (la plupart d'entre eux, en dehors de mail,
peuvent le faire), et votre MTA ne sera pas utilisé du
tout. De ce fait, il ne sera pas fait appel à votre filtre de
transport et l'adresse From: au sein du message ne sera pas
modifiée. Solution : affecter à "serveur SMTP" dans le client mail le
nom de votre Linuxette, de façon à ce qu'il puisse passer les messages
au MTA. Si on vous demande votre "adresse e-mail", donnez votre
adresse locale, le filtre de transport d'exim la
changera pour tout courrier sortant.
Le "From de l'enveloppe" n'est pas modifié.
Là était le gros problème. Comme je l'ai dit, l'échange d'e-mail avec un hôte SMTP met en oeuvre trois étapes :
Si tout se passe bien, le système distant répondra "OK" (c'est à dire,
"250") aux deux premières. Enfin, en général ! Beaucoup de serveurs de
courrier (voire la plupart), y compris celui de mon propre FAI, ne
tiennent pas compte de l'adresse du champ MAIL FROM:. Pour
eux, c'est toujours "OK". Quelques-uns vérifient que la
partie domaine de cette adresse existe bien. Dans le cas contraire, le
message est refusé. Si c'est ce qui se passe chez votre FAI, la
configuration décrite dans mon précédent article ne fonctionnera
tout simplement pas pour le courrier sortant. Si votre FAI ne
vérifie pas, mais que vous envoyez du courrier vers un destinataire
qui le fasse, il n'arrivera pas à bon port et vous n'en serez pas
averti.
En clair, il faut absolument arranger non seulement l'adresse From:
incluse dans le message (à l'aide du programme
outfilt décrit dans mon article précédent), mais aussi celle
du champ MAIL FROM: (le "From: de l'enveloppe"). Il y a deux
manières de le faire.
Si vous utilisez exim 2.05 ou antérieur, la seule façon est
d'ajouter une ligne dans la dernière section, REWRITE
CONFIGURATION, de exim.conf :
*@home joe.bloggs@fai.com F
Ceci va remplacer toutes les adresses locales MAIL FROM: par
celle du FAI. Malheureusement, avec cette méthode, autant le courrier
sortant que local est modifié. Vous pouvez vous en accommoder, les
utilisateurs ne voyant jamais "le From: de l'enveloppe" quand ils
ouvrent un message. Les réponses iront à la bonne adresse (le From: du
message). Cependant, si quelqu'un se trompe en tapant une adresse
locale, de sorte qu'un courrier est envoyé vers un utilisateur local
fantôme, un message d'erreur ne sera pas expédié vers le FAI, mais
localement.
Par contre, avec exim 2.10 ou ultérieur, vous pouvez
ajouter une option à la sous-section remote_smtp de la
section TRANSPORTS CONFIGURATION du fichier
exim.conf. Ces versions plus récentes d'exim
permettent au "From: de l'enveloppe" d'être modifié pour le
courrier sortant uniquement. Après la ligne
driver~=~smtp, insérez une ligne
~; return_path = "joe.bloggs@fai.com".
Comme cette méthode est bien meilleure, si vous utilisez exim 2.05, je vous engage à procéder à une mise à jour. Dans le cas de la distribution Debian, on peut trouver la dernière version (au moment de l'écriture de ces lignes, 3.03) sur http://www.debian.org, parmi les paquetages "instables" (ne vous inquiétez pas, il est plutôt stable). La mise à jour se fait sans douleur.
Les deux méthodes décrites ci-dessus engendrent une adresse du
"From: de l'enveloppe" fixe, tout comme le programme
outfilt de mon précédent article le faisait pour le "From: du
message". Le présent cas de figure repose sur un compte e-mail
unique. Si les utilisateurs de la maisonnée sont connus du monde
extérieur par différentes adresses e-mail, la configuration
devient un peu plus ardue, mais cela reste faisable. Il serait trop
long d'en expliquer toutes les possibilités ici, jetez donc un coup
d'oeil au "développement de chaînes" et à "l'analyse de fichiers" dans
la documentation d'exim.
Copyright © 1999, Jan Stumpel. Publié dans le numéro 45 de la Linux Gazette, septembre 1999.
Traduction française de Joël Sagnes.