GMail显示纯文本电子邮件，而不是HTML
我的Rails 3应用程序发送纯文本和HTML格式的电子邮件。 我已经在本地使用RoundCube和Squirrel Mail客户端进行了testing，他们都显示带有图片，链接等的HTML版本。另一方面，GMailselect纯文本格式。 任何想法是什么造成这个？
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.229.211.138 with SMTP id go10mr1544841qcb.195.1299200507499; Thu, 03 Mar 2011 17:01:47 -0800 (PST) Return-Path: <info@example.com> 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 info@example.com) 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 info@example.com) smtp.mail=info@example.com Received: from localhost.localdomain (localhost [127.0.0.1]) by beta.example.com (Postfix) with ESMTP id F3C273A3EC for <test@gmail.com>; Fri, 4 Mar 2011 01:01:45 +0000 (UTC) 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.comhttp://img.dovov.comlogo.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-- 尝试切换消息部分的顺序，将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 <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.
