Change Location Europe - Flag EUR
Mouser Europe - Flag Mouser Europe

Incoterms: DDP is available to customers in EU Member States.
All prices include duty and customs fees on select shipping methods.

Incoterms: DDU applies to most non-EU customers.
Duty, customs fees and taxes are collected at time of delivery.

Please confirm your currency selection:

Euros are accepted for payment only in EU member states these countries.

US Dollars
USD is accepted in all countries.

Other currency options may also be available - see
Mouser Worldwide.

Bench Talk for Design Engineers

Bench Talk


Bench Talk for Design Engineers | The Official Blog of Mouser Electronics

Part II: Use HTML-based Email, Become Famous Arden Henderson


In Part I, we described a scenario where Bob’s bank account was vacuumed to the last dollar after he was phished. We talked about phishing and various other nefarious email-related exploits, tricks, and landmines that slither around in the dark underbelly of the internets, splashing about in the webtubulars.

Let’s take a quick look at how your basic dubious HTML-based email is strung together. Here’s a stripped-down email with the usual suspects’ names changed and the company’s name spindled:


Bunch of other headers here proclaiming Probably Not Spam, Etc.
From: somebody
To: somebody else
Subject: I am John's HTML-based Email
Date: Some date, in UTC if the sender is cool
Bunch of more headers not pertinent to the discussion
Content-Type: multipart/alternative;
MIME-Version: 1.0
Return-Path: that somebody

Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Here is some text, explaining everything the reader needs to know.
Blah-blah. And Blah.

For more exciting info, hit our very important link Super Very Cool Stuff Here!!


Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" xmlns:m=3D"
fice/2004/12/omml" xmlns=3D"">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
/* Font Definitions */=0A=
    {font-family:"Cambria Math";=0A=
    panose-1:2 4 5 3 5 4 6 3 2 4;}=0A=
    panose-1:2 15 5 2 2 2 4 3 2 4;}=0A=
    panose-1:2 11 6 4 3 5 4 4 2 4;}=0A=
/* Style Definitions */=0A=
p.MsoNormal, li.MsoNormal, div.MsoNormal=0A=
a:link, span.MsoHyperlink=0A=
a:visited, span.MsoHyperlinkFollowed=0A=
@page WordSection1=0A=
    {size:8.5in 11.0in;=0A=
    margin:1.0in 1.0in 1.0in 1.0in;}=0A=
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si=
Here is some text, explaining everything the reader needs to know.
Blah-blah. And Blah.&nbsp;
For more exciting info, hit our very important link
<a href=3D"">Super Very Cool Stuff Here!!</a>



The multipart/alternative boundary makes it all clear. The top half of the email is mere plain text. The bottom half is HTML, wrapped around the actual message, plus heaping piles of additional HTML and embedded CSS, depending on how slick the email must be, usually dictated from on high. Company logo graphics, photos of happy people, product photos, and so on can be included in HTML-based email.

Multipurpose Internet Mail Extensions aka MIME makes it happen. This is the internet standard that injudiciously extended the format of email to be prettified, able to tumble through hoops, set computers on fire, and generally make a bad day if used for evil.

By the way, if the reader is wondering why all the “3D” text in the email source, the useful part is actually “=3D” and represents the ASCII equal sign. This is due to the quoted-printable encoding, one of the the two basic MIME content transfer encodings.

As a side comment, note that the reader can easily peruse email source since most, if not all, email clients have a “View Source” feature. Taking time to do this, especially with a supercharged, spruced-up HTML-based email, will be quite illuminating.

Okay, so back to the email source example above. The main thing to notice is the plain text version of the link clearly shows the actual link while the HTML version of the email will only display “Super Very Cool Stuff Here!!” as clickable text. The actual related link of sketchy purposes is hidden by the rendered HTML in the email client. This is because the HTML anchor element, which marks the beginning and end of a hyperlink, lets one define both the actual URL and a description, to wit:


<a href=3D"">Super Very Cool Stuff Here!!</a>


Notably, the anchor’s descriptive text, which becomes the clickable text, can be a graphic, a button, and most anything else. The point is the actual hyperlink is not visible in this context – it’s part of the HTML, the markup. In the same way, the links in this blog the reader is avidly reading just now are not visible, just the text associated with the link as defined by the code, that code being HTML. Email clients and web browers render pages based on the code; they don’t display the code. (Most email clients and browsers allow viewing the source code.)

Those who have chosen the paths of darkness, and toil away night and day on deplorable HTML-based email fashioned for squalid purposes, can, and do, create amazingly complex phishing email, complete with shortened URL links and other sly tricks such as steganography, surreptitiously concealing vicious computer-gobbling code inside photos of soft, cuddly bunnies and cosmically-cute kittens. Apparently, many of them are not aware their authoring software is generating plain-text/HTML email, exposing their dire schemes to those running plain-text-only email clients. If the unconscionable malcontents generate their egregious attacks as HTML-only email, then no harm done either – nothing shows up in plain-text-only emailers, therefore no link traps.

