我正在尝试发送不错的MIME电子邮件，只要有可能就会显示html，如果不可能，它应该有文本后备。
也就是说，当html包含图像时，“替代”部分应该显示“img ...应该在这里”。
问题是我在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消息不同的消息。一个有能力的邮件程序不应该显示替代消息，对吗？
答案 0 :(得分：4)
基本上，您的邮件没有正确显示。有几种方法可以在MIME消息中排列这些部分，以便它们对邮件代理有意义。让我们从简单开始，一直到复杂的选项：
最简单的是带有一些附件的文字。例如，您想将简历发送给某人，所以您写下几个介绍并附上一个或多个文件（求职信，简历）：
mime───multipart/mixed─┬─text
├─attachment1
└─attachment2
Multipart / mixed意味着电子邮件代理将连续显示部件 - 一个接一个地显示。
inline，电子邮件代理能够显示给定的附件类型，然后它将显示在消息本身内 - 最后。attachment，它们通常会显示为某种图标或链接，用于保存附件。如果要发送漂亮的HTML邮件，通常包括纯文本版本和HTML版本。这样，即使在不支持HTML的电子邮件阅读器中，收件人也可以阅读它。您需要使用multipart / alternative：
mime───multipart/mixed─┬─multipart/alternative─┬─text/plain
│ └─text/html
├─attachment1
└─attachment2
因此，消息内容再次包括三个部分，正文和两个附件。但是正文本身是multipart/alternative，它包含明文版本和HTML版本。请记住将明文放在第一位，将HTML放在第二位，因为约定是邮件代理选择它知道如何显示的最后一个替代方案。
附件将在身体后面连续显示，就像之前一样，因为它们是主要级别的下一个部分，即multipart/mixed。
现在让我们看一下没有＆＃34;附件＆＃34;的邮件，但它确实有嵌入HTML内部的图片。在这种情况下，邮件代理需要知道附件不仅仅是发送到要下载的阅读器的文件，而是它应该与HTML相关联地显示它们。因此，正确的mime类型为multipart/related，以显示部件是相关的。在这种情况下，您还需要为其提供正确的内容ID，并在HTML中使用这些内容ID。这不是MIME标准的一部分，但它现在通常是如何完成HTML邮件的。
就MIME而言，这样的消息将如下所示：
mime───multipart/alternative─┬─text/plain
└─multipart/related─┬─text/html
├─embedded image 1
└─embedded image 2
这次我们没有附件，所以我们可以将multipart / alternative作为我们的顶级内容。它首先具有明文替代方案，如前所述，但第二种方案本身是MimeMultipart("related")。
在其中，您有HTML部分和两个图像。 HTML及其图像必须始终是同一多部分/相关对象的一部分。
现在，如果您想将文档附加到这样的邮件，即其中包含HTML 和图像的邮件，该怎么办？然后你将使用这样的东西：
mime───multipart/mixed─┬─multipart/alternative─┬─text/plain
│ └─multipart/related─┬─text/html
│ ├─embedded image 1
│ └─embedded image 2
├─attachment1
└─attachment2
因此，您的顶级对象是多部分/混合对象，允许您以连续方式为邮件添加附件。消息＆＃34; body＆＃34; （multipart/mixed的第一部分）是multipart/alternative的复杂结构，其中嵌入了multipart/related。然后是其他附件。
总结：
multipart/mixed消息的第一部分应该是您的可读消息，其余部分是附件。 所有部分都将由读者的邮件代理显示。multipart/alternative消息提供相同内容的不同显示选项，从最常见的分母到最罕见的演示文稿类型（例如纯文本→HTML→富文本→专有格式）和收件人的邮件排序程序选择它知道如何显示的最后一个。 您只看到其中一个替代方案。multipart/related消息通常用于将HTML正文与其内联消息组合在一起。第一部分是HTML，其他部分包含HTML用于其<img src="..." />标记的Content-ID。现在，让我们根据边界字符串查看您自己的层次结构。您的最外层是multipart/mixed，边界为===============9061258228856181354==。如果您查找此边框显示的所有位置，您会看到此multipart/alternative有三个部分。
第一部分是：
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==--
这部分是multipart/alternative，，但它只有一个替代部分 - 其内容类型为text / plain。
第二部分是：
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
所以它是一张图片。
第三部分是：
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==--
嗯，它是multipart/related。但它只有一部分 - text/html消息。图像不是它的一部分。
因此，不要使用以下层次结构，这是您所描述的适当的层次结构（文本普通和html替代，具有嵌入图像的html部分）
mime───multipart/alternative─┬─text/plain
└─multipart/related─┬─text/html
└─embedded image
您有错误的层次结构：
mime───multipart/mixed─┬─multipart/alternative───text/plain
├─image
└─multipart/related───text/html
因为所有部分都在multipart/mixed中，所以它们是连续显示的，而不是替代品。由于text/plain和multipart/related不是同一multipart/alternative的一部分，因此邮件代理不知道它们是彼此的替代品。它看不到text/plain的其他替代方案，multipart/alternative中只有一个部分。
由于multipart/related部分不包含图像，因此会有邮件代理无法正确地将图像放入HTML中。此外，因此，图像可能是连续显示给您或作为附件显示 - 它是独立的，与其他任何内容无关。
因此，您必须重新排列邮件以符合正确的层次结构，以使替代方案正常工作，并使图像与HTML正确相关。