組織：中國互動出版網(wǎng)（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者： 劉偉力（truelwl   truelwl@sina.com）
譯文發(fā)布時間：2001-4-27
版權：本中文翻譯文檔版權歸中國互動出版網(wǎng)所有。可以用于非商業(yè)用途自由轉載，但必須
保留本文檔的翻譯及版權信息。

Network Working Group                                          N. Freed
Request for Comments: 2920                                     Innosoft
STD: 60                                                  September 2000
Obsoletes: 2197
Category: Standards Track

SMTP 針對命令流水線的服務擴展
(RFC2920 SMTP Service Extension for Command Pipelining)

  
本備忘錄的狀態(tài)
本文檔講述了一種Internet社區(qū)的Internet標準跟蹤協(xié)議，它需要進一步進行討論和建
議以得到改進。請參考最新版的“Internet正式協(xié)議標準” (STD1)來獲得本協(xié)議的標準化
程度和狀態(tài)。本備忘錄的發(fā)布不受任何限制。
版權聲明
Copyright (C) The Internet Society (1999).  All Rights Reserved.

摘要
該文檔定義了對簡單郵件傳輸協(xié)議(SMTP)服務的一種擴展。這種擴展服務使得郵
件服務器在單次基于傳輸控制協(xié)議(TCP)	的發(fā)送操作中能夠接受多條命令。這樣單次
TCP發(fā)送操作實現(xiàn)多條郵件傳輸命令可以顯著提高SMTP的性能。

目錄
1 介紹	2
1.1 需求符號	2
2 命令流水線擴展的基本框架結構	3
3 流水線服務擴展	3
3.1 客戶端使用流水線	3
3.2 服務器支持流水線	4
4 舉例	4
5 安全方面的考慮	6
6 致謝	6
6 參考資料	7
8.作者的地址	7
9.版權說明	7

1 介紹
雖然SMTP已經(jīng)得到廣泛,穩(wěn)定的應用,但是一定程度的對其功能的擴展無疑是有
益的, 尤其是對那種用在因特網(wǎng)上使用的高延遲的網(wǎng)絡連接這種擴展更加必要. 在這
種高延遲網(wǎng)絡連接中, SMTP固有的一條命令對應一條回應的模式很不利, 每次連接時
間都花費在等待個別命令的回應(周轉時間)上了.
最簡單的情況莫過于直接開發(fā)SMTP的客戶端軟件,勢其使用命令流水線: 把多條
命令集成在一條TCP的發(fā)送操作中. 不幸的是, 最初的SMTP規(guī)范[RFC-821]沒有明確
的規(guī)定SMTP服務器必須支持命令流水線. 因此,大量的因特網(wǎng)SMTP服務器不能完全
處理命令流水線. 在現(xiàn)存的服務其中存在以下缺陷:
(1). 在SMTP對話期間進行連接傳遞(connection handoff)和緩沖區(qū)的刷新. 一般
來說, 服務器對相應的SMTP連接請求生成相應的進程進行處理是一種有用,明顯 和
無害的實現(xiàn)技術,然而, 一些SMTP服務器可能會推遲進行處理進程的生成和連接的傳
遞(connection handoff), 可能會導致存儲在進程緩沖區(qū)里的來自TCP連接的數(shù)據(jù)丟失.
(2).當一個SMTP命令失敗后,TCP 輸入緩沖區(qū)會刷新. 事實上, SMTP命令經(jīng)常會
失敗, 而這些刷新是沒有道理的. 不管怎樣, 一些SMTP服務器確實這樣做了.
(3).對失敗的SMTP命令不合適的處理. 舉例來說, 在最后一個RCPT(假設有不止
一個RCPT命令 – 譯者)命令失效時, 盡管其他的RCPT命令成功了,一些SMTP服務
器會拒絕接受接下來的DATA命令. 相反,有些服務器即使在所有的RCPT命令都失效
的情況下,仍然會接受DATA命令. 雖然, 實現(xiàn)了命令流水線的郵件客戶端程序可以適
應上述的兩種情況,但是畢竟這給客戶端的實現(xiàn)帶來了不必要麻煩.

