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

发布于 2024-10-20 15:12:48 字数 4042 浏览 4 评论 0原文

我的 Rails 3 应用程序以纯文本和 HTML 格式发送电子邮件。我已经使用 RoundCube 和 Squirrel Mail 客户端在本地对其进行了测试，它们都显示带有图像、链接等的 HTML 版本。另一方面，GMail 选择纯文本格式。知道是什么原因造成的吗？

Received-SPF: neutral (google.com: 69.123.123.123 is neither permitted nor denied by best guess record for domain of [email protected]) client-ip=69.123.123.123;
Date: Fri, 04 Mar 2011 01:01:45 +0000
From: [email protected]
To: [email protected]
Message-ID: <[email protected]>
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: <[email protected]>

<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: <[email protected]>

Congratulations, Test!

Your example.com account was activated.

----==_mimepart_4d7039f9e6967_3449482ab7831370--

原文

My Rails 3 application sends out emails in both plain text and HTML formats. I have tested it locally using RoundCube and Squirrel Mail clients and they both display HTML version with images, links, etc. GMail on the other hand chooses plain text format. Any idea what's causing this?

Delivered-To: [email protected]
Received: by 10.42.166.2 with SMTP id m2cs16081icy;
        Thu, 3 Mar 2011 17:01:48 -0800 (PST)
Received: by 10.229.211.138 with SMTP id go10mr1544841qcb.195.1299200507499;
        Thu, 03 Mar 2011 17:01:47 -0800 (PST)
Return-Path: <[email protected]>
Received: from beta.example.com (testtest.test.com [69.123.123.123])
        by mx.google.com with ESMTP id j14si1690118qcu.136.2011.03.03.17.01.46;
        Thu, 03 Mar 2011 17:01:46 -0800 (PST)
Received-SPF: neutral (google.com: 69.123.123.123 is neither permitted nor denied by best guess record for domain of [email protected]) client-ip=69.123.123.123;
Authentication-Results: mx.google.com; spf=neutral (google.com: 69.123.123.123 is neither permitted nor denied by best guess record for domain of [email protected]) [email protected]
Received: from localhost.localdomain (localhost [127.0.0.1])
  by beta.example.com (Postfix) with ESMTP id F3C273A3EC
  for <[email protected]>; Fri,  4 Mar 2011 01:01:45 +0000 (UTC)
Date: Fri, 04 Mar 2011 01:01:45 +0000
From: [email protected]
To: [email protected]
Message-ID: <[email protected]>
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: <[email protected]>

<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: <[email protected]>

Congratulations, Test!

Your example.com account was activated.

----==_mimepart_4d7039f9e6967_3449482ab7831370--

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

始终不够爱げ你 2024-10-27 15:12:48

尝试切换消息各部分的顺序，将 HTML 部分放在纯文本部分之后。它可能会起作用:)。

注意：我现在不记得我在哪里读到过这篇文章（或者我什至不记得我是在哪里读到的）
做了），但切换可能有帮助的原因是因为我认为
消息的优选部分可以是最后部分。

更新：我发现一个地方说多部分 MIME 消息中的各部分应按优先级递增的顺序排列 - 此处，第 7.2.3 节（编辑：最新版本这里；谢谢 @ALEXintlsos！），从倒数第三段开始。

更新：这是第 7.2.3 节的引用，（请参阅https://stackoverflow.com/help/referencing ):

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 <[email protected]> 
To: Ned Freed <[email protected]> 
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.

Try switching the order of the parts of the message, putting the HTML part after the plain-text part. It might work :).

NOTE: I cannot remember now where I read this (or if I for sure even
did), but the reason switching might help is because I think the
preferred part of the message may be the last part.

Update: I found a place where it says that parts in a multipart MIME message should be in order of increasing preference -- here, in section 7.2.3 (edit: latest version here; thanks @ALEXintlsos!), starting with the third to last paragraph.

Update: Here is a quote of section 7.2.3, (see https://stackoverflow.com/help/referencing):

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 <[email protected]> 
To: Ned Freed <[email protected]> 
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.

回复收藏 0 原文

~没有更多了~