Aller au contenu principal

4. Terminologie

Le présent document suppose une compréhension raisonnable des protocoles et de la terminologie des normes de base de messagerie, tels que documentés dans les RFC 5321 [RFC5321] et RFC 5322 [RFC5322].

4.1. Utilisateurs et agents de transfert du courrier​

Une grande partie de la description de ce document dépend des abstractions de "Mail Transfer Agent" ("MTA") et "Mail User Agent" ("MUA"). Cependant, il est important de comprendre que ces termes et les concepts sous-jacents datent de la conception de l'architecture de courrier électronique d'Internet et de l'application du principe des "protocoles sur le fil" à elle. Cette architecture de courrier électronique, telle qu'elle a évolué, et ce principe "sur le fil" ont empêché toute distinction forte et normalisée sur la façon dont les MTA et les MUA interagissent sur un hôte d'origine ou de destination donné (ou même si elles sont séparées).

Cependant, le terme "MTA de livraison finale" est utilisé dans ce document d'une manière équivalente au terme "système de livraison" ou "système de livraison finale" de la RFC 5321. C'est le serveur SMTP qui contrôle le format des parties locales des adresses et est autorisé à les inspecter et à les interpréter. Il reçoit des messages du réseau pour la livraison aux boîtes postales ou pour un autre traitement local, y compris tout transfert ou aliasing qui change les adresses d'enveloppe, plutôt que de relayer. Du point de vue du réseau, tout arrangement de livraison local tel que l'enregistrement dans un magasin de messages, la remise à des programmes ou agents de livraison de messages spécifiques, et les mécanismes de récupération de messages sont tous "derrière" le MTA de livraison finale et ne font donc pas partie du processus de transport ou de livraison SMTP.

4.2. Jeux de caractères des adresses​

Dans ce document, une adresse est "toute ASCII", ou simplement "adresse ASCII", si chaque caractère de l'adresse est dans le répertoire de caractères ASCII [ASCII]; une adresse est "non-ASCII", ou une "i18n-adresse", si un caractère n'est pas dans le répertoire de caractères ASCII. De telles adresses peuvent être restreintes d'autres manières, mais ces restrictions ne sont pas pertinentes pour cette définition. Le terme "toute ASCII" est également appliqué à d'autres éléments de protocole lorsque la distinction est importante, avec "non-ASCII" ou "internationalisé" comme son contraire.

Le terme général décrivant l'internationalisation de l'adresse e-mail spécifiée par le présent document et ses documents d'accompagnement est "SMTPUTF8". Par exemple, une adresse autorisée par ce document est appelée "SMTPUTF8 (adresses conformes).

Veuillez noter que, selon les définitions données ici, l'ensemble de toutes les adresses "toutes ASCII" et l'ensemble de toutes les adresses "non ASCII" sont mutuellement exclusives.

4.3. Types d'utilisateurs​

Un "utilisateur ASCII" (i) utilise exclusivement des adresses e-mail qui ne contiennent que des caractères ASCII et (ii) ne peut pas générer des adresses destinataires qui ne contiennent pas de caractères ASCII.

Un "utilisateur d'e-mail internationalisé" a une ou plusieurs adresses e-mail non ASCII, ou est capable de générer des adresses destinataires qui contiennent des caractères non ASCII. Un tel utilisateur peut également avoir des adresses ASCII; si l'utilisateur a plus d'un compte e-mail et une adresse correspondante, ou plus d'un alias pour la même adresse, il ou elle a une méthode pour choisir l'adresse à utiliser sur le courrier électronique sortant. Notez qu'en vertu de cette définition, il n'est pas possible de dire à partir d'une adresse ASCII si le propriétaire de cette adresse est un utilisateur d'e-mail internationalisé ou non. (Une adresse non ASCII implique une croyance que le propriétaire de cette adresse est un utilisateur d'e-mail internationalisé.) Il n'y a pas de telle chose comme un "message d'e-mail internationalisé"; le terme s'applique uniquement aux utilisateurs et à leurs agents et capacités utilisateurs. En particulier, l'utilisation de contenus non ASCII, et donc présumément internationaux, des messages fait partie intégrante des spécifications MIME [RFC2045] et ne nécessite pas ces extensions (bien qu'il soit compatible avec elles).

4.4. Messages​

Un "message" est envoyé d'un utilisateur (l'expéditeur) à l'aide d'une adresse e-mail particulière à une ou plusieurs autres adresses e-mail destinataires (souvent désignées simplement comme "utilisateurs" ou "utilisateurs destinataires").

4.5. Listes de diffusion​

Une " liste de diffusion " est un mécanisme par lequel un message peut être distribué à plusieurs destinataires en l'envoyant à une seule adresse destinataire. Un agent (généralement pas un être humain) à cette adresse unique fait ensuite que le message soit redistribué aux destinataires cibles. Cet agent fixe l'adresse de retour de l'enveloppe du message redistribué à une adresse différente de celle du message original. L'utilisation d'une adresse de retour d'enveloppe différente (route inverse) provoque un traitement d'erreur (et d'autres messages générés automatiquement) pour se rendre à une adresse d'erreur.

Les dispositions spéciales relatives à la gestion des listes de diffusion qui pourraient contenir des adresses non ASCII sont discutées dans un document spécifique à ce sujet [RFC5983] et à son successeur attendu [RFC5983bis-MailingList].

4.6. Message conventionnel et message internationalisé​

  • Un message conventionnel est celui qui n'utilise aucune extension définie dans le document d'extension SMTP [RFC6531] ou dans le document UTF8header [RFC6532] dans cet ensemble de spécifications, et qui est strictement conforme à la RFC 5322 [RFC5322].

  • Un message international est un message qui utilise une ou plusieurs des extensions définies dans cet ensemble de spécifications, de sorte qu'il ne soit plus conforme à la spécification traditionnelle d'un message électronique ou de son transport.

4.7. Messages non distribuables, notifications et accusés de remise​

Comme spécifié dans RFC 5321, un message qui n'est pas livrable pour une raison quelconque est prévu de se traduire par une notification à l'expéditeur. Cela peut se produire de l'une des deux façons. L'une, généralement appelée "Réjection", se produit lorsqu'un serveur SMTP renvoie un code de réponse indiquant une erreur fatale (un code "5yz") ou renvoie persistamment une erreur d'échec temporaire (un code "4yz"). L'autre implique d'accepter le message lors du traitement SMTP et de générer un message à l'expéditeur, généralement connu sous le nom de "Notification de non-livrabilité" ou "NDN". La pratique actuelle favorise souvent le rejet sur les NDN en raison de la probabilité réduite que la génération de NDN sera utilisée comme technique de spam.

Un expéditeur PEUT également demander explicitement des reçus de message [RFC3461] qui soulèvent les mêmes problèmes pour ces extensions d'internationalisation que les NND.