5. Médiateurs
Le transfert de message de base de l'Auteur aux Destinataires est accompli en utilisant une infrastructure de communication asynchrone de stockage et de retransmission (store-and-forward) 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 de publications et de livraisons par l'intermédiaire de Médiateurs. Un Médiateur transfère un message via un processus de republication. Le Médiateur partage certaines fonctionnalités avec le relais MTA de base, mais a une plus grande flexibilité à la fois dans l'adressage et le contenu que celle disponible pour les MTA.
Voici l'ensemble principal d'informations de message qui est couramment défini par tous les types de Médiateurs :
RFC5321.HELO/.EHLO : Défini par - Expéditeur Médiateur
RFC3461.ENVID : Défini par - Expéditeur Médiateur
RFC5321.RcptTo : Défini par - Auteur Médiateur
RFC5321.Received : Défini par - Destinataire Médiateur
Le Médiateur peut enregistrer les informations reçues pour indiquer la livraison à l'adresse d'origine et la soumission à l'adresse d'alias. La trace des champs d'en-tête Received: peut inclure tout, de la publication originale, à travers le relais, jusqu'à la livraison finale.
L'aspect d'un Médiateur qui le distingue de tout autre MUA créant un message est qu'un Médiateur préserve l'intégrité et le ton du message original, y compris les aspects essentiels de ses informations d'origine. Le Médiateur peut également ajouter des commentaires.
Les exemples de messages MUA qu'un Médiateur ne crée pas incluent :
Nouveau message qui transfère (Forwards) un message existant :
Bien que cette action fournisse un modèle de base pour une classe de Médiateurs, son occurrence typique n'est pas, en elle-même, un exemple de Médiateur. Le nouveau message est considéré comme provenant de l'Acteur qui effectue le transfert, plutôt que de l'Auteur original.
Un nouveau message encapsule le message original et est vu comme provenant du nouvel Expéditeur. Cet Expéditeur Médiateur peut ajouter des commentaires et peut modifier le contenu du message original. Parce que le message transféré est un composant du message envoyé par le nouvel Expéditeur, le nouveau message crée un nouveau dialogue. Cependant, le Destinataire final voit toujours le message contenu comme provenant de l'Auteur original.
Réponse (Reply) :
Lorsqu'un Destinataire répond à l'Auteur d'un message, le nouveau message n'est généralement pas considéré comme un transfert de l'original. Son objectif est le nouveau contenu, bien qu'il puisse contenir tout ou partie du matériel du message original. Le matériel antérieur est simplement contextuel et secondaire. Cela inclut les réponses automatisées, telles que les avis d'absence du bureau, comme discuté dans la Section 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 le commentaire du texte original. Le but 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 l'emplacement interne d'une boîte aux lettres afin d'effectuer la livraison. Un Alias est une simple fonction de réadressage qui fournit une ou plusieurs nouvelles adresses de messagerie Internet, plutôt qu'une seule adresse interne ; le message continue à travers le service de transfert, pour une livraison à une ou plusieurs adresses alternatives. Bien que généralement implémentée dans le cadre d'un MDA, cette fonction est une fonction de Destinataire. Elle resoumet le message, bien que toutes les informations de traitement, à l'exception de l'adresse du Destinataire de l'enveloppe (rfc5321.RcptTo), soient conservées. En particulier, l'adresse de retour (rfc5321.MailFrom) est inchangée.
Ce qui est distinctif dans ce mécanisme de transfert est à quel point il ressemble étroitement au relais store-and-forward normal du MTA. Sa seule différence significative est qu'il modifie la valeur RFC5321.RcptTo. Parce que ce changement est si petit, l'aliasing peut être considéré comme une partie de l'activité de relais de courrier de bas niveau. Cependant, ce petit changement a un impact sémantique important : le Destinataire désigné a choisi un nouveau Destinataire.
NOTE : Lorsque la liste de remplacement comprend plus d'une adresse, l'alias est de plus en plus susceptible d'avoir des problèmes de livraison. Tout rapport de problème va à l'Auteur original, et non à l'administrateur de l'entrée d'alias. Cela rend plus difficile la résolution du problème, car l'Auteur original n'a aucune connaissance du mécanisme d'Alias.
En incluant l'ensemble principal d'informations de message répertorié au début de cette section, l'Alias change généralement :
RFC5322.To/.CC/.BCC : Défini par - Auteur
Ces champs conservent leurs adresses d'origine.
RFC5321.MailFrom : Défini par - Auteur
L'avantage de conserver la valeur MailFrom d'origine est de s'assurer qu'un Acteur lié à l'ADMD d'origine sait qu'il y a eu un problème de livraison. D'autre part, la responsabilité de gérer les problèmes, lors du transit de la boîte aux lettres du Destinataire d'origine vers la boîte aux lettres d'alias, incombe généralement à ce Destinataire d'origine, car le mécanisme d'Alias est strictement sous le contrôle de ce Destinataire. Conserver l'adresse MailFrom d'origine empêche cela.
5.2. Ré-Expéditeur (ReSender)
Aussi appelé le Redirigeur (ReDirector), les actions du Ré-Expéditeur diffèrent du transfert car le Médiateur « épisse » les informations d'adressage d'un message pour connecter l'Auteur du message original avec le Destinataire du nouveau message. Cette connexion leur permet d'avoir un échange direct, en utilisant leurs fonctions normales de réponse MUA, tout en enregistrant également des informations de référence complètes sur le Destinataire qui a servi de Médiateur. Par conséquent, le nouveau Destinataire voit le message comme provenant de l'Auteur original, même si le Médiateur ajoute des commentaires.
En incluant l'ensemble principal d'informations de message répertorié au début de cette section, ces identités sont pertinentes pour un message réexpédié :
RFC5322.From : Défini par - Auteur original
Les noms et adresses de l'Auteur original du contenu du message sont conservés. La partie libre (display-name) de l'adresse peut être modifiée pour fournir une référence informelle au Ré-Expéditeur.
RFC5322.Reply-To : Défini par - Auteur original
Si ce champ est présent dans le message original, il est conservé dans le message réexpédié.
RFC5322.Sender : Défini par - Expéditeur de l'Auteur ou Expéditeur du Médiateur
RFC5322.To/.CC/.BCC : Défini par - Auteur original
Ces champs spécifient les Destinataires du message original.
RFC5322.Resent-From : Défini par - Auteur Médiateur
Cette adresse est celle du Destinataire original qui redirige le message. Sinon, les mêmes règles s'appliquent au champ Resent-From: qu'à un champ RFC5322.From original.
RFC5322.Resent-Sender : Défini par - Expéditeur Médiateur
L'adresse de l'Acteur responsable de la resoumission du message. Comme pour RFC5322.Sender, ce champ peut être omis lorsqu'il contient la même adresse que RFC5322.Resent-From.
RFC5322.Resent-To/-CC/-BCC : Défini par - Auteur Médiateur
Les adresses des nouveaux Destinataires qui sont maintenant capables de répondre à l'Auteur original.
RFC5321.MailFrom : Défini par - Expéditeur Médiateur
L'Acteur responsable de la resoumission (RFC5322.Resent-Sender) est également responsable de la spécification de la nouvelle adresse MailFrom.
5.3. Listes de Diffusion (Mailing Lists)
Une Liste de Diffusion reçoit des messages en tant que destinataire explicite, puis les republie à une liste de membres abonnés. La Liste de Diffusion effectue une tâche qui peut être considérée comme une élaboration du Ré-Expéditeur. En plus d'envoyer le nouveau message à un nombre potentiellement important de nouveaux Destinataires, la Liste de Diffusion peut modifier le contenu, par exemple en supprimant les pièces jointes, en convertissant le format et en ajoutant des commentaires spécifiques à la liste. Les Listes de Diffusion archivent également les messages publiés par les Auteurs. Le message conserve toujours les caractéristiques d'être de l'Auteur original.
En incluant l'ensemble principal d'informations de message répertorié au début de cette section, ces identités sont pertinentes pour un processeur de Liste de Diffusion lors de la soumission d'un message :
RFC2919.List-Id : Défini par - Auteur Médiateur
RFC2369.List-* : Défini par - Auteur Médiateur
RFC5322.From : Défini par - Auteur original
Les noms et adresses e-mail de l'Auteur original du contenu du message sont conservés.
RFC5322.Reply-To : Défini par - Médiateur ou Auteur original
Bien que problématique, il est courant qu'une Liste de Diffusion attribue ses propres adresses au champ d'en-tête Reply-To: des messages qu'elle publie. Cette attribution vise à garantir que les réponses vont à tous les membres de la liste, plutôt qu'à l'Auteur original seul. En tant qu'Acteur Utilisateur, une Liste de Diffusion est l'Auteur du nouveau message et peut légitimement définir la valeur Reply-To:. En tant que Médiateur tentant de représenter le message au nom de son Auteur original, la création ou la modification d'un champ Reply-To: peut être considérée comme une violation de l'intention de cet Auteur. Lorsque le Reply-To est modifié de cette manière, une réponse destinée uniquement à l'Auteur original ira plutôt à toute la liste. Lorsque la Liste de Diffusion ne définit pas le champ, une réponse destinée à toute la liste peut au contraire aller uniquement à l'Auteur original. Au mieux, chaque choix est une question de culture de groupe pour la liste particulière.
RFC5322.Sender : Défini par - Expéditeur de l'Auteur ou Expéditeur du Médiateur
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 d'une manière similaire à un simple relais MTA préservent autant que possible les informations de traitement d'origine, y compris le champ RFC5322.Sender original. (Notez que ce mode de fonctionnement fait que la Liste de Diffusion se comporte beaucoup comme un Alias, avec une différence possible dans le nombre de nouveaux destinataires.)
RFC5322.To/.CC : Défini par - Auteur original
Ces champs contiennent généralement la liste originale des adresses des Destinataires.
RFC5321.MailFrom : Défini par - Expéditeur Médiateur
Parce qu'une Liste de Diffusion peut modifier le contenu d'un message de quelque manière que ce soit, elle est responsable de ce contenu ; c'est-à-dire qu'elle est un Auteur. En tant que tel, l'Adresse de Retour est spécifiée par la Liste de Diffusion. Bien qu'il soit plausible pour la Liste de Diffusion de réutiliser l'Adresse de Retour employée par l'Expéditeur original, les notifications envoyées à cette adresse après qu'un message a été traité par une Liste de Diffusion pourraient être problématiques.
5.4. Passerelles (Gateways)
Une Passerelle effectue le travail de routage et de transfert de base du relais de messages, mais elle est également autorisée à modifier le contenu, la structure, l'adresse ou les attributs selon les besoins pour envoyer le message dans un environnement de messagerie qui fonctionne selon des normes différentes ou des politiques potentiellement incompatibles. Lorsqu'une Passerelle connecte deux services de messagerie différents, son rôle est facile à identifier et à comprendre. Lorsqu'elle connecte des environnements qui suivent des normes techniques similaires, mais des politiques administratives très différentes, il est facile de considérer une Passerelle simplement comme un MTA.
La distinction critique entre un MTA et une Passerelle est qu'une Passerelle peut apporter des modifications substantielles à un message pour faire correspondre les normes. Dans pratiquement tous les cas, ce mappage entraîne un certain degré de perte sémantique. Le défi de la conception de Passerelle est de minimiser cette perte. Les Passerelles standardisées vers la messagerie Internet sont le fac-similé [RFC4143], la messagerie vocale [RFC3801], et le service de messagerie multimédia (MMS) [RFC4356].
Une Passerelle peut définir n'importe quel champ d'identité disponible pour un MUA. En incluant l'ensemble principal d'informations de message répertorié au début de cette section, ces identités sont généralement pertinentes pour les Passerelles :
RFC5322.From : Défini par - Auteur original
Les noms et adresses de l'Auteur original du contenu du message sont conservés. Comme pour toutes les informations d'adressage originales dans le message, la Passerelle peut traduire les adresses selon les besoins pour continuer à être utiles dans l'environnement cible.
RFC5322.Reply-To : Défini par - Auteur original
Il est préférable qu'une Passerelle conserve ces informations, si elles sont présentes. La capacité d'effectuer une réponse réussie par un Destinataire est un test typique de la fonctionnalité de Passerelle.
RFC5322.Sender : Défini par - Expéditeur de l'Auteur ou Expéditeur du Médiateur
Ce champ peut conserver la valeur originale ou être défini sur une nouvelle adresse.
RFC5322.To/.CC/.BCC : Défini par - Destinataire original
Ces champs conservent généralement leurs adresses d'origine.
RFC5321.MailFrom : Défini par - Expéditeur de l'Auteur ou Expéditeur du Médiateur
L'Acteur responsable du traitement du message peut spécifier une nouvelle adresse pour recevoir les notifications de traitement.
5.5. Filtre de Frontière (Boundary Filter)
Pour appliquer les limites de sécurité, les organisations peuvent soumettre les messages à une analyse de conformité avec leurs politiques de sécurité. Un exemple est la détection de contenu classé comme spam ou virus. Un filtre peut modifier le contenu pour le rendre sûr, par exemple en supprimant le contenu jugé inacceptable. Généralement, ces actions ajoutent du contenu au message qui enregistre les actions.