Aller au contenu principal

RFC 6530 - Overview and Framework for Internationalized Email (Aperçu et cadre pour le courrier électronique internationalisé)

  • Statut: Proposed Standard
  • Publié: February 2012
  • Stream: IETF
  • Remplace: RFC4952, RFC5504, RFC5825
  • Errata: Pas d'errata

Document Information (Informations sur le document)​

  • RFC Number: 6530
  • Title: Overview and Framework for Internationalized Email (Aperçu et cadre pour le courrier électronique internationalisé)
  • Authors: J. Klensin, Y. Ko
  • Date: February 2012
  • Category: Standards Track
  • Obsoletes: RFC 4952, RFC 5504, RFC 5825
  • ISSN: 2070-1721

Abstract (Résumé)​

Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published.

L'utilisation complète du courrier électronique dans le monde entier exige que (sous réserve d'autres contraintes) les gens puissent utiliser des variations proches de leurs propres noms (écrits correctement dans leurs propres langues et écritures) comme noms de boîte aux lettres dans les adresses électroniques. Ce document présente une série de spécifications qui définissent les mécanismes et les extensions de protocole nécessaires pour prendre pleinement en charge les adresses électroniques internationalisées. Ces changements incluent une extension SMTP et une extension de la syntaxe des en-têtes de courrier électronique pour s'adapter aux données UTF-8. L'ensemble de documents comprend également une discussion sur les hypothèses clés et les problèmes liés au déploiement d'un courrier électronique entièrement internationalisé. Ce document remplace la RFC 4952 ; il reflète les problèmes supplémentaires identifiés depuis la publication de ce document.

Status of This Memo (Statut de ce mémoire)​

This is an Internet Standards Track document.

Ceci est un document de la voie des normes Internet (Standards Track).

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Ce document est un produit de l'Internet Engineering Task Force (IETF). Il représente le consensus de la communauté IETF. Il a fait l'objet d'un examen public et a été approuvé pour publication par l'Internet Engineering Steering Group (IESG). De plus amples informations sur les normes Internet sont disponibles dans la section 2 de la RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6530.

Des informations sur le statut actuel de ce document, les éventuels errata et la manière de fournir des commentaires à son sujet peuvent être obtenues sur http://www.rfc-editor.org/info/rfc6530.

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Ce document est soumis au BCP 78 et aux dispositions légales du IETF Trust relatives aux documents IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Veuillez examiner ces documents attentivement, car ils décrivent vos droits et restrictions concernant ce document. Les composants de code extraits de ce document doivent inclure le texte de la licence BSD simplifiée tel que décrit dans la section 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence BSD simplifiée.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Ce document peut contenir du matériel provenant de documents IETF ou de contributions IETF publiés ou rendus publics avant le 10 novembre 2008. La ou les personnes contrôlant le droit d'auteur sur une partie de ce matériel peuvent ne pas avoir accordé au IETF Trust le droit d'autoriser des modifications de ce matériel en dehors du processus de normalisation de l'IETF. Sans obtenir une licence adéquate de la ou des personnes contrôlant le droit d'auteur sur ces matériaux, ce document ne peut être modifié en dehors du processus de normalisation de l'IETF, et aucune œuvre dérivée de celui-ci ne peut être créée en dehors du processus de normalisation de l'IETF, sauf pour le formater en vue de sa publication sous forme de RFC ou pour le traduire dans des langues autres que l'anglais.

