Groupe de travail Réseau	A. Gulbrandsen, Oryx Mail Systems GmbH
Request for Comments : 5530	mai 2009
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Codes de réponse IMAP

Statut de ce mémoire
Le présent document spécifie un protocole sur la voie de la normalisation de l’Internet 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.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document.

Résumé
Les réponses IMAP consistent en un type de réponse (OK, NO, BAD) un code de réponse facultatif lisible par la machine, et un texte lisible par l'homme.

Le présent document collecte et documente divers codes de réponse lisibles par la machine, pour une meilleure inter opération et de meilleurs rapports d'erreurs.
Table des matières
1. Introduction	1
2. Conventions utilisées dans ce document	2
3. Codes de réponse	2
4. Syntaxe formelle	4
5. Considérations sur la sécurité	4
6. Considérations relatives à l'IANA	4
7. Remerciements	6
8. Références normatives	6
9. Références pour information	6
Adresse de l'auteur	6

 	1.	Introduction

Le paragraphe 7.1 de la [RFC3501] définit un certain nombre de codes de réponse qui peuvent aider à dire à un client IMAP quelle commande a échoué. Cependant, l'expérience a montré que plus de codes seraient utiles. Par exemple, il est utile qu'un client sache qu'une tentative d'authentification a échoué à cause d'un problème de serveur plutôt que d'un problème de mot de passe.

Actuellement, de nombreux serveurs IMAP utilisent du texte lisible par l'homme en anglais pour décrire ces erreurs, et quelques clients IMAP tentent de traduire ce texte dans la langue de l'utilisateur.

Le présent document désigne diverses erreurs comme codes de réponse. Il se fonde sur des erreurs qui ont été vérifiées et rapportées dans certaines mises en œuvre de serveur IMAP, et sur les besoins de certains clients IMAP.

Le présent document n'exige d'aucun serveur qu'il essaye ces erreurs ou d'aucun client qu'il fasse des essais avec ces noms.  Il nomme seulement les erreurs pour en faire un meilleur traitement et rapport.

 	2.	Conventions utilisées dans ce document

La syntaxe formelle est définie par la [RFC3501] telle que modifiée par la [RFC5234].

Les lignes d'exemple commençant par "C:" sont envoyées par le client et celles commençant par "S:" sonr envoyées par le serveur. "[...]" signifie une élision.

 	3.	Codes de réponse

Cette section définit tous les nouveaux codes de réponse. Chaque définition est suivie d'un ou plusieurs exemples.

UNAVAILABLE (indisponible) : défaillance temporaire due à la défaillance d'un sous système. Par exemple, un serveur IMAP qui utilise un serveur du protoeole léger d'accès à un répertoire (LDAP, Lightweight Directory Access Protocol) ou Radius pour l'authentification pourrait utiliser ce code de réponse quand le serveur LDAP/Radius est en panne.

C: a LOGIN "fred" "foo"
S: a NO [UNAVAILABLE] l'extrémité de l'utilisateur est en cours de maintenance

AUTHENTICATIONFAILED : l'authentification a échoué pour une raison que le serveur ne veut pas développer. Normalement, cela inclut "utilisateur inconnu" et "mauvais mot de passe". C'est la même chose que de n'envoyer aucun code de réponse, sauf que quand un client voit AUTHENTICATIONFAILED, il sait que le problème n'est pas, par exemple, UNAVAILABLE, de sorte qu'il ne sert à rien d'essayer le même mot de passe ultérieurement.

C: b LOGIN "fred" "foo"
S: b NO [AUTHENTICATIONFAILED] Échec d'authentification

AUTHORIZATIONFAILED : l'authentification a réussi en utilisant l'identité d'authentification, mais le serveur ne peut pas ou ne veut pas permettre que l'identité d'authentification agisse comme l'identité d'autorisation demandée. Ceci n'est applicable que quand les identités d'authentification et d'autorisation sont différentes.

C: c1 AUTHENTICATE PLAIN
[...]
S: c1 NO [AUTHORIZATIONFAILED] Pas de tel identifiant d'autorisation

C: c2 AUTHENTICATE PLAIN
[...]
S: c2 NO [AUTHORIZATIONFAILED] L'authentificateur n'est pas un administrateur

EXPIRED : soit l'authentification a réussi, soit le serveur n'a plus les données nécessaires ; dans les deux cas, l'accès n'est plus permis en utilisant ce mot de passe. Le client ou l'utilisateur devrait obtenir un nouveau mot de passe.

