2. Panoramica del protocollo (Protocol Overview)
2.1. Livello di collegamento (Link Level)
Il protocollo IMAP4rev1 presuppone un flusso di dati affidabile come quello fornito da TCP. Quando viene utilizzato TCP, un server IMAP4rev1 ascolta sulla porta 143.
2.2. Comandi e risposte (Commands and Responses)
Una connessione IMAP4rev1 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, dati server e una risposta di risultato di completamento comando server.
Tutte le interazioni trasmesse dal client e dal server sono sotto forma di righe, cioè stringhe che terminano con un CRLF. Il ricevitore di protocollo di un client o server IMAP4rev1 sta leggendo una riga o sta leggendo una sequenza di ottetti con un conteggio noto seguito 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 è prefissato da un identificatore (tipicamente una breve stringa alfanumerica, ad esempio A0001, A0002, ecc.) chiamato "tag". Un tag diverso è generato dal client per ogni comando.
I client devono (MUST) seguire rigorosamente la sintassi delineata in questa specifica. È un errore di sintassi inviare un comando con spazi o argomenti mancanti o estranei.
Ci sono due casi in cui una riga dal client non rappresenta un comando completo. In un caso, un argomento di comando è quotato con un conteggio di ottetti (vedere la descrizione del letterale in String sotto Formati di dati); nell'altro caso, gli argomenti del comando richiedono feedback dal server (vedere il comando AUTHENTICATE). In entrambi i casi, il server invia una risposta di richiesta di continuazione comando se è pronto per gli ottetti (se appropriato) e il resto del comando. Questa risposta è prefissata dal token "+".
Nota: Se invece, il server rileva 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 taggati. In entrambi i casi, la richiesta di continuazione comando è ancora in sospeso; il client esegue l'azione appropriata per la risposta e legge un'altra risposta dal server. In tutti i casi, il client deve (MUST) inviare un comando completo (inclusa la ricezione di tutte le risposte di richiesta di continuazione comando e continuazioni di comando per il comando) prima di iniziare un nuovo comando.
Il ricevitore di protocollo di un server IMAP4rev1 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 comando 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 prefissate dal token "*", e sono chiamate risposte non taggate (untagged responses).
I dati server possono (MAY) essere inviati come risultato di un comando client, o possono (MAY) essere inviati unilateralmente dal server. Non c'è differenza sintattica tra i dati server che risultano da un comando specifico e i dati server che sono stati inviati unilateralmente.
La risposta di risultato di completamento server indica il successo o il fallimento dell'operazione. È taggata con lo stesso tag del comando client che ha iniziato l'operazione. Quindi, se più di un comando è in corso, il tag in una risposta di completamento server identifica il comando a cui la risposta si applica. Ci sono tre possibili risposte di completamento server: OK (che indica il successo), NO (che indica il fallimento), o BAD (che indica un errore di protocollo come comando non riconosciuto o errore di sintassi del comando).
I server dovrebbero (SHOULD) applicare rigorosamente la sintassi delineata in questa specifica. Qualsiasi comando client con un errore di sintassi di protocollo, inclusi (ma non limitati a) spazi o argomenti mancanti o estranei, dovrebbe (SHOULD) essere rifiutato con una risposta di completamento BAD.
2.3. Attributi dei messaggi (Message Attributes)
Oltre agli attributi dei messaggi (Message Attributes), IMAP supporta diversi elementi di dati definiti dal server. Questi elementi di dati server possono variare in base all'implementazione del server e sono estensibili.
2.3.1. Numeri di messaggio (Message Numbers)
I messaggi sono identificati da un numero di sequenza di messaggio (Message Sequence Number) o da un identificatore univoco (Unique Identifier, UID).
2.3.1.1. Attributo di messaggio identificatore univoco (UID) (Unique Identifier (UID) Message Attribute)
L'identificatore univoco (Unique Identifier, UID) è un valore a 32 bit associato a un messaggio in una mailbox. Questo identificatore univoco deve (MUST) essere univoco nella mailbox nel tempo. Gli UID non cambiano quando i messaggi vengono eliminati.
Gli UID devono (MUST) essere strettamente crescenti.
Ogni volta che un messaggio viene aggiunto alla mailbox, gli viene assegnato un UID maggiore di qualsiasi UID precedentemente utilizzato, anche se gli UID precedenti non sono più utilizzati (cioè se i messaggi sono stati eliminati).
Il requisito di unicità degli UID richiede che il server mantenga un record di ogni UID precedentemente utilizzato e non lo riutilizzi. Il modo più semplice per garantire l'unicità degli UID è semplicemente assegnare UID in modo monotono, cioè assegnare a ogni nuovo messaggio in arrivo un UID superiore di uno rispetto a quello del messaggio precedente.
2.3.1.2. Attributo di messaggio numero di sequenza di messaggio (Message Sequence Number Message Attribute)
Il numero di sequenza di messaggio (Message Sequence Number) è la posizione relativa di un messaggio nella mailbox. I numeri di sequenza di messaggio sono numeri interi consecutivi da 1 al numero totale di messaggi nella mailbox.
I numeri di sequenza di messaggio possono cambiare quando il contenuto della mailbox cambia. In particolare, quando i messaggi vengono eliminati o aggiunti, tutti i numeri di sequenza di messaggio dopo il numero di sequenza di messaggio interessato cambiano.
I numeri di sequenza di messaggio sono validi solo durante la sessione. Quando la sessione termina, i numeri di sequenza di messaggio perdono il loro significato.
2.3.2. Attributo di messaggio flag (Flags Message Attribute)
I flag sono parole chiave o token associati a un messaggio. Ci sono due tipi di flag: flag di sistema e parole chiave.
I flag di sistema sono flag con significato speciale che iniziano con il carattere backslash (""). I flag di sistema sono:
\Seen- Il messaggio è stato letto\Answered- Il messaggio è stato risposto\Flagged- Il messaggio è contrassegnato\Deleted- Il messaggio è contrassegnato per l'eliminazione\Draft- Il messaggio è una bozza\Recent- Il messaggio è arrivato di recente (questa sessione)
Le parole chiave sono flag definiti dal server o dal client. Le parole chiave non devono (MUST NOT) iniziare con un backslash.
2.3.3. Attributo di messaggio data interna (Internal Date Message Attribute)
La data interna (Internal Date) è la data e l'ora in cui il messaggio è arrivato nella mailbox. Questo può essere diverso dal campo dell'intestazione Date: del messaggio.
2.3.4. Attributo di messaggio dimensione [RFC-2822] ([RFC-2822] Size Message Attribute)
La dimensione [RFC-2822] è la dimensione del messaggio in ottetti.
2.3.5. Attributo di messaggio struttura della busta (Envelope Structure Message Attribute)
La struttura della busta (Envelope Structure) è l'informazione derivata dall'intestazione del messaggio.
2.3.6. Attributo di messaggio struttura del corpo (Body Structure Message Attribute)
La struttura del corpo (Body Structure) è l'informazione sulla struttura MIME del messaggio.
2.4. Testi dei messaggi (Message Texts)
I testi dei messaggi (Message Texts) includono l'intestazione completa e il corpo del messaggio. I testi dei messaggi devono (MUST) essere in formato [RFC-2822].