Network Working Group J. Klensin, WG Chair Request For Comments: 1869 MCI STD: 10 N. Freed, Editor Obsoleti : 1651 Innosoft International, Inc. Categoria: Traccia Standard M. Rose Dover Beach Consulting, Inc. E. Stefferud Network Management Associates, Inc. D. Crocker Brandenburg Consulting November 1995 Estensioni del servizio SMTP Distribuita da .::http://www.rfc.altervista.org::. Stato di questo promemoria Questo documento specifica un protocollo standard di Internet per la comunita' di Internet, e richiede discussioni e suggerimenti per dei miglioramenti. Per favore, riferitevi alla versione corrente di "Internet Official Protocol Standards" (STD 1) per lo stato di standardizzazione e per lo stato di questo protocollo. La distribuzione di questo promemoria e' illimitata. 1. Teoria Questo memoriale definisce una struttura per estendere il servizio SMTP definendo un mezzo attraverso il quale un server SMTP possa informare un client SMTP sulle estensioni che supporta. Le estensioni servizio SMTP sono registrate con IANA. Questa struttura non richiede modifiche dei clients SMTP pre-esistenti o dei servers a meno che le estensioni del servizio sono richieste o fornite. 2. Introduzione Il Simple Mail Transfer Protocol (SMTP) [1] ha fornito una stabile, efficace base per la funzione di trasmissione degli agenti di trasferimento dei messaggi. Benche' vecchio di dieci anni, l'SMTP si e' dimostrato straordinariamente elastico. Nonostante cio', il bisogno di un numero di estensioni del protocollo e' diventato evidente. Piuttosto che descrivere queste estensioni come entita' separate e casuali, questo documento accresce l'SMTP in modo diretto fornendo una struttura all'interno della quale tutte le future estensioni possano essere costruite in maniera coerente. 3. La struttura per le estensioni all' SMTP Per estendere il servizio SMTP, l' SMTP invia un oggetto di posta (N.d.T. un messaggio) contenente un involucro ed un contenuto. Klensin, et al Traccia Standard [Pagina 1] RFC 1869 Estensioni del servizio SMTP Novembre 1995 (1) L'involucro SMTP e' lineare, ed e' inviato come una serie di unita' del protocollo SMTP: e' composto da un indirizzo mittente (al quale dovrebbero essere diretti messaggi di errore); una modalita' di consegna (per esempio, consegna all'indirizzo del destinatario); e, uno o piu' indirizzi destinatari. (2) Il contenuto SMTP e' inviato nell'unita' SMTP DATA del protocollo ed e' fatto di due parti: l' headers e il corpo. Gli headers formano un gruppo di coppie campi/valore strutturate secondo l' RFC 822 [2], mentre il corpo, se strutturato, e' definito secondo il MIME [3]. Il contenuto in genere e' testuale, espresso usando il repertorio US ASCII (ANSI X3.4-1986). Sebbene le estensioni (come il MIME) possono ridurre questa restrizione per il contenuto del corpo, il contenuto degli headers e' sempre codificato usando il repertorio US ASCII. L'algoritmo definito in [4] e' usato per rappresentare i valori degli header al di fuori del repertorio US ASCII, sebbene continuando ad usare il repertorio US ASCII per codificarli. Benche' l' SMTP e' largamente diffuso, alcune parti della comunita' Internet potrebbero voler estendere il servizio SMTP. Questo promemoria definisce un mezzo per mezzo del quale un client ed un server di SMTP esteso possano riconoscersi come tali ed il server possa informare il client riguardo le estensioni al servizio che supporta. Bisogna dare risalto al fatto che ogni estensione al servizio SMTP non dovrebbe essere considerata con leggerezza. La forza dell' SMTP viene principalmente dalla sua semplicita'. L'esperienze con molti protocolli ha dimostrato che: protocolli con poche opzioni tendono all'ubiquita', mentre protocolli con troppe opzione tendono all'incomprensibilita'. Questo significa che ogni estensione, a dispetto dei suoi benefici, deve essere esaminata attentamente con occhio particolare alla sua implementazione, apertura e ai costi dell'interoperabilita'. In molti casi, il costo per estendere il servizio SMTP superera' di molto i benefici. Poste queste condizioni, la struttura per le estensioni descritta in questo promemoria consiste di: (1) un nuovo comando SMTP (sezione 4) (2) un registro delle estensioni del servizio SMTP (sezione 5) (3) parametri addizionali nei comandi SMTP MAIL FROM e RCPT TO (sezione 6). Klensin, et al Traccia Standard [Pagina 2] RFC 1869 Estenzioni del servizio SMTP Novembre 1995 4. Il comando EHLO Un client SMTP che supporti le estenzioni al servizio SMTP avvia una sessione SMTP inviando il comando EHLO invece del comando HELO. Se il server SMTP supporta le estenzioni al servizio SMTP dara' una risposta positiva (vedi la sezione 4.3), una risposta negativa (vedi 4.4), o un messaggio di errore (4.5). Se il server SMTP non supporta nessuna estensione del servizio SMTP generera' un messaggio di errore (vedi la sezione 4.5). 4.1. Cambiamenti allo STD 10, RFC 821 Questa specificazione e' volta ad estendere STD 10, RCF 821 senza andare a scontrarsi, in alcun modo, con i servizi pre-esistenti. I piccoli cambiamenti richiesti sono enumerati disotto. 4.1.1. Primo comando RFC 821 afferma che il primo comando in una sessione SMTP deve essere il comando HELO. Questa necessita' e' in tal modo corretta per accettare una sessione che cominci sia con EHLO che con HELO. 4.1.2. Lunghezza massima di una linea di comando Questa specificazione estende SMTP MAIL FROM e RCPT TO per accettare parametri e valori addizionali. E' possibile che le linee MAIL FROM e RCPT TO possano risultare piu' lunghe del limite di 512 caratteri per linea di comando imposto dall' RFC 821. In tal modo tale limite e' applicabile solo a linee di comando senza parametri. Ogni specificazione che definisce nuovi parametri per MAIL FROM e per RCPT TO deve inoltre definire la lunghezza massima dei valori dei parametri per ogni parametro in modo tale che i realizzatori di un qualche insieme di estensioni sappiano quanto spazio debba essere allocato per il buffer. La lunghezza massima che puo' essere supportata da un' implementazione SMTP con le estenzioni e 512 piu' la somma di tutte le lunghezze massime dei parametri per tutte le estensioni supportate. 4.2. Sintassi dei comandi La sintassi per questo comando, usando la notazione ABNF di [2], e': ehlo-cmd ::= "EHLO" SP dominio CR LF Se il comando ha avuto successo, il server risponde con il codice 250. In caso di fallimento, il server risponde con il codice 550. In caso di errore, il server risponde con uno dei seguenti codici: 500, 501, 502, 504 o 421. Klensin, et al Traccia Standard [Pagina 3] RFC 1869 Estenzioni del servizio SMTP Novembre 1995 Questo comando e' inviato invece del comando HELO, e puo' essere inviato ogni volta che il comando HELO e' appropriato. Cioe', se il comando EHLO e' inviato, e riceviamo una risposta positiva, allora un successivo comando HELO o EHLO fara' rispondere il server SMTP con il codice 503. Un client SMTP non deve conservare nella cache alcuna informazione se il comando EHLO ha successo. Vale a dire, un client SMTP deve inviare il comando EHLO all'avvio di ogni sessione SMTP se sono richieste informazioni sui servizi estesi. 4.3. Risposta con esito positivo Se il server SMTP implementa e puo' eseguire il comando EHLO, ritornera' il codice 250. Questo indica che sia il server che il client sono nello stato iniziale, ossia, che non c'e' alcuna transazione in corso e che tutte le tabelle di stato e i buffer sono vuoti. Di solito, questa risposta stara' su piu' linee. Ogni linea della risposta contiene una parola chiave e, facoltativamente, uno o piu' parametri. La sintassi per una risposta positiva, usando la notazione ABNF di [2], e': ehlo-ok-rsp ::= "250" dominio [ SP saluti ] CR LF / ( "250-" dominio [ SP saluti ] CR LF *( "250-" ehlo-line CR LF ) "250" SP ehlo-line CR LF ) ; la solita chiacchierata del HELO saluti ::= 1* ehlo-line ::= ehlo-keyword *( SP ehlo-param ) ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") ; sintassi e valori dipendono da ehlo-keyword ehlo-param ::= 1* ALPHA ::= DIGIT ::= CR ::= LF ::= Klensin, et al Traccia Standard [Pagina 4] RFC 1869 Estenzioni del servizio SMTP Novembre 1995 SP ::= Sebbene le parole chiave EHLO possano essere specificate in maiuscolo , minuscolo, o in caratteri misti, devono essere comunque riconosciute e processate indipendentemente dal tipo del carattere. Questa e' semplicemente un'estensione delle pratiche iniziate nel RFC 821. IANA conserva un registro delle estenzioni del servizio SMTP. Associata con ogni estensione c'e' il corrispondente valore della parola chiave EHLO. Ogni estensione del servizio registrata con IANA deve essere definita in un RFC. Tali RFC devono o essere sulla traccia standard o devono definire un protocollo sperimentale approvato dallo IESG. La definizione deve includere: (1) il nome testuale dell'estensione del servizio SMTP; (2) Il valore della parola chiave EHLO associata con l'estensione; (3) la sintassi e i possibili valori dei parametri associati con il valore della parola chiave EHLO; (4) Qualsiasi verbo addizionale dell'SMTP associato con le estensioni (verbi addizionale di solito saranno uguali, ma non e' richiesto, al valore della parola chiave EHLO); (5) qualsiasi nuovo parametro l'estensioni associ con i verbi MAIL FROM o RCPT TO; (6) come il supporto per l'estensione influisce sul comportamento di un server e di un client SMTP; e, (7) L'incremento con il quale l'estensione sta aumentando la lunghezza dei comandi MAIL FROM, RCPT TO, o entrambi, rispetto a quanto specificato nell'RFC 821. In oltre, ogni valore della parola chiave EHLO che inizia con un carattere "X" maiuscolo o minuscolo si riferisce ad una estensione locale del servizio SMTP, la quale funziona su un accordo bilaterale, piuttosto che standardizzato. Le parole chiave inizianti per "X" non possono essere usate in una estensione registrata del servizio. Ogni parola chiave presentata nella risposta EHLO che non inizia con una "X" devo corrispondere a uno standard, a una traccia standard, o a una estensione sperimentale del servizio SMTP, approvata dallo IESG, registrata con IANA. Un server conforme non deve offrire valori di parole chiave, non prefissate dalla "X", che non sono descritte in una estensione registrata. Klensin, et al Traccia Standard [Pagina 5] RFC 1869 Estenzioni del servizio SMTP Novembre 1995 Verbi addizionali sono legati alle stesse regole delle parole chiave EHLO; in particolare, verbi inizianti con una "X" sono estensioni locale che possono essere non registrati o standardizzati e verbi non inizianti con una "X" devono necessariamente essere registrati. 4.4. Risposta fallimentare Se per una qualche ragione il server SMTP non puo' listare le estensioni del servizio che supporta, ritornera' il codice 554. In caso di una risposta fallimentare, il client SMTP dovrebbe inviare o il comando HELO o il comando QUIT. 4.5. Messaggi di errore da server con estensioni Se il server SMTP riconosce il comando EHLO, ma l'argomento del comando e' inaccettabile, ritornera' il codice 501. Se il server riconosce, ma non implementa, il comando EHLO, ritornera' il codice 502. Se il server SMTP determina che il servizio SMTP non e' piu' disponibile (per esempio, dovuto ad un arresto imminente del server), ritornera' il codice 421. In caso di un qualsiasi altro errore, il client SMTP dovrebbe inviare o il comando HELO o il comando QUIT. 4.6. Risposte da servers senza estensioni Un server SMTP che e' conforme al RFC 821 ma non supporta le estensioni qui specificate non riconoscera' il comando EHLO e ritornera' di conseguenza il codice 500, come specificato nel RFC 821. Il server SMTP dovrebbe essere nello stesso stato dopo aver ritornato questo codice (vedi la sezione 4.1.1 del RFC 821). Il Il client SMTP puo' quindi inviare il comando HELO o QUIT. 4.7. Risposte da servers non correttamente configurati Si conosce di alcuni servers SMTP che disconnettono il canale di trasmissione SMTP dopo aver ricevuto il comando EHLO. La disconnessione puo' avvenire immediatamente o dopo aver inviato una risposta. Tale comportamento viola la sezione 4.1.1 del RFC 821, che stabilisce chiaramente che la disconnessione deve avvenire solo dopo che il comando QUIT e' stato inviato. Tuttavia, per raggiungere la massima interoperabilita' si suggerisce di codificare i client di SMTP esteso, che usano EHLO, in modo da controllare una eventuale chiusura della connessione da parte del server dopo che EHLO e' stato inviato, prima o dopo di inviare una Klensin, et al Traccia Standard [Pagina 6] RFC 1869 Estenzioni del servizio SMTP Novembre 1995 risposta. Se accade cio' il client deve decidere se l'operazione puo' essere completata con successo senza usare le estensioni dell' SMTP. Se cio' e' possibile, il client puo' aprire una nuova connessione e usare il comando HELO. Altri servers non correttamente implementati non accetteranno un comando HELO dopo che EHLO e' stato inviato e rifiutato. In alcuni casi, si puo' risolvere questo problema inviando un RSET dopo la risposta fallimentare all' EHLO, e poi inviando un HELO. I client che fanno cio' devono tener conto che molte implementazioni ritorneranno un codice di fallimento (es, 503 Errata sequenza dei comandi) in risposta al RSET. Questo codice puo' essere tranquillamente ignorato. 5. Il registro iniziale IANA Il registro iniziale dello IANA delle estensioni del servizio SMTP consiste in queste righe: Estensione EHLO Keyword Parametri Verbi Comportamento aggiuntivo ------------- ------------ ---------- ---------- ------------------ Send SEND nessuno SEND defined in RFC 821 Send or Mail SOML nessuno SOML defined in RFC 821 Send and Mail SAML nessuno SAML defined in RFC 821 Expand EXPN nessuno EXPN defined in RFC 821 Help HELP nessuno HELP defined in RFC 821 Turn TURN nessuno TURN defined in RFC 821 che corrispondono a quei comandi SMTP definiti come facoltativi in [5]. (I comandi SMTP obbligatori, secondo [5], sono HELO, MAIL, RCPT, DATA, RSET, VRFY, NOOP, QUIT.) 6. Parametri di MAIL FROM e RCPT TO E' noto che molte delle estensioni progettate per l'SMTP faranno uso di parametri addizionali associato ai comandi MAIL FROM e RCPT TO. La sintassi per questi comandi, continuando ad usare la notazione ABNF [2] cosi come le definizioni fondamentali da [1], e': esmtp-cmd ::= inner-esmtp-cmd [SP esmtp-parametri] CR LF esmtp-parametri ::= esmtp-parametro *(SP esmtp-parametro) esmtp-parametro ::= esmtp-parolachiave ["=" esmtp-valore] esmtp-parolachiave ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") ; La sintassi e i valori dipendono da ; esmtp-parolachiave esmtp-value ::= 1* C: S: 220 dbc.mtview.ca.us SMTP service ready C: EHLO ymir.claremont.edu S: 250 dbc.mtview.ca.us says hello ... indica che il server implementa solo quei comandi che sono definiti come obbligatori in [5]. Klensin, et al Traccia Standard [Pagina 8] RFC 1869 Estenzioni del servizio SMTP Novembre 1995 (2) Al contrario, una interazione del tipo: S: C: S: 220 dbc.mtview.ca.us SMTP service ready C: EHLO ymir.claremont.edu S: 250-dbc.mtview.ca.us says hello S: 250-EXPN S: 250-HELP S: 250-8BITMIME S: 250-XONE S: 250 XVRB ... indica che il server SMTP implementa anche i comandi SMTP EXPN e HELP, una estensione standard del servizio (8BITMIME), e due estensioni del servizio non standard e non registrate (XONE e XVRB). (3) In fine, un server che non supporta estensioni del servizio SMTP agira' come segue: S: C: S: 220 dbc.mtview.ca.us SMTP service ready C: EHLO ymir.claremont.edu S: 500 Command not recognized: EHLO ... La risposta 500 indica che il server SMTP non implementa le estensioni qui specificate. Il client dovra' normalmente inviare il comando HELO e procedere come specificato nel RFC 821. Vedi la sezione 4.7 per le discussioni aggiuntive. 9. Considerazioni di sicurezza Questo RFC non discute di problemi di sicurezza e non si pensa che porti altri problemi di sicurezza non di gia' endemici nella posta elettronica e presente nelle implementazioni pienamente conformi al RFC 821. Fornisce un annuncio sulle capacita' dei server di posta rispondendo EHLO. Comunque, tutte le informazioni date dall'annuncio di uno dei set iniziali delle estensioni definite con questo RFC possono essere prontamente dedotte indagando con cura i verbi richiesti per trasportare e consegnare la posta. Le implicazioni sulla sicurezza delle estensioni descritte in altri RFC dovrebbero essere trattate in quegli stessi RFC. Klensin, et al Traccia Standard [Pagina 9] RFC 1869 Estenzioni del servizio SMTP Novembre 1995 10. Ringraziamenti Questo documento rappresenta una sintesi delle idee di molte persone e delle reazioni alle idee e proposte di altri. Randall Atkinson, Craig Everhart, Risto Kankkunen, e Greg Vaudreuil hanno contribuito con idee e testi sufficienti per essere considerati co-autori. Altri importanti suggerimenti, testi, o incoraggiamenti sono venuti da Harald Alvestrand, Jim Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A. Miller, Keith Moore, John Myers, Dan Oscarsson, Julian Onions, Rayan Zachariassen, e i contributi dell'intero IETF SMTP Working Group. Naturalmente, nessuno degli individui e' necessariamente responsabile della varieta' di idee qui rappresentate . In verita', in qualche caso, la risposta a una critica particolare era di accettare il problema dell'identificazione ma di includere una soluzione completamente differente da quella proposta. 11. Referenze [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, Agosto 1982. [2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, Agosto 1982. [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions", RFC 1521, Bellcore, Innosoft, Settembre 1993. [4] Moore, K., "Representation of Non-ASCII Text in Internet Message Headers", RFC 1522, University of Tennessee, Settembre 1993. [5] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, USC/Information Sciences Institute, Ottobre 1989. 12. Chair, Editor, and Author Addresses John Klensin, WG Chair MCI 2100 Reston Parkway Reston, VA 22091 Phone: +1 703 715-7361 Fax: +1 703 715-7436 EMail: klensin@mci.net Klensin, et al Traccia Standard [Pagina 10] RFC 1869 Estenzioni del servizio SMTP Novembre 1995 Ned Freed, Editor Innosoft International, Inc. 1050 East Garvey Avenue South West Covina, CA 91790 USA Phone: +1 818 919 3600 Fax: +1 818 919 3614 EMail: ned@innosoft.com Marshall T. Rose Dover Beach Consulting, Inc. 420 Whisman Court Moutain View, CA 94043-2186 USA Phone: +1 415 968 1052 Fax: +1 415 968 2510 EMail: mrose@dbc.mtview.ca.us Einar A. Stefferud Network Management Associates, Inc. 17301 Drey Lane Huntington Beach, CA, 92647-5615 USA Phone: +1 714 842 3711 Fax: +1 714 848 2091 EMail: stef@nma.com Dave Crocker Brandenburg Consulting 675 Spruce Dr. Sunnyvale, CA 94086 USA USA Phone: +1 408 246 8253 Fax: +1 408 249 6205 EMail: dcrocker@mordor.stanford.edu ------------------------------------------------------------------------ Tradotto in Italiano da: N'em Sy - nemesys@napolihak.it Note di traduzione: ho cercato di fare una traduzione il piu' possibile fedele all'originale. In caso di problemi o critiche fate potete sempre fare riferimento all'originale in lingua Inglese su http://www.napolihak.it Finito di tradurre il 16 Dicembre 2001 Klensin, et al Traccia Standard [Pagina 11]