1. Introduction

Au cours de ses trente-cinq années d'histoire, la messagerie Internet a considérablement évolué en termes d'échelle et de complexité, devenant un service d'infrastructure mondial. 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 se distingue par de nombreux opérateurs indépendants, de nombreux composants différents pour fournir un 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. Ces spécifications forment le noyau :

• Simple Mail Transfer Protocol (SMTP) ([RFC0821], [RFC2821], [RFC5321]) déplace un message via Internet.

• Internet Mail Format (IMF) ([RFC0733], [RFC0822], [RFC2822], [RFC5322]) définit un objet message.

• Multipurpose Internet Mail Extensions (MIME) [RFC2045] définit une amélioration de l'objet message qui permet d'utiliser des pièces jointes multimédias.

La collaboration publique sur les activités techniques, opérationnelles et politiques du courrier électronique, y compris celles qui répondent aux défis de l'abus de courrier électronique, a amené un éventail beaucoup plus large de participants dans la communauté technique. Pour collaborer de manière productive sur ce système vaste et complexe, tous les participants doivent travailler à partir d'une vue commune de celui-ci et 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 qu'un autre participant veut dire.

C'est la nécessité de résoudre ces différences qui motive ce document, qui décrit les réalités du système actuel. La messagerie Internet fait l'objet de travaux techniques, opérationnels et politiques continus, et les discussions sont souvent entravées par différents modèles de conception de services de messagerie et différentes significations pour les mêmes termes.

Pour servir de cadre de référence commun nécessaire, ce document décrit l'architecture améliorée de la messagerie Internet, reflétant le service actuel. Le document se concentre sur :

• Capturer les améliorations apportées au modèle de messagerie

• Clarifier les rôles fonctionnels des composants architecturaux

• Clarifier les problèmes liés à l'identité, à travers le service de messagerie

• Définir la terminologie des composants architecturaux et de leurs interactions

1.1. Historique

La première architecture normalisée pour le courrier électronique en réseau spécifiait une simple division entre le monde de l'utilisateur, sous la forme d'agents utilisateurs de messages (MUA), et le monde du transfert, sous la forme du service de traitement de messages (MHS), qui est composé d'agents de transfert de messages (MTA) [RFC1506]. Le MHS accepte un message d'un utilisateur et le livre à un ou plusieurs autres utilisateurs, créant un environnement d'échange virtuel MUA-à-MUA.

Comme le montre la figure 1, cette architecture définit deux couches logiques d'interopérabilité. L'une est directement entre les utilisateurs. L'autre se situe entre les composants le long du chemin de transfert. De plus, il existe une interopérabilité entre les couches, d'abord lorsqu'un message est posté de l'utilisateur au MHS et plus tard lorsqu'il est livré du MHS à l'utilisateur.

Le service opérationnel a évolué, bien que les aspects fondamentaux du service, tels que l'adressage de la boîte aux lettres et le style de format du message, restent remarquablement constants. La distinction originale entre le niveau utilisateur et le niveau transfert demeure, mais avec des élaborations dans chacun. Le terme "Messagerie Internet" est utilisé pour désigner l'ensemble de la collection de composants et de services utilisateur et de transfert.

Pour la messagerie Internet, le terme "de bout en bout" fait généralement référence à un seul envoi et à l'ensemble des livraisons résultant d'un seul transit du MHS. Une exception courante est le dialogue de groupe qui est médiatisé par une liste de diffusion ; dans ce cas, deux envois se produisent avant que les destinataires prévus ne reçoivent le message d'un auteur, comme indiqué à la section 2.1.4. En fait, certaines utilisations du courrier électronique considèrent l'ensemble du service de courrier électronique, y compris l'auteur et le destinataire, comme un composant subordonné. Pour ces services, "de bout en bout" fait référence à des points situés en dehors du service de courrier électronique. Des exemples sont la messagerie vocale par courrier électronique [RFC3801], l'EDI (échange de données informatisé) par courrier électronique [RFC1767] et la télécopie par courrier électronique [RFC4142].

                                     +--------+
                  ++================>| Utilisateur |
                  ||                 +--------+
                  ||                      ^
      +--------+  ||          +--------+  .
      | Utilisateur +==++=========>| Utilisateur |  .
      +---+----+  ||          +--------+  .
          .       ||               ^      .
          .       ||   +--------+  .      .
          .       ++==>| Utilisateur |  .      .
          .            +--------+  .      .
          .                 ^      .      .
          .                 .      .      .
          V                 .      .      .
      +---+-----------------+------+------+---+
      |   .                 .      .      .   |
      |   .................>.      .      .   |
      |   .                        .      .   |
      |   ........................>.      .   |
      |   .                               .   |
      |   ...............................>.   |
      |                                       |
      |   Service de traitement de messages (MHS) |
      +---------------------------------------+

      Légende : === les lignes indiquent des transferts ou
                    rôles principaux (éventuellement indirects)
                ... les lignes indiquent des transferts ou
                    rôles de soutien

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

