Use Plaintext Email (2019)(useplaintext.email)
useplaintext.email
Use Plaintext Email (2019)
https://useplaintext.email/
26 comments
Counterpoint: If you have to guarantee delivery, I don't see how you can choose something other than plaintext unless you can make assurances about the environment recipients are using to read the message.
Case in point: Last I heard, The College Board still sends critical test information - admission tickets and the like - in plaintext.
Case in point: Last I heard, The College Board still sends critical test information - admission tickets and the like - in plaintext.
far more consequential emails are sent with HTML mail
By volume, yes...
However, my choice of this example was intentional. You're not looking for a low bounce rate, you want - and need - exactly zero. Questions about standards are moot in a plaintext environment and security concerns are, if not eliminated, greatly minimized if you can't include images or live, clickable URLs.
Business do send a metric fuckton of HTML mail, but they generally have the budget to test for and support more types of clients.
However, my choice of this example was intentional. You're not looking for a low bounce rate, you want - and need - exactly zero. Questions about standards are moot in a plaintext environment and security concerns are, if not eliminated, greatly minimized if you can't include images or live, clickable URLs.
Business do send a metric fuckton of HTML mail, but they generally have the budget to test for and support more types of clients.
Client testing is a fair point, but I'm skeptical of the claims that plaintext improves bounce rate and I don't follow how it improves security unless you mean exploits that target the HTML renderer itself.
As it was explained to me, the worry was less about actual exploits and more to do with supporting various HTML features in the respective clients (Think Caniuse, but specifically for email).
Back when I was doing some work in this area, the Email Standards Project was trying to get most of the popular clients to update their rendering engines with this goal in mind. So far as I can tell, this work seems to have been inherited by the people behind the Email Markup Consortium.[1]
[1]: https://emailmarkup.org
Back when I was doing some work in this area, the Email Standards Project was trying to get most of the popular clients to update their rendering engines with this goal in mind. So far as I can tell, this work seems to have been inherited by the people behind the Email Markup Consortium.[1]
[1]: https://emailmarkup.org
There is a great irony in a webpage with a section entitled "Rich text isn't that great, anyway" using rich text to set said title apart from the surrounding text typographically. The rest of the page also makes significant use of hyperlinked text, text with background colors, and other useful communication aids that aren't possible with plaintext email.
There is no irony because an email is not a webpage
It's not that ironic; it's a web page that contains far more information that one might expect in any but the largest of emails.
The web is where the eyeballs are and nobody's going to convince anyone of a new idea by wrapping whole-page content in a <pre> tag, no matter the idealological purity this would reveal. To reduce friction (already created by telling someone to potentially change email clients) with readers the author needs to speak the visual language of the medium.
The web is where the eyeballs are and nobody's going to convince anyone of a new idea by wrapping whole-page content in a <pre> tag, no matter the idealological purity this would reveal. To reduce friction (already created by telling someone to potentially change email clients) with readers the author needs to speak the visual language of the medium.
This is the truth.
Want to look like a pro in email? Plain text, bottom posted, trimmed.
Replying wherever the email app happens to leave the cursor is like driving down the road wherever your car happened to be pointing. It's antisocial, stupid, and makes the experience much worse for everyone. Learn to drive. Learn to email.
Want to look like a pro in email? Plain text, bottom posted, trimmed.
Replying wherever the email app happens to leave the cursor is like driving down the road wherever your car happened to be pointing. It's antisocial, stupid, and makes the experience much worse for everyone. Learn to drive. Learn to email.
Sorry, top posting has won. You are going to reply to a business person, and they're going to think you forgot to write anything when their own message is at the top.
Also, I like that when I get added to a chain, the entire context comes with it. If you trim it, it automatically becomes an XY problem to my point of view.
Also, I like that when I get added to a chain, the entire context comes with it. If you trim it, it automatically becomes an XY problem to my point of view.
Hi Dave,
My answers below.
> yadda yadda
blah blah
---
Works like a charm.
Messes up the quotation if some people top-quote and other bottom-quote in the same conversation, but do people in 2024 seriously read the quoted text when every halfway decent email client remembers the entire conversation and/or thread? Quoted text is noise anyway, especially if coming from laymen with Outlook with half a dozen lines of disclaimers, logo and signatures repeated and quoted every email.
My answers below.
> yadda yadda
blah blah
---
Works like a charm.
Messes up the quotation if some people top-quote and other bottom-quote in the same conversation, but do people in 2024 seriously read the quoted text when every halfway decent email client remembers the entire conversation and/or thread? Quoted text is noise anyway, especially if coming from laymen with Outlook with half a dozen lines of disclaimers, logo and signatures repeated and quoted every email.
> do people in 2024 seriously read the quoted text when every halfway decent email client remembers the entire conversation and/or thread?
Sometimes new people get added onto threads after they've been going on for a while, and then those people have to read the quoted history to understand the context.
Sometimes new people get added onto threads after they've been going on for a while, and then those people have to read the quoted history to understand the context.
I do a mix of both. Top posting when I’m making a general comment, but if I’m responding to several questions, I pare the original mail back as much as possible and reply underneath each.
My logic is there isn’t any benefit to bottom posting if all you’re doing is making someone scroll.
Also, I refuse to ever use a signature or Out of Office reply.
(Full disclosure: I only use public transport.)
My logic is there isn’t any benefit to bottom posting if all you’re doing is making someone scroll.
Also, I refuse to ever use a signature or Out of Office reply.
(Full disclosure: I only use public transport.)
> Want to look like a pro in email? Plain text, bottom posted, trimmed.
Top posted + interleaved quoting, ya' filthy animals.
Top posted + interleaved quoting, ya' filthy animals.
> Replying wherever the email app happens to leave the cursor .. It's antisocial, stupid, and makes the experience much worse for everyone.
Bottom posting is even more antisocial if your recipient is likely to be using a client that always opens the email with only the top visible.
I agree that bottom posting is best but your ire should be directed at the makers of the mail clients not the users.
Bottom posting is even more antisocial if your recipient is likely to be using a client that always opens the email with only the top visible.
I agree that bottom posting is best but your ire should be directed at the makers of the mail clients not the users.
Bottom posting is weird and I hate it.
Serious question: why do I want to "look like a pro in email"?
You'd rather look like an amateur?
I'm not sure I want the styling of my email to be especially noteworthy
It is worth considering that every interaction you have tells other people something about you. Many people don’t spend much time thinking about what small choices say about them, but they always tell a story whether you want them to or not. Sometimes it can be a good idea to optimize those messages (especially in a professional context). I would argue that it is much more important what you write, rather than where you write it, but everything says something, and what it says is very context dependent.
What kind of person am I interacting with that cares about email this way? It's certainly not customer prospects or investors, both of whom have HTML email junk you wouldn't believe.
Insofar as that’s true, I do not think I want plaintext. Especially if it’s a message that would otherwise have inline links or images or any sort of rich text.
I would like the content of my emails to be memorable. Not an unusual UX.
Maybe if I were trying to cultivate an image as a slightly eccentric techie.
I would like the content of my emails to be memorable. Not an unusual UX.
Maybe if I were trying to cultivate an image as a slightly eccentric techie.
I'm wondering why I'd care either way.
What is bottom posting? Like the ordering of replies?
This is paraphrased from some old Usenet sig lines:
A: Because it messes with the flow of the conversation.
Q: Why is it bad?
A: Posting your reply above the text you are quoting.
Q: What is top-posting?
A: Because it messes with the flow of the conversation.
Q: Why is it bad?
A: Posting your reply above the text you are quoting.
Q: What is top-posting?
Haha good one! Most mail clients do top posting but then go through elaborate tricks to order the conversation top to bottom. I never though about it but it’s weird indeed.
[deleted]
What’s wrong with interleaving?
I love plaintext email. I always send them and I like getting them too. I have Thunderbird configured for displaying email as plaintext. HTML emails are ugly.
> In plaintext emails, the URL is always visible, and you can more easily make an informed choice to click it. Many phishing emails have also taken the step of carefully replicating the visual style of an email you might trust, such as the appearance of a PayPal email. With plain text, it's much more difficult to trick you like this.
This isn't actually true anymore. It's actually pretty hard to trick a user and anti-spam software with HTML these days. And getting look alike domains is pretty easy. More and more successful phishing attacks happen with plaintext emails!
> HTML emails open up a lot of possibilities which are exploited by spammers to circumvent spam filters, such as making large amounts of text invisible, using hidden elements, and so on. Many people discard HTML emails (particularly mailing lists) on the simple basis that it dramatically reduces the amount of spam emails they receive.
Also not true anymore, at least if you use a service like Yahoo or Gmail. If anything, HTML gives Gmail's filters more "clues" as to whether something is spam.
This isn't actually true anymore. It's actually pretty hard to trick a user and anti-spam software with HTML these days. And getting look alike domains is pretty easy. More and more successful phishing attacks happen with plaintext emails!
> HTML emails open up a lot of possibilities which are exploited by spammers to circumvent spam filters, such as making large amounts of text invisible, using hidden elements, and so on. Many people discard HTML emails (particularly mailing lists) on the simple basis that it dramatically reduces the amount of spam emails they receive.
Also not true anymore, at least if you use a service like Yahoo or Gmail. If anything, HTML gives Gmail's filters more "clues" as to whether something is spam.
> This isn't actually true anymore. It's actually pretty hard to trick a user and anti-spam software with HTML these days.
I see tons of phishing email using HTML email. The ones that use plaintext tend to be the least convincing ones (often the fill in the blank style) as well. Phishing messages love to include logos, and to hide the URL of the links they include which often are URL shorteners or free website/form/survey builders.
One of the reasons I recommend people use plaintext email is to prevent their email from looking like spam, either to the people getting it or to spam filters. Almost all the spam we see uses HTML. I can't remember the last time I saw an unsubscribe link in a plain text message (I have seen plain text spam with instructions to reply with a certain phrase in the subject line though).
I see tons of phishing email using HTML email. The ones that use plaintext tend to be the least convincing ones (often the fill in the blank style) as well. Phishing messages love to include logos, and to hide the URL of the links they include which often are URL shorteners or free website/form/survey builders.
One of the reasons I recommend people use plaintext email is to prevent their email from looking like spam, either to the people getting it or to spam filters. Almost all the spam we see uses HTML. I can't remember the last time I saw an unsubscribe link in a plain text message (I have seen plain text spam with instructions to reply with a certain phrase in the subject line though).
Is this through a service like Gmail or self-hosting? The only phishing attempts I ever see making it through Gmail's filters these days have all been plaintext emails usually with a fake invoice attached.
It's not self hosted, we're using one of the largest email vendors for ISPs. We used to allow Google to host our mail servers, and saw similar levels of phishing getting through although that was several years ago now, and I can only hope they've gotten better at filtering out what actually reaches people's inboxes.
At this point, the battle for only sending plaintext has been decisively lost.
What I'd much rather fight for, now: please always send a valid text/plain part, that includes the full content, including things like the verification code for email verification, or the URLs for anything you expect the user to follow.
Some services send emails that have a text/plain part, but the text/plain part has things like "click here to ..." and the URL to click on is not present.
What I'd much rather fight for, now: please always send a valid text/plain part, that includes the full content, including things like the verification code for email verification, or the URLs for anything you expect the user to follow.
Some services send emails that have a text/plain part, but the text/plain part has things like "click here to ..." and the URL to click on is not present.
I'm amazed at the level of push back this concept faces everytime I've suggested it.
HTML email is one of the main facilitators of putting deceptive links in email.
Plain text allows the user to see exactly what is being presented.
And yet every business entity insists on HTML email. Including the internal IT depeartments when discussing corporate email.
I guess the modern world just can't get by without those exploding "congratulations" party popper emojis...
HTML email is one of the main facilitators of putting deceptive links in email.
Plain text allows the user to see exactly what is being presented.
And yet every business entity insists on HTML email. Including the internal IT depeartments when discussing corporate email.
I guess the modern world just can't get by without those exploding "congratulations" party popper emojis...
So this site wants you to use e-mail in a way that the vast majority of people don't use? So if I for some reason even wanted to do that, it would break how other people see my emails? This makes absolutely no sense, and really comes across as some weird mega-nerd swim-against-the-stream-just-because kind of rant.
They want you to use e-mail in a way that the vast majority of spammers, phishers, and junkmail marketers don't use it. Plaintext email looks fine in most clients. If your MUA doesn't display a plaintext email correctly you should probably find a new one.
Plain-text, sure. Bottom-up? Doubt it.
Yeah, that I'll agree with. Top posting is a must, although when I have to I'll an add quotes as needed in the body and place my responses underneath them.
Bottom posting works really well in some very specific contexts (like certain forum software), but the sad fact is that you can't trust people to find your reply if they have to scroll down past their own email to see it. Placing the most relevant information at the top is a good practice.
Bottom posting works really well in some very specific contexts (like certain forum software), but the sad fact is that you can't trust people to find your reply if they have to scroll down past their own email to see it. Placing the most relevant information at the top is a good practice.
But sometimes that's kind of lovely too, it takes all kinds after all. It's like using Gopher in 2023 and insisting everyone else should too.
"Try using a mail client from this century." --the IT guy at a former worksite of mine
And yes, top posting has won. When you collaborate with others, you communicate on the group's shared terms. For most workgroups that means using Outlook's conventions, if not Outlook itself.
And yes, top posting has won. When you collaborate with others, you communicate on the group's shared terms. For most workgroups that means using Outlook's conventions, if not Outlook itself.
Yes, the battle against top-posters was lost. But if someone is bottom-posting a reply to something I wrote, I will immediately switch to that myself and use for that conversation. No point in trying to blend in with the top-posters when they are not watching. They are still wrong even if they won.
I was willing to die on this hill for a while, but as others have said, that time has unfortunately passed by. The same with top vs bottom replies.
Another reason to let go of plain text is that it seems like sometimes short plain text emails are more likely to end up in spam filters. I don't have great proof of this, but definitely have seen it happen.
Another reason to let go of plain text is that it seems like sometimes short plain text emails are more likely to end up in spam filters. I don't have great proof of this, but definitely have seen it happen.
Any history lessons for why 72 characters is the line length limit? For compatibility with printers and old-school terminals, I thought a hard limit of less than 80 characters per line was the necessary. This not the case? Or is the 72 character limit's significance for something different?
You need to add room for potentially multiple levels of added quote marks.
> Any history lessons for why 72 characters is the line length limit?
I believe it was punched cards (80 columns total, but 8 of those generally used as sequence number).
https://en.wikipedia.org/wiki/Punched_card
I believe it was punched cards (80 columns total, but 8 of those generally used as sequence number).
https://en.wikipedia.org/wiki/Punched_card
An observation: I switched to mainly reading my email in a text client (vi-cmdg, which is a fork of cmdg, a Gmail client that uses the API rather than IMAP - the fork has vim keybindings).
I’m finding I can process email quicker and it’s less stressful than using say Apple Mail, which in turn is always less stressful than the Gmail web client.
I think it might be because: - black and white and effectively dark mode due to my terminal - much less furniture on the screen - not seeing images in the emails (there’s a shortcut to render stuff with a roughly HTML-equivalent line wrap) - its slightly more work to click links (keyboard shortcut which adds numbers next to each link for you to press) but that doesn’t seem to irritate me too much - you get a simple list of attachments - you can write replies in Vim, which I quite like
Interested to hear if anyone else is doing this…
I’m finding I can process email quicker and it’s less stressful than using say Apple Mail, which in turn is always less stressful than the Gmail web client.
I think it might be because: - black and white and effectively dark mode due to my terminal - much less furniture on the screen - not seeing images in the emails (there’s a shortcut to render stuff with a roughly HTML-equivalent line wrap) - its slightly more work to click links (keyboard shortcut which adds numbers next to each link for you to press) but that doesn’t seem to irritate me too much - you get a simple list of attachments - you can write replies in Vim, which I quite like
Interested to hear if anyone else is doing this…
I completely agree. I switched to neomutt three or four years ago and there are a few things with text-based emails that really accelerate my workflow.
1. Fewer distractions. 2. Scripting keyboard shortcuts through emails - creating a to-do from an email with just tapping a function key, for example, or adding a company to a CRM with another function key tap. 3. Being able to delete emails with a Regex filter, which is really important for mailing lists. 4. Much faster latency which Though it seems to be trivial Google's research has shown is important to great user experiences 5. Ability to use neovim within the email client. 6. Local search using not much which again much lower latency than Google even for very large mailboxes.
1. Fewer distractions. 2. Scripting keyboard shortcuts through emails - creating a to-do from an email with just tapping a function key, for example, or adding a company to a CRM with another function key tap. 3. Being able to delete emails with a Regex filter, which is really important for mailing lists. 4. Much faster latency which Though it seems to be trivial Google's research has shown is important to great user experiences 5. Ability to use neovim within the email client. 6. Local search using not much which again much lower latency than Google even for very large mailboxes.
>An observation: I switched to mainly reading my email in a text client (vi-cmdg, which is a fork of cmdg, a Gmail client that uses the API rather than IMAP - the fork has vim keybindings).
Welcome to the club. I've been using Emacs continuously for almost three decades, 99.9999% of the time text-only (whether Linux console, X terminal console, xterm, or SSH client) on a remote server. My email client is VM, written in Emacs Lisp. I've used it to read mail for almost as long as I've used Emacs.
VM (and ancillary tools, like Personality Crisis and mairix)
* does a great of job displaying HTML messages with Emacs's integrated W3M browser engine. For the very few that it doesn't, one keystroke sends the message to my web browser running locally.
* sends URLs I select (all from the keyboard) to the web browser (it doesn't use the add-number method; rather, W3M's built-in navigation keystrokes are available, including Tab and Shift-Tab for moving between links)
* opens images and attachments
* auto-adjusts the From: line of outgoing messages depending on the recipient
* archives messages to various folders using various criteria
* searches my archived mail at lightning speed
Of course, I can write Emacs Lisp code of my own to extend any or all of the above.
VM isn't perfect but, overall, I really feel like I have a superpower for email handling with it. (But I will check out cmdg; using the API is intriguing.)
Welcome to the club. I've been using Emacs continuously for almost three decades, 99.9999% of the time text-only (whether Linux console, X terminal console, xterm, or SSH client) on a remote server. My email client is VM, written in Emacs Lisp. I've used it to read mail for almost as long as I've used Emacs.
VM (and ancillary tools, like Personality Crisis and mairix)
* does a great of job displaying HTML messages with Emacs's integrated W3M browser engine. For the very few that it doesn't, one keystroke sends the message to my web browser running locally.
* sends URLs I select (all from the keyboard) to the web browser (it doesn't use the add-number method; rather, W3M's built-in navigation keystrokes are available, including Tab and Shift-Tab for moving between links)
* opens images and attachments
* auto-adjusts the From: line of outgoing messages depending on the recipient
* archives messages to various folders using various criteria
* searches my archived mail at lightning speed
Of course, I can write Emacs Lisp code of my own to extend any or all of the above.
VM isn't perfect but, overall, I really feel like I have a superpower for email handling with it. (But I will check out cmdg; using the API is intriguing.)
Related:
OpenAI drops ban on military tools to partner with The Pentagon - https://news.ycombinator.com/item?id=39020778 - Jan 2024 (449 comments)
Use plain-text email - https://news.ycombinator.com/item?id=32810515 - Sept 2022 (194 comments)
Use Plaintext Email - https://news.ycombinator.com/item?id=31529589 - May 2022 (1 comment)
Use plaintext email - https://news.ycombinator.com/item?id=20513987 - July 2019 (334 comments)
OpenAI drops ban on military tools to partner with The Pentagon - https://news.ycombinator.com/item?id=39020778 - Jan 2024 (449 comments)
Use plain-text email - https://news.ycombinator.com/item?id=32810515 - Sept 2022 (194 comments)
Use Plaintext Email - https://news.ycombinator.com/item?id=31529589 - May 2022 (1 comment)
Use plaintext email - https://news.ycombinator.com/item?id=20513987 - July 2019 (334 comments)
No, please don't send me emails in a format that will not reflow readably on my phone, especially if I didn't use the same format when emailing you. (The Fastmail instructions explicitly say to disable "When replying, use the same format as the original message".)
That sounds like a bug in your phone. Perhaps you should report it to the vendor? Even my ancient Emacs mail reader can reflow plain text emails when I ask it to do so. It sometimes needs to be told on a paragraph-by-paragraph basis, because otherwise it might also reflow ASCII art diagrams and such, but in practice I find it a minor problem.
> It sometimes needs to be told on a paragraph-by-paragraph basis, because otherwise it might also reflow ASCII art diagrams and such
Yes exactly, there is no "one right way" to do it because you never know if a newline is a "hard enter" or just a "reflow to the next line". Every default will break something.
This is why you need some (minimal) markup, no matter what you do text-only email is broken for some use cases.
Yes exactly, there is no "one right way" to do it because you never know if a newline is a "hard enter" or just a "reflow to the next line". Every default will break something.
This is why you need some (minimal) markup, no matter what you do text-only email is broken for some use cases.
It's a tradeoff. I'm willing to accept some clumsyness in return for conceptual and technical simplicity. Others may feel different. In practice, most people who write plain text emails manage to format them pleasingly themselves (and 72 column plain text is perfectly readable on my phone, although I prefer not reading email there).
> making an accessible HTML email is even more difficult than making an accessible website due to the limitations imposed on HTML emails by most mail client
FWIW I have a Gmail Add-on that reformats the garbage HTML produced by email clients and makes it accessible. (And if you're wondering what an add-on is, it's similar to a Chrome extension, but without the security risks because the code runs on Google's servers rather than in your browser.)
https://prettyfwd.com/
FWIW I have a Gmail Add-on that reformats the garbage HTML produced by email clients and makes it accessible. (And if you're wondering what an add-on is, it's similar to a Chrome extension, but without the security risks because the code runs on Google's servers rather than in your browser.)
https://prettyfwd.com/
There was a time I configured my email client to use plain text, but I no longer remember why I did that. Today I find it strangely annoying to receive an email thread reply in plain text which strips all the formatting from the entire thread.
Bottom posting died with usenet and I don't miss it. It was mostly a form of gatekeeping as far as I remember.
Bottom posting died with usenet and I don't miss it. It was mostly a form of gatekeeping as far as I remember.
Nit: Mblaze is lovely but it is not a TUI. It's a maildir-enabled copy of the "mh" command suite so you can manage and read your email from the command line and use your default editor.
Other than that, yes please plaintext. I don't need a shopping mall in my inbox, get off my lawn ;)
Other than that, yes please plaintext. I don't need a shopping mall in my inbox, get off my lawn ;)
A response to the site in question:
https://kevquirk.com/use-plaintext-email
While the tone is (overly) snarky, it does make a few good points.
https://kevquirk.com/use-plaintext-email
While the tone is (overly) snarky, it does make a few good points.
While I have a copy of Roberts Rules of order, the dejure meeting process has changed. Things come in and out of fashion, and top posting, formatted emails, etc have won out.
Personally, I like being able to include formatted code blocks in email
Personally, I like being able to include formatted code blocks in email
Are your formatted code blocks in a monospace font with line breaks in appropriate places, by chance?
Not sure why you would think that's not possible in plain text emails.
Not sure why you would think that's not possible in plain text emails.
Anyone know of mobile clients where you can use plaintext?
Newton, apparently. But it’s subscription. https://newtonhq.com/
Ok plain text has its advantages, agreed. But bottom posting is just going to lead to confusion in the normy world.
I agree that plaintext email was better in a lot of ways, but at this point, insisting on it will only confuse most correspondents. The days of plaintext email are over for all but niche use cases. Alas, but there it is.
I have my mail client set to show me only plain text. I only ever send plain text.
Every so often I receive a badly formed e-mail that requires me to click a single button that shows me the rich text.
There's no drama. I communicate just fine.
Every so often I receive a badly formed e-mail that requires me to click a single button that shows me the rich text.
There's no drama. I communicate just fine.
Learn to let go.
I try not to let the intrusive thoughts win, but this is exactly what I think almost every time there's an article on the supposed supriority of emacs or markdown (i.e., plain text).
This advice admittedly makes sense for conversations within a certain programming culture, but often doesn't make sense in other contexts where the use of email, and what people need from it, might be different. It's unfortunate that the proponents of this type of plaintext email try to push it so universally and uncompromisingly: it seems dismissive of other fields. It's actually one reason why I decided against using sourcehut for projects: with a project on sourcehut there is no way to avoid giving others the impression that you wholly support this view, and I don't.
In my experience, for example, plaintext email works poorly for many scientific discussions. Simple figures/plots are often quite helpful, and putting them as attachments that don't show up inline is annoying: it's enormously annoying when getting unformatted, figures-at-the-end Word documents for peer review that some people use rather than formatted PDFs, and it's annoying with email. Math is problematic: there are people who are fluent enough reading and writing LaTeX math source in emails, but as it becomes more complicated, it becomes both a burden to read for the LaTeX-fluent, and undecipherable to those not familiar: saying, eg, $a_i = 2 * i^2+5$ might be comprehensible enough to someone who doesn't otherwise use LaTeX, but what about when you start having \frac, \sim, \mathrm, \align, \gather, etc? Years ago, when I used to send exclusively plaintext emails, I found myself frequently getting to a point writing an email where I'd decide it would be better to send it as a PDF with something like "see attached", and that's annoying in a completely different way!
What's particularly unfortunate about the insistence on an uncompromising pure-plaintext, hard-line-break position is that there could be incremental, backwards-compatible improvements that would represent reasonable compromises rather than simply surrendering to the mess of full-HTML email and the horrors of many bulk HTML emails many of us see. Having a standard way of sending Markdown emails would open up the possibility, for example, of having reasonable, simple formatting, inline images, and with support, math, while not diverging from the text-centric format. It would also fix the flow vs verbatim problem. MIME multipart already makes it possible to send text/markdown parts, and it could be made backwards-compatible with other clients using multipart/alternative with text/plain and text/html renderings. I've actually done this from time to time, with some clients, but it is often frustrating and complex to set up as a custom process, and, of course, no one else's client is actually reading the text/markdown parts of my email.
Yes, Markdown has its inconsistencies, but they'd surely be better than the mess of HTML support inconsistencies, while still being better than plain text. In fact, when writing plain text emails back and forth, I find many people often end up naturally writing with at least some Markdown-like formatting anyway. I can also easily write messages in Element, or many other non-email places, and have basic formatting and often math with Markdown. MIME wouldn't even necessarily require that a single markup be chosen to support.
Yet I feel like the plaintext purists won't recognize that there are compromises that would work for a more diverse group of people, and so instead end up insisting everyone should follow practices that are well suited only for what they do. And so their view ends up being increasingly marginalized, when their resistance to the real mess of HTML support (both in display and composition) in email clients is quite reasonable. That's a problem that I think many people find frustrating, and an understanding approach to solving it would I think find far more support.
In my experience, for example, plaintext email works poorly for many scientific discussions. Simple figures/plots are often quite helpful, and putting them as attachments that don't show up inline is annoying: it's enormously annoying when getting unformatted, figures-at-the-end Word documents for peer review that some people use rather than formatted PDFs, and it's annoying with email. Math is problematic: there are people who are fluent enough reading and writing LaTeX math source in emails, but as it becomes more complicated, it becomes both a burden to read for the LaTeX-fluent, and undecipherable to those not familiar: saying, eg, $a_i = 2 * i^2+5$ might be comprehensible enough to someone who doesn't otherwise use LaTeX, but what about when you start having \frac, \sim, \mathrm, \align, \gather, etc? Years ago, when I used to send exclusively plaintext emails, I found myself frequently getting to a point writing an email where I'd decide it would be better to send it as a PDF with something like "see attached", and that's annoying in a completely different way!
What's particularly unfortunate about the insistence on an uncompromising pure-plaintext, hard-line-break position is that there could be incremental, backwards-compatible improvements that would represent reasonable compromises rather than simply surrendering to the mess of full-HTML email and the horrors of many bulk HTML emails many of us see. Having a standard way of sending Markdown emails would open up the possibility, for example, of having reasonable, simple formatting, inline images, and with support, math, while not diverging from the text-centric format. It would also fix the flow vs verbatim problem. MIME multipart already makes it possible to send text/markdown parts, and it could be made backwards-compatible with other clients using multipart/alternative with text/plain and text/html renderings. I've actually done this from time to time, with some clients, but it is often frustrating and complex to set up as a custom process, and, of course, no one else's client is actually reading the text/markdown parts of my email.
Yes, Markdown has its inconsistencies, but they'd surely be better than the mess of HTML support inconsistencies, while still being better than plain text. In fact, when writing plain text emails back and forth, I find many people often end up naturally writing with at least some Markdown-like formatting anyway. I can also easily write messages in Element, or many other non-email places, and have basic formatting and often math with Markdown. MIME wouldn't even necessarily require that a single markup be chosen to support.
Yet I feel like the plaintext purists won't recognize that there are compromises that would work for a more diverse group of people, and so instead end up insisting everyone should follow practices that are well suited only for what they do. And so their view ends up being increasingly marginalized, when their resistance to the real mess of HTML support (both in display and composition) in email clients is quite reasonable. That's a problem that I think many people find frustrating, and an understanding approach to solving it would I think find far more support.
Use aamath and gramscii.
https://github.com/gchudnov/aamath
https://github.com/gchudnov/aamath
Use markdown in e-mail.
But for general email communication the ship sailed many years ago and most people expect the ability to embed photos, tables, lists, and text formatting directly into messages so we can better communicate our intent using modern tools, without writing 'source code' to do it, even that as simple as Markdown (which is based on plain text email conventions). I wouldn't expect anything here to gain traction outside of niche communities, and the "why plain text is better" section is unconvincing.