Table of Contents (Table des matières)​

  1. Introduction (Introduction)
  2. Role of This Specification (Rôle de cette spécification)
  3. Problem Statement (Énoncé du problème)
  4. Terminology (Terminologie)
  5. Overview of the Approach and Document Plan (Aperçu de l'approche et plan du document)
  6. Review of Experimental Results (Examen des résultats expérimentaux)
  7. Overview of Protocol Extensions and Changes (Aperçu des extensions et modifications du protocole)
  8. Downgrading before and after SMTP Transactions (Déclassement avant et après les transactions SMTP)
  9. Downgrading in Transit (Déclassement en transit)
  10. User Interface and Configuration Issues (Problèmes d'interface utilisateur et de configuration)
  11. Additional Issues (Problèmes supplémentaires)
  12. Key Changes from the Experimental Protocols and Framework (Principaux changements par rapport aux protocoles expérimentaux et au cadre)
  13. Security Considerations (Considérations de sécurité)
  14. Acknowledgments (Remerciements)
  15. References (Références)

1. Introduction (Introduction)​

In order to use internationalized email addresses, it is necessary to internationalize both the domain part and the local part of email addresses. The domain part of email addresses is already internationalized [RFC5890], while the local part is not. Without the extensions specified in this document, the mailbox name is restricted to a subset of 7-bit ASCII [RFC5321]. Though MIME [RFC2045] enables the transport of non-ASCII data, it does not provide a mechanism for internationalized email addresses. In RFC 2047 [RFC2047], MIME defines an encoding mechanism for some specific message header fields to accommodate non-ASCII data. However, it does not permit the use of email addresses that include non-ASCII characters. Without the extensions defined here, or some equivalent set, the only way to incorporate non-ASCII characters in any part of email addresses is to use RFC 2047 coding to embed them in what RFC 5322 [RFC5322] calls the "display name" (known as a "name phrase" or by other terms elsewhere) of the relevant header fields. Information coded into the display name is invisible in the message envelope and, for many purposes, is not part of the address at all.

Afin d'utiliser des adresses électroniques internationalisées, il est nécessaire d'internationaliser à la fois la partie domaine et la partie locale des adresses électroniques. La partie domaine des adresses électroniques est déjà internationalisée [RFC5890], alors que la partie locale ne l'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 l'ASCII 7 bits [RFC5321]. Bien que MIME [RFC2045] permette le transport de données non ASCII, il ne fournit pas de mécanisme pour les adresses électroniques internationalisées. Dans la RFC 2047 [RFC2047], MIME définit un mécanisme de codage pour certains champs d'en-tête de message spécifiques afin de prendre en charge les données non ASCII. Cependant, il ne permet pas l'utilisation d'adresses électroniques incluant 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 une partie quelconque des adresses électroniques est d'utiliser le codage RFC 2047 pour les intégrer dans ce que la 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, à bien des égards, ne font pas du tout partie de l'adresse.

This document is a replacement for RFC 4952 [RFC4952]; it reflects additional issues, shared terminology, and some architectural changes identified since that document was published. It obsoletes that document. The experimental descriptions of in-transit downgrading [RFC5504] [RFC5825] are now irrelevant and no longer needed due to the changes discussed in Section 12. The RFC Editor is requested to move all three of those documents to Historic.

Ce document remplace la RFC 4952 [RFC4952] ; il reflète les problèmes supplémentaires, la terminologie partagée et certaines modifications architecturales identifiées depuis la publication de ce document. Il rend ce document obsolète. Les descriptions expérimentales du déclassement en transit [RFC5504] [RFC5825] sont désormais non pertinentes et ne sont plus nécessaires en raison des changements discutés dans la section 12. L'éditeur RFC est invité à déplacer ces trois documents vers le statut Historique.

The pronouns "he" and "she" are used interchangeably to indicate a human of indeterminate gender.

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

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].

Les mots clés "DOIT", "NE DOIT PAS", "REQUIS", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" dans ce document doivent être interprétés comme décrit dans BCP 14, RFC 2119 [RFC2119].

2. Role of This Specification (Rôle de cette spécification)​

This document presents the overview and framework for an approach to the next stage of email internationalization. This new stage requires not only internationalization of addresses and header fields, but also associated transport and delivery models. A prior version of this specification, RFC 4952 [RFC4952], also provided an introduction to a series of experimental protocols [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825]. This revised form provides overview and conceptual information for the Standards Track successors of a subset of those protocols. Details of the documents and the relationships among them appear in Section 5 and a discussion of what was learned from the experimental protocols and their implementations appears in Section 6.

Ce document présente l'aperçu et le cadre d'une approche pour la prochaine étape de l'internationalisation du courrier électronique. 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, la RFC 4952 [RFC4952], fournissait également une introduction à une série de protocoles expérimentaux [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825]. Cette forme révisée fournit un aperçu et des informations conceptuelles pour les successeurs de la voie des normes (Standards Track) d'un sous-ensemble de ces protocoles. Les détails des documents et les relations entre eux figurent à la section 5, et une discussion sur ce qui a été appris des protocoles expérimentaux et de leurs mises en œuvre figure à la section 6.

Taken together, these specifications provide the details for a way to implement and support internationalized email. The document itself describes how the various elements of email internationalization fit together and the relationships among the primary specifications associated with message transport, header formats, and handling.

Prises ensemble, ces spécifications fournissent les détails d'un moyen de mettre en œuvre et de prendre en charge le courrier électronique internationalisé. Le document lui-même décrit comment les différents éléments de l'internationalisation du courrier électronique s'articulent et les relations entre les principales spécifications associées au transport des messages, aux formats d'en-tête et au traitement.

This document, and others that comprise the collection described above, assume a reasonable familiarity with the basic Internet electronic mail specifications and terminology [RFC5321] [RFC5322] and the MIME [RFC2045] and 8BITMIME [RFC6152] ones as well. While not strictly required to implement this specification, a general familiarity with the terminology and functions of IDNA [RFC5890] [RFC5891] [RFC5892] [RFC5893] [RFC5894] are also assumed.

Ce document, et d'autres qui composent la collection décrite ci-dessus, supposent une familiarité raisonnable avec les spécifications et la terminologie de base du courrier électronique Internet [RFC5321] [RFC5322] ainsi qu'avec celles de MIME [RFC2045] et 8BITMIME [RFC6152]. Bien que cela ne soit pas strictement requis pour mettre en œuvre cette spécification, une familiarité générale avec la terminologie et les fonctions d'IDNA [RFC5890] [RFC5891] [RFC5892] [RFC5893] [RFC5894] est également supposée.

3. Problem Statement (Énoncé du problème)​

Internationalizing Domain Names in Applications (IDNA) [RFC5890] permits internationalized domain names, but deployment has not yet reached most users. One of the reasons for this is that we do not yet have fully internationalized naming schemes. Domain names are just one of the various names and identifiers that are required to be internationalized. In many contexts, until more of those identifiers are internationalized, internationalized domain names alone have little value.

L'internationalisation des noms de domaine dans les applications (IDNA) [RFC5890] permet les noms de domaine internationalisés, mais le déploiement n'a pas encore atteint la plupart des utilisateurs. L'une des raisons à cela est que nous n'avons pas encore de schémas de nommage entièrement internationalisés. Les noms de domaine ne sont que l'un des divers noms et identifiants qui doivent être internationalisés. Dans de nombreux contextes, tant que davantage de ces identifiants ne seront pas internationalisés, les noms de domaine internationalisés seuls auront peu de valeur.

Email addresses are prime examples of why it is not good enough to just internationalize the domain name. As most observers have learned from experience, users strongly prefer email addresses that resemble names or initials to those involving seemingly meaningless strings of letters or numbers. Unless the entire email address can use familiar characters and formats, users will perceive email as being culturally unfriendly. If the names and initials used in email addresses can be expressed in the native languages and writing systems of the users, the Internet will be perceived as more natural, especially by those whose native language is not written in a subset of a Roman-derived script.

Les adresses électroniques sont de parfaits exemples de la raison pour laquelle il ne suffit pas d'internationaliser uniquement le nom de domaine. Comme la plupart des observateurs l'ont appris par expérience, les utilisateurs préfèrent fortement les adresses électroniques qui ressemblent à des noms ou à des initiales plutôt qu'à celles impliquant des chaînes de lettres ou de chiffres apparemment sans signification. À moins que l'adresse électronique entière ne puisse utiliser des caractères et des formats familiers, les utilisateurs percevront le courrier électronique comme étant culturellement inamical. Si les noms et les initiales utilisés dans les adresses électroniques peuvent être exprimés dans les langues maternelles et les systèmes d'écriture des utilisateurs, l'Internet sera perçu comme plus naturel, en particulier par ceux dont la langue maternelle n'est pas écrite dans un sous-ensemble d'une écriture dérivée du romain.

Internationalization of email addresses is not merely a matter of changing the SMTP envelope; or of modifying the "From:", "To:", and "Cc:" header fields; or of permitting upgraded Mail User Agents (MUAs) to decode a special coding and respond by displaying local characters. To be perceived as usable, the addresses must be internationalized and handled consistently in all of the contexts in which they occur. This requirement has far-reaching implications: collections of patches and workarounds are not adequate. Even if they were adequate, a workaround-based approach may result in an assortment of implementations with different sets of patches and workarounds having been applied with consequent user confusion about what is actually usable and supported. Instead, we need to build a fully internationalized email environment, focusing on permitting efficient communication among those who share a language and writing system. That, in turn, implies changes to the mail header environment to permit those header fields that are appropriately internationalized to utilize the full range of Unicode characters, an SMTP extension to permit UTF-8 [RFC3629] [RFC5198] mail addressing and delivery of those extended header fields, support for internationalization of delivery and service notifications [RFC3461] [RFC3464], and (finally) a requirement for support of the 8BITMIME SMTP extension [RFC6152] so that all of these can be transported through the mail system without having to overcome the limitation that header fields do not have content-transfer-encodings.

L'internationalisation des adresses électroniques n'est pas simplement une question de modification de l'enveloppe SMTP ; ou de modification des champs d'en-tête "From:", "To:" et "Cc:" ; ou de permission aux agents utilisateurs de messagerie (MUA) mis à niveau de décoder un codage spécial et de répondre en affichant des caractères locaux. Pour être perçues comme utilisables, les adresses doivent être internationalisées et traitées de manière cohérente dans tous les contextes où elles apparaissent. Cette exigence a des implications profondes : les collections de correctifs et de solutions de contournement ne sont pas adéquates. Même s'ils étaient adéquats, une approche basée sur des solutions de contournement pourrait aboutir à un assortiment de mises en œuvre avec différents ensembles de correctifs et de solutions de contournement appliqués, entraînant une confusion pour l'utilisateur sur ce qui est réellement utilisable et pris en charge. Au lieu de cela, nous devons construire un environnement de messagerie entièrement internationalisé, en nous concentrant sur la permission d'une communication efficace entre ceux qui partagent une langue et un système d'écriture. Cela implique à son tour des changements dans l'environnement des en-têtes de courrier pour permettre à ces champs d'en-tête qui sont correctement internationalisés d'utiliser toute la gamme des caractères Unicode, une extension SMTP pour permettre l'adressage de courrier UTF-8 [RFC3629] [RFC5198] et la livraison de ces champs d'en-tête étendus, la prise en charge de l'internationalisation des notifications de livraison et de service [RFC3461] [RFC3464], et (enfin) une exigence de prise en charge de l'extension SMTP 8BITMIME [RFC6152] afin que tout cela puisse être transporté par le système de messagerie sans avoir à surmonter la limitation selon laquelle les champs d'en-tête n'ont pas de codages de transfert de contenu.

4. Terminology (Terminologie)​

This document assumes a reasonable understanding of the protocols and terminology of the core email standards as documented in RFC 5321 [RFC5321] and RFC 5322 [RFC5322].

Ce document suppose une compréhension raisonnable des protocoles et de la terminologie des normes de base du courrier électronique telles que documentées dans la RFC 5321 [RFC5321] et la RFC 5322 [RFC5322].

4.1. Mail User and Mail Transfer Agents (Agents utilisateurs et agents de transfert de courrier)​

Much of the description in this document depends on the abstractions of "Mail Transfer Agent" ("MTA") and "Mail User Agent" ("MUA"). However, it is important to understand that those terms and the underlying concepts postdate the design of the Internet's email architecture and the application of the "protocols on the wire" principle to it. That email architecture, as it has evolved, and that "on the wire" principle have prevented any strong and standardized distinctions about how MTAs and MUAs interact on a given origin or destination host (or even whether they are separate).

Une grande partie de la description dans ce document dépend des abstractions d'"Agent de transfert de courrier" ("MTA") et d'"Agent utilisateur de courrier" ("MUA"). Cependant, il est important de comprendre que ces termes et les concepts sous-jacents sont postérieurs à la conception de l'architecture de messagerie d'Internet et à l'application du principe des "protocoles sur le fil" à celle-ci. Cette architecture de messagerie, 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 s'ils sont séparés).

However, the term "final delivery MTA" is used in this document in a fashion equivalent to the term "delivery system" or "final delivery system" of RFC 5321. This is the SMTP server that controls the format of the local parts of addresses and is permitted to inspect and interpret them. It receives messages from the network for delivery to mailboxes or for other local processing, including any forwarding or aliasing that changes envelope addresses, rather than relaying. From the perspective of the network, any local delivery arrangements such as saving to a message store, handoff to specific message delivery programs or agents, and mechanisms for retrieving messages are all "behind" the final delivery MTA and hence are not part of the SMTP transport or delivery process.

