RFC 5598 - Internet Mail Architecture

Statut: Informational
Publié: July 2009
Stream: IETF
Errata: Pas d'errata

Status of This Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Ce mémo fournit des informations à la communauté Internet. Il ne spécifie aucune norme Internet d'aucune sorte. La distribution de ce mémo est illimitée.

Copyright Notice

Abstract

Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service.

Au cours de ses trente-cinq ans d'histoire, le courrier Internet a considérablement changé d'échelle et de complexité, devenant un service d'infrastructure mondial. Ces changements ont été évolutifs plutôt que révolutionnaires, reflétant une forte volonté de préserver à la fois sa base installée et son utilité. 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. Pour servir de cadre de référence commun nécessaire, ce document décrit l'architecture de courrier Internet améliorée, reflétant le service actuel.

1. Introduction

The underlying technical standards for Internet Mail comprise a rich array of functional capabilities. These specifications form the core:

Les normes techniques sous-jacentes pour le courrier Internet comprennent un riche éventail de capacités fonctionnelles. Ces spécifications forment le noyau :

Simple Mail Transfer Protocol (SMTP) ([RFC0821], [RFC2821], [RFC5321]) moves a message through the Internet.
Le protocole simple de transfert de courrier (SMTP) ([RFC0821], [RFC2821], [RFC5321]) déplace un message à travers Internet.
Internet Mail Format (IMF) ([RFC0733], [RFC0822], [RFC2822], [RFC5322]) defines a message object.
Le format de courrier Internet (IMF) ([RFC0733], [RFC0822], [RFC2822], [RFC5322]) définit un objet de message.
Multipurpose Internet Mail Extensions (MIME) [RFC2045] defines an enhancement to the message object that permits using multimedia attachments.
Les extensions de courrier Internet polyvalentes (MIME) [RFC2045] définissent une amélioration de l'objet de message qui permet d'utiliser des pièces jointes multimédias.

Public collaboration on technical, operations, and policy activities of email, including those that respond to the challenges of email abuse, has brought a much wider range of participants into the technical community. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means.

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.

It is the need to resolve these differences that motivates this document, which describes the realities of the current system. Internet Mail is the subject of ongoing technical, operations, and policy work, and the discussions often are hindered by different models of email-service design and different meanings for the same terms.

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. Le courrier 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 courrier électronique et différentes significations pour les mêmes termes.

To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. The document focuses on:

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

Capturing refinements to the email model
Capturer les améliorations apportées au modèle de courrier électronique
Clarifying functional roles for the architectural components
Clarifier les rôles fonctionnels des composants architecturaux
Clarifying identity-related issues, across the email service
Clarifier les problèmes liés à l'identité, à travers le service de courrier électronique
Defining terminology for architectural components and their interactions
Définir la terminologie pour les composants architecturaux et leurs interactions

1.1. History

The first standardized architecture for networked email specified a simple split between the user world, in the form of Message User Agents (MUAs), and the transfer world, in the form of the Message Handling Service (MHS), which is composed of Message Transfer Agents (MTAs) [RFC1506]. The MHS accepts a message from one User and delivers it to one or more other Users, creating a virtual MUA-to-MUA exchange environment.

La première architecture normalisée pour le courrier électronique en réseau spécifiait une simple division entre le monde des utilisateurs, sous la forme d'agents utilisateurs de messages (MUA), et le monde du transfert, sous la forme du service de traitement des 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.

As shown in Figure 1, this architecture defines two logical layers of interoperability. One is directly between Users. The other is among the components along the transfer path. In addition, there is interoperability between the layers, first when a message is posted from the User to the MHS and later when it is delivered from the MHS to the User.

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 est parmi 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é par l'utilisateur vers le MHS et plus tard lorsqu'il est livré par le MHS à l'utilisateur.

The operational service has evolved, although core aspects of the service, such as mailbox addressing and message format style, remain remarkably constant. The original distinction between the user level and transfer level remains, but with elaborations in each. The term "Internet Mail" is used to refer to the entire collection of user and transfer components and services.

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 des messages, restent remarquablement constants. La distinction originale entre le niveau utilisateur et le niveau transfert demeure, mais avec des élaborations dans chacun. Le terme "courrier Internet" est utilisé pour désigner l'ensemble de la collection de composants et de services utilisateur et de transfert.

For Internet Mail, the term "end-to-end" usually refers to a single posting and the set of deliveries that result from a single transit of the MHS. A common exception is group dialogue that is mediated through a Mailing List; in this case, two postings occur before intended Recipients receive an Author's message, as discussed in Section 2.1.4. In fact, some uses of email consider the entire email service, including Author and Recipient, as a subordinate component. For these services, "end-to-end" refers to points outside the email service. Examples are voicemail over email [RFC3801], EDI (Electronic Data Interchange) over email [RFC1767], and facsimile over email [RFC4142].

Pour le courrier 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 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é dans 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. Les 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].

                                         +--------+
                      ++================>|  User  |
                      ||                 +--------+
                      ||                      ^
          +--------+  ||          +--------+  .
          |  User  +==++=========>|  User  |  .
          +---+----+  ||          +--------+  .
              .       ||               ^      .
              .       ||   +--------+  .      .
              .       ++==>|  User  |  .      .
              .            +--------+  .      .
              .                 ^      .      .
              .                 .      .      .
              V                 .      .      .
          +---+-----------------+------+------+---+
          |   .                 .      .      .   |
          |   .................>.      .      .   |
          |   .                        .      .   |
          |   ........................>.      .   |
          |   .                               .   |
          |   ...............................>.   |
          |                                       |
          |     Message Handling Service (MHS)    |
          +---------------------------------------+

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

                Figure 1: Basic Internet Mail Service Model

End-to-end Internet Mail exchange is accomplished by using a standardized infrastructure with these components and characteristics:

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

An email object
Un objet de courrier électronique
Global addressing
Adressage mondial
An asynchronous sequence of point-to-point transfer mechanisms
Une séquence asynchrone de mécanismes de transfert point à point
No requirement for prior arrangement between MTAs or between Authors and Recipients
Aucune exigence d'arrangement préalable entre les MTA ou entre les auteurs et les destinataires
No requirement for prior arrangement between point-to-point transfer services over the open Internet
Aucune exigence d'arrangement préalable entre les services de transfert point à point sur l'Internet ouvert
No requirement for Author, Originator, or Recipients to be online at the same time
Aucune exigence pour que l'auteur, l'expéditeur ou les destinataires soient en ligne en même temps

The end-to-end portion of the service is the email object, called a "message". Broadly, the message itself distinguishes control information, for handling, from the Author's content.

La partie de bout en bout du service est l'objet de courrier électronique, appelé "message". Au sens large, le message lui-même distingue les informations de contrôle, pour le traitement, du contenu de l'auteur.

A precept to the design of mail over the open Internet is permitting User-to-User and MTA-to-MTA interoperability without prior, direct arrangement between the independent administrative authorities responsible for handling a message. All participants rely on having the core services universally supported and accessible, either directly or through Gateways that act as translators between Internet Mail and email environments conforming to other standards. Given the importance of spontaneity and serendipity in interpersonal communications, not requiring such prearrangement between participants is a core benefit of Internet Mail and remains a core requirement for it.

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 que les services de base soient universellement pris en charge et accessibles, soit directement, soit par l'intermédiaire de passerelles qui agissent comme traducteurs entre le courrier Internet et les environnements de courrier électronique 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 du courrier Internet et reste une exigence fondamentale pour celui-ci.

Within localized networks at the edge of the public Internet, prior administrative arrangement often is required and can include access control, routing constraints, and configuration of the information query service. Although Recipient authentication has usually been required for message access since the beginning of Internet Mail, in recent years it also has been required for message submission. In these cases, a server validates the client's identity, whether by explicit security protocols or by implicit infrastructure queries to identify "local" participants.

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 du courrier 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. The Role of This Architecture

An Internet service is an integration of related capabilities among two or more participating nodes. The capabilities are accomplished across the Internet by one or more protocols. What connects a protocol to a service is an architecture. An architecture specifies how the protocols implement the service by defining the logical components of a service and the relationships among them. From that logical view, a service defines what is being done, an architecture defines where the pieces are (in relation to each other), and a protocol defines how particular capabilities are performed.

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.

As such, an architecture will more formally describe a service at a relatively high level. A protocol that implements some portion of a service will conform to the architecture to a greater or lesser extent, depending on the pragmatic tradeoffs they make when trying to implement the architecture in the context of real-world constraints. Failure to precisely follow an architecture is not a failure of the protocol, nor is failure to precisely cast a protocol a failure of the architecture. Where a protocol varies from the architecture, it will of course be appropriate for it to explain the reason for the variance. However, such variance is not a mark against a protocol: Happily, the IETF prefers running code to architectural purity.

En tant que tel, 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 plus ou moins grande mesure, en fonction des compromis pragmatiques qu'ils font lorsqu'ils tentent de mettre en œuvre l'architecture dans le contexte des contraintes du monde réel. Le fait de ne pas suivre précisément une architecture n'est pas un échec du protocole, et le fait de ne pas définir précisément un protocole n'est pas un échec de l'architecture. Lorsqu'un protocole s'écarte de l'architecture, il sera bien sûr approprié pour lui d'expliquer la raison de cet écart. Cependant, un tel écart n'est pas une marque contre un protocole : Heureusement, l'IETF préfère le code en cours d'exécution à la pureté architecturale.

In this particular case, this architecture attempts to define the logical components of Internet email and does so post hoc, trying to capture the architectural principles that the current email protocols embody. To different extents, email protocols will conform to this architecture more or less well. Insofar as this architecture differs from those protocols, the reasons are generally well understood and are required for interoperation. The differences are not a sign that protocols need to be fixed. However, this architecture is a best attempt at a logical model of Internet email, and insofar as new protocol development varies from this architecture, it is necessary for designers to understand those differences and explain them carefully.

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. Dans différentes mesures, les protocoles de courrier électronique se conformeront 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 requises 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 varie par rapport à cette architecture, il est nécessaire que les concepteurs comprennent ces différences et les expliquent soigneusement.

