Email client support - what is reasonable

jetcitywoman

I don't have a WTF to report right now, but a question for you guys. I noticed recently that we have someone here who has worked on email systems, like for marketing and such. My team is struggling to draft/send HTML/Mime emails supported by the most popular clients. From the Litmus website, I got this info:

Email client<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>	Market share<o:p></o:p>
Outlook<o:p></o:p>	43%<o:p></o:p>
Hotmail<o:p></o:p>	17%<o:p></o:p>
Yahoo! Mail<o:p></o:p>	13%<o:p></o:p>
Gmail<o:p></o:p>	5%<o:p></o:p>
Apple Mail<o:p></o:p>	4%<o:p></o:p>
iPhone<o:p></o:p>	4%<o:p></o:p>
Thunderbird<o:p></o:p>	2.40%<o:p></o:p>
Windows Live Mail (Desktop)<o:p></o:p>	2%<o:p></o:p>
AOL Mail<o:p></o:p>	1.20%<o:p></o:p>
Lotus Notes<o:p></o:p>	0.40%<o:p></o:p>
Others<o:p></o:p>	8%<o:p></o:p>

I'm sure it actually depends on what kind of email you're sending as well as the customer demographic. But overall, what do you feel is reasonable to support? I suggested to our biz team that we cut off support between Yahoo and Gmail. They countered by asking us to support all the way down to Thunderbird.

By "support" I mean make sure that the emails we send look good in those email clients.

serguey123

@jetcitywoman said:

Email client
Market share Outlook 43% Hotmail 17% Yahoo! Mail 13% Gmail 5% Apple Mail 4% iPhone 4%Others 8%

Anything else is small fry, pay attention to that Other category, it seems to have a huge marketshare

dhromed

@jetcitywoman said:

I suggested to our biz team that we cut off support between Yahoo and Gmail. They countered by asking us to support all the way down to Thunderbird.

You should make a second list based on the capabilities of each.

Thunderbird, for example, has a fully-featured HTML parser and will only block remote images by default. It is relatively trivial to support Thunderbird and its usage percentage is not a factor in the decision. Others will have varying degrees of CSS support, stripping and imageblocking. Outlook-Webaccess and Gmail are notorious strippers and will turn your baroque marketing email into near-plaintext mush.

