Groupe de travail Réseau	G. Vaudreuil	
Request for Comments : 3463	Lucent Technologies	
RFC rendue obsolète : 1893	janvier 2003	
Catégorie : En cours de normalisation	Traduction Claude Brière de L'Isle	

Codes d'état améliorés du système de messagerie

Statut du présent mémoire
Le présent document spécifie un protocole de normalisation Internet pour la communauté Internet, et appelle à discussion et suggestions en vue de son amélioration. Prière de se rapporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Déclaration de copyright
Copyright (C) The Internet Society (2003). Tous droits réservés

Résumé
Le présent document définit un ensemble de codes d'état étendu à utiliser avec le système de messagerie pour les rapports d'état de livraison, le traçage, et l'amélioration des diagnostics. En les combinant avec les autres informations fournies dans le rapport de livraison de la notation d'état de livraison (DSN, Delivery Status Notification) ces codes facilitent une restitution de l'état de livraison du message indépendante du support et du langage.

Table des Matières

1.	Généralités
2.	Structure des codes d'état
3.	Description des codes d'état
3.1	État autre ou indéfini
3.2	État d'adresse
3.3	État de boîte aux lettres
3.4	État de système de messagerie
3.5	État du réseau et de l'acheminement
3.6	État du protocole de livraison de la messagerie
3.7	État du contenu du message ou du support du message
3.8	État de la sécurité ou de la politique
4.	Références normative
5.	Considérations pour la sécurité
Appendice A – Récapitulation des codes d'état
Appendice B - Changements par rapport à la RFC1893
Adresse de l'auteur
Déclaration complète de droits de reproduction

1.	Généralités

Il y a besoin pour le rapport des erreurs du système de messagerie d'un mécanisme standard qui soit plus riche que l'ensemble limité offert par SMTP et les descriptions textuelles spécifiques des systèmes envoyées dans les messages électroniques. Il y a un pressant besoin de codes d'état plus riches, lisibles par la machine, indépendants des langages humains, utilisables pour les notifications d'état de livraison [DSN]. Le présent document propose à cette fin un nouvel ensemble de codes d'état.

Les codes d'erreur [SMTP] ont historiquement été utilisés pour le rapport des erreurs des systèmes de messagerie. À cause des limitations de la conception du code SMTP, ceux-ci ne conviennent pas pour une utilisation dans les notifications d'état de livraison. SMTP fournit environ 12 codes utiles pour les rapports de livraison. La majorité des codes sont des codes de réponse spécifiques du protocole tels que la réponse 354 à la commande de données SMTP. Chacun des douze codes utiles est surchargé pour indiquer plusieurs conditions d'erreur. SMTP a souffert de plusieurs atteintes dans son histoire, dont la plus notable est le dommage infortuné causé au mécanisme d'extension du code de réponse par une utilisation incontrôlée. La présente proposition facilite l'extensibilité future en exigeant que le client interprète les codes d'erreur inconnus conformément à la théorie des codes tout en exigeant des serveurs qu'ils enregistrent les nouveaux codes de réponse.

La théorie SMTP des codes de réponse partage l'espace des nombres de telle manière que les codes restant disponibles ne fournissent pas l'espace nécessaire. L'exemple le plus critique en est l'existence de seulement cinq codes restants pour les erreurs du système de messagerie. La classification du système de messagerie comporte des conditions d'erreur à la fois pour les hôtes et les boîtes aux lettres. L'espace à trois chiffres restant serait complètement consommé pour indiquer les erreurs MIME et de conversion de support et les erreurs de système de sécurité.

Une révision de la théorie SMTP des codes de réponse pour mieux répartir les conditions d'erreur dans l'espace des nombres sera nécessairement incompatible avec SMTP. De plus, la consommation de l'espace des nombres de code de réponse restant pour les rapports de notification de livraison va réduire les codes disponibles pour de nouvelles extensions ESMTP.

