SMTP 針對命令流水線的服務擴展

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

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

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

1.1需求符號
在該文檔中,偶爾會用到大寫的名詞.大寫的"MUST","MUST
NOT","SHOULD","SHOULDNOT",和"MAY"用來表示在本規范中的特殊需求.在
[RFC-1123]中有專門對這些名詞,例如"MUST","SHOULD"和"MAY"含義的介紹.而那些
名詞"MUSTNOT"和"SHOULDNOT"是對上述名字的邏輯擴展.

2命令流水線擴展的基本框架結構
命令流水線采用如下定義:
(1).這種SMTP服務擴展的名稱是流水線.
(2).關鍵字EHLO的值一定是PIPELINING.
(3).使用關鍵字PIPELININGEHLO時沒有參數.
(4).對命令MAILFROM和RCPTTO沒有定義額外的參數.
(5).沒有為擴展服務定義額外的SMTP動詞(命令).
(6).在下一章講解為了支持擴展服務,服務器和客戶端會受到怎樣的影響.
3流水線服務擴展
當一個SMTP客戶希望使用命令流水線時,它首先要向服務器發送EHLO 命令.如
果服務器返回代碼250,而且返回信息中包含關鍵字EHLO本身和它的值PIPELINING,
那么這說明該SMTP服務器支持命令流水線的特性.
3.1客戶端使用流水線
一旦SMTP客戶端確信服務器支持流水線的特性,那么它就可以不必等待每條命令
的回應而選擇使用一組SMTP命令發送到服務器.特別是,命令RSET,MAILFROM,
SENDFROM,SOMLFROM,SAMLFROM,和RCPTTO可以在命令組中任何地方
出現.而對EHLO,DATA,VERY,EXPN,TURN,QUIT,和NOOP,由于他們的返回結果很關
鍵,可能影響到整個連接的狀態,所以只能出現在命令組的末尾處.(NOOP也屬于此類
命令,所以它可以作為連接的同步點).

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

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

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

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

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

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

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


4舉例
考慮下面的沒有使用流水線的SMTP對話:
S:<waitforopenconnection>
C:<openconnectiontoserver>
S:220Innosoft.comSMTPserviceready
C:HELOdbc.mtview.ca.us
S:250Innosoft.com
C:MAILFROM:<mrose@dbc.mtview.ca.us>
S:250sender<mrose@dbc.mtview.ca.us>OK
C:RCPTTO:<ned@innosoft.com>
S:250recipient<ned@innosoft.com>OK
C:RCPTTO:<dan@innosoft.com>
S:250recipient<dan@innosoft.com>OK
C:RCPTTO:<kvc@innosoft.com>
S:250recipient<kvc@innosoft.com>OK
C:DATA
S:354entermail,endwithlinecontainingonly"."
...
C:.
S:250messagesent
C:QUIT
S:221goodbye
在這個簡單的例子中,客戶端足足等了服務器的反饋9次,.但是如果采用流水
線服務,則是下面的情形:

S:<waitforopenconnection>
C:<openconnectiontoserver>
S:220innosoft.comSMTPserviceready
C:EHLOdbc.mtview.ca.us
S:250-innosoft.com
S:250PIPELINING
C:MAILFROM:<mrose@dbc.mtview.ca.us>
C:RCPTTO:<ned@innosoft.com>
C:RCPTTO:<dan@innosoft.com>
C:RCPTTO:<kvc@innosoft.com>
C:DATA
S:250sender<mrose@dbc.mtview.ca.us>OK
S:250recipient<ned@innosoft.com>OK
S:250recipient<dan@innosoft.com>OK
S:250recipient<kvc@innosoft.com>OK
S:354entermail,endwithlinecontainingonly"."
...
C:.
C:QUIT
S:250messagesent
S:221goodbye

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

S:<waitforopenconnection>
C:<openconnectiontoserver>
S:220innosoft.comSMTPserviceready
C:EHLOdbc.mtview.ca.us
S:250-innosoft.com
S:250PIPELINING
C:MAILFROM:<mrose@dbc.mtview.ca.us>
C:RCPTTO:<nsb@thumper.bellcore.com>
C:RCPTTO:<galvin@tis.com>
C:DATA
S:250sender<mrose@dbc.mtview.ca.us>OK
S:550remotemailto<nsb@thumper.bellore.com>notallowed
S:550remotemailto<galvin@tis.com>notallowed
S:554novalidrecipientsgiven
C:QUIT
S:221goodbye
客戶端也是等待服務器4次.但是如果服務器在接受DATA之前不對接收者進
行至少一個有效的檢驗,則是以下的情形:
S:<waitforopenconnection>
C:<openconnectiontoserver>
S:220innosoft.comSMTPserviceready
C:EHLOdbc.mtview.ca.us
S:250-innosoft.com
S:250PIPELINING
C:MAILFROM:<mrose@dbc.mtview.ca.us>
C:RCPTTO:<nsb@thumper.bellcore.com>
C:RCPTTO:<galvin@tis.com>
C:DATA
S:250sender<mrose@dbc.mtview.ca.us>OK
S:550remotemailto<nsb@thumper.bellore.com>notallowed
S:550remotemailto<galvin@tis.com>notallowed
S:354entermail,endwithlinecontainingonly"."
C:.
C:QUIT
S:554novalidrecipients
S:221goodbye

5安全方面的考慮
本RFC不討論安全性問題,但是可以相信它不會給電子郵件帶來新的安全漏洞.
而且,本RFC描述的工作過程與[RFC-821]實現完全一致.
6致謝
該文擋基于在RFC1425中論述的SMTP服務擴展模型.另外,MarshallRose在他的
著作"TheInternetMessage"一書中對命令流水線的論述對該文擋提供了很多啟發和幫
助.
6參考資料
[RFC-821]Postel,J.,"簡單郵件傳輸協議",STD10,RFC
821,August1982.
[RFC-1123]Braden,R.,"因特網主機需求--應用和支持",STD3,RFC1123,
October,1989.
[RFC-1854]Freed,N.,"SMTP命令流水線的服務擴展",RFC1854,October1995.
[RFC-1869]Klensin,J.,Freed,N.,Rose,M.,Stefferud,E.andD.
Crocker,"SMTP服務擴展",STD10,RFC1869,
November1995.
[RFC-2197]Freed,N.,"SMTP針對命令流水線的服務擴展",RFC2197,
September1997.

8.作者的地址
NedFreed
InnosoftInternational,Inc.
1050LakesDrive
WestCovina,CA91790
USA

Phone:+16269193600
Fax:+1626919361
EMail:ned.freed@innosoft.com

ThisdocumentisaproductofworkdonebytheInternetEngineering
TaskForceWorkingGrouponMessagingExtensions,AlanCargille,
chair.

9.版權說明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuclearcase/" target="_blank" >ccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.


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