It's a lonely road indeed.
This is one I often get which I notice because my Android mail client shows the plain text version in the notification so all you see is this failed HTML encoding flooding the screen as the notification text.
Chalk another win up for the Salesforce Marketing Cloud letting an encoding hack from the HTML version leak into the plain text version.
This is a multi-part message in MIME format.
--ySCSIjGKGV=_?:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
͏‌ ͏‌ ͏‌ ͏‌ ͏‌ ͏‌ ͏‌ ͏‌ ͏‌ ͏‌ ͏‌ ͏‌ ͏‌ ͏‌ ͏‌ ͏‌ ͏‌ ͏‌ [ repeated for a screen full ]The ideal case is that a website gracefully degrades with JS disabled. That's largely a pipe dream with React usage being what it is, but some sites manage it. Github is one who still does this well.
The nonideal case is that I'm presented with a misrendered site, but I can still see some semantic information that may, or may not, be what I was looking for. Gitlab's an example of this.
The worst case comes where the site white-screens and doesn't load _anything_ of use. Reddit is an example where it loads nothing but a loading image. My worst pet peeve is the Stack Overflow-style failure mode, though, which explicit says: "Enable JavaScript and cookies to continue.", rather than making any attempt to show any content at all, which is most similar to what the author here is describing.
My 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
After switching to the HTML version, I was not greeted with a rendered equivalent of:
<html> <head> <title>...</title> </head> <body> <p>Plain text version not available</p> </body> </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.
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.
Scenario: They're using a MIME-capable email client which can't handle text/html.
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.
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.
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.
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.
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.
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 <site.website>[sic] for latest show times.
text/html
Use
it before it’s gone
[50 blank lines]
[... a bit more content ...] [... random CSS stylesheet oneliner ...]
[100 more blank lines]
[... et cetera ...]
[title]
Hi Tom /,
Thanks for your order!
[date]
Your receipt is attached to this email.
If you do not want to receive receipts by email, you can unsubscribe.