該備忘錄使用了在[RFC-1869]中描述的機制來定義SMTP服務的擴展. 使用這種
擴展服務的服務器可以聲明自己是否能夠處理命令流水線的情況. SMTP客戶端可以檢
查到這一聲明,只有在確保服務器支持使用命令流水線時,才可以使用它.

1.1 需求符號
	在該文檔中,偶爾會用到大寫的名詞. 大寫的"MUST","MUST 
NOT","SHOULD","SHOULD NOT", 和"MAY" 用來表示在本規(guī)范中的特殊需求. 在
[RFC-1123]中有專門對這些名詞,例如"MUST","SHOULD" 和"MAY" 含義的介紹. 而那些
名詞"MUST NOT" 和 "SHOULD NOT"是對上述名字的邏輯擴展.
    
2 命令流水線擴展的基本框架結構
命令流水線采用如下定義:
(1). 這種SMTP服務擴展的名稱是流水線.
(2). 關鍵字EHLO 的值一定是PIPELINING.
(3). 使用關鍵字PIPELINING EHLO時沒有參數(shù).
(4). 對命令 MAIL FROM 和 RCPT TO 沒有定義額外的參數(shù).
(5). 沒有為擴展服務定義額外的SMTP動詞(命令).
(6). 在下一章講解為了支持擴展服務,服務器和客戶端會受到怎樣的影響.
3 流水線服務擴展
當一個SMTP客戶希望使用命令流水線時,它首先要向服務器發(fā)送EHLO	命令.如
果服務器返回代碼 250 ,而且返回信息中包含關鍵字EHLO本身和它的值PIPELINING,
那么這說明該SMTP服務器支持命令流水線的特性.
3.1 客戶端使用流水線
	一旦SMTP客戶端確信服務器支持流水線的特性,那么它就可以不必等待每條命令
的回應而選擇使用一組SMTP命令發(fā)送到服務器. 特別是, 命令 RSET, MAIL FROM, 
SEND FROM, SOML FROM, SAML FROM, 和RCPT TO 可以在命令組中任何地方
出現(xiàn). 而對EHLO,DATA,VERY,EXPN,TURN,QUIT,和NOOP,由于他們的返回結果很關
鍵,可能影響到整個連接的狀態(tài),所以只能出現(xiàn)在命令組的末尾處. (NOOP 也屬于此類
命令,所以它可以作為連接的同步點).

如果沒有特別說明, 由其他SMTP擴展協(xié)議定義的額外命令也只能放在命令組的結尾.

實際傳遞消息內(nèi)容明確的規(guī)定可以作為一個命令組里的第一條命令. 也就是說, 一個
RDET/MAIL FROM 用來初始一個新消息的命令序列可以跟上一條消息的傳遞消息頭
部和消息體的命令放在同一個組里.

一個客戶端要想實現(xiàn)流水線,必須(MUST)檢查在同一個命令組里所有的命令的相關狀
態(tài). 例如, 如果沒有一個 RCPT TO 目的地址被接受,那么客戶端必須檢查DATA命令
的返回狀態(tài). 此時,客戶端不能想當然的認為DATA一定會失敗. 如果DATA命令失敗了, 
這是客戶要發(fā)送 RCPT命令,如果DATA成功的被接受了,那么客戶需要發(fā)送一個點(.)
來結束DATA命令.

命令狀態(tài)必須(MUST) 能夠分清返饋信息和發(fā)送的命令之間一一對應的關系,還要清楚
發(fā)送的命令數(shù)目. 多行的反饋信息必須(MUST)得到支持. 簡單的匹配返回的錯誤代碼
和錯誤信息是被禁止的.

