Aller au contenu principal

10. Interface utilisateur et problèmes de configuration

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

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

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

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

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

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

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

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

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

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

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