HEC Montréal：大规模邮件系统部署
在过去几年中，电子邮件已发展成为最重要的通信媒介之一。自然而然地，电子邮件基础设施必须快速、安全且可靠。理想情况下，它们还应该能够轻松有效地与反垃圾邮件（UBE）解决方案集成。
HEC Montréal 是加拿大第一所管理学院，成立于 1907 年。每年有超过 11,000 名学生和 220 名教授使用 HEC 的电子邮件系统，校友毕业后也保留其电子邮件帐户。不幸的是，专有的电子邮件系统没有发展，并且随着负载开始增加，基础设施再也无法满足需求。
HEC Montréal 之前的邮件基础设施基于四台运行 Netscape Messaging Server 4.15 的 IBM AIX 服务器。这些服务器中的每一台都为一部分用户提供所有服务（IMAP、POP3、SMTP 和 Webmail 访问）。该系统根本无法扩展以满足当前的邮件需求。根据 HEC Montréal 的高级网络分析师 Eddy Béliveau 的说法
我们发现自己使用的邮件服务器软件在过去两年中没有升级，因为 AIX 平台不再受拥有邮件服务器软件的 Sun/iPlanet/Netscape 支持。在过去的 12 个月中，由于 UBE 和试图复制自身的病毒的存在，我们的电子邮件流量 регулярно 增加。我们遇到了超过 100 个并发 SMTP 连接的峰值，这对我们的服务器来说太多了；所有服务器上的典型负载平均值都超过 50。在我们的旧 133MHz 服务器上，我们无法执行任何防病毒或反 UBE 应用程序，甚至无法执行简单的 RBL 过滤策略。因此，我们不得不重新检查电子邮件系统的硬件和软件架构，但[无法]找到时间安装替代方案。我们就像一只追逐自己尾巴的狗，试图稳定局面。
HEC Montréal 联系了 Inverse, Inc.，以帮助他们更换邮件基础设施并部署更好的替代方案。
图 1. HEC Montréal 是一个棘手的电子邮件问题：35,500 名用户和每周超过 600,000 封垃圾邮件。
提议的解决方案受以下因素驱动
成本：HEC Montréal 无法负担 35,500 名用户的按用户许可费。
易于维护：基础设施必须易于管理。帐户的创建和销毁应自动化，更新应易于应用，并且基础设施应让 HEC Montréal 利用他们拥有的专业知识。
安全性：解决方案的组件应具有经过验证的安全记录。
稳健性：组件应成熟，并且应已在生产环境中使用了数月。此外，开发应积极进行，以加速错误修复、功能增强和安全更新。
可扩展性：该解决方案必须在未来数月内满足其用途，因为用户数量每年增长 2,000–3,000 人。其架构还应允许添加额外的服务器以分配负载或提供更多冗余。
当我们第一次被联系时，HEC Montréal 倾向于使用运行 Novell NetMail 3.1 的基于 Linux 的解决方案。由于我们在免费替代方案方面拥有丰富的经验，我们决定将我们想到的解决方案与 Novell 的产品进行比较。
也就是说，我们使用 Red Hat Linux 9 构建了两个相同的测试环境，并在其中一个上安装了 NetMail 3.1，在另一个上安装了我们提议的解决方案。接下来，我们进行了一系列压力测试，以衡量两种解决方案的稳定性和性能。测试使用两个基准测试实用程序 postal 和 tm 进行。结果表明，虽然 NetMail 在 POP3 操作方面最快，但在 IMAP 和 SMTP 测试中证明是最慢的。当 IMAP 请求使服务器过载时，它也存在许多稳定性问题。
结合我们的经验，我们提出了一个几乎完全基于开源组件的解决方案。我们从标准的 Red Hat Linux 9 发行版开始，使用了 Silicon Graphics, Inc. 的 XFS 内核软件包。我们包含了 Cyrus IMAP 和 Cyrus SASL，其中包括 IMAP、LMTP 和 POP3 守护程序，以及身份验证库和使用 Sieve 的重定向/休假脚本支持。接下来，添加了 Postfix、AMaViS、SpamAssassin、Vipul's Razor 和 NAI VirusScan，以构建完整的 SMTP 服务器解决方案，并增强了限制 UBE 和病毒传递的工具。Apache、PHP4、IMAP Proxy 和 SquirrelMail 提供了完整的 Webmail 解决方案。添加了 OpenLDAP 以存储有关用户帐户的所有信息（电子邮件地址和别名、SquirrelMail 首选项等），以及 HEC Montréal 的其他特定属性。最后，我们安装了 Linux HA Heartbeat，该软件用于监控网络上某些节点的健康状况。
新的基础设施运行在 11 台 IBM eServer xSeries x305 和 x335 服务器上。两台 x335 通过光纤通道连接到 IBM FAST 700 存储区域网络 (SAN)，邮件存储位于其中。XFS 文件系统用于邮件存储，以最大程度地提高文件访问操作。图 2 描述了该架构。
图 2. 提议的基础设施的架构
使用了四台运行 Postfix 的 STMP 服务器：其中两台是 HEC Montréal 域的邮件交换器 (MX)，另外两台用于满足内部邮件需求。这些服务器还使用 AMaViS、SpamAssassin、Vipul's Razor 和 Network Associates' VirusScan 来限制 UBE 和病毒的传递。此外，两台 Cyrus IMAP 服务器使用串行和以太网电缆连接，以实现高可用性。任何时候只有一个 Cyrus IMAP 服务器处于活动状态；它服务于所有 POP3 和 IMAP 连接，将邮件存储在 SAN 上（使用 LMTP 协议从四台 Postfix 服务器接收），并处理 Sieve 脚本。
两台 Webmail 服务器运行 Apache、PHP4、SquirrelMail 和 IMAP Proxy。后者用于缓存 SquirrelMail 和 Cyrus IMAP 服务器之间的 IMAP 连接，以最大程度地减少邮件存储上的负载（身份验证和进程分叉）。最后，另一台服务器仅用于测试目的。也就是说，对基础设施的任何修改都必须通过此服务器，该服务器配置为运行每个组件，然后才能应用于生产环境。
关于 UBE 过滤，我们在多个级别检查邮件，以确保我们尽可能多地阻止邮件。我们的检查包括仔细选择的实时黑洞列表 (RBL)；使用 SecuritySage, Inc. 的最新地图进行标头和 MIME 标头检查；以及从 AMaViS 发起的基于内容的过滤，使用 SpamAssassin、Vipul's Razor 进行 UBE 分析，以及 VirusScan 进行病毒扫描。
事实证明，该解决方案非常有效，并且产生的误报很少。该系统还在构建时考虑了负载均衡和故障转移。SMTP 和 Webmail 服务器以循环方式使用，有效地在它们之间分配负载。
主 Cyrus 服务器有一个相同的备份服务器，以防发生故障。后者连接到主 Cyrus 服务器，并使用 Heartbeat 监控服务器的可用性。如果发生故障（硬件问题、操作系统崩溃等），辅助 Cyrus 服务器将接管所有服务。Heartbeat 自动挂载邮件存储（位于 SAN 上），激活网络别名并启动所有 Cyrus 服务。这提供了一个热切换，可以最大程度地缩短停机时间；有时甚至不明显。
最后，LDAP 系统提供了一个主节点以及一个使用 slurpd 复制前者的从节点。所有服务都配置为在主节点发生故障时自动故障转移到从节点。某些服务也配置为使用从节点作为主节点，以便在两台服务器之间分配 LDAP 负载；它们故障转移到主节点。
在将新基础设施的 11 台服务器部署到位后，剩下的挑战之一是将所有用户从旧基础设施迁移到新基础设施。大约 35,500 名用户、82,500 个邮箱和数十万封邮件（35GB 邮件）必须迁移。此外，重定向脚本和休假消息也必须转换，并且以前的 Webmail 系统中的首选项等信息也必须保持不变。为了做到这一点，我们创建了一组 Perl 脚本来处理整个迁移，使其对用户来说是无缝的
LDAP 初始化：使用以前的 LDAP 服务器（基于 Netscape iPlanet）中的值填充新的 LDAP 服务器（基于 OpenLDAP）。包含的属性是电子邮件地址和别名、特殊文件夹和 Webmail 的签名首选项。
创建用户：创建即将迁移的所有用户帐户。
加载 Sieve：通过读取以前的 LDAP 服务器中的属性来创建 Sieve 脚本并将其上传到邮件存储。Sieve 脚本用于自动重定向和休假消息。
复制邮箱：复制正在迁移的用户的所有邮箱。所有邮件标志都保持不变。此脚本大量使用了 IMAP 协议。此脚本还更新了两个 LDAP 服务器上的 mailHost 属性，以便邮件被路由到正确的目的地邮箱。
更新邮箱：在迁移后的第二天早上运行，以移动用户邮箱中剩余的（如果有）邮件。在用户的 mailHost 属性更改之前，邮件可能已卡在 SMTP 服务器的队列中。
为了最大程度地减少用户的服务中断，我们在课程结束后，在一天结束时按列出的顺序运行脚本。导入过程中很少有邮件被拒绝；那些被拒绝的邮件只是被源 SMTP 服务器重试。总共需要四个晚上才能迁移所有信息。运行脚本花费了四到七个小时，具体取决于每个源服务器上的用户数量和执行速度，这主要受到旧 AIX 服务器性能的限制。
迁移后，我们广泛监控所有服务，以发现任何问题。正如预期的那样，我们没有遇到太多问题。我们主要调整了 Cyrus 进程的最小预派生数以及它们各自的最大子进程数。我们还针对默认进程限制和 AMaViS 的预派生数调整了 SMTP 服务器。我们还在迁移期间使用了临时 LDAP 查询，因此我们必须在迁移完成后将它们替换为优化的查询。
在典型的一天中，HEC Montréal 收到超过 125,000 封电子邮件，其中 60% 到 80% 的流量由 UBE 组成。内部 SMTP 服务器还管理着用户、通讯组列表或其他系统发送的数千封邮件。主 Cyrus 服务器每天发起约 300,000 个 POP3 连接（来自 5,500 个不同的用户）和 60,000 个 IMAP 连接（来自 5,000 个不同的用户）。经常遇到 225 个并发 IMAP 连接和 50 个并发 POP3 连接的峰值。
如前所述，已实施的反 UBE 策略已被证明是有效的。在迁移后的第一周，两台邮件交换器阻止了超过 600,000 封未经请求的批量电子邮件。一周后，垃圾邮件发送者不再那么激进，系统阻止了超过 25 万封邮件。最有效的策略是 RBL 检查，其次是内容过滤检查（使用 SpamAssassin 和 Vipul's Razor），最后是标头和 MIME 标头检查。
为了提取这些统计数据，我们安装了 Spamity，它解析来自四台 Postfix 服务器的邮件日志，并更新测试服务器上运行的 PostgreSQL 数据库。此后，用户或管理员可以使用简单的 Web 浏览器检查被反 UBE 策略阻止的邮件。用户还可以搜索特定的电子邮件地址或域名，并按反 UBE 策略过滤结果。
正如您在本文中看到的那样，从专有解决方案迁移到开源解决方案是一项挑战。根据 HEC Montréal 信息系统主管 Emmanuel Vigne 的说法
关键的业务优势是巨大的，因为我们几乎消除了 UBE，并大大增强了邮件基础设施的架构。我们从一个所有服务都由四台服务器提供的架构，转变为一个由多台服务器提供服务的架构。这使我们能够最大程度地减少任何潜在的停机时间，并随着用户数量的增长而扩展。万一发生故障，只会影响一项特定服务，这与以前的情况相反，以前如果单台服务器发生故障，数千名用户将无法再使用电子邮件服务。
部署这个新的基础设施使我们能够为开源社区做出贡献，方法是开发一组补丁来纠正我们安装的大多数组件的错误和/或添加功能。
与任何其他系统一样，这个系统也会随着时间的推移而发展。有趣的反 UBE 技术正在兴起，例如发件人策略框架 (SPF) [参见第 50 页] 和 Spamhaus Exploits Block List (XBL)，并且 Cyrus 的新稳定版本已发布，支持 NNTP 和邮箱注释。此外，Postfix 2.1 进展顺利，其新的 anvil 服务器应提供出色的连接/速率控制。
最后，在撰写本文时，正在为 SAN 部署镜像解决方案。这应该提供存储冗余，并消除当前基础设施中唯一的潜在单点故障。
本文的资源： /article/7456。
Ludovic Marcotte (ludovic@inverse.ca) 拥有蒙特利尔大学计算机科学学士学位。他目前是 Inverse, Inc. 的软件架构师，Inverse, Inc. 是一家位于蒙特利尔市中心的 IT 咨询公司。
