3. Syntaxe
3.1. Introduction
La syntaxe donnée dans cette section définit la syntaxe légale des messages Internet. Les messages conformes à cette spécification MUST être conformes à la syntaxe de cette section. S'il existe dans cette section des options parmi lesquelles une option SHOULD être générée, cela est indiqué soit dans le texte, soit dans un commentaire adjacent à la syntaxe.
Pour les expressions définies, une brève description de la syntaxe et de son usage est donnée, suivie de la syntaxe en ABNF, puis d'une analyse sémantique. Les jetons primitifs suivants, qui sont utilisés mais par ailleurs non spécifiés, sont tirés des « Core Rules » de [RFC5234], annexe B.1 : CR, LF, CRLF, HTAB, SP, WSP, DQUOTE, DIGIT, ALPHA et VCHAR.
Dans certaines définitions figurent des non-terminaux dont les noms commencent par « obs- ». Ces éléments « obs- » renvoient à des jetons définis dans la syntaxe obsolète à la section 4. Dans tous les cas, ces productions doivent être ignorées aux fins de la génération de messages Internet légaux et MUST NOT être utilisées dans un tel message. Cependant, lors de l'interprétation de messages, ces jetons MUST être honorés comme faisant partie de la syntaxe légale. En ce sens, la section 3 définit une grammaire pour la génération de messages, avec des éléments « obs- » à ignorer, tandis que la section 4 ajoute une grammaire pour l'interprétation des messages.
3.2. Jetons lexicaux
Les règles suivantes servent à définir un analyseur lexical sous-jacent, qui fournit des jetons aux analyseurs de niveau supérieur. Cette section définit les jetons utilisés dans les corps de champs d'en-tête structurés.
Remarque : Les lecteurs de cette spécification doivent accorder une attention particulière à la manière dont ces jetons lexicaux sont utilisés dans la syntaxe de niveau inférieur comme de niveau supérieur plus loin dans le document. En particulier, les jetons d'espacement et les jetons de commentaire définis à la section 3.2.2 sont utilisés dans les jetons de niveau inférieur définis ici, et ces jetons de niveau inférieur sont à leur tour utilisés comme parties des jetons de niveau supérieur définis plus loin. Par conséquent, les espaces blancs et les commentaires peuvent être autorisés dans les jetons de niveau supérieur même s'ils n'apparaissent pas explicitement dans une définition particulière.
3.2.1. Caractères cités
Certains caractères sont réservés à une interprétation spéciale, par exemple pour délimiter des jetons lexicaux. Pour permettre l'utilisation de ces caractères comme données non interprétées, un mécanisme de citation est fourni.
quoted-pair = ("\" (VCHAR / WSP)) / obs-qp
Partout où un quoted-pair apparaît, il doit être interprété comme le caractère seul. Autrement dit, le caractère « \ » qui fait partie d'un quoted-pair est sémantiquement « invisible ».
Remarque : Le caractère « \ » peut apparaître dans un message sans faire partie d'un quoted-pair. Un caractère « \ » qui n'apparaît pas dans un quoted-pair n'est pas sémantiquement invisible. Les seuls endroits de cette spécification où quoted-pair apparaît actuellement sont ccontent, qcontent et obs-dtext à la section 4.
3.2.2. Espaces blancs de pliage et commentaires
Les caractères d'espacement, y compris l'espace utilisé pour le pliage (décrit à la section 2.2.3), peuvent apparaître entre de nombreux éléments des corps de champs d'en-tête. De plus, des chaînes de caractères traitées comme des commentaires peuvent être incluses dans les corps de champs structurés sous forme de caractères entre parenthèses. Ce qui suit définit les constructions d'espacement de pliage (FWS) et de commentaire.
Les chaînes de caractères entre parenthèses sont considérées comme des commentaires tant qu'elles n'apparaissent pas à l'intérieur d'une « quoted-string », comme défini à la section 3.2.4. Les commentaires peuvent s'imbriquer.
Il existe plusieurs endroits dans cette spécification où les commentaires et les FWS peuvent être librement insérés. Pour tenir compte de cette syntaxe, un jeton supplémentaire, « CFWS », est défini pour les endroits où des commentaires et/ou des FWS peuvent apparaître. Cependant, là où CFWS apparaît dans cette spécification, il MUST NOT être inséré de manière à ce qu'une ligne quelconque d'un champ d'en-tête plié soit constituée entièrement de caractères WSP et de rien d'autre.
FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
; Folding white space
ctext = %d33-39 / ; Printable US-ASCII
%d42-91 / ; characters not including
%d93-126 / ; "(", ")", or "\"
obs-ctext
ccontent = ctext / quoted-pair / comment
comment = "(" *([FWS] ccontent) [FWS] ")"
CFWS = (1*([FWS] comment) [FWS]) / FWS
Tout au long de cette spécification, là où FWS (le jeton d'espacement de pliage) apparaît, il indique un endroit où le pliage, comme discuté à la section 2.2.3, peut avoir lieu. Partout où un pliage apparaît dans un message (c'est-à-dire un corps de champ d'en-tête contenant un CRLF suivi d'un WSP quelconque), le dépliage (suppression du CRLF) est effectué avant toute analyse sémantique ultérieure de ce champ d'en-tête conformément à cette spécification. Autrement dit, tout CRLF qui apparaît dans un FWS est sémantiquement « invisible ».
Un commentaire est normalement utilisé dans un corps de champ structuré pour fournir un texte informatif lisible par l'humain. Comme un commentaire peut contenir des FWS, le pliage y est autorisé. Notez également que, comme quoted-pair est autorisé dans un commentaire, les caractères parenthèses et barre oblique inverse peuvent apparaître dans un commentaire, tant qu'ils apparaissent sous forme de quoted-pair. Sémantiquement, les parenthèses englobantes ne font pas partie du commentaire ; le commentaire est ce qui est contenu entre les deux parenthèses. Comme indiqué précédemment, le « \ » de tout quoted-pair et le CRLF de tout FWS apparaissant dans le commentaire sont sémantiquement « invisibles » et ne font donc pas partie du commentaire non plus.
Les suites de FWS, de commentaires ou de CFWS qui apparaissent entre des jetons lexicaux dans un corps de champ structuré sont sémantiquement interprétées comme un seul caractère espace.
3.2.3. Atome
Plusieurs productions des corps de champs d'en-tête structurés sont simplement des chaînes de certains caractères de base. Ces productions sont appelées atomes.
Certains des corps de champs d'en-tête structurés autorisent également le caractère point (« . », valeur ASCII 46) au sein de suites d'atext. Un jeton supplémentaire, « dot-atom », est défini à cette fin.
Remarque : Le jeton « specials » n'apparaît nulle part ailleurs dans cette spécification. Il s'agit simplement des caractères visibles (c'est-à-dire ni de contrôle, ni d'espacement) qui n'apparaissent pas dans atext. Il n'est fourni que parce qu'il est utile aux implémenteurs qui utilisent des outils d'analyse lexicale des messages. Chacun des caractères de specials peut servir à indiquer un point de découpage en jetons lors de l'analyse lexicale.
atext = ALPHA / DIGIT / ; Printable US-ASCII
"!" / "#" / ; characters not including
"$" / "%" / ; specials. Used for atoms.
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
atom = [CFWS] 1*atext [CFWS]
dot-atom-text = 1*atext *("." 1*atext)
dot-atom = [CFWS] dot-atom-text [CFWS]
specials = "(" / ")" / ; Special characters that do
"<" / ">" / ; not appear in atext
"[" / "]" /
":" / ";" /
"@" / "\" /
"," / "." /
DQUOTE
atom et dot-atom sont tous deux interprétés comme une unité unique, comprenant la chaîne de caractères qui les constitue. Sémantiquement, les commentaires et les FWS facultatifs entourant le reste des caractères ne font pas partie de l'atome ; l'atome n'est que la suite de caractères atext d'un atom, ou les caractères atext et « . » d'un dot-atom.
3.2.4. Chaînes citées
Les chaînes de caractères qui comprennent des caractères autres que ceux autorisés dans les atomes peuvent être représentées sous forme de chaîne citée, où les caractères sont entourés de guillemets (DQUOTE, valeur ASCII 34).
qtext = %d33 / ; Printable US-ASCII
%d35-91 / ; characters not including
%d93-126 / ; "\" or the quote character
obs-qtext
qcontent = qtext / quoted-pair
quoted-string = [CFWS]
DQUOTE *([FWS] qcontent) [FWS] DQUOTE
[CFWS]
Une quoted-string est traitée comme une unité. Autrement dit, quoted-string est sémantiquement identique à atom. Comme une quoted-string peut contenir des FWS, le pliage y est autorisé. Notez également que, comme quoted-pair est autorisé dans une quoted-string, les caractères guillemet et barre oblique inverse peuvent apparaître dans une quoted-string tant qu'ils apparaissent sous forme de quoted-pair.
Sémantiquement, ni les CFWS facultatifs situés à l'extérieur des guillemets, ni les guillemets eux-mêmes ne font partie de la quoted-string ; la quoted-string est ce qui est contenu entre les deux guillemets. Comme indiqué précédemment, le « \ » de tout quoted-pair et le CRLF de tout FWS/CFWS apparaissant dans la quoted-string sont sémantiquement « invisibles » et ne font donc pas partie de la quoted-string non plus.
3.2.5. Jetons divers
Trois jetons supplémentaires sont définis : word et phrase pour des combinaisons d'atomes et/ou de quoted-strings, et unstructured pour l'utilisation dans les champs d'en-tête non structurés et à certains endroits des champs d'en-tête structurés.
word = atom / quoted-string
phrase = 1*word / obs-phrase
unstructured = (*([FWS] VCHAR) *WSP) / obs-unstruct
3.3. Spécification de la date et de l'heure
Des valeurs de date et d'heure apparaissent dans plusieurs champs d'en-tête. Cette section spécifie la syntaxe d'une spécification complète de date et d'heure. Bien que l'espacement de pliage soit autorisé dans toute la spécification de date-heure, il est RECOMMENDED d'utiliser un seul espace à chaque endroit où FWS apparaît (qu'il soit obligatoire ou facultatif) ; certaines mises en œuvre plus anciennes n'interpréteront pas correctement des séquences plus longues d'espacement de pliage.
date-time = [ day-of-week "," ] date time [CFWS]
day-of-week = ([FWS] day-name) / obs-day-of-week
day-name = "Mon" / "Tue" / "Wed" / "Thu" /
"Fri" / "Sat" / "Sun"
date = day month year
day = ([FWS] 1*2DIGIT FWS) / obs-day
month = "Jan" / "Feb" / "Mar" / "Apr" /
"May" / "Jun" / "Jul" / "Aug" /
"Sep" / "Oct" / "Nov" / "Dec"
year = (FWS 4*DIGIT FWS) / obs-year
time = time-of-day zone
time-of-day = hour ":" minute [ ":" second ]
hour = 2DIGIT / obs-hour
minute = 2DIGIT / obs-minute
second = 2DIGIT / obs-second
zone = (FWS ( "+" / "-" ) 4DIGIT) / obs-zone
Le jour est le jour numérique du mois. L'année est une année numérique quelconque, 1900 ou ultérieure.
Le time-of-day spécifie le nombre d'heures, de minutes et éventuellement de secondes écoulées depuis minuit à la date indiquée.
La date et le time-of-day SHOULD exprimer l'heure locale.
Le zone spécifie le décalage par rapport au temps universel coordonné (UTC, anciennement appelé « Greenwich Mean Time ») que représentent la date et le time-of-day. Le « + » ou le « - » indique si le time-of-day est en avance (c'est-à-dire à l'est) ou en retard (c'est-à-dire à l'ouest) par rapport au temps universel. Les deux premiers chiffres indiquent le nombre d'heures d'écart par rapport au temps universel, et les deux derniers chiffres indiquent le nombre de minutes supplémentaires d'écart par rapport au temps universel. (Ainsi, +hhmm signifie +(hh * 60 + mm) minutes, et -hhmm signifie -(hh * 60 + mm) minutes.) La forme « +0000 » SHOULD être utilisée pour indiquer un fuseau horaire au temps universel. Bien que « -0000 » indique également le temps universel, il est utilisé pour indiquer que l'heure a été générée sur un système qui peut se trouver dans un fuseau horaire local autre que le temps universel et que la date-heure ne contient aucune information sur le fuseau horaire local.
Une spécification de date-heure MUST être sémantiquement valide. C'est-à-dire que le day-of-week (s'il est inclus) MUST être le jour impliqué par la date, le day-of-month numérique MUST être compris entre 1 et le nombre de jours autorisés pour le mois spécifié (dans l'année spécifiée), le time-of-day MUST être compris entre 00:00:00 et 23:59:60 (le nombre de secondes tenant compte d'une seconde intercalaire ; voir [RFC1305]), et les deux derniers chiffres du zone MUST être compris entre 00 et 59.
3.4. Spécification des adresses
Des adresses apparaissent dans plusieurs champs d'en-tête de message pour indiquer les expéditeurs et les destinataires des messages. Une adresse peut être soit une boîte aux lettres individuelle, soit un groupe de boîtes aux lettres.
address = mailbox / group
mailbox = name-addr / addr-spec
name-addr = [display-name] angle-addr
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] /
obs-angle-addr
group = display-name ":" [group-list] ";" [CFWS]
display-name = phrase
mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
address-list = (address *("," address)) / obs-addr-list
group-list = mailbox-list / CFWS / obs-group-list
Une boîte aux lettres reçoit le courrier. C'est une entité conceptuelle qui ne se rapporte pas nécessairement au stockage de fichiers. Par exemple, certains sites peuvent choisir d'imprimer le courrier sur une imprimante et de livrer la sortie au bureau du destinataire.
Normalement, une boîte aux lettres est composée de deux parties : (1) un nom d'affichage facultatif qui indique le nom du destinataire (qui peut être une personne ou un système) et qui peut être affiché à l'utilisateur d'une application de courrier, et (2) une adresse addr-spec encadrée par des chevrons (« < » et « > »). Il existe une autre forme simple de boîte aux lettres, où l'adresse addr-spec apparaît seule, sans le nom du destinataire ni les chevrons. L'adresse addr-spec Internet est décrite à la section 3.4.1.
Remarque : Certaines mises en œuvre héritées utilisaient la forme simple où l'addr-spec apparaît sans les chevrons, mais incluaient le nom du destinataire entre parenthèses, sous forme de commentaire suivant l'addr-spec. Comme la signification des informations d'un commentaire n'est pas spécifiée, les mises en œuvre SHOULD utiliser la forme complète name-addr de la boîte aux lettres, plutôt que la forme héritée, pour spécifier le nom d'affichage associé à une boîte aux lettres. De plus, comme certaines mises en œuvre héritées interprètent le commentaire, les commentaires SHOULD NOT en général être utilisés dans les champs d'adresse afin d'éviter de dérouter ces mises en œuvre.
Lorsqu'il est souhaitable de traiter plusieurs boîtes aux lettres comme une unité unique (c'est-à-dire dans une liste de diffusion), la construction group peut être utilisée. La construction group permet à l'expéditeur d'indiquer un groupe nommé de destinataires. Pour ce faire, on donne un nom d'affichage pour le groupe, suivi de deux-points, suivi d'une liste séparée par des virgules d'un nombre quelconque de boîtes aux lettres (y compris zéro et un), et se terminant par un point-virgule. Comme la liste de boîtes aux lettres peut être vide, l'utilisation de la construction group est également un moyen simple de communiquer aux destinataires que le message a été envoyé à un ou plusieurs ensembles nommés de destinataires, sans fournir réellement l'adresse de boîte aux lettres individuelle d'aucun de ces destinataires.
3.4.1. Spécification addr-spec
Un addr-spec est un identifiant Internet spécifique qui contient une chaîne interprétée localement, suivie du caractère arobase (« @ », valeur ASCII 64), suivi d'un domaine Internet. La chaîne interprétée localement est soit une quoted-string, soit un dot-atom. Si la chaîne peut être représentée sous forme de dot-atom (c'est-à-dire qu'elle ne contient aucun caractère autre que des caractères atext ou « . » entourés de caractères atext), alors la forme dot-atom SHOULD être utilisée et la forme quoted-string SHOULD NOT être utilisée. Les commentaires et l'espacement de pliage SHOULD NOT être utilisés autour du « @ » dans l'addr-spec.
Remarque : Une syntaxe libérale pour la partie domaine de l'addr-spec est donnée ici. Cependant, la partie domaine contient des informations d'adressage spécifiées par d'autres protocoles et utilisées dans ceux-ci (par exemple, [RFC1034], [RFC1035], [RFC1123], [RFC5321]). Il incombe donc aux mises en œuvre de se conformer à la syntaxe des adresses pour le contexte dans lequel elles sont utilisées.
addr-spec = local-part "@" domain
local-part = dot-atom / quoted-string / obs-local-part
domain = dot-atom / domain-literal / obs-domain
domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
dtext = %d33-90 / ; Printable US-ASCII
%d94-126 / ; characters not including
obs-dtext ; "[", "]", or "\"
La partie domaine identifie le point auquel le courrier est remis. Sous la forme dot-atom, elle est interprétée comme un nom de domaine Internet (soit un nom d'hôte, soit un nom de serveur d'échange de courrier) tel que décrit dans [RFC1034], [RFC1035] et [RFC1123]. Sous la forme domain-literal, le domaine est interprété comme l'adresse Internet littérale de l'hôte particulier. Dans les deux cas, la manière dont l'adressage est utilisé et dont les messages sont transportés vers un hôte particulier est traitée dans des documents distincts, tels que [RFC5321]. Ces mécanismes sortent du champ d'application de ce document.
La partie local-part est une chaîne dépendante du domaine. Dans les adresses, elle est simplement interprétée, sur l'hôte particulier, comme le nom d'une boîte aux lettres particulière.
3.5. Syntaxe globale du message
Un message se compose de champs d'en-tête, éventuellement suivis d'un corps de message. Les lignes d'un message MUST comporter au maximum 998 caractères, CRLF exclu, mais il est RECOMMENDED que les lignes soient limitées à 78 caractères, CRLF exclu. (Voir la section 2.1.1 pour une explication.) Dans un corps de message, bien que tous les caractères énumérés dans la règle text MAY être utilisés, l'utilisation de caractères de contrôle US-ASCII (valeurs 1 à 8, 11, 12 et 14 à 31) est déconseillée, car leur interprétation par les récepteurs aux fins d'affichage n'est pas garantie.
message = (fields / obs-fields)
[CRLF body]
body = (*(*998text CRLF) *998text) / obs-body
text = %d1-9 / ; Characters excluding CR
%d11 / ; and LF
%d12 /
%d14-127
Les champs d'en-tête portent l'essentiel des informations sémantiques et sont définis à la section 3.6. Le corps est simplement une série de lignes de texte qui ne sont pas interprétées aux fins de cette spécification.
3.6. Définitions des champs
Les champs d'en-tête d'un message sont définis ici. Tous les champs d'en-tête ont la même structure syntaxique générale : un nom de champ, suivi de deux-points, suivi du corps du champ. La syntaxe spécifique de chaque champ d'en-tête est définie dans les sections suivantes.
Remarque : Dans la syntaxe ABNF de chaque champ des sections suivantes, chaque nom de champ est suivi des deux-points requis. Cependant, par souci de concision, il arrive que les deux-points ne soient pas mentionnés dans la description textuelle de la syntaxe. Ils n'en sont pas moins obligatoires.
Il est important de noter que l'ordre des champs d'en-tête n'est pas garanti. Ils peuvent apparaître dans n'importe quel ordre et l'on sait qu'ils sont parfois réordonnés lors de leur transport sur l'Internet. Cependant, aux fins de cette spécification, les champs d'en-tête SHOULD NOT être réordonnés lorsqu'un message est transporté ou transformé. Plus important encore, les champs d'en-tête de trace et les champs d'en-tête resent MUST NOT être réordonnés et SHOULD être conservés en blocs ajoutés au début du message. Voir les sections 3.6.6 et 3.6.7 pour plus d'informations.
Les seuls champs d'en-tête obligatoires sont le champ de date d'origine et le ou les champs d'adresse d'origine. Tous les autres champs d'en-tête sont syntaxiquement facultatifs. Plus d'informations figurent dans le tableau suivant cette définition.
fields = *(trace
*optional-field /
*(resent-date /
resent-from /
resent-sender /
resent-to /
resent-cc /
resent-bcc /
resent-msg-id))
*(orig-date /
from /
sender /
reply-to /
to /
cc /
bcc /
message-id /
in-reply-to /
references /
subject /
comments /
keywords /
optional-field)
Le tableau suivant indique les limites du nombre de fois où chaque champ peut apparaître dans la section d'en-tête d'un message, ainsi que toute limitation particulière à l'utilisation de ces champs. Un astérisque (« * ») à côté d'une valeur dans la colonne du minimum ou du maximum indique qu'une restriction particulière figure dans la colonne Notes.
+----------------+--------+------------+----------------------------+
| Field | Min | Max number | Notes |
| | number | | |
+----------------+--------+------------+----------------------------+
| trace | 0 | unlimited | Block prepended - see |
| | | | 3.6.7 |
| resent-date | 0* | unlimited* | One per block, required if |
| | | | other resent fields are |
| | | | present - see 3.6.6 |
| resent-from | 0 | unlimited* | One per block - see 3.6.6 |
| resent-sender | 0* | unlimited* | One per block, MUST occur |
| | | | with multi-address |
| | | | resent-from - see 3.6.6 |
| resent-to | 0 | unlimited* | One per block - see 3.6.6 |
| resent-cc | 0 | unlimited* | One per block - see 3.6.6 |
| resent-bcc | 0 | unlimited* | One per block - see 3.6.6 |
| resent-msg-id | 0 | unlimited* | One per block - see 3.6.6 |
| orig-date | 1 | 1 | |
| from | 1 | 1 | See sender and 3.6.2 |
| sender | 0* | 1 | MUST occur with |
| | | | multi-address from - see |
| | | | 3.6.2 |
| reply-to | 0 | 1 | |
| to | 0 | 1 | |
| cc | 0 | 1 | |
| bcc | 0 | 1 | |
| message-id | 0* | 1 | SHOULD be present - see |
| | | | 3.6.4 |
| in-reply-to | 0* | 1 | SHOULD occur in some |
| | | | replies - see 3.6.4 |
| references | 0* | 1 | SHOULD occur in some |
| | | | replies - see 3.6.4 |
| subject | 0 | 1 | |
| comments | 0 | unlimited | |
| keywords | 0 | unlimited | |
| optional-field | 0 | unlimited | |
+----------------+--------+------------+----------------------------+
L'interprétation exacte de chaque champ est décrite dans les sections suivantes.
3.6.1. Le champ de date d'origine
Le champ de date d'origine se compose du nom de champ « Date » suivi d'une spécification de date-heure.
orig-date = "Date:" date-time CRLF
La date d'origine spécifie la date et l'heure auxquelles le créateur du message a indiqué que le message était complet et prêt à entrer dans le système de remise du courrier. Par exemple, il peut s'agir du moment où un utilisateur appuie sur le bouton « send » ou « submit » d'un programme applicatif. En tout état de cause, elle n'est spécifiquement pas destinée à transmettre l'heure à laquelle le message est effectivement transporté, mais plutôt l'heure à laquelle l'humain ou l'autre créateur du message a mis le message sous sa forme finale, prêt au transport. (Par exemple, un utilisateur d'ordinateur portable qui n'est pas connecté à un réseau peut mettre un message en file d'attente pour la remise. La date d'origine est destinée à contenir la date et l'heure auxquelles l'utilisateur a mis le message en file d'attente, et non l'heure à laquelle l'utilisateur s'est connecté au réseau pour envoyer le message.)
3.6.2. Champs d'origine
Les champs d'origine d'un message se composent du champ from, du champ sender (le cas échéant) et éventuellement du champ reply-to. Le champ from se compose du nom de champ « From » et d'une liste séparée par des virgules d'une ou plusieurs spécifications de boîte aux lettres. Si le champ from contient plus d'une spécification de boîte aux lettres dans la mailbox-list, alors le champ sender, contenant le nom de champ « Sender » et une seule spécification de boîte aux lettres, MUST apparaître dans le message. Dans l'un ou l'autre cas, un champ reply-to facultatif MAY également être inclus, lequel contient le nom de champ « Reply-To » et une liste séparée par des virgules d'une ou plusieurs adresses.
from = "From:" mailbox-list CRLF
sender = "Sender:" mailbox CRLF
reply-to = "Reply-To:" address-list CRLF
Les champs d'origine indiquent la ou les boîtes aux lettres de la source du message. Le champ « From: » spécifie le ou les auteurs du message, c'est-à-dire la ou les boîtes aux lettres de la ou des personnes ou systèmes responsables de la rédaction du message. Le champ « Sender: » spécifie la boîte aux lettres de l'agent responsable de la transmission effective du message. Par exemple, si une secrétaire envoyait un message pour une autre personne, la boîte aux lettres de la secrétaire apparaîtrait dans le champ « Sender: » et la boîte aux lettres de l'auteur réel apparaîtrait dans le champ « From: ». Si l'origine du message peut être indiquée par une seule boîte aux lettres et que l'auteur et le transmetteur sont identiques, le champ « Sender: » SHOULD NOT être utilisé. Sinon, les deux champs SHOULD apparaître.
Remarque : Les informations relatives au transmetteur sont toujours présentes. L'absence du champ « Sender: » est parfois prise à tort comme signifiant que l'agent responsable de la transmission du message n'a pas été spécifié. Cette absence signifie simplement que le transmetteur est identique à l'auteur et n'est donc pas placé de manière redondante dans le champ « Sender: ».
Les champs d'origine fournissent également les informations requises pour répondre à un message. Lorsque le champ « Reply-To: » est présent, il indique la ou les adresses auxquelles l'auteur du message suggère d'envoyer les réponses. En l'absence du champ « Reply-To: », les réponses SHOULD par défaut être envoyées à la ou aux boîtes aux lettres spécifiées dans le champ « From: », sauf indication contraire de la personne qui compose la réponse.
Dans tous les cas, le champ « From: » SHOULD NOT contenir de boîte aux lettres qui n'appartient pas au ou aux auteurs du message. Voir également la section 3.6.3 pour plus d'informations sur la formation des adresses de destination d'une réponse.
3.6.3. Champs d'adresse de destination
Les champs de destination d'un message se composent de trois champs possibles, tous de même forme : le nom de champ, qui est soit « To », soit « Cc », soit « Bcc », suivi d'une liste séparée par des virgules d'une ou plusieurs adresses (syntaxe de boîte aux lettres ou de groupe).
to = "To:" address-list CRLF
cc = "Cc:" address-list CRLF
bcc = "Bcc:" [address-list / CFWS] CRLF
Les champs de destination spécifient les destinataires du message. Chaque champ de destination peut comporter une ou plusieurs adresses, et ces adresses indiquent les destinataires visés par le message. La seule différence entre les trois champs réside dans la manière dont chacun est utilisé.
Le champ « To: » contient la ou les adresses du ou des destinataires principaux du message.
Le champ « Cc: » (où « Cc » signifie « Carbon Copy », au sens de la réalisation d'une copie sur une machine à écrire à l'aide de papier carbone) contient les adresses des autres personnes qui doivent recevoir le message, même si le contenu du message peut ne pas leur être destiné.
Le champ « Bcc: » (où « Bcc » signifie « Blind Carbon Copy ») contient les adresses des destinataires du message dont les adresses ne doivent pas être révélées aux autres destinataires du message. Le champ « Bcc: » s'utilise de trois manières. Dans le premier cas, lorsqu'un message contenant un champ « Bcc: » est préparé pour l'envoi, la ligne « Bcc: » est supprimée alors même que tous les destinataires (y compris ceux spécifiés dans le champ « Bcc: ») reçoivent une copie du message. Dans le second cas, les destinataires spécifiés dans les lignes « To: » et « Cc: » reçoivent chacun une copie du message avec la ligne « Bcc: » supprimée comme ci-dessus, mais les destinataires de la ligne « Bcc: » reçoivent une copie distincte du message contenant une ligne « Bcc: ». (Lorsque le champ « Bcc: » contient plusieurs adresses de destinataires, certaines mises en œuvre envoient en fait une copie distincte du message à chaque destinataire, avec un « Bcc: » ne contenant que l'adresse de ce destinataire particulier.) Enfin, comme un champ « Bcc: » peut ne contenir aucune adresse, un champ « Bcc: » peut être envoyé sans aucune adresse, ce qui indique aux destinataires que des copies invisibles ont été envoyées à quelqu'un. La méthode à utiliser avec les champs « Bcc: » dépend de la mise en œuvre, mais reportez-vous à la section « Considérations de sécurité » de ce document pour une discussion de chacune.
Lorsqu'un message est une réponse à un autre message, les boîtes aux lettres des auteurs du message original (les boîtes aux lettres du champ « From: ») ou les boîtes aux lettres spécifiées dans le champ « Reply-To: » (s'il existe) MAY apparaître dans le champ « To: » de la réponse, puisque celles-ci seraient normalement les destinataires principaux de la réponse. Si une réponse est envoyée à un message qui comporte des champs de destination, il est souvent souhaitable d'envoyer une copie de la réponse à tous les destinataires du message, en plus de l'auteur. Lorsqu'une telle réponse est formée, les adresses des champs « To: » et « Cc: » du message original MAY apparaître dans le champ « Cc: » de la réponse, puisque ce sont normalement les destinataires secondaires de la réponse. Si un champ « Bcc: » est présent dans le message original, les adresses de ce champ MAY apparaître dans le champ « Bcc: » de la réponse, mais elles SHOULD NOT apparaître dans les champs « To: » ou « Cc: ».
Remarque : Certaines applications de courrier disposent de commandes de réponse automatique qui incluent les adresses de destination du message original parmi les adresses de destination de la réponse. Le comportement de ces commandes de réponse dépend de la mise en œuvre et sort du champ d'application de ce document. En particulier, la question de savoir s'il faut ou non inclure les adresses de destination originales lorsque le message original comportait un champ « Reply-To: » n'est pas traitée ici.
3.6.4. Champs d'identification
Bien qu'ils soient indiqués comme facultatifs dans le tableau de la section 3.6, chaque message SHOULD avoir un champ « Message-ID: ». En outre, les messages de réponse SHOULD avoir des champs « In-Reply-To: » et « References: » selon le cas et comme décrit ci-dessous.
Le champ « Message-ID: » contient un identifiant de message unique. Les champs « References: » et « In-Reply-To: » contiennent chacun un ou plusieurs identifiants de message uniques, éventuellement séparés par des CFWS.
La syntaxe de l'identifiant de message (msg-id) est une version limitée de la construction addr-spec, encadrée par les caractères chevrons « < » et « > ». Contrairement à addr-spec, cette syntaxe n'autorise que la forme dot-atom-text du côté gauche du « @ » et ne comporte aucun CFWS interne nulle part dans l'identifiant de message.
Remarque : Comme pour addr-spec, une syntaxe libérale est donnée pour le côté droit du « @ » dans un msg-id. Cependant, plus loin dans cette section, l'utilisation d'un domaine pour le côté droit du « @ » est RECOMMENDED. Là encore, la syntaxe des constructions de domaine est spécifiée par d'autres protocoles et utilisée dans ceux-ci (par exemple, [RFC1034], [RFC1035], [RFC1123], [RFC5321]). Il incombe donc aux mises en œuvre de se conformer à la syntaxe des adresses pour le contexte dans lequel elles sont utilisées.
message-id = "Message-ID:" msg-id CRLF
in-reply-to = "In-Reply-To:" 1*msg-id CRLF
references = "References:" 1*msg-id CRLF
msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS]
id-left = dot-atom-text / obs-id-left
id-right = dot-atom-text / no-fold-literal / obs-id-right
no-fold-literal = "[" *dtext "]"
Le champ « Message-ID: » fournit un identifiant de message unique qui renvoie à une version particulière d'un message particulier. L'unicité de l'identifiant de message est garantie par l'hôte qui le génère (voir ci-dessous). Cet identifiant de message est destiné à être lisible par machine et n'est pas nécessairement significatif pour les humains. Un identifiant de message se rapporte à exactement une version d'un message particulier ; les révisions ultérieures du message reçoivent chacune de nouveaux identifiants de message.
Remarque : Il existe de nombreux cas où des messages sont « modifiés », mais ces modifications ne constituent pas une nouvelle instanciation de ce message et, par conséquent, le message ne reçoit pas de nouvel identifiant de message. Par exemple, lorsque des messages sont introduits dans le système de transport, ils sont souvent précédés de champs d'en-tête supplémentaires tels que les champs de trace (décrits à la section 3.6.7) et les champs resent (décrits à la section 3.6.6). L'ajout de tels champs d'en-tête ne change pas l'identité du message et le champ « Message-ID: » d'origine est donc conservé. Dans tous les cas, c'est la signification que l'expéditeur du message souhaite transmettre (c'est-à-dire s'il s'agit du même message ou d'un message différent) qui détermine si le champ « Message-ID: » change, et non une quelconque différence syntaxique particulière qui apparaît (ou n'apparaît pas) dans le message.
Les champs « In-Reply-To: » et « References: » sont utilisés lors de la création d'une réponse à un message. Ils contiennent l'identifiant de message du message original et les identifiants de message d'autres messages (par exemple, dans le cas d'une réponse à un message qui était lui-même une réponse). Le champ « In-Reply-To: » peut servir à identifier le ou les messages auxquels le nouveau message répond, tandis que le champ « References: » peut servir à identifier un « fil » de conversation.
Lors de la création d'une réponse à un message, les champs « In-Reply-To: » et « References: » du message résultant sont construits comme suit :
Le champ « In-Reply-To: » contiendra le contenu du champ « Message-ID: » du message auquel celui-ci répond (le « message parent »). S'il y a plus d'un message parent, le champ « In-Reply-To: » contiendra le contenu de tous les champs « Message-ID: » des parents. S'il n'y a pas de champ « Message-ID: » dans l'un des messages parents, le nouveau message n'aura pas de champ « In-Reply-To: ».
Le champ « References: » contiendra le contenu du champ « References: » du parent (le cas échéant) suivi du contenu du champ « Message-ID: » du parent (le cas échéant). Si le message parent ne contient pas de champ « References: » mais possède un champ « In-Reply-To: » contenant un seul identifiant de message, alors le champ « References: » contiendra le contenu du champ « In-Reply-To: » du parent suivi du contenu du champ « Message-ID: » du parent (le cas échéant). Si le parent ne possède aucun des champs « References: », « In-Reply-To: » ou « Message-ID: », alors le nouveau message n'aura pas de champ « References: ».
Remarque : Certaines mises en œuvre analysent le champ « References: » pour afficher le « fil de discussion ». Ces mises en œuvre supposent que chaque nouveau message est une réponse à un seul parent et qu'elles peuvent donc remonter le champ « References: » pour trouver le parent de chaque message qui y est listé. Par conséquent, il est déconseillé d'essayer de former un champ « References: » pour une réponse ayant plusieurs parents ; la manière de procéder n'est pas définie dans ce document.
L'identifiant de message (msg-id) lui-même MUST être un identifiant globalement unique pour un message. Le générateur de l'identifiant de message MUST garantir que le msg-id est unique. Plusieurs algorithmes peuvent être utilisés pour y parvenir. Comme le msg-id a une syntaxe similaire à celle d'addr-spec (identique, sauf que les chaînes citées, les commentaires et l'espacement de pliage ne sont pas autorisés), une bonne méthode consiste à placer le nom de domaine (ou une adresse IP littérale de domaine) de l'hôte sur lequel l'identifiant de message a été créé du côté droit du « @ » (les noms de domaine et les adresses IP étant normalement uniques), et à placer une combinaison de la date et de l'heure absolues courantes ainsi que quelque autre identifiant actuellement unique (peut-être séquentiel) disponible sur le système (par exemple, un numéro d'identification de processus) du côté gauche. Bien que d'autres algorithmes fonctionnent, il est RECOMMENDED que le côté droit contienne un identifiant de domaine (soit de l'hôte lui-même, soit autre) tel que le générateur de l'identifiant de message puisse garantir l'unicité du côté gauche dans la portée de ce domaine.
Sémantiquement, les caractères chevrons ne font pas partie du msg-id ; le msg-id est ce qui est contenu entre les deux caractères chevrons.
3.6.5. Champs d'information
Les champs d'information sont tous facultatifs. Les champs « Subject: » et « Comments: » sont des champs non structurés tels que définis à la section 2.2.1, et peuvent donc contenir du texte ou de l'espacement de pliage. Le champ « Keywords: » contient une liste séparée par des virgules d'un ou plusieurs mots ou quoted-strings.
subject = "Subject:" unstructured CRLF
comments = "Comments:" unstructured CRLF
keywords = "Keywords:" phrase *("," phrase) CRLF
Ces trois champs sont destinés à ne contenir qu'un contenu lisible par l'humain comportant des informations sur le message. Le champ « Subject: » est le plus courant et contient une chaîne courte identifiant le sujet du message. Lorsqu'il est utilisé dans une réponse, le corps du champ MAY commencer par la chaîne « Re: » (abréviation du latin « in re », signifiant « au sujet de ») suivie du contenu du corps du champ « Subject: » du message original. Si cela est fait, une seule occurrence de la chaîne littérale « Re: » devrait être utilisée, car l'emploi d'autres chaînes ou de plus d'une occurrence peut conduire à des conséquences indésirables. Le champ « Comments: » contient tout commentaire supplémentaire sur le texte du corps du message. Le champ « Keywords: » contient une liste séparée par des virgules de mots et de phrases importants qui peuvent être utiles au destinataire.
3.6.6. Champs Resent
Les champs resent SHOULD être ajoutés à tout message réintroduit par un utilisateur dans le système de transport. Un ensemble distinct de champs resent SHOULD être ajouté chaque fois que cela se produit. Tous les champs resent correspondant à un renvoi particulier du message SHOULD être regroupés. Chaque nouvel ensemble de champs resent est ajouté au début du message ; c'est-à-dire que l'ensemble le plus récent de champs resent apparaît plus tôt dans le message. Aucun autre champ du message n'est modifié lorsque des champs resent sont ajoutés.
Chacun des champs resent correspond à un champ particulier ailleurs dans la syntaxe. Par exemple, le champ « Resent-Date: » correspond au champ « Date: » et le champ « Resent-To: » correspond au champ « To: ». Dans chaque cas, la syntaxe du corps du champ est identique à la syntaxe donnée précédemment pour le champ correspondant.
Lorsque des champs resent sont utilisés, les champs « Resent-From: » et « Resent-Date: » MUST être envoyés. Le champ « Resent-Message-ID: » SHOULD être envoyé. « Resent-Sender: » SHOULD NOT être utilisé si « Resent-Sender: » serait identique à « Resent-From: ».
resent-date = "Resent-Date:" date-time CRLF
resent-from = "Resent-From:" mailbox-list CRLF
resent-sender = "Resent-Sender:" mailbox CRLF
resent-to = "Resent-To:" address-list CRLF
resent-cc = "Resent-Cc:" address-list CRLF
resent-bcc = "Resent-Bcc:" [address-list / CFWS] CRLF
resent-msg-id = "Resent-Message-ID:" msg-id CRLF
Les champs resent servent à identifier un message comme ayant été réintroduit dans le système de transport par un utilisateur. L'objectif de l'utilisation des champs resent est que le message apparaisse au destinataire final comme s'il avait été envoyé directement par l'expéditeur d'origine, tous les champs d'origine restant identiques. Chaque ensemble de champs resent correspond à un événement de renvoi particulier. Autrement dit, si un message est renvoyé plusieurs fois, chaque ensemble de champs resent fournit des informations d'identification pour chaque fois prise individuellement. Les champs resent sont strictement informatifs. Ils MUST NOT être utilisés dans le traitement normal des réponses ou d'autres actions automatiques de ce type sur les messages.
Remarque : Réintroduire un message dans le système de transport et utiliser des champs resent est une opération différente du « réacheminement ». Le « réacheminement » a deux sens : un premier sens du réacheminement est qu'un utilisateur peut demander à un programme de lecture de courrier de réacheminer une copie d'un message à une autre personne, le message réacheminé constituant le corps du nouveau message. Un message réacheminé en ce sens ne semble pas provenir de l'expéditeur d'origine, mais constitue un message entièrement nouveau de la part de la personne qui le réachemine. Le réacheminement peut aussi signifier qu'un programme de transport de courrier reçoit un message et le réachemine vers une destination différente pour la remise finale. Les champs d'en-tête resent ne sont pas destinés à être utilisés avec l'un ou l'autre de ces deux types de réacheminement.
Les champs d'origine resent indiquent la boîte aux lettres de la ou des personnes ou du ou des systèmes qui ont renvoyé le message. Comme pour les champs d'origine ordinaires, il existe deux formes : une forme simple « Resent-From: », qui contient la boîte aux lettres de la personne qui effectue le renvoi, et la forme plus complexe, où une personne (identifiée dans le champ « Resent-Sender: ») renvoie un message pour le compte d'une ou plusieurs autres personnes (identifiées dans le champ « Resent-From: »).
Remarque : Lorsqu'on répond à un message renvoyé, les réponses se comportent exactement comme avec tout autre message, en utilisant les champs « From: », « Reply-To: », « Message-ID: » et d'autres champs d'origine. Les champs resent sont uniquement informatifs et MUST NOT être utilisés dans le traitement normal des réponses.
Le champ « Resent-Date: » indique la date et l'heure auxquelles le message renvoyé est expédié par la personne qui le renvoie. Comme le champ « Date: », il ne s'agit pas de la date et de l'heure auxquelles le message a été effectivement transporté.
Les champs « Resent-To: », « Resent-Cc: » et « Resent-Bcc: » fonctionnent de manière identique aux champs « To: », « Cc: » et « Bcc: », respectivement, sauf qu'ils indiquent les destinataires du message renvoyé, et non les destinataires du message original.
Le champ « Resent-Message-ID: » fournit un identifiant unique pour le message renvoyé.
3.6.7. Champs de trace
Les champs de trace sont un groupe de champs d'en-tête constitué d'un champ « Return-Path: » facultatif et d'un ou plusieurs champs « Received: ». Le champ d'en-tête « Return-Path: » contient une paire de chevrons qui encadrent un addr-spec facultatif. Le champ « Received: » contient une liste (éventuellement vide) de jetons suivie d'un point-virgule et d'une spécification de date-heure. Chaque jeton doit être un word, un angle-addr, un addr-spec ou un domain. D'autres restrictions sont appliquées à la syntaxe des champs de trace par les spécifications qui prévoient leur utilisation, telles que [RFC5321].
trace = [return]
1*received
return = "Return-Path:" path CRLF
path = angle-addr / ([CFWS] "<" [CFWS] ">" [CFWS])
received = "Received:" *received-token ";" date-time CRLF
received-token = word / angle-addr / addr-spec / domain
Une discussion complète de l'utilisation des champs de trace dans le courrier Internet figure dans [RFC5321]. Aux fins de cette spécification, les champs de trace sont strictement informatifs, et toute interprétation formelle de ceux-ci sort du champ d'application de ce document.
3.6.8. Champs optionnels
Des champs peuvent apparaître dans les messages alors qu'ils ne sont pas spécifiés par ailleurs dans ce document. Ils MUST être conformes à la syntaxe d'un optional-field. Il s'agit d'un nom de champ, constitué des caractères US-ASCII imprimables à l'exception de SP et des deux-points, suivi de deux-points, suivi de tout texte conforme à la syntaxe non structurée.
Les noms de champ de tout champ optionnel MUST NOT être identiques à un nom de champ spécifié ailleurs dans ce document.
optional-field = field-name ":" unstructured CRLF
field-name = 1*ftext
ftext = %d33-57 / ; Printable US-ASCII
%d59-126 ; characters not including
; ":".
Aux fins de cette spécification, tout champ optionnel est non interprété.