Courriel international - International email

Le courrier électronique international résulte de la fourniture combinée de noms de domaine internationalisés ( IDN ) et d' internationalisation d'adresses électroniques ( EAI ). Le résultat est un courrier électronique contenant des caractères internationaux (caractères qui n'existent pas dans le jeu de caractères ASCII ), codés en UTF-8 , dans l'en- tête du courrier électronique et dans les protocoles de transfert de courrier prenant en charge. L'aspect le plus important de ceci est l'allocation d' adresses e - mail (également appelées identités e-mail) dans la plupart des systèmes d'écriture du monde, à la fois au niveau de l'interface et du transport.

Adresses mail

Les adresses e-mail traditionnelles sont limitées aux caractères de l' alphabet anglais et à quelques autres caractères spéciaux.

Les adresses e-mail traditionnelles valides sont les suivantes : 

Abc@example.com                               (English, ASCII)
Abc.123@example.com                           (English, ASCII)   
user+mailbox/department=shipping@example.com  (English, ASCII)
!#$%&'*+-/=?^_`.{|}~@example.com              (English, ASCII)
"Abc@def"@example.com                         (English, ASCII)
"Fred\ Bloggs"@example.com                    (English, ASCII)
"Joe.\\Blow"@example.com                      (English, ASCII)

Un Russe peut souhaiter utiliser иван.сергеев@пример.рф comme identifiant, mais être obligé d'utiliser une transcription telle que ivan.sergeev@example.ru ou même un autre identifiant totalement indépendant à la place. La même chose est clairement vraie pour le chinois, le japonais et de nombreuses autres nationalités qui n'utilisent pas d' écriture latine , mais s'applique également aux utilisateurs de pays européens non anglophones dont les adresses souhaitées peuvent contenir des signes diacritiques (par exemple, André ou Płużyna ). En conséquence, les utilisateurs de messagerie sont obligés de s'identifier à l'aide de scripts non natifs - ou les programmeurs de systèmes de messagerie doivent compenser cela en convertissant les identifiants de leurs scripts natifs en scripts ASCII et inversement au niveau de l'interface utilisateur.

Le courrier électronique international, en revanche, utilise des caractères Unicode codés en UTF-8 , ce qui permet de coder le texte des adresses dans la plupart des systèmes d'écriture du monde.

Les adresses suivantes sont toutes des adresses e-mail internationales valides : 

用户@例子.广告               (Chinese, Unicode)
अजय@डाटा.भारत               (Hindi, Unicode)
квіточка@пошта.укр          (Ukrainian, Unicode)
χρήστης@παράδειγμα.ελ       (Greek, Unicode)
Dörte@Sörensen.example.com  (German, Unicode)
коля@пример.рф              (Russian, Unicode)

En revanche, dans le cas des domaines Idn qui relèvent des exceptions, ils ne font donc pas l'objet d'un encodage, ou parce que les caractères natifs n'ont pas de traduction ou parce qu'il n'y a pas encore d'encodage pour ces certains caractères, les e respectifs -les adresses mail seront également affichées en caractères natifs et non leur code punicode. Ainsi, par exemple, pour le domaine xn--9ckb.com, l'adresse e-mail indiquée ci-dessous est affichée telle qu'elle est écrite sur Gmail et presque tous les autres services de messagerie internationaux. 

support@ツッ.com            (Katakana, Unicode)

En-têtes UTF-8

Bien que le format traditionnel de la section d'en-tête des e-mails permette d'inclure des caractères non ASCII dans la partie valeur de certains champs d'en-tête en utilisant des mots codés MIME (par exemple dans les noms d'affichage ou dans un champ d'en-tête Objet ), le codage MIME ne doit pas être utilisé pour encoder d'autres informations dans un en-tête, telles qu'une adresse e-mail, ou des champs d'en-tête tels que Message-ID ou Received . De plus, le codage MIME nécessite un traitement supplémentaire de l'en-tête pour convertir les données vers et à partir de sa représentation de mot codée MIME, et nuit à la lisibilité d'une section d'en-tête.

Les normes RFC 6532 et RFC 6531 de 2012 autorisent l'inclusion de caractères Unicode dans un contenu d'en-tête à l'aide de l'encodage UTF-8 et leur transmission via SMTP, mais dans la pratique, la prise en charge ne se déploie que lentement.

Interopérabilité par rétrogradation

L'internationalisation du domaine fonctionne par déclassement. Les parties UTF-8, appelées U-Labels, sont transformées en A-Labels via une méthode ad hoc appelée IDNA. Par exemple, sörensen.example.comest codé comme xn--srensen-90a.example.com. En 2003, lorsque le besoin a été satisfait, cela semblait plus facile que de vérifier que tous les logiciels DNS pouvaient être conformes aux chaînes UTF-8, bien qu'en théorie, le DNS puisse transporter des données binaires. Ce codage est nécessaire avant d'émettre des requêtes DNS.

Notez que les noms de domaine sont également, sinon principalement, utilisés pour la navigation Web. L'EAI diffère.

Étant donné que les normes de courrier électronique traditionnelles contraignent toutes les valeurs d'en-tête de courrier électronique à des caractères ASCII uniquement, il est possible que la présence de caractères UTF-8 dans les en-têtes de courrier électronique diminue la stabilité et la fiabilité du transport de ce courrier électronique. C'est parce que certains serveurs de messagerie ne prennent pas en charge ces caractères. La vérification de la conformité avec les chaînes UTF-8 doit être effectuée progiciel par progiciel (voir #Adoption ci-dessous). prise en charge des serveurs. Cette proposition était trop lourde, car la signification de la partie gauche d'une adresse e-mail est locale au serveur cible. Aucun moyen de vérifier qu'il ne s'agit pas d'un nom d'utilisateur valide, utilisé dans certains domaines. Cette expérience a donc été rendue obsolète en 2012 par la RFC 6530. xn--something

Cadre de normes

L'ensemble des documents Internet RFC RFC 6530, RFC 6531, RFC 6532 et RFC 6533, tous publiés en février 2012, définissent les mécanismes et les extensions de protocole nécessaires pour prendre pleinement en charge les adresses électroniques internationalisées. Ces modifications incluent une extension SMTP et une extension de la syntaxe de l'en-tête des e-mails pour s'adapter aux données UTF-8. L'ensemble de documents comprend également une discussion sur les hypothèses et les problèmes clés liés au déploiement d'e-mails entièrement internationalisés.

Adoption

  • 2013-11-14 : La chauve-souris ! Le client de messagerie a implémenté la prise en charge des noms de domaine internationalisés (IDN) dans les adresses e-mail.
  • 2014-07-15: Postfix mailer a commencé à prendre en charge le courrier internationalisé, également connu sous le nom d' EAI ou SMTPUTF8 , défini dans RFC 6530 .. RFC 6533. Le support initial a été rendu disponible avec une version de développement 20140715, et le 2015-02-08 s'est terminé en une version stable 3.0.0. Cela prend en charge UTF-8 dans les adresses d'expéditeur SMTP ou LMTP, les adresses de destinataire et les valeurs d'en-tête de message.
  • 2014-07-19 : XgenPlus Email Server a commencé à prendre en charge les e-mails basés sur les IDN, également connus sous le nom de prise en charge de SMTPUTF8 , en particulier pour le domaine .भारत.
  • 05-08-2014 : Google a annoncé que Gmail reconnaîtra les adresses contenant des caractères accentués ou non latins, avec une prise en charge supplémentaire de l'internationalisation à venir. Leurs expéditeurs (MX MTA) annoncent la prise en charge de SMTP Extension for Internationalized Email (SMTPUTF8, RFC 6531).
  • 2014-09-30 : Message Systems a annoncé que son produit Momentum (versions 4.1 et 3.6.5) prend en charge SMTPUTF8 , l'extension d'internationalisation des adresses e-mail au protocole SMTP, permettant d'envoyer des e-mails à de nouveaux destinataires non occidentaux.
  • 2014-10-22: la version 2.10.0 du filtre de contenu de messagerie Amavis a été publiée, ajoutant la prise en charge de SMTPUTF8 , EAI et IDN .
  • 2016-12-07 : почта.рус lance un courrier électronique entièrement en russe (cyrillique) à Moscou via une conférence de presse.
  • Le ministre en chef Vasundhara Raje du Rajasthan a lancé une adresse e-mail gratuite @rajasthan.in et un domaine @राजस्थान.भारत le 3 décembre 2017. L'État du Rajasthan est devenu le premier État au monde à fournir une adresse e-mail à chaque citoyen dans sa propre langue.
  • 2016-10-18 : Data Xgen Technologies a lancé une adresse e-mail linguistique gratuite sous le nom « DATAMAIL ». À l'appui de Digital India, cela a fait arrêter une application de messagerie indienne qui prend en charge IDN ( nom de domaine internationalisé ) en hindi (हिन्दी), gujarati (ગુજરાતી), ourdou (اردو), pendjabi (ਪੰਜਾਬੀ ਦੇ), tamoul (தமிழ்), telgu (తెలుగు ), bengali (বাংলা), marathi (मराठी), anglais latin. DATAMAIL a lancé des langues internationales pour les pays utilisant l'arabe (العَرَبِيَّة), le russe (русский) et le chinois (汉语/漢語) comme langue de base.
  • 2017-03-07 : Apple Store inclut un produit pour prendre en charge EAI.
  • 2017-12-27 : Microsoft annonce la prochaine prise en charge de la messagerie IDN sur Office 365 et annonce également le partenaire XgenPlus hébergeant les boîtes aux lettres IDN.
  • 03/01/2018 : Microsoft ajoute l'internationalisation des e-mails à Exchange Online.
  • 2018-09-18 : Courier-MTA publie la prise en charge des messages électroniques Unicode, en UTF-8, pour tous les packages Courier. De plus, Courier-IMAP utilise Unicode (UTF8) pour les noms des dossiers maildir.

Voir également

Les références

Bibliographie

Liens externes