Aller au contenu principal

7. Aperçu des extensions et modifications de protocole

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

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

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

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

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

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

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

  2. Un relais SMTP MUST:

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

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

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

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

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

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

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

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

7.3. Extension du service SMTP pour les DSN​

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