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.
That's nice.
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.
> 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.
I have received some messages that don't, but in some cases the HTML is written clearly so that the message is still easily readable despite that.
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.
And also disable MDN's [1] in stand-alone email clients and discard them in MTA's if your user-base is cool with it.
using WARN as testing example, change to DISCARD to drop them# grep MDN /etc/postfix/header_checks change WARN* to discard to drop them. /^Subject: MDN: / WARN MDN_Seen_1000 /^Subject: Read-Receipt-To: / WARN MDN_Seen_1001 /^Subject: Disposition-Notification-To: / WARN MDN_Seen_1002 /^Message-ID: \<receipt/ WARN MDN_Seen_1003 /^Subject: Read: / WARN MDN_Seen_1004Why though? Sometimes it is useful to know whether the mail got delivered, i.e. for handing in assignments. Also the read notification is only sent on recipient wish.
you cannot depend on it and trackers/scammers/... use it as a way to see if your address is actually alive or not.
DSN's Delivery Status Notifications are absolutely useful otherwise they never would have been created. Read-replies and out of office auto-replies that reply to non corporate primary domains are used to validate email addresses for spammers. Even DSN's can be abused this way. Older versions of Exchange would not limit out-of-office replies to the corporate domains.
One can drop read-replies and even out-of-office auto-replies without dropping specific DSN's. It is up to each organization how they wish to handle these. Some financial institutions will go full BOFH Bastard Operator from Hell, like me and some will cherry pick what goes through such as limiting responses to employees. Some will let everything through to justify the purchase of their anti-spam, anti-malware third party service. I was brought into existence in the 2150th level of hell.
So that is the cool thing about such rules is that one can cherry pick whichever meets the needs and requirements of their organization and this is just the beginning of what one can do. The first step in this process is to enable logging of Subjects, Attachment Names / Sizes, FCrDNS and others to syslog then start building reports to see what is leaking out of ones organization and what nonsense is flooding ones organization. Some DLP's Data Loss Prevention appliances can do some of this too but they can be pricey and may leak data to yet another third party. As a proper BOFH I keep logs in-house. Logging to a third party can get extra painful with newer privacy laws in some countries.
I always front-end exchange servers with multiple Postfix servers with large queues so that work can be done without losing things, extra logging can be enabled and extra anti-spam capabilities can be enabled or added.
Aren't auto-replies set up by your users voluntarily? Would really annoy me if the server admin is working against his users.
A spammer still knows whether an address exist, because otherwise the mail would bounce. Unless you also block those? Would that even be an RFC-conformant server? So if I send a mail to your server and have I typo in the address, I wouldn't even know? That sucks, even more so, since a lot of communication is nowadays forced into email and it is silently assumed that every message has arrived by laymans.
Also do you think a spammer cares if your address actually exists? I would expect them to send millions of messages regardless. Curating the addresses would mean that they need to actually spend resources. Given the already low conversion rate, non-existing addresses are just noise. Unless you think about targeted phishing? In this case they probably know your address already.
Would really annoy me if the server admin is working against his users.
I did mention in the top post, "if your user-base is cool with it." Not everyone is and that's why I leave it up to the majority. In places that had mismanaged email for decades it can be a welcome change. In one company I brought the spam down from about 50K+ spam messages per hour down to a dozen per day spread across the entire company. It was not without some pain especially for the executives that had buddies spawning third party companies out of their garages but I told them to suck it up. The users were overjoyed to finally be able to use email again since they depended on it to do their daily job.
Also do you think a spammer cares if your address actually exists?
They do and don't. The cost to them is nothing in terms of resources since they are using infected computers to do most of the work but if they have too many dead addresses it is easier for junior admins and cheap anti-spam software to spot them which can mean most of their spam ends up unseen. Proofpoint is just one example of software that can spot this and instantly start sending all their emails to quarantine. For existing employees that had their email address leaked by out-of-office messages and other notifications they had to rely on my anti-spam measures and third parties in companies that permitted this. New employees benefited more from these measures.
Some of the RFC's are conditionally ignored by the big providers and it annoys me just as much as I am sure it annoys you because there are timeouts they artificially shorten well below the RFC "must" values vs, "should". The rate limits on the big providers are also obscenely low. This is mostly the big "free" providers which are anything but free. Yes targeted phishing is its own massive topic. I was the number two recipient of targeted phishing at one company and I did not see any of it thanks to proofpoint but they generated some nifty reports. I'm glad they took care of it because one of my hobbies is tracking down shady people IRL and that quickly turns into a time sink. Now that I am retired I can spend unlimited time finding the shifty individuals.
Any way to add something like this to fastmail sieve system? thanks
ooh good point, I ensure read receipts are disabled too. What a bad feature these days.
And use https://www.emailprivacytester.com to test that your email client is configured correctly
Also does not work with fastmail.com adresses
> fastmail.com adresses
Curious, what was the result for fastmail.com addresses ?
Was a local error. Fixed now
ERR connection refused like error. I guess gmail doesn't like them
Sorry about that. Try again now
What’s interesting to see here is Apple’s "Protect Mail Activity" option working as advertised.
Loading images through their servers and throwing off the tracking software.
It still says you loaded it though.
What Apple does is load all images in all emails on their server, instantly when they arrive, before you open the email or not. So the sender can't know if you saw the email and track email open rates.
I think Gmail does the same now too, I tested that site with my Google Workspace address, it got hard spam filtered (never even reached the spam folder) but it still saw 3 image loads from a google server.
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).
It's only a lost cause if you decide to let it be.
Plain text email continues to work just fine for me every day.
My heart sank when I inline replied to a long email from a clinic, only to get a reply that “you only said hello and your message is empty”.
I don’t know what client they are using, or if they never received a properly formatter reply in their life.
Crappy helpdesk software does that. I've never bothered to ask those companies what garbage they're using though.
I have not had problems doing it for the last 35 years, so if you are using terrible tools, you should probably fix that.
You misunderstood, or I wasn't very clear. I have and use good email tools. I only meant that the crusade to get everyone else to follow is lost.
I am the one oddball in my office who doesn't use Outlook and who sends plain-text emails with ">" prefixed quotes. But I'm under no illusions that anyone else is going to be convinced, and I no longer make any effort to try.
Modern email clients are getting too clever for their own good, and I have no choice on what client others use.
For decades, inline replies worked perfectly—you'd quote the relevant part and respond right underneath it. But now email apps are "helping" by trimming messages into compact views, cutting off replies right at the first quoted section unless someone taps "show more."
I've basically abandoned inline replied and have gone back to dumping everything at the top like it's 1995.
The irony is these apps think they're making email better by hiding "clutter," but they're actually making conversations harder to follow.
You can still make the decision whether to top-post or inline-post based on your recipient. Programmer's mailing list -> inline post. Family member -> top post. You can send a stranger an inline post, somehow confirm they were able to view it, and include them in your mental whitelist of people that understand inline posting.
Kind of like how one adjusts their language / choice of words / choice of topics based on their recipient.
No one except fellow older tech heads seem to speak in the old ways
A possible work-around that comes to mind is always prefixing your reply with some form of ‘(reply below)’.
I wrote a tool for my boss years ago that would reformat emails for plain text and put those arrows and fix the indentation. He loved it so much. Older gentleman. I guess that's how he did it in his day and never saw the need to change. Glad I could make him happy with like 1 day of work. Tiny app.
Making more than a completely negligible group of people change tools - or even the settings of their tools - is what’s a lost cause.
The easiest way for this crusade to succeed would be to take aim at Outlook and Gmail and try to make them change defaults.
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?
It does not and it's tedious when people do so unconditionally. I've seen systems not even accept multipart/alternative and it's just wack.
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.
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 wish we could all just agree on markdown.
I spent some time hacking on things with dodo [1] but have fallen back to thunderbird for the time being.
I'd settle for something markdown-like rather than full-blown html. Basic headings, lists, and inline images are all I want.
For Proton users:
> 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.)
ASCII is always plaintext.
But plaintext may not always be ASCII.
Campaign started in 1998. How common was non-ASCII plaintext in 1998.
Except that “plain text” is more general than ASCII.
Yes, although often ASCII will be suitable. (Sometimes, other character sets are helpful, though.)
Use plain text websites.
Hard no.
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).
I disagree with you vehemently.
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.
Both you, and your parent, should consider changing your view in favor of Postel's law:
https://en.wikipedia.org/wiki/Robustness_principle
"... be conservative in what you send, be liberal in what you accept ..."
I don’t see how that applies to be honest. The default has changed to html a long time ago and that’s what people expect.
What would be great would be if clients detected when I send an email with only text and just chose to format it as plaintext then BUT importantly, that th e reverse happens in the reading client: it formats it the same regardless, so my text email doesn’t look strange. Needs to render with the same font etc.
it almost never happens that I send a plain text email though since my org like so many prescribes the use of an image as signature. Not to mention that 9 emails out of 10 contains other images anyway.
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.
There are other disadvantages of the working of many modern software programs though, including undesirable features, and you might not want to use the sender's formatting, and missing stuff, and stuff that doesn't work as well. Shortcut keys is not the only issue.
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.
Well, I as a recipient want plain text.
You’ll need to hope I can guess it. But in most orgs this isn’t a problem. My guess is nearly all email is within an organization where no one chooses mail programs.
If you send a plain text email you’ll likely get one in response. But the chance you’d get an initial email as plain text is pretty slim. There is no way it somehow becomes the default except in situations where it’s clearly prescribed up front.
Why would I limit proper display of my email to 78 character wide monospace devices?
I think mobile viewing and most marketing email is around that limit. So not really a hard choice to make.
Mobile is often less than that and any hard wrapping looks absolutely horrid. I mean, hard wrapping in general looks disgusting on anything besides an ancient VT-80, but it looks extra bad on mobile. Only tolerable option for plain text is "format=flowed".
Hard wrapping is nice. My screen is too large for any kind of flowed text so I often have to add the extra margin that is required to get back between 80 and 120 characters. On mobile, you can just rotate the phone.
Sounds like you need a client whose width can be configured. Rather than imposing arbitrary, non-semantic formatting on all messages.
I've had autorotation turned off for a decade, I'm not turning it on for your email. It's a bit odd that plain text proponents don't want HTML imposed on them but are okay with imposing this.
iPhone and the most popular android devices are much less.
They go into that at length in section 4.
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.
I'm sure markdown email has been done? But just didn't gain traction?
GNOME Evolution supports Markdown natively (I believe either raw or rendered to HTML on send; I use the latter.)
Mailmate on macos solves this very nicely. As a bonus my html mails have never looked better and i get the bonus of writing in text using markdown . Currently evaluating it.
There's no The Markdown that's standardised (or safe enough), that it could be implemented like that unfortunately.
Thank you. I hate when people say “Markdown” as if it was a single language and not a collective term for 100+ kinda similar languages.
For macOS check MailMate : https://freron.com/
>1999 was the pinnacle of engineering
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.
If you don’t like the emails your electricity provider sends you, don’t give them your email address, or filter all of their emails to the trash.
Rich text emails as a format and as a feature are great. If you don’t like the content of emails that doesn’t change the issue at all. In the alternative you are proposing, the unsubscribe link isn’t clickable at all.
(I also dislike Discord for many of the same reasons, but it won because it is better for users, because it has more features. Your complaints about it, which I share, are irrelevant to this discussion.)
>just don't get spammed bro
Great solution! I wish I'd thought of that.
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.
I use uBlock Origin with everything blocked by default. Most websites actually load fine. For those that don't, I manually whitelist just the scripts they need and then press the lock to remember that for the next time I visit that website.
As a non dinosaur, It's not actually hard nor tedious to not use JavaScript everywhere and I would recommend it. I think the problem in your situation may have been that those people actively made their problem your problem.
> instead of clicking X to close the facebook login popup, reply "sorry, I don't have facebook"
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.
But I don't have Facebook. The worst is the incessant "call me back on WhatsApp". I don't use any of this crap.
What do you use? Not saying for a moment that anyone needs to use Facebook, but I'm curious if you use anything else...
I use Signal. I also use Telegram for non-important stuff.
i made a sendmail CLI for sending plain text mail using gmail and outlook REST APIs.
Gmail’s smtp gateway breaks plaintext formatting, restmail preserves it.
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.
>but they aren't a reason not to send HTML email
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.
If anything, only plaintext emails are considered suspicious at this point. Some spam filters discourage having mismatching plain text and HTML parts though.
I've never seen this.
Some previous discussions:
2024 https://news.ycombinator.com/item?id=39033046
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.
"How about you use a mail client from this century." --the IT guy from a former job
Weird omission of some clients like Thunderbird from the list.
Yet it’s missing from the recommendation list.
I don’t think you’re going to get many people switching from mail.google.com to something in a terminal emulator straight away.
The recommendations list is described thus:
> These clients all compose plain text emails by default, with correct quoting and text wrapping settings, requiring no additional configuration to use correctly.
Thunderbird is not in the list because it requires configuration.
The recommended list includes several GUIs and web clients.
I don't really understand how people are checking their email without configuring an email client, but then I realized I don't care and once again I should just never interact with anything from sr.ht
- [deleted]
Thunderbird is basically a web browser that executes whatever you want it to.
Given the unfathomably bloated mess the desktop issue has become it doesn't entirely belong in the list of recommended clients.
There’s no other cross platform GUI client I can think of.
Claws and Sylpheed come to mind.
* https://www.claws-mail.org/downloads.php
* https://sylpheed.sraoss.jp/en/download.html
Compare those to https://www.thunderbird.net/en-US/thunderbird/all
I can't find a current download for modern macOS on either of the first two
Shouldn't need Homebrew to install a GUI email client.
Really shouldn't need to explain that, IMO.
Has the goal post been moved enough now? The author shouldn't need to explain why a 350 MiB monster like Thunderbird isn't in their list of recommended options for making the move to basic plain-text email.
It must be difficult for you to appreciate the idea of not gatekeeping email. If you’re trying to get people to use plain text email in 2025, Thunderbird is the only obvious choice for a GUI client.
It runs everywhere and can be installed by anyone.
Why do want to make it harder for people?
I'm not trying to gatekeep anything or complicate for anyone. I didn't write the list, I just agree with it for obvious reasons relating to plain-text e-mailing. I run Thunderbird. I think you ran out of talking points and had to switch to accusations.
Your suggestion was that Mac users who want a a GUI should use homebrew.
If that’s not gatekeeping I don’t know what to tell you.
Intentional or not, good omission though.