1. Introduction
1.1. Scope (Portée)
Ce document définit le format de message Internet (IMF, Internet Message Format), une syntaxe pour les messages textuels envoyés entre utilisateurs d'ordinateurs, dans le cadre des messages de « courrier électronique ». Cette spécification est une révision de la RFC 2822, qui elle-même a remplacé la RFC 822, la mettant à jour pour refléter les pratiques actuelles et incorporant les changements incrémentaux spécifiés dans d'autres RFC.
Ce document spécifie une syntaxe pour les messages textuels uniquement. En particulier, il ne prévoit pas la transmission d'images, d'audio ou d'autres types de données structurées dans les messages de courrier électronique. Plusieurs extensions ont été publiées, telles que la série de documents MIME (RFC 2045, RFC 2046, RFC 2049), qui décrivent des mécanismes pour transmettre de telles données par courrier électronique.
Dans le contexte du courrier électronique, les messages sont considérés comme ayant une enveloppe et un contenu. L'enveloppe contient les informations nécessaires pour accomplir la transmission et la livraison (voir RFC 5321 pour une discussion sur l'enveloppe). Le contenu comprend l'objet à livrer au destinataire. Cette spécification s'applique uniquement au format et à une partie de la sémantique du contenu du message. Elle ne contient aucune spécification des informations dans l'enveloppe.
Cependant, certains systèmes de messagerie peuvent utiliser des informations du contenu pour créer l'enveloppe. Cette spécification vise à faciliter l'acquisition de telles informations par les programmes.
Cette spécification est destinée à être une définition du format de contenu de message à transmettre entre les systèmes. Bien que certains systèmes de messagerie stockent localement les messages dans ce format (éliminant le besoin de traduction entre formats), d'autres utilisent des formats natifs différents. Le stockage local est en dehors de la portée de cette spécification.
Note : Cette spécification n'est pas destinée à dicter les formats internes utilisés par les sites, les fonctionnalités spécifiques du système de messagerie qu'ils sont censés prendre en charge, ou les caractéristiques des programmes d'interface utilisateur qui créent ou lisent des messages. De plus, ce document ne spécifie pas l'encodage de caractères utilisé pour la transmission ou le stockage.
1.2. Notational Conventions (Conventions de notation)
1.2.1. Requirements Notation (Notation des exigences)
Ce document utilise occasionnellement des termes qui apparaissent en lettres majuscules. Lorsque les termes « MUST », « SHOULD », « RECOMMENDED », « MUST NOT », « SHOULD NOT » et « MAY » apparaissent en majuscules, ils sont utilisés pour indiquer des exigences particulières de cette spécification. Une discussion des significations de ces termes apparaît dans la RFC 2119.
Référence des mots-clés :
| Terme | Signification |
|---|---|
| MUST | doit (Exigence absolue) |
| MUST NOT | ne doit pas (Interdiction absolue) |
| SHOULD | devrait (Forte recommandation) |
| SHOULD NOT | ne devrait pas (Forte non-recommandation) |
| RECOMMENDED | recommandé (Pratique recommandée) |
| MAY | peut (Optionnel) |
1.2.2. Syntactic Notation (Notation syntaxique)
Cette spécification utilise la notation Forme de Backus-Naur Augmentée (ABNF, Augmented Backus-Naur Form) telle que décrite dans la RFC 5234. Les caractères sont spécifiés soit par des valeurs décimales (par exemple, %d65 pour A majuscule, %d97 pour a minuscule) soit par des valeurs littérales insensibles à la casse entre guillemets (par exemple, « A » représente soit A majuscule soit a minuscule).
Bases de l'ABNF :
- Littéraux :
"From:"- insensible à la casse - Valeurs décimales :
%d65- code ASCII 65 (caractère A) - Plages :
%d48-57- chiffres 0-9 - Répétition :
*(zéro ou plus),1*(un ou plus),2*4(2 à 4 fois) - Optionnel :
[OPTIONAL]- éléments entre crochets sont optionnels - Groupement :
()- parenthèses groupent les éléments - Alternatives :
/- choisir un
1.2.3. Structure of This Document (Structure de ce document)
Ce document est organisé en plusieurs sections.
Cette section (Section 1) est une brève introduction au document.
La Section 2 présente la description générale d'un message et de ses parties constituantes. Il s'agit d'un aperçu pour aider le lecteur à comprendre certains des principes généraux utilisés dans les parties ultérieures de ce document. Tout exemple dans cette section ne doit pas (MUST NOT) être considéré comme une spécification formelle de toute partie du message.
La Section 3 spécifie les règles ABNF formelles pour la structure (syntaxe) de chaque partie d'un message et décrit la relation entre ces parties et leur signification (sémantique) dans le contexte des messages. Elle liste les règles réelles (syntaxe) pour la structure de chaque partie d'un message, ainsi que la description et les notes explicatives sur celles-ci (sémantique). Cela inclut à la fois l'analyse syntaxique et sémantique des sous-parties de message ayant une structure spécifique. La syntaxe de la Section 3 représente comment les messages doivent (MUST) être créés. Il y a également des notes dans la Section 3 indiquant si les options dans la syntaxe devraient (SHOULD) être utilisées plutôt que d'autres options.
La Section 2 et la Section 3 décrivent toutes deux des messages qu'il est légal de générer selon cette spécification.
La Section 4 spécifie la syntaxe « obsolète ». Ces éléments de syntaxe obsolète sont référencés dans la Section 3. Les règles de la syntaxe obsolète sont des éléments qui sont apparus dans des versions antérieures de cette spécification ou qui ont été largement utilisés sur Internet, mais qui ne doivent plus être utilisés lors de la génération de messages. Par conséquent, les analyseurs de messages conformes doivent (MUST) interpréter ces éléments. Cependant, puisque les éléments de cette syntaxe ont été déterminés comme étant non interopérables ou causant des problèmes importants pour les destinataires de messages, les créateurs de messages conformes ne doivent pas (MUST NOT) les générer.
La Section 5 détaille les considérations de sécurité lors de l'implémentation de cette spécification.
L'Annexe A liste des exemples de différents types de messages. Ces exemples ne sont pas exhaustifs des types de messages qui apparaissent sur Internet, mais donnent un large aperçu de certaines formes syntaxiques.
L'Annexe B liste les différences entre cette spécification et les spécifications de messages Internet antérieures.
L'Annexe C contient les remerciements.
Résumé des concepts clés
Structure du message
+-------------------------+
| Section d'en-tête | ← Défini par cette spec
| - From: alice@... |
| - To: bob@... |
| - Subject: Hello |
| - Date: ... |
+-------------------------+
| Ligne vide (CRLF) | ← Séparateur requis
+-------------------------+
| Section corps | ← Cette spec (texte brut)
| Hello World! | MIME étend (multimédia)
+-------------------------+
Portée de la spécification
| Contenu | Cette spécification | Autres spécifications |
|---|---|---|
| Format du contenu du message | ✅ Défini | - |
| Transport du message (SMTP) | ❌ Non couvert | RFC 5321 |
| Informations d'enveloppe | ❌ Non couvert | RFC 5321 |
| Contenu multimédia | ❌ Non couvert | RFC 2045-2049 (MIME) |
| Format de stockage local | ❌ Non couvert | Spécifique au système |
| Encodage de caractères | ❌ Non spécifié | Couche de transport |
Relation avec les RFC connexes
RFC 5322 (Cette RFC)
↓ définit
Format de message (IMF)
↓ étendu par
Série MIME (RFC 2045-2049)
↓ transporté par
SMTP (RFC 5321)
Guide de lecture du document
- Compréhension rapide : Lire les Sections 1-2 (Aperçu)
- Spécification d'implémentation : Étudier la Section 3 (Génération de messages)
- Compatibilité héritée : Référencer la Section 4 (Analyse de messages)
- Sécurité : Examiner la Section 5
- Exemples pratiques : Parcourir l'Annexe A
Suivant : 2. Lexical Analysis of Messages (Analyse lexicale des messages)