1.3. Document Conventions

References to structured fields of a message use a two-part dotted notation. The first part cites the document that contains the specification for the field, and the second part is the name of the field. Hence <RFC5322.From> is the IMF From: header field in an email content header, and <RFC5321.MailFrom> is the address in the SMTP "Mail From" command.

Les références aux champs structurés d'un message utilisent une notation par points 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. Par conséquent, <RFC5322.From> est le champ d'en-tête IMF From: dans un en-tête de contenu de courrier électronique, et <RFC5321.MailFrom> est l'adresse dans la commande SMTP "Mail From".

When occurring without the IMF (RFC 5322) qualifier, header field names are shown with a colon suffix. For example, From:.

Lorsqu'ils se produisent 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:.

References to labels for actors, functions or components have the first letter capitalized.

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

4. Services and Standards

The Internet Mail architecture comprises six basic types of functionality, which are arranged to support a store-and-forward service. As shown in Figure 5, each type can have multiple instances, some of which represent specialized roles. This section considers the activities and relationships among these components, and the Internet Mail standards that apply to them.

L'architecture de la messagerie Internet comprend six types de fonctionnalités de base, qui sont organisées pour prendre en charge un service de stockage et de retransmission. 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
Message
Message User Agent (MUA)
Agent utilisateur de message (MUA)
- Author MUA (aMUA)
- MUA auteur (aMUA)
- Recipient MUA (rMUA)
- MUA destinataire (rMUA)
Message Submission Agent (MSA)
Agent de soumission de message (MSA)
- Author-focused MSA functions (aMSA)
- Fonctions MSA axées sur l'auteur (aMSA)
- MHS-focused MSA functions (hMSA)
- Fonctions MSA axées sur le MHS (hMSA)
Message Transfer Agent (MTA)
Agent de transfert de message (MTA)
Message Delivery Agent (MDA)
Agent de distribution de message (MDA)
- Recipient-focused MDA functions (rMDA)
- Fonctions MDA axées sur le destinataire (rMDA)
- MHS-focused MDA functions (hMDA)
- Fonctions MDA axées sur le MHS (hMDA)
Message Store (MS)
Stockage de messages (MS)
- Author MS (aMS)
- MS auteur (aMS)
- Recipient MS (rMS)
- MS destinataire (rMS)

This figure shows function modules and the standardized protocols used between them.

Cette figure montre les modules de fonction et les protocoles normalisé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   ++...........................       .
              ||          ++...................................
              ++==========++

Legend: --- lines indicate primary (possibly indirect)
            transfers or roles
        === boxes indicate data objects
        ... lines indicate supporting transfers or roles
        *** lines indicate aggregated service

                 Figure 5: Protocols and Services

4.1. Message Data

4.1. Données de message

The purpose of the Message Handling System (MHS) is to exchange an IMF message object among participants [RFC5322]. All of its underlying mechanisms serve to deliver that message from its Author to its Recipients. A message can be explicitly labeled as to its nature [RFC3458].

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

A message comprises a transit-handling envelope and the message content. The envelope contains information used by the MHS. The content is divided into a structured header and the body. The header comprises transit-handling trace information and structured fields that are part of the Author's message content. The body can be unstructured lines of text or a tree of multimedia subordinate objects, called "body-parts" or, popularly, "attachments". [RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289], [RFC2049].

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 structuré et le corps. 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 » ou, communément, « pièces jointes ». [RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289], [RFC2049].

In addition, Internet Mail has a few conventions for special control data, notably:

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

Delivery Status Notification (DSN):

A Delivery Status Notification (DSN) is a message that can be generated by the MHS (MSA, MTA, or MDA) and sent to the RFC5321.MailFrom address. MDA and MTA are shown as sources of DSNs in Figure 5, and the destination is shown as Returns. DSNs provide information about message transit, such as transfer errors or successful delivery [RFC3461].

Notification d'état de remise (DSN) :

Une notification d'état de remise (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 Retours. Les DSN fournissent des informations sur le transit des messages, telles que les erreurs de transfert ou la réussite de la remise [RFC3461].

Message Disposition Notification (MDN):

A Message Disposition Notification (MDN) is a message that provides information about post-delivery processing, such as indicating that the message has been displayed [RFC3798] or the form of content that can be supported [RFC3297]. It can be generated by an rMUA and is sent to the Disposition-Notification-To addresses. The mailbox for this is shown as Disp in Figure 5.

Notification de disposition de message (MDN) :

Une notification de disposition de message (MDN) est un message qui fournit des informations sur le traitement après remise, comme l'indication que le message a été affiché [RFC3798] ou la forme de contenu qui peut être prise en charge [RFC3297]. Elle peut être générée par un rMUA et est envoyée aux adresses Disposition-Notification-To. La boîte aux lettres pour cela est indiquée comme Disp dans la figure 5.

Message Filtering (SIEVE):

Sieve is a scripting language used to specify conditions for differential handling of mail, typically at the time of delivery [RFC5228]. Scripts can be conveyed in a variety of ways, such as a MIME part in a message. Figure 5 shows a Sieve script going from the rMUA to the MDA. However, filtering can be done at many different points along the transit path, and any one or more of them might be subject to Sieve directives, especially within a single ADMD. Figure 5 shows only one relationship, for (relative) simplicity.

Filtrage des 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 remise [RFC5228]. Les scripts peuvent être transmis de diverses manières, par exemple sous la forme d'une 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 n'importe lequel d'entre eux peut être soumis à des directives Sieve, en particulier au sein d'un seul ADMD. La figure 5 ne montre qu'une seule relation, pour des raisons de simplicité (relative).

4.1.1. Envelope

4.1.1. Enveloppe

Internet Mail has a fragmented framework for transit-related handling information. Information that is used directly by the MHS is called the "envelope". It directs handling activities by the transfer service and is carried in transfer-service commands. That is, the envelope exists in the transfer protocol SMTP [RFC5321].

La messagerie Internet dispose d'un cadre fragmenté pour les informations de traitement liées au transit. Les informations 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. Autrement dit, l'enveloppe existe dans le protocole de transfert SMTP [RFC5321].

Trace information, such as RFC5322.Received, is recorded in the message header and is not subsequently altered [RFC5322].

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

4.1.2. Header Fields

4.1.2. Champs d'en-tête

Header fields are attribute name/value pairs that cover an extensible range of email-service parameters, structured user content, and user transaction meta-information. The core set of header fields is defined in [RFC5322]. It is common practice to extend this set for different applications. Procedures for registering header fields are defined in [RFC3864]. An extensive set of existing header field registrations is provided in [RFC4021].

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].

One danger of placing additional information in header fields is that Gateways often alter or delete them.

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. Body

4.1.3. Corps

The body of a message might be lines of ASCII text or a hierarchically structured composition of multimedia body part attachments using MIME ([RFC2045], [RFC2046], [RFC2047], [RFC4288], and [RFC2049]).

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

4.1.4. Identity References in a Message

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

Table 1 lists the core identifiers present in a message during transit.

Le tableau 1 répertorie les identifiants principaux présents dans un message pendant le transit.

Layer	Field	Set By
Message Body	MIME Header	Author
Message header fields	From:	Author
	Sender:	Originator
	Reply-To:	Author
	To:, CC:, BCC:	Author
	Message-ID:	Originator
	Received:	Originator, Relay, Receiver
	Return-Path:	MDA, from MailFrom
	Resent-*:	Mediator
	List-Id:	Mediator
	List-*:	Mediator
SMTP	HELO/EHLO	Latest Relay Client
	ENVID	Originator
	MailFrom	Originator
	RcptTo	Author
	ORCPT	Originator
IP	Source Address	Latest Relay Client

Couche	Champ	Défini par
Corps du message	En-tête MIME	Auteur
Champs d'en-tête de message	From:	Auteur
	Sender:	Originateur
	Reply-To:	Auteur
	To:, CC:, BCC:	Auteur
	Message-ID:	Originateur
	Received:	Originateur, Relais, Récepteur
	Return-Path:	MDA, de MailFrom
	Resent-*:	Médiateur
	List-Id:	Médiateur
	List-*:	Médiateur
SMTP	HELO/EHLO	Dernier client relais
	ENVID	Originateur
	MailFrom	Originateur
	RcptTo	Auteur
	ORCPT	Originateur
IP	Adresse source	Dernier client relais

Legend:

Layer - The part of the email architecture that uses the identifier.
Field - The protocol construct that contains the identifier.
Set By - The Actor role responsible for specifying the identifier value (and this can be different from the Actor that performs the fill-in function for the protocol construct).

Légende :