客戶端實現(xiàn)可以(MAY)采用非阻塞模式.即使仍然有上一條TCP發(fā)送操作的數(shù)據(jù)在傳輸
中, 進行處理的服務器對剛剛收到的命令立即進行處理, 如果非阻塞操作不被支持, 那
么客戶端實現(xiàn)必須(MUST)也要檢查TCP 窗體的大小,以確保每組命令完全跟窗體大小
匹配. 一般,窗體大小是4K 字節(jié),但也有例外. 如果不能確保這種檢查正確進行, 往往
會導致死鎖.

客戶端必須不能(MUST NOT)混淆多條命令和多條反饋. 每一條命令需要一條或多條
的信息反饋,在最后一行的反饋代碼和信息中不能包含破折號.

3.2 服務器支持流水線
		 一個支持流水線的SMTP服務器必須具備以下條件:
(1). 必須(MUST)按照順序對從客戶端提交的命令進行反饋.
(2). 應該(SHOULD)對成組的命令RSET,MAIL FROM,SEND FROM,SOML 
FROM,SAML FROM, 和RCPT TO 利用內(nèi)部緩沖區(qū)進行選擇性的存儲,以便他們能夠
當作一個單元進行發(fā)送.
(3). 當且僅當有一個或多個RCPT TO 地址有效時, 應該(SHOULD)給與客戶端正
確的反饋.
		(4). 在對沒有有效接受方地址的情況下,給了DATA命令以正確的反饋, 接著必然
收到一個空的消息正文 , 此時一定不能(MUST NOT)給任何接受方發(fā)送任何消息.
		(5). 對命令 EHLO,DATA,VEFY,EXPN,TURN,QUIT,和NOOP的反饋不能(MUST 
NOT)緩存.
	(6). 對不能識別的命令一定不能(MUST NOT)緩存.
	(7). 當本地的TCP輸入緩沖區(qū)為空時,一定要(MUST)立即發(fā)送所有待發(fā)的命令反
饋.
(8). 一定不能(MUST NOT)對尚未收到的命令做任何假設.
(9). 	在任何境況下.一定不能(MUST NOT)刷新TCP輸入緩沖區(qū)的內(nèi)容
(10).應該(SHOULD)提供模糊的或是明確的反饋文本來標志與反饋信息相匹配的
命令.
	這些對服務器端的需求目的就是要讓服務器盡可能的符合流水線擴展服務.
	

4 舉例
考慮下面的沒有使用流水線的SMTP對話:
	   S: <wait for open connection>
	   C: <open connection to server>
	   S: 220 Innosoft.com SMTP service ready
	   C: HELO dbc.mtview.ca.us
	   S: 250 Innosoft.com
	   C: MAIL FROM:<mrose@dbc.mtview.ca.us>
	   S: 250 sender <mrose@dbc.mtview.ca.us> OK
	   C: RCPT TO:<ned@innosoft.com>
	   S: 250 recipient <ned@innosoft.com> OK
	   C: RCPT TO:<dan@innosoft.com>
	   S: 250 recipient <dan@innosoft.com> OK
	   C: RCPT TO:<kvc@innosoft.com>
	   S: 250 recipient <kvc@innosoft.com> OK
	   C: DATA
	   S: 354 enter mail, end with line containing only "."
	    ...
	   C: .
	   S: 250 message sent
	   C: QUIT
	   S: 221 goodbye
		在這個簡單的例子中,客戶端足足等了服務器的反饋9 次,. 但是如果采用流水
