“与HTML无关的电子邮件客户端中的反向通道”是什么？

Question

已发布的利用EFAIL电子邮件加密漏洞的示例似乎都使用HTML创建了用于提取解密数据的反向通道。

然而，https://efail.de/的主页声称：

短期内:禁用HTML呈现。...注意到，电子邮件客户端中还有其他可能的反向通道，它们与HTML无关，但它们更难以利用。

据我所见，所有已发布的示例都依赖于远程内容的加载(即从HTML邮件链接的内容，如图像或CSS)。

所以：

• 为什么建议完全禁用HTML呈现？禁用远程内容加载(这在大多数现代邮件程序中是默认的)还不够吗？
• 还有哪些“与HTML无关”的回溯通道？作者在某个地方详细说明了这一点吗？

Answer 1

首先，我建议您不仅阅读漏洞的主页，而且还要阅读实际论文，因为它有更多的细节。你的问题在看报纸时都被回答了。

为什么建议完全禁用HTML呈现？禁用远程内容加载(这在大多数现代邮件程序中是默认的)还不够吗？

因为禁用远程内容的设置(如果存在的话)通常不会实际禁用所有远程内容。仅举论文中的一个例子(第20页，第21页)，即使禁用了远程内容的加载，以下内容也会导致对Thunderbird中的远程URL的请求：

<link href="http://efail.de" rel="preconnect">

还有哪些“与HTML无关”的回溯通道？作者在某个地方详细说明了这一点吗？

是的，提交人清楚地阐述了这一点。在论文的第20页和第21页，作者列出了许多不同邮件客户端关于可能的回溯渠道的行为。虽然大多数的回溯通道都需要HTML，但也有一些是由普通邮件头造成的。例如，根据纸，Apple可以用于如下所示的反向通道：

Remote-Attachment-Url: http://efail.de