L'ensemble de codes d'état suivant se fonde sur la théorie SMTP des codes de réponse. Il adopte la sémantique de réussite, d'erreur permanente, et d'erreur transitoire de la première valeur, avec une description et une classification plus complète dans la seconde. Cette proposition redistribue les classifications pour mieux répartir les conditions d'erreur, comme de séparer les erreurs de boîte aux lettres des erreurs d'hôte.

Conventions du document
Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [RFC 2119].

2.	Structure des codes d'état

Le présent document définit un nouvel ensemble de codes d'état pour faire rapport des conditions du système de messagerie. Ces codes d'état sont utilisés pour des rapports d'état indépendants du support et du langage. Ils ne sont pas destinés aux diagnostics spécifiques du système.

La syntaxe des nouveaux codes d'état est définie comme :

code-d'état = classe "." sujet "." détail

classe = "2"/"4"/"5"

sujet = 1*3chiffres

détail = 1*3chiffres

Les caractères d'espace blanche et les commentaires NE SONT PAS admis au sein d'un code-d'état. Chaque sous code numérique au sein du code-d'état DOIT être exprimé sans chiffre commençant par un ou des zéros.

Un code d'état consiste en trois champs numériques séparés par ".". Le premier sous-code indique si la tentative de livraison a été un succès. Le second sous-code indique la source probable d'une anomalie de livraison, et le troisième sous-code indique une condition d'erreur précise.

Exemple :  2.1.23

L'espace de codes défini est destiné à n'être étendu que par des documents de normalisation. Les codes d'état spécifiques des systèmes de messagerie devraient être transposés aussi proches que possible des codes d'état standard. Les serveurs devraient n'envoyer que des codes d'état définis et enregistrés. Les erreurs spécifiques des système et les diagnostics devraient être portés par des moyens autres que les codes d'état.

De nouveaux codes de sujets et de détails seront ajoutés à l'avenir. Comme l'espace de nombres est grand, il n'est pas prévu que les codes d'état publiés soient redéfinis ou éliminés. Les clients devraient préserver l'extensibilité de l'espace des codes en faisant rapport des erreurs générales décrites dans les sous-codes de sujet lorsque le détail spécifique n'est pas reconnu.

Le sous-code de classe donne une classification large de l'état. les valeurs énumérée pour chaque classe sont définies comme :

2.XXX.XXX : Succès
Le succès spécifie que le DSN rapporte une action de livraison positive. Les sous-codes de détails peuvent fournir la notification de transformations exigées pour la livraison.

4.XXX.XXX : Défaillance transitoire persistante
Une défaillance transitoire persistante est celle dans laquelle le message envoyé est valide, mais la persistance de certaines conditions temporaires a causé l'abandon ou le retard d'une tentative d'envoi du message. Si ce code accompagne un rapport d'échec de livraison, un envoi futur pourrait réussir.

5.XXX.XXX : Défaillance permanente
Une défaillance permanente est celle qui a peu de chances d'être résolue par un nouvel envoi du message dans la forme actuelle. Certains changements au message ou à la destination doivent être faits pour la réussite de la livraison.

Un client doit reconnaître et rapporter les sous-codes de classe même lorsque les sous-codes de sujet suivants ne sont pas reconnus.

Le sous-code de sujet classe l'état. Cette valeur s'applique à chacune des trois classifications. Le sous-code de sujet, si il est reconnu, doit être rapporté même si le détail supplémentaire fourni par le sous-code de détail n'est pas reconnu. Les valeurs énumérées pour le sous-code de sujet sont :

X.0.XXX ; autre état ou état indéfini
Il n'y a pas d'information supplémentaire de sujet disponible.

X.1.XXX : état d'adressage
L'état d'adressage fait rapport sur l'adresse d'origine ou de destination. Il peut inclure la syntaxe ou la validité de l'adresse. Ces erreurs peuvent généralement être corrigées par l'envoyeur et réessayées.