C: d login "fred" "foo"
S: d NO [EXPIRED] Ce mot de passe n'est plus valide

PRIVACYREQUIRED : l'opération n'est pas permise à cause d'un manque de confidentialité. Si la sécurité de la couche transport (TLS, Transport Layer Security) n'est pas utilisée, le client pourrait essayer STARTTLS (voir lc paragraphe  6.2.1 de la [RFC3501]) et ensuite répéter l'opération.

C: d login "fred" "foo"
S: d NO [PRIVACYREQUIRED] La connexion n'assure pas la confidentialité

C: d select inbox
S: d NO [PRIVACYREQUIRED] La connexion n'assure pas la confidentialité

CONTACTADMIN : l'utilisateur devrait contacter l'administrateur du système ou le bureau d'assitance.

C: e login "fred" "foo"
S: e OK [CONTACTADMIN]

NOPERM : le système de contrôle d'accès (par exemple, liste de contrôle d'accès (ACL, Access Control List) voir la [RFC4314]) ne permet pas à cet utilisateur d'effectuer une opération, comme de choisir ou créer une boîte aux lettres.

C: f select "/archive/projects/experiment-iv"
S: f NO [NOPERM] Accès refusé

INUSE : une opération n'a pas éte effectuée parce que elle implique de scier une branche sur laquelle quelqu'un est assis. Quelqu'un d'autre peut être le détenteur d'un verrouillage exclusif nécessaire pour cette opération, ou l'opération peut impliquer de supprimer une ressource que quelqu'un d'autre est en train d'utiliser, normalement, une boîte aux lettres. L'opération peut réussir si le client essaye à nouveau ultérieurement.

C: g delete "/archive/projects/experiment-iv"
S: g NO [INUSE] Boîte aux lettres utilisée.

EXPUNGEISSUED : quelqu'un d'autre a produit un EXPUNGE pour la même boîte aux lettres. Le client peut vouloir produire bientôt un NOOP. La [RFC2180] discute ce sujet en profondeur.

C: h search from fred@example.com
S: * SEARCH 1 2 3 5 8 13 21 42
S: h OK [EXPUNGEISSUED] Recherche terminée

CORRUPTION : le serveur a découvert que des données pertinentes (par exemle, la boîte aux lettres) sont corrompues. Ce code de réponse n'inclut aucune information sur ce qui est corrompu, mais le serveur peut inscrire cela dans ses fichiers journaux

C: i select "/archive/projects/experiment-iv"
S: i NO [CORRUPTION] Ne peut pas ouvrir la boîte aux lettres

SERVERBUG : le serveur a rencontré une faute chez lui ou a violé un de ses propres invariants.

C: j select "/archive/projects/experiment-iv"
S: j NO [SERVERBUG]  [RFC5234] Ceci ne devrait pas se produire

CLIENTBUG : le serveur a détecté une faute chez le client. Cela peut accompagner tous les OK, NO, et BAD, selon la faute du client.

C: k1 select "/archive/projects/experiment-iv"
[...]
S: k1 OK [READ-ONLY] Fait
C: k2 status "/archive/projects/experiment-iv" (messages)
[...]
S: k2 OK [CLIENTBUG] Fait

CANNOT : l'opération viole un invariant du serveur et ne va jamais réussir

C: l create "///////"
S: l NO [CANNOT] les barres obliques adjacentes ne sont pas acceptées

LIMIT : l'opération a touché une certaine limite de mise en œuvre, comme le nombre de fanions sur un seul message ou le nombre de fanions utilisés dans une boîte aux lettres.

C: m STORE 42 FLAGS f1 f2 f3 f4 f5 ... f250
S: m NO [LIMIT] Au plus 32 fanions pris en charge dans une boîte aux lettres

