邮件服务器分为哪两个部分

楼主您好！
邮件服务器基本原理
电子邮件的运行机制由IETF（Internet Engineering Task Force，Internet工程任务组）出版的一组相关RFC（Request for Commen，请求注解）文档定义，其中包括了SMTP（Simple Mail Transfer Protocol，简单邮件传输协议）、POP3（邮局协议3）、IMAP4（Internet Mail Access Protocol 4，Internet邮件访问协议4）、MIME（Multipurpose Internet Mail Extensions，多用途的Internet邮件扩展协议）等标准规范。电子邮件服务在实现中一般分为两个部分，即MUA（Mail User Agent，邮件用户代理）和MTA（邮件传送代理），MUA负责提供用户管理邮件的界面，而MTA则负责邮件的传递。LDA（Local Deliver Agent，邮件投递代理），投递邮件到本地邮箱。
1、 SMTP、MTA和MUA
SMTP定义了邮件服务器间的通信，它的端口号为25。RFC821描述了它的工作原理。SMTP的工作原理：
A、客户机通过Telnet命令与服务器的25号端口建立一个TCP连接，连接成功后，服务器返回一个表示通信连接成功的220应答代码（telnet localhost 25）。
Ｂ、发送HELLO，向服务器标识发件人的身份，若成功，则会收到250应答码（HELO localhost）。
Ｃ、使用MAIL FROM：命令给服务器传送发信人地址（MALO localhost）。
Ｄ、使用RCPT TO：命令传送收信人地址，可以传送多个收件人地址。
E、向服务发送DATA命令，准备开始传送邮件内容，服务器若返回354应答码，即表示已经准备接收邮件内容。
F、使用QUIT命令退出通信过程。
2、 邮局与POP3/IMAP
POP协议规定：用户的电子邮件投递到一个中间机器上，叫做POP服务器。POP客户机连接到这个服务器，取出信件，并删除它们（通过PC机110端口与服务器进行连接）。
IMAP同POP一样，提供客户机存取远程服务器的的信件的功能，但它比POP提供更有效、更强大的邮件访问功能
a、支持同时对多个远程信箱进行访问
b、支持多客户机同时访问一个信箱
c、支持多个用户作为不同的标示同时访问一个文件夹
d、支持客户机取出信件的结构信息和信件的子集
e、IMAP支持客户机与服务器之间的同步
IMAP客户机通过TCP端口143与服务器进行连接。

它是—种用电子手段提供信息交换的通信方式。
是互联网应用最广的服务。通过网络的电子邮件系统，用户可以以非常低廉的价格（不管发送到哪里，都只需负担网费）、非常快速的方式（几秒钟之内可以发送到世界上任何指定的目的地），与世界上任何一个角落的网络用户联系。
电子邮件可以是文字、图像、声音等多种形式。同时，用户可以得到大量免费的新闻、专题邮件，并实现轻松的信息搜索。电子邮件的存在极大地方便了人与人之间的沟通与交流，促进了社会的发展。
电子邮件在Internet上发送和接收的原理可以很形象地用我们日常生活中邮寄包裹来形容：当我们要寄一个包裹时，我们首先要找到任何一个有这项业务的邮局，在填写完收件人姓名、地址等等之后包裹就寄出而到了收件人所在地的邮局，那么对方取包裹的时候就必须去这个邮局才能取出。
同样的，当我们发送电子邮件时，这封邮件是由邮件发送服务器（任何一个都可以）发出，并根据收信人的地址判断对方的邮件接收服务器而将这封信发送到该服务器上，收信人要收取邮件也只能访问这个服务器才能完成。

Linux会是未来社会的主流,如果微软的产品还是很贵的话,所以说开发LINUX是很有前途的

支持多传输域:sendmai支持在Internet,DECnet,X400及UUCP之间转发消息。Postfix则灵活的设计为无须虚拟域(vistualdomai)或别名来实现这种转发。但是在早期的发布里仅仅支持STMP和有限度地支持UUCP,但对于我国用户来说，多传输域的支持没有什么意义。

