本备忘录的状态
本文档讲述了一种Internet社区的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
revokedbytheInternetSocietyoritssuccessorsorassigns.
Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.
致谢
感谢Internet协会给予RFC编辑部门的资金。
