組織：中國(guó)互動(dòng)出版網(wǎng)（http://www.china-pub.com/）
RFC文檔中文翻譯計(jì)劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：何煒麗（hwl_myself@sina.com）
譯文發(fā)布時(shí)間：2001-9-6
版權(quán)：本中文翻譯文檔版權(quán)歸中國(guó)互動(dòng)出版網(wǎng)所有?？梢杂糜诜巧虡I(yè)用途自由轉(zhuǎn)載，但必須
文檔的翻譯及版權(quán)信息。


Network Working Group                               J. Klensin, WG Chair
Request For Comments: 1869                                           MCI
STD: 10                                                 N. Freed, Editor
Obsoletes: 1651                             Innosoft International, Inc.
Category: Standards Track                                        M. Rose
                                            Dover Beach Consulting, Inc.
                                                            E. Stefferud
                                     Network Management Associates, Inc.
                                                              D. Crocker
                                                  Brandenburg Consulting
                                                           November 1995


SMTP服務(wù)擴(kuò)展
（RFC1869——SMTP Service Extensions）
目錄
1. 摘要	2
2. 介紹	2
3. SMTP 擴(kuò)展框架	2
4. EHLO 命令	3
4.1.  對(duì)STD 10, RFC 821的變動(dòng)	3
4.2.  命令語(yǔ)法	3
4.3.  成功響應(yīng)	4
4.4. 失敗響應(yīng)	5
4.5. 擴(kuò)展服務(wù)器的出錯(cuò)響應(yīng)	5
4.6. 不支持?jǐn)U展的服務(wù)器響應(yīng)	5
4.7. 服務(wù)器未正確完成命令的響應(yīng)	6
5. 初始 IANA 注冊(cè)	6
6. MAIL FROM 和 RCPT TO 參數(shù)	6
6.1.  出錯(cuò)響應(yīng)	7
7. 收到: 頭部域注釋	7
8. 應(yīng)用舉例	7
9. 安全考慮	8
10. 鳴謝	9
11. 參考文獻(xiàn)	9
12. 主席，編輯及作者地址	9




本備忘錄的狀態(tài)
本文檔講述了一種Internet社區(qū)的Internet標(biāo)準(zhǔn)跟蹤協(xié)議，它需要進(jìn)一步進(jìn)行討論和建
議以得到改進(jìn)。請(qǐng)參考最新版的“Internet正式協(xié)議標(biāo)準(zhǔn)” (STD1)來(lái)獲得本協(xié)議的標(biāo)準(zhǔn)化程
度和狀態(tài)。本備忘錄的發(fā)布不受任何限制。

1. 摘要
本備忘錄通過(guò)定義服務(wù)器SMTP通知客戶端SMTP它所支持的服務(wù)擴(kuò)展的方法，定義了一
個(gè)擴(kuò)展SMTP服務(wù)的框架。SMTP服務(wù)擴(kuò)展在IANA中已經(jīng)注冊(cè)。本框架并不要求修改現(xiàn)有的SMTP
服務(wù)器或客戶端，除非要求使用或提供服務(wù)擴(kuò)展中的特性。

2. 介紹
    簡(jiǎn)單郵件傳送協(xié)議為消息傳遞代理的轉(zhuǎn)發(fā)函數(shù)提供了一個(gè)穩(wěn)定有效的基礎(chǔ)。雖然已經(jīng)有
10年的歷史了，但是SMTP還是非常具有活力。然而，對(duì)一些協(xié)議進(jìn)行擴(kuò)展的需要越來(lái)越明
顯。除了單獨(dú)的對(duì)這些擴(kuò)展進(jìn)行描述外，本文以一種直接方式提供一個(gè)框架，其中所有未來(lái)
的擴(kuò)展都可以以一種單獨(dú)相容的方式進(jìn)行。

3. SMTP 擴(kuò)展框架
為了對(duì)SMTP服務(wù)進(jìn)行擴(kuò)展，SMTP可以轉(zhuǎn)發(fā)郵件，其中包括信封和內(nèi)容。
    (1) SMTP 信封簡(jiǎn)單易懂，它作為SMTP協(xié)議單元系列被傳遞：它包括發(fā)送者地址（郵件
傳遞出錯(cuò)時(shí)，返回信息的接受者）；傳遞模式（例如，傳遞到接收者的信箱）；以及一個(gè)或多
個(gè)接收者地址。

