Utenti Online:  | IP:  28/10/2002: Aggiornata la grafica del sito, by pCwArE ;))
Documentazione
Enciclopedia Lord Shinva
Guida protocollo TCP/IP

Security FAQ 1.0

RFC
Porte di connessione
Jargon file
E-zine

 

DISCLAIMER: Si ricorda che il Web Admin del sito ed il provider non si ritengono responsabili in nessun modo del cattivo utilizzo che chiunque dovesse fare di tutto il materiale contenuto nel sito. Lo scopo della Security Check Community è quello di condividere ed approfondire le conoscenze della comunità.

 

Votaci!!

Hacking/Documentazione
RFC 1869
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]

 

 

 

Partner

pCwArE
ZeroDay
Il tuo sito qui..
Il tuo sito qui..
Il tuo sito qui..

>Diventa Partner

Newsletter

A breve la Newsletter!!
Community
Forum
Chat

Statistiche

[contatore visite]

 

TORNA ALLA HOMEPAGE

Security Check™ Designed By http://www.pcware.tk