译者/作者：chunzi
出处：中国Perl协会 FPC(Foundation of Perlchina)
原名：The Evolution of Perl Email Handling
作者：Simon Cozens
原文：http://www.perl.com/pub/a/2004/06/10/email.html
发表：June 10, 2004
请保护作者的著作权,维护作者劳动的结晶。
每天我都要花费大量的时间在电子邮件相关的工作上，或者通过邮件来和其他工作伙伴联系，或者饶有兴致地分析，索引，重新组织以及挖掘邮件内容。很自然的，Perl 协助我做这些事情。 在 CPAN 上有很多现成的模块可以用来处理电子邮件，我们将介绍其中几个主要的。同时我们也将关注由我和 Richard Clamp，Simon Wistow 以及其他伙伴所致力的 Perl 电子邮件项目（Perl Email Project），该项目的目标是提供一系列简单的，有效的，精准的邮件处理模块。
邮件消息的处理我们从一些比较简单的，用来描绘一封单独邮件，提供对邮件头和邮件体的访问，甚至修改它们的信息的那些模块开始介绍。 所有的这些模块的曾祖父都是 Mail::Internet ，由 Graham Barr 创建，目前 Mark Overmeer 在维护。该模块提供了通过数组（元素为字符串行）或者文件句柄来读取信件内容的构造器，并通过它返回一个描述该信件的 Mail::Internet 对象。在下面的例子中，我们使用变量 $rfc2822 来表示字符串形式的邮件信息内容。 my $obj = Mail::Internet-new( [ split /\n/, $rfc2822 ] );
Mail::Internet 从信件中提取构造出一个邮件头对象，并连带邮件体信息。邮件头对象的类为 Mail::Header 。你可以通过该对象获取或者设置邮件头的信息： my $subject = $obj-head-get("Subject"); $obj-head-replace("Subject", "New subject");
而读取或者编辑邮件体内容的操作，则可以使用 body 方法： my $old_body = $obj-body; $obj-body("Wasn't worth reading anyway.");
到现在为止我还没有提到过任何关于 MIME 的东西。对于简单的任务来说，Mail::Internet 确实非常方便，不过它并不完全支持对 MIME 的处理。谢天谢地，MIME::Entity 作为一个为 MIME 而考虑设计的 Mail::Internet 子类，允许你读取 MIME 消息的每一个独立的部分（part）： my $num_parts = $obj-parts; for (0..$num_parts) { my $part = $obj-parts($_); ... }
如果 Mail::Internet 和 MIME::Entity 都不适合你，你可以试试 Mark Overmeer 自己的 Mail::Message 模块，该模块是令人印象深刻的 Mail::Box 模块中的一部分。Mail::Message 是个极富特色的、功能全面的模块，但这些优点并不总意味着褒扬。 Mail::Message 对象通常都是在 Mail::Box 读取一个电子邮件文件夹的时候，在内部构建的。当然它也可以通过 read 方法来读取一封信件： $obj = Mail::Message-read($rfc2822);
就像 Mail::Internet 一样，邮件消息被分割为邮件头和邮件体，而与 Mail::Internet 不同的是，邮件体也是一个对象。我们如此读取邮件头： $obj-head-get("Subject");
或者，如果是 Subject 头信息以及其他常见的邮件头信息，可以如此读取： $obj-subject;
我找不到直接设置头信息的方法，所以最终可能需要这样做： $obj-head-delete($header); $obj-head-add($header, $_) for @data;
读取邮件体内容作为字符串形式表达也仅有一点麻烦： $obj-decoded-string
而设置邮件体内容的操作则绝对是恶梦 -- 我们不得不构建一个 Mail::Message::Body 对象来覆盖现有的。 $obj-body(Mail::Message::Body-new(data = [split /\n/, $body]));
Mail::Message 处理邮件的时候可能有点慢，也着实难用。它的体系也非常复杂，上面我们所看到的这些操作就已经用到了 16 种类 （Mail::Address, Mail::Box::Parser, Mail::Box::Parser::Perl, Mail::Message, Mail::Message::Body, Mail::Message::Body::File, Mail::Message::Body::Lines, Mail::Message::Body::Multipart, Mail::Message::Body::Nested, Mail::Message::Construct, Mail::Message::Field, Mail::Message::Field::Fast, Mail::Message::Head, Mail::Message::Head::Complete, Mail::Message::Part, 以及 Mail::Reporter）和 4400 多行的代码。尽管它确实拥有很多功能，我还是傻傻的觉得邮件的分析处理应该更为简洁。所以我坐下来决定自己着手编写尽可能简洁的邮件处理函数库，结果就有了 Email::Simple 模块，它的交互界面如下所示： my $obj = Email::Simple-new($rfc2822); my $subject = $obj-header("Subject"); $obj-header_set("Subject", "A new subject"); my $old_body = $obj-body; $obj-body_set("A new body\n"); print $obj-as_string;
它做的事情并不多，但却非常简单和高效。如果你需要 MIME 处理，可以使用它的子类 Email::MIME， 该类增加了 parts 方法。 实际上，选择哪一种邮件处理函数库完全取决于你，最终用户，不过并不总是这样的。有许多辅助性的模块，帮助你在更高的应用层上处理邮件信息的，可能要求你提供特定的邮件表达对象。比如最近的 Mail::ListDetector 模块（稍后我们将解析），需要传给它的邮件为 Mail::Internet 对象，因为该对象的操作界面（API）是已知的。而我不想用 Mail::Internet 对象，但我又需要 Mail::ListDetector 的一些功能，那我可以做些什么呢？ 为了让用户也能够有这样的选择，我写了一个用于表达上面各个模块操作界面的抽象层，叫做 Email::Abstract 。给出上面任何一种类型的对象，我们都可以说： my $subject = Email::Abstract-get_header($obj, "Subject"); Email::Abstract-set_header($obj, "Subject", "My new subject"); my $body = Email::Abstract-get_body($obj); Email::Abstract-set_body($message, "Hello\nTest message\n"); $rfc2822 = Email::Abstract-as_string($obj);
Email::Abstract 知道如何在这些主要的邮件表达对象上作相应的操作。它也抽象了构造邮件消息的过程，并允许你通过类方法 cast 来改变邮件消息对象的操作界面： my $obj = Email::Abstract-cast($rfc2822, "Mail::Internet");
my $mm = Email::Abstract-cast($obj, "Mail::Message"); 这样使得模块的作者得以使用“接口预先未知（interface-agnostic）”的方式来撰写邮件处理函数库。我很感谢 Michael Stevens 立即在 Mail::ListDetector 中使用了 Email::Abstract 。现在我可以将 Email::Simple 对象传递给 Mail::ListDetector 了，而且它工作的非常好。 Email::Abstract 也给了我们对上面所有这些模块作基准测试（benchmarks）的机会。这里是我使用的测试代码： use Email::Abstract; my $message = do { local $/; ; }; my @classes = qw(Email::MIME Email::Simple MIME::Entity Mail::Internet Mail::Message); eval "require $_" or die $@ for @classes; use Benchmark; my %h; for my $class (@classes) { $h{$class} = sub { my $obj = Email::Abstract-cast($message, $class); Email::Abstract-get_header($obj, "Subject"); Email::Abstract-get_body($obj); Email::Abstract-set_header($obj, "Subject", "New Subject"); Email::Abstract-set_body($obj, "A completely new body"); Email::Abstract-as_string($obj); } } timethese(1000, \%h); __DATA__ ...
我把一封短小的邮件放到 DATA 部分中，并运行相同的操作一千次：构造一个新的消息对象，读取邮件头，读取邮件体，并将消息内容作为字符串返回。 Benchmark: timing 1000 iterations of Email::MIME, Email::Simple, MIME::Entity, Mail::Internet, Mail::Message... Email::MIME: 10 wallclock secs ( 7.97 usr + 0.24 sys = 8.21 CPU) @ 121.80/s (n=1000) Email::Simple: 9 wallclock secs ( 7.49 usr + 0.05 sys = 7.54 CPU) @ 132.63/s (n=1000) MIME::Entity: 33 wallclock secs (23.76 usr + 0.35 sys = 24.11 CPU) @ 41.48/s (n=1000) Mail::Internet: 24 wallclock secs (17.34 usr + 0.30 sys = 17.64 CPU) @ 56.69/s (n=1000) Mail::Message: 20 wallclock secs (17.12 usr + 0.27 sys = 17.39 CPU) @ 57.50/s (n=1000)
Perl 电子邮件项目确实是成功的：Email::MIME 和 Email::Simple 的运行速度差不多是对手的两倍。然而，我们要强调一点，这里所做的测试都是非常低级的，如果你要做任何比这里看到的更加复杂的操作，你该考虑哪些老的 Mail:: 模块。 邮箱的处理对于单独信件的处理已经谈了很多了，让我们来看看对一组邮件或者存放邮件的文件夹该如何处理。我们提到过 Mail::Box ，它绝对是处理邮件文件夹的老大，它支持本地和远程的文件夹处理，可以编辑文件夹，以及作相应的排序操作等等。要使用它，我们首先需要 Mail::Box::Manager 模块，它是用来构建 Mail::Box 对象的工厂对象。 use Mail::Box::Manager my $mgr = Mail::Box::Manager-new;
接下来，我们通过管理器来打开文件夹： my $folder = $mgr-open(folder = $folder_file);
而现在，我们可以获取各个独立的邮件表达对象（Mail::Message）： for ($folder-messages) { print $_-subject,"\n"; }
与此最为相近的，我喜欢用的邮箱管理器还是 Mail::Util 的 read_mbox 函数。把 Unix 中 mbox 文件路径传递给它，然后返回一系列的匿名数组，每个匿名数组都表示一个邮件消息，其元素为该消息的每一行。如此一来，它非常适合 Mail::Internet-new 或者相近的： for (read_mbox($folder_file)) { my $obj = Mail::Internet-new($_); print $_-head-get("Subject"),"\n"; }
这两种做法都非常容易，不过似乎在 Mail::Util 的简洁性和 Mail::Box 的功能上还有些简化的余地，于是电子邮件项目再次停滞下来，这次的焦点集中在 Email::Folder 和 Email::LocalDelivery 上面。 Email::Folder 可以处理 mbox 和 maildir 格式的邮件文件夹，以及计划中更多其他格式，并且它有非常简洁的操作界面： my $folder = Email::Folder-new($folder_file); for ($folder-messages) { print $_-header("Subject"),"\n"; }
默认情况，它返回一系列 Email::Simple 对象用以表达每封邮件，不过这可以通过派生一个子类来改变。例如，如果我们想要原始的 RFC2822 格式的字符串，我们可以这样做： package Email::Folder::Raw; use base 'Email::Folder'; sub bless_message { my ($self, $rfc2822) = @_; return $rfc2822; }
可能将来我们不用再派生一个子类，然后 bless_message ，而改用 Email::Abstract-cast 来更容易的改变对邮件消息的表达方式。 处理文件夹的另一方面就是如何写数据了。或者说如何本地投递。Email::LocalDelivery 模块的出现是为了辅助 Email::Filter 。问题比听起来要更难些，因为它必须处理锁定，跳开邮件体，以及由 mailbox 和 maildir 等不同格式而引发的问题。而 LocalDelivery 则通过简单的界面把所有这些都隐藏起来： Email::LocalDelivery-deliver($rfc2822, @mailboxes);
Email::LocalDelivery 和 Email::Folder 都使用了 Email::FolderType 模块来帮助确定是哪种类型的邮件文件夹（通过文件名来判断）。 邮件地址的处理我们再次从抽象层面回到低级的处理，有大量的模块可用于对邮件地址的处理。我很喜欢老的 Mail::Address 模块。邮件地址可以分割为各种字段，诸如：实际的邮件地址，名称短语，注释信息。例如： Example user (Not a real user)
Mail::Address 解析这些邮件地址，并将名称短语和注释分离出来，以便获取各个独立的部分： for (Mail::Address-parse($from_line)) { print $_-name, "\t", $_-address, "\n"; }
不幸的是，和其他很多邮件模块一样，并不真的那么有用。 my ($addr) = Mail::Address-parse('"eBay, Inc." '); print $addr-name # Inc. eBay
得到的结果仍然难以让人接受，虽然它比之间的版本所返回的 "Inc Ebay" 要好些。于是 Casey West 加入我们并创造了 Email::Address 模块。它和 Mail::Address 使用一致的交互界面，并且运行地更加快速，差不多两到三倍。（译注：上面的例子中，Email::Address 返回 "eBay, Inc." 。看来在作者眼里，Mail::Address 的作者画蛇添足了。） 还有一件我们经常需要做的事情就是校验邮件地址是否合法。比如，某个用户在站点上注册，我们就需要对他所提供的邮件地址是否能够接收邮件作检查。Email::Valid 模块是在我们这帮叛逆的人冲进来之前，就已有的 Email:: 名字空间的原住民，这个模块就是用来做这件事情的。在它最简约的用法中，我们可以说： if (not Email::Valid-address('test@example.com')) { die "Not a valid address" }
你也可以打开其他检查的选项，比如确定它的域名拥有一个合法的 MX 记录，修正常见的 AOL 和 Compuserve 的邮件地址的一些错误，如下： if (not Email::Valid-address(-address = 'test@example.com', -mxcheck = 1)) { die "Not a valid address" }
邮件数据转换我们有了自己的信件，接下来会对它们做些什么呢？我发现大多是对邮件进行文本化分析，这里有三个模块可以协助我们： 首先是 Text::Quoted ，它获取邮件体的文本，实际上可以是任何其他文本，然后尝试找出某些引用其他邮件的文本部分，然后将之分离并保存到嵌套的数据结构中。例如，如果我们有 $message = foo # Bar baz quux EOF
然后运行 extract($message) 就会返回如下的数据结构： [ [ { text = 'foo', quoter = '', raw = ' foo' }, [ { text = 'Bar', quoter = ' #', raw = ' # Bar' } ], { text = 'baz', quoter = '', raw = ' baz' } ], { empty = 1 }, { text = 'quux', quoter = '', raw = 'quux' } ];
当你显示邮件消息的内容时，准备用不同的颜色来区分不同的引用文本，那么这个模块就帮到你大忙了。类似概念的还有 Text::Original 模块，用于搜寻以原始文件内容开头，没有被引用的部分。它知道如何识别各种类型的属性行，所以有： $message = Why are there so many different mail modules? There's more than one way to do it! Different modules have different focuses, and operate at different levels; some lower, some higher. EOF
那么 first_sentence($message) 将返回 There's more than one way to do it!。Mariachi 邮件列表存档程序就使用了这项技术，为一个线索中的邮件给出它的提白。 说到邮件的线索化，Mail::Thread 模块实现了 Jamie Zawinski 的邮件线索化算法，该算法先是被 Mozilla 所用，继而许多其他邮件客户端也开始使用这种技术。当然 Mariachi 也使用了这项技术，最近它还作了更新，使用 Email::Abstract 来处理各种你扔过去的邮件表达对象： my $threader = Mail::Thread-new(@mails); $threader-thread; # 计算线索 for ($threader-rootset) { # 在一个线索内的原始邮件 dump_thread($_); }
邮件过滤经典的 Perl 的邮件过滤工具莫不就是 Mail::Audit 了，我还在这里写过关于如何使用 Mail::Audit 模块的文章（http://www.perl.com/pub/a/2001/07/17/mailfiltering.html），以及如何与 Mail::SpamAssassin （http://www.perl.com/pub/a/2002/03/06/spam.html）模块相结合使用。 我们已经提到过 Mail::ListDetector 模块好几次了。我把它和 Mail::Audit 结合在一起使用，帮助自己做了大量的自动邮件过滤工作。Mail::Audit::List 的插件使用 ListDetector 来查找信件中的邮件列表头信息，诸如 List-Id，X-Mailman-Version 等等类似的东西，这些头信息可以帮助判别该邮件是否来自于邮件列表。这意味着我有能力过滤所有来自邮件列表的信件到各自的文件夹中，就像这样： my $list = Mail::ListDetector-new($obj); if ($list) { my $name = $list-listname; $item-accept("mail/$name.-$date"); }
然而，Mail::Audit 本身还有很长一段路要走，所以如果你新架设的系统的话，我们鼓励您使用电子邮件项目的 Email::Filter 模块作为替代，它们的大部分操作界面是一致的，尽管功能并不完全相同。为了追求简洁和速度，它使用了新式的 Email::Simple 作为邮件表达对象模块。 邮件信息挖掘最后，我所做的比较高级的事情就是开发一个自动分类，组织，并索引邮件到数据库的应用框架，并尝试从中分析并提取有价值的信息。 我的第一个完成这个预期目标的模块是 Mail::Miner ，它由三个主要部分组成。第一个部分获取一封邮件后，去除各种附件，并分别存储到数据库。第二部分纵览这封邮件并运行一系列的识别（Recogniser）模块，如此搜寻邮件地址，电话号码，一些关键字和短语等等，并把它们存储到另一个独立的数据库表中。第三部分为命令行工具，用来查询数据库中的邮件以及相关的信息。 举个例子，如果我需要找 Tim O'Reilly 的邮政地址，我就会使用查询工具 mm ，从他发来的信中找出该地址： % mm --from "Tim O" --address Address found in message 1835 from "Tim O'Reilly" : Tim O'Reilly @ O'Reilly %26amp; Associates, Inc. 1005 Gravenstein Highway North, Sebastopol, CA 95472
如果要获取完整的邮件，我可以说 % mm --id 1835
如果它原本包含一个附件，那么我们可能会看到类似下面的部分： [ text/xml attachment something.xml detached - use mm --detach 208 to recover ]
我粘贴中间的那一行 mm --detach 208 到 shell 中，然后很快的，something.xml 写到了磁盘上。 现在 Mail::Miner 已经非常不错了，不过它把三种思想紧紧地捆绑在一个包中 -- 邮件的归档，邮件的数据挖掘以及查询数据库的命令行界面 -- 这使得很难单独开发或者扩展每块的功能。当然，它使用了老式的 Mail:: 名字空间。 这引领我们走到这次邮件模块旅程的最后一站，最新发布的：Email::Store 模块。这是个基于 Class::DBI 的应用框架，用来存储邮件到数据库并以各种方式索引： use Email::Store 'dbi:SQLite:mail.db'; Email::Store-setup; Email::Store::Mail-store($rfc2822);
紧接着... my ($name) = Email::Store::Name-search( name = "Simon Cozens" ) @mails_from_simon = $name-addressings( role = "From" )-mails;
它可以用来构建类似 Mariachi 的邮件列表归档工具，或者类似 Mail::Miner 的数据挖掘。它仍然在初步的开发阶段，并在增强模块的扩展性方面使用了一些新的思想。 在我们使用 Email::Store 写出第一个邮件归档和搜索工具的时候，我会再次给大家作详细介绍的。这也是为了 perl.org 的新的 Perl 邮件列表处理接口而准备做的工作。 小结我们已经看过了 CPAN 上的几个主要的邮件处理模块，当然还有更多。很明显的，我着实偏袒那些自己写的模块。特定的 Perl 电子邮件项目的模块则使用 Email::* 的名字空间。我们特别设计了这些简洁、高效的模块，而它们并不总是老式的 Mail::* 模块的优良替换方案，特别像 Mail::Box 之类。到此，我希望各位通过对本文的阅读，了解和认识更多的邮件处理工具模块，并在之后使用 Perl 来处理邮件时，胸中有丘壑。
