3. Sintassi
3.1. Introduzione
La sintassi fornita in questa sezione definisce la sintassi legale dei messaggi Internet. I messaggi conformi a questa specifica MUST essere conformi alla sintassi di questa sezione. Se in questa sezione vi sono opzioni in cui una opzione SHOULD essere generata, ciò è indicato nel testo o in un commento accanto alla sintassi.
Per le espressioni definite, viene fornita una breve descrizione della sintassi e dell'uso, seguita dalla sintassi in ABNF, seguita da un'analisi semantica. I seguenti token primitivi che sono utilizzati ma altrimenti non specificati sono tratti dalle "Core Rules" di [RFC5234], Appendice B.1: CR, LF, CRLF, HTAB, SP, WSP, DQUOTE, DIGIT, ALPHA e VCHAR.
In alcune definizioni vi saranno non-terminali i cui nomi iniziano con "obs-". Questi elementi "obs-" si riferiscono a token definiti nella sintassi obsoleta nella sezione 4. In tutti i casi, queste produzioni devono essere ignorate ai fini della generazione di messaggi Internet legali e MUST NOT essere utilizzate come parte di tali messaggi. Tuttavia, nell'interpretazione dei messaggi, questi token MUST essere rispettati come parte della sintassi legale. In questo senso, la sezione 3 definisce una grammatica per la generazione dei messaggi, con elementi "obs-" che devono essere ignorati, mentre la sezione 4 aggiunge una grammatica per l'interpretazione dei messaggi.
3.2. Token lessicali
Le seguenti regole sono utilizzate per definire un analizzatore lessicale (lexical analyzer) di base, che fornisce token ai parser di livello superiore. Questa sezione definisce i token utilizzati nei corpi strutturati dei campi di intestazione.
Nota: I lettori di questa specifica devono prestare particolare attenzione a come questi token lessicali siano utilizzati sia nella sintassi di livello inferiore sia in quella di livello superiore più avanti nel documento. In particolare, i token di spazio bianco e i token di commento definiti nella sezione 3.2.2 vengono utilizzati nei token di livello inferiore qui definiti, e tali token di livello inferiore sono a loro volta utilizzati come parti dei token di livello superiore definiti più avanti. Pertanto, spazi bianchi e commenti possono essere consentiti nei token di livello superiore anche se potrebbero non apparire esplicitamente in una particolare definizione.
3.2.1. Caratteri quotati
Alcuni caratteri sono riservati a un'interpretazione speciale, come la delimitazione di token lessicali. Per consentire l'uso di questi caratteri come dati non interpretati, è fornito un meccanismo di quotatura.
quoted-pair = ("\" (VCHAR / WSP)) / obs-qp
Dove appare un quoted-pair, esso deve essere interpretato come il carattere da solo. Vale a dire, il carattere "" che appare come parte di un quoted-pair è semanticamente "invisibile".
Nota: Il carattere "" può apparire in un messaggio dove non fa parte di un quoted-pair. Un carattere "" che non appare in un quoted-pair non è semanticamente invisibile. Gli unici luoghi in questa specifica in cui quoted-pair appare attualmente sono ccontent, qcontent e obs-dtext nella sezione 4.
3.2.2. Spazio bianco di ripiegamento e commenti
I caratteri di spazio bianco, compreso lo spazio bianco utilizzato nel ripiegamento (descritto nella sezione 2.2.3), possono apparire tra molti elementi nei corpi dei campi di intestazione. Inoltre, stringhe di caratteri trattate come commenti possono essere incluse nei corpi strutturati dei campi come caratteri racchiusi tra parentesi. Quanto segue definisce lo spazio bianco di ripiegamento (folding white space, FWS) e i costrutti di commento.
Le stringhe di caratteri racchiuse tra parentesi sono considerate commenti fintanto che non appaiono all'interno di una "quoted-string", come definito nella sezione 3.2.4. I commenti possono annidarsi.
Vi sono diversi punti in questa specifica in cui commenti e FWS possono essere inseriti liberamente. Per venire incontro a tale sintassi, è definito un token aggiuntivo per "CFWS" per i punti in cui commenti e/o FWS possono comparire. Tuttavia, dove CFWS compare in questa specifica, esso MUST NOT essere inserito in modo tale che una qualche riga di un campo di intestazione ripiegato sia composta interamente da caratteri WSP e nulla più.
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
Nel corso di questa specifica, dove appare FWS (il token di spazio bianco di ripiegamento), esso indica un punto in cui il ripiegamento, come discusso nella sezione 2.2.3, può avvenire. Ovunque il ripiegamento appaia in un messaggio (cioè un corpo di campo di intestazione contenente un CRLF seguito da un qualunque WSP), la distensione (rimozione del CRLF) viene eseguita prima che qualunque ulteriore analisi semantica sia eseguita su quel campo di intestazione secondo questa specifica. Vale a dire, qualunque CRLF che appaia in FWS è semanticamente "invisibile".
Un commento è normalmente usato in un corpo strutturato di campo per fornire del testo informativo leggibile dall'uomo. Poiché a un commento è consentito contenere FWS, il ripiegamento è permesso all'interno del commento. Si noti inoltre che, poiché quoted-pair è consentito in un commento, i caratteri parentesi e barra rovesciata possono apparire in un commento, purché appaiano come quoted-pair. Semanticamente, le parentesi che racchiudono non fanno parte del commento; il commento è ciò che è contenuto tra le due parentesi. Come affermato in precedenza, il "" in qualunque quoted-pair e il CRLF in qualunque FWS che appare all'interno del commento sono semanticamente "invisibili" e quindi non fanno parte nemmeno del commento.
Sequenze di FWS, commento o CFWS che compaiono tra token lessicali in un campo di intestazione strutturato sono interpretate semanticamente come un singolo carattere spazio.
3.2.3. Atom
Diverse produzioni nei corpi strutturati dei campi di intestazione sono semplicemente stringhe di certi caratteri di base. Tali produzioni sono chiamate atom.
Alcuni dei corpi strutturati dei campi di intestazione consentono anche il carattere punto (".", valore ASCII 46) all'interno di sequenze di atext. A questo scopo è definito un token aggiuntivo "dot-atom".
Nota: Il token "specials" non appare in nessun altro punto di questa specifica. Esso è semplicemente i caratteri visibili (cioè non di controllo, non di spazio bianco) che non appaiono in atext. È fornito solo perché è utile agli implementatori che utilizzano strumenti che analizzano lessicalmente i messaggi. Ciascuno dei caratteri in specials può essere usato per indicare un punto di tokenizzazione nell'analisi lessicale.
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
Sia atom sia dot-atom sono interpretati come una singola unità, comprendente la stringa di caratteri che la compone. Semanticamente, i commenti opzionali e gli FWS che circondano il resto dei caratteri non fanno parte dell'atom; l'atom è soltanto la sequenza di caratteri atext in un atom, oppure i caratteri atext e "." in un dot-atom.
3.2.4. Stringhe quotate
Stringhe di caratteri che includono caratteri diversi da quelli consentiti negli atom possono essere rappresentate in un formato di stringa quotata, in cui i caratteri sono circondati da caratteri virgoletta (DQUOTE, valore 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]
Una quoted-string è trattata come un'unità. Vale a dire, quoted-string è identica ad atom, semanticamente. Poiché a una quoted-string è consentito contenere FWS, il ripiegamento è permesso. Si noti inoltre che, poiché quoted-pair è consentito in una quoted-string, i caratteri virgoletta e barra rovesciata possono apparire in una quoted-string purché appaiano come quoted-pair.
Semanticamente, né il CFWS opzionale all'esterno dei caratteri virgoletta né i caratteri virgoletta stessi fanno parte della quoted-string; la quoted-string è ciò che è contenuto tra i due caratteri virgoletta. Come affermato in precedenza, il "" in qualunque quoted-pair e il CRLF in qualunque FWS/CFWS che appaia all'interno della quoted-string sono semanticamente "invisibili" e quindi non fanno parte nemmeno della quoted-string.
3.2.5. Token vari
Sono definiti tre token aggiuntivi: word e phrase per combinazioni di atom e/o quoted-string, e unstructured per l'uso nei campi di intestazione non strutturati e in alcuni punti all'interno dei campi di intestazione strutturati.
word = atom / quoted-string
phrase = 1*word / obs-phrase
unstructured = (*([FWS] VCHAR) *WSP) / obs-unstruct
3.3. Specifica di data e ora
I valori di data e ora compaiono in diversi campi di intestazione. Questa sezione specifica la sintassi per una specifica completa di data e ora. Sebbene lo spazio bianco di ripiegamento sia consentito in tutta la specifica di data e ora, è RECOMMENDED che in ogni punto in cui appare FWS (che sia obbligatorio o opzionale) si usi un singolo spazio; alcune implementazioni più vecchie non interpreteranno correttamente sequenze più lunghe di spazio bianco di ripiegamento.
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
Il giorno è il giorno numerico del mese. L'anno è un qualunque anno numerico dal 1900 in poi.
L'ora del giorno specifica il numero di ore, minuti e opzionalmente secondi dalla mezzanotte della data indicata.
La data e l'ora del giorno SHOULD esprimere l'ora locale.
Il fuso specifica lo scostamento rispetto al Tempo Coordinato Universale (Coordinated Universal Time, UTC, in precedenza chiamato "Greenwich Mean Time") che la data e l'ora del giorno rappresentano. Il segno "+" o "-" indica se l'ora del giorno è in anticipo (cioè a est) o in ritardo (cioè a ovest) rispetto al Tempo Universale. Le prime due cifre indicano il numero di ore di differenza dal Tempo Universale, e le ultime due cifre indicano il numero di minuti aggiuntivi di differenza dal Tempo Universale. (Pertanto, +hhmm significa +(hh * 60 + mm) minuti, e -hhmm significa -(hh * 60 + mm) minuti). La forma "+0000" SHOULD essere usata per indicare un fuso orario al Tempo Universale. Sebbene anche "-0000" indichi il Tempo Universale, esso è usato per indicare che l'ora è stata generata su un sistema che può trovarsi in un fuso orario locale diverso dal Tempo Universale e che la data-ora non contiene informazioni sul fuso orario locale.
Una specifica di data-ora MUST essere semanticamente valida. Vale a dire, il giorno della settimana (se incluso) MUST essere il giorno implicato dalla data, il giorno numerico del mese MUST essere compreso tra 1 e il numero di giorni consentiti per il mese specificato (nell'anno specificato), l'ora del giorno MUST essere nell'intervallo da 00:00:00 a 23:59:60 (il numero di secondi tiene conto del secondo intercalare; si veda [RFC1305]), e le ultime due cifre del fuso MUST essere comprese nell'intervallo da 00 a 59.
3.4. Specifica degli indirizzi
Gli indirizzi compaiono in diversi campi di intestazione dei messaggi per indicare i mittenti e i destinatari dei messaggi. Un indirizzo può essere una singola casella di posta oppure un gruppo di caselle di posta.
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
Una casella di posta riceve la posta. È un'entità concettuale che non riguarda necessariamente la memorizzazione su file. Per esempio, alcuni siti possono scegliere di stampare la posta su una stampante e consegnare l'output alla scrivania del destinatario.
Normalmente, una casella di posta è composta da due parti: (1) un nome visualizzato opzionale che indica il nome del destinatario (che può essere una persona o un sistema) e che potrebbe essere mostrato all'utente di un'applicazione di posta, e (2) un indirizzo addr-spec racchiuso tra parentesi angolari ("<" e ">"). Esiste una forma semplice alternativa di casella di posta in cui l'indirizzo addr-spec appare da solo, senza il nome del destinatario o le parentesi angolari. L'indirizzo Internet addr-spec è descritto nella sezione 3.4.1.
Nota: Alcune implementazioni legacy usavano la forma semplice in cui addr-spec appare senza le parentesi angolari, ma includevano il nome del destinatario tra parentesi come commento dopo l'addr-spec. Poiché il significato delle informazioni in un commento non è specificato, le implementazioni SHOULD usare la forma completa name-addr della casella di posta, invece della forma legacy, per specificare il nome visualizzato associato a una casella di posta. Inoltre, poiché alcune implementazioni legacy interpretano il commento, i commenti in genere SHOULD NOT essere usati nei campi degli indirizzi per evitare di confondere tali implementazioni.
Quando è desiderabile trattare diverse caselle di posta come una singola unità (cioè in una lista di distribuzione), si può usare il costrutto group. Il costrutto group consente al mittente di indicare un gruppo denominato di destinatari. Ciò si fa dando un nome visualizzato per il gruppo, seguito da due punti, seguito da una lista separata da virgole di un numero qualsiasi di caselle di posta (inclusi zero e uno), e terminando con un punto e virgola. Poiché la lista di caselle di posta può essere vuota, usare il costrutto group è anche un modo semplice per comunicare ai destinatari che il messaggio è stato inviato a uno o più insiemi denominati di destinatari, senza fornire effettivamente l'indirizzo della singola casella di posta per nessuno di tali destinatari.
3.4.1. Specifica di addr-spec
Un addr-spec è uno specifico identificatore Internet che contiene una stringa interpretata localmente seguita dal carattere chiocciola ("@", valore ASCII 64) seguito da un dominio Internet. La stringa interpretata localmente è una quoted-string o un dot-atom. Se la stringa può essere rappresentata come dot-atom (cioè non contiene caratteri diversi dai caratteri atext o "." circondati da caratteri atext), allora SHOULD essere usata la forma dot-atom e SHOULD NOT essere usata la forma quoted-string. Commenti e spazio bianco di ripiegamento SHOULD NOT essere usati attorno alla "@" nell'addr-spec.
Nota: Qui è fornita una sintassi liberale per la porzione di dominio dell'addr-spec. Tuttavia, la porzione di dominio contiene informazioni di indirizzamento specificate e utilizzate da altri protocolli (ad esempio [RFC1034], [RFC1035], [RFC1123], [RFC5321]). Spetta pertanto alle implementazioni essere conformi alla sintassi degli indirizzi per il contesto in cui sono utilizzati.
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 porzione di dominio identifica il punto a cui la posta è consegnata. Nella forma dot-atom, essa è interpretata come un nome di dominio Internet (un nome host o un nome di mail exchanger) come descritto in [RFC1034], [RFC1035] e [RFC1123]. Nella forma domain-literal, il dominio è interpretato come l'indirizzo Internet letterale dell'host particolare. In entrambi i casi, come l'indirizzamento sia usato e come i messaggi siano trasportati a un particolare host è trattato in documenti separati, come [RFC5321]. Questi meccanismi sono al di fuori dell'ambito di questo documento.
La porzione local-part è una stringa dipendente dal dominio. Negli indirizzi, essa è semplicemente interpretata sull'host particolare come nome di una particolare casella di posta.
3.5. Sintassi complessiva del messaggio
Un messaggio è costituito da campi di intestazione, seguiti opzionalmente da un corpo del messaggio. Le righe in un messaggio MUST avere una lunghezza massima di 998 caratteri, escluso il CRLF, ma è RECOMMENDED che le righe siano limitate a 78 caratteri, escluso il CRLF. (Si veda la sezione 2.1.1 per la spiegazione.) In un corpo del messaggio, sebbene tutti i caratteri elencati nella regola text MAY essere utilizzati, l'uso di caratteri di controllo US-ASCII (valori da 1 a 8, 11, 12 e da 14 a 31) è sconsigliato, poiché la loro interpretazione da parte dei riceventi ai fini della visualizzazione non è garantita.
message = (fields / obs-fields)
[CRLF body]
body = (*(*998text CRLF) *998text) / obs-body
text = %d1-9 / ; Characters excluding CR
%d11 / ; and LF
%d12 /
%d14-127
I campi di intestazione portano la maggior parte delle informazioni semantiche e sono definiti nella sezione 3.6. Il corpo è semplicemente una serie di righe di testo che non vengono interpretate ai fini di questa specifica.
3.6. Definizioni dei campi
I campi di intestazione di un messaggio sono definiti qui. Tutti i campi di intestazione hanno la stessa struttura sintattica generale: un nome del campo, seguito da due punti, seguito dal corpo del campo. La sintassi specifica per ciascun campo di intestazione è definita nelle sezioni successive.
Nota: Nella sintassi ABNF per ciascun campo nelle sezioni successive, ogni nome di campo è seguito dai due punti richiesti. Tuttavia, per brevità, talvolta i due punti non sono menzionati nella descrizione testuale della sintassi. Essi sono comunque richiesti.
È importante notare che i campi di intestazione non sono garantiti in un ordine particolare. Possono apparire in qualunque ordine, ed è noto che sono stati occasionalmente riordinati durante il trasporto su Internet. Tuttavia, ai fini di questa specifica, i campi di intestazione SHOULD NOT essere riordinati quando un messaggio è trasportato o trasformato. Ancora più importante, i campi di intestazione di traccia e i campi di intestazione resent MUST NOT essere riordinati e SHOULD essere mantenuti in blocchi anteposti al messaggio. Si vedano le sezioni 3.6.6 e 3.6.7 per ulteriori informazioni.
Gli unici campi di intestazione richiesti sono il campo della data di origine e il campo o i campi dell'indirizzo dell'originatore. Tutti gli altri campi di intestazione sono sintatticamente opzionali. Ulteriori informazioni sono contenute nella tabella che segue questa definizione.
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)
La tabella seguente indica i limiti al numero di volte in cui ciascun campo può comparire nella sezione di intestazione di un messaggio, nonché eventuali limitazioni speciali sull'uso di tali campi. Un asterisco ("*") accanto a un valore nella colonna del minimo o del massimo indica che nella colonna Notes compare una restrizione speciale.
+----------------+--------+------------+----------------------------+
| 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'interpretazione esatta di ciascun campo è descritta nelle sezioni successive.
3.6.1. Il campo della data di origine
Il campo della data di origine consiste nel nome del campo "Date" seguito da una specifica di data-ora.
orig-date = "Date:" date-time CRLF
La data di origine specifica la data e l'ora in cui il creatore del messaggio ha indicato che il messaggio era completo e pronto a entrare nel sistema di consegna della posta. Per esempio, potrebbe essere il momento in cui un utente preme il pulsante "send" o "submit" in un programma applicativo. In ogni caso, essa non è specificamente intesa a trasmettere il momento in cui il messaggio è effettivamente trasportato, bensì il momento in cui l'essere umano o altro creatore del messaggio ha messo il messaggio nella sua forma finale, pronto per il trasporto. (Per esempio, un utente di computer portatile non connesso a una rete potrebbe accodare un messaggio per la consegna. La data di origine è intesa a contenere la data e l'ora in cui l'utente ha accodato il messaggio, non il momento in cui l'utente si è connesso alla rete per inviare il messaggio.)
3.6.2. Campi dell'originatore
I campi dell'originatore di un messaggio consistono nel campo from, nel campo sender (quando applicabile) e, opzionalmente, nel campo reply-to. Il campo from consiste nel nome del campo "From" e in una lista separata da virgole di una o più specifiche di casella di posta. Se il campo from contiene più di una specifica di casella di posta nella mailbox-list, allora il campo sender, contenente il nome del campo "Sender" e una singola specifica di casella di posta, MUST apparire nel messaggio. In entrambi i casi, un campo reply-to opzionale MAY essere incluso, contenente il nome del campo "Reply-To" e una lista separata da virgole di uno o più indirizzi.
from = "From:" mailbox-list CRLF
sender = "Sender:" mailbox CRLF
reply-to = "Reply-To:" address-list CRLF
I campi dell'originatore indicano la casella o le caselle di posta della fonte del messaggio. Il campo "From:" specifica l'autore o gli autori del messaggio, cioè la casella o le caselle di posta della persona o delle persone (o del sistema o dei sistemi) responsabili della scrittura del messaggio. Il campo "Sender:" specifica la casella di posta dell'agente responsabile della trasmissione effettiva del messaggio. Per esempio, se una segretaria inviasse un messaggio per un'altra persona, la casella di posta della segretaria apparirebbe nel campo "Sender:" e la casella di posta dell'autore effettivo apparirebbe nel campo "From:". Se l'originatore del messaggio può essere indicato da una singola casella di posta e l'autore e il trasmettitore coincidono, il campo "Sender:" SHOULD NOT essere usato. Altrimenti, entrambi i campi SHOULD apparire.
Nota: L'informazione sul trasmettitore è sempre presente. L'assenza del campo "Sender:" è talvolta erroneamente interpretata come indicazione che l'agente responsabile della trasmissione del messaggio non è stato specificato. Questa assenza significa soltanto che il trasmettitore è identico all'autore e pertanto non è collocato in modo ridondante nel campo "Sender:".
I campi dell'originatore forniscono anche le informazioni necessarie quando si risponde a un messaggio. Quando il campo "Reply-To:" è presente, indica l'indirizzo o gli indirizzi a cui l'autore del messaggio suggerisce di inviare le risposte. In assenza del campo "Reply-To:", le risposte SHOULD per impostazione predefinita essere inviate alla casella o alle caselle di posta specificate nel campo "From:", salvo diversa indicazione da parte della persona che compone la risposta.
In tutti i casi, il campo "From:" SHOULD NOT contenere alcuna casella di posta che non appartenga all'autore o agli autori del messaggio. Si veda anche la sezione 3.6.3 per ulteriori informazioni sulla formazione degli indirizzi di destinazione di una risposta.
3.6.3. Campi dell'indirizzo di destinazione
I campi di destinazione di un messaggio consistono in tre possibili campi, ciascuno della stessa forma: il nome del campo, che è "To", "Cc" o "Bcc", seguito da una lista separata da virgole di uno o più indirizzi (con sintassi di casella di posta o di gruppo).
to = "To:" address-list CRLF
cc = "Cc:" address-list CRLF
bcc = "Bcc:" [address-list / CFWS] CRLF
I campi di destinazione specificano i destinatari del messaggio. Ciascun campo di destinazione può avere uno o più indirizzi, e gli indirizzi indicano i destinatari previsti del messaggio. L'unica differenza tra i tre campi è il modo in cui ciascuno è usato.
Il campo "To:" contiene l'indirizzo o gli indirizzi del destinatario o dei destinatari primari del messaggio.
Il campo "Cc:" (dove "Cc" significa "Carbon Copy", nel senso di fare una copia su una macchina da scrivere usando carta carbone) contiene gli indirizzi di altri che devono ricevere il messaggio, anche se il contenuto del messaggio può non essere loro diretto.
Il campo "Bcc:" (dove "Bcc" significa "Blind Carbon Copy") contiene gli indirizzi dei destinatari del messaggio i cui indirizzi non devono essere rivelati agli altri destinatari del messaggio. Vi sono tre modi in cui il campo "Bcc:" è usato. Nel primo caso, quando un messaggio contenente un campo "Bcc:" è preparato per essere inviato, la riga "Bcc:" è rimossa anche se a tutti i destinatari (inclusi quelli specificati nel campo "Bcc:") viene inviata una copia del messaggio. Nel secondo caso, ai destinatari specificati nelle righe "To:" e "Cc:" viene inviata una copia del messaggio con la riga "Bcc:" rimossa come sopra, ma i destinatari sulla riga "Bcc:" ricevono una copia separata del messaggio contenente una riga "Bcc:". (Quando nel campo "Bcc:" vi sono più indirizzi di destinatari, alcune implementazioni inviano effettivamente una copia separata del messaggio a ciascun destinatario con un "Bcc:" contenente solo l'indirizzo di quel particolare destinatario.) Infine, poiché un campo "Bcc:" può non contenere alcun indirizzo, un campo "Bcc:" può essere inviato senza alcun indirizzo, indicando ai destinatari che sono state inviate copie cieche a qualcuno. Quale metodo usare con i campi "Bcc:" dipende dall'implementazione, ma si faccia riferimento alla sezione "Considerazioni sulla sicurezza" di questo documento per una discussione di ciascuno.
Quando un messaggio è una risposta a un altro messaggio, le caselle di posta degli autori del messaggio originale (le caselle di posta nel campo "From:") o le caselle di posta specificate nel campo "Reply-To:" (se esiste) MAY apparire nel campo "To:" della risposta, poiché queste sarebbero normalmente i destinatari primari della risposta. Se una risposta è inviata a un messaggio che ha campi di destinazione, è spesso desiderabile inviare una copia della risposta a tutti i destinatari del messaggio, oltre che all'autore. Quando si forma tale risposta, gli indirizzi nei campi "To:" e "Cc:" del messaggio originale MAY apparire nel campo "Cc:" della risposta, poiché questi sono normalmente destinatari secondari della risposta. Se nel messaggio originale è presente un campo "Bcc:", gli indirizzi in quel campo MAY apparire nel campo "Bcc:" della risposta, ma SHOULD NOT apparire nei campi "To:" o "Cc:".
Nota: Alcune applicazioni di posta hanno comandi di risposta automatici che includono gli indirizzi di destinazione del messaggio originale negli indirizzi di destinazione della risposta. Il comportamento di tali comandi di risposta dipende dall'implementazione ed è al di fuori dell'ambito di questo documento. In particolare, non è qui trattato se includere o meno gli indirizzi di destinazione originali quando il messaggio originale aveva un campo "Reply-To:".
3.6.4. Campi di identificazione
Sebbene elencato come opzionale nella tabella della sezione 3.6, ogni messaggio SHOULD avere un campo "Message-ID:". Inoltre, i messaggi di risposta SHOULD avere i campi "In-Reply-To:" e "References:" secondo appropriatezza e come descritto di seguito.
Il campo "Message-ID:" contiene un singolo identificatore univoco di messaggio. I campi "References:" e "In-Reply-To:" contengono ciascuno uno o più identificatori univoci di messaggio, opzionalmente separati da CFWS.
La sintassi dell'identificatore di messaggio (msg-id) è una versione limitata del costrutto addr-spec racchiusa tra i caratteri parentesi angolari "<" e ">". A differenza di addr-spec, questa sintassi consente solo la forma dot-atom-text sul lato sinistro della "@" e non ha CFWS interni in alcun punto dell'identificatore di messaggio.
Nota: Come per addr-spec, è fornita una sintassi liberale per il lato destro della "@" in un msg-id. Tuttavia, più avanti in questa sezione, è RECOMMENDED l'uso di un dominio per il lato destro della "@". Ancora una volta, la sintassi dei costrutti di dominio è specificata e utilizzata da altri protocolli (ad esempio [RFC1034], [RFC1035], [RFC1123], [RFC5321]). Spetta pertanto alle implementazioni essere conformi alla sintassi degli indirizzi per il contesto in cui sono utilizzati.
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 "]"
Il campo "Message-ID:" fornisce un identificatore univoco di messaggio che si riferisce a una particolare versione di un particolare messaggio. L'unicità dell'identificatore di messaggio è garantita dall'host che lo genera (si veda di seguito). Questo identificatore di messaggio è inteso come leggibile da una macchina e non necessariamente significativo per gli esseri umani. Un identificatore di messaggio riguarda esattamente una versione di un particolare messaggio; le revisioni successive del messaggio ricevono ciascuna nuovi identificatori di messaggio.
Nota: Vi sono molte occasioni in cui i messaggi sono "modificati", ma tali modifiche non costituiscono una nuova istanza di quel messaggio, e pertanto il messaggio non otterrebbe un nuovo identificatore di messaggio. Per esempio, quando i messaggi sono introdotti nel sistema di trasporto, sono spesso preceduti da campi di intestazione aggiuntivi come i campi di traccia (descritti nella sezione 3.6.7) e i campi resent (descritti nella sezione 3.6.6). L'aggiunta di tali campi di intestazione non cambia l'identità del messaggio e pertanto il campo "Message-ID:" originale è mantenuto. In tutti i casi, è il significato che il mittente del messaggio desidera trasmettere (cioè se questo è lo stesso messaggio o un messaggio differente) a determinare se il campo "Message-ID:" cambi, e non una qualunque particolare differenza sintattica che appaia (o non appaia) nel messaggio.
I campi "In-Reply-To:" e "References:" sono usati quando si crea una risposta a un messaggio. Essi contengono l'identificatore di messaggio del messaggio originale e gli identificatori di messaggio di altri messaggi (per esempio, nel caso di una risposta a un messaggio che era esso stesso una risposta). Il campo "In-Reply-To:" può essere usato per identificare il messaggio (o i messaggi) a cui il nuovo messaggio risponde, mentre il campo "References:" può essere usato per identificare un "thread" di conversazione.
Quando si crea una risposta a un messaggio, i campi "In-Reply-To:" e "References:" del messaggio risultante sono costruiti come segue:
Il campo "In-Reply-To:" conterrà il contenuto del campo "Message-ID:" del messaggio a cui questo risponde (il "messaggio genitore"). Se vi è più di un messaggio genitore, allora il campo "In-Reply-To:" conterrà il contenuto dei campi "Message-ID:" di tutti i genitori. Se non vi è alcun campo "Message-ID:" in nessuno dei messaggi genitori, allora il nuovo messaggio non avrà alcun campo "In-Reply-To:".
Il campo "References:" conterrà il contenuto del campo "References:" del genitore (se presente) seguito dal contenuto del campo "Message-ID:" del genitore (se presente). Se il messaggio genitore non contiene un campo "References:" ma ha un campo "In-Reply-To:" contenente un singolo identificatore di messaggio, allora il campo "References:" conterrà il contenuto del campo "In-Reply-To:" del genitore seguito dal contenuto del campo "Message-ID:" del genitore (se presente). Se il genitore non ha nessuno dei campi "References:", "In-Reply-To:" o "Message-ID:", allora il nuovo messaggio non avrà alcun campo "References:".
Nota: Alcune implementazioni analizzano il campo "References:" per visualizzare il "thread della discussione". Queste implementazioni presumono che ogni nuovo messaggio sia una risposta a un singolo genitore e quindi che possano percorrere a ritroso il campo "References:" per trovare il genitore di ciascun messaggio ivi elencato. Pertanto, è sconsigliato cercare di formare un campo "References:" per una risposta che ha più genitori; come farlo non è definito in questo documento.
L'identificatore di messaggio (msg-id) stesso MUST essere un identificatore globalmente univoco per un messaggio. Il generatore dell'identificatore di messaggio MUST garantire che il msg-id sia univoco. Vi sono diversi algoritmi che possono essere usati per ottenere ciò. Poiché il msg-id ha una sintassi simile ad addr-spec (identica, tranne per il fatto che non sono consentiti stringhe quotate, commenti e spazio bianco di ripiegamento), un buon metodo è mettere il nome di dominio (o un indirizzo IP letterale di dominio) dell'host su cui è stato creato l'identificatore di messaggio sul lato destro della "@" (poiché i nomi di dominio e gli indirizzi IP sono normalmente univoci), e mettere una combinazione della data e dell'ora assolute correnti insieme a qualche altro identificatore attualmente univoco (forse sequenziale) disponibile sul sistema (per esempio, un numero di identificazione di processo) sul lato sinistro. Sebbene altri algoritmi funzionino, è RECOMMENDED che il lato destro contenga qualche identificatore di dominio (dell'host stesso o altro) tale che il generatore dell'identificatore di messaggio possa garantire l'unicità del lato sinistro nell'ambito di quel dominio.
Semanticamente, i caratteri parentesi angolari non fanno parte del msg-id; il msg-id è ciò che è contenuto tra i due caratteri parentesi angolari.
3.6.5. Campi informativi
I campi informativi sono tutti opzionali. I campi "Subject:" e "Comments:" sono campi non strutturati come definito nella sezione 2.2.1, e pertanto possono contenere testo o spazio bianco di ripiegamento. Il campo "Keywords:" contiene una lista separata da virgole di una o più word o quoted-string.
subject = "Subject:" unstructured CRLF
comments = "Comments:" unstructured CRLF
keywords = "Keywords:" phrase *("," phrase) CRLF
Questi tre campi sono intesi ad avere solo contenuto leggibile dall'uomo con informazioni sul messaggio. Il campo "Subject:" è il più comune e contiene una breve stringa che identifica l'argomento del messaggio. Quando è usato in una risposta, il corpo del campo MAY iniziare con la stringa "Re: " (abbreviazione del latino "in re", che significa "in merito a") seguita dal contenuto del corpo del campo "Subject:" del messaggio originale. Se ciò è fatto, dovrebbe essere usata una sola istanza della stringa letterale "Re: ", poiché l'uso di altre stringhe o di più di una istanza può portare a conseguenze indesiderabili. Il campo "Comments:" contiene eventuali commenti aggiuntivi sul testo del corpo del messaggio. Il campo "Keywords:" contiene una lista separata da virgole di parole e frasi importanti che potrebbero essere utili al destinatario.
3.6.6. Campi Resent
I campi resent SHOULD essere aggiunti a qualunque messaggio reintrodotto da un utente nel sistema di trasporto. Un insieme separato di campi resent SHOULD essere aggiunto ogni volta che ciò avviene. Tutti i campi resent corrispondenti a un particolare reinvio del messaggio SHOULD essere raggruppati insieme. Ogni nuovo insieme di campi resent è anteposto al messaggio; vale a dire, l'insieme più recente di campi resent appare prima nel messaggio. Nessun altro campo del messaggio è modificato quando si aggiungono campi resent.
Ciascuno dei campi resent corrisponde a un particolare campo altrove nella sintassi. Per esempio, il campo "Resent-Date:" corrisponde al campo "Date:" e il campo "Resent-To:" corrisponde al campo "To:". In ciascun caso, la sintassi del corpo del campo è identica alla sintassi data in precedenza per il campo corrispondente.
Quando si usano i campi resent, i campi "Resent-From:" e "Resent-Date:" MUST essere inviati. Il campo "Resent-Message-ID:" SHOULD essere inviato. "Resent-Sender:" SHOULD NOT essere usato se "Resent-Sender:" sarebbe identico a "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
I campi resent sono usati per identificare un messaggio come reintrodotto nel sistema di trasporto da un utente. Lo scopo dell'uso dei campi resent è che il messaggio appaia al destinatario finale come se fosse stato inviato direttamente dal mittente originale, con tutti i campi originali rimasti invariati. Ogni insieme di campi resent corrisponde a un particolare evento di reinvio. Vale a dire, se un messaggio è reinviato più volte, ogni insieme di campi resent fornisce informazioni identificative per ciascuna singola volta. I campi resent sono strettamente informativi. Essi MUST NOT essere usati nella normale elaborazione delle risposte o in altre azioni automatiche di questo tipo sui messaggi.
Nota: Reintrodurre un messaggio nel sistema di trasporto e usare i campi resent è un'operazione diversa dall'"inoltro" (forwarding). "Inoltro" ha due significati: un senso dell'inoltro è che a un programma di lettura della posta un utente può impartire l'istruzione di inoltrare una copia di un messaggio a un'altra persona, rendendo il messaggio inoltrato il corpo del nuovo messaggio. Un messaggio inoltrato in questo senso non appare provenire dal mittente originale, ma è un messaggio del tutto nuovo da parte di chi inoltra il messaggio. L'inoltro può anche significare che un programma di trasporto della posta riceve un messaggio e lo inoltra a una destinazione diversa per la consegna finale. I campi di intestazione resent non sono intesi per l'uso con nessuno dei due tipi di inoltro.
I campi resent dell'originatore indicano la casella di posta della persona o delle persone (o del sistema o dei sistemi) che hanno reinviato il messaggio. Come per i campi ordinari dell'originatore, vi sono due forme: una forma semplice "Resent-From:", che contiene la casella di posta dell'individuo che esegue il reinvio, e la forma più complessa, quando un individuo (identificato nel campo "Resent-Sender:") reinvia un messaggio per conto di uno o più altri (identificati nel campo "Resent-From:").
Nota: Quando si risponde a un messaggio reinviato, le risposte si comportano esattamente come farebbero con qualunque altro messaggio, usando i campi originali "From:", "Reply-To:", "Message-ID:" e gli altri. I campi resent sono solo informativi e MUST NOT essere usati nella normale elaborazione delle risposte.
Il campo "Resent-Date:" indica la data e l'ora in cui il messaggio reinviato è spedito da chi lo reinvia. Come il campo "Date:", non è la data e l'ora in cui il messaggio è stato effettivamente trasportato.
I campi "Resent-To:", "Resent-Cc:" e "Resent-Bcc:" funzionano in modo identico ai campi "To:", "Cc:" e "Bcc:", rispettivamente, tranne per il fatto che indicano i destinatari del messaggio reinviato, non i destinatari del messaggio originale.
Il campo "Resent-Message-ID:" fornisce un identificatore univoco per il messaggio reinviato.
3.6.7. Campi di traccia
I campi di traccia sono un gruppo di campi di intestazione costituiti da un campo opzionale "Return-Path:" e da uno o più campi "Received:". Il campo di intestazione "Return-Path:" contiene una coppia di parentesi angolari che racchiudono un addr-spec opzionale. Il campo "Received:" contiene una lista (possibilmente vuota) di token seguita da un punto e virgola e da una specifica di data-ora. Ogni token deve essere una word, un angle-addr, un addr-spec o un domain. Ulteriori restrizioni sono applicate alla sintassi dei campi di traccia dalle specifiche che ne prevedono l'uso, come [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
Una discussione completa dell'uso dei campi di traccia nella posta Internet è contenuta in [RFC5321]. Ai fini di questa specifica, i campi di traccia sono strettamente informativi, e qualunque interpretazione formale di essi è al di fuori dell'ambito di questo documento.
3.6.8. Campi opzionali
Campi possono apparire nei messaggi che non sono altrimenti specificati in questo documento. Essi MUST essere conformi alla sintassi di un optional-field. Si tratta di un nome di campo, composto dai caratteri US-ASCII stampabili eccetto SP e i due punti, seguito da due punti, seguito da qualunque testo conforme alla sintassi unstructured.
I nomi dei campi di qualunque campo opzionale MUST NOT essere identici a qualunque nome di campo specificato altrove in questo documento.
optional-field = field-name ":" unstructured CRLF
field-name = 1*ftext
ftext = %d33-57 / ; Printable US-ASCII
%d59-126 ; characters not including
; ":".
Ai fini di questa specifica, qualunque campo opzionale è non interpretato.