Aller au contenu principal

2. Rôles des acteurs responsables

La messagerie Internet est un service hautement distribué, avec divers acteurs jouant des rôles différents. Ces acteurs se répartissent en trois types de base :

  • Utilisateur (User)

  • Service de traitement des messages (MHS)

  • Domaine de gestion administrative (ADMD)

Bien que lié à une architecture technique, l'accent mis sur les acteurs concerne les responsabilités des participants, plutôt que la fonctionnalité des modules. Pour cette raison, les étiquettes utilisées sont différentes de celles utilisées dans les diagrammes classiques d'architecture de messagerie électronique.

2.1. Acteurs utilisateurs​

Les utilisateurs sont les sources et les puits (sinks) des messages. Les utilisateurs peuvent être des personnes, des organisations ou des processus. Ils peuvent avoir un échange qui itère, et ils peuvent étendre ou réduire l'ensemble des utilisateurs qui participent à un ensemble d'échanges. Dans la messagerie Internet, il existe quatre types d'utilisateurs :

  • Auteurs (Authors)

  • Destinataires (Recipients)

  • Gestionnaires de retour (Return Handlers)

  • Médiateurs (Mediators)

La figure 2 montre les flux primaires et secondaires de messages entre eux. En tant qu'heuristique pragmatique : les acteurs utilisateurs peuvent générer, modifier ou consulter l'ensemble du message.

         ++==========++
         ||  Author  ||<..................................<..
         ++=++=++=++=++                                     .
         || || ||     ++===========++                    .
         || || ++====>|| Recipient ||                    .
         || ||        ++=====+=====++                    .
         || ||               .                           .
         || ||               ..........................>.+
         || ||                                           .
         || ||               ...................         .
         || ||               .                 .         .
         || ||               V                 .         .
         || ||         +-----------+    ++=====+=====++  .
         || ++========>| Mediator  +===>|| Recipient ||  .
         ||            +-----+-----+    ++=====+=====++  .
         ||                  .                 .         .
         ||                  ..................+.......>.+
         ||                                              .
         ||    ..............+..................         .
         ||    .             .                 .         .
         \/    V             V                 '         .
         +-----------+    +-----------+    ++=====+=====++  .
         | Mediator  +===>| Mediator  +===>|| Recipient ||  .
         +-----+-----+    +-----+-----+    ++=====+=====++  .
               .                .                 .         .
               .................+.................+.......>..

        Legend: === lines indicate primary (possibly indirect)
                    transfers or roles
                ... lines indicate supporting transfers or roles

               Figure 2: Relationships among User Actors

Du point de vue de l'utilisateur, toutes les activités de transfert de messages sont effectuées par un service de traitement des messages (MHS) monolithique, même si le service réel peut être fourni par de nombreuses organisations indépendantes. Les utilisateurs sont des clients de ce service unifié.

Chaque fois qu'un acteur MHS renvoie des informations à un auteur ou à un expéditeur (Originator) dans la séquence de traitement d'un message, cet acteur est un utilisateur.

2.1.1. Auteur (Author)​

L'auteur est responsable de la création du message, de son contenu et de sa liste d'adresses de destinataires. Le MHS transfère le message de l'auteur et le livre aux destinataires. Le MHS a un rôle d'expéditeur (section 2.2.1) qui correspond au rôle de l'auteur.

2.1.2. Destinataire (Recipient)​

Le destinataire est un consommateur du message livré. Le MHS a un rôle de récepteur (section 2.2.4) qui correspond au rôle de destinataire. Cela est étiqueté Recv dans la figure 3.

Tout destinataire peut fermer la boucle de communication utilisateur en créant et en soumettant un nouveau message qui répond à l'auteur. Un exemple de formulaire de réponse automatisé est la notification de disposition de message (MDN), qui informe l'auteur du traitement du message par le destinataire. (Voir la section 4.1.)

2.1.3. Gestionnaire de retour (Return Handler)​

Également appelé « Bounce Handler », le gestionnaire de retour est une forme spéciale de destinataire chargé de traiter les notifications générées par le MHS lors du transfert ou de la livraison du message. (Voir la figure 3.) Ces avis peuvent concerner des échecs ou des achèvements et sont envoyés à une adresse spécifiée par l'expéditeur. Cette adresse de gestion de retour (également appelée adresse de retour) peut n'avoir aucune caractéristique visible en commun avec l'adresse de l'auteur ou de l'expéditeur.

2.1.4. Médiateur (Mediator)​

