简述Postfix的工作原理

传统的Sendmail将所有功能都集中在同一个程序里，这种结构我们称之为“单体式设计”(monolithic).Postfix采用专职负责的策略，不同的功能分别交由不同的专门程序处理，这种结构称为“模块化设计”(modular)。这些自成一格的专门程序，我们称之为组件(component)。大多数组件都是以daemon的形式存在，也就是常驻在系统内存里的连续动作的后台进程(background process)。
　　当Postfix被启动后，首先启动的是master daemon，它主导邮件的处理流程，同时也是其他组件的总管。在处理邮件的过程中，master会启动对应功能的组件来处理相关事宜，被master启动的组件，在完成交付的工作之后会自行结束；或者，如果组件的处理时间超过时限，或是工作量到达预定限度，组件也会自行结束。master daemon会常驻在系统中，当管理员启动它时，它从main.cf和master.cf这两个配置文件取得启动参数。

Postfix内部收信、发信流程图

整个处理流程分为三个阶段：接收邮件、将邮件排入队列、递送邮件。每个阶段由一组独立的Postfix组件负责。当一封邮件被收下并排入队列之后，队列管理器(Queue Manager)会启动适当的MDA，将邮件送到终点。

邮件如何进入Postfix系统

邮件有四种渠道可以进入Postfix系统：
　　1、Postfix可接受来自本机系统的邮件(本机用户或自主进程提交的邮件)。
　　2、Postfix可接受网络传入的邮件(来自MUA或者其他MTA)。
　　3、已经被Postfix收下并交给MDA的邮件，被MDA传回到Postfix(通常是为了转寄到另一个地址)。
　　4、当Postfix无法将邮件寄到目的地时，自己会产生退信通知函。
　　邮件有可能在进入Postfix之前就被拒绝了，或者因为暂时性的故障(网络断线、远程服务器响应暂时性的错误等)，同样的邮件可能会每隔一段时间就重复进入Postfix系统一次，重新递送。

来自服务器本机的邮件

各个Postfix组件之间的合作全靠队列(Queue)交换邮件、Postfix系统有多个队列，这些队列全部队列管理器(Queue Manager)负责控制管理。Postfix组件可将邮件交付给Queue Manager，由其代为放入适当的队列。当需要处理特定工作时，Queue Manager将队列里的邮件交付给正确的组件。
　　在Unix系统上，当用户要寄出邮件时(不管这封信是寄到哪里)，通常是使用sendmail包内的sendmail命令。Postfix提供了一个与此命令兼容的同名工具，也称为sendmail。当用户以Postfix的sendmail寄出邮件后，sendmail(postfix的版本)会使用postdrop程序将邮件存入Postfix队列目录下的maildrop/子目录。专门注意maildrop子目录有无变化的是Pickup Daemon，每当有新的邮件进入maildrop时，Pickup Daemon便会读出新邮件，然后交给cleanup daemon进入“清理程序”。
　　当邮件刚进入Postfix时，不一定含有构成有效邮件的所有必要字段，而且标头里的地址也可能需要被改写成标准格式([e-mail])，并依据规范的或虚拟的查询表(如果有的话)将原本的地址改成其他地址。所谓的“清理程序”就是补足遗漏的标头字段，这部分工作由cleanup daemon负责；地址的处理由Trivial-Rewrite Daemon负责。
　　经过Cleanup Daemon处理好的邮件，会被传入收件队列(Incoming Queue)。Queue Manager会不断的注意收件队列的变化，每当有新邮件进入收件队列时，便会用适当的MDA将邮件送到下一站，或直接送到最终目的地。

来自网络的邮件

来自网络的邮件由Postfix Smtpd Daemon接收进来，然后交给Cleanup Daemon运行清理程序，随后排入收件队列，由Queue Manager选择适当的MDA将邮件送到下一站或最终目的地。Smtpd有可能收到两种邮件，第一种是外界寄给Postfix所控制的网域的邮件(Postfix系统本身是邮件的终点站或网关)，另一种是要寄到其他网域的邮件。
　　Smtpd一定会收下第一种邮件(如果收件人存在的话)，至于第二种邮件(目的地在其他网域)，就要看传邮件过来的客户端是否有资格。网络收下要寄到其他网域的邮件，并代为寄送到目的地的动作称为转发(relay)。在两种情况下，Postfix愿意提供转发服务：一是客户端符合配置文件限定的资格，二是收信网域是relay_domain参数所列出的网域之一。

通知函

当用户的邮件被延时时，或是根本无法递送到目的地时，Postfix使用Defer或Bounce Daemon产生一封新的通知函。这封通知函会被交给Cleanup Daemon，由它进行例行的清理程序之后再排入收件队列，由Queue Manager接手处理。