What to do? It’s easy: Set the email client to never display HTML-based email, only the plain text part, and to never compose and send HTML-based email. Yes, plain text email is simple but it’s also relentlessly straightforward and trustworthy.

Sure, even if the URL is visible and “is what it is,” it could be bogus. Slightly misspelled URLs are a time-dishonored way of tricking people to slimy sites which look impressively legit, for example, visually exactly the same as a trusted bank website. Nonetheless, at some point there must be competence and even just a vague awareness of how technical things work.

That is to say, at least with plain text email, one has a chance to discern the actual URL isn’t quite right. Not so with HTML-based email. (Unless the reader peruses the HTML-based email source each time, and, if that’s the case, no worries about the reader.)

A note of irony: HTML-based email does not render the same across all email clients, all machine configurations, all combinations of OS and application software, all hardware, all platforms. And it doesn’t always degrade graciously.

Take the font choice, for example. When creating the HTML-based email, the author makes a typographical design decision in choosing the preferred font plus some fallback fonts. If the font doesn’t exist on the user’s machine, HTML-based email rendering must degrade graciously, spiraling down through specified alternate fonts and finally some default font which will be different across the platform landscape. Already at that point, the rendered HTML does not look like the author intended.

The problems multiply. If the HTML-based email uses CSS3, it may be displayed in an email client that only is good to CSS2. If the HTML-based email is written as HTML5, rendering as intended goes out the window in older email clients unaware of HTML5.

Therefore, all that effort, time, and creative prowess to create a perfect, official corporate email is a roll of the dice out in the wild.

Sure, enterprise HTML-based email reliably renders the same inside the corporation because it’s a controlled environment with identical, or mostly identical, platforms. The corporate HTML-based email is beautiful and awesome and wonderfully represents the corporation… internally on identical company machines.

Yet, outside in the wind-blown flatlands of the email tundra, anything can happen. There is simply no predictability of how HTML-based email will render everywhere as compared to the authoring machine. In fact, given enough platform variations, HTML-based email will reliably degrade spectacularly in ways the author will never imagine. Certainly, care and effort to maintain fidelity to explicit corporate publication specifications will be squandered. Which, of course, completely renders pointless of doing bright and shiny HTML-based email in the first place.

In summary, we’ve touched on the disassembly of one malicious HTML-based email example masquerading as official email from a trusted institution, designed to exploit the user’s naivete and unawareness, directing the user to sign-in at a bogus site that appears authentic where the user’s password and login name will be gleefully captured.

But wait, there’s more. The reader may recall the related email nightmares mentioned in Part I of this series. Clicking a link in HTML-based email can cause malware to be installed straight into the user’s device. Merely opening email can run a script to download and install malware. Opening email attachments can silently deliver malware chaos. Cheerful email actually sent from trusted friends’ hacked email accounts, urging us to “click this link for more info about this exciting stuff I just discovered!” Hacked enterprise email accounts can result in highly trusted coworker internal email sent by exploited machines, packed full of unhappy surprises. Unencrypted can be intercepted and modified. And, unencrypted email – the bulk of email sent even today – is visible to crafty driftnets, the illusion of email privacy still somehow persisting after decades to the contrary.

User lack of awareness and the deceptive simplicity of email have been used for endless exploits for a long time now. The solution is technical awareness and alertness and common sense. Or switching to tin cans and string.

Once again, Dear Readers, remember that friends don’t let friends do HTML-based email.

Footnote: What about Bob? Readers will be happy to know that it turned out okay. Though his bank accounts had been vacuumed dry, Bob was able to turn to his trusted friend Alice for a goodly loan. The loan would make it possible to turn the electricity back on and get the robots charged and back to work. Alice wired the money a few hours ago, directly to Bob’s bank. Bob is waiting by his computer for the bank’s deposit confirmation notification.

It should show up any moment.

« Back

Arden Henderson spent at least part of his life toolsmithing in dark, steam-powered workshops of software tool forges long gone, drenched in blood, sweat, and code under the glare of cathode ray tubes, striving for the perfect line of self-modifying software and the holy grail of all things codecraft: The perfectly rendered pixel. These days, when not working on his 1964 Flux Blend time machine (which he inadvertently wrecked before it was built after a particularly deep recursive loop), Mr. Henderson works in part-time castle elf and groundskeeper jobs, chatting with singularities spawned from code gone mad in vast labyrinths of vacuum tubes, patch cords, and electro-mechanical relays. Mr. Henderson earned a B.S.C.S. late in life at Texas A&M. Over the hundreds of years gone by before then and after, he has worked in various realms ranging from petrochemical wonderlands spread across the flat Gulf Coast saltgrass plains, as far as the eye can see, to silicon bastions deep in the heart of Central Texas.

All Authors

Show More Show More
View Blogs by Date