Stop Sending Me Your Errors - Tomasz KramkowskiMy desktop email client of choice can render both text/plain and text/html emails. I happen to prefer text/plain versions. And you're right, I should get with the times. But when you misuse multipart/alternative to send me an error, you're not helping me or anyone else for that matter. In fact, you're doing the exact opposite.The ancient scrolls document multipart/alternative as a way to present the same information in multiple interchangeable forms. Most commonly, this is used to send the HTML version of an email alongside its plain text counterpart.In other words, multipart/alternative is NOT FOR SENDING ME YOUR DAMNED ERRORS . If my email client cannot handle your email, it's the client's job to report such errors.This morning, I received an email with the body:Plain text version not available<br>After switching to the HTML version, I was not greeted with a rendered equivalent of:&LT!DOCTYPE html><br>html><br>head><br>title>...&LT/title><br>&LT/head><br>body><br>p>Plain text version not available&LT/p><br>&LT/body><br>&LT/html>

Instead, I was greeted with actual email content. I would have been surprised if this weren't so common.Let's consider the scenarios where a user would be presented with the text/plain version:Scenario: They're using an ancient pre-MIME email client because they are a time traveller from the '80s.<br>Result: They see some gibberish, followed by "Plain text version not available", followed by HTML-looking gibberish. If they don't already know what's happening, then this message isn't going to help them fix anything. That's assuming they even spot it among the gibberish.<br>Scenario: They're using a MIME-capable email client which can't handle text/html.<br>Result: They see this "error", and since their client understands MIME, it infers that this "error" is supposedly interchangeable with the bit it can't understand and presents it. Maybe the client offers a way to grab the HTML, or maybe not. The user might not even understand that the situation is recoverable.<br>If there were no text/plain part, their client would probably do no worse than your "error" message, and might even offer an actual recovery path instead. And if it did do worse, you should again ask yourself whether your message would actually help them.<br>Scenario: They're using a MIME-capable email client which can handle both text/html and text/plain, but they configured it to prefer text/plain.<br>Result: Very similar to scenario 2, except they would have immediately gotten the intended experience if you had simply not added an error as a text/plain part.<br>Now they must rely on their understanding of the situation and knowledge of their email client to find the option to switch to the format they explicitly configured it not to prefer. You just made their life more difficult.<br>If your email system cannot generate a useful text/plain version of the email, then it doesn't help anyone to tell them that. If scenario 1 sounded desirable to you1, you could instead use HTML comments to give the victims of your HTML email more or less an equivalently confusing experience, without ignoring the RFC or pissing off random internet nobodies."But," I hear you cry, "I put the text/plain version first and the text/html version last. Just like the scrolls said I should do to indicate my preferred representation."That's cool. I get that you prefer HTML, but I prefer plain text. When multipart/alternative is used correctly, the plain text part can be much cleaner than anything I can render from the HTML part. If I didn't register my preference for text/plain with my email client, I would face the mirror image of scenario 3.Thankfully, there's an easy solution to all of this: just stop sending text/plain alternatives that are not, in fact, alternatives. Not only will it make all 10 of us happy, but it can also help avoid getting your email marked as spam.It doesn't even stop at errors. Here are some more (verbatim, aside from bits in [square brackets]) examples of real text/plain parts of multipart/alternative emails I've received recently:This email contains html content. Please configure your email client for html or visit &LTsite.website>[sic] for latest show times.<br>text/html<br>Use<br>it before it’s gone<br>[50 blank lines]<br>[... a bit more content ...] [... random CSS stylesheet oneliner ...]<br>[100 more blank lines]<br>[... et cetera ...]<br>[title]<br>Hi Tom &amp#x2F;,<br>Thanks for your order!<br>[date]<br>Your receipt is attached to this email.<br>If you do not want to receive receipts by email, you can &LTa style="text-decoration:none;" href="https:&amp#x2F;&amp#x2F;[domain]&amp#x2F;optOut&amp#x2F;receiptOptOut?businessId=[id]&ampamp;emailAddress=[my-email]&ampamp;token=[token]">unsubscribe&LTa/>.<br>Footnotes<br>I very much doubt that anyone who would be confused by this situation is using an email client without MIME support, or even without text/html support in 2026.↩