1.SMTP是工作在两种情况下：一是电子邮件从客户机传输到服务器；二是从某一个服务器传输到另一个服务器
2.SMTP是个请求/响应协议，命令和响应都是基于ASCII文本，并以CR和LF符结束。响应包括一个表示返回状态的三位数字代码
3.SMTP在TCP协议25号端口监听连接请求
4.连接和发送过程：
?a.建立TCP连接
?b.客户端发送HELO命令以标识发件人自己的身份，然后客户端发送MAIL命令 服务器端正希望以OK作为响应，表明准备接收
?c.客户端发送RCPT命令，以标识该电子邮件的计划接收人，可以有多个RCPT行 服务器端则表示是否愿意为收件人接受邮件
?d.协商结束，发送邮件，用命令DATA发送
?e. 以.表示结束输入内容一起发送出去
?f.结束此次发送，用QUIT命令退出。
5.另外两个命令： VRFY---用于验证给定的用户邮箱是否存在，以及接收关于该用户的详细信息。 EXPN---用于扩充邮件列表。
6.邮件路由过程： SMTP服务器基于‘域名服务DNS中计划收件人的域名来路由电子邮件。SMTP服务器基于DNS中的MX记录 来路由电子邮件，MX记录注册了域名和相关的SMTP中继主机，属于该域的电子邮件都应向该主机发送。 若SMTP服务器 mail.abc.com 收到一封信要发到 :
?a.Sendmail请求DNS给出主机sh.abc.com的CNAME记录，如有，假若CNAME到shmail.abc.com，则再次请求shmail.abc.com的CNAME记录，直到没有为止
?b.假定被CNAME到 shmail.abc.com , 然后 sendmail 请求 @abc.com 域的DNS给出 shmail.abc.com 的MX记录， shmail MX 5 shmail.abc.com 10 shmail2.abc.com
?c. Sendmail 最后请求 DNS 给出 shmail.abc.com 的 A 记录，即 IP 地址，若返回值为1.2.3.4
?d. Sendmail 与 1.2.3.4 连接，传送这封给 的信到 1.2.3.4 这台服务器的SMTP后台程序
7.SMTP基本命令集：
命令 描述
------------------------------
HELO 向服务器标识用户身份
发送者能欺骗，说谎，但一般情况下服务器都能检测到。
MAIL 初始化邮件传输
mail from:
RCPT 标识单个的邮件接收人；常在MAIL命令后面可有多个rcpt to:
DATA 在单个或多个RCPT命令后，表示所有的邮件接收人已标识，并初始化数据传输，以.结束。
VRFY 用于验证指定的用户/邮箱是否存在；由于安全方面的原因，服务器常禁止此命令
EXPN 验证给定的邮箱列表是否存在，扩充邮箱列表，也常被禁用
HELP 查询服务器支持什么命令
NOOP 无操作，服务器应响应OK
QUIT 结束会话
RSET 重置会话，当前传输被取消
--------------------------------
8.MAIL FROM 命令中指定的地址是称作 envelope from 地址，不需要和发送者自己的地址是一致的。
RCPT TO 与之等同，指明的接收者地址称为envelope to地址，而与实际的to：行是什么无关。
9.为什么没有RCPT CC和RCPT BCC:?
所有的接收者协商都通过RCPT TO命令来实现，如果是BCC，则协商发送后在对方接收时被删掉信封接收者
10.邮件被分为信封部分，信头部分和信体部分
envelope from, envelope to 与message from:, message to:完全不相干。
evnelope是由服务器主机间SMTP后台提供的，而message from/to是由用户提供的。有无冒号也是区别。
11.怎样由信封部分检查是否一封信是否是伪造的？
?a. received行的关联性。
现在的SMTP邮件传输系统，在信封部分除了两端的内部主机处理的之个，考虑两个公司防火墙之间
的部分，若两台防火墙机器分别为Ａ和Ｂ，但接收者检查信封received：行时发现经过了C.则是伪造的。
?b. received：行中的主机和IP地址对是否对应如：
Receibed: from galangal.org (turmeric.com [104.128.23.115] by mail .bieberdorf.edu....
?c. 被人手动添加在最后面的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:<>;
S: 250 sender <>; OK
C: RCPT TO:<>;
S: 250 recipient <>; OK
C: RCPT TO:<>;
S: 250 recipient <>; OK
C: RCPT TO:<>;
S: 250 recipient <>; 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:<>;
C: RCPT TO:<>;
C: RCPT TO:<>;
C: RCPT TO:<>;
C: DATA
S: 250 sender <>; OK
S: 250 recipient <>; OK
S: 250 recipient <>; OK
S: 250 recipient <>; 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:<>;
C: RCPT TO:<>;
C: RCPT TO:<>;
C: DATA
S: 250 sender <>; OK
S: 550 remote mail to <>; not allowed
S: 550 remote mail to <>; 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:<>;
C: RCPT TO:<>;
C: RCPT TO:<>;
C: DATA
S: 250 sender <>; OK
S: 550 remote mail to <>; not allowed
S: 550 remote mail to <>; not allowed
S: 354 传输邮件内容，并以一个只有”.”的行结束邮件
C: .
C: QUIT
S: 554 no valid recipients //未给出合法的接收者
S: 221 goodbye
telnet smtp.163.com 110
telnet smtp.163.com 110\r\n
helo client\r\n返回欢迎信息
auth login\r\n这时候返回base64编码的Username;
输入用base64编码的用户名\r\n
返回base64编码的Password
输入用base64编码的密码\r\n
返回成功注册或不能login on信息.
然后就mail from :<>
rcpt to:<>
data
...
\r\n.\r\n.
rfc的文件这儿是中文的doc
阅读(2257) | 评论(0) | 转发(0) |
