我其实刚刚在几个月前处理过这个问题。我为我工作的产品添加了电子邮件功能,包括发送和接收。第一部分是向用户发送提醒,但我们不想管理客户管理员的反弹,我们决定在邮件收件箱中显示管理员可以在没有我们的情况下看到反弹和回复,管理员可以处理调整电子邮件地址,如果他们需要。
因此,我们接受发送到我们收看的所有电子邮件。我们使用VERP将电子邮件与用户相关联,并将整个电子邮件原样存储在数据库中。然后,当管理员请求查看电子邮件时,我们必须解析电子邮件。
我的第一次尝试与先前的答案非常相似。如果其中一个部分是html,则显示它。如果是文本,请显示它。否则,请显示原始的原始电子邮件。这几个邮件真正快速地分解了一些不是由sendmail生成的邮件。 Outlook,Exchange和其他一些电子邮件系统不这么做,他们使用多部分来发送电子邮件。经过大量的挖掘和诅咒之后,我发现这个问题似乎并没有很好的记录。在查阅MHonArc并阅读RFC(RFC2045和RFC2046)的帮助下,我决定了下面的解决方案。我决定不使用MHonArc,因为我无法轻松地重用解析和显示功能。我不会说这是完美的,但我们使用它已经足够好了。
首先,接收邮件并使用Email :: MIME解析它。然后使用Email :: MIME为您提供 - > parts()部分的数组,调用名为get_part的函数。
get_part,对于它传递的每个部分,解码内容类型,在哈希中查找它,如果存在,调用与该内容类型关联的函数。如果解码器能够给我们一些东西,把它放在结果数组上。
拼图的最后一块是这个解码器阵列。基本上,它定义了内容类型我可以处理:
- text/html的
- 纯文本/
- 消息/递送状态,这实际上也是纯文本
- multipart/mixed
- multipart/related
- 多部分/替代
的非多段我返回原样。对于混合,相关和替代,我只需在该MIME节点上调用get_parts并返回结果。因为替代方法很特殊,所以在调用get_parts之后它有一些额外的代码。它只会返回HTML,如果它有一个HTML部分,或者它只会返回它的文本部分有一个文本部分。如果它没有,它不会返回任何有效的。
有效内容类型散列的优点是我可以根据需要轻松添加更多部分的逻辑。到get_parts完成时,您应该有一系列您关心的所有内容。
我应该提到另一个项目。作为其中的一部分,我们创建了一个实际服务于这些消息的独立域。管理员工作的主要域名将拒绝提供该信息并将浏览器重定向到我们的用户内容域。这第二个域只会提供用户内容。这是为了帮助浏览器正确地将内容从我们的主域中转移出来。看到相同的来源政策(http://en.wikipedia.org/wiki/Same_origin_policy)
dupe of http://stackoverflow.com/questions/2795893 – daxim 2010-06-18 12:20:47
感谢daxim,我没有发现,当我看到之前。看起来我必须使用Email :: MIME。 – aidan 2010-06-18 16:26:26