试图发送“替代”与MIME，但它也显示在有能力的邮件客户端 [英] Trying to send "alternative" with MIME but it also shows up in capable mail client

问题描述

我正在尝试发送不错的MIME电子邮件，其中html将会尽可能地显示，而不可能的话，应该有一个文本的回退。当html包含图像时，替代部分应该显示img ...应该在这里。

问题是我看到 em>，也是gmail中的替代方案。

我的MIME邮件有问题吗？

内容：

 内容类型：multipart / mixed; boundary ================ 9061258228856181354 ==
 MIME-Version：1.0 
 From：[e-mail]< [e-mail]& 
至：[e-mail] 
 
  -  =============== 9061258228856181354 == 
内容类型：多部分/替代; boundary ================ 2889524977048828163 ==
 MIME版本：1.0 
 
  -  ========= ====== 2889524977048828163 == 
 Content-Type：text / plain; charset =us-ascii
 MIME版本：1.0 
 Content-Transfer-Encoding：7bit 
 
 img 1043833786270341319应该在这里
  -  == =========== 2889524977048828163 ==  -  
 
  -  =============== 9061258228856181354 == 
 Content-类型：image / jpeg; name =sky.jpg
 MIME版本：1.0 
 Content-ID：< 1043833786270341319> 
内容传输编码：的base64 
 
 / 9J / 4AAQSkZJRgABAQAAAQABAAD / 2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK 
 CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT / 2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU 
 FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT / wAARCAEbAakDASIA 
 AhEBAxEB / 8QAHQAAAgIDAQEBAAAAAAAAAAAAAgQBAwUGBwAICf / EADoQAAEEAQMDAwIFAgYBBAMB 
 
  -  =============== 9061258228856181354 == 
内容类型：multipart / related; boundary ================ 7011550496984103126 ==
 MIME版本：1.0 
 
  -  ========= ====== 7011550496984103126 == 
内容类型：text / html; charset =us-ascii
 MIME版本：1.0 
内容传输编码：7bit 
 
< div>< h1> bla< / h1>< / div>< img src =cid：1043833786270341319title =1043833786270341319/> 
  -  =============== 7011550496984103126 ==  -  
 
  -  ============ = 9061258228856181354 ==  -  
  

注意：图像代码只是因为它不是很大的代码。再次，简单的目的是为非html读者显示一个回退，应该有一个不同于html消息的消息。一个有能力的邮件员不应该显示替代邮件，对吧？

解决方案

基本上，你的邮件没有正确的发生。有几种方法可以在MIME消息中排列这些部分，使其对邮件代理有意义。让我们从简单的开始到复杂的选项：

---

最简单的是带有几个附件的文本。例如，你想把你的简历发给某人，所以你写几个简介，并附上一个或多个文件（求职信，简历）：

 
mime───multipart/mixed-┬-text
├─attachment1
└─attachment2
 

Multipart / mixed意味着电子邮件代理将逐个显示零件。

• 如果附件的内容-disposition是 inline ，电子邮件代理能够显示给定的附件类型，然后它将显示在消息本身的结尾。


• 如果附件的内容处理是附件，它们通常会显示为保存附件的某种图标或链接。 li>
  

---

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

 
mime──multipart/mixed-┬-multipart/alternative-┬-text/ plain 
│└─text/ html 
├─attachment1
└─attachment2
 

所以，再次，消息内容包括身体和两个附件的三个部分。但身体本身是一个 multipart / alternative ，它包含明文版本和HTML版本。记住要把明文放在第一位，而第二个HTML则是邮件代理选择最后一个它知道如何显示的选项。

附件是就像以前一样，像以前一样，是在主体级别的下一个部分，即 multipart / mixed 。

---

现在我们来看看一个没有附件的邮件，但它的图片应该嵌入到HTML中。在这种情况下，邮件代理需要知道附件不仅仅是将文件发送给读者进行下载，而且应该与HTML相关联地显示它们。所以正确的mime类型是 multipart / related ，以显示部件是相关的。在这种情况下，您还需要给予正确的内容ID，并在HTML中使用这些内容ID。这不是MIME标准的一部分，但是HTML邮件通常是这样做的。

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

 
mime-──multipart/alternative-┬-text/ plain 
└─multipart/related-┬-text/ html 
├─embeddedimage 1 
└─embeddedimage 2 
 

这一次我们没有附件，所以我们可以把multipart / alternative作为我们的顶级内容。它具有明文替代方法，如前所述，但第二种替代方案本身就是一个 MimeMultipart（related）。

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

---

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

 
mime-──multipart/mixed-┬-multipart/alternative-┬-text/ plain 
│└─multipart/related-┬-text/ html 
│├─embeddedimage 1 
│└─embeddedimage 2 
├─attachment1
└─attachment2 
 

