Aller au contenu principal

RFC 6530 - Aperçu et cadre pour le courrier électronique internationalisé

  • Statut: Proposition de norme

  • Publié: février 2012

  • Flux: IETF

  • Rend obsolètes: RFC 4952, RFC 5504, RFC 5825

  • Errata: Recherche d'errata

Informations sur les documents​

  • Numéro RFC: 6530

  • Titre: Aperçu et cadre pour le courrier électronique internationalisé

  • Auteurs: J. Klensin, Y. Ko

  • Date: février 2012

  • Catégorie: Standards Track

  • Rend obsolètes: RFC 4952, RFC 5504, RFC 5825

  • ISSN: 2070-1721

Résumé​

Pour que le courrier électronique puisse être pleinement utilisé partout dans le monde, les personnes doivent pouvoir employer des variantes proches de leur propre nom, correctement écrites dans leur langue et leur système d'écriture, comme noms de boîte aux lettres dans les adresses électroniques. Le présent document introduit une série de spécifications définissant les mécanismes et extensions de protocole nécessaires à la prise en charge complète des adresses électroniques internationalisées. Ces changements comprennent une extension SMTP et une extension de la syntaxe des en-têtes de courrier afin d'accepter des données UTF-8. Cet ensemble de documents examine aussi les principales hypothèses et les difficultés liées au déploiement d'un courrier entièrement internationalisé. Le présent document remplace la RFC 4952 et tient compte de problèmes supplémentaires identifiés depuis sa publication.

Statut de ce mémo​

Le présent document appartient à la filière de normalisation Internet.

Ce document est un produit du groupe de travail sur l'ingénierie Internet (IETF). Il représente le consensus de la communauté IETF. Il a reçu un examen public et a été approuvé pour publication par le groupe directeur de l'ingénierie Internet (IESG).

L'état actuel du présent document, les errata éventuels et les modalités de retour d'information sont disponibles à l'adresse http://www.rfc-editor.org/info/rfc6530.

Avis sur le droit d'auteur​

Copyright (c) 2012 IETF Trust et les personnes identifiées comme auteurs du document.

