Email GMail显示纯文本电子邮件而不是HTML_Email_Html Email_Mime Mail

Email GMail显示纯文本电子邮件而不是HTML

Email GMail显示纯文本电子邮件而不是HTML,email,html-email,mime-mail,Email,Html Email,Mime Mail,我的Rails 3应用程序以纯文本和HTML格式发送电子邮件。我使用RoundCube和Squirrel邮件客户端在本地进行了测试，它们都显示HTML版本的图像、链接等。GMail则选择纯文本格式。知道是什么引起的吗 Delivered-To: test@gmail.com Received: by 10.42.166.2 with SMTP id m2cs16081icy; Thu, 3 Mar 2011 17:01:48 -0800 (PST) Received: by 10

我的Rails 3应用程序以纯文本和HTML格式发送电子邮件。我使用RoundCube和Squirrel邮件客户端在本地进行了测试，它们都显示HTML版本的图像、链接等。GMail则选择纯文本格式。知道是什么引起的吗

Received-SPF: neutral (google.com: 69.123.123.123 is neither permitted nor denied by best guess record for domain of info@example.com) client-ip=69.123.123.123;
Date: Fri, 04 Mar 2011 01:01:45 +0000
From: info@example.com
To: test@gmail.com
Message-ID: <4d7039f9e9d3e_3449482ab7831658@test.mail>
Subject: Your example account was activated.
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_4d7039f9e6967_3449482ab7831370";
 charset=UTF-8
Content-Transfer-Encoding: 7bit

----==_mimepart_4d7039f9e6967_3449482ab7831370
Date: Fri, 04 Mar 2011 01:01:45 +0000
Mime-Version: 1.0
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-ID: <4d7039f9e95ed_3449482ab7831519@test.mail>

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type" />
  </head>
  <body>
    <p><a href="http://example.com/"><img border="0" src="http://example.com/images/logo.png" alt="example logo" /></a></p>
    <p>Congratulations, Test!</p>
    <p>
      Your <a style="text-decoration:none;color:#ef4923;" href="http://example.com/">example</a> account was activated.
    </p>
  </body>
</html>

----==_mimepart_4d7039f9e6967_3449482ab7831370
Date: Fri, 04 Mar 2011 01:01:45 +0000
Mime-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-ID: <4d7039f9e8b0e_3449482ab78314b7@test.mail>

Congratulations, Test!

Your example.com account was activated.

----==_mimepart_4d7039f9e6967_3449482ab7831370--

交付给：test@gmail.com
收到日期：10.42.166.2，SMTP id为M2CS160811；
2011年3月3日星期四17:01:48-0800（太平洋标准时间）
收到日期：10.229.211.138，SMTP id为go10mr1544841qcb.195.12992005077499；
2011年3月3日星期四17:01:47-0800（太平洋标准时间）
返回路径：
收到：来自beta.example.com（testtest.test.com[69.123.123.123]）
通过mx.google.com和ESMTP id j14si1690118qcu.136.2011.03.03.17.01.46；
2011年3月3日星期四17:01:46-0800（太平洋标准时间）
收到的SPF:neutral（google.com:69.123.123.123）既不允许，也不被域名的最佳猜测记录拒绝info@example.com)客户ip=69.123.123.123；
认证结果：mx.google.com；spf=neutral（google.com:69.123.123.123）的域名最佳猜测记录既不允许也不拒绝info@example.com)smtp.mail=info@example.com
接收：来自localhost.localdomain（localhost[127.0.0.1]）
通过beta.example.com（后缀），ESMTP id为F3C273A3EC
对于2011年3月4日星期五01:01:45+0000（UTC）
日期：2011年3月4日星期五01:01:45+0000
发件人：info@example.com
致：test@gmail.com
消息ID:
主题：您的示例帐户已激活。
Mime版本：1.0
内容类型：多部分/备选；
边界=“-->=”mimepart_4d7039f9e6967_3449482ab7831370”；
字符集=UTF-8
内容传输编码：7bit
----==_mimepart_4d7039f9e6967_3449482ab7831370
日期：2011年3月4日星期五01:01:45+0000
Mime版本：1.0
内容类型：text/html；
字符集=UTF-8
内容传输编码：7bit
内容ID:

恭喜你，考

您的帐户已激活。

----==_mimepart_4d7039f9e6967_3449482ab7831370
日期：2011年3月4日星期五01:01:45+0000
Mime版本：1.0
内容类型：文本/纯文本；
字符集=UTF-8
内容传输编码：7bit
内容ID:
恭喜你，考！
您的example.com帐户已激活。
----==_mimepart_4d7039f9e6967_3449482ab7831370--

尝试切换消息部分的顺序，将HTML部分放在纯文本部分之后。它可能会工作：）

注意：我现在记不起我在哪里读到这篇文章（或者我是否确实读过这篇文章）是的），但切换的原因可能会有所帮助，因为我认为消息的首选部分可能是最后一部分

更新：我在第7.2.3节（编辑：最新版本；谢谢！）中找到了一个地方，上面说多部分MIME消息中的部分应该按优先顺序递增，从第三段到最后一段开始