線服務, 則是下面的情形:
		
	   S: <wait for open connection>
	   C: <open connection to server>
	   S: 220 innosoft.com SMTP service ready
	   C: EHLO dbc.mtview.ca.us
	   S: 250-innosoft.com
	   S: 250 PIPELINING
	   C: MAIL FROM:<mrose@dbc.mtview.ca.us>
	   C: RCPT TO:<ned@innosoft.com>
	   C: RCPT TO:<dan@innosoft.com>
	   C: RCPT TO:<kvc@innosoft.com>
	   C: DATA
	   S: 250 sender <mrose@dbc.mtview.ca.us> OK
	   S: 250 recipient <ned@innosoft.com> OK
	   S: 250 recipient <dan@innosoft.com> OK
	   S: 250 recipient <kvc@innosoft.com> OK
	   S: 354 enter mail, end with line containing only "."
	    ...
	   C: .
	   C: QUIT
	   S: 250 message sent
	   S: 221 goodbye

	所有的周轉次數(shù)從9減少到了4.
  下面的例子說明了使用流水線服務時,當所有的郵件接收者都無效時的一種可能情形.

	   S: <wait for open connection>
	   C: <open connection to server>
	   S: 220 innosoft.com SMTP service ready
	   C: EHLO dbc.mtview.ca.us
	   S: 250-innosoft.com
	   S: 250 PIPELINING
	   C: MAIL FROM:<mrose@dbc.mtview.ca.us>
	   C: RCPT TO:<nsb@thumper.bellcore.com>
	   C: RCPT TO:<galvin@tis.com>
	   C: DATA
	   S: 250 sender <mrose@dbc.mtview.ca.us> OK
	   S: 550 remote mail to <nsb@thumper.bellore.com> not allowed
	   S: 550 remote mail to <galvin@tis.com> not allowed
	   S: 554 no valid recipients given
	   C: QUIT
   S: 221 goodbye 
	客戶端也是等待服務器4次. 但是如果服務器在接受DATA之前不對接收者進
行至少一個有效的檢驗,則是以下的情形:
            S: <wait for open connection>
	   C: <open connection to server>
	   S: 220 innosoft.com SMTP service ready
	   C: EHLO dbc.mtview.ca.us
	   S: 250-innosoft.com
	   S: 250 PIPELINING
	   C: MAIL FROM:<mrose@dbc.mtview.ca.us>
	   C: RCPT TO:<nsb@thumper.bellcore.com>
	   C: RCPT TO:<galvin@tis.com>
	   C: DATA
	   S: 250 sender <mrose@dbc.mtview.ca.us> OK
	   S: 550 remote mail to <nsb@thumper.bellore.com> not allowed
	   S: 550 remote mail to <galvin@tis.com> not allowed
	   S: 354 enter mail, end with line containing only "."
	   C: .
	   C: QUIT
	   S: 554 no valid recipients
	   S: 221 goodbye
	
5 安全方面的考慮
 	 本RFC不討論安全性問題,但是可以相信它不會給電子郵件帶來新的安全漏洞.
而且, 本RFC描述的工作過程與[RFC-821]實現(xiàn)完全一致.
6 致謝
該文擋基于在RFC 1425中論述的SMTP服務擴展模型. 另外,Marshall Rose在他的
著作"The Internet Message" 一書中對命令流水線的論述對該文擋提供了很多啟發(fā)和幫
助.
6 參考資料
	   [RFC-821]  Postel, J., "簡單郵件傳輸協(xié)議", STD 10, RFC
              821, August 1982.
[RFC-1123] Braden, R., "因特網(wǎng)主機需求 --應用和支持", STD 3, RFC 1123, 
October, 1989.
	   [RFC-1854] Freed, N., "SMTP命令流水線的服務擴展", RFC 1854, October 1995.
	   [RFC-1869] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
              Crocker, "SMTP 服務擴展", STD 10, RFC 1869,
              November 1995.
[RFC-2197] Freed, N., "SMTP 針對命令流水線的服務擴展", RFC 2197, 
September 1997.

8.作者的地址
	Ned Freed
   Innosoft International, Inc.
   1050 Lakes Drive
   West Covina, CA 91790
   USA

   Phone: +1 626 919 3600
   Fax:   +1 626 919 361
   EMail: ned.freed@innosoft.com

   This document is a product of work done by the Internet Engineering
   Task Force Working Group on Messaging Extensions, Alan Cargille,
   chair.

9.版權說明
	Copyright (C) The Internet Society (2000).  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.

   
致謝
感謝Internet協(xié)會給予RFC編輯部門的資金。


RFC2920 SMTP Service Extension for Command Pipelining   SMTP 針對命令流水線的服務擴展


1
RFC文檔中文翻譯計劃