Le protocole SMTP (RFC 821)

C’est un protocole de transfert dédié au service de messagerie, il s’appuie sur TCP/IP et est défini dans la RFC 821. Ce protocole gère le dialogue entre un client et un serveur de messagerie. Pour échanger un message, une "discussion" a lieu entre le client et le serveur et différentes commandes sont échangées en ligne.

Liste des commandes SMTP

Champ	Explications
HELO site-émetteur	Commence une session SMTP par une identification des deux parties. Le récepteur s’identifie dans sa réponse
MAIL FROM : émetteur	Commence une nouvelle transaction. Spécifie l’expéditeur, pour le renvoi des messages d’erreur éventuels
RCPT TO : destinataire	Spécifie un destinataire. Cette procédure peut être répétée autant de fois que nécessaire. Si le destinataire n’est pas valide, un code d’erreur est renvoyé aussitôt
DATA	Envoie le message (en-tête + corps) terminé par une ligne ne contenant qu’un point. Pour ne pas interférer avec le message à transmettre, toute ligne du message contenant un point en première position est modifiée en insérant un point supplémentaire en début. Ce point supplémentaire est supprimé par le récepteur (hidden dot algorithm)
SEND FROM : expéditeur	Commence une nouvelle transaction (de manière analogue à MAIL) pour envoyer un message sur un terminal Note : non supporté par sendmail.
SEND FROM : expéditeur	Commence une nouvelle transaction (de manière analogue à MAIL) pour envoyer un message sur un terminal Note : non supporté par sendmail.
SOML FROM : expéditeur	Commence une nouvelle transaction (de manière analogue à MAIL) pour envoyer un message sur un terminal ou dans une boîte aux lettres si le destinataire n’est pas connecté Note : non supporté par sendmail.
SAML FROM : expéditeur	Commence une nouvelle transaction (de manière analogue à MAIL) pour envoyer un message sur un terminal et dans une boîte aux lettres Note : non supporté par sendmail.
RSET	La transaction courante est annulée, l’ensemble du logiciel est réinitialisé, un nouveau message peut donc être envoyé sur le même canal.
VRFY destinataire	Demande au site récepteur de vérifier que le destinataire est une adresse valide.
EXPN destinataire	Demande au site récepteur, d’une part de vérifier que le destinataire est une adresse de liste de diffusion valide, et d’autre part de renvoyer les identités des membres de la liste.
HELP	Help (HELP commande) Renvoie la liste des commandes SMTP admises par le site récepteur.
NOOP	Ne fait rien
QUIT	Termine la session SMTP
TURN	Demande au site récepteur de devenir site émetteur. Le site émetteur devient site récepteur Note : non supporté par sendmail.

Ce message, comme pour une lettre envoyée par la poste, est mis dans une enveloppe qui servira au routage par les serveur de messagerie. Cette enveloppe contient des indications sur l’identité des destinataires et de l’expéditeur (écrites par l’agent de routage de message). Au fur et à mesure du routage du message de serveur en serveur, des traces sur l’dentité des agents de transport par lesquels il est passé sont ajoutées.

Format des messages SMTP (RFC 822)

Comme la plupart des codages utilisés sur Internet, les fichiers sont codés en format ASCII standard 7 bits et ne peuvent donc pas représenter de textes comportant des accents ni de fichiers binaires. Le message est constitué de différentes parties :
  En-tête
Suite de champs From, To, Date, Subject, Message-ID, CC, ... renseignés par l’User Agent (UA) ou par les agents de routage. Un champ est constitué d’un mot clé (From, To, Date, ...) suivi de " :" puis de la valeur du champ. Si un champ fait plusierus lignes, une nouvelle ligne commence par un caractère de tabulation.
  Corps
Le contenu du message (texte) est séparé de l’en-tête par une ligne vide, son contenu est standardisé par la RFC 821 et maintenant par Mime.
  Champs

Champ	Explications
Return-Path	adresse de l’expéditeur de l’enveloppe
Received	Informations ajoutées par chaque agent de routage pendant le routage du message
From	Expéditeur, placé par son UA lors de l’émission de message
Sender	Identité de l’expéditeur réel ; sert par exemple pour le retour des erreurs, champ renseigné s’il différe de From
Repply-to	Adresse à mettre en cas de réponse
Date	Date d’expédition (exemple 29 Aug 95 08 07 46+0200, date heure fuseau horaire)
To	Destinataire principaux
Cc	En copie
Bcc	En copie muette
Message-Id	Identifiant du message
In-Reply-To	Référence au message original en cas de réponse
References	Identifiants de messages précédemment envoyé et cités en référence
Keywords	Mots-clés séparés par des virgules, spécifiés par l’expéditeur à l’aide de son UA
Subjects	Sujet du message
Comments	Commentaires
Encrypted	Chiffrage du message et indication de la méthode utilisée

Exemple d’u n envoie de message SMTP