更新：以下是第7.2.3节的引用（请参阅）：

7.2.3多部分/备选子类型
multipart/alternative类型在语法上与multipart/mixed相同，
但是语义是不同的。特别是，每个部分都是一个
相同信息的“替代”版本。用户代理应该识别
各部分的内容是可互换的。用户代理
应根据用户的环境和环境选择“最佳”类型
首选项，或向用户提供可用的备选方案。一般来说，选择
最佳类型意味着仅显示可以显示的最后一个零件。这
例如，可用于以这种方式以奇特的文本格式发送邮件
它可以方便地显示在任何地方：
发件人：纳撒尼尔·博伦斯坦
致：内德·弗里德
主题：格式化文本邮件
MIME版本：1.0
内容类型：多部分/备选；边界=边界42
--边界42
内容类型：文本/纯文本；字符集=美国ascii码
…此处显示的是纯文本版本的消息。。。。
--边界42
内容类型：text/richtext
.... 相同消息的richtext版本出现在这里。。。
--边界42
内容类型：text/x-where
.... 同一消息的最奇特的格式化版本出现在这里
... 
--边界42--
在本例中，其邮件系统理解“text/x-where”的用户
format只能看到花哨的版本，而其他用户只能看到
richtext或纯文本版本，取决于其系统的功能。
通常，组成多部分/替代实体的用户代理应该
按首选项的递增顺序放置身体部位，即使用
首选格式最后一个。对于花式文本，发送用户代理应将
最简单的格式在前，最丰富的格式在后。接收用户代理应
选择并显示他们能够显示的最后一种格式。在这种情况下
其中一个备选方案本身为“multipart”类型并包含
无法识别的子部件，用户代理可以选择显示
备选方案，早期备选方案，或两者兼而有之。
注意：从实现者的角度来看，反转似乎更明智
这种排序，并有最简单的选择最后。但是
最简单的选择首先是最友好的选择
使用不兼容MIME的邮件查看多部分/备选实体
读者虽然这种方法确实给合规的邮件阅读器带来了一些负担，
与旧邮件阅读器的互操作性被认为更重要
这个案子。
如果某些用户代理可以识别多个用户代理，则可能会出现这种情况
在这些格式中，用户更愿意选择哪种格式
看法例如，如果邮件包含格式良好的
图像版本和易于编辑的文本版本。然而，最关键的是，
是指不会自动向用户显示相同数据的多个版本。
应该向用户显示最后识别的版本，或者
你可以选择。

您发送电子邮件时使用的是什么标题（MIME类型）？Gmail允许您通过转到电子邮件，单击下一步的向下箭头来查看实际的电子邮件包数据

7.2.3 The Multipart/alternative subtype
The multipart/alternative type is syntactically identical to multipart/mixed, 
but the semantics are different. In particular, each of the parts is an
"alternative" version of the same information. User agents should recognize
that the content of the various parts are interchangeable. The user agent
should either choose the "best" type based on the user's environment and
preferences, or offer the user the available alternatives. In general, choosing
the best type means displaying only the LAST part that can be displayed. This
may be used, for example, to send mail in a fancy text format in such a way
that it can easily be displayed anywhere:

From:  Nathaniel Borenstein <nsb@bellcore.com> 
To: Ned Freed <ned@innosoft.com> 
Subject: Formatted text mail 
MIME-Version: 1.0 
Content-Type: multipart/alternative; boundary=boundary42 


--boundary42 
Content-Type: text/plain; charset=us-ascii 

...plain text version of message goes here.... 

--boundary42 
Content-Type: text/richtext 

.... richtext version of same message goes here ... 
--boundary42 
Content-Type: text/x-whatever 

.... fanciest formatted version of same  message  goes  here 
... 
--boundary42-- 

In this example, users whose mail system understood the "text/x-whatever"
format would see only the fancy version, while other users would see only the
richtext or plain text version, depending on the capabilities of their system.

In general, user agents that compose multipart/alternative entities should
place the body parts in increasing order of preference, that is, with the
preferred format last. For fancy text, the sending user agent should put the
plainest format first and the richest format last. Receiving user agents should
pick and display the last format they are capable of displaying. In the case
where one of the alternatives is itself of type "multipart" and contains
unrecognized sub-parts, the user agent may choose either to show that 
alternative, an earlier alternative, or both.

NOTE: From an implementor's perspective, it might seem more sensible to reverse
this ordering, and have the plainest alternative last. However, placing the
plainest alternative first is the friendliest possible option when
multipart/alternative entities are viewed using a non-MIME- compliant mail
reader. While this approach does impose some burden on compliant mail readers,
interoperability with older mail readers was deemed to be more important in
this case.

It may be the case that some user agents, if they can recognize more than one
of the formats, will prefer to offer the user the choice of which format to
view. This makes sense, for example, if mail includes both a nicely-formatted
image version and an easily-edited text version. What is most critical, however,
is that the user not automatically be shown multiple versions of the same data.
Either the user should be shown the last recognized version or should 
explicitly be given the choice.