Passa al contenuto principale

6.3.2 Comando SELECT

Argomenti: nome casella di posta

Risposte:

  • Risposte non taggate RICHIESTE: FLAGS, EXISTS, LIST
  • Risposte OK non taggate RICHIESTE: PERMANENTFLAGS, UIDNEXT, UIDVALIDITY

Risultato:

  • OK - select completata, ora nello stato selezionato
  • NO - select fallita, ora nello stato autenticato: nessuna casella di posta di questo tipo, impossibile accedere alla casella di posta
  • BAD - comando sconosciuto o argomenti non validi

Il comando SELECT seleziona una casella di posta in modo che i messaggi nella casella di posta possano essere accessibili. Prima di restituire un OK al client, il server deve (deve) inviare i seguenti dati non taggati al client. (L'ordine delle singole risposte non è importante.) Si noti che le versioni precedenti di questo protocollo, come la versione IMAP4rev1 specificata in [RFC2060], richiedevano solo le risposte non taggate FLAGS ed EXISTS e il codice di risposta UIDVALIDITY. Le implementazioni client che devono rimanere compatibili con tali versioni IMAP più vecchie devono implementare il comportamento predefinito per i dati mancanti, come discusso con i singoli elementi.

FLAGS Flag definiti nella casella di posta. Vedere la descrizione della risposta FLAGS nella Sezione 7.3.5 per maggiori dettagli.

<n> EXISTS Il numero di messaggi nella casella di posta. Vedere la descrizione della risposta EXISTS nella Sezione 7.4.1 per maggiori dettagli.

LIST Il server deve (deve) restituire una risposta LIST con il nome della casella di posta. L'elenco degli attributi della casella di posta deve (deve) essere accurato. Se il server consente nomi di caselle di posta UTF-8 denormalizzati (vedere Sezione 5.1) e il nome della casella di posta fornito differisce dalla versione normalizzata, il server deve (deve) restituire LIST con l'elemento di dati esteso OLDNAME. Vedere la Sezione 6.3.9.7 per maggiori dettagli.

OK [PERMANENTFLAGS (<elenco>)] Un elenco di flag di messaggio che il client può modificare in modo permanente. Se questo manca, il client dovrebbe presumere che tutti i flag possano essere modificati in modo permanente.

OK [UIDNEXT <n>] Il valore del prossimo identificatore univoco. Fare riferimento alla Sezione 2.3.1.1 per ulteriori informazioni.

OK [UIDVALIDITY <n>] Il valore di validità dell'identificatore univoco. Fare riferimento alla Sezione 2.3.1.1 per ulteriori informazioni.

In una connessione può essere selezionata una sola casella di posta alla volta; l'accesso simultaneo a più caselle di posta richiede più connessioni. Il comando SELECT deseleziona automaticamente qualsiasi casella di posta attualmente selezionata prima di tentare la nuova selezione. Di conseguenza, se una casella di posta è selezionata e viene tentato un comando SELECT che fallisce, nessuna casella di posta è selezionata. Quando si deseleziona una casella di posta selezionata, il server deve (deve) restituire una risposta OK non taggata con il codice di risposta "[CLOSED]" quando la casella di posta attualmente selezionata viene chiusa (vedere Sezione 7.1).

Se il client è autorizzato a modificare la casella di posta, il server dovrebbe (dovrebbe) far precedere il testo della risposta OK taggata dal codice di risposta "[READ-WRITE]".

Se il client non è autorizzato a modificare la casella di posta ma ha accesso in lettura, la casella di posta viene selezionata come di sola lettura e il server deve (deve) far precedere il testo della risposta OK taggata a SELECT dal codice di risposta "[READ-ONLY]". L'accesso di sola lettura tramite SELECT differisce dal comando EXAMINE in quanto alcune caselle di posta di sola lettura possono (possono) consentire la modifica dello stato permanente su base per utente (anziché globale). I messaggi Netnews contrassegnati in un file .newsrc basato su server sono un esempio di tale stato permanente per utente che può essere modificato con caselle di posta di sola lettura.

Esempio:

C: A142 SELECT INBOX
S: * 172 EXISTS
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: * LIST () "/" INBOX
S: A142 OK [READ-WRITE] SELECT completed

Esempio:

C: A142 SELECT INBOX
S: * 172 EXISTS
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: A142 OK [READ-WRITE] SELECT completed
[...qualche tempo dopo...]
C: A143 SELECT Drafts
S: * OK [CLOSED] Previous mailbox is now closed
S: * 5 EXISTS
S: * OK [UIDVALIDITY 9877410381] UIDs valid
S: * OK [UIDNEXT 102] Predicted next UID
S: * LIST () "/" Drafts
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \Answered \Flagged \Draft \*)] System flags and keywords allowed
S: A143 OK [READ-WRITE] SELECT completed

Si noti che i server conformi a IMAP4rev1 possono anche inviare la risposta RECENT non taggata che è stata deprecata in IMAP4rev2, ad esempio "* 0 RECENT". I client IMAP4rev2 puri sono invitati a ignorare la risposta RECENT non taggata.

Ultimo aggiornamento il