8. Rétrogradation avant et après les transactions SMTP
Un problème important avec ces extensions est la façon de gérer les interactions entre les systèmes qui prennent en charge les adresses non ASCII et les systèmes anciens qui s'attendent à ASCII. Il n'y a, bien sûr, aucun problème avec les systèmes ASCII envoyés à ceux qui peuvent traiter des formulaires internationaux parce que les formulaires 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 récepteurs 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 de première sortie (c'est-à-dire le serveur SMTP accédé par le serveur de soumission agissant en tant que client SMTP), les systèmes d'origine de message DEVRAient être prêts à envoyer des enveloppes et des en-têtes de message conventionnels ou à renvoyer le message à l'utilisateur d'origine afin que le message puisse être dégradé manuellement à la forme traditionnelle, éventuellement en utilisant des mots codés [RFC2047] dans les en-têtes de message. Bien sûr, ces transformations impliquent que l'utilisateur ou le système d'origine doit avoir des adresses ASCII uniquement disponibles pour tous les expéditeurs et les destinataires. Les mécanismes par lesquels de telles adresses peuvent être trouvées ou identifiées sont en dehors de la portée de ces spécifications, comme les décisions concernant la conception des systèmes d'origine telles que si des transformations requises sont faites par l'utilisateur, l'utilisateur ou le serveur de soumission MUA.
Une situation un peu plus complexe se produit lorsque le système de premier bond prend en charge ces extensions mais que certains serveurs ultérieurs de la chaîne de transmission SMTP ne le font pas. Il est important de noter que la plupart des cas de cette situation avec des adresses de pointe vers l'avant seront le résultat d'erreurs de configuration: en particulier si elle héberge des adresses non ASCII, une MTA de livraison finale qui accepte ces extensions NE DEVRAIT PAS être configurée avec des hôtes MX de faible préférence qui ne le font pas. Lorsque le seul adresse non ASCII qui est transmise est de pointe vers l'arrière (par exemple, dans un SMTP MAIL), la configuration du destinataire ne peut pas s'aider en général. D'autre part, les adresses alternatives, toutes ASCII pour les expéditeurs sont celles qui sont les plus susceptibles d'être connues de manière autoritaire par l'environnement de soumission ou l'expéditeur. Par conséquent, si un relais SMTP intermédiaire qui nécessite ces extensions découvre que le prochain système de la chaîne ne les prend pas en charge, il n'aura pas d'autre choix que de rejeter ou de retourner le message.
Comme mentionné ci-dessus, la dégradation à un formulaire ASCII uniquement 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 d'accueillir les magasins de messages, les serveurs IMAP ou POP, ou les clients qui ont des capacités différentes de la livraison MTA. Ces cas sont discutés dans les sous-sections ci-dessous.
8.1. Rétrogradation avant ou pendant la soumission du message
L'IETF a traditionnellement évité de spécifier le comportement précis des MUA pour fournir une flexibilité maximale dans les interfaces utilisateur associées. La norme SMTP [RFC5321], section 6.4, donne une large latitude aux MUA et aux serveurs de soumission quant à ce que l'utilisateur pourrait fournir 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 comme une orientation générale plutôt que comme des exigences normatives.
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 impliquent la combinaison d'adresses de pointe vers l'avant uniquement ASCII avec une adresse de pointe vers l'arrière non ASCII. Jusqu'à ce que les extensions décrites ici aient é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 utilisent et s'attendent à tous les ASCII, devront être particulièrement prudents quant aux conditions d'erreur qui peuvent survenir. Les risques sont particulièrement importants dans les environnements dans lesquels les messages non-livrables (ou d'autres indications des serveurs soumis) sont systématiquement abandonnés ou ignorés.
Il est évident que le moment le plus pratique pour trouver une adresse ASCII correspondant à une adresse internationalement est peut-être à l'AU d'origine ou à des systèmes étroitement associés. Cela peut se produire soit avant l'envoi du message, soit après que la forme internationalement modifiée du message ait été rejetée. C'est également le moment le plus pratique pour convertir un message de la forme internationalement modifiée en une 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 large éventail de choix, y compris le changement d'adresses de pointe arrière, le contact avec le destinataire hors bande pour une adresse alternative, la consultation des annuaires appropriées, la préparation de la traduction des deux adresses et du contenu du message dans une langue différente, etc. Bien qu'il soit naturel de penser que la dégradation des messages est optimalement un processus entièrement automatisé, nous ne devrions pas sous-estimer les capacités d'un utilisateur d'intelligence au moins modérée qui souhaite communiquer avec un autre utilisateur de ce type.
Dans ce contexte, on peut facilement imaginer des modifications aux serveurs de soumission de messages (comme décrit dans RFC 6409 [RFC6409]) afin qu'ils effectuent des opérations de dégradation 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 prochaine sortie que rencontre le serveur de soumission.
8.2. Rétrogradation ou autre traitement après la remise SMTP finale
Lorsqu'un message électronique est reçu par un MTA de livraison finale, il est généralement stocké sous une forme ou une autre.
L'extension SMTP décrite à la section 7.1 ne protège que dans le 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 à jour pour comprendre les adresses internationalement enregistrées et les en-têtes de messages UTF-8 d'accéder aux courriels internationalement enregistrés.
Étant donné que le MTA de livraison finale (ou, plus précisément, 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 POURRAIT dégrader les courriels internationaux, spécifiquement identifier les messages qui utilisent ces extensions, ou les deux. Si l'une ou les deux de ces actions devaient être prises, le MTA de livraison finale DOIT inclure un mécanisme pour préserver ou récupérer les formulaires internationaux originaux sans perte d'informations. La préservation de ces informations est nécessaire pour soutenir l'accès par les agents SMTPUTF8 conscients.