转寄邮件

有时候，邮件在委托给MDA之后，MDA会发现该邮件其实应该寄送到另一个系统的另一个账户。比如说，当MDA在用户个人的forward文件发现了另一个地址时，就会发现这种情况。照理说，MDA可以直接使用Smtp Client(即Smtp Daemon)送出邮件。不过，由于同一封信可能有多位收件人，为了照顾到每一位收件人，同时也为了在邮件日志上留下完整记录，MDA应该依提交新邮件的方式，让邮件重新回到Postfix系统，由Postfix按照“来自本机的邮件”的程序来处理。

Postfix的队列管理器

邮件本身的处理工作主要是由队列管理器(Queue Manager)负责，每一个能收到邮件的Postfix组件，都有一个共同的目的地－－队列管理器。邮件进入队列之前的关卡是Cleanup Daemon，因为只有经过清理的邮件，才有资格进入队列。Cleanup将邮件排入队列后，会通知Queue Manager去处理新邮件。每当Queue Manager察觉收信队列有新信到达时，就会使用Trivial-Rewrite来决定邮件路由信息，这些信息包括传输方法、下一站以及收件人地址。
　　Queue Manager总共维护四种队列：收件(Incoming)、活动(Active)、延迟(Deferred)、故障(Corrupt)。新邮件通过Cleanup之后的第一站是“收件队列”。假设系统资源空闲。Queue Manager会将邮件移入“活动队列”，然后调用适当的MDA来投递邮件，而投递失败的邮件则会被移入“耽搁队列”。
　　如果邮件被耽搁太久，或是被判定无法送达，则Queue Manager还要负责协调Bounce与Defer Daemons来产生一份递送状态报告，并传回给系统管理员或送信者(或两者)。在Postfix的队列目录下(默认位置是/var/spool/postfix/)，除了上述四种邮件队列目录之外，还有bounce/与defer/目录。这些目录含有状态信息，解释特定邮件为何被耽搁或无法递送，Bounce与Defer Daemon就是利用这些目录下的状态信息来产生通知函。

投递操作

Postfix依据收件地址的类型，来判断是否要收下邮件以及如何进行投递操作。主要的地址类型有本地(Local)、虚拟别名(Virtual Alias)、虚拟邮件(Virtual Mailbox)以及转发(Relay)。如果收件地址不在这四种主要类型之中，则邮件会被交给Smtp Client，通过网络寄送出去(假设原信是来自有资格使用转发服务的客户端)；否则，Queue Manager便依据地址的类型，选择适当的MDA来投递邮件。
　　

本地邮件

　　如果收件人为Postfix本地系统的用户(在运行Postfix的那台服务器上有Shell账户的用户)，则他们的邮件会被交给Local MDA处理，凡是收件地址的网域名称与mydestination参数列出的任一网域名称相符，这类邮件都算是本地邮件，对于送到任何mydestination网域的任何有效账户的邮件，Local MDA会先检查收件人是否有个人的.forward文件，如果没有，则邮件会被存入用户的个人邮箱；否则，则依据.forward文件的内容来进行投递操作(或转寄到其他地方，或是交给外部程序处理)。
　　对于需要转寄到他处的邮件，将会被重新提交会Postfix，以便传送到新地址。如果传送过程发生了暂时性问题，MDA会通知Queue Manager，而邮件会被保存在延迟队列等待下次的递送机会；如果发生永久性问题，则要求Queue Manager将信息退给发信者。
　　

虚拟别名邮件

　　寄给虚拟别名地址的邮件，全部都需要转寄(Forward)到其真实地址，虚拟别名的网域名称列在virtual_alias_domains参数中，每一个虚拟网域都可以有自己的一组用户，不同的虚拟网域可以容许有同名的用户。用户与其真实地址之间对应关系，列在virtual_alias_maps参数所指定的查询表中。当Queue Manager发现邮件的收件地址的网域部分virtual_alias_domains所列出的网域之一，则会重新提交邮件，以便传到真实地址。
　　

虚拟邮箱邮件

　　虚拟邮箱的网域名称列在virtual_mailbox_domains参数中。每一个网域都可以有自己的用户群，而且有各自独立的命名空间，换言之，即不同的虚拟邮箱网域可以有同名的用户。用户与邮箱之间的对应关系，定义在virtual_mailbox_maps参数所指定的查询表中，虚拟邮箱与系统上的Shell账户之间没有关联性，虚拟邮箱邮件的投递操作由Virtual MDA负责运行。
　　

转发邮件

