RFC du protocole SMTP : appendice E

ap5.1 Théorie des codes de réponse

Les trois digits du code de réponse ont chacun leur signification particulière. Le premier digit qualifie globalement le sens de la réponse, en indiquant si elle est positive, négative ou incomplète. Un émetteur-SMTP simpliste pourra déterminer la prochaine action à faire (exécuter comme prévu, refaire, se replier, etc.) par la simple analyse de ce premier chiffre. Un émetteur-SMTP qui souhaite connaître la cause approximative de d'une erreur (ex., erreur du système de messagerie, erreur de syntaxe de commande) pourra examiner le second digit, le troisième étant réservé pour une analyse très fine.

Le premier digit peut prendre cinq valeurs :

1yz Réponse positive préliminaire

La commande a été acceptée, mais l'action a effectuer a été mise en attente, par exemple de confirmation de l'information fournie dans cette réponse. Un émetteur-SMTP devrait dans ce cas émettre une nouvelle fois la commande pour confirmer son exécution.

Note : SMTP ne connaît aucune commande qui admette ce type de réponse, et de ce fait ne dispose d'aucune commande Continue ou Abort.

2yz Réponse positive définitive

L'action demandée a été entièrement exécutée avec succès. Une nouvelle commande peut être reçue.

3yz Réponse positive intermédiaire

La commande a été acceptée, mais le traitement est mis en attente de réception d'information complémentaire. Un émetteur-SMTP devrait émettre une nouvelle commande pour apporter le complément d'information attendu. Cette réponse est utilisée pour de groupes de séquences de commandes.

4yz Réponse négative temporaire

La commande n'a pas été acceptée et l'action n'a pas eu lieu. Cependant, la condition d'erreur est temporaire, indiquant que la requête peut être présentée à nouveau. L'émetteur-SMTP devra, dans le cas de commandes groupées en séquence recommencer l'intégralité de la séquence de commandes. Il est difficile de donner une définition précise de ce que signifie "temporaire" dans la mesure où les deux sites (récepteur et émetteur) doivent s'accorder sur cette interprétation. Chacune des réponses de cette catégorie peuvent jouer avec des notions de temps assez différentes. Néanmoins, l'émetteur est encouragé à essayer de nouveau la commande. Une règle pratique pour déterminer si une réponse doit être associée à la classe 4yz ou 5yz (vois ci-dessous) est la suivante : une réponse sera de catégorie 4yz si la commande, répétée à l'identique, et sans aucun changement de configuration ou de paramètres de l'émetteur ou du récepteur, peut aboutir sous cette forme.

5yz Réponse négative définitive

La commande n'a pas été acceptée et l'action n'a pas eu lieu. Cette classe de réponses décourage l'émetteur-SMTP de répéter la commande sous sa forme actuelle (dans la même séquence). Certaines conditions dites permanentes d'erreur peuvent néanmoins être corrigées, et l'utilisateur humain pourra alors redéclencher la séquence de commandes par action manuelle, lorsque la cause d'erreur aura disparu (ex., après avoir corrigé une dysorthographie, ou avoir manipulé les paramètres de configuration).

Le second digit précise la réponse dans chacune des catégories :

x0z Syntaxe -

Cette série de réponse s'intéresse plus particulièrement aux erreurs de syntaxes, aux commandes syntaxiquement correctes mais qui n'ont pas de signification sémantique, ou commandes superflues ou non implémentées.

x1z Information -

Qualifie des réponses à des demandes d'information, telles que l'aide ou un état.

x2z Connexions -

Qualifie les réponses afférentes au canal de transmission.

x3z Non spécifié.

x4z Non spécifié.

x5z Système de messagerie -

Ces réponses qualifient l'état du service de messagerie côté récepteur pour le transfert demandé ou pour toute autre action système.

Le troisième digit permet d'effectuer une distinction encore plus fine dans chacune des catégories définies par l'usage des deux premiers digits. La liste des réponses prédéfinies illustre ce fait.

Les textes associés aux réponses sont des textes préconisés, mais pas imposés, et peuvent éventuellement changer suivant la commande à l'origine de la réponse. A l'opposé, les codes de réponse doivent strictement suivre les spécifications. Les implémentations de récepteurs devront se garder d'inventer des nouveaux codes pour répondre à des situations légèrement différentes que celles présentées ici, et devront se limiter à adapter les codes prédéfinis.

Par exemple, une commande telles que NOOP dont l'exécution complète ne fournit à l'émetteur-SMTP aucune information nouvelle, renverra une réponse de code 250. La réponse sera de code 502 lorsque la commande demande d'exécuter une action non implémentée, et indépendante du site. Une réponse 504 sera donnée pour une commande implémentée, mais associée à un paramètre non implémenté.

Le texte de réponse peut être plus long qu'une simple ligne ; dans ce cas, le texte complet doit être formaté pour que l'émetteur-SMTP sache jusqu'à quel point il doit prendre en compte la réponse. Ceci nécessite l'usage d'un format particulier pour les réponses multilignes.

Le format des réponses multilignes demande que chaque ligne, sauf la dernière, commence par le code de réponse, immédiatement suivi du caractère Hyphénation, "-" (moins), le texte sur la ligne étant placé à la suite. La dernière ligne commencera aussi par le code de réponse, mais immédiatement suivi d'un espace <SP>, éventuellement la fin du texte de réponse, et enfin <CRLF>.

Par exemple :

 123-Première ligne
 123-Deuxième ligne
 123-234 texte commençant par des nombres
 123 La dernière ligne

Dans de nombreux cas, l'émetteur-SMTP n'aura qu'à rechercher le code de réponse suivi d'un <SP> au début d'une ligne, et pourra ignorer toutes les lignes précédantes. Dans quelques uns des autres cas, des informations d'importance pour l'émetteur peuvent figurer dans le "texte". L'émetteur connaît ces cas suivant le contexte.