SMTP协议规范

SMTP是工作在两种情况下:一是电子邮件从客户机传输到服务器;二是从某一个服务器传输到另一个服务器

  SMTP是个请求/响应协议,命令和响应都是基于ASCII文本,并以CR和LF符结束。响应包括一个表示返回状态的三位数字代码

  SMTP在TCP协议25号端口监听连接请求

  

  连接和发送过程:

  建立TCP连接

  客户端发送HELO命令以标识发件人自己的身份,然后客户端发送MAIL命令服务器端正希望以OK作为响应,表明准备接收

  客户端发送RCPT命令,以标识该电子邮件的计划接收人,可以有多个RCPT行服务器端则表示是否愿意为收件人接受邮件

  协商结束,发送邮件,用命令DATA发送,以.表示结束输入内容一起发送出去

  结束此次发送,用QUIT命令退出。

  另外两个命令:

  VRFY---用于验证给定的用户邮箱是否存在,以及接收关于该用户的详细信息

  EXPN---用于扩充邮件列表

  

  邮件路由过程:

  SMTP服务器基于’域名服务DNS中计划收件人的域名来路由电子邮件。SMTP服务器基于DNS中的MX记录来路由电子邮件,MX记录注册了域名和相关的SMTP中继主机,属于该域的电子邮件都应向该主机发送。

  若SMTP服务器mail.abc.com收到一封信要发到shuser@sh.abc.com:

  Sendmail请求DNS给出主机sh.abc.com的CNAME记录,如有,假若CNAME到shmail.abc.com,则再次请求

  

  shmail.abc.com的CNAME记录,直到没有为止

  假定被CNAME到shmail.abc.com,然后sendmail请求@abc.com域的DNS给出shmail.abc.com的MX记录

  shmail MX 5 shmail.abc.com

  10 shmail2.abc.com

  Sendmail最后请求DNS给出shmail.abc.com的A记录,即IP地址,若返回值为1.2.3.4

  Sendmail与1.2.3.4连接,传送这封给shuser@sh.abc.com的信到1.2.3.4这台服务器的SMTP后台程序

  

  SMTP基本命令集:

  命令 描述

  HELO 向服务器标识用户身份,发送者能欺骗,说谎,但一般情况下服务器都能检测到

  MAIL 初始化邮件传输 mail from:

  RCPT 标识单个的邮件接收人;常在MAIL命令后面,可有多个rcpt to:

  DATA 在单个或多个RCPT命令后,表示所有的邮件接收人已标识,并初始化数据传输,以.结束

  VRFY 用于验证指定的用户/邮箱是否存在;由于安全方面的原因,服务器常禁止此命令

  EXPN 验证给定的邮箱列表是否存在,扩充邮箱列表,也常被禁用

  HELP 查询服务器支持什么命令

  NOOP 无操作,服务器应响应OK

  QUIT 结束会话

  RSET 重置会话,当前传输被取消

  MAIL FROM命令中指定的地址是称作envelope from地址,不需要和发送者自己的地址是一致的

  RCPT TO 与之等同,指明的接收者地址称为envelope to地址,而与实际的to:行是什么无关

  

  为什么没有RCPT CC和RCPT BCC:?

  所有的接收者协商都通过RCPT TO命令来实现,如果是BCC,则协商发送后在对方接收时被删掉信封接收者,邮件被分为信封部分,信头部分和信体部分

  envelope from, envelope to 与message from:, message to:完全不相干

  evnelope是由服务器主机间SMTP后台提供的,而message from/to是由用户提供的。有无冒号也是区别

  

  怎样由信封部分检查是否一封信是否是伪造的?

  received行的关联性。现在的SMTP邮件传输系统,在信封部分除了两端的内部主机处理的之外,考虑两个公司防火墙之间的部分,若两台防火墙机器分别为A和B,但接收者检查信封received:行时发现经过了C.则是伪造的。

  received:行中的主机和IP地址对是否对应如:

  Receibed: from galangal.org (turmeric.com [104.128.23.115] by mail .bieberdorf.edu....

  被人手动添加在最后面的received行:

  Received: from galangal.org ([104.128.23.115]) by mail .bieberdorf.edu (8.8.5)

  Received: from lemongrass.org by galangal.org (8.7.3)

  Received: from graprao.com by lemongrass.org (8.6.4)

SMTP服务对命令流水的扩展

1.摘要

本文主要定义了一种SMTP服务扩展,使用这种服务扩展服务器可以说明它在一个TCP发送操作中可以接收多少个指令。在一个TCP发送指令中使用多个操作可以大大提高系统的运行效率。

2. 介绍

虽然SMTP服务已经广泛使用了,效果也不错,但是对它的扩展也是不可少的。如果某个网络需要很长时间进行连接,那SMTP运行的效果可就比较差了。SMTP的时间就费在等待一个个的命令上了。如果能够使SMTP客户端进行命令流水,也就是一次发送许多指令,就会提高运行效率。但以前的协议中没有说明这一条,客户无法知道服务器能够同时接收多少指令。因此产生了如下的一些问题:

连接过程中连接失控或缓冲区满; 

在SMTP命令失败时清除TCP输入缓冲区,有时这是没有必要的; 

对一些命令会不讲道理地判断它为失败,例如一些服务器如果在上一个REPT TO 失败后会再不接收DATA命令,而不管RCPT TO之前的命令是不是成功,而有些服务器则可以在RCPT TO命令失败后接收DATA命令。 

3. 命令流水扩展框架

它的定义如下:

此服务扩展的名称为流水(Pipelining); 

与EHLO相关联的扩展值是PIPELINING; 

PIPELINING EHLO不再参数; 

MAIL FROM或RCPT TO命令不附加其它参数; 

没有附加其它SMTP命令; 

4. 流水服务扩展

当客户机希望使用流水时,它会发送EHLO命令到服务器,如果服务器以250响应(其中的响应包括PIPELINING)就表明服务器支持SMTP服务流水。

4.1. 客户使用流水

在客户知道服务器可以支持流水的时候,客户可以传输多个命令(称为命令组)到服务器,不用发送一条等待一下然后再发一条,特别的RSET,MAIL FROM,SEND FROM,SOML FROM,SAML FROM和RCPT TO可以出现在命令组的任何地方。EHLO,DATA,VRFY,EXPN,TURN,QUIT和NOOP只能出现在命令组中的最后位置,因为它们成功与否将改变SMTP命令所处的状态。由其它SMTP扩展产生的命令只能出现在组中的最后位置。实际传送的命令可以是组中的第一个命令。

客户SMTP必须检查与组中据有相关的状态。如果RCPT TP接收地址未被接受,客户端必须检查DATA的状态,客户端不能假设因为没有RCPT TO是成功的所以DATA就会失败。如果DATA命令被正确拒绝,客户端可以发出RSET,如果DATA命令没有被正确拒绝,客户端要发出一个点(dot)。命令所产生的状态必须和分别发出每个命令时相同,必须支持多行(Multiline)响应。客户SMTP可以选择在非阻塞状态运行,它在接收到服务器的响应时立即处理,即使还有数据需要发送也不能推迟对响应的处理。如果不支持非阻塞状态,客户端必须检查TCP窗口的大小,TCP窗口的大小必须大于命令组的大小。窗口大小经常是4K,如果不能进行这样的检查,可能会导致死锁。

4.2. 服务器对流水的支持

服务器应该提供下面的服务扩展:

 

在任何情况下不行将TCP输入缓冲区的内容丢弃; 

当且仅当接收到一个或多个有效的RCPT TO命令时,才对DATA命令应该主动发出响应; 

因为DATA命令没有合法的接收者,结果接收到空信息时,不要再发出消息给任何人(当然对DATA命令还要做一个响应); 

对成组的RSET,MAIL FROM,SEND FROM,SOML FROM,SAML FROM和RCPT TO命令的响应先保存起来,然后一起发送; 

不允许缓存对EHLO,DATA,VRFY,EXPN,TURN,QUIT和NOOP的响应; 

不允许缓冲不可识别命令的响应; 

在本地TCP输入缓冲区为空时必须将据有未发出的响应全部发出; 

不允许对未接收到的命令进行猜测;或假设它的存在; 

在响应的文本信息中应该表时这是对哪个命令进行的响应; 

5. 例子

下面是一个不支持流水的SMTP会话:其中S代表服务器,C代表客户端;

S: <等待打开连接>;

C: <打开连接>;

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 传输邮件内容,并以一个只有”.”的行结束邮件

...

C: .

S: 250 message sent

C: QUIT

S: 221 goodbye

 

在上例中客户需要9次等待服务器的响应,下面我们来看看在支持流水的情况下是什么样子:其中S代表服务器,C代表客户端;

 

S: <等待打开连接>;

C: <打开连接>;

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 传输邮件内容,并以一个只有”.”的行结束邮件

...

C: .

C: QUIT

S: 250 message sent

S: 221 goodbye

 

现在等待的次数由9次变为了4次,下面我们看一下当据有接收者均被拒绝时会是什么情况:

 

S: <等待打开连接>;

C: <打开连接>;

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: <等待打开连接>;

C: <打开连接>;

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 传输邮件内容,并以一个只有”.”的行结束邮件

C: .

C: QUIT

S: 554 no valid recipients //未给出合法的接收者

S: 221 goodbye

该压缩包包含三个文档,分别是SMTP协议详解,POP3协议详解,MIME规范详解,文档中详细介绍了一个邮件发送和接收的过程分析,协议本身的包含的命令和工作过程,为开发邮件代理的客户端提供技术基础。如下是部分SMTP协议部分内容: 1.1 SMTP在邮件通信中的位置 SMTP,即简单邮件传送协议,所对应RFC文档为RFC821。同http等多数应用层协议一样,它工作在C/S模式下,用来实现因特网上的邮件传送。SMTP在整个电子邮件通信中所处的位置。可以看出,SMTP是用来将客户机上的邮件传送到服务器上。这里的客户机是指某次连接中的发送方,服务器是指相应的接收方。在讲解发送邮件的整个通信过程前,先解释一下面几个术语。 1.2几个术语 1.2.1.邮件 邮件是一种消息的格式,由信封、首部和正文组成。 信封上最重要的是收信人的地址。邮件服务器用这个地址将邮件发送到收信人所在的邮件服务器上。 首部是由用户代理或邮件服务器添加的一些信息。包括Received、Message-ID、From、Data、Reply-To、X-Phone、X-Mailer、To和Subject等字段。 正文是是发送用户发给接收用户报文的内容。RFC 822 规定正文为NVT ASCII文字行。 更为详细的说明,请参考RFC821和RFC822等协议。 1.2.2.用户代理 用户代理UA(User Agent)是用户与电子邮件系统的交互接口,一般来说它就是我们PC机上的一个程序。Windows上常见的用户代理是Foxmail和Outlook Express。 用户代理提供一个好的用户界面,它提取用户在其界面填写的各项信息,生成一封符合SMTP等邮件标准的邮件,然后采用SMTP协议将邮件发送到发送端邮件服务器
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值