X.2.XXX : état de boîte aux lettres
L'état de boîte aux lettres indique que quelque chose qui a à voir avec la boîte aux lettre a causé cette DSN. Les questions de boite aux lettres sont supposées être sous la responsabilité générale du receveur.

X.3.XXX : état du système de messagerie
L'état du système de messagerie indique que quelque chose qui a à voir avec le système de destination a causé cette DSN. Les questions de système sont supposées être sous la responsabilité générale de l'administrateur du système de destination.

X.4.XXX : état du réseau et de l'acheminement
Les codes de réseautage ou d'acheminement rapportent des états sur le système de livraison lui-même. Ces composants de système incluent toute infrastructure nécessaire telle que les services d'annuaire et d'acheminement. Les questions de réseau sont supposées être sous la responsabilité de l'administrateur de système de destination ou de système intermédiaire.

X.5.XXX : état du protocole de livraison de messagerie
Les codes d'état du protocole de livraison de messagerie rapportent les défaillances qui impliquent le protocole de livraison de message. Ces défaillances incluent toute la gamme des problèmes qui résultent d'erreurs de mise en œuvre ou d'une connexion non fiable.

X.6.XXX : état du contenu du message ou du support
Les codes d'état du contenu du message ou du support rapportent les défaillances qui impliquent le contenu du message. Ces codes rapportent les défaillances dues à la traduction, au transcodage, ou aux autres supports de message non acceptés. Les questions de contenu du message ou du support sont de la responsabilité de l'envoyeur et du receveur, qui doivent tous deux prendre en charge un ensemble commun de types de contenus.

X.7.XXX : état de la sécurité ou de la politique
Les codes d'état de sécurité ou de politique rapportent les défaillances qui impliquent des politiques comme le filtrage selon le receveur ou selon l'hôte et les opérations cryptographiques. Les questions d'état de la sécurité ou de la politique sont supposées être de la responsabilité de l'envoyeur et/ou du receveur. Tous deux doivent permettre l'échange des messages et arranger l'échange des clés et certificats nécessaires pour les opérations cryptographiques.

3.	Description des codes d'état

La section suivante définit et décrit les sous codes détaillés. La valeur détaillée donne plus d'informations sur l'état et est définie par rapport au sujet de l'état.

3.1	État autre ou indéfini

X.0.0  : Autre état indéfini
Autre état indéfini est le seul code d'erreur indéfinie. Il devrait être utilisé pour toutes les erreurs pour lesquelles seule la classe de l'erreur est connue.

3.2	État d'adresse

X.1.0 :  Autre état d'adresse
Quelque chose concernant l'adresse spécifiée dans le message a causé cette DSN.

X.1.1 : Mauvaise adresse de boîte aux lettres de destination
La boîte aux lettres spécifiée dans l'adresse n'existe pas. Pour les noms de la messagerie Internet, cela signifie que la portion d'adresse de la partie gauche du signe "@" est invalide. Ce code n'est utile que pour les défaillances permanentes.

X.1.2 : Mauvaise adresse de système de destination
Le système de destination spécifié dans l'adresse n'existe pas ou est incapable d'accepter le message. Pour les noms de la messagerie Internet, cela signifie que la portion d'adresse à droite du signe "@" est invalide pour la messagerie. Ce code n'est utile que pour des défaillances permanentes.

X.1.3 : Mauvaise syntaxe d'adresse de boîte aux lettres de destination
L'adresse de destination est syntaxiquement invalide. Cela peut s'appliquer à tout champ de l'adresse. Ce code n'est utile que pour les défaillances permanentes.

X.1.4 : Adresse de boîte aux lettres de destination ambiguë
L'adresse de boîte aux lettres telle que spécifiée correspond à un ou plusieurs receveurs sur le système de destination. Cela peut arriver si un algorithme heuristique de transposition d'adresse est utilisé pour transposer l'adresse spécifiée en un nom de boîte aux lettres local.

X.1.5 : Adresse de destination valide
Cette adresse de boîte aux lettre est valide telle qu'elle a été spécifiée. Ce code d'état devrait être utilisé pour les rapports de livraison positifs.

