0

我正在评估 Elixir/Erlang 项目的电子邮件解析库，并试图找出哪个是“最好的”，或者我是否应该构建自己的。我用于“最佳”的标准是：哪个库最符合 RFC。

我面临的问题是（不出所料）每个库都有自己的测试，所以如果我想比较苹果与苹果，我需要针对相同的测试运行它们。

是否有可用于评估的测试电子邮件集合？还是我最好从更活跃的 Java/Ruby/Python 库中复制测试？

4

2 回答 2

2

我认为您不会在 Elixir 中找到任何完整的电子邮件解析测试套件，但它会是一个非常好的项目。

如果我要开始一个这样的项目，我可能会为任何库选择测试，评估它的完整性（基于 RFC）并构建一个通用的方法来针对任何库运行它。

DockYard/elixir-mail/blob/master/test/mail/parsers/rfc_2822_test.exs对您来说是一个很好的起点。

于 2018-11-23T16:44:12.653 回答
1

我有一组用于测试 mime 解析器的 mbox。

https://github.com/jstedfast/MimeKit/tree/master/UnitTests/TestData/mbox

该链接是一个目录，其中包含一些*.mbox.txt文件及其等效的摘要文件（这只是关于每条消息的一些元数据，一旦解析器从 mbox 解析消息，就应该很容易从消息中获取这些元数据）。

还有一些*.html文件只是提取的 html 消息正文，用于测试逻辑以确定哪个正文部分是实际的消息正文。您可能可以忽略它，因为它与 rfc 合规性无关。

要查看和使用的主要 mbox 是jwz.mbox.txt文件 - 这是我在 2000 年初从 Netscape Mail 的 Jamie Zawinski 那里获得的 mbox 文件，用于测试 Netscape Mail 的解析器。

simple.mbox.txt是一个非常短的 mbox，包含 3 条消息，其中包含使用不同边界标记集的嵌套多部分。第二条和第三条消息是最有可能破坏解析器的两条消息（第一条可能会破坏新手在 sourceforge 或 github 上编写的随机 mime 解析器，但没有认真写过）。第二条消息具有所有嵌套的多部分，使用boundary="x"它将破坏不使用边界堆栈的解析器。第三条消息具有嵌套的多部分，它们都使用空字符串边界（例如boundary=""）。

然后有一个content-length.mbox.txt用于测试解析器正确处理 Content-Length 标头的方法。

unmunged.mbox.txt看起来它是意外提交的 - 看起来我写它是为了测试 Thunderbird 对 Content-Length 标头和未处理的 From 行做了什么？

无论如何，要查看我如何生成摘要文件的输出，您可以查看https://github.com/jstedfast/MimeKit/blob/master/UnitTests/MimeParserTests.cs#L624

DumpMimeTree 等方法都列在文件中该方法的上方。

我的 C MIME 解析器也有一个非常相似的测试套件（如果您更愿意阅读 C 而不是 C#）：https://github.com/jstedfast/gmime/blob/master/tests/test-parser。 C

其他想法：

在评估 MIME 解析器时要记住的一件事是，您并不真正希望在解析时严格遵守 rfc，因为这意味着很多消息将无法解析。您真正想要的是一个库，该库将在输出严格符合 rfcs 的新消息（无论如何尽可能多）的同时处理尽可能多的损坏。

虽然这些 mbox 文件应该有助于确保您测试的解析器至少足够强大以处理这些文件，但这不一定是测试的全部。

在评估 MIME 解析器时，我接下来要做的一件事是检查解析器如何解析地址标头。它会做一些愚蠢的事情吗，比如在,'s 上拆分标题值？如果是这样，它就出来了。我可能会说它最好使用标记器方法，或者它可能甚至不值得考虑。

rfc2047 解码也是如此。

这是我在 2013 年为 C#/.NET 寻找相当好的 MIME 解析器时写的咆哮：https ://jeffreystedfast.blogspot.com/2013/09/time-for-rant-on-mime -parsers.html

这链接回我之前写的一篇文章，这是关于为什么解码标头（rfc2047）很难正确处理的咆哮：https ://jeffreystedfast.blogspot.com/2013/08/why-decoding-rfc2047-encoded-headers -is.html

我想尝试评估 MIME 解析器/电子邮件库的问题在于，您需要非常熟悉规范，以便在尝试评估它们时更有信心，超越简单的“它可以解析我的随机消息集吗？ ？”

我希望这对您有所帮助，但是...是的，如果您的经历与我在 2013 年寻找体面的 C# 解析器时的经历相似，那么您将需要编写自己的 - 请，请，请阅读如果您这样做，请遵循规范，否则您最终只会给其他电子邮件开发人员带来噩梦。

于 2018-11-24T12:36:33.547 回答