4. Services et Standards

L'architecture de messagerie Internet comprend six types de fonctionnalités de base, qui sont organisées pour soutenir un service de stockage et de retransmission (store-and-forward). Comme le montre 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 les relations entre ces composants, ainsi que les normes de messagerie Internet qui s'y appliquent.

• Message
• Agent utilisateur de message (Message User Agent, MUA)
  • MUA Auteur (Author MUA, aMUA)
  • MUA Destinataire (Recipient MUA, rMUA)
• Agent de soumission de message (Message Submission Agent, MSA)
  • Fonctions MSA centrées sur l'Auteur (aMSA)
  • Fonctions MSA centrées sur le MHS (hMSA)
• Agent de transfert de message (Message Transfer Agent, MTA)
• Agent de livraison de message (Message Delivery Agent, MDA)
  • Fonctions MDA centrées sur le Destinataire (rMDA)
  • Fonctions MDA centrées sur le MHS (hMDA)
• Magasin de messages (Message Store, MS)
  • MS Auteur (aMS)
  • MS Destinataire (rMS)

Cette figure montre les modules fonctionnels et les protocoles standardisés utilisés entre eux.

                 ++========++
                 ||        ||                             +-------+
      ...........++  aMUA  ||<............................+ Disp  |
      .          ||        ||                             +-------+
      .          ++=+==+===++                                 ^
      .  local,imap}|  |{smtp,submission                      .
      .  +-----+    |  |                          +--------+  .
      .  | aMS |<---+  | ........................>| Return |  .
      .  +-----+       | .                        +--------+  .
      .                | .    *****************       ^       .
      .          +-----V-.----*------------+  *       .       .
      .      MSA | +-------+  *   +------+ |  *       .       .
      .          | | aMSA  +-(S)->| hMSA | |  *       .       .
      .          | +-------+  *   +--+---+ |  *       .       .
      V          +------------*------+-----+  *       .       .
//==========\\                *      V {smtp  *       .       .
|| MESSAGE  ||                *   +------+    *  //===+===\\  .
||----------||            MHS *   | MTA  |    *  ||  dsn  ||  .
|| ENVELOPE ||                *   +--+---+    *  \\=======//  .
||  smtp    ||                *      V {smtp  *     ^   ^     .
|| CONTENT  ||                *   +------+    *     .   . //==+==\\
||  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 des transferts ou rôles principaux (éventuellement indirects)
             === les boîtes indiquent des objets de données
             ... les lignes indiquent des transferts ou rôles de support
             *** les lignes indiquent un service agrégé

                 Figure 5: Protocoles et Services

4.1. Données de Message

L'objectif du système de traitement des messages (Message Handling System, MHS) est d'échanger un objet message IMF entre les participants [RFC5322]. Tous ses mécanismes sous-jacents servent à livrer ce message de son Auteur (Author) à ses Destinataires (Recipients). Un message peut être explicitement étiqueté quant à sa nature [RFC3458].

Un message comprend une enveloppe de traitement de 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 (header) structuré et le corps (body). L'en-tête comprend des informations de trace de 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ées ou une arborescence d'objets subordonnés multimédias, appelés « parties de corps » (body-parts) ou, populairement, « pièces jointes » (attachments). [RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289], [RFC2049].

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

Notification d'état de livraison (Delivery Status Notification, DSN) :

Une notification d'état de livraison (DSN) est un message qui peut être généré par le MHS (MSA, MTA ou MDA) et envoyé à l'adresse RFC5321.MailFrom. Le MDA et le MTA sont indiqués comme sources de DSN dans la Figure 5, et la destination est indiquée comme Return. Les DSN fournissent des informations sur le transit du message, telles que les erreurs de transfert ou la livraison réussie [RFC3461].

Notification de disposition de message (Message Disposition Notification, MDN) :

Une notification de disposition de message (MDN) est un message qui fournit des informations sur le traitement après la livraison, comme l'indication 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 Disposition-Notification-To. La boîte aux lettres pour cela est indiquée comme Disp dans la Figure 5.

Filtrage de messages (SIEVE) :

Sieve est un langage de script utilisé pour spécifier des conditions pour le traitement différentiel du courrier, généralement au moment de la livraison [RFC5228]. Les scripts peuvent être transmis de diverses manières, par exemple en tant que partie MIME dans un message. La Figure 5 montre un script Sieve allant du rMUA au MDA. Cependant, le filtrage peut être effectué à de nombreux points différents le long du chemin de transit, et un ou plusieurs d'entre eux peuvent être soumis aux directives Sieve, en particulier au sein d'un même ADMD. La Figure 5 ne montre qu'une seule relation, pour la simplicité (relative).

4.1.1. Enveloppe (Envelope)

La messagerie Internet a un cadre fragmenté pour les informations de traitement liées au transit. Les informations qui sont utilisées directement par le MHS sont appelées « enveloppe ». Elle dirige les activités de traitement par le service de transfert et est transportée dans les commandes du service de transfert. C'est-à-dire que l'enveloppe existe dans le protocole de transfert SMTP [RFC5321].

Les informations de trace, telles que RFC5322.Received, sont enregistrées dans l'en-tête du message et ne sont pas modifiées par la suite [RFC5322].

4.1.2. Champs d'En-tête (Header Fields)

Les champs d'en-tête sont des paires nom/valeur d'attribut qui couvrent une gamme extensible de paramètres de service de messagerie, de contenu utilisateur structuré et de méta-informations de transaction utilisateur. L'ensemble principal de champs d'en-tête est défini dans [RFC5322]. Il est courant d'étendre cet ensemble pour différentes applications. Les procédures d'enregistrement des champs d'en-tête sont définies dans [RFC3864]. Un ensemble complet d'enregistrements de champs d'en-tête existants est fourni dans [RFC4021].

Un danger de placer des informations supplémentaires dans les champs d'en-tête est que les passerelles les modifient ou les suppriment souvent.

4.1.3. Corps (Body)

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

4.1.4. Références d'identité dans un Message

Le Tableau 1 liste les identifiants principaux présents dans un message pendant le transit.

Couche	Champ	Défini par
Corps du message	En-tête MIME	Auteur (Author)
Champs d'en-tête du message	From:	Auteur (Author)
	Sender:	Expéditeur (Originator)
	Reply-To:	Auteur (Author)
	To:, CC:, BCC:	Auteur (Author)
	Message-ID:	Expéditeur (Originator)
	Received:	Expéditeur, Relais, Récepteur
	Return-Path:	MDA, depuis MailFrom
	Resent-*:	Médiateur (Mediator)
	List-Id:	Médiateur (Mediator)
	List-*:	Médiateur (Mediator)
SMTP	HELO/EHLO	Dernier Client Relais
	ENVID	Expéditeur (Originator)
	MailFrom	Expéditeur (Originator)
	RcptTo	Auteur (Author)
	ORCPT	Expéditeur (Originator)
IP	Adresse Source	Dernier Client Relais

Légende :

• Couche (Layer) - La partie de l'architecture de messagerie qui utilise l'identifiant.

• Champ (Field) - La construction de protocole qui contient l'identifiant.

• Défini par (Set By) - Le rôle de l'Acteur responsable de la spécification de la valeur de l'identifiant (cela peut être différent de l'Acteur qui exécute la fonction de remplissage pour la construction du protocole).

Tableau 1 : Identités superposées

Ce sont les champs liés à l'adresse les plus courants :

RFC5322.From : Défini par - Auteur (Author)

Les noms et adresses des Auteurs du contenu du message sont listés dans le champ From:.

RFC5322.Reply-To : Défini par - Auteur (Author)

Si un Destinataire envoie un message de réponse qui utiliserait autrement les adresses du champ RFC5322.From du message d'origine, les adresses du champ RFC5322.Reply-To sont utilisées à la place. En d'autres termes, ce champ remplace le champ From: pour les réponses des Destinataires.

RFC5322.Sender : Défini par - Expéditeur (Originator)

Ce champ spécifie l'adresse responsable de la soumission du message au service de transfert. Ce champ peut être omis s'il contient la même adresse que RFC5322.From. Cependant, l'omission de ce champ ne signifie pas qu'aucun expéditeur (Sender) n'est spécifié ; cela signifie que ce champ d'en-tête est virtuel et que l'adresse du champ From: doit être utilisée.

La spécification des adresses de retour de notification, qui sont contenues dans RFC5321.MailFrom, est faite par le RFC5322.Sender. Généralement, l'adresse de retour est la même que l'adresse de l'expéditeur (Sender). Cependant, certains scénarios d'utilisation exigent qu'elles soient différentes.

RFC5322.To/.CC : Défini par - Auteur (Author)

Ces champs spécifient les adresses des Destinataires MUA. Cependant, certaines ou toutes les adresses dans ces champs peuvent ne pas être 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 censé agir sur le message. Un destinataire CC reçoit généralement une copie par courtoisie.

RFC5322.BCC : Défini par - Auteur (Author)

Une copie du message peut être envoyée à un destinataire dont la participation ne doit pas être divulguée aux Destinataires RFC5322.To ou RFC5322.CC et, généralement, pas aux autres Destinataires BCC. Le champ d'en-tête BCC: indique une copie de message à un tel Destinataire. L'utilisation de ce champ est discutée dans [RFC5322].

RFC5321.HELO/.EHLO : Défini par - Expéditeur, MSA, MTA

Tout client SMTP -- y compris Expéditeur, 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 : Défini par - Expéditeur (Originator)

Le MSA peut spécifier une chaîne opaque, à inclure dans un DSN, comme moyen d'aider le Destinataire de l'Adresse de Retour à identifier le message qui a produit un DSN ou un suivi de message.

RFC5321.MailFrom : Défini par - Expéditeur (Originator)

Il s'agit d'une chaîne de bout en bout qui spécifie une adresse e-mail pour recevoir des informations de contrôle de retour, telles que les messages renvoyés. Le nom de ce champ est trompeur, car il n'est pas nécessaire de spécifier l'Auteur ou l'Acteur responsable de la soumission du message. C'est plutôt l'Acteur responsable de la soumission qui spécifie l'adresse RFC5321.MailFrom. En fin de compte, la base simple pour décider quelle adresse doit figurer dans le champ RFC5321.MailFrom est de déterminer quelle adresse doit être informée des problèmes au niveau du transfert (et éventuellement des succès).

RFC5321.RcptTo : Défini par - Auteur, MTA Final, MDA

Ce champ spécifie l'adresse de la boîte aux lettres MUA d'un Destinataire. La chaîne peut ne pas être visible dans l'en-tête du contenu du message. Par exemple, les champs d'en-tête d'adresse de destination IMF, tels que RFC5322.To, peuvent 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 : Défini par - Expéditeur (Originator)

Il s'agit d'un paramètre optionnel de la commande RCPT, indiquant l'adresse d'origine à laquelle correspond l'adresse RCPT TO actuelle, après qu'un mappage a été effectué pendant le transit. Un ORCPT est le seul moyen fiable de corréler un DSN d'un transfert de message multi-destinataire avec le Destinataire prévu.

RFC5321.Received : Défini par - Expéditeur, Relais, Médiateur, Dest

Ce champ contient des informations de trace, y compris l'hôte d'origine, les relais, les médiateurs et les noms de domaine d'hôte MSA et/ou les adresses IP.

RFC5321.Return-Path : Défini par - Expéditeur (Originator)

Le MDA enregistre l'adresse RFC5321.MailFrom dans le champ RFC5321.Return-Path.

RFC2919.List-Id : Défini par - Médiateur, Auteur

Ce champ fournit un cadre de nommage de liste de diffusion unique au niveau mondial 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 e-mail. Le résultat est rarement un vrai nom de domaine, répertorié dans le service de nom de domaine, bien qu'il puisse l'être.

RFC2369.List-* : Défini par - Médiateur, Auteur

[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 à la liste pour les opérations courantes des utilisateurs de listes de diffusion. Les identifiants de ces opérations sont pour la liste elle-même et l'utilisateur en tant qu'abonné [RFC2369].

RFC0791.SourceAddr: Défini par - L'hôte d'envoi SMTP Client précédant immédiatement le serveur SMTP de réception actuel

[RFC0791] définit l'unité de base du transfert de données pour Internet : le datagramme IP. Il contient un champ Adresse Source qui spécifie l'adresse IP de l'hôte (interface) à partir duquel le datagramme a été envoyé. Cette information est définie et fournie par la couche IP, ce qui la rend indépendante des mécanismes au niveau du courrier. En tant que telle, elle est souvent considérée comme faisant autorité, bien qu'il soit possible de fournir de fausses adresses.

4.2. Services de Niveau Utilisateur

Les interactions au niveau de l'utilisateur impliquent des échanges de protocoles, distincts de ceux qui se produisent aux couches inférieures de l'architecture MHS de messagerie Internet, qui est, à son tour, au-dessus de la couche de transport Internet. Parce que la motivation du courrier électronique, et une grande partie de son utilisation, est l'interaction entre les personnes, la nature et les détails de ces échanges de protocoles sont souvent déterminés par les besoins de la communication interpersonnelle et de groupe. Pour tenir compte du comportement idiosyncrasique inhérent à une telle communication, seules des directives subjectives, plutôt que des règles strictes, peuvent être proposées pour certains aspects du comportement du système. Les listes de diffusion fournissent des exemples particulièrement saillants.

4.2.1. Agent Utilisateur de Message (MUA)

Un Agent Utilisateur de Message (MUA) travaille pour le compte des Acteurs Utilisateurs et des applications Utilisateurs. Il est leur représentant au sein du service de messagerie.

Le MUA Auteur (aMUA) crée un message et effectue la soumission initiale dans l'infrastructure de transfert via un Agent de Soumission de Message (MSA). Il peut également effectuer tout archivage au moment de la création et de la publication dans son Magasin de Messages (aMS). Un aMS MUA peut organiser les messages de nombreuses manières différentes. Un modèle courant utilise des agrégations, appelées « dossiers » ; dans IMAP, ils sont appelés « boîtes aux lettres ». Ce modèle permet un dossier pour les messages en cours de développement (Brouillons), 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é publiés avec succès pour le transfert (Envoyés). Mais aucun de ces dossiers n'est requis. Par exemple, IMAP permet de stocker les brouillons dans n'importe quel dossier, de sorte qu'aucun dossier Brouillons n'a besoin d'être présent.

Le MUA Destinataire (rMUA) travaille pour le compte du Destinataire pour traiter le courrier reçu. Ce traitement comprend la génération de messages de contrôle de disposition au niveau de l'utilisateur, l'affichage et la disposition du message reçu, et la fermeture ou l'expansion de la boucle de communication utilisateur en initiant des réponses et en transférant de nouveaux messages.

NOTE : Bien qu'il ne soit pas représenté dans la Figure 5, un MUA lui-même peut avoir une implémentation distribuée, telle qu'un module d'interface utilisateur « léger » sur un appareil contraint tel qu'un smartphone, avec la plupart des fonctionnalités MUA s'exécutant à distance sur un serveur plus capable. Un exemple d'une telle architecture pourrait utiliser IMAP [RFC3501] pour la plupart des interactions entre un client MUA et un serveur MUA. Une approche pour de tels scénarios est définie par [RFC4550].

Un Médiateur est une classe spéciale de MUA. Il effectue la re-publication de message, comme indiqué dans la Section 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 masse qui a une fonction de lancement programmé. 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, tel que celui qui envoie des avis d'absence du bureau. 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 agacer les Utilisateurs des listes de diffusion à moins qu'ils ne suivent [RFC3834].

Les champs d'identité sont pertinents pour un MUA typique :

• RFC5322.From

• RFC5322.Reply-To

• RFC5322.Sender

• RFC5322.To, RFC5322.CC

• RFC5322.BCC

4.2.2. Magasin de Messages (MS)

Un MUA peut utiliser un magasin de messages (MS) à long terme. La Figure 5 dépeint le MS d'un Auteur (aMS) et le MS d'un Destinataire (rMS). Un MS peut être situé sur un serveur distant ou sur la même machine que le MUA.

Un MS acquiert des messages d'un MDA soit de manière proactive par un mécanisme local ou même par un mécanisme standardisé tel que SMTP(!), soit de manière réactive en utilisant POP ou IMAP. Le MUA accède au MS soit par un mécanisme local, soit en utilisant POP ou IMAP. L'utilisation de POP pour les accès aux messages individuels, plutôt que pour le transfert en masse, est relativement rare et inefficace.

4.3. Services de Niveau MHS

4.3.1. Agent de Soumission de Message (MSA)

Un Agent de Soumission de Message (MSA) accepte le message soumis par l'aMUA et applique les politiques de l'ADMD d'hébergement et les exigences des normes Internet. Un MSA représente une dichotomie fonctionnelle inhabituelle. Il représente les intérêts de l'Auteur (aMUA) lors de la publication du message, pour faciliter le succès de la publication ; il représente également 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 au MHS, est appelé « publication ». Dans la Figure 5, il est marqué comme la transition (S), au sein du MSA.

Le hMSA assume la responsabilité de transit pour un message conforme aux normes Internet pertinentes 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 implémentations locales. Des exemples de tâches aMSA incluent l'ajout de champs d'en-tête, tels que Date: et Message-ID:, et la modification de parties du message des notations locales aux normes Internet, telles que l'expansion d'une adresse à sa représentation formelle IMF.

Historiquement, les publications de messages MUA/MSA basées sur des 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 port TCP distinct et impose des exigences distinctes, telles que 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) relaye le courrier pour un « saut » de niveau application. Il est comme un commutateur de paquets ou un routeur IP en ce sens que son travail consiste à effectuer des évaluations de routage et à rapprocher le message des Destinataires. Bien sûr, les objets de messagerie sont généralement beaucoup plus grands que la charge utile d'un paquet ou d'un datagramme, et les latences de bout en bout sont généralement beaucoup plus élevées. Le relais est effectué par une séquence de MTA jusqu'à ce que le message atteigne un MDA de destination. Par conséquent, un MTA implémente à la fois la fonctionnalité client et serveur MTA ; il ne modifie pas les adresses dans l'enveloppe ni ne reformule le contenu éditorial. Un changement de forme de données, tel que l'encodage de transfert de contenu MIME (Content-Transfer-Encoding), relève de la compétence d'un MTA, mais la suppression ou le remplacement du contenu du corps ne l'est pas. Un MTA ajoute également des informations de trace [RFC2505].

NOTE : Au sein d'un ADMD de destination, les modules de relais de courrier électronique peuvent apporter diverses modifications au message, avant la livraison. Dans de tels 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 point à point entre des MTA pairs. D'autres mécanismes de transfert incluent Batch SMTP [RFC2442] et On-Demand Mail Relay (ODMR) SMTP [RFC2645]. Comme avec la plupart des mécanismes de couche réseau, le SMTP de messagerie Internet prend en charge un niveau de fiabilité de base, en prévoyant la retransmission après un échec de transfert temporaire. Contrairement aux commutateurs de paquets typiques (et aux services de messagerie instantanée), les MTA de messagerie Internet sont censés stocker les messages d'une manière qui permet la récupération après des interruptions de service, telles que l'arrêt du système hôte. Le degré de cette robustesse et de cette persistance par un MTA peut varier. La spécification SMTP de base fournit un cadre pour les codes de réponse de protocole. Une amélioration extensible de ce cadre est définie dans [RFC5248].

Bien que très basique, le mécanisme de routage dominant pour la messagerie Internet est l'enregistrement MX DNS [RFC1035], qui spécifie un MTA par lequel le domaine interrogé peut être atteint. Ce mécanisme présume une dorsale (backbone) publique, ou au moins commune, qui permet à tout MTA attaché de se connecter à tout autre.

Les MTA peuvent effectuer l'un de ces rôles bien établis :

MTA Frontière (Boundary MTA) :

Un MTA qui fait partie d'un ADMD et interagit avec des MTA dans d'autres ADMD. C'est aussi appelé un MTA Border. Il peut y avoir différents MTA Frontière, selon la direction du flux de courrier.

MTA Sortant (Outbound MTA) : Un MTA qui relaye les messages vers d'autres ADMD.

MTA Entrant (Inbound MTA) : Un MTA qui reçoit des messages SMTP entrants de relais MTA d'autres ADMD, par exemple, un MTA s'exécutant sur l'hôte répertorié comme cible d'un enregistrement MX.

MTA Final (Final MTA) :

Le MTA qui transfère un message au MDA.

Ces identités sont pertinentes pour le MTA :

• RFC5321.HELO/.EHLO

• RFC3461.ENVID

• RFC5321.MailFrom

• RFC5321.RcptTo

• RFC5322.Received : Défini par - Serveur Relais

• RFC0791.SourceAddr

4.3.3. Agent de Livraison de Message (MDA)

Un transfert de responsabilité du MHS vers l'environnement d'un Destinataire (boîte aux lettres) est appelé « livraison ». Dans l'architecture, comme illustré à la Figure 5, la livraison a lieu au sein d'un Agent de Livraison de Message (MDA) et est représentée par la transition (D) du composant MDA orienté MHS (hMDA) vers le composant MDA orienté Destinataire (rMDA).

Un MDA peut fournir des fonctionnalités distinctes, basées sur l'adresse, rendues possibles par ses informations détaillées sur les propriétés de l'adresse de destination. Ces informations peuvent également être présentes ailleurs dans l'ADMD du Destinataire, comme à une frontière organisationnelle (Boundary) Relais. Cependant, elles sont requises pour le MDA, ne serait-ce que parce que le MDA doit savoir où livrer le message.

Comme un MSA, un MDA remplit deux rôles, comme le montre la Figure 5. Le transfert formel de responsabilité, appelé « livraison », est effectué entre les deux composants qui incarnent ces rôles et est représenté par « (D) » dans la Figure 5. La partie MHS (hMDA) fonctionne principalement comme un moteur SMTP serveur. Un rôle supplémentaire commun est de rediriger le message vers une autre adresse, comme spécifié par les préférences du destinataire. Le travail de la partie Destinataire du MDA (rMDA) est d'effectuer toutes les actions de livraison que le Destinataire spécifie.

Le transfert dans le MDA est accompli par un mécanisme de transfert MTA normal. Le transfert d'un MDA vers un MS utilise un protocole d'accès, tel que POP ou IMAP.

NOTE : Le terme « livraison » peut faire référence à la fonction MHS formelle spécifiée ici ou à la première fois qu'un message est affiché à un Destinataire. Un test simple et pratique pour savoir si la définition basée sur le MHS s'applique est de savoir si un DSN peut être généré.

Ces identités sont pertinentes pour le MDA :

RFC5321.Return-Path : Défini par - Expéditeur Auteur ou Expéditeur Médiateur

Le MDA enregistre l'adresse RFC5321.MailFrom dans le champ RFC5321.Return-Path.

RFC5322.Received : Défini par - Serveur MDA

Un MDA peut enregistrer un champ d'en-tête Received: pour indiquer des informations de trace, y compris les noms de domaine de l'hôte source et de l'hôte récepteur et/ou les adresses IP.

4.4. Modes de Transition

Du site d'origine au point de livraison, la messagerie Internet suit généralement un modèle « push ». C'est-à-dire que l'Acteur qui détient le message initie le transfert vers le prochain lieu, généralement avec SMTP [RFC5321] ou le Protocole de Transfert de Mail Local (LMTP) [RFC2033]. Avec un modèle « pull », l'Acteur qui détient le message attend que l'Acteur du prochain lieu initie une demande de transfert. Les mécanismes standardisés pour le transfert MHS basé sur le pull sont ETRN [RFC1985] et ODMR [RFC2645].

Après la livraison, le MUA (ou MS) du Destinataire peut obtenir un accès en se faisant pousser le message ou en faisant en sorte que le récepteur de l'accès tire le message, par exemple en utilisant POP [RFC1939] et IMAP [RFC3501].

4.5. Implémentation et Opération

Une discussion sur toute architecture de système intéressante s'enlise souvent lorsque l'architecture et l'implémentation sont confondues. Une architecture définit les fonctions conceptuelles d'un service, divisées en modules conceptuels discrets. Une implémentation de cette architecture peut combiner ou séparer des composants architecturaux, selon les besoins d'un environnement opérationnel particulier. Par exemple, un système logiciel qui effectue principalement le relais de message est un MTA, mais il peut également inclure une fonctionnalité MDA. Ce même système MTA pourrait être capable de s'interfacer avec des services de messagerie non Internet et donc fonctionner à la fois comme un MTA et comme une Passerelle.

De même, les modules implémentés peuvent être configurés pour former des élaborations de l'architecture. Un exemple intéressant est un MS distribué. Une partie peut être un serveur distant et une autre peut être locale au MUA. Comme discuté dans [RFC1733], il existe trois relations opérationnelles entre de tels MS :

En ligne (Online) :

Le MS est distant, et les messages sont accessibles uniquement lorsque le MUA est attaché au MS afin que le MUA récupère tout ou partie d'un message d'une session à l'autre.

Hors ligne (Offline) :

Le MS est local à l'Utilisateur, et les messages sont complètement déplacés de tout magasin distant, plutôt que (aussi) d'y être conservés.

Déconnecté (Disconnected) :

Un rMS et un uMS sont maintenus synchronisés, pour tout ou partie de leur contenu, tant qu'ils sont connectés. Lorsqu'ils sont déconnectés, le courrier peut arriver au rMS et l'Utilisateur peut apporter des modifications à l'uMS. Les deux magasins sont resynchronisés lorsqu'ils sont reconnectés.