检查电子邮件的加密状态。答案

【问题标题】：Checking encryption status of email.检查电子邮件的加密状态。
【发布时间】：2013-09-16 01:08:38
【问题描述】：

我最近一直在使用 gpg-mailgate，它几乎可以按照我想要的方式运行。

我的最后一个小障碍是如何可靠地检查收到的电子邮件是否已经过 pgp 加密。这是我看到的选项。

在使用 Mail::gpg.is_encrypted 的后缀中添加内容过滤器，如果消息返回是，则直接发送。如果没有，那么我可以将它发送到 gpg-mailgate 来处理它。
从 gpg-mailgate 中调用一个小的 perl 脚本，然后再次调用 Mail::GPG.is_encrypted 并从那里开始。我看到了一些从 python 中调用 perl 的例子，我更喜欢这样做。
我可以不可靠地通过查找 **BEGIN PGP MESSAGE** 来测试加密，但这绝不是很好的解决方案。

这就是我想出的全部。由于 gnupg python 包装器中没有任何东西可以对此进行测试，我想我将不得不考虑调用其他东西。

在前两种情况下，我担心的是性能。我试图尽可能多地避免不必要的负担。

我愿意接受所有建议，谢谢。

【问题讨论】：

这对于神经网络来说将是一个很酷的项目。也许尝试 ann 提供某种反馈，向它展示每种类型的一堆电子邮件（以训练它），然后让它尝试猜测未知的并给它反馈

标签： python perl email encryption pgp

【解决方案1】：

通过电子邮件发送的 GPG 或其他 OpenPGP 消息应以RFC 2015 格式发送。检测起来非常简单、可靠且高效。

基本上，您只是在检查 RFC822 标头是否具有如下所示的 Content-Type：

Content-Type: multipart/encrypted; boundary=whatever; protocol="application/pgp-encrypted"

理想的方法是使用 Python 中的 email 和 mime 模块，或者你最喜欢的 perl 中的 CPAN 等价物，但你可以使用精心设计的正则表达式更快地做到这一点。（如果您选择采用这种方式，请为 RFC822 标头查找经过预先测试的正则表达式并在此基础上进行构建，因为在前 20 次执行此操作时您会得到部分 RFC822 错误。续行，到处都是可选的空格，组件的可变顺序，不区分大小写等）

但是，如果有人只是将原始 OpenPGP 消息作为电子邮件文本发送了怎么办？至少一些 MUA 会检测到这一点并将其视为正确的 OpenPGP 消息。他们是怎么做到的？基本上，你建议的方式：扫描身体。

首先是获取身体本身。如果他们只是使用纯文本邮件程序，或者不是愚蠢的花哨的邮件程序，那么它只是非多部分 RFC 822 消息的正文，这很容易。但是，如果您想处理喜欢将所有内容 HTML 化的邮件，则需要在扫描之前找到 text/plain 部分。可靠或快速地做到这一点并不算太糟糕，但两者兼而有之？

现在，如何判断消息正文是否为 OpenPGP？ RFC 4880 描述了格式。特别是，请看第 6.2 节关于 ASCII 盔甲格式的内容。

但简而言之：查找 Armor 标题行 -----BEGIN PGP MESSAGE-----，然后是零个或多个 RFC-822 标题，然后是一个空白行，然后是一个全是 base-64 字符和空格的数据块，然后是 Armor 尾行-----END PGP MESSAGE-----。为了安全起见，您可能希望在标题和尾部之前和之后允许任意行（它不会使扫描变得更加困难）。任何匹配的内容都非常非常可能是 OpenPGP 消息；任何不可用的东西都不太可能与 GPG 一起使用。

这仍然无法处理人们可能使用的所有情况。如果有人发送拆分为两封电子邮件的 OpenPGP 多部分消息，拖放 OpenPGP 消息的方式使他们的邮件程序将其变成附件而不是正文，粘贴二进制 OpenPGP 消息而不是 ASCII 装甲消息， …

但我怀疑只处理正确的 OpenPGP MIME 和明文正文中的原始 OpenPGP ASCII 装甲就足够了。

【讨论】：

非常感谢。我认为我最喜欢 regexp 路径，尽管我和 regexp 从来都不是好朋友。我没有想过要走那条路，但我想当你开始着手时，这可能就是你找到的任何包装器都会做的事情。
我很快投入了几行日志记录来转储原始消息。 User-Agent: K-9 Mail for Android MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Test logging 所以 content-type 不会像我希望的那样有用。
@TheEditor：大多数包装器不会使用正则表达式；他们将使用完整的 RFC2822 和 MIME 解析器。以这种方式编写的代码将更简单，更健壮。改用正则表达式的唯一原因是，如果完整的解析器太慢了——这在你的用例中似乎是合理的，但你真的应该先试试看，而不是仅仅假设它。
@TheEditor：对于您的第二条评论，我知道一些 MUA 确实忽略了 OpenPGP 使用 MIME 的建议，而且我也知道很多人使用根本不使用 OpenPGP 的 MUA，并解决它通过将 ASCII 装甲消息粘贴到纯文本消息中（或使用为其执行此操作的插件或助手）。所以你真的需要 OpenPGP MIME 和明文正文中的原始 OpenPGP ASCII 盔甲。（你可能需要更多，但我认为你不会。所以从两个常见的情况开始，然后让它发挥作用，这可能就是你所需要的。）
再次感谢。我正在学习，所以我很感激所有的信息。