How to accidentally create an Extinction Level Email™ that kills Outlook performance

We’ve had the ping of death. The zip bomb. Now meet the Extinction Level Email™: an otherwise simple email that slows Outlook for Windows to a crawl just by being in the Inbox, even if it’s not being viewed!

First, kudos to a client for patiently proving the symptoms were real. And thanks to the spirits that led another agency to create the offending template, allowing us to get credit for debugging but none of the blame.😊

The client was eager for a rebrand, having finally bought a domain from a longtime squatter. The emails were ready: ExampleNetCo is now simply Example. An agency built out a slick new template.

Then everything broke loose: test emails made Outlook for Windows (both Outlook 2019 and the latest 365) slow to a crawl. Selecting messages in the Inbox was like being stuck in a glue trap. No matter whether you were looking at the rebranded emails or not, as long as they were in the Inbox folder, Outlook was doomed. The behavior would only subside when the emails were moved or deleted (which then “infected” the Deleted Items folder with the same behavior!).

It was weird, but it was real. And it didn’t affect any other mail clients, from various webmails to Outlook for Mac to nerd-favorite The Bat!. Just Outlook for Windows (which is, of course, the main thing we mean when we say “Outlook”).

So we set to clipping things out of the email to see if we could make it stop. We removed all Microsoft-specific stuff (conditional comments, etc.). Cut out webfonts on a (poor) hunch. Removed line breaks from attributes: another bad guess. Nothing helped until we cut out this totally innocent-looking <tr>:

Huh? (We used stronger language in reality.) Removing that one <tr> solved the problem completely. But it just has an empty <td>. How could that disrupt the performance of an entire Windows app?

Well, that block isn’t as innocent as it looks. What you assume is a line break and/or ASCII spaces is actually a series of Invisible Separator (U+2063) characters. You can see them in the qp-encoded raw email:

And in the template as HTML decimal entities:

So someone must have decided these were better than   and didn’t test in Outlook. A near-disastrous choice: nothing like announcing your rebrand by sending what amounts to a virus to your whole audience!

Luckily, we caught it in QA instead of scrambling live. But be careful out there.

As for why Outlook goes crazy when it sees a rarely used — but not in any way illegal or even particularly new — character, who can say? My complete conjecture is they have special logic for invisible math characters and it spins out of control when there’s no <math> element.