虚拟域:在大多数通用情况下，增加对一个虚拟域的支持仅仅需要改变一个Postfix查找信息表。其他的邮件服务器则通常需要多个级别的别名或重定向来获得这样的效果。

UCE控制(UCE,unsolicitedcommercialemail):Postfix能限制哪个主机允许通过自身转发邮件，并且支持限定什么邮件允许接进。Postfix实现通常的控制功能:黑名单列表、RBL查找、HELO/发送者DNS核实。基于内容过滤当前没有实现。

表查看:Postfix没有实现地址重写语言，而是使用了一种扩展的表查看来实现地址重写功能。表可以是本地dbm或db文件等格式。

Postfix体系结构及与Sendmail的比较

Postfix是基于半驻留，互 *** 作的进程的体系结构，每个进程完成特定的任务，没有任何特定的进程衍生关系(父子关系)。而且，独立的进程来完成不同的功能相对于“单块”程序具有更好的隔离性。此外，这种实现方式具有这样的优点:每个服务如地址重写等都能被任何一个Postfix部件所使用，无须进程创建等开销，而仅仅需要重写一个地址，当然并不是只有postfix采用这种方式。

Postfix是按照这种方式实现的:一个驻留主服务器根据命令运行Postfix守护进程，守护进程完成发送或接收网络邮件消息，在本地递交邮件等等功能。守护进程的数目由配置参数来决定的，并且根据配置决定守护进程运行的次数(re-usedtimes)，当空闲时间到达配置参数指定的限度时，自动消亡。这种方法明显地降低了进程创建开销，但是单个进程之间仍然保持了良好的隔离性。

Postfix的设计目标就是成为Sendmail的替代者。由于这个原因，Postfix系统的很多部分，如本地投递程序等，可以很容易地通过编辑修改类似inetd的配置文件来替代。

Postfix的核心是由十多个半驻留程序实现的。为了保证机密性的原因，这些Postfix进程之间通过Unix的socket或受保护的目录之下的FIFO进行通信。即使使用这种方法来保证机密性，Postfix进程并不盲目信任其通过这种方式接收到的数据。

Postfix进程之间传递的数据量是有限制的。在很多情况下，Postfix进程之间交换的数据信息只有队列文件名和接收者列表，或某些状态信息。一旦一个邮件消息被保存进入文件，其将在其中保存到被一个邮件投递程序读出。

Postfix采用一些通常的措施来避免丢失信息:在收到确认以前通过调用flush和fsync()保存所有的数据到磁盘中。检查所有的系统调用的返回结果来避免错误状况。

大多数构建邮件服务器者都会选择sendmail，公平的来讲sendmail是一个不错的MTA(MailTransferAgent)，最初开发时EricAllman的设计考虑主要放在了邮件传递的成功性。不幸的是，Sendmai开发时没有太多的考虑Internet环境下可能遇到的安全性问题。Sendmail在大多数系统上只能以根用户身份运行，这就意味着任何漏洞都可能导致非常严重的后果，除了这些问题之外，在高负载的情况Sendmail运行情况不是很好。当然，Sendmail具有一些缺点，其特色功能过多而导致配置文件的复杂性。当然，通过使用m4宏使配置文件的生成变的容易很多。但是，要掌握所有的配置选项是一个很不容易的事情。Sendmail在过去的版本中出现过很多安全漏洞，所以使管理员不得不赶快升级版本。而且Sendmail的流行性也使其成为攻击的目标，这有好处也有坏处:这意味着安全漏洞可以很快地被发现，但是同样使Sendmail更加稳定和安全。另外一个问题是Sendmail一般缺省配置都是具有最小的安全特性，从而使Sendmail往往容易被攻击。如果使用Sendmail，应该确保明白每个打开的选项的含义和影响。一旦你理解了Sendmail的工作原理，就Sendmail的安装和维护就变的非常容易了。通过Sendmail的配置文件，用户实现完成一切可以想象得到的需求。

