| 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
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*
Klensin, et al Traccia
Standard [Pagina 7]
RFC 1869 Estenzioni del
servizio SMTP Novembre 1995
; I comandi seguenti sono
esteso per accettare
; parametri estesi.
inner-esmtp-cmd ::=
("MAIL FROM:" mittente) /
("RCPT TO:"
destinatario)
Tutti i valori di
esmtp-parolachiave devono essere registrati come
parte del processo di
registrazione IANA come descritto sopra. Questa
Questa definizione garantisce
la struttura per future estensioni;
in questo RFC non sono
definiti parametri estesi per MAIL FROM o
RCPT TO.
6.1. Messaggi di errore
Se il server SMTP non
riconosce o non puo' implementare uno o piu'
dei parametri associati con
un particolare comando MAIL FROM o
RCPT TO, ritornera' il codice
555.
Se per una qualche ragione il
server e' temporaneamente incapace di
associare uno o piu' dei
parametri associati con un comando MAIL FROM
o RCPT TO, e se la
definizione del parametro specifico non ingiunge
l'uso di un altro codice,
dovrebbe ritornare il codice 455.
Errori specifici a
particolari parametri e ai loro valore saranno
specificati nel RFC che
definisce il parametri.
7. Received: significato del
campo received
I server SMTP devono
aggiungere un appropriato campo Received:
all'header di tutti i
messaggi che ricevono. Una clausola "with
ESMTP" dovrebbe essere
aggiunta a questo campo quando una qualsiasi
estensione SMTP e' usata.
"ESMTP" cosi' aggiunto alla lista dei nomi
dei protocolli standard
registrato con IANA.
8. Esempi d'uso
(1) 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
...
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]
|