所以你的顶级对象是multipart / mixed，允许你连续地添加附件到你的消息。消息body（ multipart / mixed 的第一部分）是 multipart / alternative 的复杂结构嵌入式 multipart / related 。

---

总结：

• 一个 multipart / mixed 消息有一个第一部分，应该是你可读的消息，其余的是附件。 所有部分将由读者的邮件代理显示。


• 一个 multipart / alternative 消息给出不同的显示相同内容的替代品，从最常用的分母排序到最罕见的展示类型（例如纯文本→HTML→富文本→专有格式），收件人的邮件程序选择最后一个它知道如何显示的内容。 您只能看到其中一种备选方案。


• 一个 multipart / related 消息通常用于组合带有内联消息的HTML主体。第一部分是HTML，其他部分具有HTML用于其< img src =.../> 标签的Content-ID。 li>
  

---

现在我们来看看你自己的层次结构，基于边界字符串。你的最外层是一个 multipart / mixed ，边界 =============== 9061258228856181354 == 。如果您查找此边框出现的所有地方，您会看到这个 multipart / alternative 有三个部分。

第一部分是：

  Content-Type：multipart / alternative; boundary ================ 2889524977048828163 ==
 MIME版本：1.0 
 
  -  ========= ====== 2889524977048828163 == 
 Content-Type：text / plain; charset =us-ascii
 MIME版本：1.0 
 Content-Transfer-Encoding：7bit 
 
 img 1043833786270341319应该在这里
  -  == =========== 2889524977048828163 ==  -  
  

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

第二部分是：

  Content-Type：image / jpeg; name =sky.jpg
 MIME版本：1.0 
 Content-ID：< 1043833786270341319> 
内容传输编码：的base64 
 
 / 9J / 4AAQSkZJRgABAQAAAQABAAD / 2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK 
 CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT / 2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU 
 FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT / wAARCAEbAakDASIA 
 AhEBAxEB / 8QAHQAAAgIDAQEBAAAAAAAAAAAAAgQBAwUGBwAICf / EADoQAAEEAQMDAwIFAgYBBAMB 
  

所以这是一个图像。

第三部分是：

  Content-Type：multipart / related; boundary ================ 7011550496984103126 ==
 MIME版本：1.0 
 
  -  ========= ====== 7011550496984103126 == 
内容类型：text / html; charset =us-ascii
 MIME版本：1.0 
内容传输编码：7bit 
 
< div>< h1> bla< / h1>< / div>< img src =cid：1043833786270341319title =1043833786270341319/> 
  -  =============== 7011550496984103126 ==  -  
  

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

所以，而不是具有以下层次结构，这适用于你所描述的（text plain和html替代方案，html部分有一个嵌入的图像）

 
mime-──multipart/alternative-┬-text/ plain 
└─multipart/ related- ┬─text/ html 
└─embeddedimage 
 

你有这个错误层次结构： p>

 
mime-──multipart/mixed-┬-multipart/alternative-─text/ plain 
├─image
 └─multipart/related-─text/ html 
 

因为所有的零件都在一个 multipart / mixed / code>，它们是连续显示的，而不是替代方案。因为 text / plain 和 multipart / related 不是同一个 multipart /替代，邮件代理不知道他们是彼此的替代品。 text / plain 没有其他替代方法， multipart / alternative 只有一部分。 p>



由于 multipart / related 部分不包含图像，将会有邮件代理无法放置图像正确的HTML内。另外，由于这个原因，图像可能是连续显示的或作为附件 - 它独立存在，与其他任何东西无关。

所以你必须重新排列你的消息，以符合正确的层次结构以替代工作，并使图像与HTML正确相关。

I'm trying to send nice MIME emails, where html will be displayed whenever possible, and when not possible it should have a textual fallback.

That is, when html contains an image, the "alternative" part should show "img ... should be here".

The problem is that I see everything, also the alternative, in gmail.

Is there something wrong with my MIME message?

Here's the content:

Content-Type: multipart/mixed; boundary="===============9061258228856181354=="
MIME-Version: 1.0
From: [e-mail] <[e-mail]>
To: [e-mail]

--===============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==--

Notes: The image code was cut just so its not huge code. Again, simply the goal is to show a fallback for non-html readers, which should have a different message than the html message. A capable mailer should NOT show the alternative message, right?

解决方案

Basically, your mail is not arraged correctly. There are a few ways to arrange the parts in a MIME message so that they make sense to a mail agent. Let's start from the simple and go through to the complicated option:

---

The simplest of all is text with a few attachments. For example, you want to send your CV to someone, So you write a few words of introduction and attach one or more document (cover letter, CV):