Couche - La partie de l'architecture de messagerie qui utilise l'identifiant.
Champ - La construction de protocole qui contient l'identifiant.
Défini par - Le rôle d'acteur responsable de la spécification de la valeur de l'identifiant (et cela peut être différent de l'acteur qui exécute la fonction de remplissage pour la construction de protocole).

Table 1: Layered Identities

Tableau 1 : Identités superposées

These are the most common address-related fields:

Voici les champs liés aux adresses les plus courants :

RFC5322.From: Set by - Author

Names and addresses for Authors of the message content are listed in the From: field.

RFC5322.From: Défini par - Auteur

Les noms et adresses des auteurs du contenu du message sont répertoriés dans le champ From:.

RFC5322.Reply-To: Set by - Author

If a Recipient sends a reply message that would otherwise use the RFC5322.From field addresses in the original message, the addresses in the RFC5322.Reply-To field are used instead. In other words, this field overrides the From: field for responses from Recipients.

RFC5322.Reply-To: Défini par - Auteur

Si un destinataire envoie un message de réponse qui utiliserait autrement les adresses du champ RFC5322.From dans le 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: Set by - Originator

This field specifies the address responsible for submitting the message to the transfer service. This field can be omitted if it contains the same address as RFC5322.From. However, omitting this field does not mean that no Sender is specified; it means that that header field is virtual and that the address in the From: field is to be used.

Specification of the notifications Return Addresses, which are contained in RFC5321.MailFrom, is made by the RFC5322.Sender. Typically, the Return address is the same as the Sender address. However, some usage scenarios require it to be different.

RFC5322.Sender: Défini par - Originateur

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 n'est spécifié ; cela signifie que ce champ d'en-tête est virtuel et que l'adresse dans le champ From: doit être utilisée.

La spécification des adresses de retour des notifications, 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. Cependant, certains scénarios d'utilisation exigent qu'elle soit différente.

RFC5322.To/.CC: Set by - Author

These fields specify MUA Recipient addresses. However, some or all of the addresses in these fields might not be present in the RFC5321.RcptTo commands.

The distinction between To and CC is subjective. Generally, a To addressee is considered primary and is expected to take action on the message. A CC addressee typically receives a copy as a courtesy.

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

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: Set by - Author

A copy of the message might be sent to an addressee whose participation is not to be disclosed to the RFC5322.To or RFC5322.CC Recipients and, usually, not to the other BCC Recipients. The BCC: header field indicates a message copy to such a Recipient. Use of this field is discussed in [RFC5322].

RFC5322.BCC: Défini par - Auteur

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 du message à un tel destinataire. L'utilisation de ce champ est discutée dans [RFC5322].

RFC5321.HELO/.EHLO: Set by - Originator, MSA, MTA

Any SMTP client -- including Originator, MSA, or MTA -- can specify its hosting domain identity for the SMTP HELO or EHLO command operation.

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

Tout client SMTP -- y compris l'originateur, le MSA ou le MTA -- peut spécifier son identité de domaine d'hébergement pour l'opération de commande SMTP HELO ou EHLO.

RFC3461.ENVID: Set by - Originator

The MSA can specify an opaque string, to be included in a DSN, as a means of assisting the Return Address Recipient in identifying the message that produced a DSN or message tracking.

RFC3461.ENVID: Défini par - Originateur

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: Set by - Originator

This field is an end-to-end string that specifies an email address for receiving return control information, such as returned messages. The name of this field is misleading, because it is not required to specify either the Author or the Actor responsible for submitting the message. Rather, the Actor responsible for submission specifies the RFC5321.MailFrom address. Ultimately, the simple basis for deciding which address needs to be in the RFC5321.MailFrom field is to determine which address is to be informed about transfer-level problems (and possibly successes).

RFC5321.MailFrom: Défini par - Originateur

Ce champ est 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 retournés. Le nom de ce champ est trompeur, car il n'est pas nécessaire de spécifier ni l'auteur ni l'acteur responsable de la soumission du message. Au lieu de cela, l'acteur responsable de la soumission 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 de niveau transfert (et éventuellement des succès).

RFC5321.RcptTo: Set by - Author, Final MTA, MDA

This field specifies the MUA mailbox address of a Recipient. The string might not be visible in the message content header. For example, the IMF destination address header fields, such as RFC5322.To, might specify a Mailing List mailbox, while the RFC5321.RcptTo address specifies a member of that list.

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: Set by - Originator.

This is an optional parameter to the RCPT command, indicating the original address to which the current RCPT TO address corresponds, after a mapping was performed during transit. An ORCPT is the only reliable way to correlate a DSN from a multi-Recipient message transfer with the intended Recipient.

RFC5321.ORCPT: Défini par - Originateur.

Il s'agit d'un paramètre facultatif 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 provenant d'un transfert de message multi-destinataire avec le destinataire prévu.

RFC5321.Received: Set by - Originator, Relay, Mediator, Dest

This field contains trace information, including originating host, Relays, Mediators, and MSA host domain names and/or IP Addresses.

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

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

RFC5321.Return-Path: Set by - Originator

The MDA records the RFC5321.MailFrom address into the RFC5321.Return-Path field.

RFC5321.Return-Path: Défini par - Originateur

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

RFC2919.List-Id: Set by - Mediator, Author

This field provides a globally unique Mailing List naming framework that is independent of particular hosts [RFC2919].

The identifier is in the form of a domain name; however, the string usually is constructed by combining the two parts of an email address. The result is rarely a true domain name, listed in the domain name service, although it can be.

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

Ce champ fournit un cadre de nommage de liste de diffusion globalement unique 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-*: Set by - Mediator, Author

[RFC2369] defines a collection of message header fields for use by Mailing Lists. In effect, they supply list-specific parameters for common Mailing-List user operations. The identifiers for these operations are for the list itself and the user-as-subscriber [RFC2369].

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: Set by - The Client SMTP sending host immediately preceding the current receiving SMTP server

[RFC0791] defines the basic unit of data transfer for the Internet: the IP datagram. It contains a Source Address field that specifies the IP Address for the host (interface) from which the datagram was sent. This information is set and provided by the IP layer, which makes it independent of mail-level mechanisms. As such, it is often taken to be authoritative, although it is possible to provide false addresses.

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 de niveau messagerie. 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. User-Level Services

4.2. Services au niveau utilisateur

Interactions at the user level entail protocol exchanges, distinct from those that occur at lower layers of the Internet Mail MHS architecture that is, in turn, above the Internet Transport layer. Because the motivation for email, and much of its use, is for interaction among people, the nature and details of these protocol exchanges often are determined by the needs of interpersonal and group communication. To accommodate the idiosyncratic behavior inherent in such communication, only subjective guidelines, rather than strict rules, can be offered for some aspects of system behavior. Mailing Lists provide particularly salient examples.

Les interactions au niveau utilisateur impliquent des échanges de protocoles, distincts de ceux qui se produisent aux couches inférieures de l'architecture MHS de messagerie Internet qui se trouve, à 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 idiosyncratique 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 en fournissent des exemples particulièrement marquants.

4.2.1. Message User Agent (MUA)

4.2.1. Agent utilisateur de message (MUA)

A Message User Agent (MUA) works on behalf of User Actors and User applications. It is their representative within the email service.

Un agent utilisateur de message (MUA) travaille pour le compte des acteurs utilisateurs et des applications utilisateur. Il est leur représentant au sein du service de messagerie.

The Author MUA (aMUA) creates a message and performs initial submission into the transfer infrastructure via a Mail Submission Agent (MSA). It can also perform any creation- and posting-time archiving in its Message Store (aMS). An MUA aMS can organize messages in many different ways. A common model uses aggregations, called "folders"; in IMAP they are called "mailboxes". This model allows a folder for messages under development (Drafts), a folder for messages waiting to be sent (Queued or Unsent), and a folder for messages that have been successfully posted for transfer (Sent). But none of these folders is required. For example, IMAP allows drafts to be stored in any folder, so no Drafts folder needs to be present.

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 stockage 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, elles sont appelées « 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.

The Recipient MUA (rMUA) works on behalf of the Recipient to process received mail. This processing includes generating user-level disposition control messages, displaying and disposing of the received message, and closing or expanding the user-communication loop by initiating replies and forwarding new messages.

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 utilisateur, l'affichage et la disposition du message reçu, ainsi que la fermeture ou l'extension de la boucle de communication utilisateur en initiant des réponses et en transférant de nouveaux messages.

NOTE: Although not shown in Figure 5, an MUA itself can have a distributed implementation, such as a "thin" user-interface module on a constrained device such as a smartphone, with most of the MUA functionality running remotely on a more capable server. An example of such an architecture might use IMAP [RFC3501] for most of the interactions between an MUA client and an MUA server. An approach for such scenarios is defined by [RFC4550].

REMARQUE : Bien que cela ne soit pas indiqué 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 performant. 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].

A Mediator is a special class of MUA. It performs message re-posting, as discussed in Section 2.1.

Un médiateur est une classe spéciale de MUA. Il effectue la republication de messages, comme indiqué dans la section 2.1.

An MUA can be automated, on behalf of a User who is not present at the time the MUA is active. One example is a bulk sending service that has a timed-initiation feature. These services are not to be confused with a Mailing List Mediator, since there is no incoming message triggering the activity of the automated service.

Un MUA peut être automatisé, pour le compte 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 dispose d'une fonction de démarrage programmé. Ces services ne doivent pas être confondus avec un médiateur de liste de diffusion, car aucun message entrant ne déclenche l'activité du service automatisé.

A popular and problematic MUA is an automatic responder, such as one that sends out-of-office notices. This behavior might be confused with that of a Mediator, but this MUA is generating a new message. Automatic responders can annoy Users of Mailing Lists unless they follow [RFC3834].

Un MUA populaire et problématique est un répondeur automatique, tel que celui qui envoie des avis d'absence du bureau. Ce comportement peut être confondu avec celui d'un médiateur, mais ce MUA génère un nouveau message. Les répondeurs automatiques peuvent ennuyer les utilisateurs de listes de diffusion à moins qu'ils ne suivent [RFC3834].

The identity fields are relevant to a typical MUA:

RFC5322.From
RFC5322.Reply-To
RFC5322.Sender
RFC5322.To, RFC5322.CC
RFC5322.BCC

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. Message Store (MS)

4.2.2. Stockage de messages (MS)

An MUA can employ a long-term Message Store (MS). Figure 5 depicts an Author's MS (aMS) and a Recipient's MS (rMS). An MS can be located on a remote server or on the same machine as the MUA.

Un MUA peut utiliser un stockage de messages (MS) à long terme. La figure 5 illustre 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.

An MS acquires messages from an MDA either proactively by a local mechanism or even by a standardized mechanism such as SMTP(!), or reactively by using POP or IMAP. The MUA accesses the MS either by a local mechanism or by using POP or IMAP. Using POP for individual message accesses, rather than for bulk transfer, is relatively rare and inefficient.

