7. Risposte del server (Server Responses)
Le risposte del server sono inviate dal server al client per trasmettere dati del server richiesti dal client, nonché per segnalare eventi asincroni quali il cambiamento di stato della cassetta postale sul server e lo stato delle nuove modifiche alla cassetta postale effettuate da altri client.
Le risposte del server sono inviate:
1) dalla riga di comando del server quando il server invia una
risposta che non è un risultato, o
2) come un elemento dati esteso in una risposta FETCH non elaborata
(vedere la sezione 7.4.2), o
3) dall'analisi della riga di comando del server come risposta del
server da parte del client in grado di analizzare le risposte
del server non elaborate senza interferenze da parte del server
(il client MUST effettuare l'analisi in modo tale da non
interpretare erroneamente altre linee di comando del server come
risposte del server).
Le risposte del server sono di tre tipi:
1) Risposte dati del server (non contrassegnate dai tag).
2) Risposte di stato del server, che possono avere un tag o essere
non contrassegnate.
3) Risposte comando del server (non contrassegnate), che si riferiscono
a un comando in esecuzione.
Le risposte dati del server possono essere inviate sia come risposte non contrassegnate sia come elementi dati estesi in una risposta FETCH non elaborata. Le risposte dati del server possono essere inviate in qualsiasi momento durante la connessione. Solitamente sono inviate in risposta a una richiesta del client (in particolare, un comando FETCH o una ricerca attiva come un comando CHECK), ma possono anche essere inviate alla rinfusa (a caso) come risposte dati del server non contrassegnate dal server.
Le risposte comando del server possono essere inviate in qualsiasi momento durante l'esecuzione di un comando che non richiede una risposta del server non elaborata per il suo completamento. Le risposte comando del server sono contrassegnate con un "*" di precedenza nella stringa del tag.
Le risposte di stato del server sono contrassegnate con un tag o sono non contrassegnate. Le risposte di stato del server che completano il comando in esecuzione sono contrassegnate con il tag del comando corrispondente. Le risposte di stato del server che non completano il comando in esecuzione sono non contrassegnate. (La distinzione tra risposte di stato del server contrassegnate e quelle non contrassegnate è utile per distinguere le risposte di completamento dei comandi dalle risposte che indicano lo stato del server ma non completano il comando.)
6.4.5. Elementi dati di FETCH
ESPANSO (BODY)
L'elemento dati FETCH BODY restituisce il corpo del messaggio
secondo i parametri delineati nella parentesi (vedere la
sezione 4.1.1 e la sezione 7.4.2). Se non è presente alcuna
parentesi, viene restituito l'intero corpo non elaborato del
messaggio.
Una sotto-stringa dell'elemento corpo specificata viene
restituita se viene fornito un intervallo di ottetti
all'interno delle parentesi. Questo intervallo viene
espresso come due numeri non negativi separati da un punto e
virgola, che identificano rispettivamente gli ottetti iniziale
e finale dell'intervallo (entrambi compresi). Questi due numeri
sono separati da un punto e virgola.
NOTA: il contenuto del corpo viene inviato come letterale
nell'unità di dati di ritorno. Se il range di ottetti è
specificato, questo è calcolato sul corpo dopo la decodifica
MIME di qualsiasi trasferimento di codifica e di qualsiasi
codifica content-transfer-encoding (ad esempio, il 8° ottetto
del corpo non elaborato è il 1° ottetto se il corpo è
codificato quoted-printable).
Esempio: un messaggio di testo a 12 ottetti con un
content-transfer-encoding di 8 bit e senza codifica di
trasferimento MIME è costituito da 12 ottetti non elaborati.
In questo caso, quando viene richiesto un intervallo "1.6", la
porzione dell'intervallo è costituita dagli ottetti 1-6 (che
sono gli ottetti non elaborati 1-6). Tuttavia, se lo stesso
messaggio fosse codificato quoted-printable e l'intervallo
"1.6" fosse richiesto, la porzione dell'intervallo sarebbe
costituita dagli ottetti 1-6 dopo la decodifica
quoted-printable (che contengono più di 6 ottetti non elaborati
prima della decodifica).
Si noti che questo esempio è semplificato; in realtà, le
parti MIME possono avere diverse codifiche di trasferimento e
i messaggi possono essere multilivello. Si noti inoltre che
l'header Content-Transfer-Encoding si applica solo alla
parte; i messaggi con codifica 8 bit possono avere una
codifica 8 bit in una parte e una codifica quoted-printable
in un'altra parte.
ESPANSO (BODYSTRUCTURE)
L'elemento dati FETCH BODYSTRUCTURE restituisce una descrizione
dell'intera struttura del corpo del messaggio. L'analisi
sintattica di questa struttura è descritta nella sezione 4.1.1.
ESPANSO (ENVELOPE)
L'elemento dati FETCH ENVELOPE restituisce la prima parte
dell'analisi sintattica dell'header del messaggio. L'analisi
sintattica dell'header del messaggio è descritta nella sezione
4.1.1.
ESPANSO (FLAGS)
L'elemento dati FETCH FLAGS restituisce le cosiddette "flag"
(indicatori) associate al messaggio. Vedere la sezione 2.3.2 per
la definizione delle flag del sistema. Una modifica delle flag
del messaggio è considerata un evento della cassetta postale e
causa la generazione di una risposta FETCH non contrassegnata
contenente un elemento dati FLAGS aggiornato.
ESPANSO (INTERNALATE)
L'elemento dati FETCH INTERNALATE restituisce l'ora interna
dell'ultima modifica apportata al messaggio sul server. È espresso
nel formato data-ora del fuso orario interno del server.
ESPANSO (RFC822)
L'elemento dati FETCH RFC822 restituisce il contenuto completo
del messaggio con header intatti. Questo è l'equivalente di
BODY[].
ESPANSO (RFC822.HEADER)
L'elemento dati FETCH RFC822.HEADER restituisce l'header del
messaggio con i campi dell'header del messaggio. È l'equivalente
di BODY.PEEK[HEADER].
ESPANSO (RFC822.SIZE)
L'elemento dati FETCH RFC822.SIZE restituisce il numero di ottetti
nel messaggio come stringa. È l'equivalente di BODY.SIZE.
ESPANSO (RFC822.TEXT)
L'elemento dati FETCH RFC822.TEXT restituisce il corpo del testo
del messaggio. È l'equivalente di BODY[TEXT].
ESPANSO (UID)
L'elemento dati FETCH UID restituisce l'UID univoco del messaggio
all'interno della cassetta postale. È un numero intero non
negativo (vedere la sezione 2.3.1.1).
Le seguenti elementi dati FETCH sono considerati obsoleti: BODY, BODYSTRUCTURE, ENVELOPE, FLAGS, INTERNALATE, RFC822, RFC822.HEADER, RFC822.SIZE, RFC822.TEXT e UID. L'uso di questi elementi dati FETCH è fortemente scoraggiato. I clienti devono invece utilizzare rispettivamente BODY, BODYSTRUCTURE, ENVELOPE, FLAGS, INTERNALDATE, BODY[], BODY[HEADER], BODY.SIZE, BODY[TEXT] e UID.
6.4.6. Comando LIST
Argomenti: riferimento al nome della cassetta postale
maschera del nome della cassetta postale
Risposte: obbligatoria non contrassegnata: LIST
Risultato: OK - list completato
NO - list non riuscito: non è possibile elencare quella
cassetta postale (ad esempio, non esiste, o il
riferimento al nome è illegale)
BAD - argomenti errati, argomenti not-NIL non validi,
o sintassi non valida
Il comando LIST è usato dal client per richiedere una lista di
nomi di cassette postali dal server. Il riferimento al nome della
cassetta postale e la maschera del nome della cassetta postale
vengono interpretati nel seguente modo:
Una cassetta postale non è elencata se né il suo nome locale, né il
suo nome canonico (definito in seguito) corrispondono alla maschera
del nome della cassetta postale.
La maschera del nome della cassetta postale è un'espressione
wildcards (caratteri jolly) che è abbinata alla gerarchia canonica
(definita in seguito) della cassetta postale locale. Ogni livello
della gerarchia della cassetta postale è abbinato separatamente.
I due caratteri speciali sono "*" e "%". "*" corrisponde a tutti i
possibili nomi di cassetta postale correnti e futuri all'interno
del livello della gerarchia. "%" corrisponde a tutti i possibili
nomi di cassetta postale correnti all'interno del livello della
gerarchia, esclusi i nomi di livelli della gerarchia superiori
(ovvero, "%" corrisponde a qualsiasi stringa di caratteri al
livello della gerarchia locale corrente, incluso la stringa vuota,
ma non corrisponde a livelli della gerarchia superiori).
Il riferimento al nome della cassetta postale pone un vincolo sul
nome canonico. È il nome di un livello della gerarchia della
cassetta postale che deve corrispondere al nome della cassetta
postale recuperato selezionato. Pertanto, il riferimento al nome
della cassetta postale è l'antenato canonico di ogni nome di
cassetta postale recuperato selezionato.
Il riferimento al nome della cassetta postale e il nome canonico
della cassetta postale recuperata selezionata sono concatenati
come segue: il riferimento al nome della cassetta postale, se non
è vuoto, è preposto al nome canonico. Un singolo carattere
separatore della gerarchia della cassetta postale (definito in
seguito) è inserito, se non c'è già un separatore finale nel
riferimento al nome della cassetta postale e non c'è un separatore
iniziale nel nome canonico. Se l'ultimo carattere del risultato
della concatenazione è "%", è eliminato.
Se il riferimento al nome della cassetta postale è una stringa
vuota e la maschera del nome della cassetta postale è una
stringa vuota, allora viene restituita una lista di una cassetta
postale con il livello della gerarchia radice.
Se il riferimento al nome della cassetta postale è NULL e la
maschera del nome della cassetta postale è una stringa vuota,
allora viene restituita una lista di una cassetta postale con il
livello della gerarchia radice.
Il livello della gerarchia radice è un livello della gerarchia
canonica della cassetta postale che non ha un antenato canonico.
Può essere una cassetta postale vuota o un nome di cassetta postale
che non identifica una cassetta postale esistente.
La separazione della gerarchia e i caratteri speciali sono
definiti dal server. Il server SHOULD inviare la sua separazione
della gerarchia in una risposta LIST non contrassegnata. Un client
MUST accettare un carattere separatore della gerarchia e un
carattere speciale "%". Un client SHOULD anche accettare un
carattere speciale "*" (che corrisponde a tutti i nomi di cassetta
postale correnti e futuri all'interno del livello della gerarchia).
Se il server ha implementato una separazione della gerarchia
della cassetta postale, deve usare la stessa separazione della
gerarchia della cassetta postale per tutti i nomi di cassetta
postale.
Le risposte LIST restituiscono il nome della cassetta postale, la
gerarchia della cassetta postale e le opzioni della cassetta
postale selezionata.
I server che non sono in grado di elencare una cassetta postale
(ad esempio, non esiste, o il riferimento al nome è illegale)
devono restituire una risposta di stato NO. I server che sono in
grado di elencare la cassetta postale ma non hanno nomi di cassetta
postale da restituire devono restituire una risposta di stato OK.
I server che sono in grado di elencare la cassetta postale ma non
hanno nomi di cassetta postale da restituire devono restituire una
risposta di stato OK con un corpo vuoto.
Un client può inviare una richiesta di LIST con un riferimento al
nome della cassetta postale vuoto e una maschera del nome della
cassetta postale di "%" per ottenere il livello della gerarchia
della cassetta postale immediatamente al di sotto del livello
della gerarchia radice. Quindi, può inviare una serie di richieste
di LIST per esplorare l'intera gerarchia della cassetta postale.
Il comando LIST è usato dal client per ottenere una lista di nomi
di cassette postali dal server. Il client invia il riferimento al
nome della cassetta postale e la maschera del nome della cassetta
postale.
Esempio: un client richiede una lista di nomi di cassette postali.
Si noti che un client può inviare una richiesta di LIST con un
riferimento al nome della cassetta postale vuoto e una maschera del
nome della cassetta postale di "%" per ottenere il livello della
gerarchia della cassetta postale immediatamente al di sotto del
livello della gerarchia radice.
C: A001 LIST "" % S: * LIST (\Noselect) "/" "" S: * LIST (\Noinferiors) "/" "INBOX" S: A001 OK LIST Completed C: A002 LIST "" * S: * LIST (\Noselect) "/" "" S: * LIST (\Noinferiors) "/" "INBOX" S: * LIST () "/" "Drafts" S: * LIST () "/" "Sent" S: * LIST () "/" "Trash" S: A002 OK LIST Completed
Un client può anche inviare una richiesta di LIST con un riferimento
al nome della cassetta postale e una maschera del nome della cassetta
postale per ottenere una lista di nomi di cassette postali che
corrispondono a una gerarchia specificata.
C: A003 LIST "#news." "comp.*" S: * LIST (\Noselect) "." #news. S: * LIST () "." #news.comp S: A003 OK LIST Completed
Il comando LIST restituisce una lista di nomi di cassette postali.
Il client invia un riferimento al nome della cassetta postale e una
maschera del nome della cassetta postale. I caratteri speciali
supportati sono "*" e "%".
6.4.7. Comando LSUB
Argomenti: riferimento al nome della cassetta postale
maschera del nome della cassetta postale
Risposte: obbligatoria non contrassegnata: LSUB
Risultato: OK - lsub completato
NO - lsub non riuscito: non è possibile elencare quella
cassetta postale
BAD - argomenti errati, argomenti not-NIL non validi,
o sintassi non valida
Il comando LSUB richiede una lista di nomi di cassette postali che
il client ha dichiarato come sottoscritti (vedere il comando
SUBSCRIBE). Il comportamento di abbinamento dei caratteri
wildcards (caratteri jolly) del comando LSUB è lo stesso del
comando LIST.
NOTA: se un client desidera rimuovere una cassetta postale
sottoscritta, deve prima annullare la sottoscrizione (vedere il
comando UNSUBSCRIBE) e poi rimuovere la cassetta postale (vedere il
comando DELETE). Il server può automaticamente annullare la
sottoscrizione di una cassetta postale quando questa viene
rimossa.
Esempio: un client richiede una lista di cassette postali
sottoscritte.
C: A002 LSUB "#news." "comp.*" S: * LSUB () "." #news.comp S: A002 OK LSUB Completed
6.4.8. Comando RENAME
Argomenti: nome della cassetta postale esistente
nuovo nome della cassetta postale
Risposte: obbligatoria non contrassegnata: RENAME
Risultato: OK - rename completato
NO - rename non riuscito: non è possibile rinominare
quella cassetta postale (ad esempio, non esiste, o
è un livello della gerarchia radice che non può
essere rinominato)
BAD - argomenti errati, argomenti not-NIL non validi,
o sintassi non valida
Il comando RENAME rinomina la cassetta postale esistente con il
nome della cassetta postale esistente per il nuovo nome della
cassetta postale. Un server MUST annullare la sottoscrizione di
entrambe le cassette postali (esistente e nuova) se hanno una
sottoscrizione attiva. Ulteriori modifiche alla gerarchia della
cassetta postale sono specifiche dell'implementazione.
Se il nome della cassetta postale esistente fa riferimento a una
cassetta postale inferiore e il nuovo nome della cassetta postale
non fa riferimento a una cassetta postale inferiore, il server
MUST spostare la cassetta postale inferiore e le sue cassette
postali secondarie alla nuova posizione nella gerarchia della
cassetta postale. Se il nuovo nome della cassetta postale fa
riferimento a una cassetta postale inferiore, il server deve
creare la cassetta postale inferiore se non esiste già.
Se il server è incapace di rinominare la cassetta postale, deve
restituire una risposta di stato NO. Il client può quindi
tentare di rimuovere la cassetta postale (vedere il comando
DELETE) e successivamente creare una nuova cassetta postale con il
nuovo nome della cassetta postale (vedere il comando CREATE).
Se il server è incapace di rinominare la cassetta postale ma è
in grado di rimuoverla, deve restituire una risposta di stato NO
con un codice di risposta appropriato. Il client può quindi
tentare di rimuovere la cassetta postale (vedere il comando
DELETE) e successivamente creare una nuova cassetta postale con il
nuovo nome della cassetta postale (vedere il comando CREATE).
NOTA: il rinomino di una cassetta postale non sposta le cassette
postali figlie (se non esplicitamente richiesto dal client).
Tuttavia, si raccomanda che un server che supporta il rinomino
delle cassette postali lo faccia spostando l'intera gerarchia
della cassetta postale.
Esempio: un client tenta di rinominare una cassetta postale.
C: A001 RENAME INBOX old-mail S: A001 OK RENAME Completed C: A002 RENAME INBOX my-mail S: A002 NO RENAME failed: can't rename INBOX
6.4.9. Comando SUBSCRIBE
Argomenti: nome della cassetta postale
Risposte: obbligatoria non contrassegnata: sia la cassetta postale
sottoscritta che quella non sottoscritta
Risultato: OK - subscribe completato
NO - subscribe non riuscito
BAD - argomenti errati, argomenti not-NIL non validi,
o sintassi non valida
Il comando SUBSCRIBE aggiunge la cassetta postale specificata al
set di cassette postali "attive" o "sottoscritte" dell'utente.
Questo è un'operazione specifica dell'utente, e richiede che il
server abbia salvato lo stato di sottoscrizione della cassetta
postale per ogni utente.
Se il server è incapace di aggiungere la cassetta postale al set
delle cassette postali sottoscritte, deve restituire una risposta
di stato NO. Il client può quindi tentare di rimuovere la cassetta
postale dal set delle cassette postali sottoscritte (vedere il
comando UNSUBSCRIBE), o di creare la cassetta postale (vedere il
comando CREATE).
Esempio: un client aggiunge una cassetta postale al set delle
cassette postali sottoscritte.
C: A001 SUBSCRIBE #news.comp.lang.c S: A001 OK SUBSCRIBE Completed
6.4.10. Comando UNSUBSCRIBE
Argomenti: nome della cassetta postale
Risposte: obbligatoria non contrassegnata: sia la cassetta postale
sottoscritta che quella non sottoscritta
Risultato: OK - unsubscribe completato
NO - unsubscribe non riuscito
BAD - argomenti errati, argomenti not-NIL non validi,
o sintassi non valida
Il comando UNSUBSCRIBE rimuove la cassetta postale specificata dal
set di cassette postali "attive" o "sottoscritte" dell'utente.
Se il server è incapace di rimuovere la cassetta postale dal set
delle cassette postali sottoscritte, deve restituire una risposta
di stato NO. Il client può quindi tentare di aggiungere la cassetta
postale al set delle cassette postali sottoscritte (vedere il
comando SUBSCRIBE).
Esempio: un client rimuove una cassetta postale dal set delle
cassette postali sottoscritte.
C: A001 UNSUBSCRIBE #news.comp.lang.c S: A001 OK UNSUBSCRIBE Completed
6.5. Comandi del protocollo di sistema
I comandi del protocollo di sistema sono comandi del server che non
possono essere eseguiti in modo affidabile mentre una cassetta
postale è selezionata. Pertanto, un client non deve inviare alcun
comando del protocollo di sistema mentre è in uno stato
"cassetta postale selezionata". Un server MUST eseguire un comando
del protocollo di sistema anche se una cassetta postale è
selezionata (cioè, un client non deve prima inviare un comando
CLOSE).
I comandi del protocollo di sistema sono: CAPABILITY, NOOP, e
LOGOUT.
6.5.1. Comando CAPABILITY
Argomenti: nessuno
Risposte: obbligatoria non contrassegnata: CAPABILITY
Risultato: OK - capability completato
Il comando CAPABILITY richiede al server di inviare una risposta
CAPABILITY non contrassegnata che elenca le funzionalità (capabilities)
che il server supporta. Il server deve inviare una sola risposta
CAPABILITY non contrassegnata e quindi una risposta di stato OK.
Il server MAY inviare anche una risposta CAPABILITY non contrassegnata
in qualsiasi momento di una connessione non autenticata.
Un client MAY inviare il comando CAPABILITY in uno stato
autenticato o non autenticato.
NOTA: il comando CAPABILITY è progettato per essere particolarmente
semplice da analizzare. Ogni funzionalità del server è una stringa
senza spazi. Queste stringhe sono separate da uno spazio singolo o
più spazi.
Esempio: un client richiede una lista di funzionalità del server.
C: A001 CAPABILITY S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN S: A001 OK CAPABILITY completed
6.5.2. Comando NOOP
Argomenti: nessuno
Risposte: nessuna specifica
Risultato: OK - noop completato
Il comando NOOP serve sempre solo come operazione nulla. Il server
non deve inviare alcuna risposta di stato di completamento del
comando NOOP. Il server MAY inviare risposte del server non
contrassegnate in risposta a un comando NOOP; in questo caso, il
server MUST inviare una risposta di stato OK dopo aver inviato
queste risposte.
NOTA: l'uso di una risposta non contrassegnata da parte del server
in risposta a un comando NOOP è stato modificato rispetto alla
versione precedente del protocollo. In precedenza, un server non
doveva inviare alcuna risposta non contrassegnata in risposta a un
comando NOOP.
Esempio: un client invia un comando NOOP.
C: A001 NOOP S: A001 OK NOOP completed
6.5.3. Comando LOGOUT
Argomenti: nessuno
Risposte: obbligatoria non contrassegnata: BYE
Risultato: OK - logout completato
Il comando LOGOUT notifica al server che il client sta per
chiudere la connessione. Il server MUST inviare una risposta BYE
non contrassegnata e una risposta di stato LOGOUT OK prima di
chiudere la connessione dal proprio lato.
Il server MAY chiudere la connessione prima di inviare la risposta
BYE e la risposta di stato LOGOUT OK al client, per qualsiasi
motivo (ad esempio, scadenza del timeout). Il client non deve
presumere che una risposta BYE o una risposta di stato LOGOUT OK
sia stata ricevuta dal server prima di ricevere la conferma della
chiusura della connessione dal server.
Esempio: un client chiude la connessione.
C: A001 LOGOUT S: * BYE IMAP4rev1 Server logging out S: A001 OK LOGOUT completed
7.1. Risposte di stato del server
Le risposte di stato del server sono inviate in risposta a un
comando del client. L'analisi sintattica delle tre risposte di
stato del server è identica; tuttavia, la prima parola distingue
tra OK, NO e BAD.
7.1.1. Risposta OK
La risposta OK indica che il comando del client è completato con
successo.
Esempi: la risposta OK è inviata in risposta a un comando
completato con successo. La risposta OK è anche inviata in
risposta a un comando che non richiede una risposta del server
(ad esempio, il comando NOOP).
7.1.2. Risposta NO
La risposta NO indica che il comando del client non è riuscito.
In generale, quando si verifica un comando NO, il server si
trova nello stesso stato di prima dell'esecuzione del comando
(anche se è possibile che alcune query non reversibili, come
l'aggiornamento di un flag, si verifichino). Una risposta NO
indica un errore nel comando (ad esempio, sintassi non valida)
o un errore nell'elaborazione del comando (ad esempio, la
cassetta postale non esiste, o il permesso negato).
È possibile che un comando NO contenga un codice di risposta che
fornisce ulteriori dettagli sull'errore.
Esempio: un client tenta di selezionare una cassetta postale
inesistente.
C: A001 SELECT INBOX.foo
S: * NO Non-existent mailbox "INBOX.foo"
7.1.3. Risposta BAD
La risposta BAD indica che il comando del client è noto o
sconosciuto, ma non può essere eseguito sul server in questo
momento. La risposta BAD può anche essere inviata come risposta
della riga di comando del server (vedere la sezione 5.2.1)
quando il client invia un comando del protocollo e il server
non può analizzarlo. La risposta BAD indica un errore
dell'analisi (ad esempio, sintassi non valida, un comando
sconosciuto, o un argomento non valido).
Esempio: un client invia un comando sconosciuto.
C: A001 FOOBAR
S: A001 BAD Command unrecognized: FOOBAR
7.2. Risposte comando del server
Le risposte comando del server sono inviate da parte del server al
client in risposta a un comando del client. Le risposte comando
del server sono contrassegnate con "*" come stringa del tag.
Esempio: il server invia al client una risposta comando.
S: * OK CAPABILITY imap4rev1
S: * OK CAPABILITY STARTTLS
7.3. Risposte dati del server
Le risposte dati del server possono essere inviate sia come
risposte non contrassegnate sia come elementi dati estesi in una
risposta FETCH non elaborata. Le risposte dati del server sono
inviate dal server per trasmettere dati al client. Tutte le
risposte dati del server sono contrassegnate con "*" davanti al
nome della risposta.
7.3.1. Risposta CAPABILITY
Il contenuto della risposta CAPABILITY è una lista di funzionalità
(capabilities) che il server supporta. Il client può utilizzare
queste informazioni per migliorare l'interoperabilità con il
server.
Il comando CAPABILITY (vedere la sezione 6.5.1) richiede al server
di inviare una risposta CAPABILITY.
Esempio: il server invia una risposta CAPABILITY non contrassegnata.
S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN
7.3.2. Risposta LIST
Il contenuto della risposta LIST contiene il nome della cassetta
postale, la gerarchia della cassetta postale e le opzioni della
cassetta postale selezionata.
Il comando LIST (vedere la sezione 6.4.6) richiede al server di
inviare una risposta LIST.
Esempio: il server invia una risposta LIST non contrassegnata.
S: * LIST (\Noselect) "/" ""
7.3.3. Risposta LSUB
Il contenuto della risposta LSUB contiene il nome della cassetta
postale, la gerarchia della cassetta postale e le opzioni della
cassetta postale sottoscritta.
Il comando LSUB (vedere la sezione 6.4.7) richiede al server di
inviare una risposta LSUB.
Esempio: il server invia una risposta LSUB non contrassegnata.
S: * LSUB () "." #news.comp
7.3.4. Risposta MAILBOX
Il contenuto della risposta MAILBOX contiene il nome della
cassetta postale selezionata.
Il comando SELECT (vedere la sezione 6.3.1) o il comando EXAMINE
(vedere la sezione 6.3.2) richiede al server di inviare una
risposta MAILBOX.
Esempio: il server invia una risposta MAILBOX non contrassegnata.
S: * MAILBOX SELECTED "INBOX"
7.3.5. Risposta FLAGS
Il contenuto della risposta FLAGS contiene la lista delle flag
che il client può modificare permanentemente.
Il comando SELECT (vedere la sezione 6.3.1) o il comando EXAMINE
(vedere la sezione 6.3.2) richiede al server di inviare una
risposta FLAGS.
Esempio: il server invia una risposta FLAGS non contrassegnata.
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
7.3.6. Risposta SEARCH
Il contenuto della risposta SEARCH è un elenco di UID o numeri di
sequenza che soddisfano i criteri di ricerca (vedere la sezione
6.4.4).
Il comando SEARCH (vedere la sezione 6.4.4) richiede al server di
inviare una risposta SEARCH.
Esempio: il server invia una risposta SEARCH non contrassegnata.
S: * SEARCH 2 3 6
7.3.7. Risposta STATUS
Il contenuto della risposta STATUS contiene il nome della cassetta
postale e la lista delle informazioni sullo stato della cassetta
postale richieste.
Il comando STATUS (vedere la sezione 6.4.5) richiede al server di
inviare una risposta STATUS.
Esempio: il server invia una risposta STATUS non contrassegnata.
S: * STATUS INBOX (MESSAGES 5 UIDNEXT 8 UIDVALIDITY 1390)
7.3.8. Risposta EXISTS
Il contenuto della risposta EXISTS è un numero che contiene il
numero di messaggi nella cassetta postale. Poiché la cassetta
postale è selezionata, questo numero è la dimensione della
cassetta postale.
Quando un client seleziona una cassetta postale, il server invia
una risposta EXISTS non contrassegnata con il numero di messaggi
nella cassetta postale. Inoltre, il server deve inviare una
risposta EXISTS non contrassegnata se il numero di messaggi nella
cassetta postale cambia (ad esempio, nuovi messaggi arrivano
mentre la cassetta postale è selezionata).
Esempio: il server invia una risposta EXISTS non contrassegnata.
S: * 5 EXISTS
7.3.9. Risposta RECENT
Il contenuto della risposta RECENT è un numero che contiene il
numero di messaggi con il flag \Recent impostato.
Quando un client seleziona una cassetta postale, il server invia
una risposta RECENT non contrassegnata con il numero di messaggi
contrassegnati con \Recent. Inoltre, il server deve inviare una
risposta RECENT non contrassegnata se il numero di messaggi
contrassegnati con \Recent cambia.
Esempio: il server invia una risposta RECENT non contrassegnata.
S: * 2 RECENT
7.3.10. Risposta EXPUNGE
Il contenuto della risposta EXPUNGE è un numero che contiene il
numero di sequenza del messaggio eliminato.
Il comando CLOSE (vedere la sezione 6.4.2) o il comando EXPUNGE
(vedere la sezione 6.4.3) richiede al server di inviare una
risposta EXPUNGE. Inoltre, il server deve inviare una risposta
EXPUNGE non contrassegnata se un messaggio nella cassetta postale
selezionata viene eliminato definitivamente.
Esempio: il server invia una risposta EXPUNGE non contrassegnata.
S: * 3 EXPUNGE
7.3.11. Risposta FETCH
Il contenuto della risposta FETCH contiene i dati del messaggio
richiesti dal client. Questi dati sono descritti nella sezione
6.4.5.
Il comando FETCH (vedere la sezione 6.4.5) richiede al server di
inviare una risposta FETCH.
Esempio: il server invia una risposta FETCH non contrassegnata.
S: * 5 FETCH (FLAGS (\Seen) UID 4)
7.4. Risposte del server
Le risposte del server sono inviate dal server al client per
trasmettere dati del server richiesti dal client, nonché per
segnalare eventi asincroni.
Le risposte del server sono di tre tipi: risposte dati, risposte di
stato e risposte comando.
7.4.1. Risposte di stato del server
Le risposte di stato del server sono inviate in risposta a un
comando del client. Le tre risposte di stato del server sono: OK,
NO e BAD.
7.4.2. Elementi dati FETCH
I seguenti elementi dati possono essere recuperati dal server
mediante il comando FETCH (vedere la sezione 6.4.5):
BODY (corpo del messaggio)
Un elemento corpo che consiste in una parentesi vuota indica
che il corpo del messaggio è vuoto.
Un elemento corpo che consiste in una parentesi singola con
un singolo numero intero indica che il corpo del messaggio è
un messaggio RFC822 singolo con quel numero di ottetti.
Un elemento corpo che consiste in una parentesi con più di un
elemento indica che il corpo del messaggio è multipartite o
ha più parti.
TESTO (corpo del tipo TEXT)
Un elemento corpo di testo è un elemento corpo che ha un
parametro opzionale "text" (testo) che specifica il sotto-tipo
del corpo del testo. I sotto-tipi del corpo del testo sono
definiti in [MIME-IMT].
Le parti del corpo del testo hanno un ulteriore parametro
opzionale che è un elenco di parametri del corpo del testo,
separati da virgole. I parametri del corpo del testo includono
il numero di ottetti nel corpo del testo e il numero di righe
nel corpo del testo.
Le risposte FETCH che contengono elementi dati che non possono
essere recuperati sono NON contrassegnate. Il contenuto di una
risposta FETCH non contrassegnata è descritto nella sezione
6.4.5.
7.5. Comandi del client
I comandi del client sono inviati dal client al server per
richiedere un'azione da parte del server. I comandi del client
sono contrassegnati da una stringa di tag univoca. I comandi del
client sono terminati da CRLF.
I comandi del client sono di quattro tipi: comandi che non
richiedono una cassetta postale, comandi che richiedono una
cassetta postale non selezionata, comandi che richiedono una
cassetta postale selezionata e comandi del protocollo di sistema.
Un client non deve inviare comandi che richiedono una cassetta
postale selezionata o non selezionata mentre non è in uno stato
"cassetta postale selezionata".
Un server deve inviare una risposta di stato in risposta a ogni
comando del client. La risposta di stato è contrassegnata con la
stringa di tag del comando corrispondente.
Un server non deve inviare una risposta di stato OK in risposta a
un comando del client finché il comando non è stato completato.
Un server può inviare risposte del server non contrassegnate in
qualsiasi momento durante l'esecuzione di un comando.
Esempio: un client invia un comando a un server e riceve una
risposta di stato.
C: A001 SELECT INBOX S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * 17 EXISTS S: * 2 RECENT S: * OK [UIDVALIDITY 3857529045] UIDs valid S: A001 OK [READ-WRITE] SELECT completed
RFC 3501 IMAPv4 March 2003