Ce document est soumis au BCP 78 et aux dispositions juridiques de l'IETF Trust relatives aux documents de l'IETF (http://trustee.ietf.org/license-info) en vigueur à la date de sa publication. Veuillez les lire attentivement, car elles décrivent vos droits et les restrictions applicables au présent document. Les composants de code extraits de ce document doivent inclure le texte de licence BSD simplifiée décrit à la section 4.e de ces dispositions et sont fournis sans garantie, conformément à cette licence.

Ce document peut contenir du matériel des Documents de l'IETF ou des Contributions de l'IETF publiés ou rendus publics avant le 10 novembre 2008. La personne qui contrôle le droit d'auteur sur certains de ces documents peut ne pas avoir accordé au IETF Trust le droit d'autoriser des modifications de ce matériel en dehors du processus de normes de l'IETF. Sans obtenir une licence adéquate de la personne qui contrôle le droit d'auteur sur ces matériaux, ce document ne peut pas être modifié en dehors du processus de normes de l'IETF, et ses œuvres dérivées ne peuvent pas être créées en dehors du processus de normes de l'IETF, sauf pour le formater pour publication en tant que RFC ou pour le traduire en langues autres que l'anglais.

Table des matières​

  1. Introduction
  2. Rôle de cette spécification
  3. Énoncé du problème
  4. Terminologie
  5. Aperçu de l'approche et plan documentaire
  6. Bilan des résultats expérimentaux
  7. Aperçu des extensions et modifications de protocole
  8. Rétrogradation avant et après les transactions SMTP
  9. Rétrogradation en transit
  10. Questions d'interface utilisateur et de configuration
  11. Questions supplémentaires
  12. Principales modifications par rapport aux protocoles expérimentaux et à leur cadre
  13. Considérations de sécurité
  14. Remerciements
  15. Références

1. Introduction​

Pour utiliser les adresses e-mail internationalement, il est nécessaire d'internationaliser à la fois la partie de domaine et la partie locale des adresses e-mail. La partie de domaine des adresses e-mail est déjà internationalement [RFC5890], tandis que la partie locale n'est pas. Sans les extensions spécifiées dans ce document, le nom de la boîte aux lettres est limité à un sous-ensemble de 7 bits ASCII [RFC5321]. Bien que MIME [RFC2045] permet le transport de données non ASCII, il ne fournit pas de mécanisme pour les adresses e-mail internationalement. Dans RFC 2047 [RFC2047], MIME définit un mécanisme de codage pour certains champs d'en-tête de message spécifiques pour accueillir des données non ASCII. Cependant, il ne permet pas l'utilisation d'adresses e-mail qui incluent des caractères non ASCII. Sans les extensions définies ici, ou un ensemble équivalent, la seule façon d'incorporer des caractères non ASCII dans n'importe quelle partie des adresses e-mail est d'utiliser le codage RFC 2047 pour les intégrer dans ce que RFC 5322 [RFC5322] appelle le "nom d'affichage" (connu sous le nom de "phrase de nom" ou par d'autres termes ailleurs) des champs d'en-tête pertinents. Les informations codées dans le nom d'affichage sont invisibles dans l'enveloppe du message et, à de nombreuses fins, ne font pas partie du nom de l'adresse du tout.

Ce document remplace la RFC 4952 [RFC4952]; il reflète des problèmes supplémentaires, une terminologie commune et certains changements architecturaux identifiés depuis la publication de celle-ci, qu'il rend obsolète. Les descriptions expérimentales de la rétrogradation en transit [RFC5504] [RFC5825] sont désormais sans objet et ne sont plus nécessaires en raison des changements présentés à la section 12. Le RFC Editor est prié de classer ces trois documents dans la catégorie Historic.

Les pronoms "il" et "elle" sont utilisés de manière interchangeable pour indiquer un humain de sexe indéterminé.

Les mots clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « MAY » et « OPTIONAL » employés dans ce document doivent être interprétés comme décrit dans le BCP 14, RFC 2119 [RFC2119].

2. Le rôle de cette spécification​

Ce document présente l'aperçu et le cadre d'une approche de la prochaine étape de l'internationalisation des e-mails. Cette nouvelle étape nécessite non seulement l'internationalisation des adresses et des champs d'en-tête, mais aussi des modèles de transport et de livraison associés. Une version antérieure de cette spécification, RFC 4952 [RFC4952], fournit également une introduction à une série de protocoles expérimentaux [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825]. Ce formulaire révisé fournit un aperçu et des informations conceptuelles pour les successeurs de la piste de normes d'un sous-ensemble de ces protocoles. Les détails des documents et les relations entre eux apparaissent dans la section 5 et une discussion de ce qui a été appris des protocoles expérimentaux et de leurs implémentations apparaît dans la section 6.

Ensemble, ces spécifications fournissent les détails d'une façon de mettre en œuvre et de soutenir le courrier électronique international. Le document lui-même décrit comment les différents éléments de l'internationalisation du courrier électronique se combinent et les relations entre les principales spécifications associées au transport de messages, aux formats d'en-tête et à la manutention.

Ce document, ainsi que d'autres qui comprennent la collection décrite ci-dessus, prennent une connaissance raisonnable des spécifications et terminologies de base de la messagerie électronique Internet [RFC5321] [RFC5322] et des MIME [RFC2045] et 8BITMIME [RFC6152] aussi bien. Bien que pas strictement nécessaire pour mettre en œuvre cette spécification, une connaissance générale de la terminologie et des fonctions de IDNA [RFC5890] [RFC5891] [RFC5892] [RFC5893] [RFC5894] sont également présumées.

3. Énoncé du problème​

L'internationalisation des noms de domaine dans les applications (IDNA) [RFC5890] permet les noms de domaine internationaux, mais le déploiement n'a pas encore atteint la plupart des utilisateurs. L'une des raisons est que nous n'avons pas encore de systèmes de nommage entièrement internationaux. Les noms de domaine ne sont qu'un des divers noms et identifiants qui doivent être internationaux. Dans de nombreux contextes, jusqu'à ce que plus de ces identifiants soient internationaux, les noms de domaine internationaux seuls ont peu de valeur.

Les adresses e-mail sont des exemples principaux de la raison pour laquelle il n'est pas suffisant de simplement internationaaliser le nom de domaine. Comme la plupart des observateurs l'ont appris par expérience, les utilisateurs préfèrent fortement les adresses e-mail qui ressemblent à des noms ou des initiales à celles impliquant des chaînes de lettres ou de chiffres apparemment sans sens. À moins que l'ensemble de l'adresse e-mail puisse utiliser des caractères et des formats familiers, les utilisateurs perçoivent le courrier électronique comme étant culturellement hostile. Si les noms et les initiales utilisés dans les adresses e-mail peuvent être exprimés dans les langues et systèmes d'écriture natifs des utilisateurs, Internet sera perçu comme plus naturel, en particulier par ceux dont la langue maternelle n'est pas écrite dans un sous-ensemble d'un script dérivé de la tradition romaine.

L'internationalisation des adresses e-mail ne consiste pas simplement à modifier l'enveloppe SMTP; ou à modifier les champs d'en-tête "De:", "À:", et "Cc:"; ou à permettre aux agents utilisateurs de messagerie (MUA) améliorés de décoder un codage spécial et de répondre en affichant des caractères locaux. Pour être perçus comme utilisables, les adresses doivent être internationalizées et gérées de manière cohérente dans tous les contextes dans lesquels elles se produisent. Cette exigence a des implications de grande envergure: les collections de correctifs et de solutions de travail ne sont pas adéquates. Même si elles étaient adéquates, une approche basée sur la solution de travail peut entraîner une variété d'impléments avec différents ensembles de correctifs et de solutions de travail ayant été appliquées avec une confusion conséquente de l'utilisateur sur ce qui est réellement acceptable et supporté. Nous devons construire un environnement de messagerie entièrement internationalisé, en nous concentrant sur la communication efficace entre ceux qui partagent un système de langue et d'écriture. Cela implique à son tour des changements dans l'environnement d'en-tête de messagerie pour permettre à ces champs d'en-tête qui sont appropriément internationaux d'utiliser la gamme complète de caractères Unicode, une extension SMTP pour permettre l'adressage de messagerie UTF-8 [RFC3629] [RFC5198] et la livraison de ces champs d'en-tête étendus, le support pour l'internationalisation des notifications de livraison et de service [RFC3461] [RFC3464], et (finellement) une exigence de soutien de l'extension SMTP 8BITMIME [RFC6152] afin que tous ceux-ci puissent être transportés à travers le système de messagerie sans avoir à surmonter la limitation que les champs d'en-tête ne disposent pas de transférencodings.

4. Terminologie​

Le présent document suppose une compréhension raisonnable des protocoles et de la terminologie des normes de base de messagerie, tels que documentés dans les RFC 5321 [RFC5321] et RFC 5322 [RFC5322].

4.1. Utilisateurs et agents de transfert du courrier​

Une grande partie de la description de ce document dépend des abstractions de "Mail Transfer Agent" ("MTA") et "Mail User Agent" ("MUA"). Cependant, il est important de comprendre que ces termes et les concepts sous-jacents datent de la conception de l'architecture de courrier électronique d'Internet et de l'application du principe des "protocoles sur le fil" à elle. Cette architecture de courrier électronique, telle qu'elle a évolué, et ce principe "sur le fil" ont empêché toute distinction forte et normalisée sur la façon dont les MTA et les MUA interagissent sur un hôte d'origine ou de destination donné (ou même si elles sont séparées).

Cependant, le terme "MTA de livraison finale" est utilisé dans ce document d'une manière équivalente au terme "système de livraison" ou "système de livraison finale" de la RFC 5321. C'est le serveur SMTP qui contrôle le format des parties locales des adresses et est autorisé à les inspecter et à les interpréter. Il reçoit des messages du réseau pour la livraison aux boîtes postales ou pour un autre traitement local, y compris tout transfert ou aliasing qui change les adresses d'enveloppe, plutôt que de relayer. Du point de vue du réseau, tout arrangement de livraison local tel que l'enregistrement dans un magasin de messages, la remise à des programmes ou agents de livraison de messages spécifiques, et les mécanismes de récupération de messages sont tous "derrière" le MTA de livraison finale et ne font donc pas partie du processus de transport ou de livraison SMTP.

4.2. Jeux de caractères des adresses​

Dans ce document, une adresse est "toute ASCII", ou simplement "adresse ASCII", si chaque caractère de l'adresse est dans le répertoire de caractères ASCII [ASCII]; une adresse est "non-ASCII", ou une "i18n-adresse", si un caractère n'est pas dans le répertoire de caractères ASCII. De telles adresses peuvent être restreintes d'autres manières, mais ces restrictions ne sont pas pertinentes pour cette définition. Le terme "toute ASCII" est également appliqué à d'autres éléments de protocole lorsque la distinction est importante, avec "non-ASCII" ou "internationalisé" comme son contraire.

Le terme général décrivant l'internationalisation de l'adresse e-mail spécifiée par le présent document et ses documents d'accompagnement est "SMTPUTF8". Par exemple, une adresse autorisée par ce document est appelée "SMTPUTF8 (adresses conformes).

Veuillez noter que, selon les définitions données ici, l'ensemble de toutes les adresses "toutes ASCII" et l'ensemble de toutes les adresses "non ASCII" sont mutuellement exclusives.

4.3. Types d'utilisateurs​

Un "utilisateur ASCII" (i) utilise exclusivement des adresses e-mail qui ne contiennent que des caractères ASCII et (ii) ne peut pas générer des adresses destinataires qui ne contiennent pas de caractères ASCII.

Un "utilisateur d'e-mail internationalisé" a une ou plusieurs adresses e-mail non ASCII, ou est capable de générer des adresses destinataires qui contiennent des caractères non ASCII. Un tel utilisateur peut également avoir des adresses ASCII; si l'utilisateur a plus d'un compte e-mail et une adresse correspondante, ou plus d'un alias pour la même adresse, il ou elle a une méthode pour choisir l'adresse à utiliser sur le courrier électronique sortant. Notez qu'en vertu de cette définition, il n'est pas possible de dire à partir d'une adresse ASCII si le propriétaire de cette adresse est un utilisateur d'e-mail internationalisé ou non. (Une adresse non ASCII implique une croyance que le propriétaire de cette adresse est un utilisateur d'e-mail internationalisé.) Il n'y a pas de telle chose comme un "message d'e-mail internationalisé"; le terme s'applique uniquement aux utilisateurs et à leurs agents et capacités utilisateurs. En particulier, l'utilisation de contenus non ASCII, et donc présumément internationaux, des messages fait partie intégrante des spécifications MIME [RFC2045] et ne nécessite pas ces extensions (bien qu'il soit compatible avec elles).

4.4. Messages​

Un "message" est envoyé d'un utilisateur (l'expéditeur) à l'aide d'une adresse e-mail particulière à une ou plusieurs autres adresses e-mail destinataires (souvent désignées simplement comme "utilisateurs" ou "utilisateurs destinataires").

4.5. Listes de diffusion​

Une " liste de diffusion " est un mécanisme par lequel un message peut être distribué à plusieurs destinataires en l'envoyant à une seule adresse destinataire. Un agent (généralement pas un être humain) à cette adresse unique fait ensuite que le message soit redistribué aux destinataires cibles. Cet agent fixe l'adresse de retour de l'enveloppe du message redistribué à une adresse différente de celle du message original. L'utilisation d'une adresse de retour d'enveloppe différente (route inverse) provoque un traitement d'erreur (et d'autres messages générés automatiquement) pour se rendre à une adresse d'erreur.

Les dispositions spéciales relatives à la gestion des listes de diffusion qui pourraient contenir des adresses non ASCII sont discutées dans un document spécifique à ce sujet [RFC5983] et à son successeur attendu [RFC5983bis-MailingList].

4.6. Message conventionnel et message internationalisé​

  • Un message conventionnel est celui qui n'utilise aucune extension définie dans le document d'extension SMTP [RFC6531] ou dans le document UTF8header [RFC6532] dans cet ensemble de spécifications, et qui est strictement conforme à la RFC 5322 [RFC5322].

  • Un message international est un message qui utilise une ou plusieurs des extensions définies dans cet ensemble de spécifications, de sorte qu'il ne soit plus conforme à la spécification traditionnelle d'un message électronique ou de son transport.

4.7. Messages non distribuables, notifications et accusés de remise​

Comme spécifié dans RFC 5321, un message qui n'est pas livrable pour une raison quelconque est prévu de se traduire par une notification à l'expéditeur. Cela peut se produire de l'une des deux façons. L'une, généralement appelée "Réjection", se produit lorsqu'un serveur SMTP renvoie un code de réponse indiquant une erreur fatale (un code "5yz") ou renvoie persistamment une erreur d'échec temporaire (un code "4yz"). L'autre implique d'accepter le message lors du traitement SMTP et de générer un message à l'expéditeur, généralement connu sous le nom de "Notification de non-livrabilité" ou "NDN". La pratique actuelle favorise souvent le rejet sur les NDN en raison de la probabilité réduite que la génération de NDN sera utilisée comme technique de spam.

Un expéditeur PEUT également demander explicitement des reçus de message [RFC3461] qui soulèvent les mêmes problèmes pour ces extensions d'internationalisation que les NND.

5. Aperçu de l'approche et plan documentaire​

Ce jeu de spécifications modifie à la fois le SMTP et le codage des caractères des en-têtes de messages de messagerie pour permettre aux caractères non ASCII d'être représentés directement. Chaque composant important du travail est décrit dans un document séparé.

En plus de ce document, les documents suivants constituent cette spécification et fournissent des conseils et un contexte.

  • Extension SMTP. Le document d'extension SMTP [RFC6531] fournit une extension SMTP (selon ce qui est prévu dans la RFC 5321) pour les adresses internationalement établies.

  • En-têtes de message de courrier électronique dans UTF-8. Le document en-tête de message de courrier électronique [RFC6532] met essentiellement à jour RFC 5322 pour permettre à certaines informations dans les en-têtes de message de courrier électronique d'être exprimées directement par des caractères Unicode codés dans UTF-8 lorsque l'extension SMTP décrite ci-dessus est utilisée. Ce document, éventuellement avec un ou plusieurs suppléments, devra également traiter les interactions avec MIME, y compris les relations entre SMTPUTF8 et les en-têtes et types de contenu internes de MIME.

  • Extensions du statut de livraison et du traitement des notifications pour s'adapter aux adresses internationalement établies [RFC6533].

  • ** Les documents à venir** spécifieront des extensions au protocole IMAP [RFC3501] pour prendre en charge les en-têtes de message internationaux [RFC5738bis-IMAP], des extensions parallèles au protocole POP [RFC5721] [RFC5721bis-POP3] et certaines propriétés communes des deux [POPIMAP-Downgrade].

6. Bilan des résultats expérimentaux​

La différence clé entre ce jeu de protocoles et le jeu expérimental qui les a précédés [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825] est que le groupe antérieur a fourni un mécanisme de dégradation de messages en transit (décrit en détail dans RFC 5504). Ce mécanisme a permis et exigé essentiellement que chaque adresse non ASCII soit accompagnée d'un équivalent ASCII. Cela a, à son tour, soulevé des inquiétudes de sécurité associées à l'association d'adresses qui ne pouvaient pas être authentifiées. Après avoir examiné l'expérience acquise avec les précédents, expérimentaux et prédécesseurs de ces spécifications, le groupe de travail qui les a élaborées a conclu que les avantages de la dégradation du niveau de transit, s'il était opérationnellement possible, seraient suffisamment importants pour surmonter ces préoccupations.

Avant de commencer les travaux qui ont conduit à ce jeu de spécifications, le GW a conclu que la combinaison des exigences et des implications à long terme de ce modèle antérieur était trop complexe pour être satisfaisante et que les travaux devaient aller de l'avant sans lui.

L'autre changement important apporté aux protocoles eux-mêmes est que le mot clé SMTPUTF8 est désormais requis comme annonce client SMTP si l'extension est nécessaire; dans la version expérimentale, seule l'annonce du serveur selon laquelle une enveloppe et/ou un contenu étendu étaient autorisés était nécessaire.

7. Aperçu des extensions et modifications de protocole​

7.1. Extension SMTP pour les adresses électroniques internationalisées​

Une extension SMTP, "SMTPUTF8", est spécifiée comme suit:

  • Permet l'utilisation de chaînes UTF-8 dans les adresses e-mail, à la fois les parties locales et les noms de domaine.

  • Permet l'utilisation sélective des chaînes UTF-8 dans les en-têtes de messages de messagerie (voir rubrique 7.2).

  • Il exige que le serveur publie l'extension 8BITMIME [RFC6152] et que le client supporte la transmission à 8 bits afin que les informations en en-tête puissent être transmises sans utiliser un codage spécial de transfert de contenu.

Certains principes généraux influencent les décisions de développement qui sous-tendent ce travail.

  1. Les adresses e-mail entrent dans des sous-systèmes (tels qu'une interface utilisateur) qui peuvent effectuer des conversions de cartographie ou d'autres modifications de codage. Lorsque la partie locale de l'adresse comprend des caractères en dehors du répertoire de caractères ASCII, l'utilisation de l'encodage ASCII-compatible (ACE) [RFC3492] [RFC5890] dans la partie de domaine est déconseillée pour promouvoir un traitement cohérent des caractères dans toute l'adresse.

  2. Un relais SMTP MUST:

    • soit reconnaître explicitement le format et accepter de le traiter au moyen d'une option ESMTP;

    • soit rejeter le message ou, si nécessaire, renvoyer une notification de non-remise afin que l'expéditeur puisse choisir une autre solution.

  3. Si le message ne peut pas être transféré parce que le système du prochain saut n'accepte pas l'extension, il MUST être rejeté, ou une notification de non-remise MUST être générée et envoyée.

  4. Dans l'intérêt de l'interopérabilité, les charsets autres que UTF-8 sont interdits dans les adresses de courrier et les en-têtes de message qui sont transmises via Internet. Il n'y a pas de moyen pratique d'identifier correctement plusieurs charsets avec une extension similaire sans introduire une grande complexité.

La conformité à l'ensemble de normes spécifié ici pour le transport et la remise du courrier exige la mise en œuvre de l'extension SMTP et de la spécification des en-têtes UTF-8. Si le système implémente IMAP ou POP, il MUST se conformer respectivement aux spécifications internationalisées d'IMAP [RFC5738bis-IMAP] ou de POP [RFC5721bis-POP3].

7.2. Transmission des champs d'en-tête de courrier électronique en codage UTF-8​

Il existe de nombreux endroits dans les MUA ou dans une présentation utilisateur où apparaissent des adresses e-mail ou des noms de domaine. Les exemples incluent les champs d'en-tête "De:", "À:", ou "Cc:" conventionnels; les champs d'en-tête "Message-ID:" et "In-Reply-To:" qui contiennent normalement des noms de domaine (mais ce peut être un cas spécial); et dans les corps de message. Chacun de ces éléments doit être examiné dans une perspective d'internationalisation. L'utilisateur s'attend à voir la boîte aux lettres et les noms de domaine dans des caractères locaux, et à les voir de manière cohérente. Si des codage non évidents, tels que les variantes ACE spécifiques au protocole, sont utilisés, l'utilisateur les verra inévitablement, sinon seulement occasionnellement, plutôt que des caractères "natifs" et trouvera cela déconcertant ou étonnant. De même, si des codes différents sont utilisés pour le transport de courrier et les corps de message, l'utilisateur est particulièrement susceptible de se surprendre, même si cela est dû au principe de " fuite de choses " établi depuis longtemps.

Lorsque les parties locales des adresses sont internationalisées, des dispositions SHOULD être prises pour que les en-têtes de message le soient entièrement eux aussi. Cette forme SHOULD utiliser UTF-8 plutôt qu'ASCII comme jeu de caractères de base du contenu des champs d'en-tête; les éléments de protocole tels que les noms des champs restent inchangés et entièrement en ASCII. Pour la transition et la compatibilité avec les systèmes anciens, les modèles MIME traditionnels de codage des caractères non ASCII dans les en-têtes [RFC2045] [RFC2231] peuvent être étendus, mais ils devraient eux-mêmes reposer sur UTF-8 plutôt que sur d'autres codages lorsque cela est possible [RFC6055]. La cible reste toutefois l'en-tête de message entièrement internationalisé décrit dans [RFC6532], et non une transition longue et pénible.

7.3. Extension du service SMTP pour les DSN​

La spécification existante des notifications d'état de remise (Delivery Status Notifications, DSN) [RFC3461], alors Draft Standard, limite au texte ASCII les parties du protocole lisibles par machine. « International Delivery and Disposition Notifications » [RFC6533] ajoute un type d'adresse pour les adresses internationalisées afin que l'adresse d'origine d'un destinataire contenant des caractères non ASCII puisse être conservée correctement même après rétrogradation. Si un serveur SMTP annonce à la fois SMTPUTF8 et l'extension DSN, il MUST implémenter les DSN internationalisées, y compris le paramètre ORCPT défini dans la RFC 3461 [RFC3461].

8. Rétrogradation avant et après les transactions SMTP​

Un problème important avec ces extensions est la façon de gérer les interactions entre les systèmes qui prennent en charge les adresses non ASCII et les systèmes anciens qui s'attendent à ASCII. Il n'y a, bien sûr, aucun problème avec les systèmes ASCII envoyés à ceux qui peuvent traiter des formulaires internationaux parce que les formulaires ASCII ne sont qu'un sous-ensemble approprié. Mais, lorsque les systèmes qui prennent en charge ces extensions envoient du courrier, ils peuvent inclure des adresses non ASCII pour les expéditeurs, les récepteurs ou les deux et peuvent également fournir des informations d'en-tête non ASCII autres que les adresses. Si l'extension n'est pas prise en charge par le système de première sortie (c'est-à-dire le serveur SMTP accédé par le serveur de soumission agissant en tant que client SMTP), les systèmes d'origine de message DEVRAient être prêts à envoyer des enveloppes et des en-têtes de message conventionnels ou à renvoyer le message à l'utilisateur d'origine afin que le message puisse être dégradé manuellement à la forme traditionnelle, éventuellement en utilisant des mots codés [RFC2047] dans les en-têtes de message. Bien sûr, ces transformations impliquent que l'utilisateur ou le système d'origine doit avoir des adresses ASCII uniquement disponibles pour tous les expéditeurs et les destinataires. Les mécanismes par lesquels de telles adresses peuvent être trouvées ou identifiées sont en dehors de la portée de ces spécifications, comme les décisions concernant la conception des systèmes d'origine telles que si des transformations requises sont faites par l'utilisateur, l'utilisateur ou le serveur de soumission MUA.

Une situation un peu plus complexe se produit lorsque le système de premier bond prend en charge ces extensions mais que certains serveurs ultérieurs de la chaîne de transmission SMTP ne le font pas. Il est important de noter que la plupart des cas de cette situation avec des adresses de pointe vers l'avant seront le résultat d'erreurs de configuration: en particulier si elle héberge des adresses non ASCII, une MTA de livraison finale qui accepte ces extensions NE DEVRAIT PAS être configurée avec des hôtes MX de faible préférence qui ne le font pas. Lorsque le seul adresse non ASCII qui est transmise est de pointe vers l'arrière (par exemple, dans un SMTP MAIL), la configuration du destinataire ne peut pas s'aider en général. D'autre part, les adresses alternatives, toutes ASCII pour les expéditeurs sont celles qui sont les plus susceptibles d'être connues de manière autoritaire par l'environnement de soumission ou l'expéditeur. Par conséquent, si un relais SMTP intermédiaire qui nécessite ces extensions découvre que le prochain système de la chaîne ne les prend pas en charge, il n'aura pas d'autre choix que de rejeter ou de retourner le message.

Comme mentionné ci-dessus, la dégradation à un formulaire ASCII uniquement peut se produire avant ou pendant la soumission initiale du message. Il peut également se produire après la livraison au MTA de livraison finale afin d'accueillir les magasins de messages, les serveurs IMAP ou POP, ou les clients qui ont des capacités différentes de la livraison MTA. Ces cas sont discutés dans les sous-sections ci-dessous.

8.1. Rétrogradation avant ou pendant la soumission du message​

L'IETF a traditionnellement évité de spécifier le comportement précis des MUA pour fournir une flexibilité maximale dans les interfaces utilisateur associées. La norme SMTP [RFC5321], section 6.4, donne une large latitude aux MUA et aux serveurs de soumission quant à ce que l'utilisateur pourrait fournir tant que le résultat est conforme aux normes "sur le fil" une fois injecté dans l'Internet public. Dans cette tradition, la discussion dans le reste de la section 8 est fournie comme une orientation générale plutôt que comme des exigences normatives.

Les messages qui nécessitent ces extensions seront parfois transférés vers un système qui ne prend pas en charge ces extensions; il est probable que les cas les plus courants impliquent la combinaison d'adresses de pointe vers l'avant uniquement ASCII avec une adresse de pointe vers l'arrière non ASCII. Jusqu'à ce que les extensions décrites ici aient été universellement mises en œuvre dans l'environnement de messagerie Internet, les expéditeurs qui préfèrent utiliser des adresses non ASCII (ou des caractères UTF-8 bruts dans les champs d'en-tête), même lorsque leurs destinataires utilisent et s'attendent à tous les ASCII, devront être particulièrement prudents quant aux conditions d'erreur qui peuvent survenir. Les risques sont particulièrement importants dans les environnements dans lesquels les messages non-livrables (ou d'autres indications des serveurs soumis) sont systématiquement abandonnés ou ignorés.

Il est évident que le moment le plus pratique pour trouver une adresse ASCII correspondant à une adresse internationalement est peut-être à l'AU d'origine ou à des systèmes étroitement associés. Cela peut se produire soit avant l'envoi du message, soit après que la forme internationalement modifiée du message ait été rejetée. C'est également le moment le plus pratique pour convertir un message de la forme internationalement modifiée en une forme ASCII conventionnelle ou pour générer un message de non-livraison à l'expéditeur si l'un ou l'autre est nécessaire. À ce stade, l'utilisateur dispose d'un large éventail de choix, y compris le changement d'adresses de pointe arrière, le contact avec le destinataire hors bande pour une adresse alternative, la consultation des annuaires appropriées, la préparation de la traduction des deux adresses et du contenu du message dans une langue différente, etc. Bien qu'il soit naturel de penser que la dégradation des messages est optimalement un processus entièrement automatisé, nous ne devrions pas sous-estimer les capacités d'un utilisateur d'intelligence au moins modérée qui souhaite communiquer avec un autre utilisateur de ce type.

Dans ce contexte, on peut facilement imaginer des modifications aux serveurs de soumission de messages (comme décrit dans RFC 6409 [RFC6409]) afin qu'ils effectuent des opérations de dégradation ou peut-être même de mise à niveau. De telles opérations permettraient de recevoir des messages avec une ou plusieurs des extensions d'internationalisation discutées ici et d'adapter le message sortant, selon les besoins, pour répondre à l'environnement de livraison ou de prochaine sortie que rencontre le serveur de soumission.

8.2. Rétrogradation ou autre traitement après la remise SMTP finale​

Lorsqu'un message électronique est reçu par un MTA de livraison finale, il est généralement stocké sous une forme ou une autre.

L'extension SMTP décrite à la section 7.1 ne protège que dans le transport. Elle n'empêche pas les MUA et les mécanismes de récupération de courrier électronique qui n'ont pas été mis à jour pour comprendre les adresses internationalement enregistrées et les en-têtes de messages UTF-8 d'accéder aux courriels internationalement enregistrés.

Étant donné que le MTA de livraison finale (ou, plus précisément, son agent de stockage de courrier correspondant) ne peut pas supposer en toute sécurité que les agents accédant au stockage de courrier électronique seront toujours capables de gérer les extensions proposées ici, il POURRAIT dégrader les courriels internationaux, spécifiquement identifier les messages qui utilisent ces extensions, ou les deux. Si l'une ou les deux de ces actions devaient être prises, le MTA de livraison finale DOIT inclure un mécanisme pour préserver ou récupérer les formulaires internationaux originaux sans perte d'informations. La préservation de ces informations est nécessaire pour soutenir l'accès par les agents SMTPUTF8 conscients.

9. Rétrogradation en transit​

La spécification SMTP de base (section 2.3.11 de RFC 5321 [RFC5321]) stipule que "en raison d'une longue histoire de problèmes lorsque les hôtes intermédiaires ont tenté d'optimiser le transport en les modifiant, la partie locale DOIT être interprétée et assignée de la sémantique uniquement par l'hôte spécifié dans la partie de domaine de l'adresse".

Le respect de cette règle signifie qu'un mécanisme de dégradation qui transforme la partie locale d'une adresse e-mail ne peut être utilisé en transit. Il ne peut être appliqué que dans les points d'extrémité, en particulier par le MUA ou le serveur de soumission ou par la MTA de livraison finale.

L'une des raisons de cette règle est liée à des systèmes de messagerie anciens qui intègrent des informations de routage de courrier dans la partie locale du champ d'adresse. La transformation de l'adresse électronique détruit ces informations de [email protected] est un itinéraire ("l'utilisateur est atteint via "foo") ou simplement une adresse locale.

10. Interface utilisateur et problèmes de configuration​

L'internationalisation des adresses et des en-têtes de message, en particulier en combinaison avec des variations du codage des caractères inhérentes à Unicode, peut faire des choix prudents des adresses et une configuration prudente des serveurs et des enregistrements DNS encore plus importants que pour le courrier électronique Internet traditionnel. Il est probable que, à mesure que l'expérience se développe avec l'utilisation de ces protocoles, il sera souhaitable de produire un ou plusieurs documents supplémentaires qui offrent des conseils pour la configuration et les interfaces. Un document qui discute des problèmes avec les MUA, en particulier en ce qui concerne la dégradation, devrait être développé. Les sous-sections ci-dessous traitent d'autres problèmes.

10.1. Choix de noms de boîte aux lettres et normalisation Unicode​

Il est vrai que la syntaxe des courriels permet de choisir des noms de boîtes de courrier qui ne sont pas sages en pratique, si l'on veut réellement que les boîtes de courrier soient accessibles à un large éventail d'expéditeurs. Les exemples les plus souvent cités impliquent l'utilisation de la sensibilité au cas et la citation délicate des caractères intégrés dans les parties locales de la boîte de courrier. Ces constructions délibérément inhabituelles sont autorisées par les protocoles, et les serveurs sont censés les soutenir. Bien qu'ils puissent fournir de la valeur dans des cas particuliers, en profitant est presque toujours une mauvaise pratique à moins que l'intention est de créer une certaine forme de sécurité par l'obscurité.

En l'absence de ces extensions, les clients et les serveurs SMTP sont contraints d'utiliser uniquement les adresses autorisées par la RFC 5321. Les parties locales de ces adresses peuvent être composées de caractères ASCII sauf les caractères de contrôle que la RFC 5321 interdit, bien que certains d'entre eux doivent être cités comme spécifié là-bas. Il est remarquable dans un contexte d'internationalisation qu'il existe une longue histoire sur certains systèmes d'utilisation de caractères ASCII surchargés (un caractère, un backspace et un autre caractère) dans une chaîne citée pour approximer les caractères non ASCII. Cette forme d'internationalisation a été autorisée par la RFC 821 [RFC0821] mais est interdite par la RFC 5321 car elle nécessite un caractère backspace (un contrôle C0 interdit). Parce que RFC 5321 (et son prédécesseur, RFC 2821) interdisent l'utilisation de ce caractère dans les noms de boîtes de courrier ASCII et qu'il est encore plus problématique (pour des raisons de canonisation et de normalisation) dans les chaînes non ASCII, le backspace NE DOIT PAS apparaître dans les noms de boîtes de courrier SMTPUTF8.

Pour le cas particulier des noms de boîtes de courrier qui contiennent des caractères non ASCII dans la partie locale, la partie de domaine ou les deux, une attention particulière DOIT être accordée à la normalisation Unicode [Unicode-UAX15], en partie parce que les chaînes Unicode peuvent être normalisées par d'autres processus indépendants de ce qu'un protocole de courrier spécifie (c'est exactement analogique à ce qui peut arriver avec la citation et le déquoting dans les adresses traditionnelles).

  • En général, il est sage de prendre en charge les adresses sous forme normalisée, en utilisant au moins le formulaire de normalisation NFC. Sauf dans les circonstances où NFKC cartographierait ensemble des caractères que les parties responsables du serveur de messagerie de destination préfèrent garder distincts, le soutien du formulaire conforme à NFKC produirait un comportement encore plus prévisible pour l'utilisateur typique.

  • Il est généralement judicieux de prendre en charge d'autres formes de la même chaîne locale, soit sous le nom d'alias, soit par normalisation des chaînes atteignant le serveur de livraison: l'expéditeur ne doit pas être dépendant pour envoyer les chaînes sous forme normalisée.

  • En termes différents et plus précis, les règles du protocole pour les chaînes de parties locales prévoient essentiellement que:

    • Les chaînes non normalisées sont valides, mais suffisamment mauvaises pour ne pas fonctionner de manière fiable sur une base globale. Les serveurs ne devraient pas dépendre des clients pour envoyer des formulaires normalisés, mais devraient être conscients que les procédures sur les machines clients en dehors du contrôle de la MUA peuvent entraîner l'envoi de chaînes normalisées indépendamment de l'intention de l'utilisateur.

    • Les commandes C0 (et probablement C1) (voir La norme Unicode [Unicode]) sont interdites, la première dans la RFC 5321 et la seconde par une extension évidente de celle-ci [RFC5198].

    • D'autres types de ponctuation, d'espaces, etc., sont une pratique risquée. Peut-être qu'ils fonctionneront, et le code du récepteur SMTP est nécessaire pour les gérer sans erreurs graves (même si de telles chaînes ne sont pas acceptées dans les adresses à livrer sur ce serveur), mais créer des dépendances à leur sujet dans les noms de boîtes de courrier choisis est généralement une mauvaise pratique et peut entraîner des problèmes d'interopérabilité.

11. Questions supplémentaires​

Cette section identifie les questions qui ne sont pas couvertes ou non couvertes de manière exhaustive dans le cadre de cet ensemble de spécifications, mais qui nécessiteront une révision continue dans le cadre du déploiement de l'adresse e-mail et de l'internationalisation des en-têtes.

11.1. Impact sur les URI et les IRI​

Le schéma [RFC6068], et sa discussion dans la spécification de l'identificateur de ressources internationalement reconnu (IRI) [RFC3987], pourraient devoir être modifiés lorsque ce travail sera terminé et normalisé.

11.2. Utilisation des adresses électroniques comme identifiants​

Il existe un certain nombre d'endroits dans l'utilisation contemporaine d'Internet où les adresses e-mail sont utilisées comme identifiants pour les individus, y compris comme identifiants pour les serveurs Web qui prennent en charge certains sites de commerce électronique et dans certains certificats X.509 [RFC5280]. Ces documents ne traitent pas ces utilisations, mais il est raisonnable de s'attendre à ce que certaines difficultés soient rencontrées lorsque des adresses internationalizées seront utilisées pour la première fois dans ces contextes, dont beaucoup ne peuvent même pas gérer la gamme complète d'adresses autorisées aujourd'hui.

11.3. Mots codés, messages signés et rétrogradation​

Une caractéristique particulière du format du courrier électronique est sa persistance: les MUA doivent traiter aussi bien les messages envoyés il y a plusieurs décennies que ceux remis quelques secondes auparavant. Les MUA et les logiciels de filtrage, tels que Sieve [RFC5228], devront donc continuer à accepter et à décoder les champs d'en-tête utilisant le mécanisme des « mots codés » [RFC2047] pour représenter des caractères non ASCII. Des extensions de POP3 [RFC1939] et d'IMAP [RFC3501] prévoient la mise à niveau automatique, par le serveur POP3 [RFC5721bis-POP3] ou IMAP [RFC5738bis-IMAP], des messages qui transportent sous forme codée des informations non ASCII, notamment le décodage RFC 2047. Certaines structures de message et certains types de contenu MIME ne permettent toutefois pas cette opération, ou celle-ci aurait des effets secondaires inacceptables.

Par exemple, les parties de message qui sont cryptographiquement signées, en utilisant par exemple S/MIME [RFC5751] ou Pretty Good Privacy (PGP) [RFC3156], ne peuvent pas être mises à niveau du formulaire RFC 2047 vers des caractères UTF-8 normaux sans casser la signature. De même, les parties de message qui sont cryptées peuvent contenir, lorsqu'elles sont décryptées, des champs d'en-tête qui utilisent le codage RFC 2047; de tels messages ne peuvent pas être " complètement " mis à niveau sans accès aux clés cryptographiques.

Des problèmes similaires peuvent survenir si les messages sont signés puis dégradés par la suite, par exemple, comme discuté à la section 8.1, puis une tentative est faite de les mettre à niveau vers la forme originale et de vérifier les signatures. Même les changements très subtils qui peuvent résulter des algorithmes pour dégrader et ensuite améliorer à nouveau peuvent suffire à invalider les signatures s'ils affectent les en-têtes des parties du corps primaires ou MIME. Lorsque les signatures sont présentes, la dégradation doit être effectuée avec extrême soin si du tout.

11.4. Autres utilisations des parties locales​

Les parties locales servent parfois à construire des étiquettes de domaine. Par exemple, la partie locale « user » de l'adresse [email protected] peut être convertie en nom d'hôte user.domain.example, avec son espace Web à l'adresse http://user.domain.example, et avec des adresses génériques telles que [email protected].

Ces régimes sont évidemment limités par, entre autres, les règles SMTP pour les noms de domaine et ne fonctionneront pas sans nouvelles restrictions pour les autres parties locales.

11.5. Formats d'encapsulation non standard​

Certaines applications utilisent des formats similaires au format application/mbox [RFC4155] au lieu du message/digest form défini dans la RFC 2046, section 5.1.5 [RFC2046] pour transférer plusieurs messages en unités uniques. Dans la mesure où ces applications supposent que tous les messages stockés utilisent le format message/rfc822 décrit dans la RFC 2046, section 5.2.1 [RFC2046] avec des en-têtes de message ASCII, ils ne sont pas prêts pour les extensions spécifiées dans cette série de documents, et des mesures spéciales peuvent être nécessaires pour les détecter et les traiter correctement.

12. Changements clés apportés aux protocoles et au cadre expérimentaux​

Le cadre initial pour les adresses e-mail et les en-têtes internationaux a été décrit dans RFC 4952 et un ensemble ultérieur de documents de protocole expérimental. Ces relations sont décrites dans la section 3. La principale différence architecturale entre les spécifications expérimentales et ce nouvel ensemble est que les spécifications antérieures ont soutenu la dégradation en transit. Ces mécanismes comprenaient la définition de la syntaxe et des fonctions pour soutenir le passage d'adresses alternatives, toutes ASCII avec les non-ASCII ainsi que des en-têtes spéciales pour indiquer le statut dégradé des messages. Ces caractéristiques ont été éliminées après que l'expérimentation a indiqué qu'elles étaient plus complexes et moins nécessaires que prévues précédemment. Ces problèmes sont décrites plus en détail dans les sections 6 et 9.

13. Considérations de sécurité​

Toute expansion de caractères autorisés et de formulaires de codage dans les adresses e-mail soulève certains risques. Il y a eu des discussions sur ce que l'on appelle " IDN-spoofing " ou " IDN homograph attacks ". Ces attaques permettent à un attaquant (ou " phisher ") de falsifier le domaine ou les URL des entreprises ou d'autres entités. Le même type d'attaque est également possible sur la partie locale des adresses e-mail internationalizées. Il convient de noter que la correction proposée implique de forcer tous les éléments affichés dans des petits caractères normalisés fonctionne pour les noms de domaine dans les URL, mais pas pour les parties locales de l'e-mail puisque ces derniers sont sensibles aux cas.

Comme les adresses e-mail sont souvent transcrites à partir de cartes de visite et de notes sur papier, elles sont soumises à des problèmes résultant de caractères confus (voir [RFC4690]). Ces problèmes sont quelque peu réduits si le domaine associé à la boîte aux lettres est sans ambiguïté et prend en charge un nombre relativement faible de boîtes aux lettres dont les noms suivent les conventions du système local.

L'internationalisation des adresses e-mail et des en-têtes de messages ne doit pas laisser Internet moins sûr qu'il ne l'est sans les extensions requises.

Ils nécessitent un examen des problèmes associés aux caractères confus - un sujet qui est en cours d'exploration en profondeur ailleurs (voir, par exemple, RFC 4690 [RFC4690]) - et, potentiellement, certains problèmes avec la normalisation UTF-8, discutés dans RFC 3629 [RFC3629], et d'autres transformations. La normalisation et d'autres problèmes associés aux transformations et aux formes standard font également partie du sujet du travail décrit ailleurs [RFC5198] [RFC5893] [RFC6055].

Certains problèmes spécifiques liés aux adresses internationalizées et aux en-têtes de message sont discutés plus en détail dans les autres documents de ce jeu. Cependant, il convient de faire attention à ce que tout mécanisme de " dégradation " ou d'utilisation d'adresses dégradées n'assume pas inappropriément des liaisons authentifiées entre les adresses internationalizées et ASCII. Ce problème potentiel peut être atténué en attendant que la plupart ou toutes ces transformations soient effectuées avant la livraison finale par des systèmes qui sont présumés être sous le contrôle administratif de l'utilisateur expéditeur (par opposition à être effectuées en transit par des entités qui ne sont pas sous le contrôle administratif de l'utilisateur expéditeur).

Le nouveau format d'en-tête et de message UTF-8 pourrait également soulever ou aggraver un autre problème connu. Si le modèle crée de nouvelles formes d'un message "invalide" ou "malformé", alors une nouvelle attaque par e-mail est créée: dans un effort pour être robuste, certains ou la plupart des agents accepteront ces messages et les interpréteront comme s'ils étaient bien formés. Si un filtre interprète un tel message différemment de la MUA utilisée par le destinataire, il peut être possible de créer un message qui semble acceptable selon l'interprétation du filtre, mais qui devrait être rejeté selon l'interprétation qui lui est donnée par ce MUA. De tels attaques ont déjà eu lieu pour les messages existants et les couches de codage, par exemple, la syntaxe MIME invalide, le marquage HTML invalide et le codage invalide de certains types d'images.

En outre, les adresses e-mail sont utilisées dans de nombreux contextes autres que l'envoi de courrier, comme pour les identifiants dans diverses circonstances (voir rubrique 11.2). Chacun de ces contextes devra être évalué, à son tour, pour déterminer si l'utilisation de formulaires non ASCII est appropriée et quelles questions particulières ils soulèvent.

Ce travail affectera clairement tous les systèmes ou mécanismes qui dépendent de signatures numériques ou de protection d'intégrité similaire pour les en-têtes de messages de messagerie (voir aussi la discussion dans la section 11.3). De nombreuses utilisations conventionnelles de PGP et S/MIME ne sont pas affectées car elles sont utilisées pour signer des parties du corps mais pas des en-têtes de message. D'autre part, le travail en cours de développement sur DomainKeys Identified Mail (DKIM) [RFC5863] devra éventuellement prendre en compte ce travail, et vice versa: alors que cette spécification ne traite pas ou ne résolve pas les problèmes soulevés par DKIM et d'autres mécanismes de en-tête signés, les problèmes devront être coordonnés et résolus éventuellement si les deux ensembles de protocoles doivent coexister. En outre, dans la mesure où les adresses e-mail figurent dans les certificats PKI (Infrastructure de clés publiques) [RFC5280], les normes qui traitent de tels certificats devront être mises à jour pour répondre à ces adresses internationalement mises à jour.

14. Remerciements​

Ce document est une mise à jour de la RFC 4952 et dérive de celle-ci. Ce document aurait été impossible sans les travaux et les contributions reconnues dans cette dernière.

Un remerciement particulier est dû à Ernie Dainow pour les critiques attentives et les suggestions de texte dans cette version et à plusieurs membres de l'IESG pour une évaluation attentive et des suggestions spécifiques.

15. Références​

15.1. Références normatives​

  • [ASCII] Institut américain des normes nationales (anciennement Institut des normes des États-Unis d'Amérique), "Code des États-Unis pour l'échange d'informations", ANSI X3.4-1968, 1968.

  • [RFC2119] Bradner, S., "Cléments pour l'utilisation dans les RFC pour indiquer les niveaux de besoins", BCP 14, RFC 2119, mars 1997.

  • [RFC3629] Yergeau, F., "UTF-8, un format de transformation de l'ISO 10646", STD 63, RFC 3629, novembre 2003.

  • [RFC5321] Klensin, J., "Protocole simple de transfert de courrier", RFC 5321, octobre 2008.

  • [RFC5322] Resnick, P., éd., "Format de message Internet", RFC 5322, octobre 2008.

  • [RFC5890] Klensin, J., "Noms de domaine internationaux pour les applications (IDNA): définitions et cadre de document", RFC 5890, août 2010.

  • [RFC6152] Klensin, J., Freed, N., Rose, M., et D. Crocker, "Extension de service SMTP pour le transport MIME à 8 bits", STD 71, RFC 6152, mars 2011.

  • [RFC6531] Yao, J. et W. Mao, "Extension SMTP pour l'adresse e-mail internationalement, RFC 6531, février 2012.

  • [RFC6532] Yang, A., Steele, S., et N. Freed, "En-tête de courrier électronique internationalisé", RFC 6532, février 2012.

  • [RFC6533] Hansen, T., Newman, C., et A. Melnikov, "Status et notification de livraison internationalement mis en place", RFC 6533, février 2012.

15.2. Références informatives​

  • [POPIMAP-Downgrade] Fujiwara, K., "Downgrading Message Post-delivery for Internationalized Email Messages", Work in Progress, octobre 2011.

  • [RFC0821] Postel, J., "Protocole simple de transfert de courrier", STD 10, RFC 821, août 1982.

  • [RFC1123] Braden, R., "Requisitions pour les hôtes Internet - Application et support", STD 3, RFC 1123, octobre 1989.

  • [RFC1939] Myers, J. et M. Rose, "Protocole du bureau de poste - Version 3", STD 53, RFC 1939, mai 1996.

  • [RFC2045] Freed, N. et N. Borenstein, "Extensions de courrier Internet à multiples fins (MIME) Partie 1: Format des corps de messages Internet", RFC 2045, novembre 1996.

  • [RFC2046] Freed, N. et N. Borenstein, "Extensions de courrier électronique Internet à plusieurs fins (MIME) Partie Deux: Types de médias", RFC 2046, novembre 1996.

  • [RFC2047] Moore, K., "MIME (Extensions de courrier Internet à plusieurs fins) Partie Troisième: Extensions d'en-tête de message pour le texte non ASCII", RFC 2047, novembre 1996.

  • [RFC2231] Freed, N. et K. Moore, "Value de paramètre MIME et Extensions de mots codés: ensembles de caractères, langues et continuations", RFC 2231, novembre 1997.

  • [RFC2821] Klensin, J., "Protocole simple de transfert de courrier", RFC 2821, avril 2001.

  • [RFC3156] Elkins, M., Del Torto, D., Levien, R., et T. Roessler, "Sécurité MIME avec OpenPGP", RFC 3156, août 2001.

  • [RFC3461] Moore, K., "Extension de service du protocole de transfert de courrier simple (SMTP) pour les notifications d'état de livraison (DSNs)", RFC 3461, janvier 2003.

  • [RFC3464] Moore, K. et G. Vaudreuil, "Un format de message extensible pour les notifications d'état de livraison", RFC 3464, janvier 2003.

  • [RFC3492] Costello, A., "Punycode: Un codage de la chaîne de démarrage d'Unicode pour les noms de domaine internationaux dans les applications (IDNA)", RFC 3492, mars 2003.

  • [RFC3501] Crispin, M., "PROTOCOL d'accès aux messages Internet - VERSION 4rev1", RFC 3501, mars 2003.

  • [RFC3987] Duerst, M. et M. Suignard, "Ressources internationalement identifiées (IRI)", RFC 3987, janvier 2005.

  • [RFC4155] Hall, E., "Le type de média de l'application/mbox", RFC 4155, septembre 2005.

  • [RFC4690] Klensin, J., Faltstrom, P., Karp, C., et IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, septembre 2006.

  • [RFC4952] Klensin, J. et Y. Ko, "Voir et cadre pour l'internationalisation du courrier électronique", RFC 4952, juillet 2007.

  • [RFC5198] Klensin, J. et M. Padlipsky, "Format Unicode pour l'échange de réseau", RFC 5198, mars 2008.

  • [RFC5228] Guenther, P. et T. Showalter, "Sieve: un langage de filtrage des courriels", RFC 5228, janvier 2008.

  • [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., et W. Polk, "Internet X.509 Certificate of Public Key Infrastructure and Certificate Revocation List (CRL) Profile", RFC 5280, mai 2008.

  • [RFC5335] Yang, A., "En-tête de courrier électronique internationalisé", RFC 5335, septembre 2008.

  • [RFC5336] Yao, J. et W. Mao, "Extension SMTP pour les adresses e-mail internationalement", RFC 5336, septembre 2008.

  • [RFC5337] Newman, C. et A. Melnikov, "Notifications internationalement sur le statut et la disposition des livraisons", RFC 5337, septembre 2008.

  • [RFC5504] Fujiwara, K. et Y. Yoneya, " Mécanisme de dégradation de l'internationalisation des adresses électroniques ", RFC 5504, mars 2009.

  • [RFC5721] Gellens, R. et C. Newman, "POP3 Support for UTF-8", RFC 5721, février 2010.

  • [RFC5721bis-POP3] Gellens, R., Newman, C., Yao, J., et K. Fujiwara, "POP3 Support for UTF-8", Work in Progress, novembre 2011.

  • [RFC5738] Resnick, P. et C. Newman, "Support IMAP pour UTF-8", RFC 5738, mars 2010.

  • [RFC5738bis-IMAP] Resnick, P., Ed., Newman, C., Ed., et S. Shen, Ed., "Imap Support for UTF-8", Work in Progress, décembre 2011.

  • [RFC5751] Ramsdell, B. et S. Turner, "Extensions de courrier électronique Internet sécurisées/multipurposées (S/MIME) Version 3.2 Spécification de message", RFC 5751, janvier 2010.

  • [RFC5825] Fujiwara, K. et B. Leiba, " Affichage de messages dégradés pour l'internationalisation des adresses électroniques ", RFC 5825, avril 2010.

  • [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., et D. Crocker, "DomainKeys Identified Mail (DKIM) Développement, déploiement et opérations", RFC 5863, mai 2010.

  • [RFC5891] Klensin, J., "Nommés de domaine internationaux dans les applications (IDNA): Protocole", RFC 5891, août 2010.

  • [RFC5892] Faltstrom, P., "Les points de code Unicode et les noms de domaine internationaux pour les applications (IDNA)", RFC 5892, août 2010.

  • [RFC5893] Alvestrand, H. et C. Karp, "Scripts de droite à gauche pour les noms de domaine internationaux pour les applications (IDNA)", RFC 5893, août 2010.

  • [RFC5894] Klensin, J., "Noms de domaine internationaux pour les applications (IDNA): contexte, explication et justification", RFC 5894, août 2010.

  • [RFC5983] Gellens, R., "Listes de diffusion et adresses électroniques internationalement établies", RFC 5983, octobre 2010.

  • ** [RFC5983bis-MailingList]** Levine, J. et R. Gellens, "Listes de diffusion et adresses UTF-8, Travail en cours, décembre 2011.

  • [RFC6055] Thaler, D., Klensin, J., et S. Cheshire, "Pensées IAB sur les codage pour les noms de domaine internationaux", RFC 6055, février 2011.

  • [RFC6068] Duerst, M., Masinter, L., et J. Zawinski, "Le schéma URI "mailto", RFC 6068, octobre 2010.

  • [RFC6409] Gellens, R. et J. Klensin, "Sendement de messages pour la poste", STD 72, RFC 6409, novembre 2011.

  • Le consortium Unicode, version 6.0.0, défini par: "Le standard Unicode, version 6.0.0", (Mountain View, CA: Le consortium Unicode, 2011. ISBN 978-1-936213-01-6). http://www.unicode.org/versions/Unicode6.0.0/- Je suis désolé .

  • [Unicode-UAX15] Le consortium Unicode, "Unicode Standard Annex #15: Formes de normalisation Unicode", septembre 2010, http://www.unicode.org/reports/tr15/- Je suis désolé .