文章发表在WinITPro杂志06年2月刊，转载请注明出处，并不允许修改和删节。
导读：
本文根据笔者在微软Technet Webcast上的讲稿整理而成。文章介绍了微软Exchange Server中的核心传输组件以及它们的工作原理，阐述了SMTP协议的内容和使用SMTP发送邮件时的详细过程；深入地讨论了邮件传输和路由的工作机制，分析了SMTP报文的组成和Exchange在传输邮件时的路由过程（包括AQ, Routing Engine等组件）。本文可以供Exchange管理员深入的了解邮件传输组件的内部工作方式。
STMP协议规范和命令字
SMTP协议是随着Internet的发展逐渐规范化和进一步完善的。SMTP协议最早在RFC821中被定义，它提供了Internet上两个节点之间传送信息的一种方式。SMTP协议非常的简单和直观，在RFC821中，STMP由一些通过ASCII码表示的命令字组成，通过这些命令字，两个节点之间(客户机和服务器)可以建立SMTP连接，并进行信息传递。SMTP的标准命令字和其作用如表一：
SMTP命令
作用
HELO
用于开始会话，通常在HELO后跟客户机的主机名(hostname)
用于指出发起会话的发件人，通常在MAIL后面跟From参数来指定发件人
RCPT
用于指定该消息的接收人，通常在RCPT后面跟To参数来指定收件人
DATA
表示客户端开始向服务器端发送消息(邮件) 正文
RSET
放弃当前的数据传输
VRFY
用以确定指定的收件人在服务器端是合法的(在发送邮件正文之前确定邮箱是否存在)，考虑到这个功能有一定的安全隐患(可能导致组织的邮件地址泄漏)，此命令在包括Exchange在内的大部分企业邮件系统中不被支持，SMTP服务器对VRFY请求，总是会返回”非法地址”
TURN
交换客户端和服务器角色，允许客户端触发服务器端的邮件传送（此命令也很少被使用）
QUIT
关闭当前会话
表一：SMTP标准命令字和其作用
SMTP服务器监听TCP 25号端口，并对客户端发送的合法命令做出响应。我们可以通过Telnet的方式演示一下最简单的SMTP邮件传送过程。表二中列出了使用Windows Telnet客户端跟Exchange SMTP Server通信的过程：（粗体表示用户输入，斜体表示服务器回应）
Telnet过程
注释
c:\telnet win2003.msft.com 25
220 win2003.msft.com Microsoft ESMTP Mail Service, Version 6.0.3790.0 ready at Tue, 18 Oct 2005 19:21:55 -0700
客户端通过TCP 25号端口连接服务器，SMTP服务器返回连接成功信息，并返回服务器操作系统类型，版本和当前时间。
HELO
250 win2003.msft.com Hello [192.168.1.100]
客户端通过HELO命令跟服务器开始通信，服务器以250回应表示服务器做好了进行通信的准备。
MAIL FROM:tom@msft.com
250 2.1.0 tom@msft.com...Sender OK
客户端提供发信人地址。
RCPT TO:mike@msft.com
250 2.1.5 mike@msft.com
客户端提供收信人地址。
DATA
354 Start mail input; end with .
客户端输入DATA命令，DATA之后的字符都将作为邮件的正文。正文以.终止。
Hello Mike,
Let’s have dinner together.
Tom
.
250 2.6.0 Queued mail for delivery
.表示连续的回车-换行-点号-回车-换行。正文传送完毕以后，服务器端会生成邮件并进行下一步的传送。
QUIT
221 2.0.0 win2003.msft.com Service closing transmission channel
使用QUIT命令结束当前会话。
表二：使用Telnet进行SMTP会话
通过Telnet进行SMTP会话在诊断一些邮件传输问题时非常有用，微软在其知识库文档中详细描述了使用Telnet进行SMTP会话的过程。（XFOR：Telnet 到端口 25 以测试 SMTP 通信，http://support.microsoft.com/default.aspx?scid=kb;zh-cn;153119）
在Exchange Server中，SMTP是邮件系统传输模块的核心，SMTP负责了组织内部邮件服务器间邮件的传送和对外发送邮件的重任。图一表示了SMTP模块在Exchange整个系统结构中的位置。SMTP协议栈运行在IIS的进程中，在IIS中，还有AQE和Routing模块协助SMTP的工作。Exchange的数据库模块(Information Store)通过EXIPC作为桥梁，跟SMTP进行通信。
520)this.width=520;" style="CURSOR: hand" onclick=javascript:window.open(this.src); src="http://www.5dmail.net/pic/exchange_4.gif" width=520 onload="javascript:if(this.width520)this.width=520;" align=absMiddle border=0 twffan="done"
图一：SMTP模块在Exchange中的位置
用户可以通过多种方式向Exchange服务器提交需要发送的邮件，例如，用户可以使用Outlook的MAPI方式，把邮件提交到Information Store中，也可以使用Outlook Express的SMTP方式，向SMTP服务器直接传送需要发送的邮件。Exchange上的SMTP模块，在不同的情况下承担的角色是不一样的，我们可以通过如下的情景分析，来透彻的了解SMTP服务器的工作方式。
用户可以通过多种方式向Exchange服务器提交需要发送的邮件，例如，用户可以使用Outlook的MAPI方式，把邮件提交到Information Store中，也可以使用Outlook Express的SMTP方式，向SMTP服务器直接传送需要发送的邮件。Exchange上的SMTP模块，在不同的情况下承担的角色是不一样的，我们可以通过如下的情景分析，来透彻的了解SMTP服务器的工作方式。
520)this.width=520;" style="CURSOR: hand" onclick=javascript:window.open(this.src); src="http://www.5dmail.net/pic/exchange_5.gif" width=520 onload="javascript:if(this.width520)this.width=520;" align=absMiddle border=0 twffan="done"
图二：SMTP服务器在不同情况下担任的角色
如图二，我们分6种情况来讨论SMTP服务器的不同角色。
连接1，2，3，4代表了Inbound连接(其中连接1中的MAPI客户端是把邮件直接提交到Information Store中，不属于SMTP连接)，当处理inbound连接时，图中的邮件服务器起到的是SMTP Server的角色。请注意，Inbound连接有两种类型，一种是客户端提交的邮件(连接2)，这种通常表示组织内的用户通过在Outlook Express软件中指定SMTP服务器IP地址，来向服务器提交需要发送的邮件；另一种类型是其他的SMTP服务器转发过来的邮件(连接3，4)，这通常表示当前邮件服务器是网关，或者是信件中收件人的邮箱所在的服务器。
连接5，6代表了Outbound连接，当处理outbound连接时，邮件服务器起到的是SMTP Client的角色，不管是发到外部，还是内部邮件的转发，都是由SMTP Client发起会话，并且由远端的服务器来响应。
由此我们可以发现，一台SMTP主机，它在运行过程中，既会承担SMTP Server的角色来接收Inbound连接所提交的SMTP报文，同时也会作为SMTP Client来向远程的服务器发送SMTP请求(Outbound)。只有分清楚了这些不同角色的含义，才可能透彻的了解Exchange的邮件传输过程。
如果把一封邮件的发送过程比喻为一次长途旅程，那么SMTP在其中只是扮演了交通工具的作用。大家可能已经注意到，对于一个给定的收件人地址(例如，abc@microsoft.com)，SMTP并没有定义到底与目标域中哪一个主机来建立连接来完成邮件的传输过程，也就是说，RFC 821中的SMTP并没有定义“寻址”的方法(下面提到的MX记录及邮件选路和域名系统的规范，在RFC 974中被详细定义)。
在Internet中，我们是通过DNS里面的MX记录来实现邮件的寻址的。当一个组织或者公司购买了一个Internet域名并且建立了邮件服务器以后，往往会把某一台或者几台服务器发布到外网，作为邮件网关，接收来自Internet的邮件。同时，需要在该域名DNS系统(这里指此域名在Internet上的DNS，而不是内网活动目录的DNS，千万不能混淆)的MX记录字段中，注册这些主机的名字，这样当给这个域中的邮箱发邮件时，发送方通过向Internet上DNS服务器查询该域名的MX记录，再确定有哪些服务器可以建立SMTP连接。我们可以使用NSLOOK这个命令，在查询特定域名下面注册的MX记录。如表三，我们查到了微软公司现有的MX记录。在输出的结果中，我们发现微软公司注册了三个主机名来作为接收外部邮件的服务器，并且当进一步解析DNS主机记录时，我们可以发现这三个主机名分别对应6个IP地址，通过这种做法，可以实现SMTP流量的负载均衡。(仔细看会发现这些IP地址属于两个不同的网段，应该是由不同的ISP提供的网络链路，这也在某种程度上实现了线路的互相备份和冗余。)
当我们架设邮件服务器系统时，只有正确的在ISP的DNS上设置了MX记录，才能够收到从外部发来的邮件。关于MX记录的更多信息，可以参考微软的知识库文档。(XFOR: DNS MX Records and CNAME http://support.microsoft.com/default.aspx?scid=kb;en-us;153001)
H:\nslookup
set q=mx
microsoft.com
DNS Server: ns-pxb.online.sh.cn
Address: 202.96.209.6
-----------Query Result-----------
microsoft.com MX preference = 10, mail exchanger = maila.microsoft.com
microsoft.com MX preference = 10, mail exchanger = mailb.microsoft.com
microsoft.com MX preference = 10, mail exchanger = mailc.microsoft.com
maila.microsoft.com internet address = 131.107.3.125
maila.microsoft.com internet address = 131.107.3.124
mailb.microsoft.com internet address = 207.46.121.51
mailb.microsoft.com internet address = 131.107.3.123
mailc.microsoft.com internet address = 207.46.121.53
mailc.microsoft.com internet address = 207.46.121.52
-----------Query Result-----------
表三：微软公司的MX记录设置
SMTP标准命令字最初定义在RFC821标准中，随着Internet的发展，这些命令逐渐无法满足一些特殊的邮件发送要求，比如，发送方身份的认证，数据加密，报文的传输优化等等。在RFC 1869中，国际标准化组织定义了扩展SMTP协议(Extended SMTP，简称ESMTP)，在原有的命令字基础之上，增加了如下表(表四)所示的的扩展命令：
ESMTP命令
作用
EHLO
作为标准HELO的替代者，客户端发送EHLO来跟服务器确定其对ESMTP的支持程度，服务器会返回一个它所支持的ESMTP命令字列表给客户端。
ATRN
TURN命令的增强，在启用TURN之前需要身份认证。
ETRN
TURN命令的增强，功能上与TURN类似，但是通过创建另外一个独立的会话完成TURN报文传送。
Pipelining
允许SMTP客户端在服务器响应之前以异步的方式连续发送若干的命令字。例如，可以在获得服务器确认之前，连续发送多个RCPT命令字，这样可以实现在慢速网络上的高效通信。
BDAT
此命令字替代DATA，允许客户端采用批量的方式传送消息报文，可以在一定程度上降低接收方的负载。
AUTH
允许客户端使用基本验证、Windows集成验证(NTLM和Kerberos)与服务器进行身份认证，进行身份认证也是避免SMTP服务器被relay的重要手段。
STARTTLS
用来表示客户端希望能够与服务器建立一个基于TLS的加密会话。
XEXCH50
用以传送Exchange服务器间专用的报头数据。这个命令会在下文讲解Exchange分类器的时候提到。
表四：ESMTP的扩展命令集
标准SMTP(RFC 821)和扩展SMTP(RFC 1869)都得到了当今主流邮件服务器的广泛支持，Exchange服务器完全兼容这两种类型的SMTP协议，并且还增加了一些用于Exchange服务器间通信的特殊SMTP命令字(非国际标准)。在一些特殊情况下(比如跟比较旧版本的邮件服务器进行SMTP通信)，我们也可以关闭Exchange Server上的ESMTP，使其只提供最简单和标准的RFC 821 SMTP协议，具体请参考：How to turn off ESMTP verbs in Exchange Server，http://support.microsoft.com/default.aspx?scid=kb;en-us;257569。
