2. Panoramica del protocollo (Protocol Overview)

2.1 Livello di collegamento (Link Level)

Il protocollo IMAP4rev2 presuppone un flusso di dati affidabile come quello fornito da TCP. Quando si usa TCP, un server IMAP4rev2 ascolta sulla porta 143 (porta in chiaro) o sulla porta 993 (porta TLS implicita).

2.2 Comandi e risposte (Commands and Responses)

Una connessione (Connection) IMAP4rev2 consiste nell'instaurazione di una connessione di rete client/server, un saluto iniziale dal server e interazioni client/server. Queste interazioni client/server consistono in un comando client (Client Command), dati server (Server Data) e una risposta di risultato di completamento del server (Server Completion Result Response).

Tutte le interazioni trasmesse dal client e dal server sono sotto forma di righe, cioè stringhe che terminano con CRLF. Il ricevitore di protocollo di un client o server IMAP4rev2 legge una riga o una sequenza di ottetti con un conteggio noto seguita da una riga.

2.2.1 Mittente di protocollo client e ricevitore di protocollo server (Client Protocol Sender and Server Protocol Receiver)

Il comando client inizia un'operazione. Ogni comando client è preceduto da un identificatore (tipicamente una breve stringa alfanumerica, ad es. A0001, A0002, ecc.) chiamato "tag". Il client genera un tag diverso per ogni comando. Più formalmente: il client dovrebbe (dovrebbe) generare un tag univoco per ogni comando, ma un server deve (deve) accettare il riutilizzo dei tag.

I client devono (devono) seguire rigorosamente la sintassi delineata in questa specifica. È un errore di sintassi inviare un comando con spazi o argomenti mancanti o superflui.

Ci sono due casi in cui una riga dal client non rappresenta un comando completo. In un caso, un argomento di comando è citato con un conteggio di ottetti (vedi la descrizione di literal nella sezione 4.3); nell'altro caso, gli argomenti del comando richiedono feedback dal server (vedi il comando AUTHENTICATE nella sezione 6.2.2). In entrambi i casi, il server invia una risposta di richiesta di continuazione del comando (Command Continuation Request Response) se è pronto per gli ottetti (se appropriato) e il resto del comando. Questa risposta è preceduta dal token "+".

Nota: Se, invece, il server ha rilevato un errore nel comando, invia una risposta di completamento BAD con un tag corrispondente al comando (come descritto di seguito) per rifiutare il comando e impedire al client di inviare altro del comando.

