[HN Gopher] Use Plaintext Email (2019)
___________________________________________________________________
Use Plaintext Email (2019)
Author : cyrc
Score : 91 points
Date : 2025-06-28 18:10 UTC (4 hours ago)
(HTM) web link (useplaintext.email)
(TXT) w3m dump (useplaintext.email)
| mattl wrote:
| Weird omission of some clients like Thunderbird from the list.
| miles wrote:
| https://useplaintext.email/#thunderbird
| mattl wrote:
| 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.
| zahlman wrote:
| 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.
| daneel_w wrote:
| Given the unfathomably bloated mess the desktop issue has
| become it doesn't entirely belong in the list of recommended
| clients.
| mattl wrote:
| There's no other cross platform GUI client I can think of.
| daneel_w wrote:
| Claws and Sylpheed come to mind.
| mattl wrote:
| * 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
| johnklos wrote:
| Thunderbird is basically a web browser that executes whatever
| you want it to.
| linhns wrote:
| Intentional or not, good omission though.
| SoftTalker wrote:
| 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).
| dsr_ wrote:
| I have not had problems doing it for the last 35 years, so if
| you are using terrible tools, you should probably fix that.
| SoftTalker wrote:
| 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.
| leakycap wrote:
| 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.
| jolmg wrote:
| 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.
| leakycap wrote:
| No one except fellow older tech heads seem to speak in
| the old ways
| F3nd0 wrote:
| A possible work-around that comes to mind is always
| prefixing your reply with some form of '(reply below)'.
| 8n4vidtmkvmk wrote:
| 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.
| alkonaut wrote:
| 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.
| antisol wrote:
| 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.
| yoz-y wrote:
| 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.
| beached_whale wrote:
| 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.
| mike-cardwell wrote:
| And use https://www.emailprivacytester.com to test that your
| email client is configured correctly
| beached_whale wrote:
| ERR connection refused like error. I guess gmail doesn't like
| them
| mike-cardwell wrote:
| Sorry about that. Try again now
| lovetox wrote:
| Also does not work with fastmail.com adresses
| mike-cardwell wrote:
| Was a local error. Fixed now
| xyst wrote:
| 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.
| beached_whale wrote:
| It still says you loaded it though.
| Bender wrote:
| 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.
| # 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
|
| _using WARN as testing example, change to DISCARD to drop them_
|
| [1] - https://en.wikipedia.org/wiki/Return_receipt
| beached_whale wrote:
| ooh good point, I ensure read receipts are disabled too. What
| a bad feature these days.
| 1718627440 wrote:
| Why 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.
| beached_whale wrote:
| you cannot depend on it and trackers/scammers/... use it as
| a way to see if your address is actually alive or not.
| Bender wrote:
| 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.
| geor9e wrote:
| 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.
| leakycap wrote:
| > 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.
| wazoox wrote:
| But I don't have Facebook. The worst is the incessant "call me
| back on WhatsApp". I don't use any of this crap.
| mattl wrote:
| What do you use? Not saying for a moment that anyone needs to
| use Facebook, but I'm curious if you use anything else...
| Fogest wrote:
| 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.
| sneak wrote:
| 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.
| kevincox wrote:
| 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.
| pomatic wrote:
| I'm sure markdown email has been done? But just didn't gain
| traction?
| jaffa2 wrote:
| 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.
| encom wrote:
| >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.
| zahlman wrote:
| 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.)
| kelnos wrote:
| 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.
| Spastche wrote:
| >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.
| Fogest wrote:
| I've never seen this.
| F3nd0 wrote:
| 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.
| layer8 wrote:
| 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].
|
| [0] https://vimhelp.org/change.txt.html#formatting
| nailer wrote:
| Why would I limit proper display of my email to 78 character wide
| monospace devices?
| mr_mitm wrote:
| They go into that at length in section 4.
| skydhash wrote:
| I think mobile viewing and most marketing email is around that
| limit. So not really a hard choice to make.
| alkonaut wrote:
| 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).
| Rotundo wrote:
| 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.
| rsync wrote:
| 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 ..."
| F3nd0 wrote:
| 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.
| mr_mitm wrote:
| Well, I as a recipient want plain text.
| Fogest wrote:
| 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.
| wazoox wrote:
| 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.
| bitwize wrote:
| "How about you use a mail client from this century." --the IT guy
| from a former job
| tonymet wrote:
| 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.
|
| https://github.com/tonymet/restmail
| rsync wrote:
| 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.
| layer8 wrote:
| 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.
| ChrisArchitect wrote:
| Some previous discussions:
|
| 2024 https://news.ycombinator.com/item?id=39033046
|
| 2022 https://news.ycombinator.com/item?id=32810515
|
| 2019 https://news.ycombinator.com/item?id=20513987
| dsp_person wrote:
| 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.
|
| [1] https://github.com/akissinger/dodo
| 1vuio0pswjnm7 wrote:
| https://en.wikipedia.org/wiki/ASCII_ribbon_campaign
___________________________________________________________________
(page generated 2025-06-28 23:01 UTC)