Groupe de travail Réseau	D. Crocker, Brandenburg InternetWorking	
Request for Comments : 5598	juillet 2009	
Catégorie : Information	Traduction Claude Brière de l'Isle	

Architecture de la messagerie Internet

Résumé
Dans son histoire vieille de plus de trente cinq ans, la messagerie Internet a changé significativement d'échelle et de complexité, car elle est devenue un service d'infrastructure mondiale. Ces changements ont été évolutifs, plutôt que révolutionnaires, reflétant un fort désir de préserver à la fois sa base installée et son utilité. Pour collaborer de façon productive sur ce système vaste et complexe, tous les participants ont besoin de travailler à une vue commune et d'utiliser un langage commun pour décrire ses composants et les interactions entre eux. Mais les nombreuses différences de perspective rendent actuellement difficile de savoir exactement ce que les autres participants comprennent. Pour servir de cadre de référence commun nécessaire, le présent document décrit l'architecture améliorée de la messagerie électronique de l'Internet, reflétant le service actuel.

Statut de ce mémoire
Le présent mémoire apporte des informations pour la communauté de l'Internet. Le présent mémoire ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiée comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.
Table des Matières
1. Introduction	2
1.1 Historique	2
1.2 Rôle de cette architecture	3
1.3 Conventions du document	4
2. Rôles d'acteur responsable	4
2.1 Acteurs utilisateurs	4
2.2 Acteurs du service de traitement de message (MHS)	6
2.3 Acteurs administratifs	7
3. Identités	9
3.1 Boîte aux lettres	9
3.2 Portée de l'utilisation d'une adresse de messagerie électronique	9
3.3 Noms de domaines	9
3.4 Identifiant de message	10
4. Services et normes	11
4.1 Données de message	12
4.2 Services de niveau utilisateur	15
4.3 Services de niveau MHS	15
4.5 Mise en œuvre et fonctionnement	17
5. Médiateurs	18
5.1 Alias	18
5.2 Renvoyeur	19
5.3 Listes de diffusion	19
5.4 Passerelles	20
5.5 Filtre de frontière	21
6. Considérations	21
6.1 Considérations sur la sécurité	21
6.2 Internationalisation	22
7. Références	23
7.1 Références normatives	23
7.2 Références pour information	24
Appendice A. Remerciements	25
Adresse de l'auteur	26

1.	Introduction

Pendant ses trente cinq ans d’histoire, la messagerie Internet a changé significativement d’échelle et de complexité, car elle est devenue un service d’infrastructure mondiale. Ces changements ont été évolutifs plutôt que révolutionnaires, reflétant un fort désir de préserver à la fois sa base installée et son utilité. Aujourd’hui, la messagerie Internet est distinguée par de nombreux opérateurs indépendants, de nombreux composants différents pour fournir le service aux utilisateurs, ainsi que de nombreux composants différents qui transfèrent les messages.

Les normes techniques sous-jacentes de la messagerie Internet comprennent un riche éventail de capacités fonctionnelles. Les spécifications suivantes en forment le cœur :
*	Le protocole simple de transfert de messagerie (SMTP, Simple Mail Transfer Protocol) ([RFC0821], [RFC2821], [RFC5321]) déplace un message à travers l’Internet.
*	Le format du message Internet (IMF, Internet Message Format) ([RFC0733], [RFC0822], [RFC2822], [RFC5322]) définit un objet de message.
*	Les extensions de message Internet multi-objets (MIME, Multipurpose Internet Message Extensions) [RFC2045] définissent une amélioration de l’objet de message qui permet d’utiliser des pièces jointes de divers supports.

La collaboration publique sur les activités techniques, de fonctionnement, et de politique de la messagerie, incluant celles qui répondent aux défis de l’emploi abusif de la messagerie, a amené une gamme beaucoup plus large de participants dans la communauté technique. Pour collaborer de façon productive à ce système vaste et complexe, tous les participants doivent travailler à partir d’une vue commune et utiliser un langage commun pour décrire ses composants et leurs interactions. Mais les nombreuses différences de perspective rendent actuellement difficile de savoir exactement ce que pensent les autres participants.

C’est la nécessité de résoudre ces différences qui motive le présent document, qui décrit les réalités du système actuel. La messagerie Internet est le sujet du travail technique, opérationnel, et de politique actuel, et les discussions sont souvent gênées par des modèles différents de conception du service de messagerie et des significations différentes sur les mêmes termes.

Pour servir de cadre de référence commun nécessaire, le présent document décrit l’architecture améliorée de la messagerie Internet, reflétant le service actuel. Le document se concentre sur :
*	saisir les raffinements au modèle de la messagerie électronique,
*	préciser les rôles fonctionnels des composants architecturaux,
*	préciser les problèmes relatifs à l’identité, à travers le service de messagerie électronique,
*	définir la terminologie des composants architecturaux et leurs interactions.

1.1	Historique
La première architecture normalisée pour la messagerie électronique en réseau spécifiait un simple partage entre le monde de l’utilisateur, sous la forme des agents d’utilisateur de message (MUA, Message User Agent) et le monde du transfert, sous la forme du service de traitement de message (MHS, Message Handling Service) qui est composé d’agents de transfert de messages (MTA, Message Transfer Agent) [RFC1506]. Le MHS accepte un message provenant d’un utilisateur et le livre à un ou plusieurs autres utilisateurs, créant un environnement virtuel d’échange de MUA à MUA.

Comme le montre la Figure 1, cette architecture définit deux couches logiques d’interopérabilité. Une est directement entre les utilisateurs. L’autre est parmi les composants le long du chemin de transfert. De plus, il y a interopérabilité entre les couches, d’abord quand un message est posté de l’utilisateur au MHS et ensuite quand il est livré du MHS à l’utilisateur.

Le fonctionnement du service a évolué, bien que les aspects centraux du service, comme l’adressage des boîtes aux lettres et le style de format de message restent remarquablement constants. La distinction originale entre le niveau utilisateur et le niveau transfert subsiste, mais avec des évolutions dans chacun. Le terme de "messagerie Internet" est utilisé pour se référer à la collection entière des composants et services d’utilisateur et de transfert.

Pour la messagerie Internet, le terme "bout en bout" se réfère généralement à un seul envoi et à l’ensemble de livraisons qui résulte d’un seul transit du MHS. Une exception courante est le dialogue de groupe qui est médiatisé à travers une liste de diffusion ; dans ce cas, deux envois se produisent avant que les receveurs prévus reçoivent un message de l’auteur, comme discuté au paragraphe 2.1.4. En fait, certains usages de la messagerie considèrent le service de messagerie électronique entier, incluant l’auteur et le receveur, comme un composant subordonné. Pour ces services, "de bout en bout" se réfère à des points en dehors du service de messagerie électronique. Des exemples sont la messagerie vocale sur messagerie électronique [RFC3801], l’échange de données électroniques (EDI, Electronic Data Interchange) sur messagerie électronique [RFC1767], et la télécopie sur messagerie électronique [RFC4142].

                                         +--------+
                      ++================>| Usager |
                      ||                 +--------+
                      ||                      ^
          +--------+  ||          +--------+  .
          | Usager +==++=========>| Usager |  .
          +---+----+  ||          +--------+  .
              .       ||               ^      .
              .       ||   +--------+  .      .
              .       ++==>| Usager |  .      .
              .            +--------+  .      .
              .                 ^      .      .
              .                 .      .      .
              V                 .      .      .
          +---+-----------------+------+------+---+
          |   .                 .      .      .   |
          |   .................>.      .      .   |
          |   .                        .      .   |
          |   ........................>.      .   |
          |   .                               .   |
          |   ...............................>.   |
          |                                       |
          | Service de traitement de message (MHS)|
          +---------------------------------------+

Légende : les lignes === indiquent les transferts ou rôles principaux (éventuellement indirects)
                 les lignes ... indiquent la prise en charge des transferts ou rôles

Figure 1 : Modèle du service de messagerie Internet de base

Les échanges de messagerie Internet de bout en bout sont accomplis en utilisant une infrastructure normalisée avec les composants et caractéristiques suivants :
*	Un objet de messagerie électronique
*	Un adressage mondial
*	Une séquence asynchrone de mécanismes de transfert en point à point
*	Pas d’exigence d’accord préalable entre les MTA ou entre auteurs et receveurs
*	Pas d’exigence d’accord préalable entre services de transfert point à point sur l’Internet ouvert
*	Pas d’exigence que l’auteur, le générateur, ou les receveurs soient en ligne au même moment.

La portion de bout en bout du service est l’objet de messagerie électronique, appelé un "message". En gros, le message lui-même distingue les informations de contrôle, pour le traitement, du contenu de l’auteur.

Un précepte de la conception de la messagerie électronique sur l’Internet ouvert est de permettre l’interopérabilité d’utilisateur à utilisateur et de MTA à MTA sans accord préalable direct entre les autorités administratives indépendantes responsables du traitement d’un message. Tous les participants se fondent sur la prise en charge universelle et l’accessibilité des services de cœur, directement ou à travers des passerelles qui agissent comme traducteurs entre messagerie Internet et environnements de messagerie électronique conformes à d’autres normes. Étant donnée l’importance de la spontanéité et de la sérénité des communications interpersonnelles, ne pas exiger un tel accord préalable entre participants est un avantage central de la messagerie Internet et reste une exigence centrale pour elle.

Dans des réseaux localisés à la bordure de l’Internet public, un accord administratif préalable est souvent requis et peut inclure un contrôle d’accès, des contraintes d’acheminement, et la configuration du service d’interrogation des informations. Bien que l’authentification du receveur ait généralement été exigée pour l’accès aux messages depuis les débuts de la messagerie Internet, ces récentes années elle a aussi été exigée pour la soumission de message. Dans ce cas, un serveur valide l’identité du client, par des protocoles de sécurité explicites ou par des interrogations implicites d’infrastructure pour identifier les participants "locaux".

1.2	Rôle de cette architecture
Un service Internet est une intégration de capacités relatives entre deux nœuds participants ou plus. Les capacités sont réalisées à travers l’Internet par un ou plusieurs protocoles. Ce qui connecte un protocole à un service est une architecture. Une architecture spécifie comment les protocoles mettent en œuvre le service en définissant les composants logiques d’un service et les relations entre eux. À partir de cette vue logique, un service définit ce qui est à faire, une architecture définit où sont les éléments (en relation avec chaque autre) et un protocole définit comment les capacités particulières sont effectuées.

À ce titre, une architecture va définir plus formellement un service à un niveau relativement élevé. Un protocole qui met en œuvre une portion d’un service va se conformer à l’architecture dans une mesure plus ou moins grande, selon les compromis pragmatiques qu’ils font quand ils essayent de mettre en œuvre l’architecture dans le contexte des contraintes du monde réel. Manquer à suivre précisément une architecture n’est pas une défaillance du protocole, ni n’est une défaillance pour un protocole de prédire précisément une défaillance de l’architecture. Lorsque un protocole diffère de l’architecture, il va bien sûr être approprié qu’il explique la raison de la variante. Cependant, une telle variante n’est pas un défaut d’un protocole. Heureusement, l’IETF préfère le code qui fonctionne à la pureté architecturale.

Dans ce cas particulier, cette architecture tente de définir les composants logiques de la messagerie Internet et le fait a posteriori en essayant de capter les principes architecturaux qu’incorporent les protocoles actuels de messagerie électronique. À différent égards, les protocoles de messagerie électronique vont se conformer plus ou moins bien à cette architecture. Dans la mesure où cette architecture diffère de ces protocoles, les raisons sont généralement bien comprises et sont exigées pour l’inter-fonctionnement. Les différences ne sont pas le signe que les protocoles doivent être corrigés. Cependant, cette architecture est une meilleure tentative d’un modèle logique de la messagerie Internet, et dans la mesure où un nouveau développement de protocole diffère de cette architecture, il est nécessaire que les concepteurs comprennent ces différences et les expliquent précisément.

1.3	Conventions du document
Les références aux champs structurés d’un message utilisent une notation à deux parties séparées par un point. La première partie cite le document qui contient la spécification du champ, et la seconde partie est le nom du champ. Donc <RFC5322.From> est le champ d'en-tête IMF From: dans un en-tête de contenu de message électronique, et <RFC5321.MailFrom> est l’adresse dans la commande SMTP "Mail From".

Quand ils se produisent sans le qualificatif IMF (RFC 5322) les noms de champ d'en-tête sont montrés avec un suffixe de deux-points. Par exemple, From:.

Les références aux étiquettes pour les acteurs, fonctions ou composants ont leur première lettre en majuscule.

2.	Rôles d'acteur responsable

La messagerie Internet est un service largement distrubué, avec divers acteurs qui tiennent des rôles différents. Ces acteurs entrent dans trois types de base :
*	Utilisateur
*	Service de traitement de message (MHS, Message Handling Service)
*	Domaine de gestion administrative (ADMD, ADministrative Management Domain)

