Menu
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-- 
696
A simple way to switch between plain text and HTML message compose (without changing the default) is to hold the shift button when you click the "New Message" or "Reply" toolbar button. That will bring up the compose window the opposite style (plain or HTML) of the default.
How the message appears to the person receiving it depends on their email program. If the recipient's email program is set to convert messages, for example, then a message you send formatted as HTML could be converted to plain text.
By default, composing a new email in Gmail results in an HTML email under the hood — even if you don't use any formatting. Luckily, it's possible to opt-out of that and use plain text email instead. In the 'new email' window, click the downwards arrow and check 'Plain text mode'.
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. If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
