4. Considérations de sécurité

Parce que l'UTF-8 nécessite souvent plusieurs octets pour encoder un seul caractère, l'internationalisation peut allonger les valeurs des champs d'en-tête (en général) et les adresses de courrier (en particulier). Comme spécifié dans [RFC5322], chaque ligne de caractères ne doit pas (MUST NOT) dépasser 998 octets, CRLF exclu. D'autre part, les processus MDA (Mail Delivery Agent) qui analysent, stockent ou traitent des adresses de courrier ou des parties locales doivent prendre un soin particulier à ne pas déborder des tampons, tronquer des adresses ou dépasser les quotas de stockage. De plus, lors des comparaisons, ils doivent veiller à utiliser la longueur totale des adresses.

Il existe de nombreuses façons d'utiliser l'UTF-8 pour représenter quelque chose d'équivalent ou de similaire à un caractère affiché particulier ou à un groupe de caractères; voir les considérations de sécurité de [RFC3629] pour plus de détails sur les problèmes que cela peut causer. Le processus de normalisation décrit à la section 3.1 est recommandé pour minimiser ces problèmes.

L'impact sur la sécurité des en-têtes UTF-8 sur les systèmes de signature de courrier électronique tels que Domain Keys Identified Mail (DKIM), S/MIME et OpenPGP est examiné à la section 14 de [RFC6530].

Si un utilisateur possède une adresse de boîte aux lettres non ASCII et une adresse de boîte aux lettres ASCII, un certificat numérique identifiant cet utilisateur peut contenir les deux adresses dans son identité. Le fait d'avoir plusieurs adresses de courrier électronique comme identités dans un seul certificat est déjà pris en charge dans PKIX (Public Key Infrastructure using X.509) [RFC5280] et OpenPGP [RFC3156], mais des problèmes d'interface utilisateur peuvent être associés à l'introduction de l'UTF-8 dans les adresses dans ce contexte.