Qmail是一个选择，其在设计实现中特别考虑了安全问题。如果你需要一个快速的解决方案如，一个安全的邮件网关，则Qmail是一个很好的选择。Qmail和Sendmail的配置文件完全不同。而对于Qmail，其有自己的配置文件，配置目录中包含了5-30个不同的文件，各个文件实现对不同部分的配置(如虚拟域或虚拟主机等)。这些配置说明都在man中有很好的文档，但是Qmail的代码结构不是很好。

Qmail要比Sendmail小很多，其缺乏一些现今邮件服务器所具有的特色功能。如不象Sendmail，qmail不对邮件信封的发送者的域名进行验证，以确保域名的正确性。自身不提供对RBL的支持，而需要add-on来实现。，而Sendmail支持RBL。同样Qmail不能拒绝接收目的接收人不存在信件，而是先将邮件接收下来，然后返回查无此用户的的邮件。Qmail最大的问题就出在发送邮件给多个接收者的处理上。若发送一个很大的邮件给同一个域中的多个用户，Sendmail将只向目的邮件服务器发送一个邮件拷贝。而Qmail将并行地连接多次，每次都发送一个拷贝给一个用户。若用户日常要发送大邮件给多个用户，使用Qmail将浪费很多带宽。可以这么认为:Sendmail优化节省带宽资源，Qmail优化节省时间。若用户系统有很好的带宽，Qmail将具有更好的性能，而如果用户系统的带宽资源有限，并且要发送很多邮件列表信息，则Sendmail效率更高一些。Qmail不支持forward(forward在很多情况下对用户很有用处);不使用/var/spool/mail，而是将邮件存放在用户home目录。下面是一些使用Qmail不容易完成的工作，要使用Qmail完成这些工作，可能需要用户自己动手实现或者使用第三方提供的不够可靠的模块。

Qmail的源代码相对于Sendmail来说要更加容易理解，这对于希望深入到内部了解MTA机制的人员来说是一个优点。Qmail在安全性方面也要稳定一些。Qmail有很好的技术支持，但是没有象Sendmail那样被广泛地应用和大量的管理员用户群。Qmail的安装不象Sendmail那样自动化，需要手工步骤。而且Qmail的文档不如Sendmail那样完整和丰富。

Qmail的add-ons比Sendmail要少一些。一般来说对于经验稍微少一些的管理员，选择Qmail相对要好一些。Qmail要简单一些，而且其特色功能能满足一般用户的需求。Sendmail类似于Office套件，80%的功能往往都不被使用。这就使Qmail在一些场合可能被更受欢迎一些，其具有一些Sendmail所没有的更流行和实用的特色功能，如mail具有内置的pop3支持。Qmail同样支持如主机或用户的伪装、虚拟域等等。Qmail的简单性也使配置相对容易一些。

本文以数据库的基本原理为基础，分析了EXCHANGE SERVER的存储系统，并说明了各部分的作用。

一、IS服务和ESE的层次关系

IS服务是EXCHANGE服务器中重要的服务之一，它控制着对邮箱和PF的存储 *** 作请求，EXCHANGE服务器的存储实际上是由ESE的数据库引擎来管理的。这个ESE引擎是微软专门为保存非关系型数据而开发的，目前在微软的很多产品中都有广泛的应用，如：AD数据库、DHCP、WINS、SRS等等。

EXCHANGE的数据库是由EDB文件、STM文件和LOG文件组成。在这些文件里，微软使用了“B+树”的内部数据结构。ESE的引擎的任务之一，就是当IS服务请求访问数据库的时候，把这些请求转化为对内部数据结构的读写访问。B+树的特点是能够对存储在硬盘上的数据提供快速访问能力。微软利用“B+树”作为ESE的后台结构的主要原因，就是尽可能的提高访问数据时I/O性能。当然，这些结构对于EXCHANGE STORE来说是透明的。

