【CSDN报道】2013年8月8日，美国加密邮件服务网站Lavabit的所有者和经营者Ladar Levison，在官方网站中发表声明称：“我被迫要做出一个艰难的决定：是成为对美国人民犯罪的同谋，还是关闭凝聚了我10年心血的Lavabit。经过慎重考虑，我决定暂停Lavabit的服务。” Lavabit也是“棱镜”情报监控项目曝光者爱德华·斯诺登（Edward Snowden）一直使用的加密电邮服务。

虽然Lavabit关闭了，不过Lavabit的架构也称得上是一个经典之作，文中的信息基本上都出自于2009年，但是仍然是一篇好博文，其中一些技术或者信息已经过时了，但是其中的一些思想仍值得大家学习。HighScalability的记者Todd Hoff 分享了这个可扩展的邮件系统架构，CSDN摘译如下：

Lavabit邮件系统

Lavabit是一个中等规模的电子邮件服务提供商，构建这个系统是为了抗衡其他大型的免费邮箱提供商，侧重服务于那些隐私意识比较强和精通技术的用户。Lavabit是第一批提供免费电子邮件服务的公司，开始是使用POP协议，再后来使用的就是IMAP协议。

Lavabit的系统架构

SMTP，POP和IMAP连接

Lavabit使用了一个两层的架构，包括一个应用层（运行自定义的邮件守护程序）和一个支持层（由NFS和MySQL服务器组成）。一个基于硬件的负载均衡器（Alteon AD4）将传入的SMTP、POP和IMAP连接分配到8个应用程序服务器（戴尔1650，拥有4GB的RAM）。

应用程序服务器被用于处理大量的进程负载，守护进程本身是一个使用C语言编写的单进程、多线程应用程序，每个守护进程配置512个线程用以处理传入的连接。另外8个线程负责异步pull广告（来自广告合作伙伴的HTTP API），并执行维护功能。其中维护功能包括更新内存表、过期会话以及日志文件，同时保持ClamAV（主要应用于邮件服务器，采用多线程后台操作，可以自动升级病毒库）的更新。

从架构的角度来看，每个传入的连接都能得到一个独有的线程，这就可以使用Blocking IO的模式来进行控制。目前，Lavabit依赖于Linux内核来均分这些处理器。

Lavabit称自己的邮件守护进程为“lavad”，它可以流畅地处理SMTP、POP和IMAP连接。守护进程还负责应用所有的业务逻辑，并且连接不同的开源库。

当通过SMTP协议来接受外部消息时，守护程序将进行下列检查：

•收件人是否有效
•传入IP是否被列入RBL
•返回的路径是否被验证使用了SPF（libspf2）
•账户是否有大小或者速率限制
•是否针对灰名单
•是否含有病毒（libclamav）
•是否是合法的域密钥签名（libdomainkeys）
•该消息是否看起来像垃圾邮件，根据统计令牌数据（libdspam）
•是否使用任何过滤器和正则表达式行排序或删除邮件
•取决用户的参数及计划，查看是否有特定的检查。例如，垃圾邮件过滤器仅限于付费用户

根据不同的检查的结果，用户可以选择标记消息，或者拒绝收取，甚至在某些情况下静静地删除它。如果消息需要被退回，退回邮件只会在这两种情况下发送：返回路径可以验证使用SPF；如果发件人使用了域密钥进行验证，并且发件人匹配该返回路径。

最后一个步骤，消息使用使用ECC（如果适用）进行加密，使用LZO进行压缩，然后存储在NFS服务器上。

对于POP连接，这个过程就相对简单多了。用户首先进行认证，然后请求消息，守护进程加载此消息，检查哈希表，以确保日期还没有被损坏，解压缩数据，然后在发送到客户端之前对其进行解密（如果适用）。

因为这需要纯文本密码来解密用户的私人密钥，所以Lavabit并不支持安全密码的身份验证，转而支持SSL（可以对一切进行加密，而不仅限于密码）。Lavabit处理SSL的加密是在应用层而不是在负载均衡器上，这是因为他们觉得应用层更容易扩展。

