2. Lexical Analysis of Messages (Analyse lexicale des messages)
2.1. General Description (Description générale)
Au niveau le plus fondamental, un message est une série de caractères. Un message conforme à cette spécification est composé de caractères avec des valeurs comprises entre 1 et 127 et interprétés comme des caractères US-ASCII. Pour plus de commodité, ce document fait parfois référence à cette plage de caractères comme simplement « caractères US-ASCII ».
Note : Cette spécification stipule que les messages sont composés de caractères dans la plage US-ASCII de 1 à 127. Il existe d'autres documents, en particulier la série de documents MIME (RFC 2045, RFC 2046, RFC 2047, RFC 2049, RFC 4288, RFC 4289), qui étendent cette spécification pour permettre des valeurs en dehors de cette plage. La discussion de ces mécanismes n'entre pas dans le cadre de cette spécification.
Les messages sont divisés en lignes de caractères. Une ligne est une série de caractères délimitée par deux caractères - retour chariot et saut de ligne ; c'est-à-dire le caractère retour chariot (CR, Carriage Return) (valeur ASCII 13) immédiatement suivi du caractère saut de ligne (LF, Line Feed) (valeur ASCII 10). (La paire retour chariot/saut de ligne est généralement écrite dans ce document comme « CRLF ».)
Un message se compose de champs d'en-tête (appelés collectivement « la section d'en-tête du message ») suivis facultativement d'un corps. La section d'en-tête est une séquence de lignes de caractères avec une syntaxe spéciale telle que définie dans cette spécification. Le corps est simplement une séquence de caractères qui suit la section d'en-tête et est séparée de la section d'en-tête par une ligne vide (c'est-à-dire une ligne sans rien précédant le CRLF).
Note : Le langage courant et les versions antérieures de cette spécification utilisent le terme « header » pour désigner soit la section d'en-tête entière, soit un champ d'en-tête individuel. Pour éviter toute ambiguïté, ce document n'utilise pas les termes « header » ou « headers » de manière isolée, mais utilise toujours « header field » (champ d'en-tête) pour désigner un champ individuel et « header section » (section d'en-tête) pour désigner l'ensemble de la collection.
Diagramme de structure du message
Message
├── Section d'en-tête (Header Section)
│ ├── From: [email protected] CRLF
│ ├── To: [email protected] CRLF
│ ├── Subject: Hello CRLF
│ └── Date: ... CRLF
├── Ligne vide (Empty Line)
│ └── CRLF
└── Corps (Body)
├── This is the message body. CRLF
└── Second line. CRLF
2.1.1. Line Length Limits (Limites de longueur de ligne)
Cette spécification place deux limites sur le nombre de caractères dans une ligne. Chaque ligne de caractères doit (MUST) comporter au maximum 998 caractères, et devrait (SHOULD) comporter au maximum 78 caractères, hors CRLF.
La limite de 998 caractères existe en raison de limitations dans de nombreuses implémentations qui envoient, reçoivent ou stockent des messages IMF et qui ne peuvent tout simplement pas gérer plus de 998 caractères sur une ligne. Les implémentations de réception feraient bien de gérer un nombre arbitrairement grand de caractères sur une ligne pour des raisons de robustesse. Cependant, il existe tellement d'implémentations qui (conformément aux exigences de transport de RFC 5321) n'acceptent pas les messages avec plus de 1000 caractères incluant CR et LF par ligne, qu'il est important que les implémentations ne créent pas de tels messages.
La recommandation de 78 caractères plus conservatrice vise à accommoder les nombreuses implémentations d'interfaces utilisateur qui affichent ces messages et qui peuvent tronquer ou envelopper de manière catastrophique l'affichage de plus de 78 caractères par ligne, même si ces implémentations ne sont pas conformes à l'intention de cette spécification (et à celle de RFC 5321 si elles causent effectivement une perte d'information). Encore une fois, même si cette limitation est imposée aux messages, il incombe aux implémentations qui affichent les messages de gérer un nombre arbitrairement grand de caractères sur une ligne (certainement au moins jusqu'à la limite de 998 caractères) pour des raisons de robustesse.
Résumé des limites de longueur de ligne :
| Type de limite | Longueur (hors CRLF) | Exigence | Raison |
|---|---|---|---|
| Limite stricte | 998 caractères | doit (MUST) | De nombreuses implémentations ne peuvent pas gérer des lignes plus longues |
| Limite recommandée | 78 caractères | devrait (SHOULD) | Accommoder la troncature d'affichage dans les IU |
Exemples de longueur de ligne :
✅ Conforme à la recommandation (dans les 78 caractères) :
Subject: This is a short subject line
✅ Conforme mais dépasse la recommandation (78-998 caractères) :
Subject: This is a very long subject line that exceeds the recommended 78 character limit but is still within the required 998 character maximum limit
❌ Non conforme (dépasse 998 caractères) :
Subject: [Contenu dépassant 998 caractères...]
2.2. Header Fields (Champs d'en-tête)
Les champs d'en-tête sont des lignes commençant par un nom de champ, suivi d'un deux-points (« : »), suivi d'un corps de champ, et terminé par CRLF. Un nom de champ doit (MUST) être composé de caractères US-ASCII imprimables (c'est-à-dire des caractères ayant des valeurs entre 33 et 126, inclus), à l'exception du deux-points. Un corps de champ peut être composé de caractères US-ASCII imprimables ainsi que des caractères espace (SP, valeur ASCII 32) et tabulation horizontale (HTAB, valeur ASCII 9) (ensemble connus sous le nom de caractères d'espacement, WSP). Un corps de champ ne doit pas (MUST NOT) inclure CR et LF sauf lorsqu'ils sont utilisés dans le « pliage » et le « dépliage », comme décrit à la Section 2.2.3. Tous les corps de champ doivent (MUST) se conformer à la syntaxe décrite aux Sections 3 et 4 de cette spécification.
Format de champ d'en-tête :
Field-Name: Field-BodyCRLF
↑ ↑ ↑ ↑
| | | +--- Terminateur de ligne
| | +---------- Contenu du champ
| +----------------- Délimiteur deux-points
+------------------------- Nom du champ
Exemple :
From: [email protected]
Subject: Meeting Tomorrow
Date: Mon, 20 Dec 2025 10:00:00 +0800
2.2.1. Unstructured Header Field Bodies (Corps de champs d'en-tête non structurés)
Certains corps de champ dans cette spécification sont définis simplement comme « non structurés » (Unstructured) (spécifiés à la Section 3.2.5 comme tout caractère US-ASCII imprimable plus les caractères d'espacement) sans autres restrictions. Ceux-ci sont appelés corps de champs non structurés. Sémantiquement, les corps de champs non structurés doivent simplement être traités comme une seule ligne de caractères sans autre traitement (sauf pour le « pliage » et le « dépliage » décrits à la Section 2.2.3).
Exemples de champs non structurés :
Subject: This is any text I want to write
Comments: Here's a free-form comment
Caractéristiques :
- Contenu libre, tout caractère ASCII imprimable
- Aucune structure syntaxique spécifique requise
- Seul le pliage/dépliage doit être traité
2.2.2. Structured Header Field Bodies (Corps de champs d'en-tête structurés)
Certains corps de champ dans cette spécification ont une syntaxe plus restrictive que les corps de champs non structurés décrits ci-dessus. Ceux-ci sont appelés corps de champs « structurés ». Les corps de champs structurés sont des séquences de jetons lexicaux spécifiques décrits aux Sections 3 et 4 de cette spécification. Beaucoup de ces jetons sont autorisés (selon leur syntaxe) à être introduits ou terminés par des commentaires (comme décrit à la Section 3.2.2) ainsi que des caractères d'espacement, et ces caractères d'espacement sont soumis au « pliage » et au « dépliage » décrits à la Section 2.2.3. L'analyse sémantique des corps de champs structurés est donnée avec leur syntaxe.
Exemples de champs structurés :
From: Alice Smith <[email protected]>
To: [email protected], [email protected]
Date: Mon, 20 Dec 2025 10:00:00 +0800
Caractéristiques :
- Doit suivre des règles syntaxiques strictes
- Contient des jetons lexicaux spécifiques (par ex. adresses e-mail, date-heure)
- Peut inclure des commentaires et des espaces
- Nécessite une analyse selon la syntaxe
Comparaison :
| Type | Rigueur syntaxique | Traitement | Exemples typiques |
|---|---|---|---|
| Non structuré | Souple, texte libre | Comme chaîne entière | Subject, Comments |
| Structuré | Strict, syntaxe spécifique | Analyser par jetons lexicaux | From, To, Date |
2.2.3. Long Header Fields (Champs d'en-tête longs)
Chaque champ d'en-tête est logiquement une seule ligne de caractères comprenant le nom du champ, le deux-points et le corps du champ. Cependant, pour plus de commodité et pour gérer les limitations de 998/78 caractères par ligne, la partie corps du champ d'un champ d'en-tête peut être divisée en une représentation multi-lignes ; c'est ce qu'on appelle le « pliage » (Folding). La règle générale est que partout où cette spécification permet l'espacement pliable (pas simplement les caractères WSP), un CRLF peut être inséré avant tout WSP.
Exemple de pliage :
Champ d'en-tête original :
Subject: This is a test
Peut être représenté comme (plié) :
Subject: This
is a test
Note : Bien que les définitions de corps de champs structurés permettent le pliage partout où l'espacement pliable est autorisé (et même à l'intérieur des jetons lexicaux), le pliage devrait (SHOULD) être limité au placement du CRLF aux points de rupture syntaxique de niveau supérieur. Par exemple, si un corps de champ est défini comme des valeurs séparées par des virgules, il est recommandé que le pliage se produise après la virgule séparant les éléments structurés, plutôt qu'à l'intérieur des éléments eux-mêmes, même si cela est autorisé ailleurs.
Règles de pliage :
- Point d'insertion : Insérer CRLF avant tout WSP (espace ou tabulation)
- Ligne de continuation : La ligne suivante doit commencer par WSP
- Position recommandée : Aux points de rupture syntaxique de haut niveau (par ex. après les virgules)
Exemple de pliage de plusieurs adresses :
Pliage recommandé (après les virgules) :
To: [email protected],
[email protected],
[email protected]
Non recommandé mais légal :
To: [email protected], bob@
example.com, [email protected]
Le dépliage (Unfolding) est le processus inverse de déplacement de cette représentation multi-lignes pliée vers sa représentation en ligne unique. Le dépliage s'effectue en supprimant simplement tout CRLF immédiatement suivi par WSP. Chaque champ d'en-tête doit être traité dans sa forme dépliée pour une évaluation syntaxique et sémantique ultérieure. Un champ d'en-tête déplié n'a pas de restriction de longueur et peut donc être indéterminément long.
Processus de dépliage :
Avant pliage (logique) :
Subject: This is a very long subject line
Après pliage (transmission) :
Subject: This is a
very long subject line
Après dépliage (analyse) :
Subject: This is a very long subject line
Algorithme de dépliage :
1. Identifier : Trouver le motif CRLF + WSP
2. Supprimer : Supprimer CRLF, conserver WSP
3. Résultat : Chaîne en ligne unique continue
2.3. Body (Corps)
Le corps d'un message est simplement des lignes de caractères US-ASCII. Les deux seules limitations sur le corps sont :
- CR et LF doivent (MUST) apparaître ensemble uniquement comme CRLF ; ils ne doivent pas (MUST NOT) apparaître indépendamment dans le corps.
- Les lignes de caractères dans le corps doivent (MUST) être limitées à 998 caractères, et devraient (SHOULD) être limitées à 78 caractères, hors CRLF.
Note : Comme cela a été mentionné, il existe d'autres documents, en particulier les documents MIME (RFC 2045, RFC 2046, RFC 2049, RFC 4288, RFC 4289), qui étendent (et limitent) cette spécification pour permettre différents types de corps de message. Encore une fois, ces mécanismes sont au-delà de la portée de ce document.
Résumé des restrictions du corps :
| Type de restriction | Exigence | Description |
|---|---|---|
| Terminateur de ligne | doit utiliser CRLF (MUST) | CR et LF ne peuvent pas apparaître indépendamment |
| Longueur de ligne (strict) | doit ≤ 998 caractères (MUST) | Hors CRLF |
| Longueur de ligne (recommandé) | devrait ≤ 78 caractères (SHOULD) | Hors CRLF |
Exemple de corps légal :
Hello Bob,CRLF
CRLF
Let's meet tomorrow at 10am.CRLF
CRLF
Best regards,CRLF
Alice CRLF
Exemples de corps illégaux :
❌ Contient CR ou LF indépendant :
Hello BobCR (LF manquant)
LineLF (CR manquant)
❌ Ligne trop longue (dépasse 998 caractères) :
[Texte continu dépassant 998 caractères...]
Résumé du Chapitre 2
Concepts clés
- Jeu de caractères : US-ASCII (1-127)
- Terminateur de ligne : CRLF (CR+LF)
- Structure du message : Section d'en-tête + Ligne vide + Corps
- Longueur de ligne : 998 caractères (MUST), 78 caractères (SHOULD)
Comparaison des types de champs d'en-tête
Champs non structurés Champs structurés
↓ ↓
Subject: Any text From: user@domain
Comments: ... To: user1, user2
Date: Day, DD Mon YYYY
↓ ↓
Traiter comme Analyser par syntaxe
ensemble
Mécanisme de pliage
Champ long Pliage
↓ ↓
To: [email protected], To: [email protected],
[email protected] --> [email protected]
↑ ↑
Ligne unique (logique) Multi-lignes (transmission)
←--- Dépliage ---
Prochaines étapes
Le Chapitre 2 fournit un aperçu lexical des messages. La Section 3 définira les règles syntaxiques ABNF précises pour créer des messages conformes.
Suivant : 3. Syntax (Syntaxe)
Précédent : 1. Introduction