X.1.6 : La boîte aux lettres de destination a été déplacée. Pas d'adresse de retransmission
L'adresse de boîte aux lettres fournie a été valide, mais la messagerie n'est plus acceptée pour cette adresse. Ce code n'est utile que pour des défaillances permanentes.

X.1.7 : Mauvaise syntaxe d'adresse de boîte aux lettres de l'envoyeur
L'adresse de l'envoyeur est syntaxiquement invalide. Cela peut s'appliquer à tout champ dans l'adresse.

X.1.8 : Mauvaise adresse système de l'envoyeur
Le système de l'envoyeur spécifié dans l'adresse n'existe pas ou est incapable d'accepter le message retourné. Pour les noms de domaines, cela signifie que la portion d'adresse à la droite du signe "@" est invalide pour la messagerie.

3.3	État de boîte aux lettres

X.2.0 : État de boîte aux lettres autre ou indéfini
La boîte aux lettres existe, mais quelque chose concernant la boîte aux lettres de destination a causé l'envoi de cette DSN.

X.2.1 : Boîte aux lettres désactivée, n'accepte pas les messages
La boîte aux lettres existe, mais n'accepte pas les messages. Cela peut être une erreur permanente si la boîte aux lettre ne sera jamais réactivée ou erreur temporaire si la boîte aux lettres est seulement temporairement désactivée.

X.2.2 : Boîte aux lettres pleine
La boîte aux lettres est pleine parce que l'utilisateur a dépassé un quota administratif pour la boîte aux lettres ou une capacité physique. La sémantique générale implique que le receveur puisse supprimer les messages pour faire de la place. Ce code devrait être utilisé comme défaillance temporaire persistante.

X.2.3 : La longueur du message excède une limite administrative
Une limite de longueur de message fixée administrativement pour la boîte aux lettres a été dépassée. Ce code d'état devrait être utilisé lorsque la limite de longueur de message pour la boîte aux lettres est inférieure à la limite générale du système. Ce code devrait être utilisé comme défaillance permanente.

X.2.4 : Problème d'expansion de liste de diffusion
La boîte aux lettres est une adresse de liste de diffusion et la liste de diffusion n'a pas pu être développée. Ce code peut représenter une défaillance permanente ou une défaillance temporaire persistante.

3.4	État de système de messagerie

X.3.0 : Autre état de système de messagerie ou état indéfini
Le système de destination existe et accepte normalement les messages, mais quelque chose concernant le système a causé la génération de cette DSN.

X.3.1 : Système de messagerie plein
La capacité mémoire du système de messagerie est dépassée. La sémantique générale implique que le receveur individuel n'est pas capable de supprimer des messages pour faire de la place pour des messages supplémentaires. Ceci n'est utile que comme erreur transitoire persistante.

X.3.2 : Le système n'accepte pas les messages réseau
L'hôte sur lequel réside la boîte aux lettres n'accepte pas les messages. Des exemples de telles conditions incluent une fermeture imminente, une charge excessive, ou la maintenance du système. Ceci est utile pour des erreurs aussi bien permanentes que transitoires persistantes.

X.3.3 : Le système n'a pas la capacité des caractéristiques sélectionnées
Les caractéristiques choisies spécifiées pour le message ne sont pas prises en charge par le système de destination. Cela peut survenir dans les passerelles lorsque les caractéristiques d'un domaine ne peuvent pas être transposées en caractéristiques prises en charge dans un autre domaine.

X.3.4 : Message trop gros pour le système
Le message est plus grand que la limite de taille par message. Cette limite peut être pour des raisons physiques ou administratives. Ceci n'est utile que comme erreur permanente.

X.3.5 : Système incorrectement configuré
Le système n'est pas configuré d'une manière qui lui permette d'accepter ce message.

3.5	État du réseau et de l'acheminement