Bien que relatifs à une architecture technique, l’objet des acteurs concerne les responsabilités des participants,plutôt que la fonction des modules. Pour cette raison, les étiquettes utilisées sont différentes de celles utilisées dans les diagrammes classiques de l’architecture de la messagerie électronique.

2.1	Acteurs utilisateurs
Les utilisateurs sont les sources et les collecteurs de messages. Les utilisateurs peuvent être des personnes, des organisations, ou des processus. Ils peuvent avoir un échange qui se répète, et ils peuvent étendre ou contracter l’ensemble des utilisateurs qui participent à un ensemble d’échanges. Dans la messagerie Internet, il y a quatre types d’utilisateurs :
*	les auteurs
*	les receveurs
*	les traitements de retour
*	les médiateurs

La Figure 2 montre les flux primaires et secondaires de messages entre eux. Comme heuristique pragmatique, les acteurs utilisateurs peuvent générer, modifier, ou chercher le message entier.

           ++==========++
           ||  Auteur  ||<..................................<..
           ++=++=++=++=++                                     .
              || || ||     ++===========++                    .
              || || ++====>|| Receveur  ||                    .
              || ||        ++=====+=====++                    .
              || ||               .                           .
              || ||               ..........................>.+
              || ||                                           .
              || ||               ...................         .
              || ||               .                 .         .
              || ||               V                 .         .
              || ||         +-----------+    ++=====+=====++  .
              || ++========>| Médiateur +===>|| Receveur  ||  .
              ||            +-----+-----+    ++=====+=====++  .
              ||                  .                 .         .
              ||                  ..................+.......>.+
              ||                                              .
              ||    ..............+..................         .
              ||    .             .                 .         .
              \/    V             V                 '         .
           +-----------+    +-----------+    ++=====+=====++  .
           | Médiateur +===>| Médiateur +===>|| Receveur  ||  .
           +-----+-----+    +-----+-----+    ++=====+=====++  .
                 .                .                 .         .
                 .................+.................+.......>..

Légende : les lignes === indiquent les transferts ou rôle primaires (éventuellement indirects)
                 les lignes …. indiquent la prise en charge des transferts ou rôles

Figure 2 : Relations entre les acteurs utilisateurs

Du point de vue d’un utilisateur, toutes les activités de transfert de message sont effectuées par un service de transfert de message (MHS) monolithique, même quand le service réel peut être fourni par de nombreuses organisations indépendantes. Les utilisateurs sont les consommateurs de ce service unifié.

Chaque fois qu’un acteur MHS renvoie des informations à un auteur ou générateur dans la séquence de traitement d’un message, cet acteur est un utilisateur.

2.1.1	Auteur
L’auteur est responsable de la création du message, de son contenu, et de la liste des adresses des receveurs. Le MHS transfère le message de l’auteur et le livre aux receveurs. Le MHS a un rôle de générateur (paragraphe 2.2.1) qui est corrélé au rôle de l’auteur.

2.1.2	Receveur
Les receveurs sont les consommateurs du message livré. Le MHS a un rôle de receveur (paragraphe 2.2.4) qui se corrèle au rôle de receveur. Cela est marqué Recv dans la Figure 3.

Tous les receveurs peuvent clore la boucle de communication d’utilisateur en créant et soumettant un nouveau message qui répond à l’auteur. Un exemple d’une forme automatisée de réponse est la notification de disposition de message (MDN, Message Disposition Notification) qui informe l’auteur du traitement du message par les receveurs. (Voir au paragraphe  4.1.)

2.1.3	Traitement de retour
Aussi appelé "traitement de rebond", le traitement de retour est une forme particulière de receveurs chargés de servir les notifications générées par le MHS lorsque il transfère ou livre le message. (Voir la Figure 3.) Ces notifications peuvent être sur des défaillances ou des achèvements et sont envoyées à une adresse qui est spécifiée par le générateur. Cette adresse de traitement de retour (aussi appelée adresse de retour) pourrait ne pas avoir de caractéristiques visibles en commun avec l’adresse de l’auteur ou générateur.

2.1.4	Médiateur
Un médiateur reçoit, agrège, reformule, et redistribue les messages parmi les auteurs et receveurs qui sont les principaux dans les échanges (potentiellement) prolongés. Cette activité est facilement confondue avec les échanges de transfert du MHS sous-jacent. Cependant, chacun sert un objet très différent et opère de façon très différente.

Quand un message est livré au médiateur spécifié dans la commande RFC5321.RcptTo pour le message original, le MHS le traite de la même façon que pour tout autre receveur. En particulier,le MHS voit chaque activité d’envoi et de livraison entre les sources et les collecteurs comme indépendante ; il ne voit pas les renvois suivants comme une continuation d’un processus. Parce que le médiateur génère les messages, il peut recevoir les réponses. Donc, quand il soumet un message reformulé, le médiateur est un auteur, quoique auteur servant en fait d’agent d’un ou plusieurs autres auteurs. Donc un médiateur est réellement un utilisateur de plein droit. Les médiateurs sont examinés en détails à la Section 5.

Un médiateur tente de préserver les informations de l’auteur d'origine dans le message qu’il reformule mais il lui est permis de faire des changements significatifs au contenu ou à l’enveloppe du message. Le MHS voit un nouveau message, mais les utilisateurs reçoivent un message qu’ils interprètent comme venant de, ou au moins initié par, l’auteur du message original. Le rôle d’un médiateur ne se limite pas à simplement connecter les autres participants ; le médiateur est responsable du nouveau message.

Le rôle d’un médiateur est complexe et contingent, par exemple, modifier et ajouter du contenu ou réguler quels utilisateurs sont admis à participer et quand. L’exemple courant de ce rôle est une liste de diffusion de groupe. Dans une utilisation plus complexe, une séquence de médiateurs pourrait effectuer une séquence d’étapes formelles, comme de revoir, modifier, et approuver une demande d’achat.
Une passerelle est une forme particulièrement intéressante de médiateur. Elle est un hybride d’utilisateur et de relais qui connecte des services de messagerie hétérogènes. Son objet est d’émuler un relais. Pour une discussion détaillée, voir le paragraphe 2.2.3.

2.2	Acteurs du service de traitement de message (MHS)
Les service de traitement de messages (MHS, Message Handling Service) effectue un seul transfert de bout en bout au nom de l’auteur pour atteindre les adresses de receveurs spécifiées dans les commandes RFC5321.RcptTo originales. Les échanges qui sont soit médiatisés, soit itératifs et prolongés, comme ceux utilisés pour une collaboration durable, sont traités par les acteurs utilisateurs, pas par les acteurs MHS. À titre d’heuristique pragmatique, les acteurs MHS génèrent, modifient, ou cherchent seulement les données de transfert, plutôt que le message entier.

La Figure 3 montre les relations entre les participants au transfert dans la messagerie Internet. Bien qu’elle montre le générateur (marqué Origine) comme distinct de l’auteur, et du receveur (marqué Recv) comme distinct du récipient, chaque paire de rôles a généralement le même acteur. Les transferts impliquent normalement un ou plusieurs relais. Cependant, la livraison directe du générateur au receveur est possible. Les services de messagerie intra-organisation ont généralement un seul relais.

           ++==========++                        ++===========++
           ||  Auteur  ||                        || Récipient ||
           ++====++====++   +--------+           ++===========++
                 ||         | Retour |                  /\
                 ||         +-+------+                  ||
                 \/           .    ^                    ||
             +---------+      .    .                +---++---+
             |         |      .    .                |        |
          /--+---------+----------------------------+--------+----\
          |  |         |      .    .      MHS       |        |    |
          |  | Origine +<......    .................+  Recv  |    |
          |  +---++----+           ^                +--------+    |
          |      ||  ..............+..................  ||        |
          |      \/  .             .                 .  ||        |
          |  +-------+-+        +--+------+        +-+--++---+    |
          |  |  Relais +=======>|  Relais +=======>|  Relais |    |
          |  +---------+        +----++---+        +---------+    |
          |                          ||                           |
          |                          \/                           |
          |                    +----------+                       |
          |                    |passerelle+-->...                 |
          |                    +----------+                       |
          \-------------------------------------------------------/

Légende : les lignes === et || indiquent les transferts ou rôle primaires (éventuellement indirects)
                 les lignes …. indiquent la prise en charge des transferts ou rôles

Figure 3 : Relations entre les acteurs MHS

2.2.1	Générateur
Le générateur s’assure qu’un message est valide pour envoi et le soumet alors à un relais. Un message est valide si il se conforme à la fois aux normes de la messagerie Internet et aux politiques de fonctionnement locales. Le générateur peut simplement revoir le message quant à sa conformité et le rejeter si il trouve des erreurs, ou il peut créer les informations nécessaires. En fait, le générateur est responsable des fonctions de l’agent de soumission de message.

Le générateur fonctionne sous une double allégeance. Il sert l’auteur et peut être la même entité. Mais son rôle pour assurer la validité signifie qu’il représente aussi l’opérateur local du MHS, c’est-à-dire, le domaine de gestion administrative (ADMD, ADministrative Management Domain) local.

Le générateur effectue aussi toutes les tâches administratives de post-soumission relatives à l’auteur, associées au transfert et à la livraison du message. Notamment, les tâches relevant de l’envoi de notification d’erreur et de livraison, d’application de la politique locale, et de traiter les messages provenant de l’auteur qui se révèlent problématiques pour l’Internet. Le générateur est comptable du contenu du message, même quand il n’en est pas responsable. L’auteur crée le message, mais le générateur en traite tous les problèmes de transmission.

2.2.2	Relais
Le relais effectue l’acheminement de service de transfert au niveau du MHS et mémorise et transmet ou retransmet le message à ses receveurs. Le relais ajoute des informations de trace [RFC2505] mais ne modifie pas les informations d’enveloppe ou la sémantique du contenu du message. Il peut modifier la représentation du contenu du message, comme de changer la forme du codage de transfert de binaire en texte, mais seulement comme nécessaire pour satisfaire les capacités du prochain bond dans le MHS.

Un réseau de système de traitement de message (MHS, Message Handling System) consiste en un ensemble de relais. Ce réseau est au-dessus de tout réseau sous-jacent de commutation de paquets qui pourrait être utilisé et en dessous de toute passerelle ou autres médiateurs.

En d’autres termes, les scénarios de messagerie électronique peuvent impliquer trois couches d’architecture distinctes, chacune fournissant son propre type de données de service de mémorisation-transmission :
*	utilisateurs médiateurs
*	relais de MHS
*	commutateurs de paquets

La couche inférieure est le service IP de l’Internet. Les scénarios les plus basiques de messagerie impliquent des relais et des commutateurs.

Quand un relais cesse de tenter de transférer un message, il devient un auteur parce qu’il envoie un message d’erreur à l’adresse de retour. Le potentiel de boucles est évité en omettant l’adresse de retour dans ce message.

2.2.3	Passerelle
Une passerelle est un hybride d’utilisateur et de relais qui connecte des services de messagerie hétérogènes. Son objet est d’émuler un relais et plus il est proche de cela, meilleur c’est. Une passerelle opère comme utilisateur quand elle a besoin de la capacité de modifier le contenu du message.

Les différences entre les services de messagerie peuvent être minimes comme des variations mineures de syntaxe, mais elles comportent généralement des distinctions sémantiques significatives. Une différence pourrait être des adresses de messagerie qui sont hiérarchiques et spécifiques de la machine plutôt qu’un espace de noms plat, mondial. Une autre différence pourrait être la prise en charge de contenu seulement de texte ou multimédia. Donc la fonction de relais dans une passerelle présente un défi de conception significatif si les performances résultantes doivent être vues comme presque sans interruption. Le défi est de s’assurer d’une fonction d’utilisateur à utilisateur entre les services, en dépit des différences de leur syntaxe et sémantique.

L’essai de base de la conception de passerelle est si un auteur d’un côté d’une passerelle peut envoyer un message utile aux receveurs de l’autre côté, sans exiger de changements aux composants des services de messagerie de l’auteur ou des receveurs, autres que l’ajout de la passerelle. Pour chacun de ces services par ailleurs indépendants, la passerelle apparaît comme étant un participant natif. Mais l’essai ultime de la conception de passerelle est si l’auteur et les receveurs peuvent soutenir un dialogue. En particulier, le MUA des receveurs peut il automatiquement formuler une réponse valide qui va atteindre l’auteur ?

2.2.4	Receveur
Le receveur effectue la livraison finale ou envoie le message à une adresse de remplacement. Il peut aussi effectuer un filtrage et autre application de politique immédiatement avant ou après la livraison.

