Email Campaigns on Windows Phone (Part 3: Exchange ActiveSync)

Tuesday August 19th 2014 at 8:04 PM

This is the final part of the email campaigns on Windows Phone series and this time I look at how Exchange ActiveSync (EAS) mailboxes behave within Outlook Mobile on Windows Phone. The EAS protocol is what powers Exchange/Office 365 mailboxes on many mobile devices including Windows Phone and is something that is common in the enterprise world. The experience from an email campaign point of view and to the end user however, is rather frustrating. Find out the key differences and why things don’t quite work the same as POP3/IMAP below.

If you’ve missed any of the previous parts or just want to jump back, here are the links to the previous parts in the series:

Email accounts that use Exchange ActiveSync

An email account that uses Exchange ActiveSync, renders email completely different to POP3/IMAP mailboxes, and there are BIG differences.

Unlike the rendering engine being IE Mobile for POP3/IMAP, any mailbox that uses Exchange ActiveSync (EAS) is actually using the EAS client itself to render HTML/CSS.

In a previous article I wrote about CSS3 media query support on Windows Phone, I thought that this was because Exchange/Office 365 mailboxes rendered with IE Quirks mode regardless, this however can now be confirmed as false, because IE Mobile is not being used at all here.

Exchange ActiveSync clients

The client itself is Exchange ActiveSync, but there are several different versions in the wild depending on the version of Exchange Server.

Exchange ActiveSync 2.0 – Exchange Server 2003
Exchange ActiveSync 2.1 – Exchange Server 2003 SP1
Exchange ActiveSync 2.5 – Exchange Server 2003 SP2
Exchange ActiveSync 12.0 – Exchange Server 2007
Exchange ActiveSync 12.1 – Exchange Server 2007 SP1
Exchange ActiveSync 14.0 – Exchange Server 2010
Exchange ActiveSync 14.1 – Exchange Server 2010 SP1
Exchange ActiveSync 14.2 – Exchange Server 2010 SP2
Exchange ActiveSync 15.0 – Exchange Server 2013

You’ll notice that the version numbers from Exchange Server 2007 and onwards match the Microsoft Office conditional comment version numbers to target specific versions of the Microsoft Outlook email client. Just thought I’d throw that fun fact in there.

There isn’t a lot information on the HTML/CSS rendering capabilities of any EAS client, but its pretty clear that is has very basic HTML/CSS support. The only resources I could find on the subject was a table of feature/policy support on various different versions of EAS on Wikipedia and TechNet.

Key rendering differences with Exchange ActiveSync

Here are some observations of the key differences when email is rendered within an EAS mailbox compared to POP3/IMAP.

Doctype is preserved
No CSS3 support
CSS in the <head> is not supported at all
Text can often appears different sizes, but are set at the same font size

I came across someone else who had also been questioning why the HTML/CSS rendering was different between POP3/IMAP vs Exchange ActiveSync, via a few a few forum threads on various Microsoft community sites.

Unfortunately, no one from Microsoft, the community or anyone else was able to answer the above questions and my own subsequent questions. So I’ve decided to do my own digging. Here’s a more detailed breakdown of what’s fundamentally different.

Doctype is preserved

Unlike POP3/IMAP mailboxes, the doctype is not removed from email within an EAS based mailbox, the preservation of the doctype doesn’t seem to affect much however, given that the rendering engine is completely different.

No CSS3 Support

Media queries or any CSS3 properties do not render in an EAS mailbox. Its likely because the EAS client has very limited HTML/CSS support, and doesn’t even have full CSS2 support, so CSS3 is out of the questions. Sigh.

No CSS in the head

To add further woes, CSS in the head doesn’t appear to be supported at all. I did a quick test, where I set the default background colour of a table cell with the bgcolor attribute and then wrote a rule in the head to override it, it stayed the colour that’s set inline in an Exchange/Office 365 mailbox. I repeated the same test with more basic properties like color and the same result was observed.

Varying font sizes

You may find that font sizes in your email vary despite being the same size in Windows Phone. I found out its not actually the size of the text necessarily but more likely the zoom level due to the different viewport that the EAS client works with. It seems to be actually related to when text content is contained within a table layout and the width of the containing table is set to a fixed pixel based width.

Basically any table that is set to a percentage width creates the text at the correct size, but for tables/cells that use a fixed pixel width value the font size is shrunk. In addition setting similar values on table cells also cause this problem. This generally means you’ll have a lot of different text sizes everywhere depending on the containing table of the content/table cell. The following all seem to be causes of font sizes appearing to be shrunk by the email client.

<table> has a width attribute with a pixel value
<table> has a height attribute with a pixel value
<table> has no width attribute set at all
<td> has a width attribute with a pixel value

I came across several questions related to this on Stack Overflow:

The solution:

From what I’ve found, the only way to fix this is to use percentage based values rather than fixed. The reason why fixed width cause an issue is likely due to how the viewport behaves with the EAS client.

I documented the issue on the Litmus Community with examples of how the behaviour affects content within table cells. My testing led to the creation of an email rendering test template which can be found on GitHub

Wrapping this series up

So that’s the end of my email campaign on Windows Phone series. What have been the key points I’ve discovered through each part?

Windows Phone 7.5 and above have the potential for responsive design
POP3/IMAP mailboxes use IE Mobile for rendering
Exchange/Office 365 mailboxes use the EAS client (which has terrible standards support)
Windows Phone 8.1 GDR1 includes some support for rendering -webkit properties

After doing all the research, testing and finally documenting my findings, I have somewhat mixed feelings. On the one hand its been shown that Windows Phone is very capable of delivering an email experience that we’ve come to expect on iOS/Android, but throw Exchange and Office 365 into the mix and we go back 10 years in an instant. Unfortunately, it seems enterprise users will be getting a very different email experience on Windows Phone, which I can’t help but make connections to how Office 365 creates a similar scenario.

Diving into Outlook Mobile on Windows Phone turned out to be no small feat. Hopefully this series on Windows Phone has been informative and helps you better understand how Outlook Mobile works and what to expect with different mail account types.

Have you found anything about Windows Phone that’s worth a mention? Let me know in the comments.