X.4.0 : Autre état de réseau ou d'acheminement indéfini
Quelque chose ne va pas dans le réseau, mais le nature du problème n'apparaît pas clairement, ou le problème ne peut pas être bien exprimé par un autre des codes de détail fournis.

X.4.1 : Pas de réponse de l'hôte
La tentative de connexion sortante na pas reçu de réponse, soit parce que le système distant était occupé, soit parce qu'il est incapable de prendre un appel. Ceci n'est utile que comme erreur transitoire persistante

X.4.2 : Mauvaise connexion
La connexion sortante a été établie, mais a été incapable d'achever la transaction, soit à cause de l'arrivée à expiration d'une temporisation, soit à cause d'une qualité inadéquate de la connexion. Ceci n'est utile que comme erreur transitoire persistante

X.4.3 : Défaillance du serveur d'annuaire
Le système réseau a été incapable de transmettre le message, parce qu'un serveur d'annuaire était indisponible. Ceci n'est utile que comme erreur transitoire persistante L'incapacité à se connecter à un serveur DNS de l'Internet est un exemple de l'erreur de défaillance de serveur d'annuaire.

X.4.4 : Incapable d'acheminer
Le système de messagerie a été incapable de déterminer le prochain bond pour le message parce que les informations d'acheminement nécessaires étaient indisponibles auprès du serveur d'annuaire. Ceci est utile aussi bien pour les erreurs permanentes que les erreurs transitoires persistantes Une recherche de DNS ne retournant qu'un enregistrement de SOA (Start of Administration) pour un nom de domaine est un exemple de l'erreur Incapable d'acheminer.

X.4.5 : Encombrement du système de messagerie
Le système de messagerie a été incapable de délivrer le message à cause de l'encombrement du système de messagerie. Ceci n'est utile que comme erreur transitoire persistante

X.4.6 : Détection d'une boucle d'acheminement
Un bouclage d'acheminement a causé la retransmission du message un trop grand nombre de fois, soit à cause de tableaux d'acheminement incorrects, soit d'une boucle de transmission d'usager. Ceci n'est utile que comme erreur transitoire persistante

X.4.7 : Expiration du délai de livraison
Le message a été considéré comme trop vieux par le système qui le rejette, soit parce qu'il est resté trop longtemps sur cet hôte, soit parce que la valeur de sa durée de vie spécifiée par l'envoyeur du message a été dépassée. Si possible, le code pour le vrai problème trouvé lors de la tentative de livraison devrait être retourné plutôt que ce code.

3.6	État du protocole de livraison de la messagerie

X.5.0 : Autre état de protocole ou protocole indéfini
Quelque chose ne va pas avec le protocole nécessaire pour livrer le message au prochain bond et le problème ne peut pas être bien exprimé avec un autre des codes de détail fournis.

X.5.1 : Commande invalide
Une commande du protocole de transaction de messagerie a été produite qui était soit hors séquence soit non prise en charge. Ceci n'est utile que comme erreur permanente.

X.5.2 : Erreur de syntaxe
Une commande du protocole de transaction de messagerie a été produite qui n'a pas pu être interprétée, soit à cause d'une erreur de syntaxe, soit de la commande qui n'est pas reconnue. Ceci n'est utile que comme erreur permanente.

X.5.3 : Receveurs trop nombreux
Plus de receveurs ont été spécifié pour le message qu'il ne peut en être livré par le protocole. Cette erreur devrait normalement résulter en la segmentation du message en deux, le reste des receveurs étant livrés sur une tentative de livraison ultérieure. Il est inclus dans cette liste pour le cas où une telle segmentation n'est pas possible.

X.5.4 : Arguments de commande invalides
Une commande valide du protocole de transaction de messagerie a été produite avec des arguments invalides, soit parce que les arguments étaient hors gamme, soit qu'ils représentent des caractéristiques non reconnues. Ceci n'est utile que comme erreur permanente.

X.5.5 : Mauvaise version du protocole
Une discordance de version de protocole existait qui n'a pas pu être automatiquement résolue par les parties à la communication.