2.3	Acteurs administratifs
Les acteurs administratifs peuvent être associés à différentes organisations, chacune avec sa propre autorité administrative. Cette indépendance de fonctionnement, couplée au besoin d’interaction entre groupes, fournit la motivation pour distinguer entre les domaines de gestion administrative (ADMD). Chaque ADMD peut avoir des politiques très différentes de fonctionnement et de prise de décision fondées sur la confiance. Un exemple évident est la distinction entre la messagerie qui est échangée au sein d’une organisation et celle qui est échangée entre des organisations indépendantes. Les règles pour traiter les deux types de trafic tendent à être assez différentes. Cette différence exige de définir les limites de chacune, et cela exige la construction du ADMD.

Le fonctionnement des services de messagerie Internet est effectué par différents fournisseurs (ou opérateurs). Chacun peut être un ADMD indépendant. Cette indépendance de prise de décision administrative définit les frontières qui distinguent les différentes portions du service de messagerie Internet. Un département qui gère un relais local, un département IT qui gère un relais d’entreprise, et un FAI qui gère un service de messagerie électronique publique partagée peut être configuré en de nombreuses combinaisons de relations administratives et opérationnelles. Chacune est un ADMD distinct, ayant potentiellement un arrangement complexe de composants fonctionnels. La Figure 4 décrit les relations entre des ADMD. L’avantage de la construction des ADMD est qu’elle facilite la discussion sur les conceptions, les politiques, et les opérations qui doivent distinguer entre les problèmes internes et externes.

L’impact architectural du besoin de frontières entre les ADMD est discuté dans [Tussle]. Le plus significntif est que les entités qui communiquent à travers les frontières des ADMD ont normalement la charge supplémentaire d’appliquer les politiques organisationnelles concernant les communications externes. À un niveau plus terre à terre, l’acheminement de la messagerie entre les ADMD peut poser des problèmes, comme d’exiger d’acheminer des messages entre des partenaires organisationnels sur des chemins particulièrement de confiance.

Il y a trois types de base d’ADMD :

Bordure : des services de transfert indépendants dans des réseaux à la bordure du service ouvert de messagerie Internet.

Consommateur : pourrait être un type de service de bordure, comme c’est courant pour l’accès à la messagerie fondée sur la Toile.

Transit : les fournisseurs de service de messagerie (MSP,  Mail Service Provider) qui offrent des capacité à valeur ajoutée pour les ADMD de bordure, comme l’agrégation et le filtrage.

Le service de transit au niveau de la messagerie est différent de la commutation de niveau paquet. Les transferts de paquet de bout en bout passent généralement à travers des routeurs intermédiaires ; l’échange de messages à travers l’Internet ouvert peut être directement entre les MTA de bordure des ADMD de bordure. Cette distinction entre interaction directe et indirecte souligne les différences discutées au paragraphe 2.2.2.

      +--------+     +---------+     +---------+     +--------------+
      |  ADMD1 |<===>|  ADMD2  |<===>|  ADMD3  |<===>|    ADMD4     |
      |  ----- |     |  -----  |     | ------- |     |   --------   |
      |        |     |         |     |         |     |              |
      | auteur |     |         |     |         |     |  receveurs   |
      |   .    |     |         |     |         |     |      ^       |
      |   V    |     |         |     |         |     |      .       |
      |Bordure.+....>|.Transit.+....>|-Bordure.+....>|.Consommateur |
      |        |     |         |     |         |     |              |
      +--------+     +---------+     +---------+     +--------------+

Légende : les lignes === et || indiquent les transferts ou rôle primaires (éventuellement indirects)
                 les lignes …. indiquent la prise en charge des transferts ou rôles

Figure 4 : Exemple de domaine administratif (ADMD)

Les réseaux de bordure peuvent utiliser des standard de messagerie propriétaires en interne. Cependant, la distinction entre services de transfert de réseau de transit et réseau de bordure est significative parce que elle souligne le besoin de se soucier des interactions et de la protection entre administrations indépendantes. En particulier, cette distinction invite à une attention supplémentaire au traitement des transitions de responsabilité et des relations de comptabilité et d’autorisation entre les participants au transfert de messages.

Les interactions des composants d’ADMD sont l’objet des politiques de ce domaine, qui couvrent des questions telles que :
*	la fiabilité
*	le contrôle d’accès
*	la comptabilité
*	l’évaluation et la modification de contenu

Ces politiques peuvent être mises en œuvre dans différents composants fonctionnels, selon les besoins de l’ADMD. Par exemple, voir la [RFC5068].

Les services de consommateur, de bordure, et de transit peuvent être offerts par les fournisseurs qui assurent des services ou ensembles de services de composants. De plus, il est possible à un ADMD d’héberger des services pour d’autres ADMD.

Voici des exemples courants d’ADMD :

Fournisseurs de service d’entreprise : ces ADMD opèrent sur les données internes et/ou les services de messagerie au sein d’une organisation.

Fournisseurs d’accès Internet (FAI) : ces ADMD opèrent sur les services de communication de données sous-jacents qui sont utilisés par un ou plusieurs relais et utilisateurs. Les FAI ne sont pas responsables de la réalisation des fonctions de messagerie électronique, mais ils peuvent fournir un environnement dans lequel ces fonctions peuvent être effectuées.

Fournisseurs de service de messagerie : ces ADMD opèrent sur des services de messagerie, comme pour des consommateurs ou des entreprises clientes.

Les problèmes de fonctionnement pratiques exigent que les fournisseurs soient impliqués dans les questions d’administration et d’application. Cette implication peut s’étendre aux opérateurs de services de paquet de niveau inférieur.

3.	Identités

Les formes d’identité utilisées par la messagerie Internet sont : boîte aux lettres, nom de domaine, identifiant de message, et ENVID (identifiant d’enveloppe). Chacune est unique au monde.

3.1	Boîte aux lettres
"Une boîte aux lettres reçoit les messages. C’est une entité conceptuelle qui ne relève pas nécessairement d’une mémorisation de fichier". [RFC5322]

Une boîte aux lettres est spécifiée comme une adresse de messagerie Internet <addr-spec>. Elle a deux parties distinctes, séparées par un signe (@). Le côté droit est un nom de domaine interprété mondialement associé à un ADMD. Les noms de domaines sont discutés au paragraphe 3.3. La syntaxe formelle de l’adressage de messagerie Internet peut prendre en charge des routes de source pour indiquer le chemin à travers lequel un message devrait être envoyé. L’utilisation des routes de source n’est pas courant et a été déconseillé dans la [RFC5321].

La portion à la gauche du signe @ contient une chaîne qui est opaque et est appelée la <partie locale>. Elle est interprétée seulement par l’entité spécifiée par le nom de domaine de l’adresse. Sauf comme noté plus loin dans ce paragraphe, toutes les autres entités traitent la <partie locale> comme une chaîne littérale non interprétée et préservent tous ses détails originaux. À ce titre, sa distribution publique est équivalente à l’envoi d’un "mouchard" de navigateur de la Toile qui est seulement interprété lorsque il est retourné à son créateur.

Certaines valeurs de parties locales ont été normalisées pour contacter une personne dans une organisation. Ces noms couvrent des opérations courantes et des fonctions d’affaires [RFC2142].

Il est courant que des sites aient des conventions locales de structuration pour le côté gauche, <local-part>, d’une <addr-spec>. Cela permet le sous adressage, comme pour distinguer différents groupes de discussion utilisés par le même participant. Cependant, on doit souligner que ces conventions sont strictement privées pour l’organisation de l’utilisateur et ne sont pas interprétées par un domaine à part celui mentionné sur le côté droit de la <addr-spec>. Les exceptions sont celles de services spécialisés qui se conforment aux conventions publiques, normalisées, comme noté ci-dessous.

