本備忘錄的狀態(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)來獲得本協(xié)議的標(biāo)準(zhǔn)化
程度和狀態(tài)。本備忘錄的發(fā)布不受任何限制。
版權(quán)聲明
Copyright(C)TheInternetSociety(1999).AllRightsReserved.

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

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

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

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

1.1需求符號(hào)
在該文檔中,偶然會(huì)用到大寫的名詞.大寫的"MUST","MUST
NOT","SHOULD","SHOULDNOT",和"MAY"用來表示在本規(guī)范中的非凡需求.在
[RFC-1123]中有專門對(duì)這些名詞,例如"MUST","SHOULD"和"MAY"含義的介紹.而那些
名詞"MUSTNOT"和"SHOULDNOT"是對(duì)上述名字的邏輯擴(kuò)展.

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

假如沒有非凡說明,由其他SMTP擴(kuò)展協(xié)議定義的額外命令也只能放在命令組的結(jié)尾.

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

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

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

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

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

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


4舉例
考慮下面的沒有使用流水線的SMTP對(duì)話:
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
在這個(gè)簡(jiǎn)單的例子中,客戶端足足等了服務(wù)器的反饋9次,.但是假如采用流水
線服務(wù),則是下面的情形:

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

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

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
客戶端也是等待服務(wù)器4次.但是假如服務(wù)器在接受DATA之前不對(duì)接收者進(jìn)
行至少一個(gè)有效的檢驗(yàn),則是以下的情形:
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不討論安全性問題,但是可以相信它不會(huì)給電子郵件帶來新的安全漏洞.
而且,本RFC描述的工作過程與[RFC-821]實(shí)現(xiàn)完全一致.
6致謝
該文擋基于在RFC1425中論述的SMTP服務(wù)擴(kuò)展模型.另外,MarshallRose在他的
著作"TheInternetMessage"一書中對(duì)命令流水線的論述對(duì)該文擋提供了很多啟發(fā)和幫
助.
6參考資料
[RFC-821]Postel,J.,"簡(jiǎn)單郵件傳輸協(xié)議",STD10,RFC
821,August1982.
[RFC-1123]Braden,R.,"因特網(wǎng)主機(jī)需求--應(yīng)用和支持",STD3,RFC1123,
October,1989.
[RFC-1854]Freed,N.,"SMTP命令流水線的服務(wù)擴(kuò)展",RFC1854,October1995.
[RFC-1869]Klensin,J.,Freed,N.,Rose,M.,Stefferud,E.andD.
Crocker,"SMTP服務(wù)擴(kuò)展",STD10,RFC1869,
November1995.
[RFC-2197]Freed,N.,"SMTP針對(duì)命令流水線的服務(wù)擴(kuò)展",RFC2197,
September1997.

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

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

ThisdocumentisaPRodUCtofworkdonebytheInternetEngineering
TaskForceWorkingGrouponMessagingExtensions,AlanCargille,
chair.

9.版權(quán)說明
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
revokedbytheInternetSocietyoritssuccessorsorassigns.

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


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