另外，作为一个数据库系统，ESE有责任提供事务级别的 *** 作的支持，并维护数据库的完整性和一致性。对数据库系统而言，我们提到事务时，一般用ACID来描述事务的特点。

A--Atomic（原子的）：事务必须是全或全无的 *** 作，要么全部成功更新，要么全部不被更新

C--Consistent（一致的）：一个成功提交的事务必须使数据库处于一个一致的状态。

I--Isolated（孤立的）：所有未提交的更改都必须能够和其他事务孤立。

D--Durable（持久的）：当事务一旦提交，所做的更改必须存储到稳定的介质上，防止系统失败导致的数据库不一致。（此点非常重要！！）

二、EXCHANGE 2000/2003存储系统的新特点

在EX55中，ESE的版本为ESE97，而在EX2000/2003里，ESE版本已经升级ESE98了。ESE引起在以下方面得到了改进：

I/O性能进一步提高和优化

对日志文件增加了计算校验 *** 作

提高了ESEUTIL等工具的维护速度

而IS也在以下方面有了更新：

在每个SERVER上提供多个SG支持

数据库STM文件格式的引入，提高了INTERNET邮件的性能

WSS的引入，用户可以使用多种协议访问数据库

三、EDB和STM的关系

常有人问，EDB文件是数据库，那STM文件是做什么用的？可以删除吗？

在EX55里，只有EDB文件，因为在EX55发布时，微软主推的是内部邮件系统，因此其主要协议为MAPI，这是微软的私有邮件西医，EDB文件是专门为此协议优化过的。因此在EX55中，为了支持INTERNET邮件，必须在每次处理INTERNET邮件时，做一个格式转换。这显然带来了性能的损失。

在EX2000里，微软加大了对INTERNET邮件的支持，这就是STM文件的来源。MAPI格式是RPC和二进制标准的，而STM是纯文本加上一些MIME编码格式，这样的区别使得它们不可能存储在同一数据库里。因此EX2000中，微软开始使用EDB和STM两个文件来分别保存两种格式的邮件。并且在两个文件之间建立了引用和关联。对于用户来说，它的邮箱实际上是跨越了EDB和STM文件共同组成的。另外，需要注意的是，EDB文件中还保留着用户的邮箱结构。所以EDB文件更加重要。那么EDB和STM是怎么协同工作的呢？我们以几个情景来分析之。

情景一：用户使用OUTLOOK（MAPI）发送接收邮件

在该情景下，用户将邮件通过MAPI协议提交给数据库，直接被保存EDB文件中。当用户通过MAPI访问邮箱里的邮件时，如果被访问的邮件在EDB里，直接返回，如果在STM里（如外来邮件），则执行转换，将STM转换为EDB文件格式，再返回用户。

情景二：用户使用标准SMTP/POP3/IMAP4等协议访问

用户使用非MAPI协议提交的邮件，内容保存在STM文件里，但是由于EDB里有邮箱结构，STM没有，因此系统会把邮件的重要信息提取出来，放在EDB里。当用户用MAPI提取邮件时，过程同上，当用户通过标准协议访问时，同样需要进行格式转换，转换为STM文件格式返回。 这些转换是在后台发生的。对用户来说是透明的。通过上面的描述，你会看到，这两个文件是紧密联系的缺一不可。所以，在任何时间我们都不要单独 *** 作这两个文件，它们是一个整体。同时也要注意的是，无论用户使用何方式访问邮箱，都需要向EDB文件请求邮箱结构信息，这是需要注意的。

四、LOG文件的重大作用

在论坛里经常会看到有人说我的硬盘怎么很快就没了，一看原来是日志文件搞的鬼，于是就有人删除日志文件，甚至使用循环日志来强制减少日志，甚至有人提出这样的疑问，日志到底有什么用？是不是多余的'？那我们来看看日志的重大作用。

