IMAP - 区分内联附件和常规附件的规则

Question

我正在开发一个电子邮件客户端，我想知道确定附件是否为常规附件（可下载文件，如 pdf、视频、音频等）的正确算法是什么... ) 或 内联附件（它只是 HTML 字母的嵌入部分）。 直到最近，我检查了正文类型（假设消息部分不是多部分，否则我会进一步递归解析 ir）不是 TEXT。也就是不管是APPLICATION,IMAGE，AUDIO还是VIDEO.，如果是这样的话，我看了一下第九个元素是等于ATTACHMENT还是INLINE。我认为如果它是 INLINE，那么它是一个嵌入的 HTML 粒子，而不是一个常规的附件。

但是，最近我收到一封电子邮件，其中包含一些 HTML 邮件正文和常规附件。问题是它的身体结构是这样的：

1. mutlipart/mixed
   1.1. mutlipart/alternative
        1.1.1. text/plain
        1.1.2. multipart/relative
               1.1.2.1. text/html
               1.1.2.2. Inline jpeg
               1.1.2.3. Inline jpeg
   1.2. pdf inline (why 'inline'? Should be 'attachment')
   1.3. pdf inline (why 'inline'? Should be 'attachment')

问题是，为什么可下载的 pdf 文件是 INLINE 类型的？确定文件是嵌入的 html 粒子还是可下载文件的适当算法是什么？我是否应该查看父子类型以查看它是否为 relative 并忽略内联与附件参数？

Answer 1

确实没有定义一刀切的算法。 inline 或 attachment 是发件人设置的内容，并提示他们是否希望将其显示为 inline（自动呈现）、attachment（显示在列表中）或两者都不显示（无偏好） )。

还有一些有时称为“嵌入”的附件，它们是带有Content-ID 的附件（这是在正文结构响应中），并由 标记等中的cid: 引用引用.

因此，这几乎必须以启发式方式完成。

这实际上取决于您的需求和客户的能力，但这里列出了您可以考虑以某种组合使用的启发式方法（其中一些是相互排斥的）：

1. 如果标记为“附件”，则将其视为附件。
2. 如果它被标记为内联，并且您可以将其视为内联（image/*，如果您愿意，也可以是text/*），那么它就是内联的。
3. 如果它具有 Content-ID，则将其视为内联。
4. 如果它有一个 Content-ID，并且 HTML 部分引用了它，则将其视为嵌入的（即 HTML 查看器将呈现它）；如果未引用，请按照您的要求将其视为内联（或附件）。
5. 如果两者都不是，并且您想将其视为内联，则将其视为内联。
6. 如果不适用，请将其视为附件。
7. 忽略处置，如果您愿意，将其视为内联（例如使所有图像始终内联）

另外，inline 的原始版本只意味着发件人希望它自动呈现；这通常与referenced by the HTML section（我称之为嵌入式）混为一谈。这些不太一样。