È anche possibile che il server invii una risposta di completamento per qualche altro comando (se più comandi sono in corso) o dati non contrassegnati (Untagged Data). In entrambi i casi, la richiesta di continuazione del comando è ancora in sospeso; il client intraprende l'azione appropriata per la risposta e legge un'altra risposta dal server. In tutti i casi, il client deve (deve) inviare un comando completo (compresa la ricezione di tutte le risposte di richiesta di continuazione del comando e l'invio di continuazioni di comando per il comando) prima di avviare un nuovo comando.

Il ricevitore di protocollo di un server IMAP4rev2 legge una riga di comando dal client, analizza il comando e i suoi argomenti e trasmette dati server e una risposta di risultato di completamento del comando del server.

2.2.2 Mittente di protocollo server e ricevitore di protocollo client (Server Protocol Sender and Client Protocol Receiver)

I dati trasmessi dal server al client e le risposte di stato che non indicano il completamento del comando sono preceduti dal token "*" e sono chiamate risposte non contrassegnate (Untagged Responses).

I dati del server possono (può) essere inviati come risultato di un comando client o possono (può) essere inviati unilateralmente dal server. Non c'è differenza sintattica tra i dati server risultanti da un comando specifico e i dati server inviati unilateralmente.

La risposta di risultato di completamento del server indica il successo o il fallimento dell'operazione. È contrassegnata con lo stesso tag del comando client che ha iniziato l'operazione. Quindi, se più comandi sono in corso, il tag in una risposta di completamento del server identifica il comando a cui si applica la risposta. Ci sono tre possibili risposte di completamento del server: OK (indica successo), NO (indica fallimento), o BAD (indica un errore di protocollo come un comando non riconosciuto o un errore di sintassi del comando).

Le risposte e i dati inviati dal server al client non devono (non deve) utilizzare tag di comando non descritti nella sintassi formale (Formal Syntax).

La risposta di risultato di completamento del server può (può) contenere un codice di risposta (Response Code) opzionale che fornisce informazioni aggiuntive sullo stato di completamento. I codici di risposta consistono in dati racchiusi tra parentesi quadre ([...]). I client che non comprendono un particolare codice di risposta devono (devono) essere in grado di accettare quel codice di risposta senza effetti negativi. Ciò significa che qualsiasi codice di risposta può essere aggiunto in modo sicuro a qualsiasi risposta di completamento senza causare problemi ai client più vecchi.

Il ricevitore di protocollo di un client IMAP4rev2 legge le risposte dal server e le elabora in modo appropriato.

---

2.3 Attributi del messaggio (Message Attributes)

Oltre ai testi dei messaggi (Message Texts), diversi attributi (Attributes) sono associati a ciascun messaggio. Questi attributi possono essere recuperati tramite numero di sequenza del messaggio (Message Sequence Number) o identificatore univoco (Unique Identifier, UID).

2.3.1 Numeri di messaggio (Message Numbers)

I messaggi hanno due forme di identificazione: numero di sequenza del messaggio e identificatore univoco (UID).

2.3.1.1 Attributo del messaggio identificatore univoco (UID) (Unique Identifier (UID) Message Attribute)

Un identificatore univoco (Unique Identifier, UID) è un valore intero senza segno non zero a 32 bit associato a un messaggio. Lo scopo principale dell'UID è fornire un identificatore per il messaggio che persiste attraverso più sessioni (Sessions) IMAP. Il server deve (deve) garantire che venga assegnato un UID univoco a ciascun messaggio nella casella di posta.

A differenza dei numeri di sequenza dei messaggi, l'UID di un messaggio aumenta rigorosamente (ma non necessariamente consecutivamente), anche durante la sessione. Il server deve (deve) garantire che se viene aggiunto un nuovo messaggio alla casella di posta, l'UID del nuovo messaggio sia maggiore dell'UID di qualsiasi messaggio esistente nella casella di posta.

Un'eccezione all'unicità e al rigoroso aumento dell'UID è il valore di validità UID (UIDVALIDITY Value). Il valore UIDVALIDITY è associato alla casella di posta ed è restituito con la casella di posta (ad esempio, nelle risposte SELECT ed EXAMINE). Il valore UIDVALIDITY viene utilizzato per rilevare se gli UID nella casella di posta sono stati reimpostati.

Il valore UIDVALIDITY deve (deve) essere maggiore di zero. Lo scopo principale del valore UIDVALIDITY è fornire una garanzia nei casi in cui la persistenza dell'UID non può essere mantenuta. Ad esempio, nei seguenti casi, il server deve (deve) utilizzare un valore UIDVALIDITY diverso nelle sessioni future:

1. Una casella di posta deve (deve) essere assegnata un nuovo valore UIDVALIDITY se i messaggi corrispondenti agli UID esistenti non sono più validi nella casella di posta. Ad esempio, se la casella di posta viene eliminata e ricreata.

2. Per chiarezza: se viene eliminata una vecchia casella di posta e viene creata una nuova casella di posta con lo stesso nome, la nuova casella di posta deve (deve) avere un valore UIDVALIDITY diverso dalla vecchia casella di posta.

3. Una casella di posta non deve (non deve) essere spostata da un server IMAP a un altro server IMAP senza modificare il suo valore UIDVALIDITY, a meno che entrambi i server IMAP forniscano accesso a un repository di caselle di posta comune. Caso speciale: il server può (può) riassegnare una casella di posta a un utente diverso con un valore UIDVALIDITY diverso mantenendo lo stesso nome.

4. La combinazione di nome casella di posta, UIDVALIDITY e UID deve (deve) fare riferimento per sempre a un singolo messaggio immutabile (o eliminato) su quel server. In particolare, la data interna (Internal Date), RFC822.SIZE, la busta (Envelope), la struttura del corpo (Body Structure) e i testi dei messaggi (tutti gli elementi di dati di recupero BODY[...]) non devono mai (deve) cambiare. Ciò non include i numeri di sequenza dei messaggi, né include gli attributi che possono essere impostati da un comando STORE (come FLAGS). Quando un messaggio viene eliminato, il suo UID non deve (non deve) essere riutilizzato sotto lo stesso valore UIDVALIDITY.

2.3.1.2 Attributo del messaggio numero di sequenza del messaggio (Message Sequence Number Message Attribute)

Un numero di sequenza del messaggio (Message Sequence Number) è una posizione relativa da 1 al numero di messaggi nella casella di posta. Questa posizione deve (deve) essere ordinata per identificatori univoci crescenti. Quando viene aggiunto ogni nuovo messaggio, gli viene assegnato un numero di sequenza del messaggio che è 1 superiore al numero di messaggi nella casella di posta prima che quel nuovo messaggio fosse aggiunto.

I numeri di sequenza dei messaggi possono essere riassegnati durante la sessione. Ad esempio, quando un messaggio viene rimosso permanentemente (expunged) dalla casella di posta, il numero di sequenza del messaggio di tutti i messaggi successivi viene decrementato. Il numero di messaggi nella casella di posta viene anche decrementato. Allo stesso modo, a un nuovo messaggio può essere assegnato un numero di sequenza del messaggio che era una volta detenuto da qualche altro messaggio prima di un'eliminazione.

Oltre ad accedere ai messaggi tramite la posizione relativa nella casella di posta, i numeri di sequenza dei messaggi possono essere utilizzati nei calcoli matematici. Ad esempio, se viene ricevuto un "11 EXISTS" non contrassegnato, e in precedenza è stato ricevuto un "8 EXISTS" non contrassegnato, sono arrivati tre nuovi messaggi con numeri di sequenza del messaggio 9, 10 e 11. Come altro esempio, se il messaggio 287 in una casella di posta di 523 messaggi ha UID 12345, ci sono esattamente 286 messaggi che hanno UID inferiori e 236 messaggi che hanno UID maggiori.

2.3.2 Attributo del messaggio flag (Flags Message Attribute)

Un messaggio ha un elenco di zero o più token denominati (Named Tokens), noti come "flag", ad esso associati. Un flag viene impostato aggiungendolo a questo elenco e viene cancellato rimuovendolo. Ci sono due tipi di flag in IMAP4rev2: flag di sistema (System Flags) e parole chiave (Keywords). Un flag di entrambi i tipi può essere permanente o solo per la sessione.

Un flag di sistema è un nome di flag predefinito in questa specifica e inizia con "". Alcuni flag di sistema (\Deleted e \Seen) hanno semantiche speciali descritte altrove in questo documento. I flag di sistema attualmente definiti sono:

• \Seen - Il messaggio è stato letto
• \Answered - Il messaggio ha ricevuto risposta
• \Flagged - Il messaggio è "contrassegnato" per attenzione urgente/speciale
• \Deleted - Il messaggio è "eliminato" per la rimozione successiva da EXPUNGE
• \Draft - Il messaggio non ha completato la composizione (contrassegnato come bozza)
• \Recent - Questo flag era in uso in IMAP4rev1 ed è ora deprecato

Una parola chiave (Keyword) è definita dall'implementazione del server. Le parole chiave non iniziano con "". I server possono (può) consentire al client di definire nuove parole chiave nella casella di posta (vedere la descrizione del codice di risposta PERMANENTFLAGS per ulteriori informazioni). Alcune parole chiave che iniziano con "$" sono anche definite in questa specifica.

Questo documento definisce diverse parole chiave che non erano originariamente definite in [RFC3501] ma sono state ritenute utili dalle implementazioni client. Queste parole chiave dovrebbero (dovrebbe) essere supportate dalle implementazioni server (consentite in SEARCH e consentite e conservate nei comandi APPEND, COPY e MOVE):

$Forwarded - Il messaggio è stato inoltrato a un altro indirizzo e-mail

$MDNSent - La notifica di disposizione del messaggio (Message Disposition Notification) è stata inviata

$Junk - Il messaggio contiene spam/posta indesiderata

$NotJunk - Il messaggio non contiene spam

$Phishing - Il messaggio è probabilmente un'e-mail di phishing

$Junk e $NotJunk sono mutuamente esclusivi. Se più di uno di questi è impostato per un messaggio, il client deve (deve) trattarlo come se nessuno fosse impostato, e dovrebbe (dovrebbe) disattivare entrambi sul server IMAP.

Altre parole chiave registrate possono essere trovate nel registro "IMAP and JMAP Keywords" [IMAP-KEYWORDS-REG]. Le nuove parole chiave dovrebbero (dovrebbe) essere registrate in questo registro utilizzando la procedura specificata in [RFC5788].

Un flag può essere permanente o solo per la sessione su base per-flag. I flag permanenti (Permanent Flags) sono quelli che il client può aggiungere o rimuovere dai flag del messaggio in modo permanente; cioè, le sessioni concorrenti e successive vedranno qualsiasi modifica ai flag permanenti. Le modifiche ai flag di sessione (Session Flags) sono valide solo in quella sessione.

2.3.3 Attributo del messaggio data interna (Internal Date Message Attribute)

Un attributo del messaggio data interna (Internal Date) è la data e l'ora interne del messaggio sul server. Questa non è la data e l'ora nell'intestazione [RFC5322] ma piuttosto una data e un'ora che riflette quando il messaggio è stato ricevuto. Nel caso di messaggi consegnati tramite [SMTP], questa è la data e l'ora della consegna finale del messaggio come definito da [SMTP]. Nel caso di messaggi creati dai comandi IMAP4rev2 COPY o APPEND, questa è la data e l'ora specificate da quei comandi.

2.3.4 Attributo del messaggio RFC822.SIZE (RFC822.SIZE Message Attribute)

RFC822.SIZE è il numero di ottetti nel messaggio quando il messaggio è espresso nel formato [RFC5322]. Questa dimensione dovrebbe (dovrebbe) corrispondere al risultato di un comando "FETCH BODY[]". Se il messaggio è memorizzato internamente in qualche altro formato, il server calcola la dimensione e spesso la memorizza per uso successivo per evitare la necessità di ricalcolo.

2.3.5 Attributo del messaggio struttura busta (Envelope Structure Message Attribute)

Una struttura busta (Envelope Structure) è una rappresentazione analizzata dell'intestazione [RFC5322] del messaggio. Si noti che la struttura busta IMAP non è la stessa di una busta [SMTP].

2.3.6 Attributo del messaggio struttura corpo (Body Structure Message Attribute)

Una struttura corpo (Body Structure) è una rappresentazione analizzata delle informazioni sulla struttura del corpo [MIME-IMB] del messaggio.

2.4 Testi dei messaggi (Message Texts)

Oltre a poter recuperare il testo [RFC5322] completo di un messaggio, IMAP4rev2 consente il recupero di porzioni del testo completo del messaggio. In particolare, è possibile recuperare l'intestazione del messaggio [RFC5322] (Message Header), il corpo del messaggio [RFC5322] (Message Body), una parte del corpo [MIME-IMB] (Body Part) o un'intestazione [MIME-IMB].

---