Un MS acquiert des messages d'un MDA soit de manière proactive par un mécanisme local, soit même par un mécanisme normalisé 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 individuels aux messages, plutôt que pour le transfert en masse, est relativement rare et inefficace.

4.3. MHS-Level Services

4.3. Services au niveau MHS

4.3.1. Mail Submission Agent (MSA)

4.3.1. Agent de soumission de message (MSA)

A Mail Submission Agent (MSA) accepts the message submitted by the aMUA and enforces the policies of the hosting ADMD and the requirements of Internet standards. An MSA represents an unusual functional dichotomy. It represents the interests of the Author (aMUA) during message posting, to facilitate posting success; it also represents the interests of the MHS. In the architecture, these responsibilities are modeled, as shown in Figure 5, by dividing the MSA into two sub-components, aMSA and hMSA, respectively. Transfer of responsibility for a single message, from an Author's environment to the MHS, is called "posting". In Figure 5, it is marked as the (S) transition, within the MSA.

Un agent de soumission de message (MSA) accepte le message soumis par l'aMUA et applique les politiques de l'ADMD hébergeur 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, respectivement aMSA et hMSA. 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.

The hMSA takes transit responsibility for a message that conforms to the relevant Internet standards and to local site policies. It rejects messages that are not in conformance. The MSA performs final message preparation for submission and effects the transfer of responsibility to the MHS, via the hMSA. The amount of preparation depends upon the local implementations. Examples of aMSA tasks include adding header fields, such as Date: and Message-ID:, and modifying portions of the message from local notations to Internet standards, such as expanding an address to its formal IMF representation.

Le hMSA assume la responsabilité du 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'extension d'une adresse à sa représentation formelle IMF.

Historically, standards-based MUA/MSA message postings have used SMTP [RFC5321]. The standard currently preferred is SUBMISSION [RFC4409]. Although SUBMISSION derives from SMTP, it uses a separate TCP port and imposes distinct requirements, such as access authorization.

Historiquement, les publications de messages MUA/MSA basées sur des normes utilisaient SMTP [RFC5321]. La norme actuellement préférée est SUBMISSION [RFC4409]. Bien que SUBMISSION dérive de SMTP, elle utilise un port TCP distinct et impose des exigences distinctes, telles que l'autorisation d'accès.

These identities are relevant to the MSA:

RFC5321.HELO/.EHLO
RFC3461.ENVID
RFC5321.MailFrom
RFC5321.RcptTo
RFC5321.Received
RFC0791.SourceAddr

Ces identités sont pertinentes pour le MSA :

RFC5321.HELO/.EHLO
RFC3461.ENVID
RFC5321.MailFrom
RFC5321.RcptTo
RFC5321.Received
RFC0791.SourceAddr

4.3.2. Message Transfer Agent (MTA)

4.3.2. Agent de transfert de message (MTA)

A Message Transfer Agent (MTA) relays mail for one application-level "hop". It is like a packet switch or IP router in that its job is to make routing assessments and to move the message closer to the Recipients. Of course, email objects are typically much larger than the payload of a packet or datagram, and the end-to-end latencies are typically much higher. Relaying is performed by a sequence of MTAs until the message reaches a destination MDA. Hence, an MTA implements both client and server MTA functionality; it does not change addresses in the envelope or reformulate the editorial content. A change in data form, such as to MIME Content-Transfer-Encoding, is within the purview of an MTA, but removal or replacement of body content is not. An MTA also adds trace information [RFC2505].

Un agent de transfert de message (MTA) relaie le courrier pour un « saut » au niveau de l'application. Il est semblable à 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 volumineux 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 les fonctionnalités MTA client et serveur ; il ne modifie pas les adresses dans l'enveloppe ni ne reformule le contenu éditorial. Un changement de format de données, tel que vers 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: Within a destination ADMD, email-relaying modules can make a variety of changes to the message, prior to delivery. In such cases, these modules are acting as Gateways, rather than MTAs.

REMARQUE : Au sein d'un ADMD de destination, les modules de relais de messagerie peuvent apporter diverses modifications au message, avant la remise. Dans de tels cas, ces modules agissent comme des passerelles, plutôt que comme des MTA.

Internet Mail uses SMTP ([RFC5321], [RFC2821], [RFC0821]) primarily to effect point-to-point transfers between peer MTAs. Other transfer mechanisms include Batch SMTP [RFC2442] and On-Demand Mail Relay (ODMR) SMTP [RFC2645]. As with most network-layer mechanisms, the Internet Mail SMTP supports a basic level of reliability, by virtue of providing for retransmission after a temporary transfer failure. Unlike typical packet switches (and Instant Messaging services), Internet Mail MTAs are expected to store messages in a manner that allows recovery across service interruptions, such as host-system shutdown. The degree of such robustness and persistence by an MTA can vary. The base SMTP specification provides a framework for protocol response codes. An extensible enhancement to this framework is defined in [RFC5248].

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 de manière à permettre la récupération après des interruptions de service, telles que l'arrêt du système hôte. Le degré d'une telle robustesse et 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].

Although quite basic, the dominant routing mechanism for Internet Mail is the DNS MX record [RFC1035], which specifies an MTA through which the queried domain can be reached. This mechanism presumes a public, or at least a common, backbone that permits any attached MTA to connect to any other.

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

MTAs can perform any of these well-established roles:

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

Boundary MTA:

An MTA that is part of an ADMD and interacts with MTAs in other ADMDs. This is also called a Border MTA. There can be different Boundary MTAs, according to the direction of mail-flow.

Outbound MTA: An MTA that relays messages to other ADMDs.

Inbound MTA: An MTA that receives inbound SMTP messages from MTA Relays in other ADMDs, for example, an MTA running on the host listed as the target of an MX record.

MTA de frontière :

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

MTA sortant : Un MTA qui relaie les messages vers d'autres ADMD.

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

Final MTA:

The MTA that transfers a message to the MDA.

MTA final :

Le MTA qui transfère un message au MDA.

These identities are relevant to the MTA:

RFC5321.HELO/.EHLO
RFC3461.ENVID
RFC5321.MailFrom
RFC5321.RcptTo
RFC5322.Received: Set by - Relay Server
RFC0791.SourceAddr

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. Mail Delivery Agent (MDA)

4.3.3. Agent de distribution de message (MDA)

A transfer of responsibility from the MHS to a Recipient's environment (mailbox) is called "delivery". In the architecture, as depicted in Figure 5, delivery takes place within a Mail Delivery Agent (MDA) and is shown as the (D) transition from the MHS-oriented MDA component (hMDA) to the Recipient-oriented MDA component (rMDA).

Un transfert de responsabilité du MHS vers l'environnement d'un destinataire (boîte aux lettres) est appelé « remise ». Dans l'architecture, comme illustré à la figure 5, la remise a lieu au sein d'un agent de distribution 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).

An MDA can provide distinctive, address-based functionality, made possible by its detailed information about the properties of the destination address. This information might also be present elsewhere in the Recipient's ADMD, such as at an organizational border (Boundary) Relay. However, it is required for the MDA, if only because the MDA is required to know where to deliver the message.

Un MDA peut fournir une fonctionnalité distinctive basée sur l'adresse, rendue possible 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, par exemple au niveau d'un relais de frontière organisationnelle (frontière). Cependant, elles sont requises pour le MDA, ne serait-ce que parce que le MDA doit savoir où remettre le message.

Like an MSA, an MDA serves two roles, as depicted in Figure 5. Formal transfer of responsibility, called "delivery", is effected between the two components that embody these roles and is shown as "(D)" in Figure 5. The MHS portion (hMDA) primarily functions as a server SMTP engine. A common additional role is to redirect the message to an alternative address, as specified by the Recipient addressee's preferences. The job of the Recipient portion of the MDA (rMDA) is to perform any delivery actions that the Recipient specifies.

Comme un MSA, un MDA remplit deux rôles, comme illustré à la figure 5. Le transfert formel de responsabilité, appelé « remise », 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 courant consiste à rediriger le message vers une adresse alternative, comme spécifié par les préférences du destinataire. Le travail de la partie destinataire du MDA (rMDA) consiste à effectuer toutes les actions de remise spécifiées par le destinataire.

Transfer into the MDA is accomplished by a normal MTA transfer mechanism. Transfer from an MDA to an MS uses an access protocol, such as POP or IMAP.

Le transfert vers 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: The term "delivery" can refer to the formal, MHS function specified here or to the first time a message is displayed to a Recipient. A simple, practical test for whether the MHS-based definition applies is whether a DSN can be generated.

REMARQUE : Le terme « remise » 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é.

These identities are relevant to the MDA:

Ces identités sont pertinentes pour le MDA :

RFC5321.Return-Path: Set by - Author Originator or Mediator Originator

The MDA records the RFC5321.MailFrom address into the RFC5321.Return-Path field.

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

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

RFC5322.Received: Set by - MDA server

An MDA can record a Received: header field to indicate trace information, including source host and receiving host domain names and/or IP Addresses.

RFC5322.Received: Défini par - Serveur MDA

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

4.4. Transition Modes

4.4. Modes de transition

From the origination site to the point of delivery, Internet Mail usually follows a "push" model. That is, the Actor that holds the message initiates transfer to the next venue, typically with SMTP [RFC5321] or the Local Mail Transfer Protocol (LMTP) [RFC2033]. With a "pull" model, the Actor that holds the message waits for the Actor in the next venue to initiate a request for transfer. Standardized mechanisms for pull-based MHS transfer are ETRN [RFC1985] and ODMR [RFC2645].

Du site d'origine au point de remise, la messagerie Internet suit généralement un modèle « push ». Autrement dit, l'acteur qui détient le message initie le transfert vers le lieu suivant, généralement avec SMTP [RFC5321] ou le protocole de transfert de courrier local (LMTP) [RFC2033]. Avec un modèle « pull », l'acteur qui détient le message attend que l'acteur du lieu suivant initie une demande de transfert. Les mécanismes normalisés pour le transfert MHS basé sur le pull sont ETRN [RFC1985] et ODMR [RFC2645].