Cependant, le terme "MTA de livraison finale" est utilisé dans ce document de manière équivalente au terme "système de livraison" ou "système de livraison final" de la RFC 5321. Il s'agit du 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 livraison dans des boîtes aux lettres ou pour d'autres traitements locaux, y compris tout transfert ou création d'alias modifiant les adresses d'enveloppe, plutôt que de relayer. Du point de vue du réseau, tous les arrangements de livraison locaux tels 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 des 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. Address Character Sets (Jeux de caractères d'adresse)​

In this document, an address is "all-ASCII", or just an "ASCII address", if every character in the address is in the ASCII character repertoire [ASCII]; an address is "non-ASCII", or an "i18n-address", if any character is not in the ASCII character repertoire. Such addresses MAY be restricted in other ways, but those restrictions are not relevant to this definition. The term "all-ASCII" is also applied to other protocol elements when the distinction is important, with "non-ASCII" or "internationalized" as its opposite.

Dans ce document, une adresse est "tout-ASCII", ou simplement une "adresse ASCII", si chaque caractère de l'adresse appartient au répertoire de caractères ASCII [ASCII] ; une adresse est "non-ASCII", ou une "adresse-i18n", si un caractère n'appartient pas au 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 "tout-ASCII" est également appliqué à d'autres éléments de protocole lorsque la distinction est importante, avec "non-ASCII" ou "internationalisé" comme opposé.

The umbrella term to describe the email address internationalization specified by this document and its companion documents is "SMTPUTF8". For example, an address permitted by this specification is referred to as a "SMTPUTF8 (compliant) address".

Le terme générique pour décrire l'internationalisation des adresses électroniques spécifiée par ce document et ses documents compagnons est "SMTPUTF8". Par exemple, une adresse autorisée par cette spécification est appelée une "adresse (conforme) SMTPUTF8".

Please note that, according to the definitions given here, the set of all "all-ASCII" addresses and the set of all "non-ASCII" addresses are mutually exclusive. The set of all addresses permitted when SMTPUTF8 appears is the union of these two sets.

Veuillez noter que, selon les définitions données ici, l'ensemble de toutes les adresses "tout-ASCII" et l'ensemble de toutes les adresses "non-ASCII" sont mutuellement exclusifs. L'ensemble de toutes les adresses autorisées lorsque SMTPUTF8 apparaît est l'union de ces deux ensembles.

4.3. User Types (Types d'utilisateurs)​

An "ASCII user" (i) exclusively uses email addresses that contain ASCII characters only, and (ii) cannot generate recipient addresses that contain non-ASCII characters.

Un "utilisateur ASCII" (i) utilise exclusivement des adresses électroniques ne contenant que des caractères ASCII, et (ii) ne peut pas générer d'adresses de destinataire contenant des caractères non ASCII.

An "internationalized email user" has one or more non-ASCII email addresses, or is able to generate recipient addresses that contain non-ASCII characters. Such a user may have ASCII addresses too; if the user has more than one email account and a corresponding address, or more than one alias for the same address, he or she has some method to choose which address to use on outgoing email. Note that under this definition, it is not possible to tell from an ASCII address if the owner of that address is an internationalized email user or not. (A non-ASCII address implies a belief that the owner of that address is an internationalized email user.) There is no such thing as an "internationalized email user message"; the term applies only to users and their agents and capabilities. In particular, the use of non-ASCII, and hence presumably internationalized, message content is an integral part of the MIME specifications [RFC2045] and does not require these extensions (although it is compatible with them).

Un "utilisateur de courrier électronique internationalisé" possède une ou plusieurs adresses électroniques non ASCII, ou est capable de générer des adresses de destinataire contenant des caractères non ASCII. Un tel utilisateur peut également avoir des adresses ASCII ; si l'utilisateur a plus d'un compte de messagerie et une adresse correspondante, ou plus d'un alias pour la même adresse, il dispose d'une méthode pour choisir quelle adresse utiliser pour le courrier sortant. Notez que selon 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 de courrier électronique internationalisé ou non. (Une adresse non ASCII implique la conviction que le propriétaire de cette adresse est un utilisateur de courrier électronique internationalisé.) Il n'existe pas de "message d'utilisateur de courrier électronique internationalisé" ; le terme s'applique uniquement aux utilisateurs, à leurs agents et à leurs capacités. En particulier, l'utilisation de contenu de message non ASCII, et donc vraisemblablement internationalisé, fait partie intégrante des spécifications MIME [RFC2045] et ne nécessite pas ces extensions (bien qu'elle soit compatible avec elles).

4.4. Messages (Messages)​

A "message" is sent from one user (the sender) using a particular email address to one or more other recipient email addresses (often referred to just as "users" or "recipient users").

Un "message" est envoyé par un utilisateur (l'expéditeur) utilisant une adresse électronique particulière à une ou plusieurs autres adresses électroniques de destinataire (souvent appelées simplement "utilisateurs" ou "utilisateurs destinataires").

4.5. Mailing Lists (Listes de diffusion)​

A "mailing list" is a mechanism whereby a message may be distributed to multiple recipients by sending it to one recipient address. An agent (typically not a human being) at that single address then causes the message to be redistributed to the target recipients. This agent sets the envelope return address of the redistributed message to a different address from that of the original single recipient message. Using a different envelope return address (reverse-path) causes error (and other automatically generated) messages to go to an error-handling address.

Une "liste de diffusion" est un mécanisme par lequel un message peut être distribué à plusieurs destinataires en l'envoyant à une seule adresse de destinataire. Un agent (généralement pas un être humain) à cette adresse unique provoque alors la redistribution du message aux destinataires cibles. Cet agent définit l'adresse de retour de l'enveloppe du message redistribué sur une adresse différente de celle du message original à destinataire unique. L'utilisation d'une adresse de retour d'enveloppe différente (chemin inverse) fait que les messages d'erreur (et autres générés automatiquement) vont à une adresse de gestion des erreurs.

Special provisions for managing mailing lists that might contain non-ASCII addresses are discussed in a document that is specific to that topic [RFC5983] and its expected successor [RFC5983bis-MailingList].

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

4.6. Conventional Message and Internationalized Message (Message conventionnel et message internationalisé)​

  • A conventional message is one that does not use any extension defined in the SMTP extension document [RFC6531] or in the UTF8header document [RFC6532] in this set of specifications, and is strictly conformant to RFC 5322 [RFC5322].

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

  • An internationalized message is a message utilizing one or more of the extensions defined in this set of specifications, so that it is no longer conformant to the traditional specification of an email message or its transport.

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

4.7. Undeliverable Messages, Notification, and Delivery Receipts (Messages non distribuables, notifications et accusés de réception)​

As specified in RFC 5321, a message that is undeliverable for some reason is expected to result in notification to the sender. This can occur in either of two ways. One, typically called "Rejection", occurs when an SMTP server returns a reply code indicating a fatal error (a "5yz" code) or persistently returns a temporary failure error (a "4yz" code). The other involves accepting the message during SMTP processing and then generating a message to the sender, typically known as a "Non-delivery Notification" or "NDN". Current practice often favors rejection over NDNs because of the reduced likelihood that the generation of NDNs will be used as a spamming technique. The latter, NDN, case is unavoidable if an intermediate MTA accepts a message that is then rejected by the next-hop server.

Comme spécifié dans la RFC 5321, un message non distribuable pour une raison quelconque est censé entraîner une notification à l'expéditeur. Cela peut se produire de deux manières. L'une, généralement appelée "Rejet", se produit lorsqu'un serveur SMTP renvoie un code de réponse indiquant une erreur fatale (un code "5yz") ou renvoie de manière persistante une erreur d'échec temporaire (un code "4yz"). L'autre consiste à accepter le message pendant le traitement SMTP, puis à générer un message à l'intention de l'expéditeur, généralement connu sous le nom de "Notification de non-livraison" ou "NDN". La pratique actuelle favorise souvent le rejet par rapport aux NDN en raison de la probabilité réduite que la génération de NDN soit utilisée comme technique de spam. Le dernier cas, NDN, est inévitable si un MTA intermédiaire accepte un message qui est ensuite rejeté par le serveur du saut suivant.

A sender MAY also explicitly request message receipts [RFC3461] that raise the same issues for these internationalization extensions as NDNs.

Un expéditeur PEUT également demander explicitement des accusés de réception de message [RFC3461], ce qui soulève les mêmes problèmes pour ces extensions d'internationalisation que les NDN.

5. Overview of the Approach and Document Plan (Aperçu de l'approche et plan du document)​

This set of specifications changes both SMTP and the character encoding of email message headers to permit non-ASCII characters to be represented directly. Each important component of the work is described in a separate document. The document set, whose members are described below, also contains Informational documents whose purpose is to provide implementation suggestions and guidance for the protocols.

Cet ensemble de spécifications modifie à la fois SMTP et le codage des caractères des en-têtes de message électronique pour permettre la représentation directe des caractères non ASCII. Chaque composant important du travail est décrit dans un document séparé. L'ensemble de documents, dont les membres sont décrits ci-dessous, contient également des documents d'information dont le but est de fournir des suggestions de mise en œuvre et des conseils pour les protocoles.

In addition to this document, the following documents make up this specification and provide advice and context for it.

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

  • SMTP extension. The SMTP extension document [RFC6531] provides an SMTP extension (as provided for in RFC 5321) for internationalized addresses.

  • Extension SMTP. Le document d'extension SMTP [RFC6531] fournit une extension SMTP (telle que prévue dans la RFC 5321) pour les adresses internationalisées.

  • Email message headers in UTF-8. The email message header document [RFC6532] essentially updates RFC 5322 to permit some information in email message headers to be expressed directly by Unicode characters encoded in UTF-8 when the SMTP extension described above is used. This document, possibly with one or more supplemental ones, will also need to address the interactions with MIME, including relationships between SMTPUTF8 and internal MIME headers and content types.

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

  • Extensions to delivery status and notification handling to adapt to internationalized addresses [RFC6533].

  • Extensions de la gestion de l'état de livraison et des notifications pour s'adapter aux adresses internationalisées [RFC6533].

  • Forthcoming documents will specify extensions to the IMAP protocol [RFC3501] to support internationalized message headers [RFC5738bis-IMAP], parallel extensions to the POP protocol [RFC5721] [RFC5721bis-POP3], and some common properties of the two [POPIMAP-downgrade].

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

6. Review of Experimental Results (Examen des résultats expérimentaux)​

The key difference between this set of protocols and the experimental set that preceded them [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825] is that the earlier group provided a mechanism for in-transit downgrading of messages (described in detail in RFC 5504). That mechanism permitted, and essentially required, that each non-ASCII address be accompanied by an all-ASCII equivalent. That, in turn, raised security concerns associated with pairing of addresses that could not be authenticated. It also introduced the first incompatible change to Internet mail addressing in many years, raising concerns about interoperability issues if the new address forms "leaked" into legacy email implementations. After examining experience with the earlier, experimental, predecessors of these specifications, the working group that produced them concluded that the advantages of in-transit downgrading, were it feasible operationally, would be significant enough to overcome those concerns.

La principale différence entre cet ensemble de protocoles et l'ensemble expérimental qui les a précédés [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825] est que le groupe précédent fournissait un mécanisme de déclassement des messages en transit (décrit en détail dans la RFC 5504). Ce mécanisme permettait, et exigeait essentiellement, que chaque adresse non ASCII soit accompagnée d'un équivalent tout ASCII. Cela a, à son tour, soulevé des problèmes de sécurité associés à l'appariement d'adresses qui ne pouvaient pas être authentifiées. Cela a également introduit le premier changement incompatible dans l'adressage de courrier Internet depuis de nombreuses années, soulevant des inquiétudes concernant les problèmes d'interopérabilité si les nouvelles formes d'adresse "fuyaient" dans les implémentations de messagerie héritées. Après avoir examiné l'expérience avec les prédécesseurs expérimentaux antérieurs de ces spécifications, le groupe de travail qui les a produits a conclu que les avantages du déclassement en transit, s'il était réalisable sur le plan opérationnel, seraient suffisamment importants pour surmonter ces préoccupations.

That turned out not to be the case, with interoperability problems among initial implementations. Prior to starting on the work that led to this set of specifications, the WG concluded that the combination of requirements and long-term implications of that earlier model were too complex to be satisfactory and that work should move ahead without it.

Cela ne s'est pas avéré être le cas, avec des problèmes d'interopérabilité entre les implémentations initiales. Avant de commencer les travaux qui ont conduit à cet ensemble de spécifications, le groupe de travail 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 avancer sans lui.

The other significant change to the protocols themselves is that the SMTPUTF8 keyword is now required as an SMTP client announcement if the extension is needed; in the experimental version, only the server announcement that an extended envelope and/or content were permitted was necessary.

L'autre changement significatif 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 par le serveur qu'une enveloppe et/ou un contenu étendus étaient autorisés était nécessaire.

7. Overview of Protocol Extensions and Changes (Aperçu des extensions et modifications du protocole)​

7.1. SMTP Extension for Internationalized Email Address (Extension SMTP pour les adresses électroniques internationalisées)​

An SMTP extension, "SMTPUTF8", is specified as follows:

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

  • Permits the use of UTF-8 strings in email addresses, both local parts and domain names.

  • Permet l'utilisation de chaînes UTF-8 dans les adresses électroniques, tant pour les parties locales que pour les noms de domaine.

  • Permits the selective use of UTF-8 strings in email message headers (see Section 7.2).

  • Permet l'utilisation sélective de chaînes UTF-8 dans les en-têtes de message électronique (voir la section 7.2).

  • Requires that the server advertise the 8BITMIME extension [RFC6152] and that the client support 8-bit transmission so that header information can be transmitted without using a special content-transfer-encoding.

  • Exige que le serveur annonce l'extension 8BITMIME [RFC6152] et que le client prenne en charge la transmission 8 bits afin que les informations d'en-tête puissent être transmises sans utiliser un codage de transfert de contenu spécial.

Some general principles affect the development decisions underlying this work.

Certains principes généraux affectent les décisions de développement sous-jacentes à ce travail.

  1. Email addresses enter subsystems (such as a user interface) that may perform charset conversions or other encoding changes. When the local part of the address includes characters outside the ASCII character repertoire, use of ASCII-compatible encoding (ACE) [RFC3492] [RFC5890] in the domain part is discouraged to promote consistent processing of characters throughout the address.

  2. Les adresses électroniques entrent dans des sous-systèmes (tels qu'une interface utilisateur) qui peuvent effectuer des conversions de jeux de caractères ou d'autres changements de codage. Lorsque la partie locale de l'adresse comprend des caractères en dehors du répertoire de caractères ASCII, l'utilisation d'un codage compatible ASCII (ACE) [RFC3492] [RFC5890] dans la partie domaine est découragée pour favoriser un traitement cohérent des caractères tout au long de l'adresse.

  3. An SMTP relay MUST

    • Either recognize the format explicitly, agreeing to do so via an ESMTP option, or
    • Reject the message or, if necessary, return a non-delivery notification message, so that the sender can make another plan.

  4. Un relais SMTP DOIT

    • Soit reconnaître le format explicitement, en acceptant de le faire via une option ESMTP, ou
    • Rejeter le message ou, si nécessaire, renvoyer un message de notification de non-livraison, afin que l'expéditeur puisse faire un autre plan.

  5. If the message cannot be forwarded because the next-hop system cannot accept the extension, it MUST be rejected or a non-delivery message MUST be generated and sent.

  6. Si le message ne peut pas être transféré parce que le système du saut suivant ne peut pas accepter l'extension, il DOIT être rejeté ou un message de non-livraison DOIT être généré et envoyé.

  7. In the interest of interoperability, charsets other than UTF-8 are prohibited in mail addresses and message headers being transmitted over the Internet. There is no practical way to identify multiple charsets properly with an extension similar to this without introducing great complexity.

  8. Dans l'intérêt de l'interopérabilité, les jeux de caractères autres que UTF-8 sont interdits dans les adresses de courrier et les en-têtes de message transmis sur Internet. Il n'y a pas de moyen pratique d'identifier correctement plusieurs jeux de caractères avec une extension similaire à celle-ci sans introduire une grande complexité.

Conformance to the group of standards specified here for email transport and delivery requires implementation of the SMTP extension specification and the UTF-8 header specification. If the system implements IMAP or POP, it MUST conform to the internationalized IMAP [RFC5738bis-IMAP] or POP [RFC5721bis-POP3] specifications respectively.

La conformité au groupe de normes spécifiées ici pour le transport et la livraison du courrier électronique nécessite la mise en œuvre de la spécification d'extension SMTP et de la spécification d'en-tête UTF-8. Si le système implémente IMAP ou POP, il DOIT se conformer respectivement aux spécifications IMAP internationalisées [RFC5738bis-IMAP] ou POP [RFC5721bis-POP3].

7.2. Transmission of Email Header Fields in UTF-8 Encoding (Transmission des champs d'en-tête de courrier électronique en codage UTF-8)​

There are many places in MUAs or in a user presentation in which email addresses or domain names appear. Examples include the conventional "From:", "To:", or "Cc:" header fields; "Message-ID:" and "In-Reply-To:" header fields that normally contain domain names (but that may be a special case); and in message bodies. Each of these must be examined from an internationalization perspective. The user will expect to see mailbox and domain names in local characters, and to see them consistently. If non-obvious encodings, such as protocol-specific ACE variants, are used, the user will inevitably, if only occasionally, see them rather than "native" characters and will find that discomfiting or astonishing. Similarly, if different codings are used for mail transport and message bodies, the user is particularly likely to be surprised, if only as a consequence of the long-established "things leak" principle. The only practical way to avoid these sources of discomfort, in both the medium and the longer term, is to have the encodings used in transport be as similar to the encodings used in message headers and message bodies as possible.

Il existe de nombreux endroits dans les MUA ou dans une présentation utilisateur où les adresses électroniques ou les noms de domaine apparaissent. Les exemples incluent les champs d'en-tête conventionnels "From:", "To:" ou "Cc:" ; les champs d'en-tête "Message-ID:" et "In-Reply-To:" qui contiennent normalement des noms de domaine (mais qui peuvent être un cas particulier) ; et dans les corps de message. Chacun d'eux doit être examiné d'un point de vue de l'internationalisation. L'utilisateur s'attendra à voir les noms de boîte aux lettres et de domaine en caractères locaux, et à les voir de manière cohérente. Si des codages non évidents, tels que des variantes ACE spécifiques au protocole, sont utilisés, l'utilisateur les verra inévitablement, même si ce n'est qu'occasionnellement, plutôt que des caractères "natifs" et trouvera cela déconcertant ou étonnant. De même, si des codages différents sont utilisés pour le transport du courrier et les corps de message, l'utilisateur est particulièrement susceptible d'être surpris, ne serait-ce qu'en conséquence du principe établi de longue date selon lequel "les choses fuient". Le seul moyen pratique d'éviter ces sources d'inconfort, à moyen et à long terme, est d'avoir des codages utilisés dans le transport aussi similaires que possible aux codages utilisés dans les en-têtes de message et les corps de message.

When email local parts are internationalized, they SHOULD be accompanied by arrangements for the message headers to be in the fully internationalized form. That form SHOULD use UTF-8 rather than ASCII as the base character set for the contents of header fields (protocol elements such as the header field names themselves are unchanged and remain entirely in ASCII). For transition purposes and compatibility with legacy systems, this can be done by extending the traditional MIME encoding models for non-ASCII characters in headers [RFC2045] [RFC2231], but even these should be based on UTF-8, rather than other encodings, if at all possible [RFC6055]. However, the target is fully internationalized message headers, as discussed in [RFC6532] and not an extended and painful transition.

Lorsque les parties locales du courrier électronique sont internationalisées, elles DEVRAIENT être accompagnées de dispositions pour que les en-têtes de message soient sous forme entièrement internationalisée. Cette forme DEVRAIT utiliser UTF-8 plutôt que ASCII comme jeu de caractères de base pour le contenu des champs d'en-tête (les éléments de protocole tels que les noms de champ d'en-tête eux-mêmes sont inchangés et restent entièrement en ASCII). À des fins de transition et de compatibilité avec les systèmes hérités, cela peut être fait en étendant les modèles de codage MIME traditionnels pour les caractères non ASCII dans les en-têtes [RFC2045] [RFC2231], mais même ceux-ci devraient être basés sur UTF-8, plutôt que sur d'autres codages, si possible [RFC6055]. Cependant, l'objectif est des en-têtes de message entièrement internationalisés, comme discuté dans [RFC6532] et non une transition prolongée et douloureuse.

7.3. SMTP Service Extension for DSNs (Extension de service SMTP pour les DSN)​

The existing Delivery Status Notifications (DSNs) specification [RFC3461], which is a Draft Standard, is limited to ASCII text in the machine-readable portions of the protocol. "International Delivery and Disposition Notifications" [RFC6533] adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. If an SMTP server advertises both the SMTPUTF8 and the DSN extension, that server MUST implement internationalized DSNs including support for the ORCPT parameter specified in RFC 3461 [RFC3461].

La spécification existante des notifications d'état de livraison (DSN) [RFC3461], qui est un projet de norme, est limitée au texte ASCII dans les parties lisibles par machine du protocole. "International Delivery and Disposition Notifications" [RFC6533] ajoute un nouveau type d'adresse pour les adresses électroniques internationales afin qu'une adresse de destinataire d'origine avec des caractères non ASCII puisse être correctement préservée même après un déclassement. Si un serveur SMTP annonce à la fois l'extension SMTPUTF8 et l'extension DSN, ce serveur DOIT implémenter des DSN internationalisés, y compris la prise en charge du paramètre ORCPT spécifié dans la RFC 3461 [RFC3461].

8. Downgrading before and after SMTP Transactions (Déclassement avant et après les transactions SMTP)​

An important issue with these extensions is how to handle interactions between systems that support non-ASCII addresses and legacy systems that expect ASCII. There is, of course, no problem with ASCII-only systems sending to those that can handle internationalized forms because the ASCII forms are just a proper subset. But, when systems that support these extensions send mail, they MAY include non-ASCII addresses for senders, receivers, or both and might also provide non-ASCII header information other than addresses. If the extension is not supported by the first-hop system (i.e., the SMTP server accessed by the submission server acting as an SMTP client), message-originating systems SHOULD be prepared to either send conventional envelopes and message headers or to return the message to the originating user so the message may be manually downgraded to the traditional form, possibly using encoded words [RFC2047] in the message headers. Of course, such transformations imply that the originating user or system must have ASCII-only addresses available for all senders and recipients. Mechanisms by which such addresses may be found or identified are outside the scope of these specifications as are decisions about the design of originating systems such as whether any required transformations are made by the user, the originating MUA, or the submission server.

Une question importante avec ces extensions est de savoir comment gérer les interactions entre les systèmes qui prennent en charge les adresses non ASCII et les systèmes hérités qui attendent de l'ASCII. Il n'y a, bien sûr, aucun problème avec les systèmes uniquement ASCII envoyant à ceux qui peuvent gérer les formes internationalisées car les formes 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 destinataires, 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 du premier saut (c'est-à-dire le serveur SMTP auquel accède le serveur de soumission agissant en tant que client SMTP), les systèmes d'origine du message DEVRAIENT être prêts soit à envoyer des enveloppes et des en-têtes de message conventionnels, soit à renvoyer le message à l'utilisateur d'origine afin que le message puisse être manuellement déclassé vers la forme traditionnelle, éventuellement en utilisant des mots codés [RFC2047] dans les en-têtes de message. Bien entendu, de telles transformations impliquent que l'utilisateur ou le système d'origine doit disposer d'adresses uniquement ASCII pour tous les expéditeurs et destinataires. Les mécanismes par lesquels de telles adresses peuvent être trouvées ou identifiées sortent du cadre de ces spécifications, tout comme les décisions concernant la conception des systèmes d'origine, telles que la question de savoir si les transformations requises sont effectuées par l'utilisateur, le MUA d'origine ou le serveur de soumission.

A somewhat more complex situation arises when the first-hop system supports these extensions but some subsequent server in the SMTP transmission chain does not. It is important to note that most cases of that situation with forward-pointing addresses will be the result of configuration errors: especially if it hosts non-ASCII addresses, a final delivery MTA that accepts these extensions SHOULD NOT be configured with lower-preference MX hosts that do not. When the only non-ASCII address being transmitted is backward-pointing (e.g., in an SMTP MAIL command), recipient configuration cannot help in general. On the other hand, alternate, all-ASCII addresses for senders are those most likely to be authoritatively known by the submission environment or the sender herself. Consequently, if an intermediate SMTP relay that requires these extensions then discovers that the next system in the chain does not support them, it will have little choice other than to reject or return the message.

Une situation un peu plus complexe se présente lorsque le système du premier saut prend en charge ces extensions mais qu'un serveur ultérieur de la chaîne de transmission SMTP ne le fait pas. Il est important de noter que la plupart des cas de cette situation avec des adresses pointant vers l'avant seront le résultat d'erreurs de configuration : surtout s'il héberge des adresses non ASCII, un MTA de livraison finale qui accepte ces extensions NE DEVRAIT PAS être configuré avec des hôtes MX de préférence inférieure qui ne le font pas. Lorsque la seule adresse non ASCII transmise pointe vers l'arrière (par exemple, dans une commande SMTP MAIL), la configuration du destinataire ne peut généralement pas aider. D'un autre côté, les adresses alternatives, toutes ASCII, pour les expéditeurs sont celles qui sont le plus susceptibles d'être connues de manière autorisée par l'environnement de soumission ou l'expéditeur lui-même. Par conséquent, si un relais SMTP intermédiaire qui nécessite ces extensions découvre ensuite que le système suivant de la chaîne ne les prend pas en charge, il n'aura guère d'autre choix que de rejeter ou de renvoyer le message.

As discussed above, downgrading to an ASCII-only form may occur before or during the initial message submission. It might also occur after the delivery to the final delivery MTA in order to accommodate message stores, IMAP or POP servers, or clients that have different capabilities than the delivery MTA. These cases are discussed in the subsections below.

Comme indiqué ci-dessus, le déclassement vers une forme uniquement ASCII 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 de s'adapter aux magasins de messages, aux serveurs IMAP ou POP, ou aux clients qui ont des capacités différentes de celles du MTA de livraison. Ces cas sont discutés dans les sous-sections ci-dessous.

8.1. Downgrading before or during Message Submission (Déclassement avant ou pendant la soumission du message)​

The IETF has traditionally avoided specifying the precise behavior of MUAs to provide maximum flexibility in the associated user interfaces. The SMTP standard [RFC5321], Section 6.4, gives wide latitude to MUAs and submission servers as to what might be supplied by the user as long as the result conforms with "on the wire" standards once it is injected into the public Internet. In that tradition, the discussion in the remainder of Section 8 is provided as general guidance rather than normative requirements.

L'IETF a traditionnellement évité de spécifier le comportement précis des MUA pour offrir une flexibilité maximale dans les interfaces utilisateur associées. La norme SMTP [RFC5321], section 6.4, laisse une grande latitude aux MUA et aux serveurs de soumission quant à ce qui peut être fourni par l'utilisateur 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 à titre d'orientation générale plutôt que d'exigences normatives.

Messages that require these extensions will sometimes be transferred to a system that does not support these extensions; it is likely that the most common cases will involve the combination of ASCII-only forward-pointing addresses with a non-ASCII backward-pointing one. Until the extensions described here have been universally implemented in the Internet email environment, senders who prefer to use non-ASCII addresses (or raw UTF-8 characters in header fields), even when their intended recipients use and expect all-ASCII ones, will need to be especially careful about the error conditions that can arise. The risks are especially great in environments in which non-delivery messages (or other indications from submission servers) are routinely dropped or ignored.

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 impliqueront la combinaison d'adresses pointant vers l'avant uniquement ASCII avec une adresse pointant vers l'arrière non ASCII. Tant que les extensions décrites ici n'auront pas é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 prévus utilisent et attendent des adresses toutes ASCII, devront être particulièrement prudents quant aux conditions d'erreur qui peuvent survenir. Les risques sont particulièrement grands dans les environnements où les messages de non-livraison (ou d'autres indications des serveurs de soumission) sont régulièrement abandonnés ou ignorés.

Perhaps obviously, the most convenient time to find an ASCII address corresponding to an internationalized address is at the originating MUA or closely associated systems. This can occur either before the message is sent or after the internationalized form of the message is rejected. It is also the most convenient time to convert a message from the internationalized form into conventional ASCII form or to generate a non-delivery message to the sender if either is necessary. At that point, the user has a full range of choices available, including changing backward-pointing addresses, contacting the intended recipient out of band for an alternate address, consulting appropriate directories, arranging for translation of both addresses and message content into a different language, and so on. While it is natural to think of message downgrading as optimally being a fully automated process, we should not underestimate the capabilities of a user of at least moderate intelligence who wishes to communicate with another such user.

Peut-être de manière évidente, le moment le plus pratique pour trouver une adresse ASCII correspondant à une adresse internationalisée se situe au niveau du MUA d'origine ou des systèmes étroitement associés. Cela peut se produire soit avant l'envoi du message, soit après le rejet de la forme internationalisée du message. C'est également le moment le plus pratique pour convertir un message de la forme internationalisée en 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 éventail complet de choix, notamment changer les adresses pointant vers l'arrière, contacter le destinataire prévu hors bande pour une autre adresse, consulter les répertoires appropriés, organiser la traduction des adresses et du contenu du message dans une autre langue, etc. Bien qu'il soit naturel de penser que le déclassement des messages est idéalement un processus entièrement automatisé, nous ne devrions pas sous-estimer les capacités d'un utilisateur d'intelligence au moins moyenne qui souhaite communiquer avec un autre utilisateur de ce type.

In this context, one can easily imagine modifications to message submission servers (as described in RFC 6409 [RFC6409]) so that they would perform downgrading operations or perhaps even upgrading ones. Such operations would permit receiving messages with one or more of the internationalization extensions discussed here and adapting the outgoing message, as needed, to respond to the delivery or next-hop environment the submission server encounters.

Dans ce contexte, on peut facilement imaginer des modifications aux serveurs de soumission de messages (comme décrit dans la RFC 6409 [RFC6409]) afin qu'ils effectuent des opérations de déclassement 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 saut suivant que rencontre le serveur de soumission.

8.2. Downgrading or Other Processing after Final SMTP Delivery (Déclassement ou autre traitement après la livraison SMTP finale)​

When an email message is received by a final delivery MTA, it is usually stored in some form. Then it is retrieved either by software that reads the stored form directly or by client software via some email retrieval mechanisms such as POP or IMAP.

Lorsqu'un message électronique est reçu par un MTA de livraison finale, il est généralement stocké sous une forme quelconque. Ensuite, il est récupéré soit par un logiciel qui lit directement la forme stockée, soit par un logiciel client via certains mécanismes de récupération de courrier électronique tels que POP ou IMAP.

The SMTP extension described in Section 7.1 provides protection only in transport. It does not prevent MUAs and email retrieval mechanisms that have not been upgraded to understand internationalized addresses and UTF-8 message headers from accessing stored internationalized emails.

L'extension SMTP décrite à la section 7.1 ne fournit une protection que lors du 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 à niveau pour comprendre les adresses internationalisées et les en-têtes de message UTF-8 d'accéder aux courriers électroniques internationalisés stockés.

Since the final delivery MTA (or, to be more specific, its corresponding mail storage agent) cannot safely assume that agents accessing email storage will always be capable of handling the extensions proposed here, it MAY downgrade internationalized emails, specially identify messages that utilize these extensions, or both. If either or both of these actions were to be taken, the final delivery MTA SHOULD include a mechanism to preserve or recover the original internationalized forms without information loss. Preservation of that information is necessary to support access by SMTPUTF8-aware agents.

Puisque le MTA de livraison finale (ou, pour être plus précis, 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 PEUT déclasser les courriers électroniques internationalisés, identifier spécialement les messages qui utilisent ces extensions, ou les deux. Si l'une ou les deux de ces actions devaient être entreprises, le MTA de livraison finale DEVRAIT inclure un mécanisme pour préserver ou récupérer les formes internationalisées d'origine sans perte d'information. La préservation de ces informations est nécessaire pour prendre en charge l'accès par des agents compatibles SMTPUTF8.

9. Downgrading in Transit (Déclassement en transit)​

The base SMTP specification (Section 2.3.11 of RFC 5321 [RFC5321]) states that "due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address". This is not a new requirement; equivalent statements appeared in specifications in 2001 [RFC2821] and even in 1989 [RFC1123].

La spécification SMTP de base (Section 2.3.11 de la RFC 5321 [RFC5321]) stipule que "en raison d'une longue histoire de problèmes lorsque des hôtes intermédiaires ont tenté d'optimiser le transport en les modifiant, la partie locale DOIT être interprétée et se voir attribuer une sémantique uniquement par l'hôte spécifié dans la partie domaine de l'adresse". Ce n'est pas une nouvelle exigence ; des déclarations équivalentes sont apparues dans des spécifications en 2001 [RFC2821] et même en 1989 [RFC1123].

Adherence to this rule means that a downgrade mechanism that transforms the local part of an email address cannot be utilized in transit. It can only be applied at the endpoints, specifically by the MUA or submission server or by the final delivery MTA.

Le respect de cette règle signifie qu'un mécanisme de déclassement qui transforme la partie locale d'une adresse électronique ne peut pas être utilisé en transit. Il ne peut être appliqué qu'aux extrémités, plus précisément par le MUA ou le serveur de soumission ou par le MTA de livraison finale.

One of the reasons for this rule has to do with legacy email systems that embed mail routing information in the local part of the address field. Transforming the email address destroys such routing information. There is no way a server other than the final delivery server can know, for example, whether the local part of user%[email protected] is a route ("user" is reached via "foo") or simply a local address.

L'une des raisons de cette règle concerne les systèmes de messagerie hérités 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 routage. Il n'y a aucun moyen pour un serveur autre que le serveur de livraison finale de savoir, par exemple, si la partie locale de user%[email protected] est un itinéraire ("user" est atteint via "foo") ou simplement une adresse locale.

10. User Interface and Configuration Issues (Problèmes d'interface utilisateur et de configuration)​

Internationalization of addresses and message headers, especially in combination with variations on character coding that are inherent to Unicode, may make careful choices of addresses and careful configuration of servers and DNS records even more important than they are for traditional Internet email. It is likely that, as experience develops with the use of these protocols, it will be desirable to produce one or more additional documents that offer guidance for configuration and interfaces. A document that discusses issues with MUAs, especially with regard to downgrading, is expected to be developed. The subsections below address some other issues.

L'internationalisation des adresses et des en-têtes de message, en particulier en combinaison avec les variations de codage de caractères inhérentes à Unicode, peut rendre les choix minutieux d'adresses et la configuration minutieuse des serveurs et des enregistrements DNS encore plus importants qu'ils ne le sont pour le courrier électronique Internet traditionnel. Il est probable que, à mesure que l'expérience se développera avec l'utilisation de ces protocoles, il sera souhaitable de produire un ou plusieurs documents supplémentaires offrant des conseils pour la configuration et les interfaces. Un document traitant des problèmes avec les MUA, notamment en ce qui concerne le déclassement, devrait être développé. Les sous-sections ci-dessous abordent d'autres questions.

10.1. Choices of Mailbox Names and Unicode Normalization (Choix des noms de boîtes aux lettres et normalisation Unicode)​

It has long been the case that the email syntax permits choices about mailbox names that are unwise in practice, if one actually intends the mailboxes to be accessible to a broad range of senders. The most often cited examples involve the use of case-sensitivity and tricky quoting of embedded characters in mailbox local parts. These deliberately unusual constructions are permitted by the protocols, and servers are expected to support them. Although they can provide value in special cases, taking advantage of them is almost always bad practice unless the intent is to create some form of security by obscurity.

Il est depuis longtemps établi que la syntaxe du courrier électronique permet des choix concernant les noms de boîtes aux lettres qui sont peu judicieux dans la pratique, si l'on a réellement l'intention que les boîtes aux lettres soient accessibles à un large éventail d'expéditeurs. Les exemples les plus souvent cités impliquent l'utilisation de la sensibilité à la casse et la citation délicate de caractères intégrés dans les parties locales des boîtes aux lettres. Ces constructions délibérément inhabituelles sont autorisées par les protocoles, et les serveurs sont censés les prendre en charge. Bien qu'elles puissent apporter de la valeur dans des cas particuliers, en tirer parti est presque toujours une mauvaise pratique, à moins que l'intention ne soit de créer une certaine forme de sécurité par l'obscurité.

In the absence of these extensions, SMTP clients and servers are constrained to using only those addresses permitted by RFC 5321. The local parts of those addresses MAY be made up of any ASCII characters except the control characters that RFC 5321 prohibits, although some of them MUST be quoted as specified there. It is notable in an internationalization context that there is a long history on some systems of using overstruck ASCII characters (a character, a backspace, and another character) within a quoted string to approximate non-ASCII characters. This form of internationalization was permitted by RFC 821 [RFC0821] but is prohibited by RFC 5321 because it requires a backspace character (a prohibited C0 control). Because RFC 5321 (and its predecessor, RFC 2821) prohibit the use of this character in ASCII mailbox names and it is even more problematic (for canonicalization and normalization reasons) in non-ASCII strings, backspace MUST NOT appear in SMTPUTF8 mailbox names.

En l'absence de ces extensions, les clients et 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 n'importe quel caractère ASCII, à l'exception des caractères de contrôle interdits par la RFC 5321, bien que certains d'entre eux DOIVENT être cités comme spécifié dans celle-ci. Il est notable dans un contexte d'internationalisation qu'il existe une longue histoire sur certains systèmes d'utilisation de caractères ASCII surfrappés (un caractère, un retour arrière et un autre caractère) à l'intérieur d'une chaîne citée pour approximer des caractères non ASCII. Cette forme d'internationalisation était autorisée par la RFC 821 [RFC0821] mais est interdite par la RFC 5321 car elle nécessite un caractère de retour arrière (un contrôle C0 interdit). Parce que la RFC 5321 (et son prédécesseur, la RFC 2821) interdisent l'utilisation de ce caractère dans les noms de boîtes aux lettres ASCII et qu'il est encore plus problématique (pour des raisons de canonicalisation et de normalisation) dans les chaînes non ASCII, le retour arrière NE DOIT PAS apparaître dans les noms de boîtes aux lettres SMTPUTF8.

For the particular case of mailbox names that contain non-ASCII characters in the local part, domain part, or both, special attention MUST be paid to Unicode normalization [Unicode-UAX15], in part because Unicode strings may be normalized by other processes independent of what a mail protocol specifies (this is exactly analogous to what may happen with quoting and dequoting in traditional addresses). Consequently, the following principles are offered as advice to those who are selecting names for mailboxes:

Pour le cas particulier des noms de boîtes aux lettres contenant des caractères non ASCII dans la partie locale, la partie 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épendamment de ce qu'un protocole de messagerie spécifie (ceci est exactement analogue à ce qui peut se produire avec la citation et la suppression de citation dans les adresses traditionnelles). Par conséquent, les principes suivants sont proposés à titre de conseil à ceux qui choisissent des noms pour les boîtes aux lettres :

  • In general, it is wise to support addresses in Normalized form, using at least Normalization Form NFC. Except in circumstances in which NFKC would map characters together that the parties responsible for the destination mail server would prefer to be kept distinguishable, supporting the NFKC-conformant form would yield even more predictable behavior for the typical user.

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

  • It will usually be wise to support other forms of the same local-part string, either as aliases or by normalization of strings reaching the delivery server: the sender should not be depended upon to send the strings in normalized form.

  • Il sera généralement sage de prendre en charge d'autres formes de la même chaîne de partie locale, soit sous forme d'alias, soit par normalisation des chaînes atteignant le serveur de livraison : on ne devrait pas compter sur l'expéditeur pour envoyer les chaînes sous forme normalisée.

  • Stated differently and in more specific terms, the rules of the protocol for local-part strings essentially provide that:

  • Dit différemment et en termes plus spécifiques, les règles du protocole pour les chaînes de partie locale prévoient essentiellement que :

    • Unnormalized strings are valid, but sufficiently bad practice that they may not work reliably on a global basis. Servers should not depend on clients to send normalized forms but should be aware that procedures on client machines outside the control of the MUA may cause normalized strings to be sent regardless of user intent.

    • Les chaînes non normalisées sont valides, mais constituent une pratique suffisamment mauvaise pour qu'elles puissent ne pas fonctionner de manière fiable à l'échelle mondiale. Les serveurs ne devraient pas compter sur les clients pour envoyer des formes normalisées, mais devraient être conscients que les procédures sur les machines clientes hors du contrôle du MUA peuvent entraîner l'envoi de chaînes normalisées indépendamment de l'intention de l'utilisateur.

    • C0 (and presumably C1) controls (see The Unicode Standard [Unicode]) are prohibited, the first in RFC 5321 and the second by an obvious extension from it [RFC5198].

    • Les contrôles C0 (et vraisemblablement C1) (voir la norme Unicode [Unicode]) sont interdits, le premier dans la RFC 5321 et le second par une extension évidente de celle-ci [RFC5198].

    • Other kinds of punctuation, spaces, etc., are risky practice. Perhaps they will work, and SMTP receiver code is required to handle them without severe errors (even if such strings are not accepted in addresses to be delivered on that server), but creating dependencies on them in mailbox names that are chosen is usually a bad practice and may lead to interoperability problems.

    • D'autres types de ponctuation, d'espaces, etc., sont des pratiques risquées. Peut-être qu'ils fonctionneront, et le code du récepteur SMTP est tenu de 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 égard dans les noms de boîtes aux lettres choisis est généralement une mauvaise pratique et peut entraîner des problèmes d'interopérabilité.

11. Additional Issues (Problèmes supplémentaires)​

This section identifies issues that are not covered, or not covered comprehensively, as part of this set of specifications, but that will require ongoing review as part of deployment of email address and header internationalization.

Cette section identifie les problèmes qui ne sont pas couverts, ou pas couverts de manière exhaustive, dans le cadre de cet ensemble de spécifications, mais qui nécessiteront un examen continu dans le cadre du déploiement de l'internationalisation des adresses électroniques et des en-têtes.

11.1. Impact on URIs and IRIs (Impact sur les URI et les IRI)​

The mailto: schema [RFC6068], and the discussion of it in the Internationalized Resource Identifier (IRI) specification [RFC3987], may need to be modified when this work is completed and standardized.

Le schéma mailto: [RFC6068], et sa discussion dans la spécification de l'identifiant de ressource internationalisé (IRI) [RFC3987], pourraient devoir être modifiés lorsque ce travail sera terminé et normalisé.

11.2. Use of Email Addresses as Identifiers (Utilisation des adresses électroniques comme identifiants)​

There are a number of places in contemporary Internet usage in which email addresses are used as identifiers for individuals, including as identifiers to Web servers supporting some electronic commerce sites and in some X.509 certificates [RFC5280]. These documents do not address those uses, but it is reasonable to expect that some difficulties will be encountered when internationalized addresses are first used in those contexts, many of which cannot even handle the full range of addresses permitted today.

Il existe un certain nombre d'endroits dans l'utilisation contemporaine d'Internet où les adresses électroniques sont utilisées comme identifiants pour les individus, notamment comme identifiants pour les serveurs Web prenant en charge certains sites de commerce électronique et dans certains certificats X.509 [RFC5280]. Ces documents n'abordent pas ces utilisations, mais il est raisonnable de s'attendre à ce que certaines difficultés soient rencontrées lorsque des adresses internationalisé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. Encoded Words, Signed Messages, and Downgrading (Mots codés, messages signés et déclassement)​

One particular characteristic of the email format is its persistency: MUAs are expected to handle messages that were originally sent decades ago and not just those delivered seconds ago. As such, MUAs and mail filtering software, such as that specified in Sieve [RFC5228], will need to continue to accept and decode header fields that use the "encoded word" mechanism [RFC2047] to accommodate non-ASCII characters in some header fields. While extensions to both POP3 [RFC1939] and IMAP [RFC3501] have been defined that include automatic upgrading of messages that carry non-ASCII information in encoded form -- including RFC 2047 decoding -- of messages by the POP3 [RFC5721bis-POP3] or IMAP [RFC5738bis-IMAP] server, there are message structures and MIME content-types for which that cannot be done or where the change would have unacceptable side effects.

Une caractéristique particulière du format de courrier électronique est sa persistance : les MUA sont censés gérer des messages qui ont été envoyés à l'origine il y a des décennies et pas seulement ceux livrés il y a quelques secondes. En tant que tels, les MUA et les logiciels de filtrage de courrier, tels que ceux spécifiés dans Sieve [RFC5228], devront continuer à accepter et à décoder les champs d'en-tête qui utilisent le mécanisme de "mot codé" [RFC2047] pour prendre en charge les caractères non ASCII dans certains champs d'en-tête. Bien que des extensions à POP3 [RFC1939] et IMAP [RFC3501] aient été définies, incluant la mise à niveau automatique des messages contenant des informations non ASCII sous forme codée -- y compris le décodage RFC 2047 -- des messages par le serveur POP3 [RFC5721bis-POP3] ou IMAP [RFC5738bis-IMAP], il existe des structures de message et des types de contenu MIME pour lesquels cela ne peut pas être fait ou où le changement aurait des effets secondaires inacceptables.

For example, message parts that are cryptographically signed, using e.g., S/MIME [RFC5751] or Pretty Good Privacy (PGP) [RFC3156], cannot be upgraded from the RFC 2047 form to normal UTF-8 characters without breaking the signature. Similarly, message parts that are encrypted may contain, when decrypted, header fields that use the RFC 2047 encoding; such messages cannot be 'fully' upgraded without access to cryptographic keys.

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

Similar issues may arise if messages are signed and then subsequently downgraded, e.g., as discussed in Section 8.1, and then an attempt is made to upgrade them to the original form and then verify the signatures. Even the very subtle changes that may result from algorithms to downgrade and then upgrade again may be sufficient to invalidate the signatures if they impact either the primary or MIME body part headers. When signatures are present, downgrading must be performed with extreme care if at all.

Des problèmes similaires peuvent survenir si des messages sont signés puis ultérieurement déclassés, par exemple, comme discuté à la section 8.1, et qu'une tentative est ensuite faite pour les mettre à niveau vers la forme originale puis vérifier les signatures. Même les changements très subtils qui peuvent résulter d'algorithmes de déclassement puis de nouvelle mise à niveau peuvent être suffisants pour invalider les signatures s'ils ont un impact sur les en-têtes primaires ou les en-têtes de partie de corps MIME. Lorsque des signatures sont présentes, le déclassement doit être effectué avec une extrême prudence, voire pas du tout.

11.4. Other Uses of Local Parts (Autres utilisations des parties locales)​

Local parts are sometimes used to construct domain labels, e.g., the local part "user" in the address [email protected] could be converted into a host name user.domain.example with its Web space at http://user.domain.example and the catch-all addresses [email protected].

Les parties locales sont parfois utilisées pour construire des étiquettes de domaine, par exemple, la partie locale "user" dans l'adresse [email protected] pourrait être convertie en un nom d'hôte user.domain.example avec son espace Web à http://user.domain.example et les adresses fourre-tout [email protected].

Such schemes are obviously limited by, among other things, the SMTP rules for domain names, and will not work without further restrictions for other local parts. Whether those limitations are relevant to these specifications is an open question. It may be simply another case of the considerable flexibility accorded to delivery MTAs in determining the mailbox names they will accept and how they are interpreted.

De tels schémas sont évidemment limités par, entre autres, les règles SMTP pour les noms de domaine, et ne fonctionneront pas sans restrictions supplémentaires pour les autres parties locales. La question de savoir si ces limitations sont pertinentes pour ces spécifications reste ouverte. Il peut s'agir simplement d'un autre cas de la flexibilité considérable accordée aux MTA de livraison pour déterminer les noms de boîtes aux lettres qu'ils accepteront et la manière dont ils sont interprétés.

11.5. Non-Standard Encapsulation Formats (Formats d'encapsulation non standard)​

Some applications use formats similar to the application/mbox format [RFC4155] instead of the message/digest form defined in RFC 2046, Section 5.1.5 [RFC2046] to transfer multiple messages as single units. Insofar as such applications assume that all stored messages use the message/rfc822 format described in RFC 2046, Section 5.2.1 [RFC2046] with ASCII message headers, they are not ready for the extensions specified in this series of documents, and special measures may be needed to properly detect and process them.

Certaines applications utilisent des formats similaires au format application/mbox [RFC4155] au lieu de la forme message/digest définie dans la RFC 2046, Section 5.1.5 [RFC2046] pour transférer plusieurs messages en tant qu'unités uniques. Dans la mesure où de telles 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, elles ne sont pas prêtes 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. Key Changes from the Experimental Protocols and Framework (Principaux changements par rapport aux protocoles expérimentaux et au cadre)​

The original framework for internationalized email addresses and headers was described in RFC 4952 and a subsequent set of experimental protocol documents. Those relationships are described in Section 3. The key architectural difference between the experimental specifications and this newer set is that the earlier specifications supported in-transit downgrading. Those mechanisms included the definition of syntax and functions to support passing alternate, all-ASCII addresses with the non-ASCII ones as well as special headers to indicate the downgraded status of messages. Those features were eliminated after experimentation indicated that they were more complex and less necessary than had been assumed earlier. Those issues are described in more detail in Sections 6 and 9.

Le cadre original pour les adresses électroniques et les en-têtes internationalisés a été décrit dans la RFC 4952 et un ensemble ultérieur de documents de protocole expérimentaux. Ces relations sont décrites à 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 prenaient en charge le déclassement en transit. Ces mécanismes comprenaient la définition de la syntaxe et des fonctions pour prendre en charge le passage d'adresses alternatives, toutes ASCII, avec les adresses non ASCII, ainsi que des en-têtes spéciaux pour indiquer le statut déclassé des messages. Ces fonctionnalités ont été éliminées après que l'expérimentation a indiqué qu'elles étaient plus complexes et moins nécessaires qu'on ne le supposait auparavant. Ces problèmes sont décrits plus en détail dans les sections 6 et 9.

13. Security Considerations (Considérations de sécurité)​

Any expansion of permitted characters and encoding forms in email addresses raises some risks. There have been discussions on so called "IDN-spoofing" or "IDN homograph attacks". These attacks allow an attacker (or "phisher") to spoof the domain or URLs of businesses or other entities. The same kind of attack is also possible on the local part of internationalized email addresses. It should be noted that the proposed fix involving forcing all displayed elements into normalized lowercase works for domain names in URLs, but not for email local parts since those are case sensitive.

Toute expansion des caractères et des formes de codage autorisés dans les adresses électroniques soulève certains risques. Il y a eu des discussions sur ce que l'on appelle "l'usurpation d'IDN" ou "les attaques par homographes IDN". Ces attaques permettent à un attaquant (ou "hameçonneur") d'usurper le domaine ou les URL d'entreprises ou d'autres entités. Le même type d'attaque est également possible sur la partie locale des adresses électroniques internationalisées. Il convient de noter que le correctif proposé consistant à forcer tous les éléments affichés en minuscules normalisées fonctionne pour les noms de domaine dans les URL, mais pas pour les parties locales des courriers électroniques, car celles-ci sont sensibles à la casse.

Since email addresses are often transcribed from business cards and notes on paper, they are subject to problems arising from confusable characters (see [RFC4690]). These problems are somewhat reduced if the domain associated with the mailbox is unambiguous and supports a relatively small number of mailboxes whose names follow local system conventions. They are increased with very large mail systems in which users can freely select their own addresses.

Puisque les adresses électroniques sont souvent transcrites à partir de cartes de visite et de notes sur papier, elles sont sujettes aux problèmes découlant de caractères prêtant à confusion (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 restreint de boîtes aux lettres dont les noms suivent les conventions du système local. Ils sont accrus avec de très grands systèmes de messagerie dans lesquels les utilisateurs peuvent choisir librement leurs propres adresses.

The internationalization of email addresses and message headers must not leave the Internet less secure than it is without the required extensions. The requirements and mechanisms documented in this set of specifications do not, in general, raise any new security issues.

L'internationalisation des adresses électroniques et des en-têtes de message ne doit pas rendre l'Internet moins sûr qu'il ne l'est sans les extensions requises. Les exigences et les mécanismes documentés dans cet ensemble de spécifications ne soulèvent généralement pas de nouveaux problèmes de sécurité.

They do require a review of issues associated with confusable characters -- a topic that is being explored thoroughly elsewhere (see, e.g., RFC 4690 [RFC4690]) -- and, potentially, some issues with UTF-8 normalization, discussed in RFC 3629 [RFC3629], and other transformations. Normalization and other issues associated with transformations and standard forms are also part of the subject of work described elsewhere [RFC5198] [RFC5893] [RFC6055].

Ils nécessitent un examen des problèmes associés aux caractères prêtant à confusion -- un sujet qui est exploré en profondeur ailleurs (voir, par exemple, RFC 4690 [RFC4690]) -- et, potentiellement, certains problèmes avec la normalisation UTF-8, discutés dans la 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 des travaux décrits ailleurs [RFC5198] [RFC5893] [RFC6055].

Some issues specifically related to internationalized addresses and message headers are discussed in more detail in the other documents in this set. However, in particular, caution should be taken that any "downgrading" mechanism, or use of downgraded addresses, does not inappropriately assume authenticated bindings between the internationalized and ASCII addresses. This potential problem can be mitigated somewhat by enforcing the expectation that most or all such transformations will be performed prior to final delivery by systems that are presumed to be under the administrative control of the sending user (as opposed to being performed in transit by entities that are not under the administrative control of the sending user).

Certaines questions spécifiquement liées aux adresses et aux en-têtes de message internationalisés sont discutées plus en détail dans les autres documents de cet ensemble. Cependant, il convient en particulier de veiller à ce qu'aucun mécanisme de "déclassement", ou utilisation d'adresses déclassées, ne suppose de manière inappropriée des liens authentifiés entre les adresses internationalisées et ASCII. Ce problème potentiel peut être quelque peu atténué en imposant l'attente que la plupart ou la totalité de ces transformations seront 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).

The new UTF-8 header and message formats might also raise, or aggravate, another known issue. If the model creates new forms of an 'invalid' or 'malformed' message, then a new email attack is created: in an effort to be robust, some or most agents will accept such messages and interpret them as if they were well-formed. If a filter interprets such a message differently than the MUA used by the recipient, then it may be possible to create a message that appears acceptable under the filter's interpretation but that should be rejected under the interpretation given to it by that MUA. Such attacks already have occurred for existing messages and encoding layers, e.g., invalid MIME syntax, invalid HTML markup, and invalid coding of particular image types.

Les nouveaux formats d'en-tête et de message UTF-8 pourraient également soulever, ou aggraver, un autre problème connu. Si le modèle crée de nouvelles formes de message "invalide" ou "malformé", alors une nouvelle attaque par courrier électronique est créée : dans un effort de robustesse, certains ou la plupart des agents accepteront de tels messages et les interpréteront comme s'ils étaient bien formés. Si un filtre interprète un tel message différemment du MUA utilisé par le destinataire, il peut alors ê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 telles attaques se sont déjà produites pour des messages et des couches de codage existants, par exemple, une syntaxe MIME invalide, un balisage HTML invalide et un codage invalide de types d'images particuliers.

In addition, email addresses are used in many contexts other than sending mail, such as for identifiers under various circumstances (see Section 11.2). Each of those contexts will need to be evaluated, in turn, to determine whether the use of non-ASCII forms is appropriate and what particular issues they raise.

De plus, les adresses électroniques sont utilisées dans de nombreux contextes autres que l'envoi de courrier, tels que pour des identifiants dans diverses circonstances (voir la section 11.2). Chacun de ces contextes devra être évalué, tour à tour, pour déterminer si l'utilisation de formes non ASCII est appropriée et quels problèmes particuliers elles soulèvent.

This work will clearly affect any systems or mechanisms that are dependent on digital signatures or similar integrity protection for email message headers (see also the discussion in Section 11.3). Many conventional uses of PGP and S/MIME are not affected since they are used to sign body parts but not message headers. On the other hand, the developing work on DomainKeys Identified Mail (DKIM) [RFC5863] will eventually need to consider this work, and vice versa: while this specification does not address or solve the issues raised by DKIM and other signed header mechanisms, the issues will have to be coordinated and resolved eventually if the two sets of protocols are to coexist. In addition, to the degree to which email addresses appear in PKI (Public Key Infrastructure) certificates [RFC5280], standards addressing such certificates will need to be upgraded to address these internationalized addresses. Those upgrades will need to address questions of spoofing by look-alikes of the addresses themselves.

Ce travail affectera clairement tous les systèmes ou mécanismes qui dépendent de signatures numériques ou d'une protection d'intégrité similaire pour les en-têtes de message électronique (voir également la discussion à 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, les travaux en cours sur DomainKeys Identified Mail (DKIM) [RFC5863] devront éventuellement prendre en compte ce travail, et vice versa : bien que cette spécification n'aborde ni ne résolve les problèmes soulevés par DKIM et d'autres mécanismes d'en-tête signés, les problèmes devront être coordonnés et résolus à terme si les deux ensembles de protocoles doivent coexister. De plus, dans la mesure où les adresses électroniques apparaissent dans les certificats PKI (Public Key Infrastructure) [RFC5280], les normes traitant de tels certificats devront être mises à niveau pour traiter ces adresses internationalisées. Ces mises à niveau devront aborder les questions d'usurpation par des sosies des adresses elles-mêmes.

14. Acknowledgments (Remerciements)​

This document is an update to, and derived from, RFC 4952. This document would have been impossible without the work and contributions acknowledged in it. The present document benefited significantly from discussions in the IETF EAI working group and elsewhere after RFC 4952 was published, especially discussions about the experimental versions of other documents in the internationalized email collection, and from RFC errata on RFC 4952 itself.

Ce document est une mise à jour de la RFC 4952 et en est dérivé. Ce document aurait été impossible sans le travail et les contributions qui y sont reconnus. Le présent document a grandement bénéficié des discussions au sein du groupe de travail IETF EAI et ailleurs après la publication de la RFC 4952, en particulier les discussions sur les versions expérimentales d'autres documents de la collection de courrier électronique internationalisé, et des errata RFC sur la RFC 4952 elle-même.

Special thanks are due to Ernie Dainow for careful reviews and suggested text in this version and to several IESG members for a careful review and specific suggestions.

Des remerciements particuliers sont dus à Ernie Dainow pour ses examens attentifs et ses suggestions de texte dans cette version, ainsi qu'à plusieurs membres de l'IESG pour un examen attentif et des suggestions spécifiques.

15. References (Références)​

15.1. Normative References (Références normatives)​

  • [ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

  • [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.

  • [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

  • [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.

  • [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.

  • [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.

  • [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Address", RFC 6531, February 2012.

  • [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.

  • [RFC6533] Hansen, T., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, February 2012.

15.2. Informative References (Références informatives)​

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

  • [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.

  • [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.

  • [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.

  • [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

  • [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

  • [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.

  • [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.

  • [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.

  • [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.

  • [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.

  • [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.

  • [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.

  • [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.

  • [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.

  • [RFC4155] Hall, E., "The application/mbox Media Type", RFC 4155, September 2005.

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

  • [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.

  • [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.

  • [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.

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

  • [RFC5335] Yang, A., "Internationalized Email Headers", RFC 5335, September 2008.

  • [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.

  • [RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 5337, September 2008.

  • [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for Email Address Internationalization", RFC 5504, March 2009.

  • [RFC5721] Gellens, R. and C. Newman, "POP3 Support for UTF-8", RFC 5721, February 2010.

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

  • [RFC5738] Resnick, P. and C. Newman, "IMAP Support for UTF-8", RFC 5738, March 2010.

  • [RFC5738bis-IMAP] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP Support for UTF-8", Work in Progress, December 2011.

  • [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.

  • [RFC5825] Fujiwara, K. and B. Leiba, "Displaying Downgraded Messages for Email Address Internationalization", RFC 5825, April 2010.

  • [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, May 2010.

  • [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.

  • [RFC5892] Faltstrom, P., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010.

  • [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010.

  • [RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010.

  • [RFC5983] Gellens, R., "Mailing Lists and Internationalized Email Addresses", RFC 5983, October 2010.

  • [RFC5983bis-MailingList] Levine, J. and R. Gellens, "Mailing Lists and UTF-8 Addresses", Work in Progress, December 2011.

  • [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011.

  • [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, October 2010.

  • [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.

  • [Unicode] The Unicode Consortium. The Unicode Standard, Version 6.0.0, defined by:, "The Unicode Standard, Version 6.0.0", (Mountain View, CA: The Unicode Consortium, 2011. ISBN 978-1-936213-01-6)., http://www.unicode.org/versions/Unicode6.0.0/.

  • [Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", September 2010, http://www.unicode.org/reports/tr15/.

Dernière mise à jour le