Network Working Group R. Gellens Request for Comments: 3206 QUALCOMM Category: Standards Track February 2002 I codici di risposta POP 'SYS' e 'AUTH' Traduzione a cura di ComiSAT Brescia, Apr. 2004 (comisat@yahoo.it) Distribuita da .::http://www.rfc.altervista.org::. Stato di Questo Documento Questo documento specifica una traccia standard di protocollo Internet per la comunita' Internet, e richiede discussioni e suggerimenti per migliorie. Per lo stato di standardizzazione e lo status di questo protocollo si prega di far riferimento all'edizione corrente dell' "Internet Official Protocol Standards" (STD 1). La distribuzione di questo documento non e' soggetta a limitazioni. Nota di Copyright Copyright (C) The Internet Society (2002). All Rights Reserved. Sunto Questo documento propone due codici di risposta: SYS e AUTH, i quali abilitano i clients a determinare senza ambiguita' una risposta ottimale ad un'autenticazione senza successo. In aggiunta, viene definita' una nuova possibilita' (AUTH-RESP-CODE). Indice dei Contenuti 1. Introduzione . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Convenzioni usate nel documento . . . . . . . . . . . . . . . 2 3. Background . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Il codice di risposta SYS . . . . . . . . . . . . . . . . . . 3 5. Il codice di risposta AUTH . . . . . . . . . . . . . . . . . 3 6. La possibilita' AUTH-RESP-CODE . . . . . . . . . . . . . . . 4 7. Considerazioni IANA . . . . . . . . . . . . . . . . . . . . 4 8. Considerazioni sulla sicurezza . . . . . . . . . . . . . . . 4 9. Riferimenti . . . . . . . . . . . . . . . . . . . . . . . . 5 10. Indirizzo dell'autore . . . . . . . . . . . . . . . . . . . . 5 11. Dichiarazione completa di Copyright. . . . . . . . . . . . . 6 Gellens Standards Track [Page 1] RFC 3206 The SYS and AUTH POP Response Codes February 2002 1. Introduzione L'RFC 2449 [POP3-EXT] ha definito i codici di risposta estesi [POP3] per dare ai clients maggiori informazioni relativamente agli errori, cosi' che questi possano rispondere in maniera piu' appropriata. In aggiunta a questo meccanismo sono stati definiti due codici di risposta iniziali (IN-USE e LOGIN-DELAY), nel tentativo di differenziare tra insuccessi di autenticazioni relativi a credenziali utente e altri errori. Nella pratica, questi due codici di risposta, sebbene siano d'aiuto, non vanno lontano abbastanza. Questo documento propone due codici di risposta aggiuntivi, il SYS e l'AUTH, i quali abilitano i clients a determinare senza ambiguita' una risposta ottimale ad un'autenticazione avvenuta senza successo. Viene inoltre definite una nuova possibilita' (AUTH-RESP-CODE). 2. Convenzioni usate nel Documento I termini "DEVE", "NON DEVE", "RICHIESTO", "DOVRA'", "NON DOVRA'", "DOVREBBE", "NON DOVREBBE", "RACCOMANDATO", "PUO'", e "FACOTATIVO" usati in questo documento devono essere interpretati come descritto nell'RFC 2119 [KEYWORDS]. 3. Background L'RFC 2449 [POP3-EXT] introdusse i codici di risposta IN-USE e LOGIN-DELAY. L'intenzione era quella di consentire ai clients di determinare chiaramente la causa che sta dietro ad un insuccesso per poter cosi' rispondere. Ad esempio, i clients necessitano di sapere se l'utente e' richiesto per nuove credenziali, o se la sessione POP3 dev'essere semplicemente riprovata piu' tardi. (Alcuni clients POP3 tentano di analizzare il testo degli errori di autenticazione mancata, cercando stringhe note postate da vari servers che indicano che la casella di posta e' bloccata). Il codice di risposta IN-USE indica che una chiusura (lock) esclusiva non puo' essere ottenuta per la mailbox dell'utente, probabilmente poiche' vi e' in corso un'altra sessione POP3. Il codice di risposta LOGIN-DELAY informa il client che l'utente non ha atteso abbastanza a lungo prima di una nuova autenticazione. Ad ogni modo, vi sono altre condizioni di errore che non richiedono nuove credenziali, talune delle quail dovrebbero essere portate all'attenzione dell'utente. Nonostante le risposte IN-USE e LOGIN-DELAY, i clients non possono essere sicuri se un qualsiasi altro errore richiede nuove credenziali utente. Gellens Standards Track [Page 2] RFC 3206 The SYS and AUTH POP Response Codes February 2002 4. Il Codice di Risposta SYS Il codice di risposta SYS annuncia che un insuccesso e' dovuto ad un errore di sistema, in opposizione alle credenziali utente o ad una condizione esterna. E' gerarchico, con due possibili codici di secondo livello: TEMP e PERM (Case non e' significativo in alcun livello della gerarchia). SYS/TEMP indica un problema che e' probabilmente temporaneo in natura, e non vi e' quindi la necessita' di allarmare l'utente, a meno che il problema persista. Esempi possono includere una risorsa centrale che e' attualmente bloccata o in altro modo temporaneamente non disponibile, insufficiente spazio su disco o memoria libera, ecc. SYS/PERM viene utilizzato per problemi che non sono solitamente risolvibili senza un intervento. E' appropriato allertare l'utente e suggerire che venga contattato il supporto tecnico dell'organizzazione o l'assistenza personale. Esempi includono caselle di posta corrotte, errori nella configurazione del sistema, ecc. Il codice di risposta SYS e' valido con una risposta ERR a qualsiasi comando. 5. Il Codice di Risposta AUTH Il codice di risposta AUTH informa il client che vi e' un problema con le credenziali utente. Si puo' trattare di una password incorretta, uno username sconosciuto, un account espirato, un tentativo di autenticazione che viola la politica in vigore (come proveniente da una locazione non valida o durante un periodo di tempo non autorizzato), o qualche altro problema. Il codice di risposta AUTH e' valido con una risposta -ERR a qualsiasi commando di autenticazione compresi AUTH, USER (vedasi nota), PASS o APOP. I server che implementano il codice di risposta AUTH con un qualsiasi insuccesso d'autenticazione DOVREBBERO supportare il commando CAPA [POP3-EXT] e DOVREBBERO includere la possibilita' AUTH-RESP-CODE nella risposta CAPA. L'AUTH-RESP-CODE assicura al client che sono stati causati solamente errori con il codice AUTH da problemi di credenziali. NOTA: Il ritorno del codice di risposta AUTH al commando USER rivela al client che l'utente specificato esiste. E' fortemente RACCOMANDATO che il server non inoltri quindi tale codice di risposta al comando USER. Gellens Standards Track [Page 3] RFC 3206 The SYS and AUTH POP Response Codes February 2002 6. La Possibilita' AUTH-RESP-CODE CAPA tag: AUTH-RESP-CODE Argomenti: nessuno Comandi aggiunti: nessuno Comandi standard interessati: nessuno Condizioni annunciate / possibili differenze: entrambe / no Comandi validi in stati: n/a Riferimenti specifici: questo documento Discussione: La possibilita' AUTH-RESP-CODE indica che il server include il codice di risposta AUTH con qualsiasi errore di autenticazione determinato da un problema nelle credenziali utente. 7. Considerazioni IANA Lo IANA ha aggiunto la possibilita' AUTH-RESP-CODE nella lista delle possibilita' POP3 (stabilita con l'RFC 2449 [POP3-EXT]). Lo IANA ha inoltre aggiunto i codici di risposta SYS e AUTH nella lista dei codici di risposta POP3 (anch'essi stabiliti con l'RFC 2449 [POP3-EXT]). 8. Considerazioni sulla Sicurezza La Sezione 5, Il Codice di Risposta AUTH, discute le problematiche di sicurezza relative all'uso del codice di risposta AUTH con il comando USER. Gellens Standards Track [Page 4] RFC 3206 The SYS and AUTH POP Response Codes February 2002 9. Riferimenti [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version 3", STD 53, RFC 1939, May 1996. [POP3-EXT] Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension Mechanism", RFC 2449, November 1998. 10. Indirizzo dell'Autore Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-2779 U.S.A. Phone: +1 858 651 5115 EMail: randy@qualcomm.com Gellens Standards Track [Page 5] RFC 3206 The SYS and AUTH POP Response Codes February 2002 11. Dichiarazione Completa di Copyright Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Gellens Standards Track [Page 6]