220 mail.povmaileur.fr SMTP
HELO fred.com
250 mail.povmaileur.fr Hello ppp112.monprovider.Fr [194.123.100.159], please to meet you
MAIL FROM : fred@emet.fr
250 fred@emet.fr ... Sender ok
RCPT TO : toto@web.net
250 toto@web.net ... Recipient ok
DATA -> début de la zone message
354 Enter mail, en width "." on a line by itself
Date : Sat, 06 Feb 2001 04 :30 :26 +0100
Subject : Salut, c'est fred
To : toto the best <toto@web.net>
From : fred <fred@emet.fr>
Cc : marie <marie@albert.net>
(ligne vide) -> fin de la zone d'entête du message
Salut, mon pote
Devine un peu qui t'envoie ce mail ?
.(ligne ne contenant qu'un point) -> fin de la zone data
250 EAA18871 Message accepted for delivery
QUIT

Accusé de remise

Les RFC 1891 à 1894 décrivent les DSN (Delivery Status Notifications). Il s’agit des accusés de remise, c’est-à-dire d’un message informant l’émetteur d’un message de son dépôt dans la boîte aux lettres de son destinataire.

L’émetteur peut choisir les conditions d’émission de l’accusé : aucun accusé (même en cas d’échec de la transmission du message), ou alors accusé de réussite, d’échec, ou de retard de remise. L’émetteur peut également choisir entre un accusé contenant, outre un compte-rendu systématique, l’intégralité du message déposé ou seulement son en-tête.

Comme pour l’extension 8BITMIME, si un MTA prend en charge un message demandant un accusé de remise, alors il garantit qu’il y aura émission d’un accusé. En particulier, si le prochain MTA ne supporte pas les accusés de remise, notre MTA doit émettre un accusé d’échec pour pré venir l’expéditeur que l’accusé demandé ne pourra pas lui être remis.

Pour supporter ces accusés, il faut enrichir les informations véhiculées dans l’enveloppe du message original, grâce à des paramètres supplémentaires des commandes MAIL et RCPT.

RCPT TO : destinataire NOTIFY=raison ORCPT=adresse

Le paramètre raison peut prendre la valeur NEVER, auquel cas aucun accusé de remise n’est généré, ou une liste de valeurs parmi SUCCESS, FAILURE et DELAY. Par exemple, si NOTIFY=SUCCESS,DELAY, un accusé est remis si le message arrive à bon port, mais également s’il réside longtemps dans la file d’attente d’un MTA sur le chemin.

L’adresse du destinataire peut être réécrite par les MTA intermédiaires, et peut donc ne plus correspondre à ce qu’a tapé l’expéditeur. Afin que l’accusé de remise soit correct, l’adresse originale du destinataire est spécifiée avec le paramètre adresse, ainsi que le type d’adresse (les types sont standardisés, et parmi ceux-ci figure le type rfc822).

MAIL FROM : expéditeur RET=retour ENVID=identificateur

Le paramètre retour indique la portion du message original que l’accusé doit contenir : les valeurs admises sont FULL pour avoir l’intégralité du message, ou HDRS pour n’avoir que les en-têtes.

Le paramètre identificateur, choisi par exemple par l’UA de l’expéditeur, figurera dans l’accusé. Cela permet à l’UA de retrouver le message original.

L’exemple suivant illustre l’utilisation de ces paramètres. Ici, l’accusé doit être envoyé en cas de succès, et doit spécifier l’adresse paul@uvsq.fr comme adresse de destinataire, même si cette adresse est réécrite suite à un alias. L’accusé doit conte nir l’intégralité du message.

220 soleil.uvsq.fr ESMTP Sendmail 8.9.1/jtpda-5.3.1 ready at Mon, 20 Jul 1998 09 :30 :15 (GMT)
HELO shiva.jussieu.fr
250-soleil.uvsq.fr Hello shiva.jussieu.fr, pleased to meet you
250-DSN
250 HELP
MAIL FROM : <jean@jussieu.fr> RET=HDRS ENVID=toto
250 <jean@jussieu.fr>... Sender ok
RCPT TO : <paul@uvsq.fr> NOTIFY=SUCCESS ORCPT=rfc822 ;paul@uvsq.fr
250 <paul@uvsq.fr>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
From : jean@jussieu.fr (Jean Breille)
To : paul@uvsq.fr (Paul Ochon)
Subject : essai

ceci est un essai
.
250 LAA00602 Message accepted for delivery
QUIT

Limitations de SMTP

Les implémentations de SMTP conformes à la RFC 821 doivent avoir :

  messages sur 7 bits (tronqués explicitement à 7 bits)
  nom d’utilisateur < 64 caractères
  nom de domaine < 64 caractères
  nombre de destinataires < 100
  lignes < 1000 caractères

Certaines implémentations de SMTP peuvent être moins restrictives. On a vu apparaître, dans les quelques années qui ont précédé la sortie de la version 8 de sendmail, des versions qui ne tronquaient pas le huitième bit : ces versions ne sont clairement pas conformes à la RFC 821.

Le problème est que SMTP est un protocole fermé, sans possibilité de modification, donc d’évolution. Compte-tenu des besoins immédiats, tels que l’échange de courriers contenant des caractères accentués, et des besoins ultérieurs qui ne manqueront pas d’apparaître, deux approches complémentaires ont été adoptées en 1992 :

  définition de MIME (Multipurpose Internet Mail Extensions) pour être capable, entre autres, et si besoin est, d’échanger des messages contenant des accents (donc sur 8 bits) ou des données binaires sur un canal SMTP conforme strictement à la RFC 821 ;
  définition de ESMTP (Extended SMTP), extension au protocole SMTP, afin de pouvoir faire évoluer le protocole tout en gardant la compatibilité avec les implémentations actuelles ou à venir.