Network Working Group J. Myers Request for Comments: 1939 Carnegie Mellon STD: 53 M. Rose Obsoletes: 1725 Dover Beach Consulting, Inc. Category: Standards Track May 1996 Post Office Protocol - Versione 3 (protocollo POP3) Traduzione a cura di ComiSAT Brescia, Apr. 2003 (comisat@yahoo.it) Distribuita da .::http://www.rfc.altervista.org::. Stato di questa memoria Questo documento specifica una traccia di protocollo Internet standard per la comunita’ Internet, e richiede discussioni e suggerimenti per migliorie. Per la standardizzazione e lo stato di questo protocollo si faccia riferimento all’edizione corrente dell’”Internet Official Protocol Standards” (STD 1). La distribuzione di questo documento non e’ soggetta a limitazioni. Tavola dei contenuti 1. Introduzione ................................................ 2 2. Una breve digressione ....................................... 2 3. Operazioni di base .......................................... 3 4. Stato di AUTORIZZAZIONE ..................................... 4 Comando QUIT ................................................ 5 5. Stato di TRANSAZIONE ........................................ 5 Comando STAT ................................................ 6 Comando LIST ................................................ 6 Comando RETR ................................................ 8 Comando DELE ................................................ 8 Comando NOOP ................................................ 9 Comando RSET ................................................ 9 6. Stato di AGGIORNAMENTO ...................................... 10 Comando QUIT ................................................ 10 7. Comandi POP3 opzionali ...................................... 11 Comando TOP ................................................. 11 Comando UIDL ................................................ 12 Comando USER ................................................ 13 Comando PASS ................................................ 14 Comando APOP ................................................ 15 8. Considerazioni operative e di regolamentazione .............. 16 9. Riepilogo dei comandi POP3 .................................. 18 10. Esempio di sessione POP3 ................................... 19 11. Formato del messaggio ...................................... 19 12. Riferimenti ................................................ 20 13. Considerazioni relative alla sicurezza ..................... 20 14. Ringraziamenti ............................................. 20 15. Indirizzi degli autori ..................................... 21 Appendice A. Differenze dalla RFC 1725 ......................... 22 Appendice B. Indice dei comandi ................................ 23 Myers & Rose Standards Track [Page 1] RFC 1939 POP3 May 1996 1. Introduzione Su determinati tipi di piccoli nodi presenti su Internet e’ spesso poco pratico mantenere un sistema di trasporto di messaggio (MTS). Ad esempio, una workstation potrebbe non avere risorse sufficienti (cicli, spazio su disco) per far si’ che un server SMTP [RFC 821] e il sistema di distribuzione locale della posta associato possano rimanere residenti e girare continuamente. Allo stesso modo, potrebbe risultare dispendioso (o impossibile) mantenere un personal computer interconnesso ad una rete IP per molto tempo (il nodo e’ carente della risorsa nota come “connettivita’”). Malgrado questo, e’ spesso molto utile poter gestire la posta su questi piccoli nodi, e sovente essi supportano un agente d’utente (User Agent – UA) d’aiuto per le mansioni di gestione della posta. Per ovviare a questo problema, un nodo che supporta un’entita’ MTS offre un servizio di maildrop a questi nodi meno dotati. Il Post Office Protocol – Versione 3 (POP3) e’ concepito per permettere ad una workstation di accedere in modo dinamico ad un maildrop su un host server maniera utile. Solitamente, questo significa che il protocollo POP3 viene usato per consentire ad una workstation di richiamare la posta che il server sta mantenendo per lei. Il POP3 non e’ inteso per fornire operazioni aggiuntive di manipolazione della posta presente su un server; normalmente, la posta viene scaricata e poi cancellata. Un protocollo piu’ avanzato (e complesso), l’IMAP4, viene discusso nella [RFC 1730]. Nella parte rimanente di questo documento, il termine “host client” si riferisce ad un host che fa uso del servizio POP3, mentre “host server” indica un host che offre tale servizio. 2. Una breve digressione Questo documento non specifica come un host client inoltri la posta in un sistema di trasporto, anche se viene qui presentato un metodo in linea con la filosofia del presente documento: Quando un agente d’utente su un host client desidera fornire un messaggio in un sistema di trasporto, esso stabilisce una connessione SMTP al suo host trasmittente ed invia ad esso tutta la posta. Tale host trasmittente puo’ essere, ma non necessariamente, l’host server POP3 per l’host client. Chiaramente, l’host trasmittente deve accettare la posta per tutti i destinatari arbitrari, funzionalita’ non richiesta a tutti i server SMTP. Myers & Rose Standards Track [Page 2] RFC 1939 POP3 May 1996 3. Operazioni di base Inizialmente, l’host server inizia un servizio POP3 ascoltando su TCP porta 110. Quando un client desidera usufruire del servizio stabilisce una connessione TCP con l’host server. Una volta stabilita la connessione, il server POP3 invia un saluto. Client e server POP3 si scambiano quindi comandi e risposte (rispettivamente) fino a che’ la connesione non viene terminata o interrotta. Nel POP3 i comandi consistono in parole-chiave case-insensitive [N.d.T.: non vi e’ distinzione tra maiuscole e minuscole] seguite da uno o piu’ argomenti. Tutti i comandi terminano con una coppia CRLF [N.d.T.: Control Return + Line Feed – Ritorno a Capo + Inizio Riga]. Le parole-chiave e gli argomenti sono ciascuno separati da un singolo carattere SPAZIO. Le parole-chiave sono lunghe tre o quattro caratteri. Ciascun argomento, invece, puo’ arrivare fino a 40 caratteri. Le risposte consistono in un indicatore di stato e una parola-chiave possibilmente seguita da informazioni aggiuntive. Tutte le risposte terminano con una coppia CRLF. Le risposte possono arrivare ai 512 caratteri, compresa la sequenza CRLF. Vi sono attualmente due indicatori di stato: positivo (“+OK”) e negativo (“-ERR”). I servers DEVONO inviare il “+OK” e il “-ERR” in caratteri maiuscoli. Le risposte ad alcuni comandi sono multi-linea. In questi casi, indicati chiaramente in seguito, dopo aver inviato la prima linea della risposta ed un CRLF, viene inviata qualsiasi linea aggiuntiva, ciascuna terminata da una coppia CRLF. Quanto tutte le linee della risposta sono state inviate viene spedita una linea finale, che consiste in un ottetto di terminazione (codice decimale 046, “.”) e una sequenza CRLF. Una risposta multi-linea termina cosi’ con i cinque ottetti “CRLF.CRLF”. Nell’esaminare una risposta multi- linea il client controlla se una linea inizia con l’ottetto di terminazione. In caso affermativo e seguono altri ottetti che non siano CRLF, il primo ottetto della linea (quello di terminazione) viene tagliato. Se invece segue subito il CRLF la risposta dal POP server e’ terminata e la linea contenente “.CRLF” non viene considerata parte della risposta multi-linea. Una sessione POP3 progredisce attraverso un numero di stati durante la sua durata. Una volta che la connessione TCP e’ stata aperta e il server POP3 ha inviato il saluto, la sessione apre lo stato di AUTORIZZAZIONE. In tale stato, il client deve identificarsi al server POP3. Una volta che il client lo ha fatto con successo, il server acquisisce le risorse associate alla maildrop del client e si inizia lo stato di TRANSAZIONE. In questo stato, il client richiede azioni da parte del server POP3. Quando il client ha inviato Myers & Rose Standards Track [Page 3] RFC 1939 POP3 May 1996 il comando QUIT, la sessione inizia lo stato di AGGIORNAMENTO. In questo stato il server POP3 rilascia qualsiasi risorsa acquisita durante lo stato di TRANSAZIONE e saluta. La connessione TCP viene chiusa. Un server DEVE rispondere ad un comando non riconosciuto, non implementato o non valido sintatticamente con una risposta il cui indicatore di stato e’ negativo. Un server DEVE rispondere ad un comando inviato quando la sessione e’ in uno stato non corretto con un indicatore di stato negativo. Non vi sono metodi generali per un client per fare distinzione tra un server che non implementa un comando facoltativo e un server che non puo’ o non e’ in grado di processare il comando. Un server POP3 POTREBBE avere un timer automatico di log-out per inattivita’. Un timer simile DEVE essere di almeno 10 minuti di durata. Il ricevimento di un qualsiasi comando del client durante tale intervallo dev’essere sufficiente per resettare il timer di log-out. Quando il timer espira, la sessione NON deve portare allo stato di AGGIORNAMENTO--il server deve chiudere la connessione TCP senza rimuovere alcun messaggio o inviare alcuna risposta al client. 4. Stato di AUTORIZZAZIONE Una volta che la connessione TCP e’ stata aperta dal client POP3, il server POP3 inoltra una linea di benvenuto. Questa puo’ essere una qualsiasi risposta positiva. Un esempio puo’ essere: S: +OK POP3 server ready La sessione POP3 e’ ora nello stato di AUTORIZZAZIONE. Il client deve quindi identificarsi ed autenticarsi al server POP3. Per fare questo, nel presente documento vengono descritte due possibili meccanismi, la combinazione di comando USER e PASS e il comando APOP. Entrambi i metodi sono spiegati piu’ avanti. Nell’[RFC 1734] vengono descritti dei meccanismi di autenticazione aggiuntivi. Sebbene non vi sia un meccanismo di autenticazione richiesto da tutti servers POP3, un server deve supportarne almeno uno. Una volta che il server POP3 ha determinato attraverso l’uso di un qualsiasi comando di autenticazione che al client dovrebbe essere dato l’accesso alla maildrop appropriata, il server POP3 acquisisce una serratura d’accesso- esclusivo sulla maildrop, necessaria per prevenire che i messaggi vengano modificati o rimossi prima che la sessione entri nello stato di AGGIORNAMENTO. Se la serratura viene acquisita con successo, il server POP3 risponde con una risposta di indicatore di stato positivo. La sessione POP3 entra quindi nello stato di TRANSAZIONE, con nessun messaggio contrassegnato come cancellato. Se la maildrop non puo’ essere aperta per qualche ragione (ad esempio, una serratura non puo’ essere acquisita, al client e’ negato Myers & Rose Standards Track [Page 4] RFC 1939 POP3 May 1996 l’accesso alla maildrop appropriata, o la maildrop non puo’ essere analizzata) il server POP3 risponde con un indicatore di stato negativo. (Se la serratura e’ stata acquisita ma il server POP3 intende rispondere con un indicatore di stato negativo, il server deve rilasciare la serratura prima di rifiutare il comando). Una volta ritornato l’indicatore di stato negativo, il server puo’ chiudere la connessione. Se il server non chiude la connessione, il client puo’ fornire un nuovo comando di autenticazione e ricominciare oppure inviare il comando QUIT. Una volta che il server ha aperto la maildrop assegna un numero-di-messaggio a ciascun messaggio, e nota la dimensione in ottetti di ciascun messaggio. Al primo messaggio viene assegnato il numero “1”, al secondo il numero “2”, e cosi’ via, cosi’ che al ennesimo messaggio nella maildrop viene assegnato un numero-di-messaggio pari a “n”. Nei comandi e risposte POP3, tutti i numeri- di-messaggio e la dimensione dei messaggi vengono espressi in base-10 (decimale). Riportiamo qui il riassunto del comando QUIT quando usato nello stato di AUTORIZZAZIONE: QUIT Argumenti: nessuno Restrizioni: nessuna Risposte possibili: +OK Esempi: C: QUIT S: +OK dewey POP3 server signing off 5. Stato di TRANSAZIONE Una volta che il client si e’ identificato con successo al server POP3 e il server ha bloccato e aperto la maildrop appropriata, la sessione POP3 passa allo stato di TRANSAZIONE. Il client puo’ ora fornire qualsiasi dei seguenti comandi POP3, ripetutamente. Dopo ciascun comando il server POP3 invia una risposta. Finalmente, il client invia il comando QUIT e la sessione POP3 entra nello stato di AGGIORNAMENTO. Myers & Rose Standards Track [Page 5] RFC 1939 POP3 May 1996 Si riportano qui i comandi POP3 validi nello stato di TRANSAZIONE: STAT Argomenti: nessuno Restrizioni: Usabile solamente nello stato di TRANSAZIONE Spiegazione: Il server POP3 invia una risposta positiva con una linea contenente informazioni sulla maildrop. Tale linea viene chiamata “drop listing” (elenco) per tale maildrop. Per semplificare l’analisi, a ciascun server POP3 e’ richiesto di utilizzare un determinato formato per l’elencazione. La risposta positiva consiste in un “+OK” seguito da uno spazio singolo, il numero dei messaggi presenti nella maildrop, uno spazio singolo, e la dimensione della maildrop in ottetti. Il presente documento non determina alcun requisito su cosa segua la dimensione. Le implementazioni minime dovrebbero solamente terminare la linea della risposta con una sequenza CRLF. Le implementazioni piu’ avanzate potrebbero includere invece ulteriori informazioni. NOTA: Questo documento scoraggia FORTEMENTE le implementazioni dal fornire informazioni aggiuntive nell’elencazione. Altre facilitazioni, facoltative, che consentono al client di analizzare la maildrop, sono discusse in seguito. Si noti che i messaggi contrassegnati come cancellati non sono conteggiati in alcun totale. Risposte possibili: +OK nn mm Esempi: C: STAT S: +OK 2 320 LIST [msg] Argomenti: Un numero-di-messaggio (facoltativo) il quale NON puo’ riferirsi a messaggi contrassegnati come cancellati, se presenti. Myers & Rose Standards Track [Page 6] RFC 1939 POP3 May 1996 Restrizioni: Usabile solamente nello stato di TRANSAZIONE Spiegazione: Se viene dato un argomento e il server POP3 fornisce una risposta positiva con una linea contenente informazioni per quel messaggiom tale linea viene chiamata “scan listing” (elenco di scansione/esplorazione) per quel messaggio. Se non viene dato alcun argomento e il server POP3 fornisce una risposta positiva, questa e’ una risposta multi-linea. Dopo il +OK iniziale, per ciascun messaggio della maildrop il server POP3 risponde con una linea contenente informazioni per quel messaggio. Anche qui la linea viene chiamata “scan listing” per quel messaggio. Se nella maildrop non vi sono messaggi il server POP3 risponde con nessuna scan listing--esso fornisce una risposta positiva seguita da una linea contenente un ottetto di terminazione e una coppia CRLF. Per semplificare l’analisi, a ciascun server POP3 e’ richiesto di utilizzare un determinato formato per l’elencazione. Una scan- listing consiste nel numero-di-messaggio del messaggio seguito da un singolo spazio e l’esatta dimensione del messaggio in ottetti. I metodi per calcolare l’esatta dimensione del messaggio sono descritti nella sezione “Formato del Messaggio” piu’ avanti. Il presente documento non determina alcun requisito su cosa debba seguire la dimensione del messaggio nella scan listing. Le implementazioni minime dovrebbero solamente terminare la linea della risposta con una sequenza CRLF. Le implementazioni piu’ avanzate potrebbero includere invece ulteriori informazioni, recuperate dal messaggio. NOTA: Questo documento scoraggia FORTEMENTE le implementazioni dal fornire informazioni aggiuntive nell’elencazione. Altre facilitazioni, facoltative, che consentono al client di analizzare i messaggi della maildrop, sono discusse in seguito. Si noti che i messaggi contrassegnati come cancellati non vengono listati. Risposte possibili: +OK scan listing follows (segue l’elenco) -ERR no such message (messaggio non trovato) Esempi: C: LIST S: +OK 2 messages (320 octets) S: 1 120 Myers & Rose Standards Track [Page 7] RFC 1939 POP3 May 1996 S: 2 200 S: . ... C: LIST 2 S: +OK 2 200 ... C: LIST 3 S: -ERR no such message, only 2 messages in maildrop (messaggio non trovato, solo 2 messaggi nella maildrop) RETR msg Argomenti: Un numero-di-messaggio (richiesto) il quale NON puo’ riferirsi a messaggi contrassegnati come cancellati, se presenti. Restrizioni: Usabile solamente nello stato di TRANSAZIONE Spiegazione: Se il server POP3 fornisce una risposta positiva, tale risposta e’ multi-linea. Dopo l’+OK iniziale, il server POP3 invia il messaggio corrispondente al numero-di-messaggio dato, prestando attenzione a riempire il byte con il carattere di terminazione (come per tutte le risposte multi-linea). Risposte possibili: +OK message follows (segue il messaggio) -ERR no such message (messaggio non trovato) Esempi: C: RETR 1 S: +OK 120 octets S: S: . DELE msg Argomenti: Un numero-di-messaggio (richiesto) il quale NON puo’ riferirsi a messaggi contrassegnati come cancellati, se presenti. Restrizioni: Usabile solamente nello stato di TRANSAZIONE Myers & Rose Standards Track [Page 8] RFC 1939 POP3 May 1996 Spiegazione: Il server POP3 contrassegna il messaggio come cancellato. Qualsiasi futuro riferimento in un comando POP3 al numero-di-messaggio associato al messaggio genera un errore. Il server POP3 non cancellera’ il messaggio finche’ la sessione POP3 non entra nello stato di AGGIORNAMENTO. Risposte possibili: +OK message deleted (messaggio cancellato) -ERR no such message (messaggio non trovato) Esempi: C: DELE 1 S: +OK message 1 deleted (messaggio 1 cancellato) ... C: DELE 2 S: -ERR message 2 already deleted (messaggio 2 gia’ cancellato) NOOP Argomenti: nessuno Restrizioni: Usabile solamente nello stato di TRANSAZIONE Spiegazione: Il server POP3 non fa nulla, si limita a rispondere con una risposta positiva. Risposte possibili: +OK Esempi: C: NOOP S: +OK RSET Argomenti: nessuno Restrizioni: Usabile solamente nello stato di TRANSAZIONE Spiegazione: Un qualsiasi messaggio contrassegnato come cancellato dal server POP3 viene decontrassegnato. Il server POP3 risponde quindi Myers & Rose Standards Track [Page 9] RFC 1939 POP3 May 1996 con una risposta positiva. Risposte possibili: +OK Esempi: C: RSET S: +OK maildrop has 2 messages (320 octets) (la maildrop ha 2 messaggi (320 ottetti)) 6. Stato di AGGIORNAMENTO Quando il client fornisce il comando QUIT dallo stato di TRANSAZIONE, la sessione POP3 entra nello stato di AGGIORNAMENTO. (Si tenga presente che se il client invia il comando QUIT dallo stato di AUTORIZZAZIONE, la sessione POP3 viene terminata SENZA passare dallo stato di AGGIORNAMENTO). Se una sessione termina per qualche altro motivo che non sia un comando QUIT inviato dal client, la sessione NON entra nello stato di AGGIORNAMENTO e NON DEVE essere rimosso alcun messaggio dalla maildrop. QUIT Argomenti: nessuno Restrizioni: nessuna Spiegazione: Il server POP3 rimuove dalla maildrop tutti i messaggi contrassegnati come cancellati e replica lo stato di tale operazione. Se si verifica un errore, come una carenza di risorse, durante la rimozione dei messaggi, puo’ succedere che alcuni o nessuno dei messaggi, contrassegnati come cancellati, siano stati rimossi. In nessun caso il server puo’ eliminare dei messaggi che non sono stati contrassegnati come rimossi. Sia che la rimozione abbia avuto successo o meno, il server rilascia qualsiasi blocco d’accesso esclusivo sulla maildrop e chiude la connessione TCP. Risposte possibili: +OK -ERR some deleted messages not removed (alcuni messaggi cancellati non sono stati rimossi) Esempi: C: QUIT S: +OK dewey POP3 server signing off (maildrop empty) ... C: QUIT Myers & Rose Standards Track [Page 10] RFC 1939 POP3 May 1996 S: +OK dewey POP3 server signing off (2 messages left) ... 7. Comandi POP3 opzionali I comandi discussi finora devono essere supportati da tutte le implementazioni minime dei servers POP3. I comandi POP3 facoltativi descritti adesso permettono ad un client POP3 maggior liberta’ nella gestione dei messaggi, pur preservando una semplice implementazione server. NOTA: Questo documento incoraggia FORTEMENTE che le implementazioni supportino questo comandi per rafforzare l’elencazioni scan e drop. In breve, la filosofia di questo documento e’ porre intelligenza a lato client invece che a lato server. TOP msg n Argomenti: Un numero-di-messaggio (richiesto) il quale NON puo’ riferirsi a messaggi contrassegnati come cancellati, e un numero non-negativo di linee (richiesto). Restrizioni: Usabile solamente nello stato di TRANSAZIONE Spiegazione: Se il server POP3 inoltra una risposta positiva, tale risposta e’ multi-linea. Dopo l’+OK iniziale il server invia l’intestazione del messaggio, una linea vuota che separa l’intestazione del corpo, quindi il numero di linee del corpo del messaggio indicato, facendo attenzione a riempire il byte col carattere di terminazione (come per tutte le risposte multi-linea). Si noti che se il numero di linee richiesto dal client e’ superiore al numero di linee del corpo il server invia l’intero messaggio. Risposte possibili: +OK top of message follows (segue la parte superiore del messaggio) -ERR no such message (messaggio non trovato) Esempio: C: TOP 1 10 S: +OK Myers & Rose Standards Track [Page 11] RFC 1939 POP3 May 1996 S: S: . ... C: TOP 100 3 S: -ERR no such message (messaggio non trovato) UIDL [msg] Argomenti: Un numero-di-messaggio (facoltativo) il quale NON puo’ riferirsi a messaggi contrassegnati come cancellati Restrizioni: Usabile solamente nello stato di TRANSAZIONE Spiegazione: Se viene dato un argomento e il server POP3 fornisce una risposta positiva con una linea contenente informazioni per quel messaggio, tale linea viene chiamata “elencazione ad id-univoco” per quel messaggio. Se non vengono specificati argomenti il server POP3 fornisce invece una risposta positiva, multi-linea. Dopo l’+OK iniziale, per ciascun messaggio nella maildrop il server POP3 risponde con una linea contenente informazioni per quel messaggio. Questa linea viene chiamata “elencazione ad id-univoco” per quel messaggio. Per semplificare l’analisi, a tutti i servers POP3 e’ richiesto di utilizzare un determinato formato per l’elencazione ad id-univoco. Tale elencazione consiste in un numero-di-messaggio per il messaggio, seguito da uno spazio singolo e dall’id-univoco del messaggio. Nessun altra informazione segue l’id-univoco nell’elencazione ad id-univoco. L’id-univoco di un messaggio e’ una stringa determinata dal server in maniera arbitraria, consistente da 1 a 70 caratteri nel range 0x21 – 0x7E, che identifica in maniera univoca un messaggio in una maildrop e che persiste attraverso sessioni. Tale persistenza e’ richiesta anche se una sessione termina senza entrare nello stato di AGGIORNAMENTO. Il server non deve mai riutilizzare un id-univoco in una data maildrop, per tutto il tempo in cui l’entita’ che usa l’id-univoco esiste. Si noti che i messaggi contrassegnato come cancelalti non vengono listati. Sebbene sia generalmente preferibile per le implementazioni server memorizzare nella maildrop id-univoci arbitrariamente assegnati, Myers & Rose Standards Track [Page 12] RFC 1939 POP3 May 1996 questa specifica e’ concepita per consentire che gli id-univoci siano calcolati come un hash del messaggio. I clients dovrebbero essere in grado di gestire situazioni in cui due copie identiche di un messaggio di una maildrop abbiano lo stessto id-univoco. Risposte possibili: +OK unique-id listing follows (segue l’elenco degli id-univoci) -ERR no such message (messaggio non trovato) Esempi: C: UIDL S: +OK S: 1 whqtswO00WBw418f9t5JxYwZ S: 2 QhdPYR:00WBw1Ph7x7 S: . ... C: UIDL 2 S: +OK 2 QhdPYR:00WBw1Ph7x7 ... C: UIDL 3 S: -ERR no such message, only 2 messages in maildrop (messaggio non trovato, solamente 2 messaggi nella maildrop) USER nome Argomenti: Una stringa che indentifica una mailbox (richiesta), la quale ha significato SOLAMENTE per il server Restrizioni: Usabile solamente nello stato di AUTORIZZAZIONE dopo il saluto del server POP3 o un comando USER o PASS inviato senza successo Spiegazione: Per autenticare l’uso della combinazione di comando USER e PASS il client deve inoltrare per primo il comando USER. Se il server POP3 risponde con un indicatore di stato positivo (“+ok”), allora il client puo’ inviare il comando PASS per completare l’autenticazione, oppure il comando QUIT per terminare la sessione POP3. Se il server risponde invece con un indicatore di stato negativo (“-ERR”) al comando USER, il client puo’ inviare un nuovo comando di autenticazione oppure inoltrare il comando QUIT. Il server puo’ ritornare una risposta positiva anche se non esiste nessuna mailbox. Il server puo’ ritornare una risposta negativa se la mailbox esiste ma non consente autenticazione password testuale. Myers & Rose Standards Track [Page 13] RFC 1939 POP3 May 1996 Risposte possibili: +OK name is a valid mailbox (il nome e’ una mailbox valida) -ERR never heard of mailbox name (mai sentita un mailnox con tale nome) Esempi: C: USER frated S: -ERR sorry, no mailbox for frated here (spiacente, nessuna mailbox di nome frated esistente) ... C: USER mrose S: +OK mrose is a real hoopy frood PASS stringa Argomenti: Una password server/mailbox specifica (richiesta) Restrizioni: Usabile solamente nello stato di AUTORIZZAZIONE immediatamente dopo un comando USER inviato con successo Spiegazione: Quando il client inoltra un comando PASS, il server POP3 utilizza la coppia di argomenti passati con i comandi USER e PASS per determinare se al client dev’essere dato accesso alla maildrop appropriata. Poiche’ il comando PASS ha esattamente un argomento, un server POP3 puo’ trattare gli spazi nell’argomento come parte della password, anziche’ come separatori d’argomento. Risposte possibili: +OK maildrop locked and ready (mailbox bloccata e pronta) -ERR invalid password (password non valida) -ERR unable to lock maildrop (impossibile bloccare la maildrop) Esempi: C: USER mrose S: +OK mrose is a real hoopy frood C: PASS secret S: -ERR maildrop already locked ... C: USER mrose S: +OK mrose is a real hoopy frood C: PASS secret S: +OK mrose's maildrop has 2 messages (320 octets) Myers & Rose Standards Track [Page 14] RFC 1939 POP3 May 1996 APOP nome valore-di-compendio Argomenti: Una stringa che identifica una mailbox e una stringa di compendio (digest) MD5 (entrambe richieste) Restrizioni: Usabile solamente nello stato di AUTORIZZAZIONE dopo il saluto del server POP3 o un comando USER o PASS inviato senza successo Spiegazione: Normalmente ciascuna sessione POP3 inizia con uno scambio USER/PASS. Questo comporta che una password server/user-id specifica sia inviata in chiaro sulla rete. Per un uso saltuario del POP3 questo non presenta un considerevole rischio. Ad ogni modo, molte implementazioni POP3 lato client si connettono al server POP3 regolarmente--per verificare la presenza di nuova posta. In aggiunta, l’intervallo dell’inizio di sessione puo’ essere dell’ordine di cinque minuti. Cosi’ il rischio di un intercettazione di password e’ sicuramente elevato. E’ quindi richiesto un metodo alternativo di autenticazione, che fornisca sia autenticazione che protezione di risposta ma che non implichi l’invio della password in chiaro sulla rete. Il comando APOP garantisce queste funzionalita’. Un server POP3 che implementa il comando APOP includera’ nel suo banner di saluto un tempo. La sintassi di tale tempo corrisponde al ‘msg-id’ [N.d.T.: identificatore di messaggio] della [RFC 822] e DEVE essere diverso ogni volta che il server POP3 inoltra un banner di saluto. Ad esempio, su un’implementazione UNIX, nella quale viene usato un processo UNIX separato per ciascuna istanza di un server POP3, la sintassi della stringa tempo potrebbe essere: dove ‘ID-processo’ e’ il valore decimale del PID del processo, orologio il valore decimale dell’orologio di sistema e nomehost il nome-di-dominio pienamente-qualificato corrispondente all’host su cui gira il server. Il client POP3 annota tale tempo e fornisce il comando APOP. Il parametro ‘nome’ ha la stessa semantica di quello usato col comando USER. Il parametro ‘valore-di-compendio’ viene calcolato applicando l’algoritmo MD5 [RFC 1321] alla stringa tempo (compresa di parentesi angolari) seguita da una parola segreta condivisa. Myers & Rose Standards Track [Page 15] RFC 1939 POP3 May 1996 Tale parola segreta e’ una stringa nota solamente al client e server POP3. Una grande attenzione dev’essere prestata affinche’ non si verifichi la divulgazione non autorizzata di tale parola poiche’ la conoscenza del segreto consentira’ a qualsiasi entita’ di mascherarsi da utente valido. Il parametro ‘valore-di-compendio’ in se’ e’ un valore di 16-ottetti inviato in formato esadecimale usando caratteri ASCII minuscoli. Quando il server POP3 riceve il comando APOP verifica che sia stato fornito il valore-di-compendio. Se questo e’ corretto il server POP3 invia una risposta positiva e la sessione POP3 entra nello stato di TRANSAZIONE. Al contrario, viene inviata una risposta negativa e la sessione POP3 rimane nello stato di AUTORIZZAZIONE. Si noti che col crescere della lunghezza della parola segreta condivisa cresce anche la difficolta’ di risalirvi. Per questo, le parole segrete condivise dovrebbero essere stringhe lunghe (considerevolmente piu’ lunghe rispetto all’esempio di 8-caratteri riportato qui sotto). Risposte possibili: +OK maildrop locked and ready (maildrop bloccata e pronta) -ERR permission denied (permesso negato) Esempi: S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> C: APOP mrose c4c9334bac560ecc979e58001b3e22fb S: +OK maildrop has 1 message (369 octets) Nel presente esempio la parola segreta condivisa e’ la stringa ‘tanstaaf’. Cosi’, l’algoritmo MD5 viene applicato alla stringa <1896.697170952@dbc.mtview.ca.us>tanstaaf che produce il seguente valore di compendio c4c9334bac560ecc979e58001b3e22fb 8. Considerazioni operative e di regolamentazione Dal momento che alcune delle caratteristiche opzionali fin qui descritte sono state aggiunte al protocollo POP3, e’ stata accumulata esperienza relativa al loro utilizzo in operazioni di posta su vasta scala commerciale nelle quali la maggior parte degli utenti non erano in relazione l’uno con l’altro. In queste e altre situazioni, utenti e fornitori di clients POP3 hanno scoperto che l’uso combinato del comando UIDL e il non inoltro del comando DELE puo’ fornire una debole versione della funzionalita’ di “maildrop come deposito semi-permanente” normalmente associata ad IMAP. Chiaramente le altre Myers & Rose Standards Track [Page 16] RFC 1939 POP3 May 1996 possibilita’ dell’IMAP, come tener d’occhio una connessione esistente per nuovi messaggi arrivati e il supporto di cartelle multiple sul server, non sono presenti nel POP3. Quando tali funzionalita’ sono usate in questo modo da utenti casuali, vi e’ stata la tendenza all’accumulo senza limite sul server di messaggi gia’ letti. Questo e’ chiaramente un modello di comportamento non desiderabile dal punto di vista dell’operatore server. Tale situazione si e’ aggravata per il fatto che le funzionalita’ limitate del POP3 non consentono una gestione efficiente di maildrops in cui sono presenti centinaia se non migliaia di messaggi. Di conseguenza, e’ raccomandato che gli operatori di server con larga scala di multi-utenti, specialmente quelli nei quali l’unico accesso dell’utente alla maildrop e’ via POP3, considerino le seguenti opzioni, quali: * Imporre una quota di spazio maildrop per-utente e simili Uno svantaggio di questa opzione e’ che l’accumulo di messaggi puo’ comportare l’impossibilita’ dell’utente di riceverne di nuovi. Le postazioni che scelgono questa opzione dovrebbero assicurarsi di informare gli utenti dell’imminente o attuale raggiungimento del limite di quota, magari inserendo un appropriato messaggio nella maildrop dell’utente. * Far rispettare una propria politica relativa al mantenimento di mail sul server Le postazioni sono libere di stabilire una politica locale relativa all’archiviazione e al mantenimento di messaggi sul server, sia letti che non letti. Ad esempio, una postazione potrebbe cancellare dal server i messaggi non letti dopo 60 giorni e quelli letti dopo 7. Tali cancellazioni di messaggio sono fuori l’obiettivo del protocollo POP3 e non sono considerate violazioni di protocollo. Gli operatori server che fanno rispettare la politica di eliminazione dovrebbero preoccuparsi di informare tutti gli utenti della politica in vigore. I client non devono dare per scontato che una politica locale automatizzera’ la cancellazione dei messaggi, ma devono continuare a cancellarli esplicitamente mediante l’uso appropriato del comando DELE. Dev’essere evidenziato che far rispettare politiche di cancellazione dei messaggi puo’ causare confusione alla comunita’ degli utenti, dal momento che i loro client POP3 possono contenere opzioni di configurazione per lasciare la posta sul server che pero’ di fatto non saranno supportate dal server. Uno speciale caso di politica di postazione prevede che i messaggi possano essere scaricati solamente una volta dal server, dopodiche’ vengono cancellati. Questo puo’ essere implementato sul software server POP3 Myers & Rose Standards Track [Page 17] RFC 1939 POP3 May 1996 secondo il seguente meccanismo: “a seguito di un login POP3 da parte di un client che e’ terminato con un comando QUIT cancellare tutti i messaggi scaricati durante la sessione per mezzo del comando RETR”. E’ importante che non siano cancellati i messaggi in caso di terminazione anormale (ad es., se non e’ stato ricevuto un QUIT proveniente dal client) della connessione poiche’ il client potrebbe non aver ricevuto o archiviato con successo i messaggi. I server che implementano una politica di scarica-e- cancella potrebbero anche voler disabilitare o limitare il comando opzionale TOP, poiche’ esso potrebbe essere utilizzato come scappatoia alternativa per scaricare interamente i messaggi. 9. Riepilogo dei comandi POP3 Comandi POP3 d’implementazione minima: USER nome valido nello stato di AUTORIZZAZIONE PASS stringa QUIT STAT valido nello stato di TRANSAZIONE LIST [msg] RETR msg DELE msg NOOP RSET QUIT Comandi POP3 facoltativi: APOP nome valore-di-compendio valido nello stato di AUTORIZZAZIONE TOP msg n valido nello stato di TRANSAZIONE UIDL [msg] Risposte POP3: +OK -ERR Si noti che, ad eccezione dei comandi STAT, LIST e UIDL, la risposta significativa data dal server POP3 ad un comando qualsiasi e’ “+OK” e “- ERR”. Qualsiasi testo inoltrato dopo tale risposta puo’ essere ignorato dal client. Myers & Rose Standards Track [Page 18] RFC 1939 POP3 May 1996 10. Esempio di sessione POP3 S: C: S: +OK POP3 server pronto <1896.697170952@dbc.mtview.ca.us> C: APOP mrose c4c9334bac560ecc979e58001b3e22fb S: +OK la maildrop di mrose ha 2 messaggi (320 ottetti) C: STAT S: +OK 2 320 C: LIST S: +OK 2 messaggi (320 ottetti) S: 1 120 S: 2 200 S: . C: RETR 1 S: +OK 120 ottetti S: S: . C: DELE 1 S: +OK messaggio 1 cancellato C: RETR 2 S: +OK 200 ottetti S: S: . C: DELE 2 S: +OK messaggio 2 cancellato C: QUIT S: +OK dewey server POP3 in uscita (maildrop vuota) C: S: 11. Formato del messaggio Tutti i messaggi trasmessi durante una sessione POP3 si presume siano conformi allo standard di formato dei messaggi di testo Internet [RFC 822]. E’ importante notare che il contatore di ottetti per un messaggio sull’host server puo’ differire da quello assegnato a quel messaggio a causa di convenzioni locali per la designazione dell’end-of-line [N.d.T.: fine della linea]. Solitamente, durante lo stato di AUTORIZZAZIONE della sessione POP3, il server POP3 puo’ calcolare la dimensione in ottetti di ciascun messaggio quando esso apre la maildrop. Ad esempio, se il server POP3 rappresenta internamente l’end-of-line come un singolo carattere, il server POP3 conta semplicemente ciascuna presenza di questi caratteri in un messaggio come due ottetti. Si noti che le linee nel messaggio che iniziano con l’ottetto di terminazione non necessitano (e non devono) di essere contate due volte, poiche’ il client POP3 rimuovera’ tutti i caratteri di terminazione superflui quando esso riceve una risposta multi-linea. Myers & Rose Standards Track [Page 19] RFC 1939 POP3 May 1996 12. Riferimenti [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982. [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text Messages", STD 11, RFC 822, University of Delaware, August 1982. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, April 1992. [RFC1730] Crispin, M., "Internet Message Access Protocol - Version 4", RFC 1730, University of Washington, December 1994. [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, Carnegie Mellon, December 1994. 13. Considerazioni relative alla sicurezza Si suppone che l’uso del comando APOP fornisca identificazione d’origine e protezione di risposta per una sessione POP3. Di conseguenza, un server POP3 che implementa sia il comando PASS che il comando APOP non dovrebbe consentire entrambi i metodi di accesso per un dato utente; ovvero, per un dato nome di mailbox e’ consentito l’uso o della sequenza di comando USER/PASS o il comando APOP, ma non entrambi. In piu’, si noti che col crescere della lunghezza della parola segreta condivisa cresce la difficolta’ di risalirvi. I servers che rispondono con –ERR ad un comando USER danno ai potezionali intrusi degli indizi circa la validita’ del nome. L’utilizzo del comando PASS invia password in chiaro sulla rete. L’utilizzo dei comandi RETR e TOP invia posta in chiaro sulla rete. Altre questioni relative alla sicurezza non sono discusse in questo documento. 14. Ringraziamenti La famiglia POP ha una storia lunga e provata. Seppur soprattutto una revisione minore all’RFC 1460, il POP3 si basa sulle idee presentate con le RFCs 918, 937 e 1081. In aggiunta, Alfred Grimstad, Keith McCloghrie e Neil Ostroff hanno contribuito con significanti commenti sul comando APOP. Myers & Rose Standards Track [Page 20] RFC 1939 POP3 May 1996 15. Indirizzi degli autori John G. Myers Carnegie-Mellon University 5000 Forbes Ave Pittsburgh, PA 15213 EMail: jgm+@cmu.edu Marshall T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Mountain View, CA 94043-2186 EMail: mrose@dbc.mtview.ca.us Myers & Rose Standards Track [Page 21] RFC 1939 POP3 May 1996 Appendice A. Differenze dalla RFC 1725 Questo documento e’ una revisione dell’RFC 1725, un Draft Standard [N.d.T.: una bozza dello standard]. Sono state apportate le seguenti modifiche a quel documento: - chiarito che i comandi sono case-insensitive. - specificato che i servers devono inviare le risposte “+OK” e “-ERR” in caratteri maiuscoli. - Specificato che il saluto iniziale e’ una risposta positiva, invece di qualsiasi stringa che puo’ essere una risposta positiva. - chiarito il comportamento per i comandi non implementati. - resi facoltativi i comandi USER e PASS. - chiarito il set di possibili risposte per il comando USER. - invertito l’ordine degli esempi per I comandi USER e PASS, per ridurre confusione. - chiarito che il comando PASS puo’ essere dato solamente subito dopo un comando USER. - chiariti i requisiti di persistenza degli UID e aggiunte alcune note di implementazione. - specificato che il limite della lunghezza di UID e’ da 1 a 70 ottetti. - specificato che il limite della lunghezza dell’indicatore di stato e’ di 512 ottetti, compreso il CRLF. - chiarito che LIST senza argomenti su una mailbox vuota ritorna una validita’. - aggiunto un riferimento dal comando LIST alla sezione relativa al Formato del Messaggio. - chiarito il comportamento di QUIT su un guasto - chiarita la sezione relativa alla sicurezza per non implicare l’uso del comando USER col comando APOP. - aggiunti riferimenti alle RFCs 1730 e 1734 - chiarito il metodo per mezzo del quale un agente d’utente puo’ inoltrare posta sul sistema di trasporto. Myers & Rose Standards Track [Page 22] RFC 1939 POP3 May 1996 - chiarito che il secondo argomento di un comando TOP e’ un numero di linee. - modificato il suggerimento per un server, nella sezione sulle considerazioni relative alla sicurezza, di non accettare entrambi i comandi PASS e APOP per un dato utente, da “deve” a “dovrebbe”. - aggiunta una sezione sulle considerazioni operative e di regolamentazione Appendice B. Indice dei comandi APOP ....................................................... 15 DELE ....................................................... 8 LIST ....................................................... 6 NOOP ....................................................... 9 PASS ....................................................... 14 QUIT ....................................................... 5 QUIT ....................................................... 10 RETR ....................................................... 8 RSET ....................................................... 9 STAT ....................................................... 6 TOP ........................................................ 11 UIDL ....................................................... 12 USER ....................................................... 13 Myers & Rose Standards Track [Page 23]