对于一个SG来说，系统会产生一系列的日志，这些日志的扩展名为LOG，前缀一般是E00、E01……除了这些连续的日志文件外，还有一些特殊的日志文件（res1log,res2log,e0xchk））），它们又有什么用呢？我们的管理员通常不喜欢备份这一 *** 作，因此对这些日志是痛恨不已啊。那么微软在EXCHANGE数据库系统中引入日志的作用难道真的是多此一举吗？我们从以下几个方面来考察一下日志的作用：

1、作为一个企业级的邮件系统，必须要保证数据安全和完整。必须能够面对随时可能发生的意外灾难，把数据损失降低到最小。

2、必须提供高性能的邮件处理能力，对数据库中的邮件的事务 *** 作在完成后必须马上（或是说立即）被记录在存储介质上（见前面的事务持久性说明）

3、灾难发生后，使用数据库备份恢复必须要返回到灾难发生前一刻的数据库状态（这是至关重要的！！）

现在我们来更进一步的看一下，当用户要修改邮箱中的内容时，被修改的内容首先被提取出来放到内存中，实际的修改是发生在内存里的，这是众所周知的，当修改完成后，这些内容必须被尽快写回存储介质，这样才表示一个事务成功完成了。

从事务的描述中我们可以看到，事务是具有原子特性的，为了保证数据库的一致和完整，事务必须全部成功或全部失败，如果事务失败，则必须回滚到事务开始的状态。而当邮件在内存中修改完成后，此时事务并没有完成（为什么呢？）因为一旦系统崩溃，这些修改就丢失了。所以要确保事务修改完成，必须尽快将修改写回到数据库里去（也就是硬盘上）。这也是事务的持久性要求。注意，我们这里说的第一时间或是尽快，是一个什么样的概念。如果我们直接修改EDB文件，由于EDB

文件比较大，那么在硬盘上修改一个大文件，就 需要花费大量的时间在等待和寻找数据存储块上（见 *** 作系统原理），当系统出现高负载的繁忙状态时，这将是一个非常大的瓶颈。也就无法做到“尽快”了。那怎么办呢？所以数据库系统使用了日志，而日志通常很小（EXCHANGE的日志只有5MB），向这些文件写入修改结果是很快速的，因此当内存的修改完成后，这些结果就会立即写入日志中，以保证了事务的持久性。当成功写入日志后，该事务就成功完成了（现在在硬盘上了，不会因为当机丢失了）接下来，ESE引擎会在后台慢慢将这些日志里的修改记录写回真正的数据库里去（这对用户来说已经不是那么重要了），这就是日志的第一个作用：确保事务在第一时间（尽可能快的）保存到非易失存储器上（提供了事务持久性支持）。

根据上面的藐视，我们看到运行中的EXCHANGE数据库，是由三个部分组成的：

内存中已经完成处理还没有写会到日志里的内容（Dirt page）

还没有写到数据库文件里的日志内容

EDB和STM数据库文件

对于第一个部分，一旦掉电就回丢失的，是最不安全的。而对于第二部分的内容，系统通过检查点文件（CHK）来标记哪些日志已经被写入数据库了，而哪些还没有。CHK文件类似一个指针。我们可以用“ESEUTIL /MK”来检查CHK文件里的内容，在该命令的输出中的checkpoint:<0x8,26d1,29>这样的东西就是检查点位置，它表示E0x00008的日志的页面序号已经被成功写入数据库了。大家可以自己看看。。：）