mime───multipart/mixed─┬─text
                       ├─attachment1
                       └─attachment2

Multipart/mixed means that the e-mail agent will show the parts serially - one after the other.

• If the attachments' content-disposition is inline, and the e-mail agent is capable to show the given attachment type, then it will be shown inside the message itself - at its end.
• If the attachments' content-disposition is attachment, they will usually be shown as some sort of icons or links for saving the attachments.

---

If you want to send a pretty HTML message, it is customary to include both a plaintext version and an HTML version. This is so that the recipient may be able to read it even in an e-mail reader that doesn't support HTML. You need to use multipart/alternative:

mime───multipart/mixed─┬─multipart/alternative─┬─text/plain
                       │                       └─text/html
                       ├─attachment1
                       └─attachment2

So, again, the message content includes three parts, the body and the two attachments. But the body itself is a multipart/alternative, and it contains the plaintext version and the HTML version. Remember to put the plaintext first, and the HTML second, as the convention is for the mail agent to pick the last alternative that it knows how to display.

The attachments are going to be displayed serially after the body, just like before, because they are the next parts in the main level, which is multipart/mixed.

---

Now let's look at a mail that doesn't have "attachments", but it does have images that are supposed to be embedded inside the HTML. In this case, the mail agent needs to know that the attachments are not just files sent over to the reader to be downloaded, but that it should display them in association with the HTML. So the correct mime type for that is multipart/related, to show that the parts are related. In this case, you also need to give them proper content IDs, and use those content IDs in the HTML. This is not part of the MIME standard, but it's how HTML mail is usually done these days.

As far as MIME is concerned, such a message will look like:

mime───multipart/alternative─┬─text/plain
                             └─multipart/related─┬─text/html
                                                 ├─embedded image 1
                                                 └─embedded image 2

This time we don't have attachments, so we can put the multipart/alternative as our top level content. It has the plaintext alternative first, like before, but the second alternative is itself a MimeMultipart("related").

Inside it, you have the HTML part, and the two images. The HTML and its images must always be parts of the same multipart/related object.

---

Now, what if you wanted to attach your document to such a message, one that has HTML and images inside it? Then you would be using something like this:

mime───multipart/mixed─┬─multipart/alternative─┬─text/plain
                       │                       └─multipart/related─┬─text/html
                       │                                           ├─embedded image 1
                       │                                           └─embedded image 2
                       ├─attachment1
                       └─attachment2

So your top level object is multipart/mixed, allowing you to add attachments serially to your message. The message "body" (the first part of the multipart/mixed) is the complex structure of multipart/alternative with an embedded multipart/related. And then the other attachments follow that.

---

In summary:

• A multipart/mixed message has a first part which is supposed to be your readable message, and the rest are attachments. All parts will be shown by the reader's mail agent.
• A multipart/alternative message gives different display alternatives of the same content, ordered from most common denominator to most rare presentation type (e.g. plain text→HTML→rich text→proprietary formatting) and the recipient's mail program picks the last one that it knows how to display. You see only one of the alternatives.
• A multipart/related message is usually used to combine an HTML body with its inline messages. The first part is the HTML, the other parts have Content-IDs that the HTML uses for its <img src="..." /> tags.

---

Now let's look at your own hierarchy, based on the boundary strings. Your outermost level is a multipart/mixed with the boundary ===============9061258228856181354==. If you look for all the places that this border appears, you'll see that there are three parts to this multipart/alternative.

The first part is:

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==--

This part is a multipart/alternative, but it only has one alternative part - whose content type is text/plain.

The second part is:

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

So it's an image.

The third part is:

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==--

Well, it's a multipart/related. But it only has one part - the text/html message. The image is not part of it.

So instead of having the following hierarchy, which is the appropriate one for what you described (text plain and html alternatives, the html part having an embedded image)

mime───multipart/alternative─┬─text/plain
                             └─multipart/related─┬─text/html
                                                 └─embedded image

You have this wrong hierarchy:

mime───multipart/mixed─┬─multipart/alternative───text/plain
                       ├─image
                       └─multipart/related───text/html

Because all the parts are in a multipart/mixed, they are displayed serially, not as alternatives. Because the text/plain and the multipart/related are not parts of the same multipart/alternative, the mail agent is not aware that they are alternatives to each other. It sees no other alternative to the text/plain, there is only one part in that multipart/alternative.

Because the multipart/related part does not contain the images, there will be mail agents which will fail to put the image inside the HTML properly. Also, because of this, the image is probably shown to you serially or as an attachment - it stands alone and not related to anything else.

So you have to rearrange your message to conform to the proper hierarchy for the alternatives to work and for the image to be properly related to the HTML.

这篇关于试图发送“替代”与MIME，但它也显示在有能力的邮件客户端的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！