Zimbra Antispam &Antivirus机制分析

Zimbra的投递逻辑是:

Postfix smtpd ->Postfix queue -> amavisd(内容过滤) -> Postfixsmtpd -> Postfix queue -> deliver

其中，amavisd是一个perl写的内容过滤系统，以smtp协议接收postfix的请求，然后调用SpamAssassin引擎以及clamav杀毒引擎进行处理。

amavisd处理之后如果发现是垃圾邮件或者病毒，有几个可能的处理方式:

a) 直接丢弃或者放到隔离区，这样就不用再经过一次Postfix了

b) 告诉前端的Postfix queue邮件需要拒收，由前端的Postfix负责退信

c) 通过SMTP协议重新把邮件放回Postfix队列

这个存在的问题是:

1. 前端没有控制机制，假如压力测试的时候以垃圾邮件为样本进行测试，然后把信头的From设置成一个连接不上的域名，就可以使得Postfix堆积大量的退信；

2. amavisd是调用SpamAssassin作为反垃圾引擎的，其处理能力比较慢，在测试机尝试用一个线程通过smtp协议直接绕开Postfix前端发信到amavisd，处理速度是每分钟6封左右；

 (处理的时候整个系统基本都在swap, 4G的物理内存都用光了, 4个Java进程，每个进程占用500M内存。另外有5个amavisd进程，每个占用150M内存)。

3. 分析过amavisd进程，其大概处理过程如下:

5288 1261636569.403345accept() # 接收一个连接

5288 1261636570.712165read(9, "MAIL FROM:<pqf@aaaaa.com>\r\n", 4096) = 27

1.   从socket读取邮件内容，并保存到/opt/zimbra/data/amavisd/tmp/amavis-20091221T172325-05288/目录下，这个目录包含一个parts目录，parts保存的是分解后的bodypart

2.   现在开始连接clamav杀毒, 杀毒还是很快的，半秒就返回结果了

5288 1261636572.371280 connect(12,

sa_family=AF_INET, sin_port=htons(3310),sin_addr=inet_addr("127.0.0.1")

, 16) = 0

5288 1261636572.371380 sendto(12, "CONTSCAN/opt/zimbra/data/amavis"..., 73, 0, NULL, 0) = 73

5288 1261636572.798982 recvfrom(12,"", 8192, 0,

sa_family=AF_INET, sin_port=htons(38000),sin_addr=inet_addr("127.0.0.1")
, 0)

= 0

3.   现在是SpamAssassin的RBL, URLBL检查

5288 1261636573.504577 bind(12,

sa_family=AF_INET, sin_port=htons(44663),sin_addr=inet_addr("0.0.0.0")
, 16) = 0
5288 1261636573.504625 connect(12,
sa_family=AF_INET, sin_port=htons(53),sin_addr=inet_addr("192.168.170.13"), 16) = 0
5288 1261636573.504699 getsockopt(12, SOL_SOCKET, SO_RCVBUF, 223338434560,4)= 0
5288 1261636573.557825 getpeername(12, sa_family=AF_INET, sin_port=htons(53),sin_addr=inet_addr("192.168.170.13")
, [226060277865
51312]) = 0

4.   现在开始做Bayes检查

5288 1261636573.977665open("/opt/zimbra/data/amavisd/.spamassassin/bayes_toks", O_RDONLY) =13

5.   做一点优化，Bayes检查过的记录下来，下次遇到同样内容的无需再次Bayes

5288 1261636573.990256open("/opt/zimbra/data/amavisd/.spamassassin/bayes_seen", O_RDONLY) =14

6.   现在开始连接Postfix后端的smtpd(10025端口)

5288 1261636576.386879 connect(12,
sa_family=AF_INET, sin_port=htons(10025),sin_addr=inet_addr("127.0.0.1")
, 16) = 0
5288 1261636576.414884 select(16, 12,[], 12,
35, 0) = 1 (in 12,left 35, 0
)
5288 1261636576.415113 read(12, "220 zmbtest.mailtech.cn ESMTPPo"..., 16384) = 39

