Groupe de travail Réseau |
R. Gellens, Qualcomm |
Request for Comments : 2449 |
C. Newman, Innosoft |
RFC mises à jour : 1939 |
L. Lundblade, Qualcomm |
Catégorie : En cours de normalisation |
novembre 1998 |
Traduction Claude Brière de L’Isle |
|
Statut du présent mémoire
Le présent document spécifie un protocole en cours de normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussion 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 Copyright
Copyright (C) The Internet Society (1998). Tous droits réservés.
Note de l’IESG
La présente extension au protocole POP3 est à utiliser par un serveur pour exprimer des décisions de politique prises par l’administrateur du serveur. Ce n’est pas la voie ouverte vers la mise en œuvre générale d’autres extensions de POP3. On s’accorde largement sur l’idée que le protocole POP3 devrait rester simple, et destiné au simple objet de télécharger de la messagerie depuis un serveur de messagerie. Lorsqu’il est besoin d’opérations plus compliquées, le protocole IMAP [RFC 2060] devrait être utilisé. Le premier paragraphe de la section 7 devrait être lu très attentivement.
Table des matières
1. Introduction
2. Conventions utilisées dans le document
3. Grammaire générale de commande et de réponse
4. Longueurs des paramètres et des réponses
5. La commande CAPA
6. Ensemble initial de capacités
6.1 Capacité TOP
6.2 Capacité USER
6.3 Capacité SASL
6.4 Capacité RESP-CODES
6.5 Capacité LOGIN-DELAY
6.6 Capacité PIPELINING
6.7 Capacité EXPIRE
6.8 Capacité UIDL
6.9 Capacité IMPLEMENTATION
7. Extensions futures de POP3
8. Codes de réponse POP3 étendus
8.1 Codes de réponse initiaux POP3
8.1.1 Le code de réponse LOGIN-DELAY
8.1.2 Le code de réponse IN-USE
9. Considérations relatives à l’IANA10. Considérations sur la sécurité
11. Remerciements
12. Références
13. Adresse des auteurs
14. Déclaration complète de droits de reproduction
La version 3 du protocole Post Office [POP3] est très largement utilisée. Cependant, bien qu’elle comporte certaines commandes facultatives (et que certaines extensions de protocole utiles aient été publiées), il lui manque un mécanisme pour faire connaître la prise en charge de ces extensions ou de variations de comportement.
Actuellement, ces caractéristiques et extensions facultatives ne peuvent être détectées que par des essais, s’il en est. C’est au mieux inefficace, et éventuellement pire. Il en résulte que certains clients ont des options de configuration manuelles pour les capacités de serveur POP3.
Parce qu’une des plus importantes caractéristiques de POP3 est sa simplicité, il est souhaitable que le nombre des extensions reste faible (voir la section 7). Cependant, certaines extensions sont nécessaires (comme celles qui améliorent la sécurité [POP-AUTH]), alors que d’autres sont très souhaitables dans certaines situations. De plus est nécessaire un moyen de découvrir le comportement du serveur.
Le présent mémoire met à jour la RFC 1939 [POP3] pour définir un mécanisme d’annonce de la prise en charge de commandes facultatives, d’extensions, et de comportement de serveur inconditionnel. Il comporte un ensemble initial de capacités actuellement développées qui vont de la mise en œuvre de serveur à plusieurs nouvelles capacités (SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE et IMPLEMENTATION). Le présent document étend aussi les messages d’erreur POP3 de façon que les codes analysables par la machine puissent être fournis au client. Un ensemble initial de codes de réponse est inclus. De plus, une spécification [ABNF] des commandes et réponses de POP3 est définie.
Les commentaires publics devraient être envoyés à la liste de diffusion Extensions POP3 de l’IETF, <ietf-pop3ext@imc.org>. Pour s’y inscrire, envoyer un message contenant SUBSCRIBE à <ietf-pop3ext-request@imc.org>.
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "PEUT", et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans [KEYWORDS].
Dans les exemples, "C:" et "S:" indiquent respectivement les lignes envoyées par le client et le serveur.
La forme générale des commandes et réponses POP3 est décrite en [ABNF] :
Commandes POP3 :
commande = mot clé *(paramètre SP) CRLF ; 255 octets maximum
mot clé = 3*4VCHAR
paramètre = 1*VCHAR
Réponses POP3 :
réponse = greeting / single-line / capa-resp / multi-line
capa-resp = single-line *capability "." CRLF
capa-tag = 1*cchar
capability = capa-tag *(SP param) CRLF ; 512 octets maximum
cchar = %x21-2D / %x2F-7F ; ASCII imprimable, à l’exclusion de "."
dot-stuffed = *CHAR CRLF ; doit être complété par des points
gchar = %x21-3B / %x3D-7F ; ASCII imprimable, à l’exclusion de "<"
greeting = "+OK" [resp-code] *gchar [timestamp] *gchar CRLF ; 512 octets maximum
multi-line = single-line *dot-stuffed "." CRLF
rchar = %x21-2E / %x30-5C / %x5E-7F ; ASCII imprimable, à l’exclusion de "/" et "]"
resp-code = "[" resp-level *("/" resp-level) "]"
resp-level = 1*rchar
schar = %x21-5A / %x5C-7F ; ASCII imprimable, à l’exclusion de "["
single-line = status [SP text] CRLF ; 512 octets maximum
status = "+OK" / "-ERR"
text = *schar / resp-code *CHAR
timestamp = "<" *VCHAR ">" ; DOIT se conformer au msg-id de la RFC-822
La présente spécification augmente les restrictions de longueur sur les commandes et les paramètres imposées par la RFC 1939.
La longueur maximum d’une commande est portée de 47 caractères (4 caractères de la commande, un seul espace, 40 caractères d’argument, CRLF) à 255 octets, y compris le CRLF de terminaison.
Les serveurs qui prennent en charge la commande CAPA DOIVENT accepter les commandes jusqu’à 255 octets. Les serveurs DOIVENT aussi accepter la longueur maximum de commande spécifiée par toute capacité prise en charge.
La longueur maximum de la première ligne d’une réponse de commande (y compris l’accueil initial) est inchangée à 512 octets (y compris le CRLF de terminaison).
La commande POP3 CAPA retourne une liste des capacités prises en charge par le serveur POP3. Elle est disponible dans les deux états AUTHORIZATION et TRANSACTION.
Une description de capacité DOIT documenter dans quels états la capacité est annoncée, et dans quels états les commandes sont valides.
Les capacités disponibles dans l’état AUTHORIZATION DOIVENT être annoncées dans les deux états.
Si une capacité est annoncée dans les deux états, mais si l’argument pourrait différer après authentification, cette possibilité DOIT être déclarée dans la description de capacité.
(Ces exigences permettent à un client de ne produire qu’une seule commande CAPA s’il n’utilise aucune capacité TRANSACTION-seule, ou aucune capacité dont les valeurs pourraient différer après authentification.)
Si l’étape d’authentification négocie une couche de protection d’intégrité, le client DEVRAIT produire une nouvelle fois la commande CAPA après l’authentification, pour vérifier qu’il n’y a pas d’attaque active visant à dégrader la négociation.
Chaque capacité peut activer des commandes de protocole supplémentaires, des paramètres et des réponses supplémentaires pour des commandes existantes, ou décrire un aspect du comportement du serveur. Ces détails sont spécifiés dans la description de la capacité.
La Section 3 décrit la réponse CAPA à l’aide de [ABNF]. Lorsque une réponse de capacité décrit une commande facultative, la <capa-tag> DEVRAIT être identique à la commande clavier. Les étiquettes de réponse à CAPA sont insensibles à la casse.
CAPA
Arguments: aucun
Restrictions: aucune
Discussion:
Une réponse -ERR indique que la commande de capacité n’est pas mise en œuvre et que le client devra prouver ses capacités comme auparavant.
Une réponse +OK est suivie par une liste de capacités, une par ligne. Chaque nom de capacité PEUT être suivi par une seule espace et une liste de paramètres séparés par une espace. Chaque ligne de capacité est limitée à 512 octets (y compris le CRLF). La liste de capacités est terminée par une ligne contenant un octet de terminaison (".") et une paire de CRLF.
Réponses possibles : +OK -ERR
Exemples :
C: CAPA
S: +OK La liste des capacités suit
S: TOP
S: USER
S: SASL CRAM-MD5 KERBEROS_V4
S: RESP-CODES
S: LOGIN-DELAY 900
S: PIPELINING
S: EXPIRE 60
S: UIDL
S: IMPLEMENTATION Shlemazle-Plotz-v302
S: .
Cette section définit un ensemble initial de capacités POP3. Il comporte les commandes POP3 facultatives, les extensions POP3 déjà publiées, et des variations de comportement entre les serveurs POP3, qui peuvent avoir un impact sur les clients.
Noter qu’il n’y a pas de capacité APOP, même si APOP est une commande facultative dans [POP3]. Les clients découvrent la prise en charge d’APOP par le serveur par la présence d’une mise en cause initiale dans la bannière d’accueil incluse entre crochets angulaires ("<>"). Donc, une capacité APOP introduirait deux façons pour qu’un serveur annonce la même chose.
Étiquette CAPA : TOP
Arguments : aucun
Commandes ajoutées : TOP
Commandes standard affectées : aucune
États annoncés / différences possibles : les deux / non
Commandes valides dans les états : TRANSACTION
Référence de spécification : [POP3]
Discussion:
La capacité TOP indique que la commande TOP facultative est disponible.
Étiquette CAPA : USER
Arguments : aucun
Commandes ajoutées : USER PASS
Commandes standard affectées : aucune
États annoncés / différences possibles : les deux / non
Commandes valides dans les états : AUTHENTICATION
Spécification de référence : [POP3]
Discussion:
La capacité USER indique que les commandes USER et PASS sont prises en charge, bien qu’elles puissent n’être pas disponibles pour tous les usagers.
Étiquette CAPA : SASL
Arguments : Mécanismes SASL pris en charge
Commandes ajoutées : AUTH
Commandes standard affectées : aucune
États annoncés / différences possibles : les deux / non
Commandes valides dans les états : AUTHENTICATION
Spécification de référence : [POP-AUTH, SASL]
Discussion:
La commande POP3 AUTH [POP-AUTH] permet l’utilisation des mécanismes d’authentification de [SASL] avec POP3. La capacité SASL indique que la commande AUTH est disponible et qu’il accepte un second argument facultatif codé en base64 pour une réponse initiale de client comme décrit dans la spécification SASL. L’argument pour la capacité SASL est une liste séparée par une espace des mécanismes SASL qui sont pris en charge.
Étiquette CAPA : RESP-CODES
Arguments : aucun
Commandes ajoutées : aucune
Commandes standard affectées : aucune
États annoncés / différences possibles : les deux / non
Commandes valides dans les états : non disponible
Spécification de référence : le présent document
Discussion :
La capacité RESP-CODES indique que tout texte de réponse produit par ce serveur qui commence par un crochet rectangulaire ouvert ("[") est un code de réponse étendue (voir à la section 8).
Étiquette CAPA : LOGIN-DELAY
Arguments : minimum de secondes entre les connexions ; facultativement suivi par USER en état AUTHENTICATION.
Commandes ajoutées : aucune
Commandes standard affectées : USER PASS APOP AUTH
États annoncés / différences possibles : les deux / oui
Commandes valides dans les états : non disponible
Spécification de référence : le présent document
Discussion :
Les clients POP3 se connectent souvent fréquemment pour vérifier les nouveaux messages. Malheureusement, le processus de création d’une connexion, d’authentification de l’usager, et d’ouverture de la boîte aux lettres de l’usager peut consommer beaucoup de ressources chez le serveur. Un certain nombre de serveurs POP3 en service essayent de réduire la charge du serveur en imposant un délai entre les connexions. La capacité LOGIN-DELAY comporte un argument entier qui indique le nombre de secondes après une réponse "+OK" à une commande PASS, APOP, ou AUTH avant qu’une autre authentification soit acceptée. Les clients qui permettent à l’usager de configurer un intervalle de vérification de messagerie DEVRAIENT utiliser cette capacité pour déterminer l’intervalle permis minimum. Les serveurs qui affichent LOGIN- DELAY DEVRAIENT la mettre en application.
Si la période du délai de connexion minimum peut différer d’un usager à l’autre (c’est-à-dire, si l’argument LOGIN-DELAY peut changer après l’authentification), le serveur DOIT annoncer dans l’état AUTHENTICATION la plus grande valeur qui peut être établie pour tout usager. Cela peut être la plus grande valeur actuellement utilisée pour tout usager (donc une seule valeur par serveur), ou même la plus grande valeur que le serveur permet d’établir pour tout usager. Le serveur DEVRAIT ajouter le jeton "USER" au paramètre LOGIN-DELAY dans l’état AUTHENTICATION, pour informer le client qu’une valeur plus précise est disponible après l’authentification. Le serveur DEVRAIT annoncer la valeur plus précise dans l’état TRANSACTION. (Le jeton "USER" permet au client de décider si une seconde commande CAPA est nécessaire ou non.)
Les serveurs mettent en application LOGIN-DELAY en rejetant une commande d’authentification avec ou sans la réponse d’erreur LOGIN-DELAY. Voir des informations complémentaires au paragraphe 8.1.1.
Étiquette CAPA : PIPELINING
Arguments: aucun
Commandes ajoutées : aucune
Commandes standard affectées : toutes
États annoncés / différences possibles : les deux / non
Commandes valides dans les états : non disponible
Spécification de référence : le présent document
Discussion :
La capacité PIPELINING indique que le serveur est capable d’accepter plusieurs commandes à la fois ; le client n’a pas à attendre la réponse à une commande avant de produire la commande suivante. Si un serveur accepte PIPELINING, il DOIT traiter chaque commande à son tour. Si un client utilise PIPELINING, il DOIT garder la trace des commandes qui sont en cours, et faire correspondre dans l’ordre les réponses du serveur aux commandes. Si le client ou le serveur utilise des enregistrements bloquants, il ne DOIT pas dépasser la taille de fenêtre de la couche de transport sous-jacente.
Certains clients POP3 ont une option pour indiquer que le serveur prend en charge les "commandes POP3 en chevauchement." Cette capacité supprime le besoin de configurer cela chez le client.
Ceci est en gros synonyme de l’extension ESMTP PIPELINING [PIPELINING], cependant, comme SMTP [SMTP] tend à avoir des commandes et réponses courtes, l’avantage réside dans le groupement de plusieurs commandes et leur envoi comme un tout. Bien qu’il y ait des cas comme cela dans POP (par exemple, USER et PASS pourraient faire un lot, plusieurs commandes RETR et/ou DELE pourraient être envoyées groupées), comme POP a des commandes courtes et parfois des réponses longues, il y a aussi un avantage à envoyer de nouvelles commandes tout en recevant la réponse à une commande antérieure (par exemple, envoyer des commandes RETR et/ou DELE tout en traitant une réponse UIDL).
Étiquette CAPA tag: EXPIRE
Arguments : Jours de rétention minimum garantis par le serveur, ou NEVER; facultativement suivi par USER dans l’état AUTHENTICATION
Commandes ajoutées : aucune
Commandes standard affectées : aucune
États annoncés / différences possibles : les deux / oui
Commandes valides dans les états : non disponible
Spécification de référence : le présent document
Discussion:
Alors que POP3 permet aux clients de laisser des messages sur le serveur, la RFC 1939 [POP3] attire l’attention sur les problèmes qui peuvent en résulter, et permet aux serveurs de supprimer les messages sur la base de la politique du site.
La capacité EXPIRE évite les problèmes mentionnés dans la RFC 1939, en permettant au serveur d’informer le client sur la politique mise en œuvre. L’argument de la capacité EXPIRE indique la période de rétention minimum du serveur, en jours, pour les messages sur le serveur.
EXPIRE 0 indique au client qu’il n’est pas permis de laisser de message sur le serveur ; quand la session entre dans l’état UPDATE, le serveur PEUT supposer un DELE implicite pour chaque message qui a été téléchargé avec RETR.
EXPIRE NEVER affirme que le serveur ne supprime pas les messages.
Le concept d’une "période de rétention" est intentionnellement vague. Les serveurs peuvent commencer à compter les jours jusqu’à l’expiration quand un message est ajouté à une boîte aux lettres, quand un client est averti de l’existence d’un message par les commandes LIST ou UIDL, quand un message a été entériné d’une façon quelconque (par exemple, TOP ou RETR), ou à l’occasion d’un autre événement quelconque. La capacité EXPIRE ne peut pas fournir une indication précise du moment exact où un message spécifique va arriver à expiration. La capacité est destinée à rendre plus facile aux clients de se comporter de façon conforme à la politique du site et aux souhaits des utilisateurs. Par exemple, un client peut afficher un avertissement pour ses tentatives de configurer une période de "dépôts de messages sur le serveur" qui serait supérieure ou égale à un certain pourcentage de la valeur annoncée par le serveur.
Si un site utilise une politique de suppression automatique, il DEVRAIT utiliser la capacité EXPIRE pour l’annoncer.
La capacité EXPIRE, avec un paramètre autre que 0 ou NEVER, est destinée à faire savoir au client que le serveur ne permet pas que les messages soient laissés sur le serveur, et à présenter une valeur qui est la plus petite qui peut être mise en application.
Les sites qui permettent aux usagers de conserver indéfiniment les messages DEVRAIENT l’annoncer avec la réponse EXPIRE NEVER.
Si la politique d’expiration diffère selon les usagers (c’est-à-dire, si l’argument EXPIRE peut changer après l’authentification), le serveur DOIT annoncer dans l’état AUTHENTICATION la plus petite valeur qui pourrait être établie pour tout utilisateur. Cela peut être la plus petite valeur actuellement utilisée pour tout usager (donc une seule valeur par serveur), ou même la plus petite valeur que le serveur permet d’établir pour tout usager. Le serveur DEVRAIT ajouter le jeton "USER" au paramètre EXPIRE dans l’état AUTHENTICATION, pour informer le client qu’une valeur plus précise sera disponible après l’authentification. Le serveur DEVRAIT annoncer la valeur plus précise dans l’état TRANSACTION. (Le jeton "USER" permet au client de décider si une seconde commande CAPA est ou non nécessaire.)
Un site peut avoir une politique d’expiration des messages qui traite les messages différemment selon l’action d’usager qui est effectuée, ou sur la base d’autres facteurs. Par exemple, un site peut supprimer des messages non lus après 60 jours, et les messages complètement- ou partiellement – lus après 15 jours.
La valeur EXPIRE annoncée est la plus petite période de rétention qui est ou pourrait être utilisée par toute catégorie ou condition de la politique actuelle du site, pour tout usager (dans l’état AUTHENTICATION) ou l’usager spécifique (dans l’état TRANSACTION). C’est-à-dire que EXPIRE informe le client du nombre minimum de jours pendant lesquels les messages peuvent rester sur le serveur dans toutes circonstances.
Exemples :
EXPIRE 5 USER
EXPIRE 30
EXPIRE NEVER
EXPIRE 0
Le premier exemple indique que le serveur peut supprimer les messages après cinq jours, mais que la période diffère selon l’usager, et qu’ainsi une valeur plus précise peut être obtenue en envoyant une seconde commande CAPA dans l’état TRANSACTION. Le second exemple indique que le serveur pourra supprimer les messages après 30 jours. Dans le troisième exemple, le serveur annonce qu’il ne supprime pas les messages. Le quatrième exemple spécifie que le site ne permet pas que les messages soient laissés sur le serveur.
Étiquette CAPA : UIDL
Arguments : aucun
Commandes ajoutées : UIDL
Commandes standard affectées : aucune
États annoncés / différences possibles : les deux / non
Commandes valides dans les états : TRANSACTION
Spécification de référence : [POP3]
Discussion : La capacité UIDL indique que la commande facultative UIDL est prise en charge.
Étiquette CAPA : IMPLEMENTATION
Arguments : chaîne donnant des informations sur la mise en œuvre du serveur
Commandes ajoutées : aucun
Commandes standard affectées : aucune
États annoncés / différences possibles : les deux (facultativement, seulement TRANSACTION) / non
Commandes valides dans les états : non disponible
Spécification de référence : le présent document
Discussion :
Il est souvent utile d’identifier la mise en œuvre d’un serveur particulier (par exemple, lors de la connexion). C’est fait habituellement dans la bannière de bienvenue, mais on peut se demander si une chaîne est un identifiant de mise en œuvre ou non.
L’argument de la capacité IMPLEMENTATION consiste en un ou plusieurs jetons qui identifient le serveur. (Noter que comme les arguments d’étiquette de réponse CAPA sont séparés par des espaces, il peut être pratique pour l’argument de capacité IMPLEMENTATION de ne pas contenir d’espaces, de sorte qu’il est d’un seul jeton.)
Normalement, les serveurs annoncent IMPLEMENTATION dans les deux états. Cependant, un serveur PEUT choisir de ne faire ainsi que dans l’état TRANSACTION.
Un serveur PEUT inclure l’identification de la mise en œuvre à la fois dans la bannière de bienvenue et dans la capacité IMPLEMENTATION.
Les clients NE DOIVENT PAS modifier leur comportement selon la mise en œuvre du serveur. Le serveur et le client devraient au lieu de cela se mettre d’accord sur une extension privée.
De futures extensions à POP3 sont en général déconseillées, car l’utilité de POP3 réside dans sa simplicité. POP3 est destiné à être un protocole de téléchargement et de suppression ; les capacités d’accès à la messagerie sont disponibles dans IMAP [IMAP4]. Les extensions qui prennent en charge l’ajout de boîtes aux lettres supplémentaires, permettent le téléchargement de messages sur le serveur, ou qui dévient du modèle de téléchargement et suppression de POP sont fortement déconseillées et ont peu de chances d’être autorisées dans la perspective de la normalisation IETF.
Les clients NE DOIVENT PAS exiger la présence d’extensions pour les fonctionnalités de base, à l’exception des commandes d’authentification (APOP, AUTH [paragraphe 6.3] et USER/PASS).
La section 9 spécifie comment les capacités supplémentaires sont définies.
POP3 sans extension est seulement capable d’indiquer le succès ou l’échec de la plupart des commandes. Malheureusement, les clients ont souvent besoin d’avoir plus d’informations sur la cause d’un échec afin de bien récupérer. Cela est particulièrement important en réponse à un échec de connexion (il y a des clients très au courant qui essayent de décoder le texte d’erreur d’un résultat de commande PASS, pour essayer de faire la distinction entre "unable to get maildrop lock" et "bad login").
La présente spécification amende la norme POP3 pour permettre un code de réponse facultatif, inclus entre des crochets, au début d’une portion de texte lisible par l’homme d’une réponse "+OK" ou "-ERR". Les clients qui acceptent cette extension PEUVENT retirer toute information incluse dans des crochets avant d’afficher le texte lisible par l’homme à l’usager. Immédiatement après le caractère "[" crochet ouvert se trouve un code de réponse qui est interprété de façon insensible à la casse par le client.
Le code de réponse est hiérarchique, avec une "/" séparant les niveaux de détail sur l’erreur. Les clients DOIVENT ignorer les détails hiérarchiques inconnus sur le code de réponse. Ceci est important, car ils pourraient être nécessaires pour fournir à l’avenir d’autres détails des codes de réponse.
La section 3 décrit les codes de réponse en [ABNF].
Si un serveur accepte les codes de réponse étendus, il l’indique en incluant la capacité RESP-CODES dans la réponse CAPA.
Exemples :
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: -ERR [IN-USE] Avez-vous une autre session POP en cours ?
La présente spécification définit deux codes de réponse POP3 qui peuvent être utilisés pour déterminer la raison d’un échec de connexion. La section 9 spécifie comment sont définis des codes de réponse supplémentaires.
Il survient sur une réponse -ERR à une commande AUTH, USER (voir la note), PASS ou APOP et indique que l’usager s’est connecté récemment et ne sera pas autorisé à se reconnecter jusqu’à ce que la période d’attente de connexion soit achevée.
NOTE : Retourner le code de réponse LOGIN-DELAY à la commande USER évite le travail d’authentification de l’usager mais révèle au client que l’usager spécifié existe. Sauf si le serveur fonctionne dans un environnement où les noms d’utilisateur ne sont pas secrets (par exemple, de nombreux clients de messagerie électronique très connus publient le nom du serveur POP et le nom d’utilisateur dans un en-tête de message sortant), ou si l’accès au serveur est protégé, ou si le serveur peut vérifier que la connexion est pour le même usager, il est fortement recommandé que le serveur ne produise pas ce code de réponse dans la commande USER. Le serveur économise ainsi le coût de l’ouverture de la boîte aux lettres, ce qui dans certains environnements est l’étape la plus coûteuse.
Il survient sur une réponse -ERR à une commande AUTH, APOP, ou PASS. Il indique que l’authentification a réussi, mais que la boîte aux lettres de l’usager est actuellement utilisée (probablement par un autre client POP3).
Le présent document demande à l’IANA de tenir deux nouveaux registres : capacités POP3 et codes de réponse POP3.
Les nouvelles capacités POP3 DOIVENT être définies dans une RFC en cours de normalisation ou approuvée par l’IESG, et NE DOIVENT PAS commencer par la lettre "X".
Les nouvelles capacités POP3 DOIVENT inclure les informations suivantes :
Étiquette CAPA
Arguments
Commandes ajoutées
Commandes standard affectées
États annoncés / différences possibles
Commandes valides dans les états
Référence de spécification
Discussion
De plus, de nouvelles limites des longueurs des commandes et réponses POP3 peuvent devoir être incluses.
Les nouveaux codes de réponse POP3 DOIVENT être définis dans une RFC ou autre référence permanente et disponible de façon fiable, en détails suffisants pour que l’interopérabilité entre des mises en œuvre indépendantes soit possible. (C’est la politique "Spécification exigée" décrite dans [IANA]).
Les spécifications de code de réponse POP3 DOIVENT inclure les informations suivantes : le code de réponse complet, pour lequel les réponses (+OK ou -ERR) et les commandes sont valides, et une définition de sa signification et du comportement attendu du client.
Une liste de capacités peut révéler des informations sur les mécanismes d’authentification du serveur qui peuvent être utilisés pour déterminer si certaines attaques seront couronnées de succès. Cependant, permettre aux clients de détecter automatiquement la disponibilité de mécanismes plus forts et d’altérer leurs configurations pour les utiliser peut améliorer la sécurité globale d’un site.
Le paragraphe 8.1 expose les questions de sécurité en rapport avec l’utilisation du code de réponse LOGIN-DELAY avec la commande USER.
Le présent document a été révisé en partie sur la base des commentaires et discussions qui ont eu lieu au sein de la liste de diffusion Extensions POP3 de l’IETF. L’aide de ceux qui ont pris le temps de réviser le présent mémoire et d’y faire des suggestions a été précieuse, en particulier celle de Alexey Melnikov, Harald Alvestrand, et Mike Gahrns.
[ABNF] D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", RFC 2234, novembre 1997.
[IANA] T. Narten et H. Alvestrand, "Conseils pour la rédaction d’une section Considérations relatives à l’IANA dans les RFC", BCP 26, RFC 2434, octobre 1998.
[IMAP4] M. Crispin, "Protocole d’accès aux messages Internet -- Version 4rev1", RFC 2060, décembre 1996.
[KEYWORDS] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d’exigence", BCP 14, RFC 2119, mars 1997.
[PIPELINING] N. Freed, "Extension de service SMTP pour l’intubage de commandes", RFC 2197, septembre 1997.
[POP3] J. Myers et M. Rose, "Protocole Post Office -- Version 3", STD 53, RFC 1939, mai 1996.
[POP-AUTH] J. Myers, "Commande AUTHentification de POP3", RFC 1734, décembre 1994.
[SASL] J. Myers, "Authentification simple et couche de sécurité (SASL)", RFC 2222, octobre 1997.
[SMTP] J. Postel, "Protocole simple de transfert de messagerie ", STD 10, RFC 821, août 1982.
Randall Gellens |
Chris Newman |
Laurence Lundblade |
QUALCOMM Incorporated |
Innosoft International, Inc. |
QUALCOMM Incorporated |
6455 Lusk Blvd. |
1050 Lakes Drive |
6455 Lusk Blvd. |
San Diego, CA 92121-2779 |
West Covina, CA 91790 |
San Diego, Ca, 92121-2779 |
USA |
USA |
USA |
téléphone : +1 619 651 5115 |
|
téléphone : +1 619 658 3584 |
Fax: +1 619 845 7268 |
|
Fax : +1 619 845 7268 |
mèl : randy@qualcomm.com |
mèl : chris.newman@innosoft.com |
mèl : lgl@qualcomm.com |
Copyright (C) The Internet Society (1998). Tous droits réservés.
Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les copyrights définis dans les processus de normes pour Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.
Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.
Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et L'INTERNET SOCIETY ET L'INTERNET ENGINEERING TASK FORCE DÉCLINE TOUTE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER, TOUTE GARANTIE QUE L'UTILISATION DE L'INFORMATION ICI PRÉSENTE N'ENFREINDRA AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D'ADAPTATION A UN OBJET PARTICULIER.