3.7	État du contenu du message ou du support du message

X.6.0 : Erreur de support autre ou indéfinie
Quelque chose concernant le contenu d'un message a fait qu'il est considéré comme non livrable et le problème ne peut pas être bien exprimé par un autre des codes de détail fournis.

X.6.1 : Support non accepté
Le support du message n'est pas pris en charge par le protocole de livraison ou par le prochain système sur le chemin de transmission. Ceci n'est utile que comme erreur permanente.

X.6.2 : Conversion exigée et interdite
Le contenu du message doit être converti avant qu'il puisse être livré et une telle conversion n'est pas permise. Une telle interdiction peut être l'expression de l'envoyeur dans le message lui-même ou la politique de l'hôte d'envoi.

X.6.3 : Conversion exigée mais non acceptée
Le contenu du message doit être converti afin d'être transmis mais une telle conversion n'est pas possible ou ne peut être pratiquée par un hôte dans le chemin de transmission. Cette condition peut survenir lorsque une passerelle ESMTP accepte le transport à 8 bits mais n'est pas capable de rétrograder le message à 7 bits comme exigé par le prochain bond.

X.6.4 : Conversion effectuée avec pertes
Ceci est un avertissement retourné à l'envoyeur lorsque la livraison du message est réussie mais que la livraison exigeait une conversion dans laquelle des données ont été perdues. Cela peut aussi être une erreur permanente si l'envoyeur a indiqué que la conversion avec pertes est interdite pour le message.

X.6.5 : Échec de conversion
Une conversion était exigée mais n'a pas réussi. Cela peut être utile comme notification permanente ou temporaire persistante

3.8	État de la sécurité ou de la politique

X.7.0 : État de sécurité autre ou indéfini
Quelque chose en rapport avec la sécurité a causé le retour du message, et le problème ne peut pas être bien exprimé avec un autre des codes de détail fournis. Ce code d'état peut aussi être utilisé lorsque la condition ne peut pas être mieux décrite à cause des politiques de sécurité en vigueur.

X.7.1 : Livraison non autorisée, message refusé
L'envoyeur n'est pas autorisé à envoyer à la destination. Cela peut être le résultat d'un filtrage selon l'hôte ou selon le receveur. Le présent mémoire ne discute pas les mérites de tels filtrages, mais donne un mécanisme pour en faire rapport. Ceci n'est utile que comme erreur permanente.

X.7.2 : Expansion de liste de diffusion interdite
L'envoyeur n'est pas autorisé à envoyer un message à la liste de diffusion prévue. Ceci n'est utile que comme erreur permanente.

X.7.3 : Conversion de sécurité exigée mais impossible
Une conversion d'un protocole de messagerie sécurisé à un autre était exigée pour la livraison et une telle conversion était impossible. Ceci n'est utile que comme erreur permanente.

X.7.4 : Caractéristiques de sécurité non prises en charge
Un message contenait des caractéristiques de sécurité telles qu'une authentification sécurisée qui n'a pas pu être assurée sur le protocole de livraison. Ceci n'est utile que comme erreur permanente.

X.7.5 : Échec cryptographique
Un système de transport par ailleurs autorisé à valider ou déchiffrer un message dans le transport a été incapable de le faire parce que les informations nécessaires, telles que des clés, n'étaient pas disponibles ou que de telles informations étaient invalides.

X.7.6 : Algorithme de chiffrement non pris en charge
Un système de transport par ailleurs autorisé à valider ou déchiffrer un message a été incapable de le faire parce que l'algorithme nécessaire n'était pas pris en charge.

X.7.7 : Échec d'intégrité du message
Un système de transport par ailleurs autorisé à valider ou déchiffrer un message a été incapable de le faire parce que le message était corrompu ou altéré. Cela peut être utile comme code permanent, transitoire persistent, ou de livraison réussie.

4.	Références normative 

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[SMTP]	J. Postel, "Protocole simple de transfert de messagerie", RFC0821, STD 10, août 1982.

