Extension de service SMTP pour le retour de codes d'erreur améliorés

Statut du présent mémoire

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

1. Résumé

Le présent mémoire définit une extension au service SMTP [RFC0821], [RFC1869] par laquelle un serveur SMTP ajoute à ses réponses les codes d'état du système de messagerie améliorée définis dans la [RFC1893]. Ces codes peuvent alors être utilisés pour apporter des explications plus informatives sur les conditions d'erreur, en particulier dans le contexte du format des notifications d'état de livraison défini dans la [RFC1894].

2. Introduction

Bien que SMTP soit largement et solidement déployé, diverses extensions ont été demandées par des parties de la communauté de l'Internet. En particulier, il existe dans l'Internet moderne, international et multilingue, un besoin d'allouer des codes à des conditions d'erreur spécifiques qui puissent être traduites dans différentes langues. La [RFC1893] définit un tel ensemble de codes d'état et la [RFC1894] définit un mécanisme pour envoyer de tels matériaux codés aux usagers. Cependant, dans de nombreux cas, l'agent qui crée la notification d'état de livraison [RFC1894] fait cela en réponse aux erreurs qu'il reçoit de la part d'un serveur SMTP distant.

À ce titre, les serveurs distants ont besoin d'un mécanisme pour incorporer des codes d'état améliorés dans leurs réponses ainsi que comme moyen pour indiquer à un client quand il se comportent ainsi. Le présent mémoire utilise le mécanisme d'extension SMTP décrit dans la RFC1869 pour définir un tel mécanisme.

3. Cadre pour l'extension des états d'erreur améliorés

L'extension de transport des états d'erreur améliorés se compose comme suit :

(1) le nom de l'extension de service SMTP définie ici est Codes d'état améliorés ;

(2) la valeur du mot clé EHLO associée à l'extension est ENHANCEDSTATUSCODES ;

(3) aucun paramètre n'est utilisé avec le mot clé ENHANCEDSTATUSCODES EHLO ;

(4) la partie textuelle de toutes les réponses SMTP 2xx, 4xx, et 5xx autre que l'accueil initial et toute réponse à HELO ou EHLO est préfacée d'un code d'état comme défini dans la [RFC1893]. Ce code d'état est toujours suivi par une ou plusieurs espaces.

(5) aucun verbe SMTP additionnel n'est défini par cette extension ;

(6) la section suivante spécifie comment la prise en charge de l'extension affecte le comportement d'un serveur et d'un client SMTP.

4. Extension de service Code d'état amélioré

Les serveurs qui prennent en charge l'extension Codes d'état améliorés doivent préfacer la partie de texte de presque toutes les lignes de réponse avec un code d'état. Comme dans la [RFC1893], la syntaxe de ces codes d'état est donnée par l'ABNF :

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

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

sujet ::= 1*3chiffres

détail ::= 1*3chiffres

Ces codes doivent apparaître dans toutes les lignes de réponse 2xx, 4xx, et 5xx autres que l'accueil initial et toute réponse à HELO ou EHLO. Noter que les réponses 3xx NE SONT PAS incluses dans cette liste.

Tous les codes d'état retournés par le serveur doivent être en accord avec le code de réponse principal, c'est-à-dire qu'une réponse 2xx doit incorporer un code 2.X.X, une réponse 4xx doit incorporer un code 4.X.X, et une réponse 5xx doit incorporer un code 5.X.X.

Lorsque les réponses sont continues à travers plusieurs lignes, le même code d'état doit apparaître au début du texte dans chaque ligne de la réponse.

Les serveurs qui prennent en charge cette extension doivent attacher les codes d'état améliorés à leurs réponses sans considérer si EHLO est employé ou non par le client.

5. Codes d'état et négociation

La présente spécification ne fournit pas de moyen pour que les clients demandent que des codes d'état soient retournés ou non ; un serveur conforme inclut ces codes dans les réponses qu'il envoie sans considérer si le client les attend ou non. C'est un peu différent de ce que font la plupart des autres extensions SMTP, où en général un client doit spécifiquement faire une demande avant que le serveur disposant de l'extension se comporte différemment d'un serveur qui n'a pas l'extension. L'omission de la négociation avec le client est dans ce cas entièrement intentionnelle: Étant donné l'état généralement misérable des mises en œuvre de code d'erreur par les serveurs SMTP on a pensé que toute mesure en faveur de codes plus compréhensibles était quelque chose dont tous les clients, avec ou sans l'extension, devraient bénéficier.

NOTE IMPORTANTE : L'utilisation de cette approche de l'extension devrait être perçue comme très exceptionnelle. Elle NE DOIT PAS être prise pour la permission à de futures extensions SMTP de changer radicalement la nature de l'interaction client-serveur SMTP sans une annonce appropriée de la part du serveur et une commande d'activation correspondante par le client.

6. Exemple d'utilisation

Le dialogue suivant illustre l'utilisation des codes d'état améliorés par un serveur :