　　实际邮箱位于其他MTA控制管理的网域，但是Postfix愿意代收并转寄的邮件，称为转发邮件。这类网域的名称列在relay_domains参数中，其邮件由smtp MDA通过网络送到目标网域的MTA。当你假设邮件网关系统时，便可利用转发功能收下Internet寄到内部网域的邮件，并转寄到内部网络的邮件系统上。
　　

其他邮件

　　如果邮件的收件地址不属于前述四类，则一律交给Smtp以递送到正确地点，因为这类邮件必定是要送到系统本身之外的其他网域。先前在“来自网络的邮件”曾说过，并非所有客户端都有资格使用转发服务。一般而言，我们会将转发服务开放给与Postfix Server位于相同局域网络的其他主机，好让这些主机可通过Postfix Server寄信到Internet上的外界网域。
　　当Smtp MDA收到外地邮件时，它会依据收件地址来判断邮件应该送到哪个(或哪些)主机，然后依序连接到这些主机，直到有一部主机愿意收下邮件为止。如果投递过程发生暂时性问题，Smtp会通知Queue Manager将邮件放在延迟队列，等待下次传送的机会；如果发生永久性错误，则要求Queue Manager退信给发信者。
　　当因暂时故障而不能连接的远程主机恢复连接时，Postfix会先采取试探性动作，以免过多的延迟邮件使对方瘫痪。一开始，Smtp只会搭建有限度的几条连接通道(数量可通过配置文件调整)到收件方，在发现对方能够成功收下邮件之后，才会慢慢提升连接通道的数量(到一个可设定的上限)；相反的，如果Smtp发现接送方有任何麻烦，它会立刻撤销连接。
　　

其他传送代理程序

　　Postfix还提供了其他MDA，可用来处理特殊的地址或目的地。这些MDA需要在master.cf配置文件中设定妥当之后才有作用。此外，你还必须在class_transport或transport_maps参数指定的传送表(transport table)中设定如何启动它们。最常用的两个特殊MDA是LMTP与PIPE。
　　

LMTP投递

　　LMTP是一种很类似SMTP的协议，但只能用于同一网络上的邮件系统之间，或是同一主机上的不同邮件程序之间。举例来说，如果需要将邮件送到不同的软件包–该软件可能与Postfix在同一台机器上，也可能位于局域网络上的另一台主机，则Queue Manager可以调用LMTP MDA将邮件传送给该软件包。
　　实际上，LMTP最常被用来将邮件交给特殊的POP/IMAP Server，以便使用特殊邮箱格式来存储邮件。在这种情况下，由于只要POP/IMAP SERVER知道特殊邮件格式，所以只好使用标准的LMTP来交付邮件。如果LMTP投递过程中出了任何问题，LMTP MDA会通知Queue Manager将邮件放在延迟队列，等待下次传送的机会。

PIPE投递

