Tim Cracked The GMail - CFMailPart Puzzle!
My main man, Tim, just cracked the puzzling way that GMail handles multi-part emails. As I had posted before, if you send an email to GMail with a rich text (text/html) part and a plain text (text/plain) part, GMail would always ignore the richly formatted text part and show the plain text. It turns out, as Tim, shows me, the order of the CFMailPart tags are important. In all of my examples, I always put the text/html part first:
<cfmail
to="liz@girls-who-code.com"
from="emy@girls-who-code.com"
subject="Great Meeting!">
<!--- Send rich formatted part. --->
<cfmailpart type="text/html">
Hey Em, it was <strong>great</strong> meeting you at
the offices yesterday.
</cfmailpart>
<!--- Send plain text part. --->
<cfmailpart type="text/plain" wraptext="60">
Hey Em, it was great meeting you at the offices yesterday.
</cfmailpart>
</cfmail>
This worked for most email clients, but for the increasingly popular GMail, it would only show the plain text part! Well, as Tim pointed out, if you switch the order of the mail parts:
<cfmail
to="liz@girls-who-code.com"
from="emy@girls-who-code.com"
subject="Great Meeting!">
<!--- Send plain text part. --->
<cfmailpart type="text/plain" wraptext="60">
Hey Em, it was great meeting you at the offices yesterday.
</cfmailpart>
<!--- Send rich formatted part. --->
<cfmailpart type="text/html">
Hey Em, it was <strong>great</strong> meeting you at
the offices yesterday.
</cfmailpart>
</cfmail>
... such that the text/html part is second, GMail will indeed show the richly formatted version! This continues to work in MS Outlook as well. Thanks Tim, you just rocked my world!
Want to use code from this post? Check out the license.
Reader Comments
cfmailpart should be great, but then along comes blackberry and a client using Eudora 3.1 and all the rules go out of the windows because neither of those clients handles the mailpart tag correctly. i'm royally stuck now because our client is desperate to use HTML but some of the users just can't see it. Know any workarounds?
Ed,
While I do not know this for a fact, I heard someone one time talking about this type of issue. I think they came up with a solution that they put in the plain text content right into the emails (as if there were no parts) and then put a CFMailPart for HTML emails at the end. For clients that couldn't handle the mail part, they saw the text version and then clients that could handle it (and HTML emails) saw the HTML version.
Of course, I have NOT TESTED this, so take it with a grain of salt.
Thanks for the quick response Ben, I just tested the theory and it didn't work in Eudora. Then again we're talking about a main client so old that it predates any modern standards for emails! Oh well, I'll keep trying. Thanks again for your help.
Ed,
Is there anyway from the email address to tell if the user is using Eudora? If that is the case, you actually just send a different email to those users.
If not, I am out of suggestions. Sorry.
I wish! :-)
Excellent... If I weren't primarily a Gmail user, I probably wouldn't have even noticed this annoyance. Thanks for posting this for the Google spiders to find. :)
This helped me make an internal page, emailing the result to Groupwise. I had the html part first originally and text part second. The emails I got were showing up fine in html format but it had this wierd attachment part.001 which was the text portion.
By switching the order and making the text first, it still achieved what I wanted, which was to show the html part first with no attachments and then also have a text part if the user was viewing text only
One more scenario for fun:
If you have a cfmail tag with one cfmailpart in it of type HTML - Gmail renders empty text, noice!
@David,
Ugg, that is lame. I wonder, do we even care about plain text emails anymore. The only thing I could ever think about was something like a Blackberry. But I assume that by now, even the Blackberry has rich text email capabilities?
So, no one is using the type="html" attribute of the cfmail tag? Not enough control?
@Mik,
I use the type="html" most of the time. I only worry about this when I have a non-html version to offer (which, I spend less and less time worrying about).
True enough.
I've been wrestling with the CFMAIL tag and CFMAILPARTS for several days now and have found issues with the CF implementation even in CF9!
What I have learned so far is:
1. Using only one CFMAILPART for a text-only email will result in no content for many email clients (Gmail, AOL, Apple Mail, etc) but not MS Outlook. Trial and error found the message goes out with TWO bodypart sections in the raw text message of the email (I would grab a copy in the CF Mail spool folder before it disappeared into the ether amd look at it.) The first bodypart had the text content. The second was empty. Both bodypart sections owere of type plain text. Obviously those mail clients seeing nothing were looking at the second bodypart section containing nothing.
SO if you need to send only a text email, don't use CFMAILPARTs at all. Simply use the CFMAIL tag alone.
If you do need to send both text and html content, then use two CFMAILPART tags, putting the text section first followed by html section. My understanding on this is that mail clients want to see the simple content first and then go to the progressively more sophisticated content (html) second so clients that don't understand HTML can ignore it is my guess.
2. WRAPTEXT parameter CFMAIL tag or CFMAILPART tag appears to do wacky things when it comes to line break placement in text emails. I have content with no line breaks except at the end of paragraphs or colons, or after lines in a mailing address, etc. Again looking at the output CF produces and places in the mail spool folder shows almost random line breaks on some content.
I specified 60 as my width and an address that has our company name on it's own line...
Lattice Semiconductor Corporation
had a line break placed at...
Lattice
Semiconductor Corporation
I can't explain this behavior. It occurred on a few other normal sentences. Like this one...
Please add
the following email address...
Why did it split the line after "Please add"?
Then there is MS Outlook 2007... it seems to interpret text email content on it's own terms. Taking a text email msg with line breaks in it carefully placed would get ignored by Outlook except when the line breaks follow punctuation and interestingly, all three lines of a standard US mailing address. But everywhere else it would remove the line breaks and go full window width.
I share all this out of frustration with dealing with MS Outlook's lack of control on text content and with dealing with what I would consider bugs in CF9 (and prior) in dealing with wraptext in cfmail tag and use of one cfmailpart tag.
@Bruce Holm,
Nice. This explains why some people reply with "email was empty" to me. Good work!
@Mik Muller, Exactly what I was encountering... complaints of empty emails. I'm really surprised no one else has reported this anywhere. I realize text emails may seem old school but there are a lot of people out there who still prefer it over the "heavier" HTML email content. So we give our users the preference setting, HTML or Text. If they select Text they get a text email message sent to them. Sometimes we choose to send text email only, to everyone. Then again this comes into play.
Glad to hear this discovery helps others.
@Bruce, @Mik,
Out of curiosity, what email clients are you targeting with text-only emails? I am starting to think that the whole html vs. text debate is somewhat outdated. I am wondering if having text-only versions of emails is really adding any value these days.
Things to consider: smart mobile devices. I used to think that text-only emails would be good for old-school BlackBerrys. But I think most all smart devices handle html formatting well.
Disabled people: I think there was a feeling that visually disabled people can only handle text-only emails; but, I have to believe that in today's times, visually disabled people have email clients that handle text-to-voice (or whatever translation happens) in a "smart" manner.
I am not sure who the text-only emails are really for anymore.
Ben,
I've been using the straight type="HTML" for a while, and every once in a while someone replies back with "email was empty." Others complain that the email was entirely on a blue background and they couldn't read the text. So I am considering parting the mail and hoping this fixes the issue for some of these people. Some of the people complaining are using Outlook.
To be honest, I haven't spent much time thinking about it. I figure, if they're having trouble with my emails, they must be having trouble with others, and if by now they haven't changed email programs, there's not much I can do for them, and I'm not sure I'm willing to jump through hoops for them. The way I figure it, they don't sell leaded gas anymore. It's 2010.
That said, lots of people use Gmail. So, unless Adobe fixes the type="HTML" attribute by switching the order of the parts, I guess I have to bite that bullet.
Ben,
From my research there are reasons for sending out email with a text content part in them because there are still some folks who only want text email. For one it's their way of filtering out spam emails which are almost always in HTML format. For a whole discourse on HTML vs Text email check out http://mailformat.dan.info/body/html.html
We have web accounts on our site for visitors to create that provides additional content not available to those who don't, such as software downloads. We want to know who is downloading software. We decided to let people select their preference, HTML or Text emails. If someone chooses Text then why send them an HTML and Text email where the HTML portion with all it's CSS and tag markup is often 2x if not up to 4x the size of the text portion. If someone doesn't want HTML then send them the lite email which will take up less space on the internet and on the servers storing it.
In our code the user preference or the marketing decision to send only text out to everyone results in a cfmail tag that has no cfmailparts in it. However if the user is ok with HTML emails then they get a cfmail tag with two cfmailparts in it for HTML and Text, text going first. Then if they happen to be reading the message on a reader that doesn't handle HTML well (list server, forums, forwarded email) then the text portion will be valuable. As the article referenced above states, some mail clients will strip out the HTML portion so if there was no text part, you'd end up with nothing.
So I think sending two parts is a minimum. Giving the user the option of opting for text only saves bandwidth and frustrated (dwindling numbers of change resistant) users is a bonus.
You may be right, maybe there is no need for a single cfmail text only message. If anyone reading this decides to send only text, just don't use cfmailpart tag due to what I call a CF bug... it will end up an empty email msg on many readers.
I should have added that about 5% of our database of opt-in accounts in the past couple years have chosen Text. The default is HTML email if they don't choose.
@Bruce Holm,
> So I think sending two parts is a minimum.
> Giving the user the option of opting for
> text only saves bandwidth [and storage]
How does sending two cfmailparts with both an HTML version and a text-only version save bandwidth and storage? I'm not trying to be argumentative, but it sounds like sending both types in a single email doubles or triples the size of the email.
If they request text-only, why not send a cfmail with not type=?
If they request HTML, then send both, in case their reader can't handle it.
@Mik Muller, That is exactly what I was trying to say Mik. We send two mailparts if they ask for HTML, else if they specify text, then I just use cfmail with no cfmailpart. Sorry if I wasn't clear.
@Bruce,
I wonder if people opt-in for TEXT-only emails because they "think" there will be a huge difference. It's like regular milk and low-fat milk. The difference is only 1%, but people feel that low-fat is way different.... OK, that's a really bad analogy. But, my question is - if you sent only HTML without any opt-in, I wonder if the people who would normally opt for text only would even care?
It's actually an interesting social question about the desire for text-only?
@Ben Nadel, our default is HTML so it takes a deliberate decision on the part of the user to select text format. I think you risk irritating the user if you send them HTML anyway. Only the email clients out there that are set to accept text would see the text part (if you sent both HTML and text parts) else they'd see the HTML. I figure the few dozen extra lines of code to send them text only upon their request is a small price to pay.
I think the real issue here not being addressed is that CF has a couple bugs that are not being addressed for several major releases. FWIW, I also found a similar bug in their WRAP function. It doesn't wrap where you'd expect when used with email content between the cfmail tags.
@Bruce,
I guess if people are actively selecting the text-only version, then the desire really is out there. It just seems like such a foreign concept to me. Typically, I find HTML emails easier to read because they can use more controller format and "texture" to point out relevant / important information.
I guess to each their own.
my client has complained of receiving blank invoices via apple email/iphone. initially i only used the type = html mailpart. by now including...
<cfmailpart type="text/plain" wraptext="60">
You are receiving this email in plain text format, please change your email application preferences or contact the site administrator.
</cfmailpart>
first, they now receive in the desired html format. thanks for the tips guys.
@Mike,
Sounds good; have you noticed better responses with this email addition?
Hey, great tips here. I was just trying to figure out why my multipart emails weren't working in gmail. They were part text and part iCalendar/vCalendar. When I switched the order (ical text and then the body text), it worked great.
Just note that this works for other multipart emails, not just text/html.
Thanks!
@Tony,
Very cool - I was not aware that you could send calendar-type emails in CFMail. I've heard of people integrating with iCal and what not; but I've never actually seen it for myself. Thanks a lot for passing this along!
@Ben: Brilliant! Thanks for posting this about GMail multipart orders. Very helpful.
@James,
Glad this helped :)
Need help.....Am trying to send an outlook invite through cfmail....Each time the mail is recieved without the calendar invite.empty mails with just the subject being shown..have tried all the tricks....help/advise me...
While this may be an old post it was very helpful this morning as I discovered that Thunderbird users have the same problem as Gmail users. If both text and html mail parts are included but the html part is first in the mix it only displayed the text component. I am sending out purchase confirmations and haven't spent much time with the text component assuming (like others) that the majority of the recipients would be reading it in HTML. Once I flipped the order the pretty HTML part came through fine. Now to remember to always put text first ... :) Thanks for the helpful entry, appreciate it.
I'm using cfmail parameters to send an email to iPhone client. The email is received when I send it as cfmailpart type = text/html. However there is an often a block of text queried from a SQLServer db table that's formatted like this:
snip
3 (15.8-ounce) cans black-eyed peas
1 (10-ounce) can diced tomatoes and green chilies
1 small onion, finely chopped
By the time the user gets it in the email it looks like this:
snip
3 (15.8-ounce) cans black-eyed peas 1 (10-ounce) can diced tomatoes and green chilies 1 small onion, finely chopped
Can someone please tell me why I cannot get the paragraph/line breaks to stay in the email? Ic an copy and paste it and send it in my email fine. I can see it on the website fine...it just never gets to the IPhone or to MSOutlook as it's formatted with the paragraphs/line breaks. Thanks much!
Found a solution for the above issue of cfmailpart not handling the paragraph or linefeed - end of lines correctly. We set a variable like this: <cfset VarMessage = #replace(qry.message,Chr(10),"<br>", "all")#>
<cfset VarMessage2 = #replace(VarMessage,Chr(13),"<br>", "all")#>
and then used the http://cookbooks.adobe.com/post_CFMAIL_the_right_way-17875.html
method recommended here to handle the rest of the email. It worked like a charm...but oh boy, I worked on this one for a week!
Thanks for the support.It is truelly appreciated.Please do ascertain out the web site and conjointly facebook ,same title and gaze below pics.Also,please do contemplate approaching to the search.What the Treasury does to bonds crossword puzzle . Then we will collect all the require information and for solving What the Treasury does to bonds crossword . http://mordo-crosswords-solution.blogspot.co.il/2013/12/what-treasury-does-to-bonds.html