[DSN]	K. Moore, G. Vaudreuil, "Format extensible de message pour les notifications d'état de livraison", RFC3464, janvier 2003. (MàJ par RFC4865, RFC5337) (D.S.)

5.	Considérations pour la sécurité

Le présent document décrit un système de codes d'état d'une précision accrue. L'utilisation de ces codes d'état peut divulguer des informations supplémentaires sur la façon dont est mis en œuvre un système interne de messagerie par rapport à ce qui est actuellement disponible.

Appendice A – Récapitulation des codes d'état

X.1.0	Autre état d'adresse	
X.1.1	Mauvaise adresse de boîte aux lettres de destination	
X.1.2	Mauvaise adresse de système de destination	
X.1.3	Mauvaise syntaxe d'adresse de boîte aux lettres de destination	
X.1.4	Adresse de boîte aux lettres de destination ambiguë	
X.1.5	Adresse de destination valide	
X.1.6	La boîte aux lettres de destination a été déplacée	
X.1.7	Mauvaise syntaxe d'adresse de boîte aux lettres de l'envoyeur	
X.1.8	Mauvaise adresse système de l'envoyeur	
X.2.0	État de boîte aux lettres autre ou indéfini	
X.2.1	Boîte aux lettres désactivée, n'accepte pas les messages	
X.2.2	Boîte aux lettres pleine	
X.2.3	La longueur du message excède une limite administrative	
X.2.4	Problème d'expansion de liste de diffusion	
X.3.0	Autre état de système de messagerie ou état indéfini	
X.3.1	Système de messagerie plein	
X.3.2	Le système n'accepte pas les messages réseau	
X.3.3	Le système n'a pas la capacité des caractéristiques sélectionnées	
X.3.4	Message trop gros pour le système	
X.4.0	Autre état de réseau ou d'acheminement indéfini	
X.4.1	Pas de réponse de l'hôte	
X.4.2	Mauvaise connexion	
X.4.3	Défaillance du serveur d'annuaire	
X.4.4	Incapable d'acheminer	
X.4.5	Encombrement du système de messagerie	
X.4.6	Détection d'une boucle d'acheminement	
X.4.7	Expiration du délai de livraison	
X.5.0	Autre état de protocole ou protocole indéfini	
X.5.1	Commande invalide	
X.5.2	Erreur de syntaxe	
X.5.3	Receveurs trop nombreux	
X.5.4	Arguments de commande invalides	
X.5.5	Mauvaise version du protocole	
X.6.0	Erreur de support autre ou indéfinie	
X.6.1	Support non accepté	
X.6.2	Conversion exigée et interdite	
X.6.3	Conversion exigée mais non acceptée	
X.6.4	Conversion effectuée avec pertes	
X.6.5	Échec de conversion	
X.7.0	État de sécurité autre ou indéfini	
X.7.1	Livraison non autorisée, message refusé	
X.7.2	Expansion de liste de diffusion interdite	
X.7.3	Conversion de sécurité exigée mais impossible	
X.7.4	Caractéristiques de sécurité non prises en charge	
X.7.5	Échec cryptographique	
X.7.6	Algorithme de chiffrement non pris en charge	
X.7.7	Échec d'intégrité du message	

Appendice B - Changements par rapport à la RFC1893

Changement des informations de contact des auteurs.

Mise à jour des paragraphes requis standard.

Correction des fautes d'orthographe.

Modification du texte qui décrit la défaillance transitoire persistante pour mieux refléter les pratiques et la compréhension actuelle.

Élimination de la restriction sur les codes X.4.7 les limitant aux erreurs transitoires persistantes

Adresse de l'auteur

Gregory M. Vaudreuil
Lucent Technologies
7291 Williamson Rd
Dallas, Tx. 75214
USA
téléphone : +1 214 823 9325
mél : GregV@ieee.org

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2003). Tous droits réservés

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou successeurs ou ayant droits.

Le présent document et les informations qui y sont contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Remerciement
Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.