Un médiateur reçoit, agrège, reformule et redistribue des messages entre les auteurs et les destinataires qui sont les principaux acteurs d'échanges (potentiellement) prolongés. Cette activité est facilement confondue avec les échanges de transfert MHS sous-jacents. Cependant, chacun sert des objectifs très différents et fonctionne de manière très différente.

Lorsque le courrier est livré au médiateur spécifié dans la commande RFC5321.RcptTo pour le message d'origine, le MHS le traite de la même manière que pour tout autre destinataire. En particulier, le MHS considère chaque activité de publication et de livraison entre les sources et les puits comme indépendante ; il ne considère pas la republication ultérieure comme la continuation d'un processus. Parce que le médiateur est à l'origine des messages, il peut recevoir des réponses. Par conséquent, lors de la soumission d'un message reformulé, le médiateur est un auteur, bien qu'il soit en fait un auteur servant d'agent à un ou plusieurs autres auteurs. Ainsi, un médiateur est vraiment un utilisateur à part entière. Les médiateurs sont examinés en détail dans la section 5.

Un médiateur tente de préserver les informations de l'auteur original dans le message qu'il reformule, mais il est autorisé à apporter des modifications significatives 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 provenant de, ou du moins initié par, l'auteur du message original. Le rôle d'un médiateur ne se limite pas à simplement connecter d'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 autorisés à 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, telles que l'examen, la modification et l'approbation d'une demande d'achat.

Une passerelle est une forme particulièrement intéressante de médiateur. C'est un hybride d'utilisateur et de relais qui connecte des services de messagerie hétérogènes. Son but est d'émuler un relais. Pour une discussion détaillée, voir la section 2.2.3.

2.2. Acteurs du service de traitement des messages (MHS)​

Le service de traitement des messages (MHS) effectue un transfert unique de bout en bout au nom de l'auteur pour atteindre les adresses de destinataires spécifiées dans les commandes RFC5321.RcptTo d'origine. Les échanges qui sont soit médiatisés, soit itératifs et prolongés, tels que ceux utilisés pour la collaboration au fil du temps, sont gérés par les acteurs utilisateurs, et non par les acteurs MHS. En tant qu'heuristique pragmatique, les acteurs MHS génèrent, modifient ou consultent uniquement les données de transfert, plutôt que le message entier.

La figure 3 montre les relations entre les participants au transfert dans Internet Mail. Bien qu'elle montre l'Originateur (étiqueté Origin) comme distinct de l'Auteur, et le Récepteur (étiqueté Recv) comme distinct du Destinataire, chaque paire de rôles a généralement le même Acteur. Les transferts impliquent généralement un ou plusieurs Relais. Cependant, une distribution directe de l'Originateur au Récepteur est possible. Les services de messagerie intra-organisationnels n'ont généralement qu'un seul Relais.

         ++==========++                        ++===========++
         ||  Author  ||                        || Recipient ||
         ++====++====++   +--------+           ++===========++
               ||         | Return |                  /\
               ||         +-+------+                  ||
               \/           .    ^                    ||
           +---------+      .    .                +---++---+
           |         |      .    .                |        |
        /--+---------+----------------------------+--------+----\
        |  |         |      .    .      MHS       |        |    |
        |  | Origin  +<......    .................+  Recv  |    |
        |  |         |           ^                |        |    |
        |  +---++----+           .                +--------+    |
        |      ||                .                    /\        |
        |      ||  ..............+..................  ||        |
        |      \/  .             .                 .  ||        |
        |  +-------+-+        +--+------+        +-+--++---+    |
        |  |  Relay  +=======>|  Relay  +=======>|  Relay  |    |
        |  +---------+        +----++---+        +---------+    |
        |                          ||                           |
        |                          ||                           |
        |                          \/                           |
        |                     +---------+                       |
        |                    | Gateway +-->...                  |
        |                     +---------+                       |
        \-------------------------------------------------------/

       Legend: === and || lines indicate primary (possibly
                   indirect) transfers or roles
               ... lines indicate supporting transfers or roles

               Figure 3: Relationships among MHS Actors

2.2.1. Originateur (Originator)​

L'Originateur s'assure qu'un message est valide pour la publication, puis le soumet à un Relais. Un message est valide s'il est conforme à la fois aux normes Internet Mail et aux politiques opérationnelles locales. L'Originateur peut simplement vérifier la conformité du message et le rejeter s'il trouve des erreurs, ou il peut créer une partie ou la totalité des informations nécessaires. En effet, l'Originateur est responsable des fonctions de l'Agent de soumission de courrier (Mail Submission Agent).