L’adressage de messagerie de base définit la <partie locale> comme étant globalement opaque. Cependant, certains usages de messagerie ajoutent un schéma global normalisé à la valeur, comme entre un auteur et une passerelle. Les détails de la <partie locale> restent invisibles à l’infrastructure de transfert de la messagerie publique, mais fournissent les instructions d’adressage et de traitement pour les actions ultérieure de la passerelle. Des exemples normalisés de ces conventions sont le format de numérotation téléphonique pour le profil vocal pour la messagerie Internet (VPIM, Voice Profile for Internet Mail) [RFC3801], comme : +16137637582@vpim.exemple.com, et iFax ([RFC3192], [RFC4143] comme dans : FAX=+12027653000/T33S=1387@ifax.exemple.com.

3.2	Portée de l'utilisation d'une adresse de messagerie électronique
Les adresses de messagerie électronique sont utilisées bien au-delà de leur rôle original dans le transfert et la livraison de messages. En termes pratiques, une chaîne d’adresse de messagerie est devenue l’identifiant commun pour représenter une identité en ligne. Donc, il est essentiel d’être clair sur la nature et le rôle d’une chaîne d’identité dans un contexte particulier et sur l’entité responsable de l’établissement de cette chaîne. Pour des exemples, voir les paragraphes 4.1.4, 4.3.3, et la Section 5.

3.3	Noms de domaines
Un nom de domaine est une référence mondiale à une ressource Internet, comme un hôte, un service, ou un réseau. Un nom de domaine se transpose généralement en une ou plusieurs adresses IP. Conceptuellement, le nom peut englober une organisation, une collection de machines intégrées dans un service homogène, ou une seule machine. Un nom de domaine peut être administré comme se référant à un utilisateur individuel, mais ce n’est pas une pratique courante. Le nom est structuré comme une séquence hiérarchique d’étiquettes, séparées par des points (.) le sommet de la hiérarchie étant à l’extrémité droite de la séquence. Il peut y avoir de nombreux noms dans la séquence -- c’est-à-dire, la profondeur de la hiérarchie peut être substantielle. Les noms de domaines sont définis et traités par le système des noms de domaines (DNS, Domain Name System) ([RFC1034], [RFC1035], [RFC2181]).

Quand il ne fait pas partie d’une adresse de boîte aux lettres, un nom de domaine est utilisé dans la messagerie Internet pour se référer à l’ADMD ou à l’hôte qui a agit sur le message, comme de fournir la portée administrative d’un identifiant de message ou d’effectuer le traitement de transfert.

3.4	Identifiant de message
Deux étiquettes sont normalisées pour identifier les messages : Message-ID: (identifiant de message) et ENVID (identifiant d’enveloppe). Un Message-ID: relève du contenu, et un ENVID relève du transfert.

3.4.1	Message-ID
Le format de messages Internet (IMF) fournit, au plus, un seul Message-ID:. Le Message-ID: pour un seul message, qui est une étiquette IMF de niveau utilisateur, a diverses utilisations qui incluent le tramage, l’aide à l’identification des dupliqués, et le traçage des notifications d’état de livraison (DSN, Delivery Status Notification). Le générateur alloue le Message-ID:. L’ADMD des receveurs est le consommateur prévu du Message-ID:, bien que tout acteur le long du chemin de transfert puisse l’utiliser.

Le Message-ID: est unique au monde. Son format est similaire à celui d’une boîte aux lettres, avec les deux parties distinctes séparées par un signe (@). Normalement, le côté droit spécifie l’ADMD ou l’hôte qui alloue l’identifiant, et le côté gauche contient une chaîne qui est globalement opaque et sert à identifier de façon univoque le message dans le domaine référencé sur le côté droit. La durée de l’unicité de l’identifiant de message est indéfinie.

Quand un message est révisé d’une façon quelconque, la décision de lui allouer un nouveau Message-ID: exige une évaluation subjective pour déterminer si le contenu rédactionnel a été suffisamment changé pour constituer un nouveau message. La [RFC5322] déclare que "un identifiant de message s'applique à exactement une version d'un message particulier  ; les révisions ultérieures du message reçoivent chacune un nouvel identifiant de message". L’expérience suggère qu’une certaine souplesse est nécessaire. Un essai impossible est si les receveurs vont considérer le nouveau message comme équivalent à l’ancien. Pour la plupart des composants de messagerie Internet, il n’y a aucun moyen de prédire les préférences d’un receveur spécifique en cette matière. La création et l’échec de création d’un nouveau Message-ID: ont leurs inconvénients.

Voici quelques lignes directrices et exemples :
o	Si seule la forme d’un message est changée, comme le codage de caractères, c’est toujours le même message.
o	Si un message a des ajouts mineurs au contenu, comme une étiquette de liste de diffusion au début du champ d'en-tête RFC5322.Subject, ou des informations de liste de diffusion administrative ajoutées à la fin du texte de la partie de corps principale, c’est probablement le même message.
o	Si des virus sont supprimés d’un message, c’est probablement le même message.
o	Si des mots offensants sont supprimés d’un message, certains receveurs vont considérer que c’est le même message, mais d’autres non.
o	Si un message est traduit dans une autre langue, certains receveurs vont considérer que c’est le même message, mais d’autres non.
o	Si un message est inclus dans un résumé de messages, le résumé constitue un nouveau message.
o	Si un message est transmis par un receveur, ce qui est transmis est un nouveau message.
o	Si un message est "redirigé", comme en utilisant des champs d’en-tête IMF "Resent-*", certains receveurs vont considérer que c’est le même message, mais d’autres non.

L’absence de critères objectifs et précis pour générer à nouveau un Message-ID: et d’une forte protection associée à la chaîne signifie que la présence d’un identifiant peut permettre une assurance qui est marginalement meilleure qu’une heuristique, mais l’identifiant n’a certainement pas de valeur par lui-même pour une référence ou comparaison formelle stricte. Pour cette raison, l’identifiant de message n’est pas destiné à être utilisé pour une fonction ayant des implications de sécurité.
3.4.2	ENVID
Le ENVID (identifiant d’enveloppe) peut être utilisé pour les besoins du suivi de messages ([RFC3885], [RFC3464]) concernant un seul transfert d’envoi/livraison. Le ENVID marque un seul transit du MHS par un message spécifique. Donc, le ENVID est utilisé pour un envoi de message jusqu’à ce que le message soit livré. Un nouvel envoi du message, comme par un médiateur, ne réutilise pas cet ENVID, mais peut en utiliser un nouveau, même si le message pourrait légitimement conserver son identifiant de message original. Le format d’un ENVID est une forme libre. Bien que son créateur puisse choisir d’imposer une structure à la chaîne, aucune n’est imposée par les normes de l’Internet. Cela implique que la portée de la chaîne est définie par le nom de domaine de l’adresse de retour.

4.	Services et normes

L’architecture de la messagerie Internet comporte six types de fonctions de base, qui sont arrangées pour prendre en charge un service de mémorisation/transmission (store-and-forward). Comme montré à la Figure 5, chaque type peut avoir plusieurs instances, dont certaines représentent des rôles spécialisés. Cette section examine les activités et relations entre ces composants, et les normes de messagerie Internet qui s’appliquent à elles.

Message
Agent d’utilisateur de message (MUA)
MUA auteur (aMUA)
MUA receveur (rMUA)
Agent de soumission de message (MSA)
fonctions de MSA centrées sur l’auteur (aMSA)
fonctions de MSA centrées sur le MHS (hMSA)
Agent de transfert de message (MTA)
Agent de livraison de message (MDA)
fonctions de MDA centrées sur le receveur (rMDA)
fonctions de MDA centrées sur le MHS (hMDA)
Mémorisation de message (MS)
MS auteur (aMS)
MS receveur (rMS)

La figure ci-dessous montre les modules de fonction et les protocoles standard utilisés entre eux.

                     ++========++
                     ||        ||                             +-------+
          ...........++  aMUA  ||<............................+ Disp  |
          .          ||        ||                             +-------+
          .          ++=+==+===++                                 ^
          .  local,imap}|  |{smtp,soumission                      .
          .  +-----+    |  |                          +--------+  .
          .  | aMS |<---+  | ........................>| Retour |  .
          .  +-----+       | .                        +--------+  .
          .                | .    *****************       ^       .
          .          +-----V-.----*------------+  *       .       .
          .      MSA | +-------+  *   +------+ |  *       .       .
          .          | | aMSA  +-(S)->| hMSA | |  *       .       .
          .          | +-------+  *   +--+---+ |  *       .       .
          V          +------------*------+-----+  *       .       .
    //==========\\                *      V {smtp  *       .       .
    || MESSAGE  ||                *   +------+    *  //===+===\\  .
    ||----------||            MHS *   | MTA  |    *  ||  dsn  ||  .
    || ENVELOPPE||                *   +--+---+    *  \\=======//  .
    ||  smtp    ||                *      V {smtp  *     ^   ^     .
    || CONTENU  ||                *   +------+    *     .   . //==+==\\
    ||  imf     ||                *   | MTA  +....*......   . || mdn ||
    ||  mime    ||                *   +--+---+    *         . \\=====//
    \\==========//                * smtp}| {local *         .     ^
          .           MDA         *      | {lmtp  *         .     .
          .      +----------------+------V-----+  *         .     .
          .      | +----------+   *   +------+ |  *         .     .
          .      | |          |   *   |      | +..*..........     .
          .      | |   rMDA   |<-(D)--+ hMDA | |  *               .
          .      | |          |   *   |      | |<.*........       .
          .      | +-+------+-+   *   +------+ |  *       .       .
          .      +------+---------*------------+  *       .       .
          .  smtp,local}|         *****************       .       .
          .             V                                 .       .
          .          +-----+                         //===+===\\  .
          .          | rMS |                         || sieve ||  .
          .          +--+--+                         \\=======//  .
          .             |{imap,pop,local                  ^       .
          .             V                                 .       .
          .       ++==========++                          .       .
          .       ||          ||                          .       .
          .......>||   rMUA   ++...........................       .
                  ||          ++...................................
                  ++==========++

Légende : les lignes --- indiquent les transferts ou rôles principaux (éventuellement indirects)
                 les boîtes === indiquent les objets de données
                 les lignes ... indiquent la prise en charge des transferts ou rôles
                 les lignes *** indiquent le service agrégé

Figure 5 : Protocoles et services

4.1	Données de message
L’objet du système de traitement de message (MHS, Message Handling System) est d’échanger un objet de message IMF entre les participants [RFC5322]. Tous ses mécanismes sous-jacents servent à livrer ce message de son auteur à ses receveurs. Un message peut être explicitement étiqueté selon sa nature [RFC3458].

Un message comporte une enveloppe de traitement du transit et le contenu du message. L’enveloppe contient les informations utilisées par le MHS. Le contenu est divisé en un en-tête structuré et le corps. L’en-tête comporte des informations de trace du traitement de transit et des champs structurés qui font partie du contenu du message de l’auteur. Le corps peut être des lignes de texte non structuré ou une arborescence d’objets multimédia subordonnés, appelés des "parties de corps" ou, couramment, "des pièces jointes". [RFC2045], [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289].

De plus, la messagerie Internet a quelques conventions pour les données de contrôle spéciales, notamment :

Notification d’état de livraison (DSN, Delivery Status Notification) : c’est un message qui peut être généré par le MHS (MSA, MTA, ou MDA) et envoyé à l’adresse RFC5321.MailFrom. MDA et MTA sont montrés comme sources des DSN dans la Figure 5, et la destination est montrée comme des retours. Les DSN fournissent des informations sur le transit de message, comme des erreurs de transfert ou la réussite de livraison [RFC3461].

Notification de disposition de message (MDN, Message Disposition Notification) : c’est un message qui fournit des informations sur le traitement post-livraison, comme d’indiquer que le message a été affiché [RFC3798] ou la forme de contenu qui peut être prise en charge [RFC3297]. Il peut être généré par un rMUA et est envoyé aux adresses de Disposition-Notification-To. La boîte aux lettres pour cela est montrée par Disp dans la Figure 5.

Filtrage de message (SIEVE) : Sieve est un langage de scripts utilisé pout spécifier les conditions du traitement différentiel de la messagerie, normalement au moment de la livraison [RFC5228]. Les scripts peuvent être portés de diverses façons, comme une partie MIME dans un message. La Figure 5 montre un script Sieve allant du rMUA au MDA. Cependant, le filtrage peut être fait à de nombreux points différents le long cu chemin de transit, et un ou plusieurs d’entre eux pourraient être soumis aux directives Sieve, en particulier au sein d’un seul ADMD. La Figure 5 montre seulement une relation, pour une (relative) simplicité.

4.1.1	Enveloppe
La messagerie Internet a un cadre fragmenté pour les informations de traitement relatives au transit. Les informations qui sont utilisées directement par le MHS sont appelées "l’enveloppe". Elles dirigent les activités de traitement par le service de transfert et sont portées dans des commandes de service de transfert. C’est-à-dire, l’enveloppe existe dans le protocole de transfert SMTP [RFC5321].

Les informations de trace, comme RFC5322.Received, sont enregistrées dans l’en-tête de message et ne sont pas altérées ensuite [RFC5322].

4.1.2	Champs d'en-tête
Les champs d’en-tête sont des paires d’attributs nom/valeur qui couvrent une gamme extensible de paramètres de service de messagerie, un contenu d’utilisateur structuré, et des méta-informations de transaction d’utilisateur. L’ensemble des champs d’en-tête centraux est défini dans la [RFC5322]. Il est de pratique courante d’étendre cet ensemble pour différentes applications. Les procédures pour enregistrer les champs d’en-tête sont définies dans la [RFC3864]. Un ensemble extensible des enregistrements des champ d'en-tête existants est fourni dans la [RFC4021].

Un danger du placement d’informations supplémentaires dans les champs d’en-tête est que les passerelles les altèrent ou les suppriment souvent.

4.1.3	Corps
Le corps d’un message pourrait être des lignes de texte ASCII ou une composition hiérarchiquement structurée de parties de corps de pièces jointes multimédia utilisant MIME ([RFC2045], [RFC2046], [RFC2047], [RFC4288], et [RFC2049]).

4.1.4	Références d'identité dans un message
Le Tableau 1 fait la liste des identifiants de cœur présents dans un message durant le transit.

Couche	Champ	Établi par
Corps de message	En-tête MIME	auteur
Champs d’en-tête de message	From: 	auteur
	Sender: 	générateur
	Reply-To:	auteur
	To:, CC:, BCC:	auteur
	Message-ID:	générateur
	Received:	générateur, relais, receveur
	Return-Path:	MDA, de MailFrom
	Resent-*:	médiateur
	List-Id:	médiateur
	List-*:	médiateur
SMTP	HELO/EHLO	dernier relais client
	ENVID	générateur
	MailFrom 	générateur
	RcptTo	auteur
	ORCPT	générateur
IP	Adresse de source	dernier relais client

Légende : 
Couche  : partie de l’architecture de messagerie qui utilise l’identifiant.
Champ  : construction de protocole qui contient l’dentifiant.
Établi par  : rôle d’acteur responsable de la spécification de la valeur d’identifiant (et qui peut être différent de l’acteur qui effectue la fonction de remplissage pour la construction de protocole).

Tableau 1 : Identités en couches

Ces champs relatifs à l’adresse sont les plus courants :

RFC5322.From : établi par l’auteur. La liste des noms et adresses pour les auteurs du contenu du message est dans le champ From:.

RFC5322.Reply-To : établi par l’auteur. Si un receveur envoie un message de réponse qui autrement utiliserait les adresses du champ RFC5322.From dans le message d’origine, les adresses dans le champ RFC5322.Reply-To sont utilisées à la place. En d’autres termes, ce champ outrepasse le champ From: pour les réponses des receveurs.

RFC5322.Sender : établi par le générateur. Ce champ spécifie l’adresse du responsable de la soumission du message au service de transfert. Ce champ peut être omis si il contient la même adresse que RFC5322.From. Cependant, omettre ce champ ne signifie pas qu’aucun envoyeur n’est spécifié ; cela signifie que ce champ d'en-tête est virtuel et que l’adresse dans le champ From: est à utiliser.
La spécification des adresses de retour de notifications, qui sont contenues dans RFC5321.MailFrom, est faite par le RFC5322.Sender. Normalement, l’adresse de retour est la même que l’adresse de l’envoyeur. Cependant, certains scénarios d’usage exigent qu’elle soit différente.

RFC5322.To/.CC : établi par l’auteur. Ce champ spécifie les adresses de MUA receveurs. Cependant, certaines ou toutes les adresses dans ces champs pourraient n’être pas présentes dans les commandes RFC5321.RcptTo. La distinction entre To et CC est subjective. Généralement, un destinataire To est considéré comme principal et est supposé agir sur le message. Un destinataire CC reçoit normalement une copie par courtoisie.

RFC5322.BCC : établi par l’auteur. Une copie du message peut être envoyée à un destinataire dont la participation n’est pas à divulguer aux receveurs RFC5322.To ou RFC5322.CC et, généralement, pas aux autres receveurs BCC. Le champ d'en-tête BCC: indique un message en copie à ces receveurs. L’utilisation de ce champ est discutée dans la [RFC5322].

RFC5321.HELO/.EHLO : établi par le générateur, MSA, MTA. tout client SMTP, incluant le générateur, MSA, ou MTA -- peut spécifier son identité de domaine d’hébergement pour l’opération de commande SMTP HELO ou EHLO.

RFC3461.ENVID : établi par le générateur. Le MSA peut spécifier une chaîne opaque, à inclure dans une DSN, comme moyen d’assister les receveurs d’adresse de retour à identifier le message qui a produit une DSN ou un traçage de message.

RFC5321.MailFrom : établi par le générateur. Ce champ est une chaîne de bout en bout qui spécifie une adresse de messagerie pour recevoir des informations de contrôle de retour, comme les messages retournés. Le nom de ce champ est trompeur, parce qu’il n’est pas exigé de spécifier l’auteur ou l’acteur responsable de la soumission du message. L’acteur responsable de la soumission spécifie plutôt l’adresse RFC5321.MailFrom. Finalement, la base la plus simple pour décider quelle adresse a besoin d’être dans le champ RFC5321.MailFrom est de déterminer quelle adresse est à être informée de problèmes au niveau du transfert (et éventuellement de son succès).

RFC5321.RcptTo : établi par l’auteur, le MTA final, le MDA. Ce champ spécifie l’adresse de boîte aux lettres du MUA d’un receveur. La chaîne pourrait n’être pas visible dans l’en-tête de contenu de message. Par exemple, les champs d’en-tête d’adresse de destination IMF, comme RFC5322.To, pourraient spécifier une boîte aux lettres de liste de diffusion, tandis que l’adresse RFC5321.RcptTo spécifie un membre de cette liste.

RFC5321.ORCPT : établi par le générateur. C’est un paramètre facultatif de la commande RCPT, qui indique l’adresse originale à laquelle l’adresse RCPT TO courante correspond, après qu’une transposition a été effectuée durant le transit. Un ORCPT est la seule façon fiable de corréler une DSN provenant d’un transfert de message multi-receveurs avec les receveurs prévus.

RFC5321.Received : établi par le générateur, relais, médiateur, Dest. Ce champ contient des informations de trace, incluant l’hôte d’origine, les relais, les médiateurs, et les noms de domaine d’hôte MSA et/ou leurs adresses IP.

RFC5321.Return-Path : établi par le générateur. Le MDA enregistre l’adresse RFC5321.MailFrom dans le champ RFC5321.Return-Path.

RFC2919.List-Id : établi par le médiateur, l’auteur. Ce champ fournit un cadre de désignation de liste de diffusion unique au monde qui est indépendant des hôtes particuliers [RFC2919]. L’identifiant est sous la forme d’un nom de domaine ; cependant, la chaîne est généralement construite en combinant les deux parties d’une adresse de messagerie. Le résultat est rarement un vrai nom de domaine, mentionné dans le service de nom de domaine, bien qu’il puisse l’être.

RFC2369.List-* : établi par - médiateur, auteur. La [RFC2369] définit une collection de champs d'en-tête de message à utiliser par les listes de diffusion. En effet, ils fournissent des paramètres spécifiques de la liste pour des opérations d’utilisateur courantes de liste de diffusion. Les identifiants pour ces opérations sont pour la liste elle-même et d’utilisateur comme abonné [RFC2369].

RFC0791.SourceAddr :  établi par l’hôte de client SMTP envoyeur qui précède immédiatement le serveur SMTP receveur actuel. La [RFC0791] définit l’unité de base de transfert de données pour l’Internet : le datagramme IP. Il contient un champ Adresse de source qui spécifie l’adresse IP pour l’hôte (interface) d’où le datagramme a été envoyé. Cette information est réglée et fournie par la couche IP, ce qui la rend indépendante des mécanismes de niveau messagerie. À ce titre, elle est souvent prise comme étant d’autorité, bien qu’il soit possible de fournir de fausses adresses.

4.2	Services de niveau utilisateur
Les interactions au niveau utilisateur englobent les échanges de protocole, distincts de ceux qui se produisent à des couches inférieures de l’architecture MHS de messagerie Internet, qui sont à leur tour au dessus de la couche de transport Internet. À cause du motif du message, et beaucoup de son utilisation, l’interaction est entre des personnes, la nature et les détails de ces échanges de protocole sont souvent déterminés par les besoins de communication interpersonnelle et de groupe. Pour s’accommoder du comportement idiosyncrasique inhérent dans de telles communications, seules des lignes directrices subjectives, plutôt que des règles strictes, peuvent être offertes pour certains aspects du comportement de système. Les listes de diffusion fournissent des exemples particulièrement marquants.

4.2.1	Agent d'utilisateur de message (MUA)
Un agent d'utilisateur de message (MUA) agit au nom des acteurs utilisateurs et des applications d’utilisateurs. Il est leur représentant au sein du service de messagerie électronique.

Le MUA d’auteur (aMUA) crée un message et effectue la soumission initiale dans l’infrastructure de transfert via un agent de soumission de message (MSA, Mail Submission Agent). Il peut aussi effectuer toute création et archivage au moment de l’envoi dans sa mémorisation de message d’auteur (aMS). Une aMS de MUA peut organiser les messages de nombreuses façons différentes. Un modèle courant utilise des agrégations, appelées des "dossiers" ; dans IMAP ils sont appelés des "boîtes aux lettres". Ce modèle permet un dossier pour messages en cours de développement (projets) un dossier pour les messages en attente d’envoi (en file d’attente ou non envoyés) et un dossier pour les messages qui ont été bien envoyés pour le transfert (Envoyés). Mais aucun de ces dossiers n’est exigé. Par exemple, IMAP permet que les projets soient mémorisés dans tout dossier, de sorte qu’aucun dossier Brouillons n’a besoin d’être présent.

Les MUA receveurs (rMUA) fonctionnent au nom des receveurs pour traiter les messages reçus. Ce traitement inclut de générer des messages de contrôle de disposition au niveau utilisateur, d’afficher et de disposer du message reçu, et de clore ou étendre la boucle de communication d’utilisateur en initiant des réponses et en transmettant de nouveaux messages.

Note : bien que ce ne soit pas montré à la Figure 5, un MUA peut lui-même avoir une mise en œuvre distribuée, comme un module "fin" d’interface d’utilisateur sur un appareil contraint comme un téléphone portable, avec la plupart des fonctions de MUA agissant à distance sur un serveur à plus grandes capacités. Un exemple d’une telle architecture pourrait utiliser IMAP [RFC3501] pour la plupart des interactions entre un MUA client et un MUA serveur. Une approche pour de tels scénarios est définie dans la [RFC4550].

Un médiateur est une classe particulière de MUA. Il effectue le renvoi de message, comme discuté au paragraphe 2.1.

Un MUA peut être automatisé, au nom d’un utilisateur qui n’est pas présent au moment où le MUA est actif. Un exemple est un service d’envoi en vrac qui a un dispositif d’initiation temporisée. Ces services ne doivent pas être confondus avec un médiateur de liste de diffusion, car il n’y a pas de message entrant déclenchant l’activité du service automatisé.

Un MUA populaire et problématique est un répondeur automatique, comme ceux qui envoient des notices d’absence.  Ce comportement pourrait être confondu avec celui d’un médiateur, mais ce MUA génère un nouveau message. Les répondeurs automatiques peuvent perturber les utilisateurs de listes de diffusion sauf si ils suivent la [RFC3834].

Les champs d’identité suivants sont pertinents pour un MUA normal :
RFC5322.From
RFC5322.Reply-To
RFC5322.Sender
RFC5322.To, RFC5322.CC
RFC5322.BCC

4.2.2	Mémorisation de messages (MS)
Un MUA peut employer une mémorisation de message à long terme. La Figure 5 décrit une MS d’auteur (aMS) et une MS de receveur (rMS). Une MS peut être située sur un serveur distant ou sur la même machine que le MUA.

Une MS acquiert les messages d’un MDA soit de façon proactive par un mécanisme local, ou même par un mécanisme normalisé comme SMTP (!), soit de façon réactive en utilisant POP ou IMAP. Le MUA accède à la MS par un mécanisme local ou en utilisant POP ou IMAP. Utiliser POP pour l’accès aux messages individuels, plutôt qu’un transfert en vrac, est relativement rare et inefficace.

4.3	Services de niveau MHS
4.3.1	Agent de soumission de messagerie (MSA)
Un agent de soumission de messagerie (MSA, Mail Submission Agent) accepte le message soumis par le aMUA et applique les politiques de l’ADMD hébergeur et les exigences des normes de l’Internet. Un MSA représente une dichotomie fonctionnelle inhabituelle. Il représente les intérêts de l’auteur (aMUA) durant l’envoi du message, pour faciliter la réussite de l’envoi ; il représente aussi les intérêts du MHS. Dans l’architecture, ces responsabilités sont modélisées, comme le montre la Figure 5, en divisant le MSA en deux sous composants, aMSA et hMSA, respectivement. Le transfert de responsabilité pour un seul message, de l’environnement d’un auteur à celui du MHS, est appelé "envoi". Dans la Figure 5, il est marqué comme la transition (S), au sein du MSA.

Le hMSA prend la responsabilité du transit pour un message qui se conforme aux normes pertinentes de l’Internet et aux politiques du site local. Il rejette les messages qui ne sont pas conformes. Le MSA effectue la préparation finale du message pour la soumission et effectue le transfert de responsabilité au MHS, via le hMSA. La quantité de préparation dépend des mises en œuvre locales. Des exemples des tâches de aMSA incluent d’ajouter des champs d’en-tête, comme Date: et Message-ID:, et de modifier des portions du message des notations locales en celles des normes de l’Internet, comme d’étendre une adresse à sa représentation IMF formelle.

Historiquement, les envois de message de MUA/MSA fondés sur les normes ont utilisé SMTP [RFC5321]. La norme actuellement préférée est SUBMISSION [RFC4409]. Bien que SUBMISSION dérive de SMTP, il utilise un accès TCP séparé et impose de exigences distinctes, comme l’autorisation d’accès.

Ces identités sont pertinentes pour le MSA :
RFC5321.HELO/.EHLO
RFC3461.ENVID
RFC5321.MailFrom
RFC5321.RcptTo
RFC5321.Received
RFC0791.SourceAddr

4.3.2	Agent de transfert de message (MTA)
Un agent de transfert de message (MTA, Message Transfer Agent ) relaye la messagerie pour un "bond" de niveau application. Il est comme un commutateur de paquets ou un routeur IP en ce que sa tâche est de faire des estimations d’acheminement et de déplacer le message au plus près des receveurs. Bien sûr, les objets de messagerie sont normalement bien plus grands que la charge utile d’un paquet ou datagramme, et les latences de bout en bout sont normalement bien plus élevées. Le relais est effectué par une séquence de MTA jusqu’à ce que le message atteigne un MDA de destination. Donc, un MTA met en œuvre les deux fonctions de MTA client et MTA serveur ; il ne change pas les adresses dans l’enveloppe ni ne reformule la rédaction du contenu. Un changement dans la forme des données, comme en codage de transfert de contenu MIME, est dans les attributions d’un MTA, mais la suppression ou le remplacement du contenu du corps ne l’est pas. Un MTA ajoute aussi des informations de trace [RFC2505].

Note : dans un ADMD de destination, des modules de relais de messagerie peuvent faire divers changements au message, avant sa livraison. Dans ce cas, ces modules agissent comme des passerelles, plutôt que comme des MTA.

La messagerie Internet utilise SMTP ([RFC5321], [RFC2821], [RFC0821]) principalement pour effectuer des transferts en point à point entre des MTA homologues. Les autres mécanismes de transfert incluent SMTP par lots [RFC2442] et le relais SMTP de messagerie à la demande (ODMR) [RFC2645].  Comme avec la plupart des mécanismes de couche réseau, la messagerie Internet SMTP prend en charge un niveau de fiabilité de base, fournissant une retransmission après un échec temporaire de transfert. À la différence des commutateurs de paquet typiques (et des services de messagerie instantanée) les MTA de messagerie Internet sont supposés mémoriser les messages d’une manière qui permette la récupération à travers les interruptions de service, comme une fermeture du système hôte.  Le degré d’une telle robustesse et persistance d’un MTA peut varier. La spécification SMTP de base donne un cadre pour les codes de réponse du protocole. Une amélioration extensible de ce cadre est définie dans la [RFC5248].

Bien qu’assez basique, le mécanisme d'acheminement dominant pour la messagerie Internet est l’enregistrement DNS MX [RFC1035], qui spécifie un MTA à travers lequel le domaine interrogé peut être atteint. Ce mécanisme suppose une colonne vertébrale publique, ou au moins commune qui permette à tout MTA rattaché de se connecter à tout autre.

Les MTA peuvent effectuer tous ces rôles bien établis :

MTA frontière : MTA qui fait partie d’un ADMD et interagit avec les MTA dans d’autres ADMD. Ceci est aussi appelé un MTA bordure. Il peut y avoir différents MTA frontière, selon la direction du flux de messages.

MTA sortant : MTA qui relaye les messages à d’autres ADMD.

MTA entrant : MTA qui reçoit des messages SMTP entrants de MTA relais dans d’autres ADMD, par exemple, un MTA fonctionnant sur l’hôte mentionné comme cible d’un enregistrement MX.

MTA final : MTA qui transfère un message au MDA.

Les identités suivantes sont pertinentes pour le MTA :
RFC5321.HELO/.EHLO
RFC3461.ENVID
RFC5321.MailFrom
RFC5321.RcptTo
RFC5322.Received:  établi par le serveur relais
RFC0791.SourceAddr

4.3.3	Agent de livraison de messagerie (MDA)
Un transfert de responsabilité du MHS à un environnement de receveur (boîte aux lettres) est appélé une "livraison". Dans l’architecture, comme décrite dans la Figure 5, la livraison a lieu dans un agent de livraison de message (MDA, Mail Delivery Agent) et est montrée comme la transition (D) du composant MDA en mode MHS (hMDA) au composant MDA côté receveur (rMDA).

Un MDA peut fournir des fonctions distinctives, fondées sur l’adresse, rendues possibles par ses informations détaillées sur les propriétés de l’adresse de destination. Ces informations pourraient aussi être présentes ailleurs dans l’ADMD des receveurs, comme un relais de bordure organisationnelle (frontière). Cependant, elles sont exigées du MDA, ne serait ce que parce que il est exigé du MDA qu’il sache où livrer le message.

Comme un MSA, un MDA a deux rôles, comme décrit dans la Figure 5. Le transfert formel de responsabilité, appelé "livraison", est effectué entre les deux composants qui tiennent ces rôles et est montré comme "(D)" dans la Figure 5. La portion MHS (hMDA) fonctionne principalement comme un moteur de serveur SMTP. Un rôle commun supplémentaire est de rediriger le message sur une adresse de remplacement, comme spécifié par les préférences des receveurs de destination. La tâche de la portion receveur du MDA (rMDA) est d’effectuer toutes les actions de livraison que le receveur spécifie.

Le transfert dans le MDA est réalisé par un mécanisme normal de transfert de MTA. Le transfert d’un MDA à une MS utilise un protocole d’accès, comme POP ou IMAP.

Note : le terme de "livraison" peut se référer à la fonction formelle de MHS spécifiée ici ou la première fois qu’un message est affiché à un receveur. Un essai pratique simple pour savoir si la définition fondée sur le MHS s’applique est si une DSN peut être générée.

Les identités suivantes sont pertinentes pour le MDA :
RFC5321.Return-Path : établi par l’auteur d'origine ou médiateur d'origine. Le MDA enregistre l’adresse RFC5321.MailFrom dans le champ RFC5321.Return-Path.
RFC5322.Received : établi par le serveur MDA. Le MDA peut enregistrer un champ d'en-tête Received: pour indiquer des informations de trace, y compris les noms de domaine et/ou adresses IP de l’hôte de source et de l’hôte receveur.

4.4	Modes de transition
Du site d’origine au point de livraison, la messagerie Internet suit généralement un modèle de "poussée". C’est-à-dire que l’acteur qui détient le message initie le transfert au prochain site, normalement avec SMTP [RFC5321] ou le protocole de transfert local de messagerie (LMTP, Local Mail Transfer Protocol) [RFC2033]. Avec un modèle de "tirage", l’acteur qui détient le message attend que l’acteur du prochain site initie une demande de transfert. Les mécanismes normalisés pour le transfert MHS fondé sur le tirage sont ETRN [RFC1985] et ODMR [RFC2645].

Après la livraison, le MUA (ou MS) du receveur peut obtenir l’accès en ayant le message poussé jusqu’à lui ou en ayant le receveur d’accès qui pousse le message, comme en utilisant POP [RFC1939] et IMAP [RFC3501].

4.5	Mise en œuvre et fonctionnement
Une discussion de toute architecture de système intéressante achoppe souvent quand l’architecture et la mise en œuvre sont confondues. Une architecture définit les fonctions conceptuelles d’un service, divisées en modules conceptuels discrets. Une mise en œuvre de cette architecture peut combiner ou séparer les composants architecturaux, comme nécessaire pour un environnement de fonctionnement particulier. Par exemple, un système logiciel qui effectue principalement du relais de message est un MTA, bien qu’il puisse aussi inclure une fonction de MDA. Le même système de MTA pourrait être capable de faire l’interface avec des services de messagerie non Internet et donc fonctionner à la fois comme MTA et comme passerelle.

De même, les modules mis en œuvre pourraient être configurés à former des élaborations de l’architecture. Un exemple intéressant est une MS distribuée. Une portion pourrait être un serveur distant et une autre être locale au MUA. Comme expliqué dans la [RFC1733], il y a trois relations opérationnelles parmi de telles MS :

En ligne : la MS est distante, et les messages sont accessibles seulement quand le MUA est rattaché à la MS de sorte que le MUA va aller chercher tout ou partie d’un message d’une session à la suivante.

Hors ligne : la MS est locale chez l’utilisateur, et les messages sont complètement déplacés de toute mémorisation distante , plutôt que d’y être (aussi) conservés.

Déconnecté : une rMS et une uMS sont gardées synchronisées, pour tout ou partie de leur contenu, pendant qu’elles sont connectées. Quand elles sont déconnectées, le message peut arriver à la rMS et l’utilisateur peut faire des changements à l’uMS. Les deux mémorisations sont re-synchronisées quand elles sont reconnectées.

5.	Médiateurs

Le transfert de message de base de l’auteur aux receveurs est accompli en utilisant une infrastructure de communication de mémorisation et transmission asynchrone dans une séquence de transmissions indépendantes à travers un certain nombre de MTA. Une tâche très différente est une séquence d’envois et de livraisons à travers des médiateurs. Un médiateur transmet un message à travers un processus de renvoi. Le médiateur partage certaines fonctions avec le relais par MTA de base, mais a une plus grande souplesse dans l’adressage et le contenu que ce qui est disponible aux MTA.

L’ensemble d’informations de message qui sont couramment établies par tous les types de médiateurs est le suivant :
RFC5321.HELO/.EHLO : établi par le médiateur d'origine
RFC3461.ENVID : établi par le médiateur d'origine
RFC5321.RcptTo : établi par le médiateur auteur
RFC5321.Received : établi par le médiateur de destination

Le médiateur peut enregistrer les informations reçues pour indiquer la livraison à l’adresse d’origine et la soumission à l’adresse du substitut. La trace des champs d’en-tête Received: peut inclure chaque composant du message original, à travers les relais, jusqu’à la livraison finale.

L’aspect d’un médiateur qui le distingue de tout autre MUA qui crée un message est qu’un médiateur préserve l’intégrité et le ton du message original, incluant les aspects essentiels de ses informations d’origine. Le médiateur pourrait aussi ajouter des commentaires.

Des exemples de messages de MUA qu’un médiateur ne crée pas incluent :

Un nouveau message qui transmet un message existant : Bien que cette action fournisse un gabarit de base pour une classe de médiateurs, son occurrence normale n’est pas, par elle-même, un exemple d’un médiateur. Le nouveau message est vu comme étant de l’acteur qui fait la transmission plutôt que de l’auteur d'origine. Un nouveau message encapsule le message original et est vu comme venant du nouveau générateur. Ce médiateur d'origine pourrait ajouter des commentaires et peut modifier le contenu du message original. Parce que le message transmis est un composant du message envoyé par le nouveau générateur, le nouveau message crée un nouveau dialogue. Cependant, le receveur final voit quand même le message contenu comme venant de l’auteur d'origine.

Réponse : quand un receveur répond à l’auteur d’un message, le nouveau message n’est normalement pas vu comme une transmission de l’original. Il se concentre sur le nouveau contenu, bien qu’il pourrait contenir tout ou partie du matériel provenant du message original. Le matériel antérieur est simplement contextuel et secondaire. Cela inclut des réponses  automatiques, comme des notices d’absence pour vacances, comme discuté dans au paragraphe 4.2.1.

Annotation : l’intégrité du message original est généralement préservée, mais un ou plusieurs commentaires sur le message sont ajoutés d’une manière qui distingue les commentaires du texte original. L’objet principal du nouveau message est de fournir un commentaire d’un nouvel auteur, similaire à une réponse.

Le reste de cette section décrit des exemples courants de médiateurs.

5.1	Alias
Une fonction d’un MDA est de déterminer la localisation interne d’une boîte aux lettres afin d’effectuer la livraison. Un alias est une simple facilité de ré-adressage qui fournit une ou plusieurs nouvelles adresses de messagerie Internet, plutôt qu’une seule, interne ; le message continue à travers le service de transfert, pour être livré à une ou plusieurs adresses de remplacement. Bien que normalement mise en œuvre au titre d’un MDA, cette facilité est une fonction des receveurs. Elle re-soumet le message, bien que toutes les informations de traitement sauf l’adresse du receveur d’enveloppe (rfc5321.RcptTo) soient conservées. En particulier, l’adresse de retour (rfc5321.MailFrom) est inchangée.

Ce qui est particulier à ce mécanisme de transmission est qu’il ressemble étroitement à un relais normal de MTA de mémorisation et transmission. Sa seule différence significative est qu’il change la valeur de RFC5321.RcptTo. Parce que ce changement est si petit, l’utilisation d’un alias peut être vue comme une partie de l’activité de relais de messagerie de niveau inférieur. Cependant, ce petit changement a un grand impact sémantique : les receveurs désignés sont choisis comme nouveaux receveurs.

Note : quand la liste de remplacement inclut plus d’une adresse, l’alias va probablement avoir des problèmes de livraison accrus. Tout rapport de problème va à l’auteur d'origine, pas à l’administrateur de l’entrée d’alias. Cela rend plus difficile la résolution de problème, parce que l’auteur d'origine n’a pas connaissance du mécanisme d’alias.

En incluant l’ensemble central d’informations de message mentionné au début de cette section, l’alias change normalement :
RFC5322.To/.CC/.BCC : établi par l’auteur. Ces champs conservent leurs adresses originales.
RFC5321.MailFrom : établi par l’ auteur. L’avantage de conserver la valeur originale de MailFrom est d’assurer qu’un acteur en relation avec l’ADMD d’origine sait qu’il y a eu un problème de livraison. Par ailleurs, la responsabilité du traitement des problèmes, quand on transite de la boîte aux lettres réceptrice originale à la boîte aux lettre d’alias incombe normalement aux receveurs originaux, parce que le mécanisme d’alias est strictement sous le contrôle de ces receveurs. Conserver l’adresse originale du MailFrom empêche cela.

5.2	Renvoyeur
Aussi appelé le redirecteur, les actions du renvoyeur diffèrent de la transmission parce que le médiateur "découpe" les informations d’adressage d’un message pour connecter l’auteur du message original avec les receveurs du nouveau message. Cette connexion leur permet d’avoir un échange direct, en utilisant leur fonction normale de réponse de MUA, tout en enregistrant aussi toutes les informations de référence sur les receveurs qui ont servi de médiateur. Donc,le nouveau receveur voit le message comme venant de l’auteur d'origine, même si le médiateur ajoute un commentaire.

En incluant l’ensemble d’informations de message mentionnées au début de cette section, ces identités sont pertinentes pour un message renvoyé :
RFC5322.From : établi par l’auteur d'origine. Les noms et adresses pour l’auteur d'origine du contenu du message sont conservés. La portion de forme libre (nom d’affichage) de l’adresse pourrait être modifiée pour fournir une référence informelle au renvoyeur.
RFC5322.Reply-To : établi par l’auteur d'origine. Si ce champ est présent dans le message original, il est conservé dans le message renvoyé.
RFC5322.Sender : établi par le générateur ou médiateur d'origine de l’auteur.
RFC5322.To/.CC/.BCC : établi par l’auteur d'origine. Ces champs spécifient les receveurs du message original.
RFC5322.Resent-From : établi par le médiateur de l’auteur. Cette adresse est celle du receveur original qui redirige le message. Autrement, les mêmes règles s’appliquent au champ Resent-From: comme à un champ original RFC5322.From.
RFC5322.Resent-Sender : établi par le médiateur d'origine. L’adresse de l’acteur responsable de la re-soumission du message. Comme avec RFC5322.Sender, ce champ peut être omis quand il contient la même adresse que RFC5322.Resent-From.
RFC5322.Resent-To/-CC/-BCC : établi par le médiateur auteur. Adresses des nouveaux receveurs qui sont maintenant capables de répondre à l’auteur d'origine.
RFC5321.MailFrom : établi par le médiateur d'origine. L’acteur responsable de la re-soumission (RFC5322.Resent-Sender) est aussi responsable de spécifier la nouvelle adresse MailFrom.

5.3	Listes de diffusion
Une liste de diffusion reçoit les messages comme une adresse explicite et les renvoie ensuite à une liste d’abonnés. La liste de diffusion effectue une tâche qui peut être vue comme une élaboration du renvoyeur. En plus d’envoyer le nouveau message à un nombre potentiellement grand de nouveaux receveurs, la liste de diffusion peut modifier le contenu, par exemple, en supprimant des pièces jointes, de convertir le format, et d’ajouter des commentaires spécifiques de la liste. Les listes de diffusion archivent aussi les messages postés par les auteurs. Le message conserve quand même les caractéristiques qui font qu’il est de l’auteur d'origine.

En incluant l’ensemble d’informations de message mentionnées au début de cette section, ces identités sont pertinentes pour un processeur de liste de diffusion quand il soumet un message :
RFC2919.List-Id : établi par le médiateur auteur.
RFC2369.List-* : établi par le médiateur auteur.
RFC5322.From : établi par l’auteur d'origine. Les noms et adresses de messagerie pour l’auteur d'origine du contenu du message sont conservés.
RFC5322.Reply-To : établi par le médiateur ou auteur d'origine. Bien que problématique, il est courant qu’une liste de diffusion alloue sa propre adresse au champ d'en-tête Reply-To: des messages qu’elle envoie. Cette allocation est destinée à assurer que les réponses vont à tous les membres de la liste, plutôt que seulement à l’auteur d'origine. Comme un utilisateur acteur, une liste de diffusion est l’auteur du nouveau message et peut légitimement régler la valeur de Reply-To:. Comme un médiateur qui tente de représenter le message au nom de son auteur d'origine, créer ou modifier un champ Reply-To: peut être vu comme violant l’intention de l’auteur. Quand le Reply-To est modifié de cette façon, une réponse qui est destinée seulement à l’auteur d'origine va plutôt aller à la liste entière. Quand la liste de diffusion ne règle pas le champ, une réponse destinée à la liste entière peut à la place aller seulement à l’auteur d'origine. Au mieux, le choix est une affaire de culture de groupe pour la liste concernée.
RFC5322.Sender : établi par l’auteur d'origine ou le médiateur d'origine. Ce champ spécifie généralement l’adresse de l’acteur responsable des opérations de la liste de diffusion. Les listes de diffusion qui fonctionnent de manière similaire à un simple MTA relais préservent autant des informations de traitement originales que possible, incluant le champ original RFC5322.Sender. (Noter que ce mode de fonctionnement cause un comportement de la liste de diffusion un peu comme un alias, avec une différence possible dans le nombre de nouveaux destinataires.)
RFC5322.To/.CC : établi par l’auteur d'origine. Ces champs contiennent généralement la liste originale des adresses des receveurs.
RFC5321.MailFrom : établi par le médiateur d'origine. Parce qu’une liste de diffusion peut de toutes façons modifier le contenu d’un message, elle est responsable de ce contenu ; c’est-à-dire, elle est un auteur. À ce titre, l’adresse de retour est spécifiée par la liste de diffusion. Bien qu’il soit plausible que la liste de diffusion réutilise l’adresse de retour employée par le générateur original, les notifications envoyées à cette adresse après le traitement d’un message par une liste de diffusion pourraient être problématiques.

5.4	Passerelles
Une passerelle effectue l’acheminement de base et le travail de transfert du relais de message, mais il lui est aussi permis de modifier le contenu, la structure, l’adresse, ou les attributs autant que nécessaire pour envoyer le message dans un environnement de messagerie qui opère avec des normes différentes ou des politiques potentiellement incompatibles. Quand une passerelle connecte deux services de messagerie différents, son rôle est facile à identifier et comprendre. Quand elle connecte des environnements qui suivent des normes techniques similaires, mais de politiques administratives significativement différentes, il est facile de voir une passerelle comme un simple MTA.

La distinction critique entre un MTA et une passerelle est qu’une passerelle peut faire des changements substantiels à un message pour transposer entre les normes. Dans virtuellement tous les cas, cette transposition résulte en un certain degré de perte sémantique. Le défi d’une conception de passerelle est de minimiser cette perte. Les passerelles normalisées pour la messagerie Internet sont la télécopie [RFC4143], la messagerie vocale [RFC3801], et le service de messagerie multimédia (MMS, Multimedia Messaging Service) [RFC4356].

Une passerelle peut régler tout champ d’identité disponible à un MUA. En incluant l’ensemble central d’informations de message mentionnées au début de cette section, ces identités sont normalement pertinentes pour les passerelles :
RFC5322.From : établi par l’auteur d'origine. Les noms et adresses pour l’auteur d'origine du contenu du message sont conservés. Comme pour toutes les informations d’adressage originales dans le message, la passerelle peut traduire les adresses comme nécessaire pour qu’elles continuent d’être utiles dans l’environnement cible.
RFC5322.Reply-To : établi par l’auteur d'origine. Il est meilleur pour une passerelle de conserver ces informations, si elles sont présentes. La capacité d’effectuer une réponse réussie par un receveur est un test typique de fonction de passerelle.
RFC5322.Sender : établi par l’auteur d'origine ou médiateur d'origine. Ce champ peut conserver la valeur originale ou peut être réglé à une nouvelle adresse.
RFC5322.To/.CC/.BCC : établi par le receveur original. Ces champs conservent généralement leurs adresses originales.
RFC5321.MailFrom: établi par l’auteur d'origine ou médiateur d'origine. L’acteur responsable du traitement du message peut spécifier une nouvelle adresse pour recevoir les notices de traitement.

5.5	Filtre de frontière
Pour appliquer les frontières de sécurité, les organisations peuvent soumettre les messages à l’analyse de leur conformité à des politiques de sûreté. Un exemple est la détection de contenu classé comme pourriel ou virus. Un filtre peut altérer le contenu pour le rendre sûr, comme de supprimer du contenu réputé inacceptable. Normalement, ces actions ajoutent au message du contenu qui enregistre les actions.

6.	Considérations
6.1	Considérations sur la sécurité
Le présent document décrit l’architecture existante de la messagerie Internet. Il n’introduit pas de nouvelles capacités. Les considérations sur la sécurité de cette architecture déployée sont documentées extensivement dans les spécifications techniques référencées par ce document. Ces spécifications couvrent les sujets de sécurité classiques, comme l’authentification et la confidentialité. Par exemple, les protocoles de transfert de message peuvent utiliser les mécanismes normalisés pour fonctionner sur des liaisons authentifiées et/ou chiffrées, et le contenu de message a des normes de protection similaires disponibles. Des exemples de ces mécanismes incluent SMTP-TLS [RFC3207], SMTP-Auth [RFC4954], OpenPGP [RFC4880], et S/MIME [RFC3851].

Le cœur de l’architecture de la messagerie Internet n’impose aucune exigence ou fonctions de sécurité aux composants de bout en bout ou bond par bond. Par exemple, il n’exige pas l’authentification des participants et ne tente pas d’empêcher la divulgation des données.

Des attributs de message particuliers pourraient exposer à des considérations de sécurité spécifiques. Par exemple, le dispositif de copie carbone aveugle de l’architecture suscite des problèmes de divulgation, comme discuté au paragraphe  7.2 de la [RFC5321] et à la Section 5 de la [RFC5322]. Le transport de contenu de texte ou non dans cette architecture a des implications de sécurité qui sont discutées dans les [RFC5322], [RFC2045], [RFC2046], et [RFC4288] ; aussi, des considérations de sécurité sont présentes pour certains types de supports enregistrés par l’IANA.

Les agents qui répondent automatiquement aux messages soulèvent des considérations de sécurité significatives, comme discuté dans la [RFC3834]. Les comportements de passerelle affectent les services de sécurité de bout en bout, comme discuté dans la [RFC2480]. Les considérations de sécurité pour les filtres de frontières sont discutées dans la [RFC5228].

Voir le paragraphe 7.1 de [RFC5321] pour une discussion du sujet de la validation de l’origine. Comme mentionné au paragraphe 4.1.4, il est de pratique courante pour les composants de cette architecture d’utiliser la RFC0791.SourceAddr pour prendre des décisions de politique [RFC2505], bien que l’adresse puisse être "usurpée". Il est possible de l’utiliser sans autorisation. SMTP et l’authentification de soumission ([RFC4409], [RFC4954]) fournissent des solutions de remplacement plus sûres.

La discussion des frontières de confiance, des ADMD, des acteurs, des rôles, et des responsabilités dans ce document souligne la pertinence et la potentielle complexité des facteurs de sécurité pour le fonctionnement d’un service de messagerie Internet. La conception centrale de la messagerie Internet encourageant un échange ouvert et insouciant de messages s’est heurtée à des défis d’échelle, car la population des participants à la messagerie électronique s’est accrue pour inclure des gens qui ont des pratiques problématiques. Par exemple, les pourriels, comme définis dans la [RFC2505], sont un sous produit de cette architecture. Un certain nombre de documents sur la voie de la normalisation ou des bonnes pratiques actuelles (BCP) sur le sujet ont été produits (voir les [RFC2505], [RFC5068], et [RFC5235]).

6.2	Internationalisation
Le cœur des normes de la messagerie électronique Internet est fondé sur l’utilisation de l’US-ASCII -- c’est-à-dire, SMTP [RFC5321] et IMF [RFC5322], ainsi que leurs prédécesseurs. Elles décrivent le transport et la composition des messages comme composés strictement de caractères de 7 bits codés en US-ASCII. Les normes ont été améliorées de façon incrémentaire pour permettre des caractères en dehors de cet ensemble limité, tout en conservant des mécanismes pour la rétro compatibilité. Précisément :

o	Les spécifications de MIME ([RFC2045], [RFC2046], [RFC2047], [RFC2049]) permettent l’utilisation de jeux de caractères codés et de schémas de codage de caractères (des "charset" dans la terminologie MIME) autres que US-ASCII. la [RFC2046] de MIME permet que le contenu textuel d’un message ait une étiquette qui spécifie le jeu de caractères utilisé dans ce contenu. La [RFC2047] de MIME permet également que le contenu textuel de certains champs d’en-tête dans un message soit étiqueté de façon similaire. Cependant, comme les messages pourraient être transportés sur des mises en œuvre de SMTP seulement capables de transporter des caractères codés sur 7 bits, la [RFC2045] de MIME permet aussi le "codage de transfert de contenu" afin que les caractères d’autres jeux de caractères puissent être re-codés comme un sur-ensemble de l’US-ASCII.

o	La [RFC2045] de MIME permet que le contenu textuel d’un message soit dans un schéma de codage de caractères sur 8  bits. Afin de les transporter sans les re-coder, la spécification SMTP prend en charge une option [RFC1652] qui permet le transport d’un tel contenu textuel. Cependant, l’option de la [RFC1652] ne vise pas l’utilisation de contenu de 8 bits dans les champs d'en-tête de message, et donc le codage de la [RFC2047] est toujours exigé pour eux.

o	Une série de protocoles expérimentaux sur l’internationalisation d’adresse de messagerie électronique (EAI, Email Address Internationalization) a été publiée pour étendre SMTP et IMF et permettre que des caractères codés sur 8 bits apparaissent dans les adresses et autres informations dans les champs d’en-tête des messages. La [RFC5335] spécifie le format de ces champs d'en-tête de message (qui codent les caractères en UTF-8), et la [RFC5336] spécifie une option SMTP pour le transport de ces messages.

o	Les [RFC2045] et [RFC2046] de MIMIE permettent le transport de vrai matériel multimédia ; ce matériel permet l’internationalisation parce qu’il n’est pas restreint à un langage particulier.

o	Les formats pour les notifications d’état de livraison (DSN, Delivery Status Notification) [RFC3462], [RFC3463], [RFC3464]) et les notifications de disposition de message (MDN, Message Disposition Notification) [RFC3798] incluent une représentation structurée et une représentation non structurée de la notification. Dans le cas où la représentation non structurée est dans le mauvais langage ou ne convient pas par ailleurs, cela permet à un MUA de construire sa propre représentation avec les adaptations locales appropriées des notifications à afficher à l’utilisateur.

o	POP et IMAP n’ont pas de difficultés avec le traitement des messages MIME, incluant ceux qui contiennent du 8bit, et ne sont donc pas une source de problèmes d’internationalisation.

Donc, l’utilisation de UTF-8 est pleinement établie dans la messagerie Internet existante. Cependant, la prise en charge des formes de codage établies depuis longtemps est conservée et est toujours utilisée.

7.	Références
7.1	Références normatives

[RFC0791]	J. Postel, éditeur, "Protocole Internet - Spécification du protocole du programme Internet", STD 5, septembre 1981.

[RFC1034]	P. Mockapetris, "Noms de domaines - Concepts et facilités", STD 13, novembre 1987. (MàJ par RFC1101, 1183, 1348, 1876, 1982, 2065, 2181, 2308, 2535, 4033, 4034, 4035, 4343, 4035, 4592, 5936, 8020, 8482, 8767)

[RFC1035]	P. Mockapetris, "Noms de domaines – Mise en œuvre et spécification", STD 13, novembre 1987. (MàJ par RFC1101, 1183, 1348, 1876, 1982, 1995, 1996, 2065, 2136, 2181, 2137, 2308, 2535, 2673, 2845, 3425, 3658, 4033, 4034, 4035, 4343, 5936, 5966, 6604, 7766, 8482, 8767)

[RFC1939]	J. Myers, M. Rose, "Protocole Post Office - version 3", mai 1996. (MàJ par RFC1957, 2449, 8314) (STD0053)

[RFC2045]	N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet", novembre 1996. (D. S., MàJ par 2184, 2231, 5335.)

[RFC2046]	N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 2 : Types de support", novembre 1996. (D. S., MàJ par 2646, 3798, 5147, 6657, 8098)

[RFC2047]	K. Moore, "MIME (Extensions de messagerie Internet multi-objets) Partie trois : extensions d'en-tête de message pour texte non ASCII", novembre 1996. (MàJ par RFC2184, RFC2231) (D.S.)

[RFC2049]	N. Freed, N. Borenstein, "Extensions multi-objets de la messagerie Internet (MIME) Partie cinq : critères de conformité et exemples", novembre 1996. (Remplace RFC1521, RFC1522, RFC1590) (D.S.)

[RFC2181]	R. Elz et R. Bush, "Clarifications pour la spécification du DNS", juillet 1997. (P.S., MàJ par RFC4035, RFC2535, RFC4343, RFC4033, RFC4034, RFC5452, RFC8767)

[RFC2369]	G. Neufeld, J. Baer, "Utilisation des URL comme méta syntaxe pour les commandes centrales de liste de messagerie et leur transport à travers les champs d'en-tête de message", juillet 1998. (P.S.)

[RFC2645]	R. Gellens, "Relais de messagerie à la demande (ODMR) pour SMTP avec adresses IP dynamiques", août 1999. (P.S.)

[RFC2919]	R. Chandhok, G. Wenger, "List-Id : un champ structuré et un espace de nom pour l'identification de listes de diffusion", mars  2001. (P.S.)

[RFC3192]	C. Allocchio, "Format minimal d'adresse FAX dans la messagerie Internet", octobre 2001. (D.S.)

[RFC3297]	G. Klyne, R. Iwazaki, D. Crocker, "Négociation de contenu pour les services de messagerie fondés sur la messagerie électronique", juillet 2002. (P.S.)

[RFC3458]	E. Burger et autres, "Contexte de message pour la messagerie Internet", janvier 2003. (MàJ par RFC3938) (P.S.)

[RFC3461]	K. Moore, "Extension de service du protocole simple de transfert de messagerie (SMTP) pour les notifications d'état de livraison (DSN)", janvier 2003. (MàJ par RFC3798, RFC3885, RFC5337, RFC6533, RFC8098) (D.S.)

[RFC3462]	G. Vaudreuil, "Type de contenu Multipart/Report pour les rapports des messages administratifs du système de messagerie", janvier 2003. (Remplacée par RFC6522, STD 73)

[RFC3463]	G. Vaudreuil, "Codes d'état améliorés du système de messagerie", janvier 2003. (MàJ par RFC3886, RFC4468, RFC4865, RFC4954, RFC5248) (D.S.)

[RFC3501]	M. Crispin, "Protocole d'accès au message Internet - version 4rev1", mars 2003. (P.S. ; MàJ par RFC4466, 4469, 4551, 5032, 5182, 7817, 8314, 8437, 8474 ; remplacée par la 9051

[RFC3798]	T. Hansen et G. Vaudreuil, éd., "Notification de disposition de message", mai 2004. (MàJ par RFC5337, RFC6533) (D.S.; Rendue obsolète par RFC8098)

[RFC3834]	K. Moore, "Recommandations sur les réponses automatiques à la messagerie électronique", août 2004. (MàJ par RFC5436) (P.S.)

[RFC3864]	G. Klyne, M. Nottingham, J. Mogul, "Procédures d'enregistrement pour les champs d'en-tête de message", septembre  2004. (BCP0090 ; MàJ par 9110)

[RFC4021]	G. Klyne, J. Palme, "Enregistrement des champs d'en-tête Mail et MIME", mars 2005. (MàJ par RFC5322) (P.S.)

[RFC4288]	N. Freed et J. Klensin, "Spécifications du type de support et procédures d'enregistrement", BCP 13, décembre 2005.

[RFC4289]	N. Freed, J. Klensin, "Extensions multi-objet de messagerie Internet (MIME) Partie quatre : Procédures d'enregistrement", décembre 2005. (Remplace RFC2048) (BCP0013)

[RFC4409]	R. Gellens, J. Klensin, "Soumission du message de messagerie électronique", avril 2006. (Remplacé par la RFC6409 STD072)

[RFC4550]	S. Maes, A. Melnikov, "Messagerie électronique Internet pour la prise en charge de divers profils d'environnements de service (Lemonade)", juin 2006. (P.S.  ; Remplac馥 par  la RFC5550)

[RFC5228]	P. Guenther et autres, "Sieve : un langage de filtrage de messagerie électronique", janvier 2008. (P.S. ; Remplace RFC3028, MàJ par RFC5229, 5429 9042)

[RFC5248]	T. Hansen, J. Klensin, "Registre des codes d'état de système de messagerie améliorée pour SMTP", juin 2008. BCP0138

[RFC5321]	J. Klensin, "Protocole simple de transfert de messagerie(SMTP)", octobre 2008. (D.S.  ;Remplace RFC2821  ; MàJ RFC1123)

[RFC5322]	P. Resnick, éd., "Format du message Internet", octobre 2008. (D.S.  : Remplace RFC2822  ; MàJ RFC4021)

7.2	Références pour information

[RFC0733]	D. Crocker, J. Vittal, K. Pogran, et D. Henderson, "Norme pour le format des messages de texte du réseau ARPA", novembre 1977. (Remplac�e par RFC0822)

[RFC0821]	J. Postel, "Protocole simple de transfert de messagerie", STD 10, août 1982.

[RFC0822]	D. Crocker, "Norme pour le format des messages de texte de l'ARPA-Internet", STD 11, août 1982. (Obsolète, voir RFC5322)

[RFC1506]	J. Houttuin, "Didacticiel sur l'établissement de passerelles entre les messageries X.400 et Internet", août 1993. (Information)

[RFC1652]	J. Klensin et autres, "Extensions de service SMTP pour transport MIME sur 8 bits", juillet 1994. (Remplacée par RFC6152) (D.S.)

[RFC1733]	M. Crispin, "Modèles de messagerie électronique répartie dans IMAP4", décembre 1994. (Information)

[RFC1767]	D. Crocker,"Encapsulation MIME d'objets EDI", mars 1995. (P.S.)

[RFC1985]	J. De Winter, "Extension de service SMTP pour débuter la file d'attente de messages distants", août 1996. (P.S.)

[RFC2033]	J. Myers; "Protocole de transfert de messagerie locale", octobre 1996. (Information)

[RFC2142]	D. Crocker, "Noms de boîtes aux lettres pour les services, rôles et fonctions communs", mai 1997. (P.S.)

[RFC2442]	N. Freed, D. Newman, J. Belissent, M. Hoy, "Type de support Batch sur SMTP", novembre 1998. (Information)

[RFC2480]	N. Freed, "Les routeurs et le traitement de multiparties de sécurité MIME", janvier 1999. (P.S.)

[RFC2505]	G. Lindberg, "Recommandations contre les pourriels dans les MTA de SMTP", février 1999. (BCP0030)  

[RFC2821]	J. Klensin, éditeur, "Protocole simple de transfert de messagerie", STD 10, avril 2001. (Obsolète, voir RFC5321)

[RFC2822]	P. Resnick, "Format de message Internet", avril 2001. (Remplace la RFC0822, STD 11, Remplacée par RFC5322)

[RFC3207]	P. Hoffman, "Extension de service SMTP pour un SMTP sécurisé sur TLS", février 2002. (P.S., MàJ par RFC7817)

[RFC3464]	K. Moore, G. Vaudreuil, "Format extensible de message pour les notifications d'état de livraison", janvier 2003. (MàJ par RFC4865, RFC5337, RFC6533) (D.S.)

[RFC3801]	G. Vaudreuil, G. Parsons, "Profil vocal pour la messagerie Internet - version 2 (VPIMv2)", juin 2004. (D.S.)

[RFC3851]	B. Ramsdell, "Spécification du message d'extensions de messagerie Internet multi-objets/sécurisé (S/MIME) version  3.1", juillet 2004. (Obsolète, voir RFC5751)

[RFC3885]	E. Allman, T. Hansen, "Extension de service SMTP pour le suivi de message", septembre 2004. (P.S.)

[RFC4142]	D. Crocker, G. Klyne, "Profil de télécopie en mode plein pour messagerie Internet (FFPIM)", novembre 2005. (P.S.)

[RFC4143]	K. Toyoda, D. Crocker, "Service ENUM de télécopie sur messagerie Internet (IFAX)", novembre 2005. (P.S.)

[RFC4356]	R. Gellens, "Transposition entre le service de messagerie multimédia (MMS) et la messagerie Internet", janvier 2006. (P.S.)

[RFC4880]	J. Callas et autres, "Format de message OpenPGP", novembre 2007. (Remplace RFC1991, RFC2440) (P.S.)

[RFC4954]	R. Siemborski et A. Melnikov, éd., "Extension de service à SMTP pour l'authentification", juillet 2007. (Remplace RFC2554) (MàJ RFC3463) (MàJ par RFC5248) (P.S.)

[RFC5068]	C. Hutzler et autres, "Opérations de soumission de message électronique : exigences d'accès et de comptabilité", novembre  2007. (BCP0134) (MàJ par RFC8314)

[RFC5235]	C. Daboo, "Filtrage de messagerie Sieve : extensions Spamtest et Virustest", janvier 2008. (Remplace RFC3685) (P.S.)

[RFC5335]	Y. Abel, éd., "En-têtes de messagerie internationalisés", septembre 2008. (MàJ RFC2045, RFC2822) (Remplacée par la RFC6532) (Expérimentale)

[RFC5336]	J. Yao et W. Mao, éd., "Extension SMTP pour adresses de messagerie internationalisée", septembre 2008.  (Expérimentale  ; MàJ RFC2821, RFC2822, RFC4952  ; Remplacée par la RFC6531)

[Tussle]	Clark, D., Wroclawski, J., Sollins, K., and R. Braden, "Tussle in Cyberspace: Defining Tomorrow's Internet", ACM SIGCOMM, 2002.

Appendice A.	Remerciements

Ce travail a commencé en 2004 et a évolué à travers de nombreuses révisions par la communauté ; il découle d’une section d’une première version de la [RFC5068]. Pendant ses cinq années de développement, le document est passé par 14  versions, avec de vigoureuses révisions par la communauté qui ont produit de nombreux changements de substance. Les révisions ont été effectuées à l’IETF et autres événements techniques de la messagerie électronique. Bien que ce ne soit pas une activité formelle de l’IETF, des problèmes du contenu du document ont été résolus en utilisant le style ouvert classique de la communauté de l’IETF, la prise de décision de groupe. Le document est déjà cité dans d’autres travaux, comme les spécifications IMAP et Sieve et dans les travaux académiques. L’étape de la normalisation est utile pour fournir une référence solide et stable au service maintenant complexe de la messagerie Internet.

Les détails du rôle de l’acteur d’origine ont été largement précisés durant les discussions du groupe de travail Marid de l’IETF.

Graham Klyne, Pete Resnick, et Steve Atkins ont fourni des apports sérieux sur le cadre et les détails des projets originaux, comme l’a fait Chris Newman pour les versions finales, tout en servant aussi de directeur de zone compétent pour le document. Tony Hansen a servi de gardien du document dans le processus de l’IETF.

Des relectures et suggestions ultérieures ont été fournies par Eric Allman, Nathaniel Borenstein, Ed Bradford, Cyrus Daboo, Frank Ellermann, Tony Finch, Ned Freed, Eric Hall, Willemien Hoogendoorn, Brad Knowles, John Leslie, Bruce Valdis Kletnieks, Mark E. Mallett, David MacQuigg, Alexey Melnikov, der Mouse, S. Moonesamy, Daryl Odnert, Rahmat M. Samik-Ibrahim, Marshall Rose, Hector Santos, Jochen Topf, Greg Vaudreuil, Patrick Cain, Paul Hoffman, Vijay Gurbani, et Hans Lachman.

Une relecture attentive a été effectuée par Bruce Lilly. Une révision technique professionnelle a été fournie par Susan Hunziker.

Les étapes finales du développement de ce document ont été guidées par une équipe de conception composée de Alexey Melnikov, Pete Resnick, Carl S. Gutekunst, Jeff Macdonald, Randall Gellens, Tony Hansen, et Tony Finch. Pete Resnick a développé la version finale de la section sur l’internationalisation.

Adresse de l'auteur
Dave Crocker
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA  94086
USA
téléphone : +1.408.246.8253
mél : dcrocker@bbiw.net