尝试使用 MIME 发送“替代”，但它也显示在功能强大的邮件客户端中

Question

我正在尝试发送漂亮的 MIME 电子邮件，其中 html 将尽可能显示，如果不可能，它应该有一个文本回退。

也就是说，当 html 包含图像时，“alternative”部分应显示“img ... should be here”。

问题是我在 gmail 中看到了所有内容，还有其他选择。

我的 MIME 消息有问题吗？

以下是内容：

Content-Type: multipart/mixed; boundary="===============9061258228856181354=="
MIME-Version: 1.0
From: me@gmail.com <me@gmail.com>
To: me@gmail.com

--===============9061258228856181354==
Content-Type: multipart/alternative; boundary="===============2889524977048828163=="
MIME-Version: 1.0

--===============2889524977048828163==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

img 1043833786270341319 should be here
--===============2889524977048828163==--

--===============9061258228856181354==
Content-Type: image/jpeg; name="sky.jpg"
MIME-Version: 1.0
Content-ID: <1043833786270341319>
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK
CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU
FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCAEbAakDASIA
AhEBAxEB/8QAHQAAAgIDAQEBAAAAAAAAAAAAAgQBAwUGBwAICf/EADoQAAEEAQMDAwIFAgYBBAMB

--===============9061258228856181354==
Content-Type: multipart/related; boundary="===============7011550496984103126=="
MIME-Version: 1.0

--===============7011550496984103126==
Content-Type: text/html; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

<div><h1>bla</h1></div><img src="cid:1043833786270341319" title="1043833786270341319"/>
--===============7011550496984103126==--

--===============9061258228856181354==--

注意：图像代码被剪掉了，所以它的代码不是很大。同样，简单的目标是为非 html 阅读器显示后备，它应该具有与 html 消息不同的消息。一个有能力的邮件程序不应该显示替代消息，对吗？

Answer 1

基本上，您的邮件没有正确排列。有几种方法可以在 MIME 消息中排列各个部分，以便它们对邮件代理有意义。让我们从简单的开始，然后进入复杂的选项：

最简单的是带有一些附件的文本。例如，您想将您的简历发送给某人，因此您写了几句话的介绍并附上一个或多个文件（求职信，简历）：

哑剧？？？多部分/混合？？？文本
                       ??附件1
                       ??附件2

多部分/混合意味着电子邮件代理将按顺序显示部分 - 一个接一个。

• 如果附件的 content-disposition 是inline，并且电子邮件代理能够显示给定的附件类型，那么它将显示在邮件本身内部 - 在其末尾。
• 如果附件的 content-disposition 是attachment，它们通常会显示为某种图标或用于保存附件的链接。

如果你想发送一个漂亮的 HTML 消息，习惯上同时包含一个纯文本版本和一个 HTML 版本。这样即使在不支持 HTML 的电子邮件阅读器中，收件人也可以阅读它。您需要使用 multipart/alternative：

mime???multipart/mixed???multipart/alternative???text/plain
                       ? ??文本/html
                       ??附件1
                       ??附件2

所以，同样，消息内容包括三个部分，正文和两个附件。但是正文本身是一个multipart/alternative，它包含纯文本版本和 HTML 版本。请记住首先放置纯文本，然后放置 HTML，因为约定是邮件代理选择它知道如何显示的最后一个选项。

附件将在正文之后连续显示，就像以前一样，因为它们是主级别中的下一个部分，即multipart/mixed.

现在让我们看看一封没有“附件”的邮件，但它确实有应该嵌入 HTML 中的图像。在这种情况下，邮件代理需要知道附件不仅仅是发送给阅读器以供下载的文件，而且应该与 HTML 相关联地显示它们。所以正确的 mime 类型是multipart/related, 以表明这些部分是相关的。在这种情况下，您还需要为它们提供正确的内容 ID，并在 HTML 中使用这些内容 ID。这不是 MIME 标准的一部分，但它是当今 HTML 邮件的通常处理方式。

就 MIME 而言，这样的消息将如下所示：

mime???multipart/alternative???text/plain
                             ??multipart/related???text/html
                                                 ??嵌入图像1
                                                 ??嵌入图像2

这次我们没有附件，所以我们可以把multipart/alternative作为我们的顶级内容。像以前一样，它首先具有明文替代方案，但第二个替代方案本身就是一个MimeMultipart("related").

在其中，您有 HTML 部分和两个图像。HTML 及其图像必须始终是同一个多部分/相关对象的一部分。

现在，如果您想将您的文档附加到这样的消息中，其中包含 HTML和图像的消息怎么办？然后你会使用这样的东西：

mime???multipart/mixed???multipart/alternative???text/plain
                       ? ??multipart/related???text/html
                       ? ??嵌入图像1
                       ? ??嵌入图像2
                       ??附件1
                       ??附件2

因此，您的顶级对象是多部分/混合的，允许您将附件按顺序添加到您的消息中。消息“正文”（ 的第一部分multipart/mixed）是multipart/alternative带有嵌入式multipart/related. 然后其他附件紧随其后。

总之：

• 甲multipart/mixed消息具有被认为是您的可读的消息的第一部分，和其余的是附件。所有部分将由读者的邮件代理显示。
• 一条multipart/alternative消息给出了相同内容的不同显示选择，从最常见的分母到最稀有的表示类型（例如纯文本？HTML？富文本？专有格式）排序，收件人的邮件程序选择它知道如何显示的最后一个。您只看到其中一种选择。
• 甲multipart/related消息通常用于将HTML体与它的内联消息组合。第一部分是 HTML，其他部分具有 HTML 用于其<img src="..." />标签的Content-ID 。

现在让我们根据边界字符串查看您自己的层次结构。你的最外层是一个multipart/mixed与边界===============9061258228856181354==。如果您查找此边框出现的所有位置，您将看到 this 包含三个部分multipart/alternative。

第一部分是：

mime???multipart/mixed???text
                       ??attachment1
                       ??attachment2

这部分是multipart/alternative，但它只有一个替代部分- 其内容类型为 text/plain。

第二部分是：

mime???multipart/mixed???multipart/alternative???text/plain
                       ?                       ??text/html
                       ??attachment1
                       ??attachment2

所以它是一个图像。

第三部分是：

mime???multipart/alternative???text/plain
                             ??multipart/related???text/html
                                                 ??embedded image 1
                                                 ??embedded image 2

嗯，这是一个multipart/related. 但它只有一个部分——text/html信息。图像不是它的一部分。

因此，而不是具有以下层次结构，这是适合您描述的层次结构（文本纯文本和 html 替代方案，html 部分具有嵌入的图像）

mime???multipart/alternative???text/plain
                             ??multipart/related???text/html
                                                 ??嵌入图像

你有这个错误的层次结构：

mime???multipart/mixed???multipart/alternative???text/plain
                       ？？图片
                       ??multipart/related???text/html

因为所有部件都在一个 中multipart/mixed，所以它们按顺序显示，而不是作为替代品。因为text/plain和multipart/related不是相同的部分multipart/alternative，邮件代理不知道它们是彼此的替代品。它认为没有其他选择text/plain，只有一部分multipart/alternative。

由于该multipart/related部分不包含图像，因此会有邮件代理无法将图像正确放入 HTML 中。此外，正因为如此，该图像可能会连续或作为附件显示给您 - 它是独立的，与其他任何东西都没有关系。

因此，您必须重新排列您的消息以符合适当的层次结构，以便替代品起作用并使图像与 HTML 正确相关。