对于IMAP连接来说，守护进程也可以呈现文件夹中的信息，并且允许服务器端的消息搜索。当下，搜索通过读取磁盘上的所有信息实现；如果文件夹很大的话，这将严重影响性能。连接将共享信箱状态的集中副本，这也创造了锁争用问题。搜索肯定是一个需要改进的地方。

对于传出消息而言，该守护程序将通过数据库来验证用户的证书，并对该账户设置发送限制（防止滥用），并检查电子邮件地址是否与认证信息匹配（以防止欺骗），最后守护进程还要检查邮件是否包含病毒。当所有的检查都通过之后，该消息就会被清理，使用域密钥进行标记，然后通过内部网络转发到Postfix服务器，再将其转发到最终目的地。

守护进程使用池来共享所有的东西，包括MySQL连接、ClamAV实例、cURL实例（pull广告）、Memcached实例、libspf2实例等等，来保持简单的部署。Lavabit编译了所有依赖的开源库，并把它们进行统一的归档，然后在运行时才进行动态的加载。不过他们并没有将这些库直接链接到应用程序之上，如果这样的话，就需要在GPL的情况下，释放守护进程。Lavabit不依赖于动态链接，因为他们不希望在未知的情况下，任何关键库会被操作系统控制，进行自动的更新。

HTTP的连接

就像入站邮件连接一样，HTTP连接通过负载均衡器被分配在两个服务器之间，Apache被用于处理请求。虽然大部分的网站是静态的XHTML文件，但是Lavabit的注册引擎是用C编写的，并且所有的C应用程序都依赖于Apache的CGI接口。

门户网站是使用Perl语言编写的，而webmail系统是基于一个流行的开源客户端（PHP）。目前webmail客户端连接到邮件系统时候通过IMAP协议，每个Web服务器都会得到一个专用的IMAP服务器。

存在的问题

虽然设置一个能够可靠地为几千个用户进行服务的邮件系统并非难事，但是超越单一的服务器，扩展同一个邮件系统绝对是非常之难。这是因为大多数电子邮件服务器最初都是被设计成在单一的服务器之上进行使用。如果想在超越单一服务器的情况下移植这些相同的系统，通常需要使用一个数据库和/或NFS服务器，然后把所有不同节点之间的数据进行同步。当然建立大型数据库和NFS实例是可能的，但是价格同样非常昂贵，并且效率也不高。

如果想避免单一的数据库或NFS服务器的问题，也可以这样做，不过加入了很多复杂性。例如，如果想实现一个非常大的Cyrus系统，典型解决方案就是使用LDAP进行身份验证，然后使用IMAP/POP的反向代理以中断传入连接，并把它们转发到特定的Cyrus服务器之上。不过管理这样一个系统，关键部分很容易出现问题。（完整的设计，请参阅 Building a Scalable High-Availability E-Mail System with Active Directory and More  ）

按这种方式设计的系统，问题在于大量的关键性服务。如果Cyrus服务器关闭，则托管在该系统上的所有用户都会处于脱机状态，虽然可以减轻这种风险，比如提供一个切换系统，定期的进行备份和同步，或者用SAN，但这些选项都很低效，而且费用昂贵。

实现大型的邮件系统很难，但是实现小型的邮件系统相对容易得多，正因为如此，每年都会有成百上千个免费电子邮件公司开始创业，然后慢慢走向消亡。当然如果系统非常受欢迎，公司却没有简单的方法来扩展规模，所以也只能被迫停止免费帐户，或者不得不关闭系统。只有少数公司有资金和技术资源，重新构建一个系统来以支持庞大的用户群。这也是为什么Lavabit效法大型的供应商，实现一个完全自定义的平台，这也是唯一的办法。Lavabit可以支持10万以上的用户，并且提供一个足够低的成本基础，使企业有利可图。

其实保证所有大型系统管理和成本效益的关键就是要保持简单，系统的关键故障点越少，系统的运行越稳定。（文/王鹏，审校/仲浩）

阅读更多：Lavabit Architecture - Creating A Scalable Email Service

良心企业Lavabit、Slient Mail相继关闭，美国云安全已死？

                                      —转自CSDN

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)