After delivery, the Recipient's MUA (or MS) can gain access by having the message pushed to it or by having the receiver of access pull the message, such as by using POP [RFC1939] and IMAP [RFC3501].

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

4.5. Implementation and Operation

4.5. Implémentation et fonctionnement

A discussion of any interesting system architecture often bogs down when architecture and implementation are confused. An architecture defines the conceptual functions of a service, divided into discrete conceptual modules. An implementation of that architecture can combine or separate architectural components, as needed for a particular operational environment. For example, a software system that primarily performs message relaying is an MTA, yet it might also include MDA functionality. That same MTA system might be able to interface with non-Internet email services and thus perform both as an MTA and as a Gateway.

Une discussion sur toute architecture 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 messages 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.

Similarly, implemented modules might be configured to form elaborations of the architecture. An interesting example is a distributed MS. One portion might be a remote server and another might be local to the MUA. As discussed in [RFC1733], there are three operational relationships among such MSs:

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 indiqué dans [RFC1733], il existe trois relations opérationnelles entre ces MS :

Online:

The MS is remote, and messages are accessible only when the MUA is attached to the MS so that the MUA will re-fetch all or part of a message from one session to the next.

En ligne :

Le MS est distant et les messages ne sont accessibles que 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.

Offline:

The MS is local to the User, and messages are completely moved from any remote store, rather than (also) being retained there.

Hors ligne :

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

Disconnected:

An rMS and a uMS are kept synchronized, for all or part of their contents, while they are connected. When they are disconnected, mail can arrive at the rMS and the User can make changes to the uMS. The two stores are re-synchronized when they are reconnected.

Déconnecté :

Un rMS et un uMS sont maintenus synchronisés, pour tout ou partie de leur contenu, pendant 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 stockages sont resynchronisés lorsqu'ils sont reconnectés.

5. Mediators

5. Médiateurs

Basic message transfer from Author to Recipients is accomplished by using an asynchronous store-and-forward communication infrastructure in a sequence of independent transmissions through some number of MTAs. A very different task is a sequence of postings and deliveries through Mediators. A Mediator forwards a message through a re-posting process. The Mediator shares some functionality with basic MTA relaying, but has greater flexibility in both addressing and content than is available to MTAs.

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 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 remises via des 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é en matière d'adressage et de contenu que celle disponible pour les MTA.

This is the core set of message information that is commonly set by all types of Mediators:

Voici l'ensemble principal d'informations de message qui sont couramment définies par tous les types de médiateurs :

RFC5321.HELO/.EHLO: Set by - Mediator Originator
RFC5321.HELO/.EHLO: Défini par - Originateur Médiateur
RFC3461.ENVID: Set by - Mediator Originator
RFC3461.ENVID: Défini par - Originateur Médiateur
RFC5321.RcptTo: Set by - Mediator Author
RFC5321.RcptTo: Défini par - Auteur Médiateur
RFC5321.Received: Set by - Mediator Dest
RFC5321.Received: Défini par - Destinataire Médiateur

The Mediator can record received information to indicate the delivery to the original address and submission to the alias address. The trace of Received: header fields can include everything from original posting, through relaying, to final delivery. Le médiateur peut enregistrer les informations reçues pour indiquer la remise à l'adresse d'origine et la soumission à l'adresse alias. La trace des champs d'en-tête Received: peut inclure tout, de la publication d'origine au relais, jusqu'à la remise finale.

The aspect of a Mediator that distinguishes it from any other MUA creating a message is that a Mediator preserves the integrity and tone of the original message, including the essential aspects of its origination information. The Mediator might also add commentary.

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 d'origine, y compris les aspects essentiels de ses informations d'origine. Le médiateur peut également ajouter des commentaires.

Examples of MUA messages that a Mediator does not create include:

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

New message that forwards an existing message:

Although this action provides a basic template for a class of Mediators, its typical occurrence is not, itself, an example of a Mediator. The new message is viewed as being from the Actor that is doing the forwarding, rather than from the original Author.

A new message encapsulates the original message and is seen as from the new Originator. This Mediator Originator might add commentary and can modify the original message content. Because the forwarded message is a component of the message sent by the new Originator, the new message creates a new dialogue. However, the final Recipient still sees the contained message as from the original Author.

Nouveau message qui transfère 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 soi, 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 d'origine.

Un nouveau message encapsule le message d'origine et est considéré comme provenant du nouvel originateur. Cet originateur médiateur peut ajouter des commentaires et modifier le contenu du message d'origine. Étant donné que le message transféré est un composant du message envoyé par le nouvel originateur, le nouveau message crée un nouveau dialogue. Cependant, le destinataire final voit toujours le message contenu comme provenant de l'auteur d'origine.

Reply:

When a Recipient responds to the Author of a message, the new message is not typically viewed as a forwarding of the original. Its focus is the new content, although it might contain all or part of the material from the original message. The earlier material is merely contextual and secondary. This includes automated replies, such as vacation out-of-office notices, as discussed in Section 4.2.1.

Réponse :

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 d'origine. Le matériel précédent est simplement contextuel et secondaire. Cela inclut les réponses automatisées, telles que les avis d'absence du bureau pour les vacances, comme indiqué dans la section 4.2.1.

Annotation:

The integrity of the original message is usually preserved, but one or more comments about the message are added in a manner that distinguishes commentary from original text. The primary purpose of the new message is to provide commentary from a new Author, similar to a Reply.

Annotation :

L'intégrité du message d'origine est généralement préservée, mais un ou plusieurs commentaires sur le message sont ajoutés de manière à distinguer le commentaire du texte d'origine. Le but principal du nouveau message est de fournir un commentaire d'un nouvel auteur, similaire à une réponse.

The remainder of this section describes common examples of Mediators.

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

5.1. Alias

One function of an MDA is to determine the internal location of a mailbox in order to perform delivery. An Alias is a simple re-addressing facility that provides one or more new Internet Mail addresses, rather than a single, internal one; the message continues through the transfer service, for delivery to one or more alternate addresses. Although typically implemented as part of an MDA, this facility is a Recipient function. It resubmits the message, although all handling information except the envelope Recipient (rfc5321.RcptTo) address is retained. In particular, the Return Address (rfc5321.MailFrom) is unchanged.

Une fonction d'un MDA consiste à déterminer l'emplacement interne d'une boîte aux lettres afin d'effectuer la remise. 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 être remis à 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.

What is distinctive about this forwarding mechanism is how closely it resembles normal MTA store-and-forward relaying. Its only significant difference is that it changes the RFC5321.RcptTo value. Because this change is so small, aliasing can be viewed as a part of the lower-level mail-relaying activity. However, this small change has a large semantic impact: The designated Recipient has chosen a new Recipient.

Ce qui distingue ce mécanisme de transfert, c'est à quel point il ressemble au relais de stockage et de retransmission MTA normal. Sa seule différence significative est qu'il modifie la valeur RFC5321.RcptTo. Étant donné que ce changement est si minime, l'utilisation d'alias peut être considérée comme faisant partie de l'activité de relais de courrier de niveau inférieur. Cependant, ce petit changement a un impact sémantique important : le destinataire désigné a choisi un nouveau destinataire.

NOTE: When the replacement list includes more than one address, the alias is increasingly likely to have delivery problems. Any problem reports go to the original Author, not the administrator of the alias entry. This makes it more difficult to resolve the problem, because the original Author has no knowledge of the Alias mechanism.

REMARQUE : Lorsque la liste de remplacement comprend plus d'une adresse, l'alias est de plus en plus susceptible d'avoir des problèmes de remise. Tous les rapports de problèmes vont à l'auteur d'origine, pas à l'administrateur de l'entrée d'alias. Cela rend la résolution du problème plus difficile, car l'auteur d'origine n'a aucune connaissance du mécanisme d'alias.

Including the core set of message information listed at the beginning of this section, Alias typically changes:

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: Set by - Author

These fields retain their original addresses.

RFC5322.To/.CC/.BCC: Défini par - Auteur

Ces champs conservent leurs adresses d'origine.

RFC5321.MailFrom: Set by - Author

The benefit of retaining the original MailFrom value is to ensure that an Actor related to the originating ADMD knows there has been a delivery problem. On the other hand, the responsibility for handling problems, when transiting from the original Recipient mailbox to the alias mailbox usually lies with that original Recipient, because the Alias mechanism is strictly under that Recipient's control. Retaining the original MailFrom address prevents this.

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 remise. D'un autre côté, la responsabilité de la gestion des problèmes, lors du transit de la boîte aux lettres du destinataire d'origine vers la boîte aux lettres de l'alias, incombe généralement à ce destinataire d'origine, car le mécanisme d'alias est strictement sous le contrôle de ce destinataire. La conservation de l'adresse MailFrom d'origine empêche cela.

5.2. ReSender

5.2. Réexpéditeur

Also called the ReDirector, the ReSender's actions differ from forwarding because the Mediator "splices" a message's addressing information to connect the Author of the original message with the Recipient of the new message. This connection permits them to have direct exchange, using their normal MUA Reply functions, while also recording full reference information about the Recipient who served as a Mediator. Hence, the new Recipient sees the message as being from the original Author, even if the Mediator adds commentary.

Également appelé redirecteur, les actions du réexpéditeur diffèrent du transfert car le médiateur « raccorde » les informations d'adressage d'un message pour connecter l'auteur du message d'origine au destinataire du nouveau message. Cette connexion leur permet d'avoir un échange direct, en utilisant leurs fonctions de réponse MUA normales, 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 d'origine, même si le médiateur ajoute des commentaires.

Including the core set of message information listed at the beginning of this section, these identities are relevant to a resent message:

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 renvoyé :

