You know how sometimes you encounter something that is so terrible and appalling that you feel you just have to tell other people about it? Well, for me, today is one of those days.
But look, I’m a nerd who writes email software and likes to write raw HTML. If the terms “SMTP” and “MIME” don’t mean anything to you, you should probably stop reading now, because you’re not going to be able to truly appreciate the abomination that I am about to share.
Still with me? OK, what we are going to tear to shreds today is the email that Staples sends you when you use your Rewards card at checkout and tell the clerk that you want your receipt by email. Rarely in my 30+ years of working on computers and the internet have I seen anything this terrible.
You can download the entire message I’m writing about (with personal details removed) from here. I’m including excerpts below of the relevant bits.
OK, so, let’s start with the message header:
X-Mailer: Mailer
Let’s talk about the purpose of the X-Mailer header. As per RFC 2076, the X-Mailer message header is supposed to contain “Information about the client software of the originator.” Typically, it contains the name and version of the software library or application that generated the email. The string “Mailer” is not exactly useful contents for this header. In fact, it’s entirely useless. If you’re going to put something entirely useless in the “X-Mailer” header, you should leave it out entirely.
Moving on, we see these styles embedded near the top of the HTML body of the email (reformatted for readibility):
html {
-webkit-text-size-adjust:none;
-ms-text-size-adjust:none;
font-size:0 !important;
line-height:0 !important;
}
What are “font-size:0” and “line-height:0” doing there? Why, why, why?
This may seem inconsequential, but it causes a lot of problems for email clients that try to preserve styles when forwarding messages. When I try to forward this email from my email clients, Thunderbird, the blank lines and “——– Forwarded Message ——–” it usually inserts above the forwarded message are missing. Well, strictly speaking, they’re not missing, they’re invisible, because they end up being formatted with a font size and line height of zero as per the styles shown above. Ridiculous.
A bit further on, we see this:
.appBanner{ background-image:url('http://media.staples.com/email/templates/usso/a2/mobile_app_banner.gif') !important; }
Do you see this problem? Why, in August 2018, is a corporate behemoth like Staples sending out emails containing URLs that don’t use SSL? Now, lest you think this is an isolated problem, there are 77 links in this email that don’t use SSL. Most of those links are to media.staples.com, which does support SSL so there’s no excuse not to use it. Perhaps you could rationalize not requiring SSL for the images and such downloaded from there, but even ignoring those, there are six links that don’t use SSL: four to weeklyad.staples.com, one to www.staples.com, and one to www.twitter.com. It’s not surprising that the link to weeklyad.staples.com doesn’t use SSL, because that web site doesn’t support SSL, another strike against Staples here. The other two sites, www.staples.com and www.twitter.com, not only support SSL but force the user to switch to SSL when they connect without it.
Let’s move on to more silliness. This occurs later in the body of the message, right in the middle of a table (again, reformatted for readibility; the HTML in the actual email body is illegibly formatted):
</tr>
<html>
<body>
<style type="text/css">
.contact a {color:#000000!important;text-decoration:none!important;}
</style>
<tr class="contact">
<td style="text-align: center; margin: 1px; font-family: monospace; font: 10pt; font-weight:normal;">
---- -------- ----- ----
</td>
</tr>
</body>
</html>
What is this little mini-HTML document, complete with <html> and <body> delimiters, doing in the middle of another HTML document? Not to mention in the middle of a table, with an incomplete table embedded inside of it? (Also, dare I mention that the <style shown above is repeated over and over again, identically, throughout the document?)
Alas, this is not an aberration. The HTML body of this email message has 92 <html> tags and 92 <body> tags in it. Over and over again throughout the body, little mini-documents are embedded. I can’t even.
Let’s continue. For this next example of the stupidity in this email, I need to show a screenshot of how Thunderbird renders a portion of the email:
See that missing inline image? This is how it’s supposed to look (well, not exactly how it’s supposed to look, since I’ve blurred the image which is of a bar-code for privacy reasons, but you’ll get the idea):
So, why doesn’t Thunderbird display the inline image? Well, it’s not Thunderbird’s fault, it’s the email’s, because of this in its header:
Content-Type: multipart/mixed; boundary="----=_Part_163323_1378570795.1535656129903"
I’ve highlighted the problem, but you still won’t recognize it unless you’re really familiar with MIME; more familiar than the people at Staples who wrote the code to generate this email, in fact!
If you want to do inline images in a MIME message, you have to use the multipart/related content type, not multipart/mixed. Arguably, mail clients like Thunderbird should be “generous” and display the message as the authors intend even though its formatting is non-compliant with the relevant standards, and indeed, there’s a Thunderbird bug report about this that has been open for almost 18 years. And many mail clients will, in fact, display the attachments inline even though the message formatting is wrong. But that doesn’t change the fact that the message formatting is wrong. It’s a stupid mistake, and they should fix it.
To summarize, every receipt email that Staples sends out for in-store purchases has the following problems:
- Bogus “X-Mailer” header.
- Incorrect “Content-Type” header that causes inline images to fail to display properly for some email clients.
- Bogus, unnecessary CSS styling of font size and line height on the body of the message causes formatting and forwarding problems for some email clients.
- Bogus
<html>and<body>tags scattered throughout the document. - Identical CSS inline stylesheets repeated over and over throughout the document.
- Lots of “http:” URLs that should be “https:”.
This is what happens when you hire people who don’t know what the hell they’re doing to write software for you.
Worth noting: emails sent by Staples about orders placed through their web site have only the last of these problems, i.e., they use some “http:” URLs when they should use “https:”. One suspects that the people who built the Staples eCommerce platform are different from the people who build the code that generates email point-of-sale receipts.