7.   一次处理结束
5288 1261636577.432211 flock(8, LOCK_EX <unfinished ...>
5288 1261636577.673285 <... flock resumed> ) = 0
5288 1261636577.673408 select(8, 57, NULL, NULL, NULL <unfinished ...>

可以看出， amavisd处理邮件一共花费了8秒(邮件20k左右，是一封html邮件)，主要花时间在接收邮件之后分拆并保存到临时文件，以及Bayes检查这两部分。当然，这个测试有点极端的是测试的时候内存严重不足，swap的情况非常严重(但是系统已经有4G物理内存了,java进程是吃内存的大头)

Coremail的处理机制明显比Zimbra的优越

首先，Coremail在前端已经在客户段尝试投递邮件的时候，已经实时的检查了邮件，如果认为邮件是垃圾邮件的，立即就reject，而不是像Zimbra那样先进入队列。

其次，对于垃圾邮件，如果size小于100K的，Coremail甚至不会涉及IO操作就可以直接reject邮件（>100K的邮件将会使用队列文件临时保存，如果拒收的最后会删除邮件）。Zimbra是任何邮件都需要先进入队列的, 需要起码四五次IO(一次进入队列，几个分解邮件保存每个part一个文件的操作， 以及若干SpamAssassin做Bayes需要的IO读写操作, 然后还有一次退信涉及的几个IO）

就算是正常邮件，Coremail需要把邮件接收下来了，IO操作也远小于Zimbra. Coremail只需要写一次队列文件，然后由da负责投递，da投递的时候，如果需要杀毒的，会由da负责分拆邮件，每个附件保存成一个小文件，查毒后删除。而Zimbra, 则首先需要由Postfix的smtpd进程接收邮件并写一次队列文件，然后由qmgr进程把队列文件mv到qmgr目录，再把文件通过网络传给amavisd,amavisd在处理的时候会把邮件分成几个part, 每个part创建一个小文件，然后查毒。查毒完毕之后Zimbra会调用SpamAssassin进行Antispam检查，检查通过的，会再连接Postfix，把邮件放回队列，而这会导致一次额外的创建队列文件操作。也就是，正常情况下，Zimbra会比Coremail多了一次创建文件操作以及起码两次的mv文件操作。

除了IO之外，Zimbra的瓶颈还在于cpu的使用以及内存使用，因为使用了SpamAssassin, 这个perl开发的软件效率特别地下，另外amavisd也是用perl来分拆邮件body然后做antivirus检查的，strace分析发现这两个部分的耗时特别高。而内存使用高主要是因为有几个java进程，不过具体为什么java要这么多内存，就要William协助分析一下了

后来Tanyi在调研Zimbra的时候找到网上有人说过mailscanner + postfix的效率比amavisd + postfix的效率要高，到mailscanner的网站（http://www.mailscanner.info/cobalt.html）查看了一下，发现原理上确实如此。

mailscanner的原理是利用postfix的header_check机制，配置postfix, 把所有进入队列的邮件，先mv到hold目录， 然后由mailscanner直接扫描hold目录，通过的邮件再放回incoming, 不通过的邮件则reject。
这个机制确实省了一点IO(使用amavisd的话，通过检查的需要再发回队列，多了一次创建队列文件），但是按照之前的分析，整个过滤系统的瓶颈不在postfix本身，也不在amavisd，而是在amavisd所调用的SpamAssassin。而mailscanner本身也只是框架，没有Antispam能力，最终还是要依赖SpamAssassin进行antispam过滤
所以就算Zimbra使用了mailscanner, 效率也不会提高多少。另外，为了节省这些不是关键的IO，需要使用非标准的postfix接口（mailscanner会以postfix协议直接处理postfix的队列文件，postfix修改了文件结构的话，mailscanner需要跟着修改），导致维护成本的增高，也是得不偿失