Il est devenu difficile de trouver un serveur opérationnel n'utilisant pas la version étendue de ce protocole et tous les exemples qui suivent seront donc donnés avec un serveur supportant cette évolution.
Je vous propose ici un extrait de l'article sur smtp paru dans linuxmagazine et que vous pouvez retrouver en intégralité sur www.nicolasjean.com
Envoyer un email
Le processus de transfert d'un email met en Åuvre une chaîne d'application et de protocole plus large que le simple protocole SMTP. Commençons par quelques définitions :MUA : Mail User Agent, c'est le client de messagerie (KMail, Evolution, etc.).
MTA : Mail Transfert Agent, c'est l'agent qui va transférer votre mail vers le serveur chargé de la gestion des emails de votre destinataire. Dans la pratique, le courrier peut transiter par plusieurs MTA.
MDA : Mail Delivery Agent est le service de remise du courrier dans les boîtes aux lettres des destinataires.
Donc si on résume, le MUA transfert l'email à un MTA qui le transfère au MTA du destinataire (ou à un MTA intermédiaire) qui le passe au MDA chargé de stocker l'email dans la boite aux lettres du destinataire. Dans la pratique le MUA établit une connexion SMTP avec un MTA qui contacte via SMTP le MTA du destinataire qui est aussi un MDA.
Ensuite libre au destinataire d'utiliser une commande simple (mail) ou un outil plus complexe (KMail, â¦) pour lire ces emails, utilisant le protocole POP ou IMAP (que nous aurons la joie de découvrir dans quelques semaines).
Un protocole client serveur
A l'instar de http, SMTP est un protocole client serveur en mode texte Il est défini dans la RFC 821. Cette dernière écrite en 1982 par Jon Postel (la légende, le père de l'Internet), se base sur une infrastructure bien moins performante que celle dont on dispose aujourd'hui. Il est donc prévu que les caractères transmis soient codés sur 7bits, oubliez les caractères accentués et autre gothique. Pour se connecter à un serveur SMTP (celui mis à disposition par votre fournisseur d'accès Internet fera parfaitement l'affaire), un simple telnet est utilisé :telnet smtp.wanadoo.fr 25
Le port 25 est celui généralement utilisé par le serveur pour recevoir une connexion. Vous retrouverez cette valeur si vous jetez un Åil dans le fichier /etc/services. Une fois la connexion établie, le serveur s'identifie.
220 mel-rta10.wanadoo.fr ESMTP Service (6.5.007) ready
On notera au passage que c'est un serveur ESMTP. Ensuite il convient d'être poli et de s'identifier en déclinant son nom de domaine:
HELO iprelax.net
Cette première opération sert à vérifier que la connexion est établie correctement et que les deux participants peuvent s'échanger des informations. (le " HELLO protocole " est une technique très répandue pour valider la qualité d'un lien ). Quant une opération se déroule bien, le serveur répond avec le code 250.
250 mel-rta8.wanadoo.fr
Nous allons ensuite envoyer un message à nicoas@iprelax.net en tant que linuxmag@iprelax.net.
MAIL FROM: <linuxmag@iprelax.net>
250 MAIL FROM:<linuxmag@iprelax.net> OK
RCPT TO: <nicoas@iprelax.net>
250 RCPT TO:<nicoas@iprelax.net> OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
bonjour,
ceci est un message de linuxmag pour nicolas.
.
250 <3D8011E600743103> Mail accepted
QUIT
221 mel-rta7.wanadoo.fr QUIT
Et je peux vous confirmer que j'ai bien reçu ce mail quelques secondes plus tard.
MAIL FROM
Rentrons un peu dans le détails, une fois le HELO de courtoisie échangé (il n'est pas toujours nécessaire), on utilise la commande 'MAIL FROM:' suivi du chemin de retour. Il s'agit en fait de l'endroit ou sera envoyé le message s'il n'est pas possible de le délivrer au destinataire. Dans la pratique, on utilise ici sa propre adresse email entourée de chevrons <>. Par exemple :MAIL FROM: <nicola@saleioche.com>
Après chaque commande on utilise les caractères 'carriage return' et 'line feed' (respectivement '\r' et '\n' dans les langages de programmation usuels). Cette commande doit être la première pour débuter une session d'envoi d'un message.
RCPT TO
La commande 'RCPT TO:' est suivi du chemin d'accès du destinataire. On parle ici de chemin et nom d'adresse car il est possible de spécifier plusieurs hôtes avant l'adresse. Un chemin a la forme "@UN,@DEUX:JOE@TROIS", dans laquelle UN, DEUX, et TROIS sont des noms d'hôtes. Cette forme est employée dans le but d'accentuer la différence formelle entre une adresse et une route. La boîte aux lettres est une adresse absolue, la route est une information permettant d'y accéder. Ces deux concepts doivent toujours être dissociés, cependant dans la vraie vie de l'utilisateur lambda à la maison cela n'arrive jamais (pour plus détails consultez la rfc). Je vais donc me contenter d'utiliser une simple adresse. On peut utiliser la commande RCPT plusieurs fois pour envoyer un même message à différentes adresses. Exemple :RCPT TO: <nicola@salemoche.com>
RCPT TO: <nicola@salemoche.net>
Ce message sera donc délivré aux 2 adresses. Le serveur valide l'adresse en renvoyant le code 250 après chaque ligne de commande.
DATA
La commande nécessite deux étapes. On passe la commande au serveur, il répond : 354 Start mail input; end withBonjour
..
.
sera reçu par le destinataire :
Bonjour
.
Sur la réception de la ligne avec le '.', le serveur valide la requête et envoie l'email. Si tout se passe bien il renvoie le code 250. Attention, si l'adresse email est invalide ou si la boite aux lettres du destinataire est inexistante ou encore pleine, le message ne sera pas délivré et vous recevrez quand même le code 250. Comme nous le verrons plus loin, la section DATA peut être composée d'un entête et d'un corps séparé par une ligne blanche, pour éviter les mauvaises surprises, si vous ne mettez pas d'entête à vos messages commencez les par une ligne blanche sous peine de perdre le première ligne d'information.
QUIT
Et sans surprise la commande 'QUIT' permet de terminer la transaction.Commandes
Il existe d'autres commandes, mais elles ne sont pas toujours disponibles sur les serveurs. On notera pêle-mêle HELP, liste les commandes disponibles sur le serveur, VRFY, vérifie une adresse destinataire, RSET, pour annuler les commandes passées et EXPN pour vérifier la disponibilité d'une liste de distribution et récupérer la liste des adresses associées.Le message
Si vous avez fait les tests précédents vous avez remarqué que lorsque vous lisez le mail, les informations 'from:', 'to:', 'subject:' (de, à et sujet en français) ne sont pas renseignés correctement. En effet, il faut distinguer les informations fournit lors du passage des commandes MAIL et RCPT qui permettent d'acheminer l'information, du contenu du message. C'est un peu comme si le facteur vous livrait une lettre en enlevant l'enveloppe au moment de la glisser dans votre boite aux lettres, à moins que l'expéditeur ait inscrit son adresse et la votre sur la lettre vous n'avez aucun moyen de savoir qui l'a envoyée. On va donc préciser dans le message (la section DATA), un certain nombre de champs. Ces champs doivent figurer au tout début du message et forment l'entête. Si vous saisissez une ligne blanche pour commencer votre message, ils ne seront pas pris en compte. Voici un petit exemple de session utilisant ces champs :220 mel-rta7.wanadoo.fr ESMTP Service (6.5.007) ready
HELO iprelax.net
250 mel-rta7.wanadoo.fr
MAIL FROM:<nicolas@salemoche.com>
250 MAIL FROM:<nicolas@salemoche.com> OK
RCPT TO:<nicolas@salemoche.net>
250 RCPT TO:<nicolas@salemoche.net> OK
DATA
354 Start mail input; end with
from: "Nicolas JEAN" <nicola@salemoche.com>
to: "Nicolas at salemioche dot net" <nicola@salemoche.net>
subject: email avec champs dans l'entete
coucou, ceci
est
un message
.
250 <3D8011E6007C45C8> Mail accepted
QUIT
221 mel-rta7.wanadoo.fr QUIT
Les champs sont formés d'une façon classique, le nom du champ immédiatement suivi de ':', un espace et la valeur du champ. Des champs pourront être ajoutés par les différents MTA pour ajouter des informations sur le routage du message jusqu'à son destinataire. Ces champs servent donc au MUA pour afficher l'email, le renseigner et permettre au destinataire d'y répondre. L'entête du message est séparé par une ligne blanche du corps du message. La RFC 822 décrit la liste de ces champs, et voici les plus courant :
From : from est suivi de l'adresse et de la route de l'expéditeur, on note ici la différence de notion entre adresse et route (entre chevrons). Théoriquement on peut donc avoir :
From: "nicoas@iprelax.net" <@smtp.wanadoo.fr,@smtp.iprelax.net:nicoas@iprelax.net"
Cet usage standard à finalement été détourné pour devenir : From: "Nickname" <adresse>
To : liste des destinataires principaux, on retrouve le format "Nick"
To: "com" <nicola@salemoche.com>, "net" <nicols@saleoche.net>
Cc : liste des destinataires en "copy carbon". Le format est le même que pour le champ 'To'. On remarque que le protocole SMTP ne fait pas de différences entre destinataire principal (To) et destinataire en copie (Cc), chacun nécessite la même commande RCPT.
Bcc : liste des destinataires en copie cachée. Personnellement, je ne trouve que peu d'intérêt à ce champ. Les adresses contenues dans ce champ ne sont pas incluses dans les copies des messages envoyées aux destinataires principaux et secondaires (Cc). Des systèmes peuvent choisir d'inclure le texte de cette zone "Bcc" seulement dans la copie de l'auteur, alors que d'autres peuvent aussi l'inclure dans le texte envoyé à tous ce qui sont indiqué dans la liste "Bcc". Dans la plupart des cas je vous recommande de ne pas l'utiliser. Pour envoyer une copie cachée, on utilise la commande RCPT pour une adresse qui ne figurera pas dans le corps du message.
Subject : pour le sujet du message.
Return-Path : donne une adresse pour la réponse qui soit différente de l'adresse utilisée pour l'envoi (celle qui figure dans le champ 'To'). Quand le destinataire utilisera la fonction 'Répondre' de son outil de messagerie, c'est cette adresse qui sera utilisée.
Date : date du message, parfait pour antidater un message :-). Exemple de date : Wed, 25 Sep 2002 17:39:28 +0200 (CEST). Si vous ne spécifiez pas de valeur, le premier MTA s'en chargera généralement.
Le but de cet article étant d'écrire un outil d'envoi de mail, ces quelques champs sont largement suffisant, je vous renvoie à la RFC pour 'tuner' vos messages plus précisément.