Your best bet, always, is to use tables (party like it's 1999), be very light on images, and embed some images if you can, to prevent blocking.

Edit

I once, long ago, put a local stylesheet into an email, and sent it to hotmail. The stylesheet was this:
* {
border:10px dotted #f0f !important;
}

Hotmail didn't strip it. It was like a small Christmas.

PJH

@jetcitywoman said:

But overall, what do you feel is reasonable to support?

Plain text emails.

(More seriously, most HTML emails I've bothered noticing seem to look reasonable in gmail, so I think if you get those above it OK, it should be alright in gmail.)

rad131304

These are the resources I've used in the past to handle html mailers

Some things I noticed in my experience: never put anything in the <head> section. You can include style blocks, but you need to put them in the <body> section. You cannot overlap text on images; if you want them combined you've got to embed the text in the image. IE and Outlook are particularly annoying - the trident engine doesn't always like to play nice with colors.

I generally also use the following wrapper to center the mailer:

<center>
    <table style="margin: 0px auto; text-align: left;">
        <tr>
            <td>
                stuff goes here
            </td>
        <tr>
    </table>
</center>

jetcitywoman

I should add that email is not our forte... Okay, I lied earlier, there is a WTF here. We're trying to take HTML emails drafted by anybody - web design folks in various marketing teams as well as outside consultants - and import them into our home-grown email system. Our system sucks them in and converts them to Mime encoding. I don't have the technical details for that, since I'm a BA. I am worrying why we're reinventing the wheel when other companies who DO EMAIL FOR A LIVING do it better, but.... I'm just the BA.

My frustration aside, our business teams both look to us for best practices but also push back and want the world. (So what's new in IT?) We lack the domain expertise (the email business domain) to do this. I was hoping for a blue pill, I think. :-)

But essentially, what we DON'T do is draft the HTML. Just make sure it looks the same going out as it did going in.

rad131304

@jetcitywoman said:

I should add that email is not our forte... Okay, I lied earlier, there is a WTF here. We're trying to take HTML emails drafted by anybody - web design folks in various marketing teams as well as outside consultants - and import them into our home-grown email system. Our system sucks them in and converts them to Mime encoding. I don't have the technical details for that, since I'm a BA. I am worrying why we're reinventing the wheel when other companies who DO EMAIL FOR A LIVING do it better, but.... I'm just the BA.

My frustration aside, our business teams both look to us for best practices but also push back and want the world. (So what's new in IT?) We lack the domain expertise (the email business domain) to do this. I was hoping for a blue pill, I think. :-)

But essentially, what we DON'T do is draft the HTML. Just make sure it looks the same going out as it did going in.

You might be able to use the information at http://www.email-standards.org/. Basically it will tell you what is supported and what is not in each client. If you "AND" the supported features across the clients you want to support, that will give you the answer of what submitted html documents to accept or reject. I'm assuming at this point that you're using your homegrown email system as a gatekeeper? I'm sorry if I'm not helping but I'm not really understanding what you're trying to accomplish.

jetcitywoman

Yeah, that's a good way to put it, our home-grown system is a gatekeeper. We mangle the source code and image files provided by marketing into one MIME file that's stored in an Oracle database. (Yeah, I know.) When business needs the email to be sent to a customer, our system pulls it from the DB, fills in variable information ala mailmerge, and sends the email through our Exchange server.

The WTF that I see is that we have coded (and are debugging) that massage-into-MIME bit. I don't like the way they do it, but I don't get to see the code to know if they're doing it right or not. I do know they have sooooooo much trouble making it work correctly. We have a small set of templates that we've been working on for about 2 months now, massaging the html, twiddling the conversion routines, passing them through GMAIL, copy-pastaing view source, you name it, trying to make them work correctly. My requests for a list of "approved" html tags goes un-answered. They don't know why they don't work. Business is being patient, but I find it excruciatingly embarrassing.

Mass marketing email companies have drag and drop template design capabilities and their results seem pretty consistent, so it's a source of increasing frustration for me that we're not using one of them. We may move that way in the future, but until then I gnash my teeth. But then, I probably take things like quality wayyy too seriously. My coworkers don't seem at all embarrassed.

zzo38

Send plain text message; it should be supported with everything, including the UNIX "mail" program. (You could have an option for HTML or plain, which the user can select if they opt-in, if it is opt-in.)

rad131304

@jetcitywoman said:

Yeah, that's a good way to put it, our home-grown system is a gatekeeper. We mangle the source code and image files provided by marketing into one MIME file that's stored in an Oracle database. (Yeah, I know.) When business needs the email to be sent to a customer, our system pulls it from the DB, fills in variable information ala mailmerge, and sends the email through our Exchange server.

The WTF that I see is that we have coded (and are debugging) that massage-into-MIME bit. I don't like the way they do it, but I don't get to see the code to know if they're doing it right or not. I do know they have sooooooo much trouble making it work correctly. We have a small set of templates that we've been working on for about 2 months now, massaging the html, twiddling the conversion routines, passing them through GMAIL, copy-pastaing view source, you name it, trying to make them work correctly. My requests for a list of "approved" html tags goes un-answered. They don't know why they don't work. Business is being patient, but I find it excruciatingly embarrassing.

Mass marketing email companies have drag and drop template design capabilities and their results seem pretty consistent, so it's a source of increasing frustration for me that we're not using one of them. We may move that way in the future, but until then I gnash my teeth. But then, I probably take things like quality wayyy too seriously. My coworkers don't seem at all embarrassed.

I feel for you; essentially, the html email standards link will tell you what is and is not supported, but building a system to test all of the permutations will be time consuming and the end result will probably be a system that will annoy the crap out of your users telling them they are a failure because html email sucks. a lot.

ekolis

If you want to make it look the same across all mail clients, how about just taking what your designers created and slapping it in a PNG? Of course then you'd probably run into all sorts of issues with blind accessibility... :/

jetcitywoman

@rad131304 said:

You might be able to use the information at http://www.email-standards.org/. Basically it will tell you what is supported and what is not in each client. If you "AND" the supported features across the clients you want to support, that will give you the answer of what submitted html documents to accept or reject.

Thank you, that's an interesting link. I only looked at it briefly so far, but it gave me another idea: as a business analyst, I need to manage expectations from the business teams. Perhaps as part of each campaign requirements, I should ask them (whoever designed the emails) to provide some evidence that they tested it against some list of clients, then my team will support that same list of clients. I have a feeling right now that they double-click the .html and call it good if it looks good. Which of course it does because browser support for html is wayyyy above email client support.

Or in other words, instead of my team making some arbitrary proclamation that we'll support x, y, and z clients, we make the business teams tell us what to support but also provide proof that their work has already been tested.

jetcitywoman

@ekolis said:

If you want to make it look the same across all mail clients, how about just taking what your designers created and slapping it in a PNG? Of course then you'd probably run into all sorts of issues with blind accessibility... :/

Along with the suggestion to use plain text.... no can do. We're also being asked to provide analytics: how many emails are opened, deleted, links clicked on, etc. Remember guys, this is MARKETING. They're giving us html so that they can have pretty designs with company logos, lots of hyperlinks and whatever. (We're using a 3rd party tool for the analytics.)

Coyne

@dhromed said:

Your best bet, always, is to use tables (party like it's 1999), be very light on images,

I second that part. I haven't had to deal with anything other than Outlook 2007, and only simple messages at that, but that 2007 client doesn't respond at all to DIV (appears to ignore it completely).

I suspect that by the time you get down to Yahoo, you'll find that everything is pretty decently supported anyway.

PJH

@jetcitywoman said:

Along with the suggestion to use plain text.... no can do.

You do realise that even if you are sending an HTML email, there should be one of those multi-parts that is plain text? Even if it's the HTML version stripped of all HTML tags. Or a "this email is best viewed in MicroFox Mail Exploiter 55.6.2, or visit <http://www.example.com/mail/20120916?user_id=12345> to view the message online" message.

jetcitywoman

Yes, but we're too busy right now fighting to make these html templates render properly, no time as of yet to add the text part to our conversion routine. I know this sounds stupid. We don't have time to do it right, just time to do it over. And over. And over.

Cassidy

@PJH said:

visit <http://www.example.com/mail/20120916?user_id=12345> to view the message online" message.

Beat me to it. It's easier to have HTML pages render in a browser than in a mail client.

I also read somewhere that image-blocking features of some mail clients skew analytics; people rarely block images or tracking cookies in browsers. Blakey will know more on that one, I suspect.

zzo38

@PJH said:

@jetcitywoman said:
Along with the suggestion to use plain text.... no can do.
You do realise that even if you are sending an HTML email, there should be one of those multi-parts that is plain text? Even if it's the HTML version stripped of all HTML tags.

Yes, that is one of the things you can do. However, probably shouldn't necessary be just the HTML version stripped of all HTML tags; depending on what HTML tags you are using, it might be better reformat the line breaks and stuff in the plain text version.

Oh God , don't envy you in this - we tried to do it here and it turned into a nightmare .

Tracking open emails - utterly useless stat as you have to use a small image to check whether it was downloaded or not - doesn't work as a lot of emial clients don't download images automatically and often folk just preview the mail before deleting - so as a stat uttlerly pointless .

We had requests to find out what email client the reciever had and SEND email appropriate to that client (um it doesn't work that way)

ISP's often greylist or just block emails from unknown senders , so you have to go get on some magic list that allows you to spam follk. (In Europe - Polish ISP's are really hot on blocking Spam. )

Over here (don't know the situtation in the US ) you have to manage permissions to send very carefully - Germany are really strict about it and its getting worse . And there are cases of folks trying it on to get a payout .

The system we used was um tempremental at best when handling Cyrillic characters , to the point some emails would work while others would turn into a gloopy mess of html - not being able to read Russian meant we didn't have a clue so had to get a russian worker to check it over before sending and even then it would go poof! at the drop of a hat.

Handling Click-through's is a pain and basically you need to have 24/7 uptimes. for those parts .

And at the end of the day the Marketing dept will want to send emails to everyone and their dog immediately and get stats totally impossible to collate and expect emails not to take time to process .

Anyway good luck . My advice - pay some company to sort that mess out .

jetcitywoman

Thank you, we've seen everything you mention also, and I think that what we're going to do is integrate with one of the third party email marketing companies and let them sort out the hairball. It will take time to negotiate contracts and such, but that's the light at the end of my tunnel. For the immediate project, I was able to talk the stakeholder (biz guy invested in the project) into just accepting what we have now and then addressing the issues when we hire the 3rd party outfit. Score one for me.

@UriGagarin said:

We had requests to find out what email client the reciever had and SEND email appropriate to that client (um it doesn't work that way)

Yesterday I had a similar request, but with phone calls. I was asked that we send calls that require feedback (press 1 to <do whatever>) to customers who'll answer the phone and send calls that don't require feedback to customer's answering machines. Umm.... sure. You tell me how to do that and we'll do it. LOL

Cassidy

@UriGagarin said:

Tracking open emails - utterly useless stat as you have to use a small image to check whether it was downloaded or not - doesn't work as a lot of emial clients don't download images automatically and often folk just preview the mail before deleting - so as a stat uttlerly pointless .

Agree (as mentioned up there somewhere), which is why providing a (trackable) link to a website and using visitor stats can usually be more accurate.

@UriGagarin said:

ISP's often greylist or just block emails from unknown senders , so you have to go get on some magic list that allows you to spam follk.

That's not a problem with HTML mail, that's a problem with mail policies on the recipient mail server. Usually there will be some opt-in process, so the mail shouldn't come from an unknown sender. Or did you mean unresolvable domain in the sender field? In which case it's malformed mail.

@UriGagarin said:

In Europe - Polish ISP's are really hot on blocking Spam.

Blocking it when it's received, maybe. They don't seem too hot on sending or relaying it.

@UriGagarin said:

don't know the situtation in the US

There's the CAN-SPAM act. Despite this, the USA seems to be constantly on the top of the list of worst spammers - but that's primarily because spammers originating in the USA send spam to non-US addresses or host spam servers in places like China and Korea where they aren't too proactive about kicking customers off for spamming. As long as the hosting company gets paid, they're happy to ignore spam reports.

@UriGagarin said:

Handling Click-through's is a pain and basically you need to have 24/7 uptimes.

Most mail and web servers are generally 24/7, and there's also redundancy measures to ensure the service is available 24/7, even if a server is not (backup MX record, DNS pooling, etc).

@UriGagarin said:

Anyway good luck . My advice - pay some company to sort that mess out .

They did.

Her.

Ach its 3 years since we did all this so I've probably forgotten all the details -

>That's not a problem with HTML mail, that's a problem with mail policies on the recipient mail server. Usually there will be some opt-in process, so the mail shouldn't come from an unknown sender. Or did you mean unresolvable domain in the sender >field? In which case it's malformed mail.

Meant the ISP blocked the email at their end from being delivered to their users inboxes .- nothing to do with HTML mail as such , just relaying the problem . You basically have to register the IP of the sending machine (or something, wasn't too involved with the details there) to make it a known email channel .

>@UriGagarin said:

don't know the situtation in the US

I meant managing the opt in and out of the emails - Germany has rules that any unsolicited email can be sued over and they enforce it . I was wondering how that is handled and what the responsibilities of the sneder are.

24/7 thing was just that marketing don't think beyond their noses half the time , so if they want genuine 24/7 and uptimes - it costs . If they ain't bothered about it being down every now and again then forget it .

my advice stands , pay someone else - you just end up hand holding them everytime an email doesn't get delivered, trying to chase it down and continually saying "email doesn't work that way" .

That or take up recreational alcoholism

dhromed

@UriGagarin said:

Ach

Are you scottish?

nah, from Surrey. Tend to use all kinds of localisms from all over the UK . Usually Yorkshire or Cornish.

Cassidy

@UriGagarin said:

You basically have to register the IP of the sending machine (or something, wasn't too involved with the details there) to make it a known email channel .

Okay... some UK ISPs do something similar - any outgoing port 25 connections must be relayed through their servers and not attempt to deliver directly. Two of my ISPs did this; I didn't need to register my IP with them, just use their mail servers as a smarthost.

@UriGagarin said:

I was wondering how that is handled and what the responsibilities of the sneder are.

24/7 thing was just that marketing don't think beyond their noses half the time , so if they want genuine 24/7 and uptimes - it costs . If they ain't bothered about it being down every now and again then forget it .

Reading jetcitywoman's post, I get the impression that doesn't part of her responsibilities. She's just got to create the letter - posting it and tracking it will be someone else's problem.

bgodot

Guess who filed the first bug in the Outlook bug database saying that automatically showing images from remote hosts was a potential privacy problem?

(Hint: He's posting in this thread)