RFC5322.From: Set by - original Author

Names and addresses for the original Author of the message content are retained. The free-form (display-name) portion of the address might be modified to provide an informal reference to the ReSender.

RFC5322.From: Défini par - Auteur d'origine

Les noms et adresses de l'auteur d'origine du contenu du message sont conservés. La partie de forme libre (nom d'affichage) de l'adresse peut être modifiée pour fournir une référence informelle au réexpéditeur.

RFC5322.Reply-To: Set by - original Author

If this field is present in the original message, it is retained in the resent message.

RFC5322.Reply-To: Défini par - Auteur d'origine

Si ce champ est présent dans le message d'origine, il est conservé dans le message renvoyé.

RFC5322.Sender: Set by - Author's Originator or Mediator Originator

RFC5322.Sender: Défini par - Originateur de l'auteur ou Originateur du médiateur

RFC5322.To/.CC/.BCC: Set by - original Author

These fields specify the original message Recipients.

RFC5322.To/.CC/.BCC: Défini par - Auteur d'origine

Ces champs spécifient les destinataires du message d'origine.

RFC5322.Resent-From: Set by - Mediator Author

This address is of the original Recipient who is redirecting the message. Otherwise, the same rules apply to the Resent-From: field as to an original RFC5322.From field.

RFC5322.Resent-From: Défini par - Auteur médiateur

Cette adresse est celle du destinataire d'origine qui redirige le message. Sinon, les mêmes règles s'appliquent au champ Resent-From: qu'à un champ RFC5322.From d'origine.

RFC5322.Resent-Sender: Set by - Mediator Originator

The address of the Actor responsible for resubmitting the message. As with RFC5322.Sender, this field can be omitted when it contains the same address as RFC5322.Resent-From.

RFC5322.Resent-Sender: Défini par - Originateur médiateur

L'adresse de l'acteur responsable de la resoumission du message. Comme avec RFC5322.Sender, ce champ peut être omis lorsqu'il contient la même adresse que RFC5322.Resent-From.

RFC5322.Resent-To/-CC/-BCC: Set by - Mediator Author

The addresses of the new Recipients who are now able to reply to the original Author.

RFC5322.Resent-To/-CC/-BCC: Défini par - Auteur médiateur

Les adresses des nouveaux destinataires qui peuvent désormais répondre à l'auteur d'origine.

RFC5321.MailFrom: Set by - Mediator Originator

The Actor responsible for resubmission (RFC5322.Resent-Sender) is also responsible for specifying the new MailFrom address.

RFC5321.MailFrom: Défini par - Originateur 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. Mailing Lists

5.3. Listes de diffusion

A Mailing List receives messages as an explicit addressee and then re-posts them to a list of subscribed members. The Mailing List performs a task that can be viewed as an elaboration of the ReSender. In addition to sending the new message to a potentially large number of new Recipients, the Mailing List can modify content, for example, by deleting attachments, converting the format, and adding list-specific comments. Mailing Lists also archive messages posted by Authors. Still the message retains characteristics of being from the original Author.

Une liste de diffusion reçoit des messages en tant que destinataire explicite, puis les republie dans 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 néanmoins les caractéristiques d'être de l'auteur d'origine.

Including the core set of message information listed at the beginning of this section, these identities are relevant to a Mailing List processor when submitting a message:

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: Set by - Mediator Author

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

RFC2369.List-*: Set by - Mediator Author

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

RFC5322.From: Set by - original Author

Names and email addresses for the original Author of the message content are retained.

RFC5322.From: Défini par - Auteur d'origine

Les noms et adresses e-mail de l'auteur d'origine du contenu du message sont conservés.

RFC5322.Reply-To: Set by - Mediator or original Author

Although problematic, it is common for a Mailing List to assign its own addresses to the Reply-To: header field of messages that it posts. This assignment is intended to ensure that replies go to all list members, rather than to only the original Author. As a User Actor, a Mailing List is the Author of the new message and can legitimately set the Reply-To: value. As a Mediator attempting to represent the message on behalf of its original Author, creating or modifying a Reply-To: field can be viewed as violating that Author's intent. When the Reply-To is modified in this way, a reply that is meant only for the original Author will instead go to the entire list. When the Mailing List does not set the field, a reply meant for the entire list can instead go only to the original Author. At best, either choice is a matter of group culture for the particular list.

RFC5322.Reply-To: Défini par - Médiateur ou Auteur d'origine

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 parviennent à tous les membres de la liste, plutôt qu'au seul auteur d'origine. 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 d'origine, 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 champ Reply-To est modifié de cette manière, une réponse destinée uniquement à l'auteur d'origine 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 aller uniquement à l'auteur d'origine. Au mieux, l'un ou l'autre choix est une question de culture de groupe pour la liste particulière.

RFC5322.Sender: Set by - Author Originator or Mediator Originator

This field usually specifies the address of the Actor responsible for Mailing List operations. Mailing Lists that operate in a manner similar to a simple MTA Relay preserve as much of the original handling information as possible, including the original RFC5322.Sender field. (Note that this mode of operation causes the Mailing List to behave much like an Alias, with a possible difference in number of new addressees.)

RFC5322.Sender: Défini par - Originateur de l'auteur ou Originateur du médiateur

Ce champ spécifie généralement l'adresse de l'acteur responsable des opérations de liste de diffusion. Les listes de diffusion qui fonctionnent de manière similaire à un simple relais MTA conservent autant que possible les informations de traitement d'origine, y compris le champ RFC5322.Sender d'origine. (Notez que ce mode de fonctionnement fait que la liste de diffusion se comporte un peu comme un alias, avec une différence possible dans le nombre de nouveaux destinataires.)

RFC5322.To/.CC: Set by - original Author

These fields usually contain the original list of Recipient addresses.

RFC5322.To/.CC: Défini par - Auteur d'origine

Ces champs contiennent généralement la liste d'origine des adresses des destinataires.

RFC5321.MailFrom: Set by - Mediator Originator

Because a Mailing List can modify the content of a message in any way, it is responsible for that content; that is, it is an Author. As such, the Return Address is specified by the Mailing List. Although it is plausible for the Mailing List to reuse the Return Address employed by the original Originator, notifications sent to that address after a message has been processed by a Mailing List could be problematic.

RFC5321.MailFrom: Défini par - Originateur 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 que la liste de diffusion réutilise l'adresse de retour utilisée par l'originateur d'origine, 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. Gateways

5.4. Passerelles

A Gateway performs the basic routing and transfer work of message relaying, but it also is permitted to modify content, structure, address, or attributes as needed to send the message into a messaging environment that operates under different standards or potentially incompatible policies. When a Gateway connects two differing messaging services, its role is easy to identify and understand. When it connects environments that follow similar technical standards, but significantly different administrative policies, it is easy to view a Gateway as merely an MTA.

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 comme un simple MTA.

The critical distinction between an MTA and a Gateway is that a Gateway can make substantive changes to a message to map between the standards. In virtually all cases, this mapping results in some degree of semantic loss. The challenge of Gateway design is to minimize this loss. Standardized Gateways to Internet Mail are facsimile [RFC4143], voicemail [RFC3801], and the Multimedia Messaging Service (MMS) [RFC4356].

La distinction critique entre un MTA et une passerelle est qu'une passerelle peut apporter des modifications substantielles à un message pour effectuer un mappage entre 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 normalisées vers la messagerie Internet sont la télécopie [RFC4143], la messagerie vocale [RFC3801] et le service de messagerie multimédia (MMS) [RFC4356].

A Gateway can set any identity field available to an MUA. Including the core set of message information listed at the beginning of this section, these identities are typically relevant to Gateways:

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: Set by - original Author

Names and addresses for the original Author of the message content are retained. As for all original addressing information in the message, the Gateway can translate addresses as required to continue to be useful in the target environment.

RFC5322.From: Défini par - Auteur d'origine

Les noms et adresses de l'auteur d'origine du contenu du message sont conservés. Comme pour toutes les informations d'adressage d'origine dans le message, la passerelle peut traduire les adresses selon les besoins pour continuer à être utiles dans l'environnement cible.

RFC5322.Reply-To: Set by - original Author

It is best for a Gateway to retain this information, if it is present. The ability to perform a successful reply by a Recipient is a typical test of Gateway functionality.

RFC5322.Reply-To: Défini par - Auteur d'origine

Il est préférable qu'une passerelle conserve ces informations, si elles sont présentes. La capacité d'un destinataire à effectuer une réponse réussie est un test typique de la fonctionnalité de la passerelle.

RFC5322.Sender: Set by - Author Originator or Mediator Originator

This field can retain the original value or can be set to a new address.

RFC5322.Sender: Défini par - Originateur de l'auteur ou Originateur du médiateur

Ce champ peut conserver la valeur d'origine ou peut être défini sur une nouvelle adresse.

RFC5322.To/.CC/.BCC: Set by - original Recipient

These fields usually retain their original addresses.

RFC5322.To/.CC/.BCC: Défini par - Destinataire d'origine

Ces champs conservent généralement leurs adresses d'origine.

RFC5321.MailFrom: Set by - Author Originator or Mediator Originator

The Actor responsible for handling the message can specify a new address to receive handling notices.

RFC5321.MailFrom: Défini par - Originateur de l'auteur ou Originateur du médiateur

L'acteur responsable du traitement du message peut spécifier une nouvelle adresse pour recevoir les avis de traitement.

5.5. Boundary Filter

5.5. Filtre de frontière

To enforce security boundaries, organizations can subject messages to analysis for conformance with its safety policies. An example is detection of content classed as spam or a virus. A filter might alter the content to render it safe, such as by removing content deemed unacceptable. Typically, these actions add content to the message that records the actions.

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. En règle générale, ces actions ajoutent au message du contenu qui enregistre les actions.

6. Considerations

6. Considérations

6.1. Security Considerations

6.1. Considérations de sécurité

This document describes the existing Internet Mail architecture. It introduces no new capabilities. The security considerations of this deployed architecture are documented extensively in the technical specifications referenced by this document. These specifications cover classic security topics, such as authentication and privacy. For example, email-transfer protocols can use standardized mechanisms for operation over authenticated and/or encrypted links, and message content has similar protection standards available. Examples of such mechanisms include SMTP-TLS [RFC3207], SMTP-Auth [RFC4954], OpenPGP [RFC4880], and S/MIME [RFC3851].

Ce document décrit l'architecture de messagerie Internet existante. Il n'introduit aucune nouvelle fonctionnalité. Les considérations de sécurité de cette architecture déployée sont documentées de manière exhaustive dans les spécifications techniques référencées par ce document. Ces spécifications couvrent les sujets de sécurité classiques, tels que l'authentification et la confidentialité. Par exemple, les protocoles de transfert de courrier électronique peuvent utiliser des mécanismes normalisés pour fonctionner sur des liens authentifiés et/ou chiffrés, et le contenu des messages dispose de normes de protection similaires. Des exemples de tels mécanismes incluent SMTP-TLS [RFC3207], SMTP-Auth [RFC4954], OpenPGP [RFC4880] et S/MIME [RFC3851].

The core of the Internet Mail architecture does not impose any security requirements or functions on the end-to-end or hop-by-hop components. For example, it does not require participant authentication and does not attempt to prevent data disclosure.

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

Particular message attributes might expose specific security considerations. For example, the blind carbon copy feature of the architecture invites disclosure concerns, as discussed in Section 7.2 of [RFC5321] and Section 5 of [RFC5322]. Transport of text or non-text content in this architecture has security considerations that are discussed in [RFC5322], [RFC2045], [RFC2046], and [RFC4288]; also, security considerations are present for some of the media types registered with IANA.

Certains attributs de message peuvent exposer des considérations de sécurité spécifiques. Par exemple, la fonctionnalité de copie carbone invisible de l'architecture invite à des problèmes de divulgation, comme indiqué dans la section 7.2 de la [RFC5321] et la section 5 de la [RFC5322]. Le transport de contenu textuel ou non textuel dans cette architecture présente des considérations de sécurité qui sont discutées dans [RFC5322], [RFC2045], [RFC2046] et [RFC4288] ; de plus, des considérations de sécurité sont présentes pour certains des types de médias enregistrés auprès de l'IANA.

Agents that automatically respond to email raise significant security considerations, as discussed in [RFC3834]. Gateway behaviors affect end-to-end security services, as discussed in [RFC2480]. Security considerations for boundary filters are discussed in [RFC5228].

Les agents qui répondent automatiquement aux courriers électroniques soulèvent d'importantes considérations de sécurité, comme indiqué dans la [RFC3834]. Les comportements des passerelles affectent les services de sécurité de bout en bout, comme indiqué dans la [RFC2480]. Les considérations de sécurité pour les filtres de périmètre sont discutées dans la [RFC5228].

See Section 7.1 of [RFC5321] for a discussion of the topic of origination validation. As mentioned in Section 4.1.4, it is common practice for components of this architecture to use the RFC0791.SourceAddr to make policy decisions [RFC2505], although the address can be "spoofed". It is possible to use it without authorization. SMTP and Submission authentication ([RFC4409], [RFC4954]) provide more secure alternatives.

Voir la section 7.1 de la [RFC5321] pour une discussion sur le sujet de la validation de l'origine. Comme mentionné dans la section 4.1.4, il est courant que les composants de cette architecture utilisent 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. L'authentification SMTP et de soumission ([RFC4409], [RFC4954]) offre des alternatives plus sûres.

The discussion of trust boundaries, ADMDs, Actors, roles, and responsibilities in this document highlights the relevance and potential complexity of security factors for operation of an Internet Mail service. The core design of Internet Mail to encourage open and casual exchange of messages has met with scaling challenges, as the population of email participants has grown to include those with problematic practices. For example, spam, as defined in [RFC2505], is a by-product of this architecture. A number of Standards Track or BCP documents on the subject have been issued (see [RFC2505], [RFC5068], and [RFC5235]).

La discussion sur les limites de confiance, les ADMD, les acteurs, les rôles et les responsabilités dans ce document met en évidence la pertinence et la complexité potentielle des facteurs de sécurité pour le fonctionnement d'un service de messagerie Internet. La conception centrale de la messagerie Internet pour encourager l'échange ouvert et occasionnel de messages a rencontré des défis de mise à l'échelle, car la population des participants au courrier électronique a augmenté pour inclure ceux ayant des pratiques problématiques. Par exemple, le spam, tel que défini dans la [RFC2505], est un sous-produit de cette architecture. Un certain nombre de documents Standards Track ou BCP sur le sujet ont été publiés (voir [RFC2505], [RFC5068] et [RFC5235]).

6.2. Internationalization

6.2. Internationalisation

The core Internet email standards are based on the use of US-ASCII -- that is, SMTP [RFC5321] and IMF [RFC5322], as well as their predecessors. They describe the transport and composition of messages as composed strictly of US-ASCII 7-bit encoded characters. The standards have been incrementally enhanced to allow for characters outside of this limited set, while retaining mechanisms for backwards-compatibility. Specifically:

Les normes fondamentales de messagerie Internet sont basées sur l'utilisation de l'US-ASCII -- c'est-à-dire SMTP [RFC5321] et IMF [RFC5322], ainsi que leurs prédécesseurs. Ils décrivent le transport et la composition des messages comme étant composés strictement de caractères codés US-ASCII 7 bits. Les normes ont été progressivement améliorées pour permettre des caractères en dehors de cet ensemble limité, tout en conservant des mécanismes de rétrocompatibilité. Plus précisément :

The MIME specifications ([RFC2045], [RFC2046], [RFC2047], [RFC2049]) allow for the use of coded character sets and character-encoding schemes ("charsets" in MIME terminology) other than US-ASCII. MIME's [RFC2046] allows the textual content of a message to have a label affixed that specifies the charset used in that content. Equally, MIME's [RFC2047] allows the textual content of certain header fields in a message to be similarly labeled. However, since messages might be transported over SMTP implementations only capable of transporting 7-bit encoded characters, MIME's [RFC2045] also provides for "content transfer encoding" so that characters of other charsets can be re-encoded as an overlay to US-ASCII.
Les spécifications MIME ([RFC2045], [RFC2046], [RFC2047], [RFC2049]) permettent l'utilisation de jeux de caractères codés et de schémas de codage de caractères (« charsets » dans la terminologie MIME) autres que l'US-ASCII. La [RFC2046] de MIME permet au contenu textuel d'un message d'avoir une étiquette apposée qui spécifie le jeu de caractères utilisé dans ce contenu. De même, la [RFC2047] de MIME permet au contenu textuel de certains champs d'en-tête d'un message d'être étiqueté de la même manière. Cependant, comme les messages peuvent être transportés sur des implémentations SMTP capables uniquement de transporter des caractères codés sur 7 bits, la [RFC2045] de MIME prévoit également un « codage de transfert de contenu » afin que les caractères d'autres jeux de caractères puissent être ré-encodés comme une superposition à l'US-ASCII.
MIME's [RFC2045] allows for the textual content of a message to be in an 8-bit character-encoding scheme. In order to transport these without re-encoding them, the SMTP specification supports an option [RFC1652] that permits the transport of such textual content. However, the [RFC1652] option does not address the use of 8-bit content in message header fields, and therefore [RFC2047] encoding is still required for those.
La [RFC2045] de MIME permet que le contenu textuel d'un message soit dans un schéma de codage de caractères 8 bits. Afin de les transporter sans les ré-encoder, la spécification SMTP prend en charge une option [RFC1652] qui permet le transport d'un tel contenu textuel. Cependant, l'option [RFC1652] ne traite pas de l'utilisation de contenu 8 bits dans les champs d'en-tête de message, et donc le codage [RFC2047] est toujours requis pour ceux-ci.
A series of experimental protocols on Email Address Internationalization (EAI) have been released that extend SMTP and IMF to allow for 8-bit encoded characters to appear in addresses and other information throughout the header fields of messages. [RFC5335] specifies the format of such message header fields (which encode the characters in UTF-8), and [RFC5336] specifies an SMTP option for the transport of these messages.
Une série de protocoles expérimentaux sur l'internationalisation des adresses électroniques (EAI) a été publiée, étendant SMTP et IMF pour permettre aux caractères codés sur 8 bits d'apparaître dans les adresses et autres informations dans les champs d'en-tête des messages. La [RFC5335] spécifie le format de tels 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.
MIME's [RFC2045] and [RFC2046] allow for the transport of true multimedia material; such material enables internationalization because it is not restricted to any particular language or locale.
La [RFC2045] et la [RFC2046] de MIME permettent le transport de véritable matériel multimédia ; un tel matériel permet l'internationalisation car il n'est restreint à aucune langue ou région particulière.
The formats for Delivery Status Notifications (DSNs -- [RFC3462], [RFC3463], [RFC3464]) and Message Disposition Notifications (MDNs -- [RFC3798]) include both a structured and unstructured representation of the notification. In the event that the unstructured representation is in the wrong language or is otherwise unsuitable for use, this allows an MUA to construct its own appropriately localized representation of notification for display to the User.
Les formats des notifications d'état de remise (DSN -- [RFC3462], [RFC3463], [RFC3464]) et des notifications de disposition de message (MDN -- [RFC3798]) incluent à la fois une représentation structurée et non structurée de la notification. Dans le cas où la représentation non structurée est dans la mauvaise langue ou est autrement inadaptée à l'utilisation, cela permet à un MUA de construire sa propre représentation localisée appropriée de la notification pour l'affichage à l'utilisateur.
POP and IMAP have no difficulties with handling MIME messages, including ones containing 8bit, and therefore are not a source of internationalization issues.
POP et IMAP n'ont aucune difficulté à gérer les messages MIME, y compris ceux contenant des 8 bits, et ne sont donc pas une source de problèmes d'internationalisation.

Hence, the use of UTF-8 is fully established in existing Internet Mail. However, support for long-standing encoding forms is retained and is still used.

Par conséquent, l'utilisation de l'UTF-8 est pleinement établie dans la messagerie Internet existante. Cependant, la prise en charge des formes de codage de longue date est conservée et est toujours utilisée.

7. References

7. Références

7.1. Normative References

7.1. Références normatives

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.

[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.

[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.

[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.

[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998.

[RFC2645] Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses", RFC 2645, August 1999.

[RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.

[RFC3192] Allocchio, C., "Minimal FAX address format in Internet Mail", RFC 3192, October 2001.

[RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content Negotiation for Messaging Services based on Email", RFC 3297, July 2002.

[RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003.

[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.

[RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.

[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.

[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.

[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.

[RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, August 2004.

[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.

[RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME Header Fields", RFC 4021, March 2005.

[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.

[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.

[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.

[RFC4550] Maes, S. and A. Melnikov, "Internet Email to Support Diverse Service Environments (Lemonade) Profile", RFC 4550, June 2006.

[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.

[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, June 2008.

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.

7.2. Informative References

7.2. Références informatives

[RFC0733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, "Standard for the format of ARPA network text messages", RFC 733, November 1977.

[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.

[RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.

[RFC1506] Houttuin, J., "A Tutorial on Gatewaying between X.400 and Internet Mail", RFC 1506, August 1993.

[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.

[RFC1733] Crispin, M., "Distributed Electronic Mail Models in IMAP4", RFC 1733, December 1994.

[RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, March 1995.

[RFC1985] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996.

[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.

[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997.

[RFC2442] Freed, N., Newman, D., and Hoy, M., "The Batch SMTP Media Type", RFC 2442, November 1998.

[RFC2480] Freed, N., "Gateways and MIME Security Multiparts", RFC 2480, January 1999.

[RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999.

[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.

[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.

[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.

[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.

[RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.

[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.

[RFC3885] Allman, E. and T. Hansen, "SMTP Service Extension for Message Tracking", RFC 3885, September 2004.

[RFC4142] Crocker, D. and G. Klyne, "Full-mode Fax Profile for Internet Mail (FFPIM)", RFC 4142, November 2005.

[RFC4143] Toyoda, K. and D. Crocker, "Facsimile Using Internet Mail (IFAX) Service of ENUM", RFC 4143, November 2005.

[RFC4356] Gellens, R., "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail", RFC 4356, January 2006.

[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

[RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.

[RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. Finch, "Email Submission Operations: Access and Accountability Requirements", BCP 134, RFC 5068, November 2007.

[RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest Extensions", RFC 5235, January 2008.

[RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, September 2008.

[RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.

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

Appendix A. Acknowledgments

Annexe A. Remerciements

This work began in 2004 and has evolved through numerous rounds of community review; it derives from a section in an early version of [RFC5068]. Over its 5 years of development, the document has gone through 14 incremental versions, with vigorous community review that produced many substantive changes. Review was performed in the IETF and other email technical venues. Although not a formal activity of the IETF, issues with the document's contents were resolved using the classic style of IETF community open, group decision-making. The document is already cited in other work, such as in IMAP and Sieve specifications and in academic classwork. The step of standardizing is useful to provide a solid and stable reference to the Internet's now-complex email service.

Ce travail a débuté en 2004 et a évolué à travers de nombreuses séries d'examens par la communauté ; il découle d'une section d'une première version de la [RFC5068]. Au cours de ses 5 années de développement, le document a traversé 14 versions incrémentielles, avec un examen vigoureux de la communauté qui a produit de nombreux changements substantiels. L'examen a été effectué à l'IETF et dans d'autres lieux techniques de messagerie. Bien qu'il ne s'agisse pas d'une activité formelle de l'IETF, les problèmes liés au contenu du document ont été résolus en utilisant le style classique de prise de décision de groupe ouverte de la communauté IETF. Le document est déjà cité dans d'autres travaux, tels que dans les spécifications IMAP et Sieve et dans les cours universitaires. L'étape de normalisation est utile pour fournir une référence solide et stable au service de messagerie désormais complexe d'Internet.

Details of the Originator Actor role was greatly clarified during discussions in the IETF's Marid working group.

Les détails du rôle d'acteur expéditeur ont été grandement clarifiés lors des discussions au sein du groupe de travail Marid de l'IETF.

Graham Klyne, Pete Resnick, and Steve Atkins provided thoughtful insight on the framework and details of the original drafts, as did Chris Newman for the final versions, while also serving as cognizant Area Director for the document. Tony Hansen served as document shepherd tout au long du processus IETF.

Graham Klyne, Pete Resnick et Steve Atkins ont fourni des informations réfléchies sur le cadre et les détails des projets originaux, tout comme Chris Newman pour les versions finales, tout en servant également de directeur de zone compétent pour le document. Tony Hansen a servi de berger de document tout au long du processus IETF.

Later reviews and suggestions were provided by 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, and Hans Lachman.

Des examens et suggestions ultérieurs ont été fournis 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.

Diligent early proof-reading was performed by Bruce Lilly. Diligent professional technical editing was provided by Susan Hunziker.

Une relecture diligente précoce a été effectuée par Bruce Lilly. Une édition technique professionnelle diligente a été fournie par Susan Hunziker.

The final stages of development for this document were guided by a design team comprising Alexey Melnikov, Pete Resnick, Carl S. Gutekunst, Jeff Macdonald, Randall Gellens, Tony Hansen, and Tony Finch. Pete Resnick developed the final version of the section on internationalization.

Les étapes finales de développement de ce document ont été guidées par une équipe de conception composée d'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.

Author's Address

Adresse de l'auteur

Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA

Phone: +1.408.246.8253 EMail: [email protected]

Status of This Memo​

Copyright Notice​

Abstract​

1. Introduction​

1.1. History​

1.2. The Role of This Architecture​

1.3. Document Conventions​

4. Services and Standards​

4.1. Message Data​

4.1. Données de message​

4.1.1. Envelope​

4.1.1. Enveloppe​

4.1.2. Header Fields​

4.1.2. Champs d'en-tête​

4.1.3. Body​

4.1.3. Corps​

4.1.4. Identity References in a Message​

4.1.4. Références d'identité dans un message​

4.2. User-Level Services​

4.2. Services au niveau utilisateur​

4.2.1. Message User Agent (MUA)​

4.2.1. Agent utilisateur de message (MUA)​

4.2.2. Message Store (MS)​

4.2.2. Stockage de messages (MS)​

4.3. MHS-Level Services​

4.3. Services au niveau MHS​

4.3.1. Mail Submission Agent (MSA)​

4.3.1. Agent de soumission de message (MSA)​

4.3.2. Message Transfer Agent (MTA)​

4.3.2. Agent de transfert de message (MTA)​

4.3.3. Mail Delivery Agent (MDA)​

4.3.3. Agent de distribution de message (MDA)​

4.4. Transition Modes​

4.4. Modes de transition​

4.5. Implementation and Operation​

4.5. Implémentation et fonctionnement​

5. Mediators​

5. Médiateurs​

5.1. Alias​

5.1. Alias​

5.2. ReSender​

5.2. Réexpéditeur​

5.3. Mailing Lists​

5.3. Listes de diffusion​

5.4. Gateways​

5.4. Passerelles​

5.5. Boundary Filter​

5.5. Filtre de frontière​

6. Considerations​

6. Considérations​

6.1. Security Considerations​

6.1. Considérations de sécurité​

6.2. Internationalization​

6.2. Internationalisation​

7. References​

7. Références​

7.1. Normative References​

7.1. Références normatives​

7.2. Informative References​

7.2. Références informatives​

Appendix A. Acknowledgments​

Annexe A. Remerciements​

Author's Address​

Adresse de l'auteur​

Status of This Memo

Copyright Notice

Abstract

1. Introduction

1.1. History

1.2. The Role of This Architecture

1.3. Document Conventions

4. Services and Standards

4.1. Message Data

4.1. Données de message

4.1.1. Envelope

4.1.1. Enveloppe

4.1.2. Header Fields

4.1.2. Champs d'en-tête

4.1.3. Body

4.1.3. Corps

4.1.4. Identity References in a Message

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

4.2. User-Level Services

4.2. Services au niveau utilisateur

4.2.1. Message User Agent (MUA)

4.2.1. Agent utilisateur de message (MUA)

4.2.2. Message Store (MS)

4.2.2. Stockage de messages (MS)

4.3. MHS-Level Services

4.3. Services au niveau MHS

4.3.1. Mail Submission Agent (MSA)

4.3.1. Agent de soumission de message (MSA)

4.3.2. Message Transfer Agent (MTA)

4.3.2. Agent de transfert de message (MTA)

4.3.3. Mail Delivery Agent (MDA)

4.3.3. Agent de distribution de message (MDA)

4.4. Transition Modes

4.4. Modes de transition

4.5. Implementation and Operation

4.5. Implémentation et fonctionnement

5. Mediators

5. Médiateurs

5.1. Alias

5.1. Alias

5.2. ReSender

5.2. Réexpéditeur

5.3. Mailing Lists

5.3. Listes de diffusion

5.4. Gateways

5.4. Passerelles

5.5. Boundary Filter

5.5. Filtre de frontière

6. Considerations

6. Considérations

6.1. Security Considerations

6.1. Considérations de sécurité

6.2. Internationalization

6.2. Internationalisation

7. References

7. Références

7.1. Normative References

7.1. Références normatives

7.2. Informative References

7.2. Références informatives

Appendix A. Acknowledgments

Annexe A. Remerciements

Author's Address

Adresse de l'auteur