L'Originateur opère avec une double allégeance. Il sert l'Auteur et peut être la même entité. Mais son rôle dans l'assurance de validité signifie qu'il représente également l'opérateur local du MHS, c'est-à-dire le domaine de gestion administrative local (ADministrative Management Domain - ADMD).

L'Originateur effectue également toutes les tâches administratives post-soumission liées à l'Auteur et associées au transfert et à la distribution des messages. Notamment, ces tâches concernent l'envoi d'avis d'erreur et de distribution, l'application des politiques locales, et le traitement des messages de l'Auteur qui s'avèrent problématiques pour Internet. L'Originateur est responsable du contenu du message, même lorsqu'il n'en est pas responsable. L'Auteur crée le message, mais l'Originateur gère tout problème de transmission lié à celui-ci.

2.2.2. Relais (Relay)​

Le Relais effectue le routage du service de transfert au niveau MHS et le stockage-et-renvoi en transmettant ou retransmettant le message à ses Destinataires. Le Relais ajoute des informations de traçage [RFC2505] mais ne modifie pas les informations d'enveloppe ni la sémantique du contenu du message. Il peut modifier la représentation du contenu du message, comme changer la forme du codage de transfert de binaire en texte, mais uniquement selon les besoins pour répondre aux capacités du saut suivant dans le MHS.

Un réseau de système de traitement de messages (MHS) consiste en un ensemble de Relais. Ce réseau est au-dessus de tout réseau de commutation de paquets sous-jacent pouvant être utilisé et en dessous de tout Passerelle ou autre Médiateur.

En d'autres termes, les scénarios de messagerie peuvent impliquer trois couches architecturaux distinctes, chacune fournissant son propre type de données de service de stockage-et-renvoi :

  • Médiateurs utilisateurs

  • Relais MHS

  • Commutateurs de paquets

La couche inférieure est le service IP d'Internet. Les scénarios de messagerie les plus élémentaires impliquent des Relais et des Commutateurs.

Lorsqu'un Relais cesse de tenter de transférer un message, il devient un Auteur car il envoie un message d'erreur à l'adresse de retour (Return Address). Le risque de bouclage est évité en omettant une adresse de retour de ce message.

2.2.3. Passerelle (Gateway)​

Une Passerelle est un hybride d'Utilisateur et de Relais qui connecte des services de messagerie hétérogènes. Son but est d'émuler un Relais et plus elle s'en rapproche, mieux c'est. Une Passerelle opère comme un Utilisateur lorsqu'elle a besoin de la capacité de modifier le contenu du message.

Les différences entre les services de messagerie peuvent être aussi petites que de légères variations de syntaxe, mais elles englobent généralement des distinctions sémantiques significatives. Une différence pourrait être des adresses e-mail hiérarchiques et spécifiques à la machine plutôt qu'un espace de noms plat et global. Une autre différence pourrait être le support de contenu texte seul ou multimédia. Ainsi, la fonction de Relais dans une Passerelle présente un défi de conception important si la performance résultante doit être perçue comme presque transparente. Le défi est d'assurer une fonctionnalité Utilisateur-à-Utilisateur entre les services, malgré les différences de syntaxe et de sémantique.

Le test de base de la conception d'une Passerelle est de savoir si un Auteur d'un côté de la Passerelle peut envoyer un message utile à un Destinataire de l'autre côté, sans nécessiter de modifications aux composants des services de messagerie de l'Auteur ou du Destinataire autres que l'ajout de la Passerelle. Pour chacun de ces services autrement indépendants, la Passerelle apparaît comme un participant natif. Mais le test ultime de la conception d'une Passerelle est de savoir si l'Auteur et le Destinataire peuvent soutenir un dialogue. En particulier, un MUA du Destinataire peut-il formuler automatiquement une Réponse valide qui atteindra l'Auteur ?

2.2.4. Récepteur (Receiver)​

Le Récepteur effectue la distribution finale ou envoie le message à une adresse alternative. Il peut également effectuer un filtrage et d'autres applications de politique immédiatement avant ou après la distribution.

2.3. Acteurs administratifs​

Les Acteurs administratifs peuvent être associés à différentes organisations, chacune ayant sa propre autorité administrative. Cette indépendance opérationnelle, couplée au besoin d'interaction entre les groupes, motive la distinction entre les domaines de gestion administrative (ADministrative Management Domains - ADMD). Chaque ADMD peut avoir des politiques opérationnelles très différentes et une prise de décision basée sur la confiance. Un exemple évident est la distinction entre le courrier échangé au sein d'une organisation et le courrier échangé entre des organisations indépendantes. Les règles de traitement des deux types de trafic tendent à être assez différentes. Cette différence nécessite de définir les limites de chacun, ce qui nécessite la construction ADMD.

