← RFC Reference

RFC 5248: Registre des codes d'état améliorés SMTP

Pourquoi cela existe

Les codes d'état améliorés (RFC 3463) utilisent un format en trois parties class.subject.detail pour décrire précisément pourquoi un message a été accepté, rejeté ou retardé. Le RFC original définissait un ensemble fixe de codes, mais les nouvelles technologies de courrier électronique ont continué à avoir besoin de nouveaux codes :

• Les défaillances DMARC nécessitaient 5.7.25 et 5.7.26
• Null MX (RFC 7505) nécessitait 5.1.10
• Les exigences TLS nécessitaient des codes dans la plage de sécurité X.7.X
• Les extensions d'authentification nécessitaient X.7.20 à X.7.27

Sans registre formel, les nouveaux codes étaient attribués au coup par coup et risquaient des collisions. La RFC 5248 établit le registre IANA « Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes », avec des règles claires pour l'enregistrement et l'exigence que chaque nouveau code ait une signification définie.

Comment cela fonctionne

Le registre organise les codes selon leurs trois composants. Les nouveaux codes sont ajoutés par le processus de normalisation de l'IETF, et chaque entrée documente :

Format d'entrée du registre

Réponse SMTP avec code défini dans le registre

MAIL FROM:<sender@example.com>
250 2.1.0 Originator address accepted

RCPT TO:<user@example.org>
550 5.7.26 This message does not pass DMARC evaluation
     ^^^^^
     Registered in IANA registry, defined by RFC 7372

RCPT TO:<nobody@null-mx.example>
556 5.1.10 Recipient address has null MX
     ^^^^^^
     Registered in IANA registry, defined by RFC 7505

Détails techniques clés

Codes d'état énumérés (classe + sujet)

La RFC 5248 définit les « codes d'état énumérés » qui combinent les valeurs de classe et de sujet. La classe reste 2, 4 ou 5, et les valeurs de sujet sont :

Codes ajoutés depuis la RFC 3463

Politique d'enregistrement

Les nouveaux codes exigent « Specification Required » selon la politique IANA. Cela signifie qu'une spécification publiée (généralement un RFC) doit définir la sémantique du code. L'examinateur expert désigné s'assure qu'il n'y a pas de conflits avec les codes existants et que le nouveau code s'inscrit dans la catégorie de sujet correcte.

Erreurs courantes

• Coder en dur un ensemble fixe de codes d'état. Le registre est extensible. De nouveaux codes sont ajoutés régulièrement. Construisez votre processeur de rebond pour gérer les codes inconnus avec élégance en revenant à la classe (2/4/5) et à la catégorie de sujet.
• Inventer des codes d'état non enregistrés. Certains serveurs de courrier retournent des codes d'état améliorés personnalisés non présents dans le registre. Bien que techniquement valides pour un usage privé, cela nuit à l'interopérabilité. Utilisez des codes enregistrés autant que possible.
• Ignorer le chiffre de classe lors du traitement des nouveaux codes. Si vous rencontrez 5.7.28 (un code hypothétique futur), vous ne connaissez peut-être pas sa signification spécifique, mais vous savez que c'est une défaillance permanente de sécurité/politique. La classe et le sujet sont toujours significatifs.
• Ne pas distinguer la classe 4 et la classe 5. 4.2.2 (boîte postale pleine, temporaire) et 5.2.1 (boîte postale désactivée, permanente) partagent le même sujet mais nécessitent un traitement complètement différent. Vérifiez toujours d'abord la classe.
• Supposer que tous les serveurs utilisent des codes améliorés. L'extension SMTP ENHANCEDSTATUSCODES est largement mais pas universellement déployée. Votre analyseur de rebond doit gérer les réponses qui ne contiennent que le code à trois chiffres de base.

Impact sur la délivrabilité

• Classification précise des rebonds. Le registre vous donne un vocabulaire standardisé pour expliquer pourquoi les messages échouent. 5.7.26 signifie défaillance DMARC — corrigez votre authentification. 5.1.1 signifie adresse invalide — supprimez-la de votre liste. Sans consulter le registre, vous deviez deviner.
• Diagnostic des défaillances d'authentification. La plage de codes 5.7.20–5.7.26 ajoutée par la RFC 7372 vous permet d'identifier précisément quel mécanisme d'authentification a échoué : DKIM, SPF, DNS inversé ou alignement DMARC.
• Gestion des rebonds à l'épreuve du temps. En analysant la classe et le sujet de n'importe quel code, même non reconnus, votre système se dégrade gracieusement à mesure que de nouveaux codes sont enregistrés. Un code 5.7.X que vous n'avez jamais vu est toujours un rejet de sécurité permanent.
• Corrélation avec les rapports DSN. Les codes d'état améliorés apparaissent à la fois dans les réponses SMTP et dans les rapports DSN (RFC 3464). Le registre garantit que le même code signifie la même chose dans les deux contextes, permettant un traitement cohérent des rebonds.

Related RFCs