S: <attend la connexion sur l'accès TCP 25>

C: <ouvre la connexion avec le serveur>

S: 220 dbc.mtview.ca.us service SMTP prêt

C: EHLO ymir.claremont.edu

S: 250-dbc.mtview.ca.us dit hello

S: 250 ENHANCEDSTATUSCODES

C: MAIL FROM:<ned@ymir.claremont.edu>

S: 250 2.1.0 Originator <ned@ymir.claremont.edu> ok

C: RCPT TO:<mrose@dbc.mtview.ca.us>

S: 250 2.1.5 Recipient <mrose@dbc.mtview.ca.us> ok

C: RCPT TO:<nosuchuser@dbc.mtview.ca.us>

S: 550 5.1.1 Mailbox "nosuchuser" n'existe pas

C: RCPT TO:<remoteuser@isi.edu>

S: 551-5.7.1 Transmission aux hôtes distants désactivée

S: 551 5.7.1 Choisie un autre hôte pour agir comme transmetteur

C: DATA

S: 354 Envoi du message, tremine par un CRLF.CRLF.

...

C: .

S: 250 2.6.0 Message accepté

C: QUIT

S: 221 2.0.0 Au revoir

Le client qui reçoit ces réponses peut alors envoyer une notification de non livraison de forme générale :

Date: Mon, 11 Mar 1996 09:21:47 -0400

From: Mail Delivery Subsystem <mailer-daemon@ymir.claremont.edu>

Sujet: Message retourné

To: <ned@ymir.claremont.edu>

MIME-Version: 1.0

Content-Type: multipart/report; report-type=état de livraison ;

boundary="JAA13167.773673707/YMIR.CLAREMONT.EDU"

--JAA13167.773673707/YMIR.CLAREMONT.EDU

content-type: text/plain; charset=us-ascii

----- Le message a bien été relayé à l'adresse suivante -----

<mrose@dbc.mtview.ca.us>

----- l'adresse suivante a des problèmes de livraison -----

<nosuchuser@dbc.mtview.ca.us>

(Mailbox "nosuchuser" n'existe pas)

<remoteuser@isi.edu>

(La transmission aux hôtes distants est désactivée)

--JAA13167.773673707/YMIR.CLAREMONT.EDU

content-type: message/delivery-status

Reporting-MTA: dns; ymir.claremont.edu

Original-Recipient: rfc822;mrose@dbc.mtview.ca.us

Final-Recipient: rfc822;mrose@dbc.mtview.ca.us

Action: relayé

Status: 2.1.5 (Adresse de destination valide)

Diagnostic-Code: smtp;

250 Recipient <mrose@dbc.mtview.ca.us> ok

Remote-MTA: dns; dbc.mtview.ca.us

Original-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us

Final-Recipient: rfc822;nosuchuser@dbc.mtview.ca.us

Action: échec

Status: 5.1.1 (Mauvaise adresse de boîte aux lettres de destination)

Diagnostic-Code: smtp;

550 La boîte aux lettres "nosuchuser" n'existe pas

Remote-MTA: dns; dbc.mtview.ca.us

Original-Recipient: rfc822;remoteuser@isi.edu

Final-Recipient: rfc822;remoteuser@isi.edu

Action: échec

Status: 5.7.1 (Livraison non autorisée, message refusé)

Diagnostic-Code: smtp;

551 Transmission aux hôtes distants désactivée

Choisir un autre hôte pour agir domme transmetteur

Remote-MTA: dns; dbc.mtview.ca.us

--JAA13167.773673707/YMIR.CLAREMONT.EDU

content-type: message/rfc822

[Le message d'origine vient ici]

--JAA13167.773673707/YMIR.CLAREMONT.EDU--

Noter que pour réduire l'encombrement, le MTA qui fait rapport a omis les informations de code d'état amélioré dans les champs de code de diagnostic qu'il a généré.

7. Considérations pour la sécurité

Des détails suplémentaires dans les réponses des serveurs fournissent automatiquement des informations supplémentaires sur le serveur. Il est concevable que des informations supplémentaires de cette sorte puissent aider à circonvenir la sécurité du serveur. L'avantage que fournissent ces informations supplémentaires doit toujours être comparé aux implications pour la sécurité d'agir ainsi.

8. Références

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

[RFC1869] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "Extensions de service à SMTP", novembre 1995. (Obsolète, voir RFC5321, STD0010)

[RFC1893] G. Vaudreuil, "Codes d'état du système de messagerie améliorée", janvier 1996. (Obsolète, voir RFC3463) (P.S.)

[RFC1894] K. Moore, G. Vaudreuil, "Format de message extensible pour les notifications d'état de livraison", janvier 1996. (Obsolète, voir RFC3464) (P.S.)

9. Adresse de l'auteur

Ned Freed

Innosoft International, Inc.

1050 East Garvey Avenue South

West Covina, CA 91790

USA

tél : +1 818 919 3600 fax: +1 818 919 3614

mél : ned@innosoft.com