OVERQUOTA : l'utilisateur va dépasser un quota après l'opération. (L'utilisateur peut ou non être déjà au delà du quota.) Noter que si le serveur envoie OVERQUOTA mais ne prend pas en charge l'extension IMAP QUOTA définie dans la [RFC2087], il y a alors un quota, mais le client ne peut pas trouver quel est ce quota.

C: n1 uid copy 1:* oldmail
S: n1 NO [OVERQUOTA] Désolé

C: n2 uid copy 1:* oldmail
S: n2 OK [OVERQUOTA] Vous avez dépassé votre quota logiciel

ALREADYEXISTS : l'opération tente de créer quelque chose qui existe déjà, comme quand les répertoires CREATE ou RENAME tentent de créer une boîte aux lettres et qu'il y en a déjà une de ce nom.

C: o RENAME ceci cela
S: o NO [ALREADYEXISTS] La boîte aux lettres "cela" existe déjà

NONEXISTENT : l'opération tente de supprimer quelque chose qui n'existe pas. Similaire à ALREADYEXISTS.

C: p RENAME ceci cela
S: p NO [NONEXISTENT] Pas de telle boîte aux lettres

 	4.	Syntaxe formelle

La spécification de syntaxe suivante utilise la notation de forme Backus-Naur augmenté (ABNF, Augmented Backus-Naur Form) comme spécifié dans la [RFC5234]. La [RFC3501] définit le non terminal "resp-text-code".

Sauf notation contraire, tous les caractères alphabétiques sont insensibles à la casse. L'utilisation de caractères majuscules ou minuscules pour définir des chaînes de jetons est seulement pour faciliter la lecture.

resp-text-code =/ "UNAVAILABLE" / "AUTHENTICATIONFAILED" /
                         "AUTHORIZATIONFAILED" / "EXPIRED" /
                         "PRIVACYREQUIRED" / "CONTACTADMIN" / "NOPERM" /
                         "INUSE" / "EXPUNGEISSUED" / "CORRUPTION" /
                         "SERVERBUG" / "CLIENTBUG" / "CANNOT" /
                         "LIMIT" / "OVERQUOTA" / "ALREADYEXISTS" /
                         "NONEXISTENT"

 	5.	Considérations sur la sécurité

Révéler des informations sur un mot de passe à des clients IMAP non authentifiés cause des problèmes.

Les codes de réponse sont plus faciles à analyser que le texte lisisble par l'homme. Cela peut amplifier les conséquences d'une fuite d'informations. Par exemple, le choix d'une boîte aux lettres peut échouer parce que la boîte aux lettres n'existe pas, parce que l'utilisateur n'a pas le droit "l" (droit de savoir que la boîte aux letres existe) ou "r" (droit de lire la boîte aux lettres). Si le serveur a envoyé une réponse différente dans les deux premiers cas dans le passé, seuls des clients malveillants vont le découvrir. Avec les codes de réponse, il est possible, peut-être probable, que les clients bienveillants vont transmettre les informations échappées à l'utilisateur. Les auteurs de serveurs sont invités à être particulièrement prudents avec les réponses NOPERM et relatives à l'authentification.

 	6.	Considérations relatives à l'IANA

L'IANA a créé le registre des codes de réponse IMAP. Le registre a été rempli avec les codes suivants :

NEWNAME 	RFC 2060 (obsolète)
REFERRAL 	RFC 2221
HASCHILDREN	RFC 3348
ALERT	RFC 3501
BADCHARSET	RFC 3501
CAPABILITY	RFC 3501
PARSE	RFC 3501
PERMANENTFLAGS	RFC 3501
READ-ONLY	RFC 3501
READ-WRITE	RFC 3501
TRYCREATE	RFC 3501
UIDNEXT	RFC 3501
UIDVALIDITY	RFC 3501
UNSEEN	RFC 3501
UNKNOWN-CTE	RFC 3516
UIDNOTSTICKY	RFC 4315
APPENDUID	RFC 4315
COPYUID	RFC 4315
URLMECH	RFC 4467
TOOBIG	RFC 4469
BADURL	RFC 4469
HIGHESTMODSEQ	RFC 4551
NOMODSEQ	RFC 4551
MODIFIED	RFC 4551
COMPRESSIONACTIVE	RFC 4978
CLOSED	RFC 5162
NOTSAVED	RFC 5182
BADCOMPARATOR	RFC 5255
ANNOTATE	RFC 5257
ANNOTATIONS	RFC 5257
TEMPFAIL	RFC 5259
MAXCONVERTMESSAGES	RFC 5259
MAXCONVERTPARTS	RFC 5259
NOUPDATE	RFC 5267
METADATA	RFC 5464
NOTIFICATIONOVERFLOW	RFC 5465
BADEVENT	RFC 5465
UNDEFINED-FILTER	RFC 5466
UNAVAILABLE	RFC 5530
AUTHENTICATIONFAILED	RFC 5530
AUTHORIZATIONFAILED	RFC 5530
EXPIRED	RFC 5530
PRIVACYREQUIRED	RFC 5530
CONTACTADMIN 	RFC 5530
NOPERM	RFC 5530
INUSE	RFC 5530
EXPUNGEISSUED	RFC 5530
CORRUPTION	RFC 5530
SERVERBUG	RFC 5530
CLIENTBUG	RFC 5530
CANNOT	RFC 5530
LIMIT	RFC 5530
OVERQUOTA	RFC 5530
ALREADYEXISTS	RFC 5530
NONEXISTENT	RFC 5530

Le nouveau registre peut être étendu en envoyant une demande d'enregistrement à l'IANA. L'IANA va transmettre cette demande à un expert désigné, appointé par le directeur responsable de zone de l'IESG, avec copie à la liste de diffusion Extensions IMAP à <ietf-imapext@imc.org> (ou un successeur désigné par le directeur de zone). Après avoir permis 30  jours pour des apports de la communauté sur la liste de diffusion Extensions IMAP ou un dernier appel réussi à l'IETF, l'expert va déterminer l'opportunité de la demande d'enregistrement et soit approuver, soit désapprouver la demande par l'envoi d'une notice de la décision au demandeur, avec copie à la liste de diffusion Extensions IMAP et à l'IANA. Une notice de refus doit être justifiée par une explication, et, dans les cas où c'est possible, des suggestions concrètes sur la façon dont la demande peut être modifiée afin de devenir acceptable devraient être fournies.

Pour chaque code de réponse, le registre contient une liste des RFC pertinentes qui décrivent (ou étendent) le code de réponse et une description facultative d'état de code de réponse, comme "obsolète" ou "réservé pour empêcher une collision avec le logiciel déployé". (Noter que dans ce dernier cas, le numéro de RFC peut manquer.) La présence de la description d'état de code de réponse signifie que le code de réponse correspondant N'est PAS RECOMMENDÉ pour une large utilisation.

L'intention est que toute future allocation soit accompagnée d'une RFC  publiée (incluant des soumissions directes à l'éditeur des RFC). Mais afin de permettre l'allocation de valeurs avant l'approbation de la RFC pour publication, l'expert désigné peut approuver les allocations une fois qu'il semble clair qu'une RFC va être publiée, par exemple, avant de demander une LC de l'IETF pour le document.

L'expert désigné peut aussi approuver des enregistrements pour des codes de réponse utilisés dans des logiciels déployés quand aucune RFC n'existe. De tels enregistrements doivent être marqués comme "réservé pour empêcher des collisions avec les logiciels déployés".

Les enregistrements de code de réponse ne peuvent pas être supprimés ; les codes de réponse qui ne sont plus estimés appropriés (par exemple, si il y a un problème avec la syntaxe du dit code de réponse ou si la spécification qui le décrit est passée au statut de Historique) devraient être marqués "obsolète" dans le registre, marquant clairement les listes publiées par l'IANA.

 	7.	Remerciements

Peter Coates, Mark Crispin, Philip Guenther, Alexey Melnikov, Ken Murchison, Chris Newman, Timo Sirainen, Philip Van Hoof, Dale Wiggins, et Sarah Wilkin ont aidé à la réalisation du présent document.

 	8.	Références normatives

[RFC3501]	M. Crispin, "Protocole d'accès au message Internet - version 4rev1", mars 2003. (P.S. ; MàJ par RFC4466, 4469, 4551, 5032, 5182, 7817, 8314, 8437, 8474 ; remplacée par la 9051

[RFC5234]	D. Crocker, P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", janvier 2008. (STD0068)

 	9.	Références pour information

[RFC2087]	J. Myers, "Extension IMAP4 QUOTA", janvier 1997. (P.S. ; remplacée par 9208)

[RFC2180]	M. Gahrns, "Pratique de boîtes aux lettres à accès multiple dans IMAP4", juillet 1997. (Information)

[RFC4314]	A. Melnikov, "Extension IMAP4 de liste de contrôle d'accès (ACL)", décembre 2005. (Remplace RFC2086) (P.S.)

 	Adresse de l'auteur

Arnt Gulbrandsen
Oryx Mail Systems GmbH
Schweppermannstr. 8
D-81671 Muenchen
Germanie

Fax : +49 89 4502 9758
mél : arnt@oryx.com