(2) SMTP內(nèi)容以SMTP DATA 協(xié)議單元形式傳遞，它包括2部分：頭部和主體。頭部是一
個(gè)結(jié)構(gòu)根據(jù)RFC 822 [2]定義的域/值對(duì)的集合，而主體是根據(jù)MIME [3]定義的。內(nèi)容是用
US ASCII repertoire (ANSI X3.4-1986)表示的自然形式的文本，雖然擴(kuò)展（例如MIME）對(duì)
內(nèi)容主體部分的這一限制會(huì)有所放松，但頭部信息仍然使用US ASCII 編碼。
雖然SMTP被廣泛的應(yīng)用，但是部分因特網(wǎng)社區(qū)仍然想對(duì)SMTP服務(wù)進(jìn)行擴(kuò)展。本備忘錄
定義了一種渠道，使得擴(kuò)展的SMTP客戶端和服務(wù)器可以識(shí)別對(duì)方，并且服務(wù)器可以通知客戶
端它所支持的服務(wù)擴(kuò)展。
必須指出：SMTP服務(wù)的任何擴(kuò)展都應(yīng)深思熟慮。SMTP的實(shí)力首先來(lái)自于它的簡(jiǎn)單性。很
多協(xié)議的經(jīng)驗(yàn)表明：
幾個(gè)選擇項(xiàng)的協(xié)議無(wú)處不在，很多選擇項(xiàng)的協(xié)議無(wú)人能懂。

     protocols with few options tend towards ubiquity, whilst
protocols with many options tend towards obscurity.
這表明：任何一個(gè)擴(kuò)展，不考慮它的效益，必須根據(jù)它的實(shí)施，調(diào)度，溝通等方面的成
本，對(duì)它進(jìn)行仔細(xì)的查看。在很多情況下，擴(kuò)展SMTP服務(wù)的費(fèi)用比它本身的效益還要多。
在這種環(huán)境下，本備忘錄中描述的服務(wù)擴(kuò)展的框架包括：
   (1)   一個(gè)新的SMTP命令 (section 4)
 (2)   一個(gè)SMTP服務(wù)擴(kuò)展的注冊(cè) (section 5)
 (3)   SMTP MAIL FROM and RCPT TO 命令的附加參數(shù) (section 6).
4. EHLO 命令
    一個(gè)支持SMTP服務(wù)擴(kuò)展的客戶SMTP應(yīng)以EHLO命令啟動(dòng)SMTP過(guò)程，而不是HELO命令。
如果SMTP服務(wù)器支持SMTP服務(wù)擴(kuò)展，他將給予一個(gè)表示成功的響應(yīng)(見(jiàn)section 4.3)，一
個(gè)表示失敗的響應(yīng)（見(jiàn)4.4），或一個(gè)表示出錯(cuò)的響應(yīng)（見(jiàn)4.5）。如果SMTP服務(wù)器不支持任
何SMTP服務(wù)擴(kuò)展，它將給予一個(gè)出錯(cuò)響應(yīng)（見(jiàn)section 4.5）。
4.1.  對(duì)STD 10, RFC 821的變動(dòng)
    這一部分希望擴(kuò)展STD 10, RFC 821而絕不影響已有的服務(wù)。所需的最小改動(dòng)見(jiàn)下述。
4.1.1.  First command
RFC 821 表明SMTP進(jìn)程第一個(gè)命令必須是HELO命令。這個(gè)要求被訂正為允許進(jìn)程以HELO
或EHLO命令開(kāi)始。
4.1.2.	命令行最大長(zhǎng)度
    這一部分?jǐn)U展了SMTP MAIL FROM 和 RCPT TO，增加了附加參數(shù)和參數(shù)值。RFC 821
規(guī)定：MAIL FROM 和 RCPT TO命令行不允許超過(guò)512個(gè)字符。這個(gè)限制被訂正為只應(yīng)用
于沒(méi)有任何參數(shù)的命令行。每一個(gè)新的定義MAIL FROM 和 RCPT TO 參數(shù)的描述也必須指
明每個(gè)參數(shù)的值的最大長(zhǎng)度，使得一些擴(kuò)展的操作者知道要預(yù)先分配多少緩存區(qū)。支持SMTP
擴(kuò)展操作的最大命令長(zhǎng)度是512加上被所有擴(kuò)展支持的所有的參數(shù)的最大長(zhǎng)度。
4.2.	命令語(yǔ)法
    該命令的語(yǔ)法，使用[2]的ABNF標(biāo)記法，表示為：
     ehlo-cmd ::= "EHLO" SP domain CR LF
	如果成功，服務(wù)器SMTP響應(yīng)“250”；如果失敗，服務(wù)器SMTP響應(yīng)“550”；如果出錯(cuò)，
服務(wù)器SMTP響應(yīng)“500”, “501”,“502”, “504”, 或 “421”中的一個(gè)。這個(gè)命令被
指定替代“HELO”命令，并且可以在任何“HELO”命令正確的地方替代。也就是說(shuō)，如果一
個(gè)“EHLO”命令發(fā)出了，并得到了成功的響應(yīng)，則其后的HELO或EHLO命令將被服務(wù)器SMTP
響應(yīng)為“503”。如果EHLO命令成功，客戶端SMTP不可能隱藏任何返回信息？？？。也就是
說(shuō)，如果需要擴(kuò)展服務(wù)的信息時(shí)，客戶端SMTP必須以EHLO命令啟動(dòng)SMTP進(jìn)程。

4.3.  成功響應(yīng)
    如果服務(wù)器SMTP運(yùn)行，并可以執(zhí)行EHLO命令，它將返回“250”。這表明服務(wù)器和客戶