前面提到过，EXCHANGE系统在出现灾难时，应能恢复到灾难发生前的时刻的状态。这是非常重要的。但即使是最勤快的管理员，也只能在指定的预定时间内做系统备份，而不可能时时刻刻的都在备份。那么在备份完成后到灾难发生之前的这段数据该如何保护呢？是不是就任由它丢失呢？显然是不可能的。那答案是什么呢？就是日志文件。前面我们知道，任何对数据库的更改都先写入日志里，再由日志写入数据库，这样我们只要找到日志文件，就可以重新进行模拟的 *** 作来完成备份后的数据库文件的更改了，我们举个例子来看看：

假设我们在凌晨3点完成了一次FULLBACKUP，备份完成后，系统正常运行，到下午4点的时候，系统突然崩溃。管理员用凌晨3点的数据恢复了数据库，那么从凌晨3点到下午4点这段时间的数据变更，就只能依赖于日志了。当完成数据库恢复后，系统会自动的跟踪到关联的日志文件，如果发现有比当前数据库还新的日志存在，系统就会自动的按照日志的顺序将更改写回到数据库中去。因此这样一来，从凌晨3点到下午4点的数据变更就被完整的恢复了。这就是日志的第二个作用：保证系统备份和恢复的完整性。当然前提是没有使用循环日志！！（看到了吧，使用循环日志的危害是相当大的，比起你的数据来说，多做几次备份不是没有意义的吧？

说到这里，有人可能要问，如果数据库和日志同时损坏，如何办？答案是：尽量避免这样的情况发生。首先数据库损坏的几率要大于日志，另外，微软建议将数据库和日志分别存储在不同的磁盘上，要是这样还会同时坏，那就没有办法了，呵呵。。对于管理员对日志文件的抱怨，合理的解决方法是定期做备份。启用循环日志是不正确的做法，当启用循环日志后，一旦系统发生灾难恢复，将有可能不能将系统恢复到灾难发生时的状态，磁盘和数据谁更重要，管理员自己要考虑考虑了。

五、ESE与IS服务的启动和关闭

ESE引擎在加载数据库文件时，会去检查数据库文件的标志。这个标志保留了上次关闭数据库的状态，当状态为正常关闭说，系统将直接加载该数据库，当数据库标志为非正常关闭时，系统将先进行一个软恢复过程（你可以在事件里看到它），然后再加载。

那么，正常关闭和非正常关闭有什么区别呢？一个正常关闭的数据库，表示所有的日志信息都已经正确的写入数据库了。反之一个非正常关闭的数据库，则表示至少有一部分数据未能正确的从日志写入数据库。要注意的是，非正常关闭的数据库并不等于已经被破坏的数据库。只表示有数据没有提交到数据库文件。

使用ESEUTIL/MH命令可以看到数据库的该状态，其中的STATE字段标记的就是这个状态，“CLEANSHUTDOWN”表示数据库正常关闭。当系统加载处于非正常关闭的数据库时，就会根据检查点文件确定日志文件的位置，并做重放 *** 作。当检查点文件丢失或损坏时，系统将从最早的日志文件开始处理。有的时候，系统不能自动的修复数据库，这时我们也可以用“ESEUTIL /R”命令手工的恢复处于非正常关闭状态的数据库。强烈推荐在系统异常关闭后执行此命令。在执行前最好前确定数据库文件的状态确实为非正常关闭，不要对正常关闭的数据库执行该恢复命令！

由此可见，EXCHANGE系统对数据库有自我修复能力，能确保系统在发生意外后恢复正确的状态。但这并不是说我们可以随意的关闭系统，仍要UPS等必要的保护措施。

六、关于M盘

在EX2000里，有一个M盘的映射。这个映射只是提供开发人员通过API访问邮箱和邮件用的。因此对M盘的手工 *** 作都可能带来数据库的破坏，请注意，另外，有一种观点认为备份了M盘就备份了邮件，这是绝对错误的。M盘虽然是数据库的映射，但已经去掉了很多的关联和内在联系。因此备份M盘是不能恢复数据库的。所有的EXCHANGE管理员必须按规定认真的备份系统状态和SG。切不可偷懒哦。

---