RFC du protocole SMTP : les spécifications smtp
4. LES SPECIFICATIONS SMTP
4.1. COMMANDES SMTP
4.1.1. SEMANTIQUE DES COMMANDES
Les commandes SMTP englobent les fonctions de transfert de message et les fonctions système appelées par l'utilisateur. Les commandes SMTP sont des chaînes de caractères terminées par une séquence <CRLF>. Les codes de commande eux-mêmes sont constitués d'une séquence de digits en mode texte terminée par un <SP> lorsque des paramètres suivent, sinon par <CRLF>. La syntaxe des boîtes-aux-lettres doit se conformer aux exigences conventionnelles du destinataire. Les commandes SMTP sont décrites ci-après. Les réponses SMTP à ces commandes sont décrites en Section 4.2.
Une transaction de courrier implique un certain nombre d'objets de données, transmis sous forme d'arguments dans les diverses commandes générées. La route inverse est l'argument de la commande MAIL, la route directe est l'argument de la commande RCPT, le contenu du message est l'argument de la commande DATA. Ces arguments ou objets de données doivent être transmis et conservés jusqu'à obtention de l'indication de "fin de données de courrier" qui achève la transaction. Le modèle préconisé pour cette tâche est de disposer de tampons de données distincts pour chaque type d'objet de données, c'est-à-dire, un tampon de route inverse, un tampon de route (directe), et un tampon de données de courrier. Certaines commandes spécifiques provoqueront l'ajout d'informations à tel ou tel tampon, ou provoquera l'effacement de tels ou tels tampons.
HELLO (HELO)
Cette commande sert à identifier l'émetteur-SMTP vis à vis du récepteur-SMTP. L'argument est formé du nom de l'hôte où réside l'émetteur-SMTP.
Le récepteur-SMTP s'identifie à son tour vis-à-vis de l'émetteur-SMTP en répondant aux "civilités", dans un message de réponse à cette commande.
Cette commande, ainsi que la réponse OK qui y sera apportée confirme que les deux agents-SMTP se faisant face sont tous deux dans leur état initial, c'est-à-dire, qu'aucune transaction n'est en cours de traitement et que toutes les tables d'état et tampons sont vides.
MAIL (MAIL)
Cette commande initialise une transaction de courrier par laquelle le message sera délivré dans une ou plusieurs boîtes-aux-lettres. L'argument mentionne une route inverse.
La route inverse consiste en une liste optionnelle d'hôtes ainsi que la boîte-aux-lettres de l'émetteur. Lorsque la liste d'hôtes est mentionnée, il s'agit d'une route "inversée" qui indique que le courrier a été relayé via chacun des hôtes de la liste (le premier hôte mentionné est le dernier relais par lequel est passé le message). Cette liste est utilisée comme route directe lorsqu'un message d'erreur doit être retourné à l'émetteur. Lorsque chaque relais utilisé ajoute son propre identifiant au début de la liste, le nom ajouté doit être celui qui identifie le relais vis-à-vis du relais suivant plutôt que celui qui l'identifie vis-à-vis de l'émetteur du message (si ces noms sont différents). Pour certains types de messages (par exemple, une notification d'erreur) la route inverse peut être vide (voir Exemple 7).
Cette commande provoque l'effacement des trois tampons (route inverse, route directe, et message) et initialise le tampon de route inverse avec l'argument fourni.
RECIPIENT (RCPT)
Cette commande permet l'identification d'un récipiendaire unique du message ; lorsque le message doit être délivré à plusieurs personnes, on multipliera d'autant l'usage de cette commande.
La route consiste en une liste optionnelle d'hôtes, ainsi que la mention de la boîte-aux-lettres du récipiendaire. Lorsque la liste d'hôtes est mentionnée, il s'agit d'une route d'acheminement qui indique que le message doit être relayé vers le premier relais mentionné dans la liste. Si le récepteur-SMTP n'implémente pas la fonction de relais de courrier, il répondra par le même message qu'il aurait généré pour un utilisateur local inconnu (550).
Lorsque le message est relayé, l'hôte relais doit supprimer son identifiant de la route (normalement en première position de celle-ci) et rajoute ce dernier en début de la route inverse. Lorsque le courrier atteint sa destination finale, (la route directe ne contient en effet qu'une seule boîte-aux-lettres cible), il est ajouté par le récepteur-SMTP dans cette boîte-aux-lettres selon les conventions locales de l'hôte support.
Par exemple, un courrier reçu par un hôte relais A avec les arguments
FROM:<USERX@HOSTY.ARPA>
TO:<@HOSTA.ARPA,@HOSTB.ARPA:USERC@HOSTD.ARPA>
sera retransmis vers l'hôte B avec les arguments :
FROM:<@HOSTA.ARPA:USERX@HOSTY.ARPA>
TO:<@HOSTB.ARPA:USERC@HOSTD.ARPA>.
Cette commande ajoute l'argument de route au tampon de route.
DATA (DATA)
Le récepteur traite les lignes suivant cette commande comme le corps du message émis par l'émetteur. Cette commande provoque l'ajout de ce texte au tampon de message. Le texte du corps de message peut contenir tout caractère parmi les 128 premiers codes ASCII.
Le corps de message est terminé lorsqu'une ligne ne contenant qu'un seul point est rencontrée, équivalent à la séquence "<CRLF>.<CRLF>" (voir la Section 4.5.2 à propos de la notion de Transparence). Cette séquence marque la fin de message.
La marque de fin de message signal au récepteur qu'il doit maintenant traiter l'ensemble des informations concernant la transaction. Ce traitement consomme l'information inscrite dans le tampon de route inverse, le tampon de route directe, et le tampon de message, lesquels sont vidés à la fin du traitement. Si le traitement s'effectue correctement, le récepteur doit envoyer une réponse OK. Si le traitement échoue, il envoie une réponse d'erreur.
Lorsque le récepteur-SMTP accepte un message, soit pour le relayer, soit pour livraison "finale", il insère au début des données de courrier une ligne de marquage temporel. Cette ligne indique l'identité de l'hôte origine du message, l'identité de l'hôte ayant reçu le message (celui qui écrit ce marqueur), ainsi que la date et l'heure à laquelle ce message a été reçu. Des messages relayés afficheront de multiples marqueurs temporels.
Lorsqu'un récepteur-SMTP effectue la livraison "finale" d'un courrier, il insère au début des données de courrier une ligne de route inverse. Cette ligne préserve l'information de l'argument <route-inverse> associé à la commande MAIL reçue. A partir de ce moment, la livraison "finale" signifie que le message quitte le "monde" SMTP. Normalement, ceci indique que le message a été correctement délivré à son récipiendaire (pas qu'il l'ait lu !) ; dans d'autres cas, le message pourra subir d'autre traitements par d'autres systèmes de courrier locaux.
La boîte-aux-lettres mentionnée dans la route inverse peut être différente de celle de l'émetteur effectif du message, par exemple, lorsque des réponses d'erreur sont routées vers une boîte-aux-lettres commune, spécialement réservée par le système à cet usage.
Les deux paragraphes précédants impliquent que les données de courrier "finales" commencent effectivement par une ligne de route inverse, suivi par une ou plusieurs lignes de marquage temporel. Ces lignes seront immédiatement suivies par l'en-tête de corps de message et le corps de message lui-même [2]. Voir l'exemple 8.
Un cas particulier de réponse doit être développé et des actions supplémentaires envisagées lorsque le traitement suivant la réception de l'indicateur de fin de message n'a pu se dérouler que partiellement. Ceci peut intervenir si, après avoir accepté des récipiendaires et le message, le récepteur-SMTP s'aperçoit qu'il est impossible de délivrer le courrier à certains destinataires, alors que d'autres peuvent être servis sans problème (par exemple, à cause d'un manque de ressources mémoires temporaire). Dans de telles situations, la réponse à une commande DATA doit néanmoins être une réponse OK. Par contre, le récepteur-SMTP doit composer et émettre un message de notification d'erreur à l'émetteur. Celui-ci peut être unique et lister tous les récipiendaires qui n'ont pu recevoir le message, ou peut être multiplié par le nombre de récipiendaires en faute, chaque message constituant une notification d'erreur simple (voir exemple 7). Toutes les notifications d'erreur sont émises via la commande MAIL (même si elles résultent du traitement de commandes SEND, SOML, ou SAML).
Exemple 8 / Exemple de réception de chemin de retour et de marquage temporel
Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA>
Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST
Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST
Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST
Date: 27 Oct 81 15:01:01 PST
From: JOE@ABC.ARPA
Subject: Improved Mailing System Installed
To: SAM@JKL.ARPA
This is to inform you that ...
SEND (SEND)
Cette commande initialise une transaction par laquelle le message doit être envoyé interactivement sur un ou plusieurs terminaux. L'argument mentionne une route inverse. La commande est considérée accomplie avec succès si le message a pu être inscrit sur le terminal.
La route inverse consiste en une liste optionnelle d'hôtes ainsi que la boîte-aux-lettres de l'émetteur. Lorsque la liste d'hôtes est mentionnée, il s'agit d'une route "inversée" qui indique que le courrier a été relayé via chacun des hôtes de la liste (le premier hôte mentionné est le dernier relais par lequel est passé le message). Cette liste est utilisée comme route directe lorsqu'un message d'erreur doit être retourné à l'émetteur. Lorsque chaque relais utilisé ajoute son propre identifiant au début de la liste, le nom ajouté doit être celui qui identifie le relais vis-à-vis du relais suivant plutôt que celui qui l'identifie vis-à-vis de l'émetteur du message (si ces noms sont différents).
Cette commande provoque l'effacement des trois tampons (route inverse, route directe, et message) et initialise le tampon de route inverse avec l'argument fourni.
SEND OR MAIL (SOML)
Cette commande initialise une transaction par laquelle le message doit être envoyé interactivement sur un ou plusieurs terminaux ou boîtes-aux-lettres. Pour chaque récipiendaire, le message est délivré sur le terminal si une session y est ouverte par le destinataire (et celui-ci accepte l'affichage interactif de messages), et par défaut, dans sa boîte-aux-lettres. L'argument mentionne une route inverse. Cette commande est considérée accomplie avec succès si le message est correctement délivré soit sur le terminal, soit dans la boîte-aux-lettres.
La route inverse consiste en une liste optionnelle d'hôtes ainsi que la boîte-aux-lettres de l'émetteur. Lorsque la liste d'hôtes est mentionnée, il s'agit d'une route "inversée" qui indique que le courrier a été relayé via chacun des hôtes de la liste (le premier hôte mentionné est le dernier relais par lequel est passé le message). Cette liste est utilisée comme route directe lorsqu'un message d'erreur doit être retourné à l'émetteur. Lorsque chaque relais utilisé ajoute son propre identifiant au début de la liste, le nom ajouté doit être celui qui identifie le relais vis-à-vis du relais suivant plutôt que celui qui l'identifie vis-à-vis de l'émetteur du message (si ces noms sont différents).
Cette commande provoque l'effacement des trois tampons (route inverse, route directe, et message) et initialise le tampon de route inverse avec l'argument fourni.
SEND AND MAIL (SAML)
Cette commande initialise une transaction par laquelle le message doit être envoyé interactivement sur un ou plusieurs terminaux et simultanément dans les boîtes-aux-lettres associées aux utilisateurs concernés. Pour chaque récipiendaire, le message est délivré sur le terminal si une session y est ouverte par le destinataire (et celui-ci accepte l'affichage interactif de messages), et quelque soit le résultat de l'action précédente, dans sa boîte-aux-lettres. L'argument mentionne une route inverse. Cette commande est considérée accomplie avec succès si le message est au moins délivré dans la boîte-aux-lettres.
La route inverse consiste en une liste optionnelle d'hôtes ainsi que la boîte-aux-lettres de l'émetteur. Lorsque la liste d'hôtes est mentionnée, il s'agit d'une route "inversée" qui indique que le courrier a été relayé via chacun des hôtes de la liste (le premier hôte mentionné est le dernier relais par lequel est passé le message). Cette liste est utilisée comme route directe lorsqu'un message d'erreur doit être retourné à l'émetteur. Lorsque chaque relais utilisé ajoute son propre identifiant au début de la liste, le nom ajouté doit être celui qui identifie le relais vis-à-vis du relais suivant plutôt que celui qui l'identifie vis-à-vis de l'émetteur du message (si ces noms sont différents).
Cette commande provoque l'effacement des trois tampons (route inverse, route directe, et message) et initialise le tampon de route inverse avec l'argument fourni.
RESET (RSET)
Cette commande demande à avorter le traitement de la transaction en cours. Toute donnée d'émetteur, de récipiendaires, et/ou de message, tous les tampons, et tables d'états doivent être effacés. Le récepteur doit émettre une réponse OK.
VERIFY (VRFY)
Cette commande demande au récepteur de confirmer que les arguments fournis désignent bien un utilisateur. S'il s'agit d'un nom d'utilisateur, le nom complet de ce dernier (s'il est connu du récepteur) ainsi que la boîte-aux-lettres totalement qualifiée doivent être renvoyés au requérant.
Cette commande n'affecte aucun des tampons courants de la transaction de courrier.
EXPAND (EXPN)
Cette commande demande au récepteur de confirmer si l'argument associé identifie une liste de diffusion, et, si c'est le cas, de renvoyer la liste des membres de cette liste. Le nom complet des utilisateurs (s'il est connu) et les adresses de boîtes-aux-lettres entièrement qualifiées seront renvoyées via une réponse multilignes.
Cette commande n'affecte aucun des tampons courants de la transaction de courrier.
HELP (HELP)
Cette commande demande au récepteur d'envoyer des informations d'aide à l'émetteur de la commande. Cette commande peut accepter un argument (ex., tout nom de commande). La réponse contient des informations plus détaillées sur cette commande.
Cette commande n'affecte aucun des tampons courants de la transaction de courrier.
NOOP (NOOP)
Cette commande n'affecte aucune donnée ni l'état de la transaction en cours. Il ne demande de la part du récepteur aucune action particulière autre que le renvoi d'une réponse OK.
Cette commande n'affecte aucun des tampons courants de la transaction de courrier.
QUIT (QUIT)
Cette commande demande au récepteur de répondre par OK, puis de fermer le canal de transmission .
Le récepteur ne devra pas lui-même fermer son canal de transmission avant qu'il n'ait reçu la réponse à la commande QUIT qu'il a envoyée (même si une erreur est détectée). L'émetteur ne devra pas plus fermer son canal de transmission sans avoir émis une commande QUIT et reçu une réponse (même s'il a reçu une notification d'erreur à une commande précédente). Si la connexion est fermée prématurément, le récepteur devra agir comme s'il avait reçu une commande RSET (annulant toute transaction en cours, mais sans annuler toute commande précédemment conclue jusqu'à son terme), l'émetteur devra quant à lui réagir comme si la commande active s'était conclue par une erreur (4xx).
TURN (TURN)
Cette commande demande au récepteur de soit, (1) répondre par OK puis prendre le rôle d'un émetteur-SMTP, soit (2) envoyer une réponse de refus et conserver son rôle de récepteur-SMTP.
Si un programme-A est actuellement l'émetteur-SMTP, envoie une commande TURN et reçoit OK en réponse (code 250), alors le programme-A prend le rôle du récepteur-SMTP. Le programme-A se retrouve alors dans le même état initial que lorsque le canal de transmission vient de s'établir, et envoie la réponse 220 indiquant qu'il est prêt à servir.
Si le programme-B est actuellement en position de récepteur-SMTP, reçoit une commande TURN et répond par OK (250), alors le programme-B devient l'émetteur-SMTP. Le programme-B se retrouve alors dans le même état initial que lorsque le canal de transmission vient de s'établir, et s'attend à recevoir le message de code 220.
Le récepteur envoie la réponse 502 pour indiquer qu'il refuse le changement de rôle.
Restrictions sur l'ordre d'apparition des commandes
Il existe des restrictions sur l'ordre dans lequel ces commandes doivent être utilisées.
La première commande d'une session doit toujours être la commande HELO. Cette commande peut quant à elle être réutilisée plus tard dans la même session. Si l'argument associé à la commande HELO ne peut être accepté par le récepteur, une réponse d'erreur 501 doit être renvoyée et le récepteur-SMTP reste dans le même état.
Les commandes NOOP, HELP, EXPN, et VRFY peuvent être utilisées à tout moment dans une session.
Les commandes MAIL, SEND, SOML, ou SAML initialisent une transaction. Une transaction consiste en l'une des commandes d'initialisation de transaction, une ou plusieurs commandes RCPT, et une commande DATA, le tout dan cet ordre précis. Une transaction en cours peut être annulée par la commande RSET. Une session peut traiter zéro ou plus transactions.
Si l'argument de commande d'initialisation de transaction ne peut être accepté par le récepteur, celui-ci répondra par une notification d'erreur de code 501 et restera dans le même état que précédemment. Si une commande est reçue, et que celle-ci déroge à l'ordre précisé ci-avant, une notification d'erreur de code 503 doit être renvoyée, le récepteur-SMTP restant dans le même état.
La dernière commande d'une session doit être la commande QUIT. Cette commande ne peut être utilisée qu'à ce moment d'une session.
4.1.2. SYNTAXE DE COMMANDES
Les commandes consistent en un code de commande suivi d'un champ d'argument. Les codes de commande sont constitués de quatre caractères alphabétiques. Il n'est pas tenu compte de la casse pour le code de commande. Ainsi, les écritures suivantes sont acceptées pour la commande MAIL :
MAIL Mail mail MaIl mAIl
Ceci s'applique également à tout symbole représentant des valeurs d'arguments, telles que "TO" ou "to" pour l'expression de la route. Les codes de commande doivent être séparés du champ d'argument par un ou plus espaces. Cependant, à l'intérieur des expressions de route et de route inverse, la casse devient importante. En particulier, sur certains hôtes, l'utilisateur "smith" est différencié de l'utilisateur "Smith".
Le champ d'argument est constitué d'une chaîne de caractères de longueur variable terminée par la séquence <CRLF>. Le récepteur ne doit pas exécuter d'action tant que cette séquence n'est pas reçue.
Des crochets signalent la présence d'un argument optionnel. Si l'option n'est pas utilisée, une valeur par défaut est prise pour ce paramètre.
Les commandes SMTP sont les suivantes :
HELO <SP> <domaine> <CRLF>
MAIL <SP> FROM:<route-inverse> <CRLF>
RCPT <SP> TO:<route-directe> <CRLF>
DATA <CRLF>
RSET <CRLF>
SEND <SP> FROM:<route-inverse> <CRLF>
SOML <SP> FROM:<route-inverse> <CRLF>
SAML <SP> FROM:<route-inverse> <CRLF>
VRFY <SP> <chaîne> <CRLF>
EXPN <SP> <chaîne> <CRLF>
HELP [<SP> <chaîne>] <CRLF>
NOOP <CRLF>
QUIT <CRLF>
TURN <CRLF>
La syntaxe des champs d'argument ci-dessus (en utilisant la notation BNF lorsqu'elle est applicable) est précisée ci-après. La notation "..." indique que le champ peut être répété plusieurs fois.
<route-inverse> ::= <chemin>
<route-directe> ::= <chemin>
<chemin> ::= "<" [ <a-d-l> ":" ] <bal> ">"
<a-d-l> ::= <at-domaine> | <at-domaine> "," <a-d-l>
<at-domaine> ::= "@" <domaine>
<domaine> ::= <élément> | <élément> "." <domaine>
<élément> ::= <nom> | "#" <nombre> | "[" <adresseIP> "]"
<bal> ::= <partie-locale> "@" <domaine>
<partie-locale> ::= <chaîne-pointée> | <chaîne-quotée>
<nom> ::= <a> <ldh-ch> <alphanum>
<chaîne-hyp> ::= <alphanum-hyp> | <alphanum-hyp> <chaîne-hyp>
<alphanum> ::= <alpha> | <digit>
<alphanum-hyp> ::= <alpha> | <digit> | "-"
<chaîne-pointée> ::= <chaîne> | <chaîne> "." <chaîne-pointée>
<chaîne> ::= <char> | <char> <chaîne>
<chaîne-quotée> ::= """ <texte> """
<texte> ::= "\" <x> | "\" <x> <texte> | <uq> | <uq> <texte>
<xcar> ::= <char> | "\" <x>
<adresseIP> ::= <short> "." <short> "." <short> "." <short>
<nombre> ::= <digit> | <digit> <nombre>
<CRLF> ::= <CR> <LF>
<CR> ::= Le caractère Retour Chariot (ASCII code 13)
<LF> ::= Le caractère Nouvelle Ligne (ASCII code 10)
<SP> ::= Le caractère Espace (ASCII code 32)
<short> ::= un, deux, ou trois digits représentant un
entier décimal de 0 à 255
<alpha> ::= tout caractère parmi les 52 caractères
alphabétiques A à Z (majuscules)
et a à z (minuscules)
<char> ::= any one of the 128 ASCII characters,
but not any <special> or <SP>
<digit> ::= un digit de 0 à 9
<uq> ::= tout caractère parmi les 128 caractères
ASCII sauf <CR>, <LF>, quote ("), ou antislash (\)
<x> ::= tout caractère de l'ASCII (pas d'exceptions)
<special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "." | "," |
";" | ":" | "@" """ | les caractères de contrôle de
l'ASCII (codes 0 à 31 inclus et 127)
Notez que l'antislash, "\", est un caractère d'échappement, utilisé pour indiquer que le caractère qui suit est à interpréter littéralement (au lieu de son interprétation normale). Par exemple, "Joe\,Smith" pourrait être écrit pour indiquer un champ unique de neufs caractères avec la virgule comme quatrième caractère.
Les hôtes sont généralement connus par des noms translatés en adresses réseau dans chaque machine. Notez que les noms issus du système de domaines sont les noms officiels - n'est pas autorisé l'usage de pseudo ou d'alias.
Parfois, un hôte n'est pas connu de la fonction de translation et la communication est bloquée. Pour éviter ce blocage, deux formes numériques sont admises pour l'expression des hôtes. La première forme est un entier décimal préfixé par le symbole dièse "#", qui indique que ce nombre est l'adresse de l'hôte. L'autre forme est une adresse IP d'hôte constituée par quatre entiers compris entre 0 et 255, séparés par des points et "encapsulés" dans des crochets, ex., "[123.255.37.2]", et qui donne une adresse Internet ARPA sur 32 bits. Les lignes de route inverse et de marquage temporel sont formellement définies comme suit :
<ln-route-inverse> ::= "Return-Path:" <SP><route-inverse><CRLF>
<ln-marqueur-temporel>::= "Received:" <SP> <marqueur> <CRLF>
<marqueur> ::= <de-domaine> <par-domaine> <info-opt> ";" <datation>
<de-domaine> ::= "FROM" <SP> <domaine> <SP>
<par-domaine> ::= "BY" <SP> <domaine> <SP>
<info-opt> ::= [<via>] [<avec>] [<id>] [<pour>]
<via> ::= "VIA" <SP> <lien> <SP>
<avec> ::= "WITH" <SP> <protocole> <SP>
<id> ::= "ID" <SP> <chaîne> <SP>
<pour> ::= "FOR" <SP> <chemin> <SP>
<lien> ::= Les noms de liens standard tels qu'ils sont
enregistrés par le Network Information Center.
<protocole> ::= les noms des protocoles standard tels que
définis par le Network Information Center.
<datation> ::= <SP> <date> <SP> <heure>
<date> ::= <dd> <SP> <mois> <SP> <yy>
<heure> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>
<dd> ::= le nombre à un ou deux digits représentant le
quantième du mois entre 1 et 31.
<mois> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
"JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
<yy> ::= les deux derniers chiffres de l'année entre 00 et 99.
<hh> ::= le nombre à deux chiffres indiquant l'heure
du jour entre 00 et 24.
<mm> ::= le nombre à deux chiffres désignat
les minutes entre 00 et 59.
<ss> ::= le nombre à deux chiffres indiquant les
secondes entre 00 et 59.
<zone> ::= "UT" pour Universal Time (par défaut) ou
tout autre identificateur
de zone horaire (comme spécifié dans [2]).
Exemple 9 / Exemple de route inverse
Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:JOE@ABLE.ARPA>
Exemple 10 / Exemple de marquage temporel
Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT
Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25
id M12345 for Smith@PDQ.ARPA ; 22 OCT 81 09:23:59 PDT
4.2. REPONSES SMTP
Les réponses aux commandes SMTP sont instaurées pour la synchronisation des requêtes et actions relatives au processus de transfert de courrier, et pour garantir à tout moment à l'émetteur-SMTP de connaître l'état du récepteur-SMTP. Chaque commande doit générer une réponse et une seule.
Les détails du séquencement des commandes et réponses sont explicités en Sections 4.3 Séquencement et 4.4 Diagrammes d'état.
Une réponse SMTP consiste en un nombre à trois digits (transmis sous forme de trois caractères numériques) suivi d'un texte. Le code numérique est à destination d'automates pour déterminer l'état suivant à atteindre ; la réponse textuelle est plutôt destinée à un utilisateur humain. Il est établi que le code à trois digits contient suffisamment d'information pour que l'émetteur-SMTP n'ait pas à examiner le texte, lequel peut être ignoré ou répercuté au niveau de l'interface utilisateur, selon le cas. En particulier, le texte peut différer selon le récepteur et le contexte, pour un code de réponse donné. Une discussion sur la théorie des codes de réponse est exposée en Appendice E. Au niveau formel, une réponse est définie comme la séquence : un code à trois chiffres, <SP>, une ligne de texte, et <CRLF>, ou éventuellement une réponse multilignes (comme défini dans l'Appendice E). Seules les commandes EXPN et HELP peuvent résulter en des réponses multilignes dans des circonstances normales, bien que par principe, des réponses multilignes soient autorisées pour toutes les commandes.
4.2.1. CODES DE REPONSE PAR GROUPES DE FONCTION
- 500 Erreur de syntaxe, commande non reconnue [y compris des erreurs de type "ligne de commande trop longue"]
- 501 Erreur de syntaxe dans des paramètres ou arguments
- 502 Commande non implémentée
- 503 Mauvaise séquence de commandes
- 504 Paramètre de commande non implémenté
- 211 Etat système, ou réponse d'aide système
- 214 Message d'aide [Informations sur l'utilisation d'un récepteur ou signification d'une commande non standard particulière; en clair pour un opérateur humain]
- 220 <domaine> Service disponible
- 221 <domaine> Canal de transmission en cours de fermeture
- 421 <domaine> Service non disponible, canal en fermeture [Réponse à émettre sur tous les canaux lorsque le système exécute une séquence d'arrêt]
- 250 Action de messagerie effectuée, succès
- 251 Utilisateur non local ; réémission vers <route-directe> (avec relais automatique)
- 450 Action non effectuée : boîte-aux-lettres non disponible [Ex., bloquée par un autre utilisateur]
- 550 Action non effectuée : boîte-aux-lettres non disponible [Ex., boîte-aux-lettres non trouvée, pas d'accès]
- 451 Action arrêtée : erreur de traitement
- 551 Utilisateur non local ; essayer <route> (sans relais automatique)
- 452 Action non effectuée : manque de ressources système
- 552 Action arrêtée : manque de ressources de stockage
- 553 Action non effectuée : nom de boîte-aux-lettres non autorisé [Ex., erreur de syntaxe dans le nom de boîte]
- 354 Début de message ; arrêt par <CRLF>.<CRLF>
- 554 Transaction échouée
4.2.2. CODES REPONSE PAR ORDRE NUMERIQUE
- 211 Etat système, ou réponse d'aide système
- 214 Message d'aide [Informations sur l'utilisation d'un récepteur ou signification d'une commande non standard particulière; en clair pour un opérateur humain]
- 220 <domaine> Service disponible
- 221 <domaine> Canal de transmission en cours de fermeture
- 250 Action de messagerie effectuée, succès
- 251 Utilisateur non local ; réémission vers <route-directe> (avec relais automatique)
- 354 Début de message ; arrêt par <CRLF>.<CRLF>
- 421 <domaine> Service non disponible, canal en fermeture [Réponse à émettre sur tous les canaux lorsque le système exécute une séquence d'arrêt]
- 450 Action non effectuée : boîte-aux-lettres non disponible [Ex., bloquée par un autre utilisateur]
- 451 Action arrêtée : erreur de traitement
- 452 Action non effectuée : manque de ressources système.
- 500 Erreur de syntaxe, commande non reconnue [y compris des erreurs de type "ligne de commande trop longue"]
- 501 Erreur de syntaxe dans des paramètres ou arguments
- 502 Commande non implémentée
- 503 Mauvaise séquence de commandes
- 504 Paramètre de commande non implémenté
- 550 Action non effectuée : boîte-aux-lettres non disponible [Ex., boîte-aux-lettres non trouvée, pas d'accès]
- 551 Utilisateur non local ; essayer <route> (sans relais automatique)
- 552 Action arrêtée : manque de ressources de stockage
- 553 Action non effectuée : nom de boîte-aux-lettres non autorisé [Ex., erreur de syntaxe dans le nom de boîte]
- 554 Transaction échouée.
4.3. SEQUENCEMENT DES COMMANDES ET REPONSES
Les communications entre l'émetteur et le récepteur sont prévues pour suivre un dialogue alterné, sous contrôle de l'émetteur. En temps que tel, l'émetteur envoie une commande à laquelle le récepteur répond. L'émetteur doit attendre cette réponse avant d'envoyer d'autres commandes.
Une réponse importante est l'acquittement des "civilités". Normalement, un récepteur renvoie une réponse 220 "Service disponible" lorsque la connexion est établie. L'émetteur doit attendre ce message avant d'émettre toute autre commande.
Note : tous ces messages de réponse à "civilités" doivent faire figurer le nom officiel de l'hôte hébergeant le récepteur en première place après le code numérique de réponse.
Par exemple,
220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF>
La table ci-après liste les réponses soit positives, soit négatives qui peuvent être attendues après chacune des commandes. Ces règles de séquencement doivent être strictement adoptées ; un récepteur peut changer le texte qu'il ajoute pour expliciter la réponse, mais la séquence de réponse, ainsi que sa signification générale doit être préservée.
4.3.1 SEQUENCES COMANDES-REPONSES
Chaque commande est listée avec toutes ses réponses possibles. Les préfixes utilisés avant les réponses possibles sont "P" pour préliminaire (contexte non utilisé par SMTP), "I" pour intermédiaire, "S" pour succès, "F" pour faute (échec), et "E" pour erreur. La réponse 421 (service non disponible, refermant le canal de transmission) peut être renvoyée suite à toute commande si le récepteur-SMTP sait qu'il doit arrêter son système. La liste suivante sert de base à l'établissement des diagrammes d'état en Section 4.4.
4.3.2 Etablissement de connexion (Implicite)
S: 220
F: 421
4.3.3 HELO
S: 250
E: 500, 501, 504, 421
4.3.4 MAIL
S: 250
F: 552, 451, 452
E: 500, 501, 421
4.3.5 RCPT
S: 250, 251
F: 550, 551, 552, 553, 450, 451, 452
E: 500, 501, 503, 421
4.3.6 DATA
I: 354 -> data -> S: 250
F: 552, 554, 451, 452
F: 451, 554
E: 500, 501, 503, 421
4.3.7 RSET
S: 250
E: 500, 501, 504, 421
4.3.8 SEND
S: 250
F: 552, 451, 452
E: 500, 501, 502, 421
4.3.9 SOML
S: 250
F: 552, 451, 452
E: 500, 501, 502, 421
4.3.10 SAML
S: 250
F: 552, 451, 452
E: 500, 501, 502, 421
4.3.11 VRFY
S: 250, 251
F: 550, 551, 553
E: 500, 501, 502, 504, 421
4.3.12 EXPN
S: 250
F: 550
E: 500, 501, 502, 504, 421
4.3.13 HELP
S: 211, 214
E: 500, 501, 502, 504, 421
4.3.14 NOOP
S: 250
E: 500, 421
4.3.15 QUIT
S: 221
E: 500
4.3.16 TURN
S: 250
F: 502
E: 500, 503
4.4. DIAGRAMMES D'ETATS
Ci-après sont exposés les diagrammes d'état pour ce qui constituerait une implémentation SMTP "légère". Seul le premier digit du code réponse est exploité. Un diagramme d'état correspond à un groupe de commandes SMTP. Le regroupement des commandes a été fait en construisant un modèle pour chaque commande, puis en réunissant les commandes de même modèle structurel.
Pour chacune des commandes, on définit trois issues possibles : "succès" (S), "faute (échec)" (F), et "erreur" (E). Les diagrammes d'états utilisent le symbole B pour "début" (begin), et le symbole W pour "attendre la réponse" (wait for answer).
Est exposé tout d'abord le diagramme représentant la plupart des commandes SMTP :
1,3 +---+
----------->| E |
| +---+
|
+---+ cmd +---+ 2 +---+
| B |---------->| W |---------->| S |
+---+ +---+ +---+
|
| 4,5 +---+
----------->| F |
+---+
Ce diagramme correspond aux commandes :
HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP, NOOP, QUIT, TURN.
Un diagramme plus complexe modélise la commande DATA :
+---+ DATA +---+ 1,2 +---+
| B |---------->| W |-------------------->| E |
+---+ +---+ ------------>+---+
3| |4,5 |
| | |
-------------- ----- |
| | | +---+
| ---------- -------->| S |
| | | | +---+
| | ------------
| | | |
V 1,3| |2 |
+---+ données +---+ --------------->+---+
| |---------->| W | | F |
+---+ +---+-------------------->+---+
4,5
Notez que les "données" sont ici une série de lignes envoyées par l'émetteur au récepteur sans qu'une réponse ne soit attendue avant la fin de la dernière ligne.
4.5. DETAILS
4.5.1. IMPLEMENTATION MINIMALE
Pour qu'une implémentation de SMTP puisse fonctionner, les récepteurs devront au minimum reconnaître les commandes suivantes :
COMMANDS -- HELO
MAIL
RCPT
DATA
RSET
NOOP
QUIT
4.5.2. PRINCIPE DE TRANSPARENCE
Sans aucun mécanisme destiné à préserver la transparence des données, la séquence de caractères "<CRLF>.<CRLF>" termine le texte du message et ne peut donc être envoyée littéralement par l'utilisateur. En général, les utilisateurs ne sont pas informés de l'existence de telles séquences "interdites". Pour permettre que tout texte d'un utilisateur quelconque puisse être transmis de manière transparente, on suivra les procédures suivantes.
- Avant d'envoyer une ligne du texte du message, l'émetteur-SMTP analyse le premier caractère de la ligne. S'il s'agit d'un point, ce point est doublé.
- Lorsqu'une ligne de texte est reçue par le récepteur-SMTP, ce dernier analyse la ligne. Si la ligne ne contient qu'un point unique, alors il s'agit de l'identificateur de fin de message. Si le premier caractère est un point, et que d'autres caractères suivent sur la même ligne, alors ce premier point est supprimé.
Le texte du message peut être composé avec les 128 premiers caractères du code ASCII. Tous les caractères sans exception doivent être recopiés dans la boîte-aux-lettres y compris des caractères de contrôle de format ou autres contrôles. Si le canal de transmission propose un mode de transmission étendu à 8 bits (canal binaire), les codes en 7 bits de l'ASCII sont transmis justifiés à droite (dans l'octet) avec le premier bit (poids forts) forcé à zéro.
Sur certains systèmes, il peut être nécessaire d'opérer une transformation sur les données au moment où elles sont reçues et enregistrées. Ceci peut être nécessaire pour des hôtes qui utilisent un jeu de caractères différent de l'ASCII pour la représentation locale des données, ou qui enregistrent les données sous forme d'enregistrements plutôt que sous forme de chaînes de caractères. Si de telles transformations sont nécessaires, alors elles doivent être réversibles - et surtout si les courriers ainsi traités doivent être relayés vers d'autres destinations.
4.5.3. TAILLES
Un certain nombre d'objets de données ont des tailles minimales et maximales définies. C'est-à-dire, toute implémentation doit s'attendre à recevoir des objets d'au moins la taille minimale, mais ne doit elle-même pas envoyer d'objets d'une taille supérieure à la taille maximale.
****************************************************
* *
* POUR UNE ADAPTABILITE OPTIMALE, LES TECHNIQUES *
* D'IMPLEMENTATION QUI N'IMPOSENT PAS DE LIMITES *
* SUR LA TAILLE DE CES OBJETS SONT PREFEREES. *
* *
****************************************************
Nom d'utilisateur
La longueur totale maximale d'un nom d'utilisateur est de 64 caractères.
Nom de domaine
La longueur totale maximale d'un nom de domaine est de 64 caractères.
Routes
La longueur maximale des routes et routes inverses est de 256 caractères chacune (y compris la ponctuation et les séparateurs d'éléments).
Ligne de commande
La longueur totale maximale de la ligne de commande, incluant le code de commande et le <CRLF> final est de 512 caractères.
Ligne de réponse
La longueur totale maximale de la ligne de réponse, incluant le code de réponse et le <CRLF> final est de 512 caractères.
Ligne de texte (corps de message)
La longueur maximale d'une ligne de texte y compris le <CRLF> final est de 1000 caractères (le point dupliqué en tête de ligne pour assurer le principe de transparence n'est pas compté).
Tampon des récipiendaires
Le nombre maximal de récipiendaires à enregistrer pour une transaction est fixé à 100.
****************************************************
* *
* POUR UNE ADAPTABILITE OPTIMALE, LES TECHNIQUES *
* D'IMPLEMENTATION QUI N'IMPOSENT PAS DE LIMITES *
* SUR LA TAILLE DE CES OBJETS SONT PREFEREES. *
* *
****************************************************
Des erreurs dues au dépassement des limites ci-dessus peuvent être reportées en utilisant les extensions de réponses suivantes :
500 Ligne trop longue.
501 Chemin trop long
552 Trop de récipiendaires.
552 Message trop long.
Crédits : J. Postel / ISI
Traduction : Valéry Frémaux / EISTI
Edition originale : Août 1982. Version FR : Avril 1998
Remplace : RFC 788, 780, 772
|