2. Lexical Analysis of Messages (Analisi lessicale dei messaggi)
2.1. General Description (Descrizione generale)
Al livello più basilare, un messaggio è una serie di caratteri. Un messaggio conforme a questa specifica è composto da caratteri con valori compresi tra 1 e 127 e interpretati come caratteri US-ASCII. Per comodità, questo documento talvolta si riferisce a questo intervallo di caratteri semplicemente come "caratteri US-ASCII".
Nota: Questa specifica stabilisce che i messaggi sono composti da caratteri nell'intervallo US-ASCII da 1 a 127. Esistono altri documenti, in particolare la serie di documenti MIME (RFC 2045, RFC 2046, RFC 2047, RFC 2049, RFC 4288, RFC 4289), che estendono questa specifica per consentire valori al di fuori di tale intervallo. La discussione di questi meccanismi non rientra nell'ambito di questa specifica.
I messaggi sono divisi in righe di caratteri. Una riga è una serie di caratteri delimitata da due caratteri - ritorno a capo e avanzamento riga; cioè, il carattere di ritorno a capo (CR, Carriage Return) (valore ASCII 13) seguito immediatamente dal carattere di avanzamento riga (LF, Line Feed) (valore ASCII 10). (La coppia ritorno a capo/avanzamento riga è solitamente scritta in questo documento come "CRLF".)
Un messaggio è costituito da campi di intestazione (collettivamente chiamati "la sezione di intestazione del messaggio") seguiti facoltativamente da un corpo. La sezione di intestazione è una sequenza di righe di caratteri con sintassi speciale come definito in questa specifica. Il corpo è semplicemente una sequenza di caratteri che segue la sezione di intestazione ed è separato dalla sezione di intestazione da una riga vuota (cioè, una riga senza nulla che precede il CRLF).
Nota: Il linguaggio comune e le versioni precedenti di questa specifica usano il termine "header" per riferirsi sia all'intera sezione di intestazione che a un singolo campo di intestazione. Per evitare ambiguità, questo documento non usa i termini "header" o "headers" in isolamento, ma usa sempre "header field" (campo di intestazione) per riferirsi a un campo individuale e "header section" (sezione di intestazione) per riferirsi all'intera collezione.
Diagramma della struttura del messaggio
Messaggio (Message)
├── Sezione intestazione (Header Section)
│ ├── From: [email protected] CRLF
│ ├── To: [email protected] CRLF
│ ├── Subject: Hello CRLF
│ └── Date: ... CRLF
├── Riga vuota (Empty Line)
│ └── CRLF
└── Corpo (Body)
├── This is the message body. CRLF
└── Second line. CRLF
2.1.1. Line Length Limits (Limiti di lunghezza della riga)
Questa specifica pone due limiti sul numero di caratteri in una riga. Ogni riga di caratteri deve (MUST) essere di non più di 998 caratteri e dovrebbe (SHOULD) essere di non più di 78 caratteri, escluso il CRLF.
Il limite di 998 caratteri esiste a causa di limitazioni in molte implementazioni che inviano, ricevono o memorizzano messaggi IMF e che semplicemente non possono gestire più di 998 caratteri su una riga. Le implementazioni riceventi farebbero bene a gestire un numero arbitrariamente grande di caratteri in una riga per motivi di robustezza. Tuttavia, ci sono così tante implementazioni che (in conformità con i requisiti di trasporto di RFC 5321) non accettano messaggi con più di 1000 caratteri inclusi CR e LF per riga, che è importante che le implementazioni non creino tali messaggi.
La più conservativa raccomandazione di 78 caratteri serve ad accogliere le numerose implementazioni di interfacce utente che visualizzano questi messaggi e che possono troncare o avvolgere catastroficamente la visualizzazione di più di 78 caratteri per riga, anche se tali implementazioni non sono conformi all'intento di questa specifica (e a quello di RFC 5321 se causano effettivamente perdita di informazioni). Ancora, anche se questa limitazione è posta sui messaggi, è responsabilità delle implementazioni che visualizzano i messaggi gestire un numero arbitrariamente grande di caratteri in una riga (certamente almeno fino al limite di 998 caratteri) per motivi di robustezza.
Riepilogo dei limiti di lunghezza della riga:
| Tipo di limite | Lunghezza (escluso CRLF) | Requisito | Motivo |
|---|---|---|---|
| Limite rigido | 998 caratteri | deve (MUST) | Molte implementazioni non possono gestire righe più lunghe |
| Limite raccomandato | 78 caratteri | dovrebbe (SHOULD) | Accomodare troncamento di visualizzazione nelle UI |
Esempi di lunghezza della riga:
✅ Conforme alla raccomandazione (entro 78 caratteri):
Subject: This is a short subject line
✅ Conforme ma supera la raccomandazione (78-998 caratteri):
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 (supera 998 caratteri):
Subject: [Contenuto che supera 998 caratteri...]
2.2. Header Fields (Campi di intestazione)
I campi di intestazione sono righe che iniziano con un nome di campo, seguito da due punti (":"), seguito da un corpo di campo e terminato da CRLF. Un nome di campo deve (MUST) essere composto da caratteri US-ASCII stampabili (cioè, caratteri che hanno valori tra 33 e 126, inclusi), eccetto i due punti. Un corpo di campo può essere composto da caratteri US-ASCII stampabili così come i caratteri spazio (SP, valore ASCII 32) e tabulazione orizzontale (HTAB, valore ASCII 9) (insieme noti come caratteri di spazio bianco, WSP). Un corpo di campo non deve (MUST NOT) includere CR e LF eccetto quando usati nella "piegatura" (Folding) e "spiegatura" (Unfolding), come descritto nella Sezione 2.2.3. Tutti i corpi di campo devono (MUST) conformarsi alla sintassi descritta nelle Sezioni 3 e 4 di questa specifica.
Formato del campo di intestazione:
Field-Name: Field-BodyCRLF
↑ ↑ ↑ ↑
| | | +--- Terminatore di riga
| | +---------- Contenuto del campo
| +----------------- Delimitatore due punti
+------------------------- Nome del campo
Esempio:
From: [email protected]
Subject: Meeting Tomorrow
Date: Mon, 20 Dec 2025 10:00:00 +0800
2.2.1. Unstructured Header Field Bodies (Corpi di campi di intestazione non strutturati)
Alcuni corpi di campo in questa specifica sono definiti semplicemente come "non strutturati" (Unstructured) (specificati nella Sezione 3.2.5 come qualsiasi carattere US-ASCII stampabile più caratteri di spazio bianco) senza ulteriori restrizioni. Questi sono chiamati corpi di campo non strutturati. Semanticamente, i corpi di campo non strutturati devono essere trattati semplicemente come una singola riga di caratteri senza ulteriore elaborazione (eccetto per "piegatura" e "spiegatura" descritte nella Sezione 2.2.3).
Esempi di campi non strutturati:
Subject: This is any text I want to write
Comments: Here's a free-form comment
Caratteristiche:
- Contenuto libero, qualsiasi carattere ASCII stampabile
- Nessuna struttura sintattica specifica richiesta
- Solo piegatura/spiegatura deve essere elaborata
2.2.2. Structured Header Field Bodies (Corpi di campi di intestazione strutturati)
Alcuni corpi di campo in questa specifica hanno una sintassi più restrittiva rispetto ai corpi di campo non strutturati descritti sopra. Questi sono chiamati corpi di campo "strutturati". I corpi di campo strutturati sono sequenze di token lessicali specifici come descritto nelle Sezioni 3 e 4 di questa specifica. Molti di questi token sono consentiti (secondo la loro sintassi) di essere introdotti o terminati con commenti (come descritto nella Sezione 3.2.2) così come caratteri di spazio bianco, e questi caratteri di spazio bianco sono soggetti a "piegatura" e "spiegatura" descritte nella Sezione 2.2.3. L'analisi semantica dei corpi di campo strutturati è fornita insieme alla loro sintassi.
Esempi di campi strutturati:
From: Alice Smith <[email protected]>
To: [email protected], [email protected]
Date: Mon, 20 Dec 2025 10:00:00 +0800
Caratteristiche:
- Deve seguire regole sintattiche rigorose
- Contiene token lessicali specifici (es. indirizzi email, data-ora)
- Può includere commenti e spazi bianchi
- Richiede analisi secondo la sintassi
Confronto:
| Tipo | Rigore sintattico | Elaborazione | Esempi tipici |
|---|---|---|---|
| Non strutturato | Lasco, testo libero | Come stringa intera | Subject, Comments |
| Strutturato | Rigoroso, sintassi specifica | Analizzare per token lessicali | From, To, Date |
2.2.3. Long Header Fields (Campi di intestazione lunghi)
Ogni campo di intestazione è logicamente una singola riga di caratteri che comprende il nome del campo, i due punti e il corpo del campo. Tuttavia, per comodità e per gestire le limitazioni di 998/78 caratteri per riga, la porzione del corpo del campo di un campo di intestazione può essere suddivisa in una rappresentazione multi-riga; questo è chiamato "piegatura" (Folding). La regola generale è che ovunque questa specifica permetta spazio bianco pieghevole (non semplicemente caratteri WSP), un CRLF può essere inserito prima di qualsiasi WSP.
Esempio di piegatura:
Campo di intestazione originale:
Subject: This is a test
Può essere rappresentato come (piegato):
Subject: This
is a test
Nota: Sebbene le definizioni di corpi di campo strutturati permettano la piegatura ovunque sia permesso lo spazio bianco pieghevole (e anche all'interno dei token lessicali), la piegatura dovrebbe (SHOULD) essere limitata al posizionamento del CRLF ai punti di interruzione sintattica di livello superiore. Ad esempio, se un corpo di campo è definito come valori separati da virgole, si raccomanda che la piegatura avvenga dopo la virgola che separa gli elementi strutturati, piuttosto che all'interno degli elementi stessi, anche se è permesso altrove.
Regole di piegatura:
- Punto di inserimento: Inserire CRLF prima di qualsiasi WSP (spazio o tabulazione)
- Riga di continuazione: La riga successiva deve iniziare con WSP
- Posizione raccomandata: Ai punti di interruzione sintattica di alto livello (es. dopo le virgole)
Esempio di piegatura di più indirizzi:
Piegatura raccomandata (dopo le virgole):
To: [email protected],
[email protected],
[email protected]
Non raccomandato ma legale:
To: [email protected], bob@
example.com, [email protected]
La spiegatura (Unfolding) è il processo inverso di spostamento di questa rappresentazione multi-riga piegata nella sua rappresentazione a riga singola. La spiegatura viene eseguita semplicemente rimuovendo qualsiasi CRLF immediatamente seguito da WSP. Ogni campo di intestazione dovrebbe essere trattato nella sua forma spiegata per ulteriore valutazione sintattica e semantica. Un campo di intestazione spiegato non ha restrizioni di lunghezza e quindi può essere indeterminatamente lungo.
Processo di spiegatura:
Prima della piegatura (logico):
Subject: This is a very long subject line
Dopo la piegatura (trasmissione):
Subject: This is a
very long subject line
Dopo la spiegatura (analisi):
Subject: This is a very long subject line
Algoritmo di spiegatura:
1. Identificare: Trovare il pattern CRLF + WSP
2. Rimuovere: Eliminare CRLF, mantenere WSP
3. Risultato: Stringa a riga singola continua
2.3. Body (Corpo)
Il corpo di un messaggio è semplicemente righe di caratteri US-ASCII. Le uniche due limitazioni sul corpo sono:
- CR e LF devono (MUST) apparire insieme solo come CRLF; non devono (MUST NOT) apparire indipendentemente nel corpo.
- Le righe di caratteri nel corpo devono (MUST) essere limitate a 998 caratteri e dovrebbero (SHOULD) essere limitate a 78 caratteri, escluso il CRLF.
Nota: Come è stato menzionato, ci sono altri documenti, specificamente i documenti MIME (RFC 2045, RFC 2046, RFC 2049, RFC 4288, RFC 4289), che estendono (e limitano) questa specifica per consentire diversi tipi di corpi di messaggio. Ancora, questi meccanismi sono al di là dell'ambito di questo documento.
Riepilogo delle restrizioni del corpo:
| Tipo di restrizione | Requisito | Descrizione |
|---|---|---|
| Terminatore di riga | deve usare CRLF (MUST) | CR e LF non possono apparire indipendentemente |
| Lunghezza riga (Rigoroso) | deve ≤ 998 caratteri (MUST) | Escluso CRLF |
| Lunghezza riga (Raccomandato) | dovrebbe ≤ 78 caratteri (SHOULD) | Escluso CRLF |
Esempio di corpo legale:
Hello Bob,CRLF
CRLF
Let's meet tomorrow at 10am.CRLF
CRLF
Best regards,CRLF
Alice CRLF
Esempi di corpo illegale:
❌ Contiene CR o LF indipendente:
Hello BobCR (LF mancante)
LineLF (CR mancante)
❌ Riga troppo lunga (supera 998 caratteri):
[Testo continuo che supera 998 caratteri...]
Riepilogo del Capitolo 2
Concetti chiave
- Set di caratteri: US-ASCII (1-127)
- Terminatore di riga: CRLF (CR+LF)
- Struttura del messaggio: Sezione intestazione + Riga vuota + Corpo
- Lunghezza riga: 998 caratteri (MUST), 78 caratteri (SHOULD)
Confronto dei tipi di campi di intestazione
Campi non strutturati Campi strutturati
↓ ↓
Subject: Any text From: user@domain
Comments: ... To: user1, user2
Date: Day, DD Mon YYYY
↓ ↓
Elaborare come Analizzare per sintassi
intero
Meccanismo di piegatura
Campo lungo Piegatura
↓ ↓
To: [email protected], To: [email protected],
[email protected] --> [email protected]
↑ ↑
Riga singola (logico) Multi-riga (trasmissione)
←--- Spiegatura ---
Prossimi passi
Il Capitolo 2 fornisce una panoramica lessicale dei messaggi. La Sezione 3 definirà regole sintattiche ABNF precise per creare messaggi conformi.
Successivo: 3. Syntax (Sintassi)
Precedente: 1. Introduction (Introduzione)