L'exploitation des services Internet Mail est assurée 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 des limites qui distinguent différentes parties du service Internet Mail. Un département qui exploite un Relais local, un département informatique qui exploite un Relais d'entreprise, et un FAI qui exploite un service de courrier partagé public peuvent être configurés en de nombreuses combinaisons de relations administratives et opérationnelles. Chacun est un ADMD distinct, ayant potentiellement un agencement complexe de composants fonctionnels. La figure 4 illustre les relations entre les ADMD. L'avantage de la construction ADMD est qu'elle facilite la discussion sur les conceptions, les politiques et les opérations qui doivent distinguer les problèmes internes des problèmes externes.

L'impact architectural du besoin de limites entre les ADMD est discuté dans [Tussle]. Le plus significatif est que les entités communiquant à travers les limites ADMD ont généralement le fardeau supplémentaire d'appliquer des politiques organisationnelles concernant les communications externes. À un niveau plus terre-à-terre, le routage du courrier entre les ADMD peut être un problème, comme le besoin de router le courrier entre des partenaires organisationnels via des chemins spécialement fiables.

Voici trois types de base d'ADMD :

Edge : : Services de transfert indépendants dans les réseaux à la périphérie du service Internet Mail ouvert.

Consumer : : Peut être un type de service Edge, comme c'est courant pour l'accès au courrier électronique basé sur le web.

Transit : : Fournisseurs de services de messagerie (MSP) qui offrent des capacités à valeur ajoutée pour les ADMD Edge, telles que l'agrégation et le filtrage.

Le service de transit au niveau du courrier est différent de la commutation au niveau des paquets. Les transferts de paquets de bout en bout passent généralement par des routeurs intermédiaires ; l'échange de courrier à travers Internet ouvert peut être directement entre les MTA limites des ADMD Edge. Cette distinction entre interaction directe et indirecte souligne les différences discutées à la section 2.2.2.

       +--------+     +---------+     +-------+     +-----------+
       |  ADMD1 |<===>|  ADMD2  |<===>| ADMD3 |<===>|   ADMD4   |
       |  ----- |     |  -----  |     | ----- |     |   -----   |
       |        |     |         |     |       |     |           |
       | Author |     |         |     |       |     | Recipient |
       |   .    |     |         |     |       |     |     ^     |
       |   V    |     |         |     |       |     |     .     |
       |  Edge..+....>|.Transit.+....>|-Edge..+....>|..Consumer |
       |        |     |         |     |       |     |           |
       +--------+     +---------+     +-------+     +-----------+

       Legend: === lines indicate primary (possibly indirect)
                   transfers or roles
               ... lines indicate supporting transfers or roles

            Figure 4: Administrative Domain (ADMD) Example

Les réseaux Edge peuvent utiliser des normes de messagerie propriétaires en interne. Cependant, la distinction entre les services de transfert de réseau Transit et de réseau Edge est significative car elle souligne le besoin de préoccupation quant à l'interaction et la protection entre administrations indépendantes. En particulier, cette distinction exige une attention supplémentaire dans l'évaluation des transitions de responsabilité et des relations de responsabilité et d'autorisation entre les participants au transfert de messages.

Les interactions des composants ADMD sont soumises aux politiques de ce domaine, qui couvrent des préoccupations telles que :

  • Fiabilité

  • Contrôle d'accès

  • Responsabilité

  • Évaluation et modification du contenu

Ces politiques peuvent être implémentées dans différents composants fonctionnels, selon les besoins de l'ADMD. Par exemple, voir [RFC5068].

Les services Consumer, Edge et Transit peuvent être offerts par des fournisseurs qui exploitent des services composants ou des ensembles de services. De plus, il est possible pour un ADMD d'héberger des services pour d'autres ADMD.

Voici des exemples courants d'ADMD :

Fournisseurs de services d'entreprise : : Ces ADMD exploitent les données internes et/ou les services de courrier au sein d'une organisation.

Fournisseurs de services Internet (ISP) : : Ces ADMD exploitent 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 l'exécution des fonctions de courrier électronique, mais ils peuvent fournir un environnement dans lequel ces fonctions peuvent être exécutées.

Fournisseurs de services de messagerie : : Ces ADMD exploitent des services de courrier électronique, tels que pour les consommateurs ou les entreprises clientes.

Les préoccupations opérationnelles 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 paquets de niveau inférieur.