L'échange de courrier Internet de bout en bout est accompli en utilisant une infrastructure normalisée avec ces composants et caractéristiques :

• Un objet email

• Adressage global

• Une séquence asynchrone de mécanismes de transfert point à point

• Aucune exigence d'arrangement préalable entre les MTA ou entre les auteurs et les destinataires

• Aucune exigence d'arrangement préalable entre les services de transfert point à point sur l'Internet ouvert

• Aucune exigence pour que l'auteur, l'expéditeur ou les destinataires soient en ligne en même temps

La partie de bout en bout du service est l'objet email, appelé un "message". Au sens large, 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 du courrier sur l'Internet ouvert est de permettre l'interopérabilité utilisateur-à-utilisateur et MTA-à-MTA sans arrangement direct préalable entre les autorités administratives indépendantes responsables du traitement d'un message. Tous les participants comptent sur le fait d'avoir les services de base universellement pris en charge et accessibles, soit directement, soit via des passerelles qui agissent comme traducteurs entre la messagerie Internet et les environnements de messagerie conformes à d'autres normes. Compte tenu de l'importance de la spontanéité et de la sérendipité dans les communications interpersonnelles, ne pas exiger un tel arrangement préalable entre les participants est un avantage fondamental de la messagerie Internet et reste une exigence fondamentale pour elle.

Au sein des réseaux localisés à la périphérie de l'Internet public, un arrangement administratif préalable est souvent requis et peut inclure le contrôle d'accès, les contraintes de routage et la configuration du service de requête d'informations. Bien que l'authentification du destinataire ait généralement été requise pour l'accès aux messages depuis le début de la messagerie Internet, ces dernières années, elle a également été requise pour la soumission de messages. Dans ces cas, un serveur valide l'identité du client, que ce soit par des protocoles de sécurité explicites ou par des requêtes d'infrastructure implicites pour identifier les participants "locaux".

1.2. Le rôle de cette architecture

Un service Internet est une intégration de capacités connexes entre deux ou plusieurs nœuds participants. Les capacités sont accomplies sur Internet par un ou plusieurs protocoles. Ce qui relie 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. De ce point de vue logique, un service définit ce qui est fait, une architecture définit où se trouvent les pièces (les unes par rapport aux autres), et un protocole définit comment des capacités particulières sont exécutées.

En tant que telle, une architecture décrira plus formellement un service à un niveau relativement élevé. Un protocole qui met en œuvre une partie d'un service se conformera à l'architecture dans une mesure plus ou moins grande, selon les compromis pragmatiques qu'ils font lorsqu'ils essaient de mettre en œuvre l'architecture dans le contexte des contraintes du monde réel. Ne pas suivre précisément une architecture n'est pas un échec du protocole, et ne pas mouler précisément un protocole n'est pas un échec de l'architecture. Lorsqu'un protocole diffère de l'architecture, il sera bien sûr approprié pour lui d'expliquer la raison de la variance. Cependant, une telle variance n'est pas une marque contre un protocole : heureusement, l'IETF préfère le code en cours d'exécution à la pureté architecturale.

Dans ce cas particulier, cette architecture tente de définir les composants logiques du courrier électronique Internet et le fait a posteriori, en essayant de capturer les principes architecturaux que les protocoles de courrier électronique actuels incarnent. À des degrés divers, les protocoles de courrier électronique se conformeront à cette architecture plus ou moins bien. Dans la mesure où cette architecture diffère de ces protocoles, les raisons sont généralement bien comprises et sont nécessaires pour l'interopérabilité. Les différences ne sont pas un signe que les protocoles doivent être corrigés. Cependant, cette architecture est une meilleure tentative de modèle logique de courrier électronique Internet, et dans la mesure où le développement de nouveaux protocoles diffère de cette architecture, il est nécessaire que les concepteurs comprennent ces différences et les expliquent soigneusement.

1.3. Conventions du document

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

Lorsqu'ils apparaissent sans le qualificatif IMF (RFC 5322), les noms de champs d'en-tête sont affichés avec un suffixe deux-points. Par exemple, From:.

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