端SMTP都已經(jīng)處于初始狀態(tài)，即進(jìn)程中沒(méi)有任何的程序在運(yùn)行，所有的狀態(tài)都是穩(wěn)定的，所
有的緩沖區(qū)都已清空。
    通常，這個(gè)響應(yīng)是多行的，每一行響應(yīng)包括一個(gè)關(guān)鍵字及一個(gè)或多個(gè)參數(shù)。成功響應(yīng)的
語(yǔ)法，用[2]的 ABNF表示法表示，即：

     ehlo-ok-rsp  ::=      "250"    domain [ SP greeting ] CR LF
                    / (    "250-"   domain [ SP greeting ] CR LF
                        *( "250-"      ehlo-line           CR LF )
                           "250"    SP ehlo-line           CR LF   )

                  ; 通常 HELO chit-chat
     greeting     ::= 1*<CR 或 LF 以外任何其他的字>

     ehlo-line    ::= ehlo-keyword *( SP ehlo-param )

     ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")

                  ; 語(yǔ)法和值依賴于ehlo-keyword
     ehlo-param   ::= 1*<除空格（SP）和所有的控制字符外，包括US ASCII 0-31>

     ALPHA        ::= <52個(gè)字母中任何一個(gè) (A 到 Z 在前, a 到 z 在后)>
     DIGIT        ::= <10個(gè)數(shù)字中的一個(gè) (0 到 9)>

     CR           ::= <回車符 (ASCII 碼 13)>
     LF           ::= <還行符 (ASCII 碼 10)>
     SP           ::= <空格    (ASCII decimal code 32)>

    雖然EHLO關(guān)鍵字可以描述成上、下、或綜合的，但是，他們必須以一種不敏感的方式被
識(shí)別和被處理。這在RFC 821里？？？
   Although EHLO keywords may be specified in upper, lower, or mixed
   case, they must always be recognized and processed in a case-insensitive manner. 
This is simply an extension of practices begun in  RFC 821.

    IANA包括SMTP服務(wù)擴(kuò)展的registry。與每個(gè)擴(kuò)展相關(guān)的是響應(yīng)的EHLO關(guān)鍵字值。每一
個(gè)在IANA中注冊(cè)的服務(wù)擴(kuò)展必須在RFC中定義。這種RFC應(yīng)該符合跟蹤標(biāo)準(zhǔn)，或定義一個(gè)
IESG認(rèn)可的經(jīng)驗(yàn)協(xié)議。定義必須包括：
 (1)   SMTP擴(kuò)展的文本名；
 (2)   與擴(kuò)展相關(guān)的EHLO關(guān)鍵字值；
 (3)   與EHLO關(guān)鍵字值相關(guān)的參數(shù)語(yǔ)法或可能的取值； 
 (4)   與擴(kuò)展有關(guān)的任何附加的SMTP動(dòng)詞（附加動(dòng)詞通常與EHLO關(guān)鍵詞值相同，但也不一
定是。）
 (5)   任何與MAIL FROM 或 RCPT TO 動(dòng)詞有關(guān)的擴(kuò)展的新參數(shù)；
如何支持受擴(kuò)展影響的服務(wù)器和客戶端SMTP的行為；
(6)	擴(kuò)展中定義的對(duì)MAIL FROM, RCPT TO或兩者都有的命令的最大長(zhǎng)度的改動(dòng)，需指出
它們的增量；
    同時(shí)，任何以an upper or lower case "X"的EHLO關(guān)鍵字值是指局域SMTP服務(wù)擴(kuò)展，
用于雙面，而非標(biāo)準(zhǔn)的。以“X”開(kāi)頭的關(guān)鍵字不可以在已注冊(cè)的服務(wù)擴(kuò)展中使用。
	任何在EHLO響應(yīng)中出現(xiàn)的不以“X”開(kāi)頭的關(guān)鍵字值必須與一個(gè)標(biāo)準(zhǔn)，標(biāo)準(zhǔn)跟蹤，或在
IANA中注冊(cè)的IESG認(rèn)可的經(jīng)驗(yàn)SMTP服務(wù)擴(kuò)展相對(duì)應(yīng)。給予肯定響應(yīng)的服務(wù)器不可以提供沒(méi)
在注冊(cè)擴(kuò)展中描述的不以“X”開(kāi)頭的關(guān)鍵字值。
    附加動(dòng)詞的約束與EHLO關(guān)鍵字一樣。特別指出，以“X”開(kāi)頭的動(dòng)詞是局域擴(kuò)展，沒(méi)有
注冊(cè)或標(biāo)準(zhǔn)化，而以“X”開(kāi)頭的動(dòng)詞一定是注冊(cè)的了。

4.4. 失敗響應(yīng)
    如果由于某種原因，服務(wù)器SMTP不能列出它所支持的服務(wù)擴(kuò)展，它會(huì)返回“554”。
    在失敗響應(yīng)的情況下，客戶端SMTP應(yīng)該發(fā)出HELO或QUIT命令。

4.5. 擴(kuò)展服務(wù)器的出錯(cuò)響應(yīng)
    如果服務(wù)器SMTP識(shí)別了EHLO命令，但是不能解釋命令的表達(dá)方法，將返回“501”。