　　Postfix提供了Pipe Daemon将邮件传送给外部程序。实际上，Pipe经常被用来将邮件传给外部的内容过滤程序(例如：病毒扫描系统、垃圾邮件分析程序)或其他通信媒介(例如：传真机)。同样，如Pipe无法顺利传出邮件，它会通知Queue Manager将邮件放在延迟队列，等待下次传送的机会。
　　实际追踪POSTFIX的邮件处理流程
　　让我们追踪一封典型邮件如何通过POSTFIX系统。处理流程是一封邮件从发信方到达目的地(信封地址所指的MTA)，然后又被转寄到最终的MTA(收件人实际取信处)。
　　例如：HELENE的账户位于一台运行POSTFIX的服务器，她使用自己习惯的MUA编写邮件，然后调用POSTFIX的sendmail命令送出邮件。POSTFIX的sendmail程序从HELENE的MUA软件中取下邮件，然后放在队列的MAILDROP/子目录下。
　　接着，Pickup Daemon从该目录取出邮件，交给CLEANUP DAEMON运行必要的清理程序，如果HELENE的MUA软件没提供地址from：，或是该地址没使用完整的主机名称，则Cleanup会自动补齐不足的信息以确保邮件格式符合标准。完成清理程序之后，Cleanup将邮件存入收件队列，并通知Queue Manager，使其知道有一封新信正在等待投递。
　　如果Queue Manager已经准备好处理新邮件，它会将邮件搬移到活动队列。由于HELENE的信是要送到其他网域系统的用户，所以Queue Manager使用SMTP MDA来投递该邮件。SMTP使用DNS查出哪些邮件服务器愿意收下目的地网域的邮件，然后从中挑出最优先的邮件交换主机(MX HOST)并与该主机接洽，以SMTP协议送出HELENE写的邮件。
　　当目的网域的服务器上的MTA SMTPD收下HELENE的SMTP MDA送来的邮件。当smtpd确认它应该收下该邮件之后，它会将邮件交给Cleanup Daemon进行检查，然后存入收件队列。
　　Queue Manager将邮件搬移到活动队列，检查收件人地址，然后使用LOCAL MDA来进行投递操作。接着，LOCAL发现收件地址其实是一个别名，其真实地址位于另一个网域，所以将邮件与新地址信息传给CLEANUP DAEMON，回到POSTFIX的队列系统。
　　当CLEANUP与Queue Manager处理邮件时，依靠TRIVIAL-REWRITE将地址转换成标准格式，并判断传送方式以及递送流程到下一站。
　　当Queue Manager发现新邮件应该送到另一个网络，则会调用SMTP来进行投递操作，而SMTP会先向DNS查出哪些邮件服务器可能接收该网域的邮件。该网域的MTA收下这封邮件后，最后会将邮件交给LOCAL MDA，由它将邮件存入该系统的邮箱。
　　到这个时候，Postfix就完成了它的工作。这时收件人现可以用他自己的MUA来阅读邮件，至于这个MUA是直接从邮箱取信，还是使用POP或IMAP之类的协议通过网络下载邮件，都已经不是Postfix所能控制的了。
　　我们的例子只假设了最理想的简单状态，实际的传送程序可能会遇到一些意外状况，诸如网络临时断线、远程主机死机、邮箱空间不足。发生意外时，MDA必须通知Queue Manager，将邮件暂时放回延迟队列，等待一段时间之后再重新投递。
　　除了临时意外回影响投递过程，还有一些情况也会影响，比方说，收件人并非实际的系统账户，而是IMAP邮件系统的一个账户，在这种情况下，Queue Mananger可能要通过LMTP MDA来投递邮件，或是通过PIPE MDA将邮件送到一个事先确定的外部程序。
　　Postfix还要面对各式各样的变化与潜在的复杂性，幸运的，它本身的结构设计足够稳定，几乎能够应付所有可想像到的情况，也有足够的可塑性来适应未来的可能变化。
　　

队列种类

　　收件：Incoming　活动：Active　延迟：Deferred　故障：Corrupt　保留：Hold
　　

组件结构

　　Master组件：主导邮件处理流程、其他组件的总管。配置文件：main.cf和master.cf。
　　Qmgr组件：队列管理器。各个postfix组件之间的合作依靠队列交换邮件。
　　Sendmail组件：服务器本机发送邮件。
　　Postdrop组件：将邮件存入postfix队列目录下的maildrop/子目录。
　　Pickup组件：监视maildrop/子目录，读出新邮件，交给cleanup组件。
　　Cleanup组件：补足遗漏的标头字段。
　　Trivial-Rewrite组件：地址处理，改成标准格式。决定路由信息，包括传输方法、下一站以及收件人地址。
　　Smtpd组件：接收来自网络的邮件，交给cleanup组件处理。
　　Defer组件：邮件被延时时产生通知函。
　　Bounce组件：邮件无法送达目的地时产生通知函。
　　Dns组件：查找符合条件的邮件服务器。
　

Postfix命令行工具

　　postalias：创建或查询别名数据库。
　　postcat：显示出队列文件的内容，让管理员可观察滞留在队列里的邮件内容。
　　postconf：显示或改变postfix参数，可一次显示一个参数，或是显示所有参数。
　　postdrop：将邮件放回到maildrop目录，由postfix重新进行投递操作。
　　postfix：启动或停止postfix系统，或重新读取配置文件。也可以用于其他维护工作，包括检查系统配置，以及清空队列。
　　postkick：对特定postfix服务发出请求。此工具的作用，主要是给shell scripts提供一个能够与postfix沟通服务的管道。
　　postlock：锁定特定文件，确保能够独占访问。此工具的作用，主要是让shell scripts能使用兼容于postfix的锁定方式。
　　postlog：将特定的信息记录到系统日志文件中。这是支持shell scripts工具，使其能以类似于postfix的样式来记录信息到日志文件。
　　postmap：创建查询表的DB数据库或查询查询表内容。postfix有许多配置信息都是记录在postmap所建的查询表数据库中。
　　postqueue：让一般的用户能够有限度地访问postfix队列。可能改变队列的访问方式需要有管理员特权才能进行，而这方面的访问能力由postsuper命令提供。
　　postsuper：供管理员访问postfix队列。管理员可删除邮件、扣留邮件(搬到hold队列)、取回邮件(将邮件从hold队列搬回active队列)，必要时，还可以修复队列目录结构。
转自：http://www.mike.org.cn/articles/postfix-works-briefly/