I use alpine, exclusively, for my personal and work emails.
It's beautiful, lightweight, efficient and can perform complex operations with keystrokes. Phishing URLs are glaringly obvious, I can quickly view full headers with a press of 'H', and no network traffic (trackers, pixels, counters) is generated by my interaction with the email.
There's one other thing:
If your mailtool runs over SSH and you send email to someone else running their mailtool over SSH on the same system ... the mail delivery is a local copy operation.
Which is to say: no rsync.net internal email has ever traversed a network.
Similar here with Mutt. And I’m happy to report that most emails still come with a text/plain part and don’t force you to use an HTML rendering fallback.
Another thing, set your mail readers to never automatically download images. This prevents the senders from knowing if/when/where from/and how often you read their message. There's always a button to download the linked images but its suprising how often it isn't needed. I do wish more mail clients had allow and deny lists for this function.
While I greatly prefer plain text email, trimming quoted text that isn't relevant to the reply, and replying inline rather than top-posting, all the major email clients discourage this, or at least don't make it easy by default, so it's a lost cause in 2025 (and was lost long before today).
I prefer plain text email, but this cranky unix-user anti-features tradition is a bad thing. Discord won over IRC because the people who make IRC clients and servers think the world in 1999 was the pinnacle of engineering. It wasn’t.
Rich text emails are great. So are variable-width fonts.
Yeah, the occasional bold word, inline link, heading or even the occasional image can make a message much more readable. If you don't like bold words your client can ignore that tag.
I think this is partly an over-reaction to some senders that go way overboard with bright colours a hundred images and complex layout that doesn't render right on your screen size. But just because a capability can be used poorly doesn't mean that it can't be used well.
I can also understand that some people choose to prefer the text version of messages because it is so common to "abuse" HTML. And for those people I even include a text fallback in case their client doesn't have the ability to do that.
Typing words to strangers online, worked just as well using IRC in 1999 as it does today. However my issue with Discord isn't the rich text, it's that Discord is a proprietary, centralised, CIA honeypot and a garbage company. Their Electron client is the least of their sins.
>Rich text emails are great.
They can be. They usually aren't. Yesterday I got a marketing email from an electricity provider. The unsubscribe link was 1302 characters of obfuscated Sendgrid bullshit. And it was full of tracking images and all links had click tracking. I wonder how this crap is GDPR compliant, because I'm fairly sure I never consented to any of this.
The main problem I always encountered when sending plan-text e-mails was quote formatting. The 72-character limit works well enough for my own reply, but when the quoted replies already consist of 72-character lines, adding several levels of indentation can break those up and mess up the formatting, since the client doesn’t extend the character limit for the quoted parts, resulting in something like this:
> > > Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
eiusmod
> > > tempor incididunt ut labore et dolore magna aliqua.
Leaving it like that annoys me, while fixing it by hand gets tedious very fast. I suppose some clients might know how to handle this automatically, but I’ve never had the fortune of using one. (And frankly, plain-text formatting is not among my most important criteria when choosing an e-mail client.)
As many gotchas as HTML e-mail might have in practice, I find the basic idea of giving messages semantic structure make a whole lot of sense. And as for top posting, I understand the criticism, but I find it very suitable for straightforward, back-and-forth exchanges, which comprise a decent part of my e-mail communication. So overall, I can’t say I’m entirely sold on plain-text e-mail.
This is kinda why "format=flowed" exists, if things fit on the screen, even deeply nested quotes remain readable if there's enough space. And vice versa, people on their phones can still read the text, albeit still to the extent that things can fit. No weird hard wrapping or stray words that could've fit at least.
With terminal-based email programs, you can usually configure your favorite editor for email authoring. And Vim, for example, comes with support for handling email quotes appropriately when using the (paragraph) text formatting commands like gq [0].
I work for one of those “evil” email software companies. Part of our business is external marketing and the much larger part of our business is internal employee communications. For over 15 years we kept track of the number of people who used HTML emails and the number of people who opted for plain text emails. It was something in the realm of 0.1% of all mail recipients had opted for plain text. That was in 2015. Today, that number would probably be even lower. So we stopped offering multipart emails entirely because the cost/benefit analysis doesn’t add up.
HTML emails aren’t sent only because that’s what the senders want. They are sent because that’s what the recipients want.
While I wholeheartedly agree with all of this, I feel like this ship may have sailed a very long time ago. Does it really make sense to continue fighting html email?
Composing a hyperlink-heavy technical message in plain text sounds like hell for both me and the receiver. Rich text is good because it intuitively increases the signal to noise ratio of your message; attempting to substitute plain text causes it to plummet due to all the sigil spam and mental context switching required to "jump" to non-inline links and resources.
I use Heirloom-mailx, which is not listed there. It uses bottom posting, and has no support for HTML.
The recommendations they mention are good ideas, although I might also add a few more:
- Allow the sender to prefer purely ASCII when applicable. (ASCII should not be mandatory (since you may want or need to use other character sets for other languages), although it should be possible to prefer it. This can also improve compatibility with the receiver.)
- When forwarding or replying to a plain text message, the reply should also be plain text by default.
- When the author of a message attaches a picture to a message and includes it inline in the HTML message, use a placeholder when converting it to plain text to make it clear to the receiver that there is a picture attached.
- Allow signatures to be disabled, and if a signature is added, then in the plain text format it should precede the signature by a line with two hyphens and one space.
I do and always did, but it's quite frequent that people call me on my weird emails (no colours ? no formatting ? weird !). It's a completely lost cause unfortunately in this eternal September.
Use whatever format and formatting your recipient wants. What they want is just a function of what client they use. If you are in an Outlook organization then just do whatever outlook does.
If you send to an external recipient you’ll need to guess, but if the recipient is at a medium to large corporation, chances are it’s Outlook there too.
And it’s not that people with html clients can’t read plaintext. It’s that it just looks odd to the recipient.
Once every 10000 emails I send something to one of the ”technical communities” mentioned. I can switch to plaintext then, or bottom/inline reply etc - because they expect or require it. But switching outright because a tiny group of niche techies find it a good idea? No, sorry. Email was eaten by gmail and Outlook and the only chance to change anything would be if their defaults changed (which isn’t happening).
The recipient will get what I deem to be appropriate. I will not, ever, stoop to the lowest common denominator of giving in to the tyranny of Outlook and its ilk.
I'm sending text, not a complete website to the recipient.
Yeah, I have to agree with this strongly. I worked at a University before and it was only the super old employees still using plain text email clients, everyone else was using Outlook. Most of the reason for not switching was simply due to a refusal to adapt and learn something new. Especially since there are more modern clients that also feature hotkeys/shortcuts that still allow you to do things quickly.
The people who refused to adapt to newer technology also caused slowdowns in other parts of the workplace as anything new that would be implemented in any site/service had to also try to account for people who wanted to do things old ways, instead of the faster new ways. Because they had 100 scripts they'd use to make the old way not suck as much and viewed that as better than learning the new way.
Realistically nobody is 100% productive, and the slight seconds that may be lost using a GUI based email client over something plaintext is insignificant.
On the other hand, it's perfectly reasonable not to give up the choice that you prefer and consider superior in many ways, just because ‘e-mail was eaten by Gmail and Outlook’. In fact, I personally feel great aversion to those two services and strongly dislike the idea of letting them dictate the way I use an open standard. If that was my main reason for ever using HTML e-mail (which, thankfully, it's not), I'd really rather just send plain text and have it look odd to the recipient.
Switch your display to greyscale. Disable javascript in your browser. When someone sends you a meme, instead of clicking X to dismiss the facebook login popup and see the public page, reply "sorry, I don't have facebook". Become insufferable.
I had to suffer with many dinosaurs in a University I worked at, and they did in fact do pretty much everything you mentioned. Was a pain in the ass to upgrade/improve sites while trying to make sure these sites could operate without JavaScript. It was such a waste of resources just for a few people who refused to learn new things. The old way wasn't really faster, they just refused to learn the new way.
One of them even was browsing many webpages using a command line based browser rather than just using something like Firefox.
Ugh. It's weird because on the one hand, I'd love a text-only email world. On the other hand, I wish people would just admit defeat. We lost. HTML email is the norm. We need to accept it and move on.
Attitudes like this are what hold back a lot of the traditional email clients. Instead of just supporting text and claiming that's how the Internet should be, they should be adding HTML support so they can talk to 99% of email users out there. It's not like we don't know how to render HTML in a terminal.
I want to use Emacs for mail. I use it for everything else. I use Outlook because I need to see the rendered HTML my coworkers and vendors send me. And as long as people are sticking to this idea that email can only ever be text, I'll be stuck using Microsoft's brain-dead idea of what an email client should be.
I used to care about this, but these days it just seem pointless, and I just can't summon a slice of my limited energy for attention to care about this. I also find many of the reasons listed to be somewhat irrelevant:
> HTML as a vector for phishing
> Privacy invasion and tracking
> Higher incidence of spam
> Mail client vulnerabilities
These are all potentially reasons to disable the display of HTML email in your own mail client, but they aren't a reason not to send HTML email. As a sender, I know I'm not trying to phish my recipient, or invade their privacy or track them, or spam them, or try to trigger a mail client vulnerability. So these just don't matter.
From the recipient's point of view, many people receive HTML emails (that don't have an embedded plain-text alternative), and actually do need to read those emails. The kind of person who doesn't, likely already is a firm believer in plain-text-only and doesn't need to be convinced.
And other reasons seem dubious:
> HTML emails are less accessible
This is odd, because HTML has accessibility features built into it. Certainly a bunch of plain text is easier for a screen reader to deal with, but only if the sender doesn't care about conveying formatting or nuance at all. Later in the piece, the author suggests using asterisks, underscores, etc. to indicate bold/italic/etc., but I expect screen readers don't know what that's supposed to mean, so using such a thing will make your emails less accessible, not more.
> Some clients can't display HTML emails at all
The kind of people who use mail clients that can't display HTML email at all are probably not in your target audience if you are going to send HTML email. If people like that have deliberately chosen to use software that can't display everything out there, that's their choice, and they can deal with the consequences.
And anyway:
> In a text-only interface it's not possible to render an HTML email, and instead the reader will just see a mess of raw HTML text.
Then that's a missing feature in the terminal mail reader. If lynx and links can render HTML to a terminal in a useful, readable way, a mail reader can do so too.
> A lot of people simply send HTML emails directly to spam for this reason.
"A lot" is doing a bit of work there. I guess "a lot" of people in the author's small bubble?
> Rich text isn't that great, anyway
That's opinion, not fact, and reasonable people can reasonably disagree. I happen to be one of them. I actually don't use much in the way of text styling in my emails, but it's nice to have the option, and as someone who does sometimes receive actually-useful, non-spam HTML emails, the presentation/styling often does add to the experience, not detract.
rsync|8 months ago
It's beautiful, lightweight, efficient and can perform complex operations with keystrokes. Phishing URLs are glaringly obvious, I can quickly view full headers with a press of 'H', and no network traffic (trackers, pixels, counters) is generated by my interaction with the email.
There's one other thing:
If your mailtool runs over SSH and you send email to someone else running their mailtool over SSH on the same system ... the mail delivery is a local copy operation.
Which is to say: no rsync.net internal email has ever traversed a network.
That's nice.
layer8|8 months ago
beached_whale|8 months ago
Bender|8 months ago
[1] - https://en.wikipedia.org/wiki/Return_receipt
mike-cardwell|8 months ago
SoftTalker|8 months ago
antisol|8 months ago
Plain text email continues to work just fine for me every day.
yoz-y|8 months ago
I don’t know what client they are using, or if they never received a properly formatter reply in their life.
dsr_|8 months ago
sneak|8 months ago
Rich text emails are great. So are variable-width fonts.
kevincox|8 months ago
I think this is partly an over-reaction to some senders that go way overboard with bright colours a hundred images and complex layout that doesn't render right on your screen size. But just because a capability can be used poorly doesn't mean that it can't be used well.
I can also understand that some people choose to prefer the text version of messages because it is so common to "abuse" HTML. And for those people I even include a text fallback in case their client doesn't have the ability to do that.
encom|8 months ago
Typing words to strangers online, worked just as well using IRC in 1999 as it does today. However my issue with Discord isn't the rich text, it's that Discord is a proprietary, centralised, CIA honeypot and a garbage company. Their Electron client is the least of their sins.
>Rich text emails are great.
They can be. They usually aren't. Yesterday I got a marketing email from an electricity provider. The unsubscribe link was 1302 characters of obfuscated Sendgrid bullshit. And it was full of tracking images and all links had click tracking. I wonder how this crap is GDPR compliant, because I'm fairly sure I never consented to any of this.
F3nd0|8 months ago
> > > Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
eiusmod
> > > tempor incididunt ut labore et dolore magna aliqua.
Leaving it like that annoys me, while fixing it by hand gets tedious very fast. I suppose some clients might know how to handle this automatically, but I’ve never had the fortune of using one. (And frankly, plain-text formatting is not among my most important criteria when choosing an e-mail client.)
As many gotchas as HTML e-mail might have in practice, I find the basic idea of giving messages semantic structure make a whole lot of sense. And as for top posting, I understand the criticism, but I find it very suitable for straightforward, back-and-forth exchanges, which comprise a decent part of my e-mail communication. So overall, I can’t say I’m entirely sold on plain-text e-mail.
Avamander|8 months ago
layer8|8 months ago
[0] https://vimhelp.org/change.txt.html#formatting
matty22|8 months ago
HTML emails aren’t sent only because that’s what the senders want. They are sent because that’s what the recipients want.
nailer|8 months ago
skydhash|8 months ago
mr_mitm|8 months ago
mcv|8 months ago
Avamander|8 months ago
colonial|8 months ago
pbronez|8 months ago
zzo38computer|8 months ago
The recommendations they mention are good ideas, although I might also add a few more:
- Allow the sender to prefer purely ASCII when applicable. (ASCII should not be mandatory (since you may want or need to use other character sets for other languages), although it should be possible to prefer it. This can also improve compatibility with the receiver.)
- When forwarding or replying to a plain text message, the reply should also be plain text by default.
- When the author of a message attaches a picture to a message and includes it inline in the HTML message, use a placeholder when converting it to plain text to make it clear to the receiver that there is a picture attached.
- Allow signatures to be disabled, and if a signature is added, then in the plain text format it should precede the signature by a line with two hyphens and one space.
dsp_person|8 months ago
I'd settle for something markdown-like rather than full-blown html. Basic headings, lists, and inline images are all I want.
[1] https://github.com/akissinger/dodo
zahlman|8 months ago
> Visit Settings → Appearance
> Set "Composer Mode" to "Plain Text"
This is out of date; the setting is now in "Messages and Composing" (after a break), not in "Appearance". (You'll have to scroll down a fair bit.)
1vuio0pswjnm7|8 months ago
1vuio0pswjnm7|8 months ago
But plaintext may not always be ASCII.
Campaign started in 1998. How common was non-ASCII plaintext in 1998.
layer8|8 months ago
ChrisArchitect|8 months ago
2024 https://news.ycombinator.com/item?id=39033046
2022 https://news.ycombinator.com/item?id=32810515
2019 https://news.ycombinator.com/item?id=20513987
wazoox|8 months ago
alkonaut|8 months ago
Use whatever format and formatting your recipient wants. What they want is just a function of what client they use. If you are in an Outlook organization then just do whatever outlook does.
If you send to an external recipient you’ll need to guess, but if the recipient is at a medium to large corporation, chances are it’s Outlook there too.
And it’s not that people with html clients can’t read plaintext. It’s that it just looks odd to the recipient.
Once every 10000 emails I send something to one of the ”technical communities” mentioned. I can switch to plaintext then, or bottom/inline reply etc - because they expect or require it. But switching outright because a tiny group of niche techies find it a good idea? No, sorry. Email was eaten by gmail and Outlook and the only chance to change anything would be if their defaults changed (which isn’t happening).
Rotundo|8 months ago
The recipient will get what I deem to be appropriate. I will not, ever, stoop to the lowest common denominator of giving in to the tyranny of Outlook and its ilk.
I'm sending text, not a complete website to the recipient.
Fogest|8 months ago
The people who refused to adapt to newer technology also caused slowdowns in other parts of the workplace as anything new that would be implemented in any site/service had to also try to account for people who wanted to do things old ways, instead of the faster new ways. Because they had 100 scripts they'd use to make the old way not suck as much and viewed that as better than learning the new way.
Realistically nobody is 100% productive, and the slight seconds that may be lost using a GUI based email client over something plaintext is insignificant.
F3nd0|8 months ago
mr_mitm|8 months ago
geor9e|8 months ago
wazoox|8 months ago
Fogest|8 months ago
One of them even was browsing many webpages using a command line based browser rather than just using something like Firefox.
leakycap|8 months ago
Never send facebook links, problem solved. It's poor form.
The little "X" you refer to is rarely there for those of us who don't ever log in.
tonymet|8 months ago
Gmail’s smtp gateway breaks plaintext formatting, restmail preserves it.
https://github.com/tonymet/restmail
binary132|8 months ago
spauldo|8 months ago
Attitudes like this are what hold back a lot of the traditional email clients. Instead of just supporting text and claiming that's how the Internet should be, they should be adding HTML support so they can talk to 99% of email users out there. It's not like we don't know how to render HTML in a terminal.
I want to use Emacs for mail. I use it for everything else. I use Outlook because I need to see the rendered HTML my coworkers and vendors send me. And as long as people are sticking to this idea that email can only ever be text, I'll be stuck using Microsoft's brain-dead idea of what an email client should be.
bitwize|8 months ago
kelnos|8 months ago
> HTML as a vector for phishing
> Privacy invasion and tracking
> Higher incidence of spam
> Mail client vulnerabilities
These are all potentially reasons to disable the display of HTML email in your own mail client, but they aren't a reason not to send HTML email. As a sender, I know I'm not trying to phish my recipient, or invade their privacy or track them, or spam them, or try to trigger a mail client vulnerability. So these just don't matter.
From the recipient's point of view, many people receive HTML emails (that don't have an embedded plain-text alternative), and actually do need to read those emails. The kind of person who doesn't, likely already is a firm believer in plain-text-only and doesn't need to be convinced.
And other reasons seem dubious:
> HTML emails are less accessible
This is odd, because HTML has accessibility features built into it. Certainly a bunch of plain text is easier for a screen reader to deal with, but only if the sender doesn't care about conveying formatting or nuance at all. Later in the piece, the author suggests using asterisks, underscores, etc. to indicate bold/italic/etc., but I expect screen readers don't know what that's supposed to mean, so using such a thing will make your emails less accessible, not more.
> Some clients can't display HTML emails at all
The kind of people who use mail clients that can't display HTML email at all are probably not in your target audience if you are going to send HTML email. If people like that have deliberately chosen to use software that can't display everything out there, that's their choice, and they can deal with the consequences.
And anyway:
> In a text-only interface it's not possible to render an HTML email, and instead the reader will just see a mess of raw HTML text.
Then that's a missing feature in the terminal mail reader. If lynx and links can render HTML to a terminal in a useful, readable way, a mail reader can do so too.
> A lot of people simply send HTML emails directly to spam for this reason.
"A lot" is doing a bit of work there. I guess "a lot" of people in the author's small bubble?
> Rich text isn't that great, anyway
That's opinion, not fact, and reasonable people can reasonably disagree. I happen to be one of them. I actually don't use much in the way of text styling in my emails, but it's nice to have the option, and as someone who does sometimes receive actually-useful, non-spam HTML emails, the presentation/styling often does add to the experience, not detract.
Spastche|8 months ago
I've seen a lot of email providers flag random emails for having weird HTML. why take the chance of non-delivery at all? send plain text.
mattl|8 months ago
miles|8 months ago
johnklos|8 months ago
daneel_w|8 months ago
linhns|8 months ago