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.
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.
Kind of like how one adjusts their language / choice of words / choice of topics based on their recipient.
The easiest way for this crusade to succeed would be to take aim at Outlook and Gmail and try to make them change defaults.
Plain text email continues to work just fine for me every day.
I don’t know what client they are using, or if they never received a properly formatter reply in their life.
Loading images through their servers and throwing off the tracking software.
# 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_1004
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.
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.
One of them even was browsing many webpages using a command line based browser rather than just using something like Firefox.
Rich text emails are great. So are variable-width fonts.
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.
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.)
> 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.)
> 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.
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.
> > > 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.
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.
https://en.wikipedia.org/wiki/Robustness_principle
"... be conservative in what you send, be liberal in what you accept ..."
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.
Gmail’s smtp gateway breaks plaintext formatting, restmail preserves it.
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.
2024 https://news.ycombinator.com/item?id=39033046
I'd settle for something markdown-like rather than full-blown html. Basic headings, lists, and inline images are all I want.
mattl•5h ago
miles•5h ago
mattl•4h ago
I don’t think you’re going to get many people switching from mail.google.com to something in a terminal emulator straight away.
zahlman•4h ago
> 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.
daneel_w•4h ago
mattl•4h ago
daneel_w•4h ago
mattl•2h ago
* 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
daneel_w•4m ago
johnklos•4h ago
linhns•4h ago