Technical Blog Post
Abstract
IBM i 平台下MTA反垃圾邮件引擎的设计
Body
IBM i 平台下MTA反垃圾邮件引擎的设计 引言： 随着科技的发展，电子邮件越来越广泛的被应用到人们的生活当中，电子邮件地址已经和个人手机号码一样，成为人们在生活中两个必不可少的联系方式。尤其是随着3G网络与智能手机在全世界各国的普及，电子邮件的普及程度和应用率将会达到一个前所未有的高度。这就给反垃圾邮件技术提出了一个更高的要求。根据作者调查，每个在互联网络公开的电子邮件地址（可以通过搜素引擎搜到的地址）每天收到的垃圾邮件达到上百封。如果服务端的反垃圾邮件技术不过关，这将给终端用户，尤其是3G终端用户带来极大的麻烦——浪费数据流量和消耗手机软硬件资源（内存、存储卡……）。IBM i 作为IBM POWER系统上运行的重要操作系统被广泛应用于金融业，零售业等多个行业，电子邮件是IBM i平台上的重要应用之一，下面我们就来讨论一下如何在IBM i平台下实现反垃圾邮件引擎的设计。 反垃圾邮件的原理：
反垃圾邮件技术包括两个方面：来源检测和内容检测。如果要讨论这两方面的检测，则不能不提电子邮件系统的一个重要组成部分MTA(Mail Transport Agent)。MTA的本质则是SMTP相关协议的实现。下面我们就以SMTP协议的工作流程和关键消息字段来阐述反垃圾邮件引擎在整个邮件投递传输的六个检测关键点。检测点的检测内容为信件来源检测或信件内容检测。如下图所示:
一、接受并检测连接：
众所周知，任何C/S架构的系统，工作过程中所做的第一件事就是建立套接字(socket)连接。当邮件服务器接受邮件客户端的网络连接之后，立即通过操作系统提供的套接字API，如inet_ntoa，获取客户端的IP地址。然后根据后台提供的一个白名单(allowlist)，灰名单(Graylist)和黑名单(blocklist)来决定此客户端的信件处理方式。白名单无条件接收转发，无需任何来源和内容检测。灰名单对来源和内容进行检测，并根据检测结果的统计信息决定是否将此IP加入到黑名单，黑名单则立即断开连接。不在黑、灰、白名单的则对来源和内容一起检测，需要时记录剩余的非垃圾信用。
其中鉴于白名单的特殊性，一般其内容属于手工加入，其内容则是内部邮局的各个MTA的IP（极少数MTA设置为允许为其他MTA做中继转发）。灰名单属于程序自动维护，一般设计为未知IP地址通过来源检测和内容检测后的所有信件总数和垃圾邮件数，如果总信件超过一定数目后垃圾邮件达到一定的百分比（譬如十万封统计后，垃圾邮件占98%，或者一千封邮件统计垃圾邮件为100%）则加入到黑名单 。黑名单的维护则属于手动和自动相结合的方式。这三个名单，内容包含了IP地址，信件总数，已检测到的垃圾邮件数和记录过期时间。对于名单的格式内容，根据软件自身需要，可以自定义格式也可以使用XML格式——便于使用第三方库来操作。
二、客户主机名检测：
HELO和EHLO分别为SMTP的两个用于握手的协议字段。均为客户端与服务器建立连接后，客户端所发送的第一个协议消息。协议消息格式为：
HELO <主机名><CRLF>
EHLO <主机名><CRLF>
其中主机名为用户终端主机名或者其他转发MTA的主机名。对于此主机名的检测，尤其是知名主机名的检测，可以过滤出大部分的符合此类型的伪装来源信件。譬如某垃圾信件发送源发送 “HELO d23av03.au.ibm.com”到本地邮件服务器后，通过此域名反查获取d23av03.au.ibm.com主机的IP，发现此IP和发送源的IP并不一致，应则高度怀疑判断此信件为垃圾信件，譬如设置此次会话的"垃圾疑似度“为90(最高为100)。不过要注意的是，本地用户终端发信和MTA转发邮件均会使用此消息字段，而对于本地终端用户，是不需要做主机名检测的，所以真正的检测并不是在收到此协议消息时检测，而是放在第四阶段时检测，此时只是记录了这个主机名，并不作出上述判断。
三、身份认证：
AUTH消息属于SMTP的用户认证消息字段。它用于邮件服务器验证本地终端用户。如果会话不是和终端用户而是和其他MTA之间的，这个消息并不会出现。如果收到了AUTH协议字段并通过了认证，我们只是标志此会话是由本地用户终端发起，等待第四步去检测其提交的发信地址是否合法——防止冒用他人邮箱。
四、获取并检测发信地址：
MAIL 属于SMTP的标志发送者协议消息。它描述了当前会话的电子邮件的具体邮箱来源。它的消息结构是:
MAIL FROM: <源电子邮箱地址>
在检测此阶段信息的合法性之前，根据第二阶段（HELO/EHLO阶段）的描述，我们要首先根据是否存在第三阶段（AUTH阶段）来判断——连接的客户端是用户终端还是其他MTA，采取不同的策略：对于MTA，进行主机名反查IP操作；对于用户终端，则省略反查操作。
接下来的操作是在会话中记录MAIL FROM协议消息的具体邮箱来源内容。等待第六阶段时和发送目的邮箱地址一起验证。
五、获取并检测收信地址：
RCPT 属于SMTP的协议消息。它描述了当前会话的邮件的目的地址。同时一个SMTP会话可以有多个RCPT TO协议消息，这意味着可以发给多个收件人。本协议消息的结构为:
RCPT TO: <目的电子邮箱地址>
此阶段仍为只在本会话中保存目的邮件地址的列表信息，等待在第六阶段和源邮箱地址进行一起验证，而不进行其他验证操作。
六、接收并检测信件内容：
DATA属于SMTP的信件体传送协议消息。当服务端收到此消息的时候，意味着客户端开始准备向本地服务端发送信件体。在此阶段的主要任务就是对邮件进行内容检测。
根据第四阶段和第五阶段的描述，在内容检测之前要对源邮件地址和目的邮件地址进行检测。防止在未认证模式，伪造本地地址发送邮件。
内容检测是整个邮件系统最为复杂的一部分。包括信件标题、正文和文本（可阅读）性质的附件的垃圾邮件关键字过滤检测，其他附件中的病毒检测，恶意脚本代码监测，防隐私泄漏检测等。通常绝大部分邮件都是MIME格式，邮件的标题、正文和附件均为经过编码后传输的，所以邮件的缓存和快速检测成为此部分设计的关键点。同时如果条件允许，通过系统自动学习、管理员手动维护和用户协助识别添加一个垃圾邮件特征库也是很有必要的。对于机器学习，贝叶斯算法是当前流行的垃圾邮件机器学习算法。
在IBM i 中的实现:
对于在Unix/Linux和Windows平台实现上述功能，它们使用的是动态连接库和系统钩子技术。对于IBM i，类似技术是Service PGM和Exit Program。
Service PGM从广义上来说，和Unix/Linux和Windows下的动态连接库差不多。它提供了对应的接口函数供其他程序调用。对于反垃圾邮件的Service PGM，可以设计针对上述每个监测点设计一个接口函数供邮件服务器调用。不过使用Service PGM设计有一个缺点，因为调用接口是在程序中固定写好的(Hard Code),所以不能支持多个引擎的叠加。而Exit Program就没有这个问题。Exit Program的每个Exit Point可以注册多个PGM，而且可以定义其调用顺序。这样就解决了i中反垃圾邮件引擎的叠加检测问题，支持了反垃圾邮件引擎的二次开发，而且Exit Program可以使用其他程序语言甚至脚本语言设计，更大大增强了引擎在客户环境多样化方面的适应性。
当然Exit Program也有其缺点，因为属于邮件系统外的一个PGM，工作任务间通信和启动开销都会比Service PGM大（Service PGM直接使用接口函数参数通信），而通常繁忙的邮件服务器，每秒要处理几千甚至上万封邮件，每封邮件都要进出Exit Point，这对于系统来说是一个不小的开销。当然，我们在设计Exit Progrom的时候尽量要考虑到这一点，并且根据需要通过适当的方法或工具来优化这个动作，让它影响最小化。
这两个实现方法到底选用哪个，具体可以针对不同的需要来实现和部署。
结束语：
虽然垃圾邮件投递系统也会寻找各种各样的系统漏洞去发送垃圾邮件，但是如果我们在设计引擎时不断完善在以上阶段的过滤检测算法，不断学习各种垃圾邮件的发送策略和特征标签库，再加上运行在POWER系统强大的处理能力，我们将能够提供一个完备高效的反垃圾邮件解决方案。
作者： Sheng BinUID
ibm11145860