Use plaintext email | Hacker News Reader

Use plaintext email

useplaintext.email

337 pointsddevault334 comments

> Rich text features desirable for end users include things like inline images, bold or italicized text, and so on. However, the tradeoff isn't worth it. Images can simply be attached to your email, and you can employ things like asterisks, /slashes/, _underscores_, or UPPERCASE for emphasis.

Well, why bother writing his own post in rich text then? He has headings, bold, links, grey font at the bottom, image.

Don't get me wrong - for high security systems/environments, plaintext is way to go. For everyday life use cases I prefer html. Although with Markdown rendered text I would be pretty happy. And enough for author to cover his post sans the green/red boxes and grey text.

The page footer might interest you. It directly answers your question.

Quoting

  "But if plaintext is so good, why is this page written in HTML?" 
  This is a reference document, not an email, you twit.

But emails can be reference documents too! In fact I would argue most work emails that are longer than a few lines are a reference document of some sort.

Then you are better off using some format that can stand alone as a file such as PDF. If it is a reference document that is intended to be edited on an ongoing basis it is better to use something like a wiki. Having to root around in your email to find a reference document is pretty inefficient and annoying.

All of the reasons given against HTML emails hold at least equally well against PDF: it's a vector for phishing and tracking, ripe with client vulnerabilities, less accessible and not displayable on a terminal. For me as a reader having to read both an E-Mail and the attached PDF is also annoying, and many people will simply skip reading the PDF.

We send syntax highlighted code all the time via email at my job. I hope you're not suggesting we should use PDF instead?

And no, creating snippets on a wiki is also an extra unnecessary step. Email is just easier and faster.

And if its a reference document it should be in source control and properly versioned - not to go all BS5750/ISO 9000 here :-)

Exactly, work mailboxes are a treasure trove of automatically-archived information. I'd argue that these days, emails form more of a "knowledge base" than any other single repository of information for most organisations.

This is very true and yet the search tools supplied with these knowledge bases are terribly inadequate. Is there a better, standalone tool out there for turning email archives, from multiple sources, into a usable database with a powerful query language?

email is a terrible place to keep reference documents.

"where's the information on that?" "oh, you should have it in your email somewhere. I think I got one a few months ago about it"

no. just. no. If you care _at all_ about your reference documents you get them out of email ASAP.

And that's ignoring that anyone can delete old emails and thus not have what you considered a reference doc but they just considered old mail. Or that the server could loose your emails and no-one has they synced locally these days.

> email is a terrible place to keep reference documents.

Newsgroups are better in that regard. You can reference the message using the message-id value. A lot of newsgroups would have FAQS posted every 30 days or so. A reference document that's periodically updated could be sent the same way.

If your emails are reference documents then I would argue that you're using email wrong.

That's pretty much a non-sequitur. HTML is better in email as well as "reference documents" according to the opinions of many. You don't like thing. Okay.

RFC 822 is plaintext. That's a reference document. Don't see why HTML would be an argument for a reference document. In fact, tex is a good format for reference documents, it diff's well and can produce .ps/.pdf outputs among others.

Fair. I like that minimal formatting there anyway.

But often I have to communicate via email, report on complex issues, etc. It is nice to have some headings, tables, images in there.

Agreed. As much as I like plain text email personally, having inline images etc. is really helpful sometimes.

The key is sometimes. Plain text by default, rich text when required.

Software that would strip all html out of emails for security would be handy

Before MIME was common, people used to insert uuencoded data within the email message. IIRC, certain email clients would display the decoded content inline with the surrounding text.

Why not use MS Word or some other tool designed for writing documents then ?

Am I crazy for using email to send memos? Those serve as reference documents too, while creating a papertrail.

The very last clause in that sentence answers a question that I hadn't even thought to ask.

I thought it was very odd for what is essentially a marketing post.

ha! and i really love the design of this site- just the right amount of design & css styling to elegantly communicate the message..

Email is supposed to be easy to quote, just like you’ve used a block quote in your comment. I assume it’s obvious that rich text is difficult to quote, but a quick explanation is that the invisible formatting characters used to represent rich text behave inconsistently when re-contextualized for a quote.

> "Email is supposed to be easy to quote"

Since when? I have never heard anyone say this in my entire life. I want emails to look good. So I guess people are different and we can't draw a simple conclusion about what people want from email?

I’m not sure what you’re saying here. Is it that you’ve never heard of the concept of quoting a passage of an email? Or are you saying “sure people do that, but it doesn’t matter if it’s easy”?

> it’s obvious that rich text is difficult to quote

I don't see how. It's just the same as plain text.

It would be easy if there were a single accepted way to quote in rich text. (Seriously, the block quote tag has been around for eternity!) I don't think it works well in plain text either.

HTML has a hierarchical structure.

<div class="quote"> quoted content </div>

It's far better than trying to keep count of how many ">" are in play, and deal with the vagaries of soft linebreaks and hard linebreaks and wrapping of plaintext.

Ok, but then your email client should be smart enough that if, for example, you quote two bullet points from a list it doesn't quote them as

    <div class="quote">
      <li>Second</li>
      <li>Third</li>
    </div>

Without the surrounding `<ul>`. Luckily Thunderbird is smart enough to do this. I don't know about other clients.

You can use markdown with https://markdown-here.com/. It allows composing emails in markdown and sending email as multipart message with plain text markdown plus rendered html. Discussed in https://news.ycombinator.com/item?id=15646425

Some people sending plain text mails also wrap them manually.

If my window is small (maybe because I am using a small screen), the text is painful to read. And a non manually wrapped plain text is not wrapped at all in some cases.

By all means, send me plain text mails, it will be lighter for my self-hosted inbox, but don't wrap them manually.

If you are going to abuse /this/ kind of `formatting`, however, you are making your mail harder to read for me. These are tags anyway, just not HTML tags. I'd prefer you use the real formatting that is correctly handled in most cases, but I will adapt.

> There are two main types of emails on the internet: plaintext and HTML. The former is strongly preferred

You will need to back this up because this is not what I observe.

My email client takes care of my privacy and my security, and you can use it too if you are concerned, it's a cross platform maintained free software. It's okay.

My problems with HTML emails is colors: if you want to use something like a night mode, you will see emails with hard coded white background and black texts, or worse, only black texts. You may be able to ignore colors but people will assume you can see them. Maybe an extension like dark background on light texts when using a browser for reading emails who do the trick, but I don't.

I'm very sad about manual line wrapping too (since I love plain text otherwise), but unfortunately it's in the MIME standard.

> Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.

Of course with HTML, your source code can adhere to this standard while still having arbitrarily long lines of text...

https://mailformat.dan.info/body/linelength.html

It’s an outdated standard and a terrible idea nowadays, since it makes emails unreadable on mobile devices. I’d really love to use plain-text emails — hell, I use plain text for everything — but they’re sadly not a good idea today, unless you want your emails looking like crap on every mobile device.

The suggestion to use `format=flowed` doesn’t help, as the standard is ill-supported: https://fastmail.blog/2016/12/17/format-flowed/

I’ve researched the issue far and wide and the only way to have responsive, nicely wrapped emails is using HTML.

This is the one blemish (in my view) on fastmail's record. I love them otherwise.

I initially came to the same conclusion as you, but after receiving one too many badly quoted HTML emails (and after some lost hours unsuccessfully trying to understand how fastmail web, gmail, thunderbird and ios mail.app do HTML quoting (hint: they're all subtly different)), I decided to double-down on format=flowed.

The main arguments in the fastmail blog you reference are:

1. Lack of support

2. Lack of people sending/reading plain text email

3. HTML bloat is no longer a real concern

Then they make some implementation difficulty arguments

1. Implement an editor that supports only semantic blockquoting

2. Fix "embarrassing line wrap" due to clients that lack support

For the first 3 arguments, I would say that lack of support from other clients doesn't mean that a client shouldn't support it. I regularly posted to usenet with Thunderbird (which supports format=flowed) and had people respond to my posts with clients that didn't support that feature.

To them (and when viewing the message source), the messages still appeared to be hard-wrapped. When viewing the messages in Thunderbird, the parts I typed were softwrapped. "Embarrassing line wrap" simply did not happen (no matter many times a given piece of text was quoted). "Embarrassing line wrap" was only an issue because certain clients would further re-wrapped quoted text without taking the quote markers into account instead of just leaving it alone or properly re-wrapping it.

Text editors like emacs and vim have features that will easily re-wrap quoted email text. Thunderbird has a feature where you can highlight quoted text and press ctrl-r to rewrap it. So I don't really see how it's difficult to eliminate the "embarrassing line wrap" issue when there are open source programs out there that have the capability (for several decades now) to fix it.

And I think they're missing the point by saying that HTML bloat is no longer an issue. It's not the amount of text that's transferred; it's how readable it is in a client that doesn't support rendering that text. IOW, reading raw HTML is not that easy.

As for implementing an editor that only supports semantic block quoting, I think they're missing the point again. It should be the person who's composing the email who decides whether a particular section of text should be hard-wrapped (meaning no trailing whitespace at the end of each line). You could have a feature where you highlight the text you want hardwrapped and then use a key combination or context menu to apply that change. The rest of the text is assumed to be soft-wrapped and will have trailing whitespace at the end of each line unless that line followed by a blank line.

The RFC you quoted actually refers to line lengths within a MIME message as a whole (headers and body), and only after Content-Transfer-Encoding has been applied, not before.

In other words, your text parts can have lines of arbitrary line length, provided you encode them as QuotedPrintable or Base64 and set the Content-Transfer-Encoding header accordingly, which most email clients do.

Thanks for the correction!

> If my window is small (maybe because I am using a small screen), the text is painful to read. And a non manually wrapped wrapped plain text is not wrapped at all in certain cases.

If the MUA (Mail User Agent) does not soft wrap text, then text without hard wraps is painful to read. This also applies to text that's not meant to be soft wrapped (source code, error message output, log messages, etc.).

There is an RFC [1] that addresses this issue by introducing a format= flowed option in the MIME headers.

[1] https://www.ietf.org/rfc/rfc3676.txt

Sadly f=f is not widely supported (Thunderbird is a notable client using it).

I’m pretty sure hard wrapping at 80(?) chars is part of one of the RFCs.

hard wrap at 72 characters seems pretty conservative

The reason it's 72 characters is to allow for quoted text, which gets indented relative to the new text. That would allow a line in an email that's 72 characters long to still fit within 80 characters if it's prefixed with 8 quote characters. For example:

>>>>>>>>This line was 72 characters long, but is now 80 characters long instead.

    Still looks pretty
    bad on anything
    less
    than 72 characters
    because there's
    random
    newlines in the 
    middle of 
    paragraphs. 
    
    Content should be
    separated from
    presentation.

    Additionally 72
    characters implies
    monospace 
    fonts which have
    been shown to be 
    less
    readable.

> Content should be separated from presentation.

Not necessarily. There are times where text should not be wrapped (code snippets, error messages, or log output), but if text is softwrapped, then there's no way to prevent that text from getting wrapped unless you use some time of mark up like HTML or markdown. This requires that the client supports that type of markup which isn't always the case.

There is an RFC[1] that describes the format=flowed option in the MIME headers that addresses the wrapping issue (where text that should be soft-wrapped should have trailing whitespace at the end of each line). That would work with email clients that support that feature and will still appear to be hard-wrapped to email clients that do not. So, unlike HTML or markdown, we don't require those who use clients that only support plain text to update their clients to support a new feature. We can use that feature in clients that support it and have a sensible fallback for clients that do not.

[1] https://www.ietf.org/rfc/rfc3676.txt

> If text is softwrapped, then there's no way to prevent that text from getting wrapped unless you use some time of mark up like HTML or markdown

Precisely. HTML and markdown separate content from presentation, so content that should never be wrapped - like ```code``` or <blockquote>code</blockquote> is handled properly.

Yes, but that doesn't have a sensible fallback for clients that don't support html or markdown. format=flowed does have a sensible fallback.

This will wrap badly on many phones in portrait mode. The only hard wrapping that will probably not break anyone's workflow for sure is 1.

>If my window is small (maybe because I am using a small screen), the text is painful to read.

If your screen is so small that it can't display 80 characters across then pretty much anything you look at it with is going to look odd. Any HTML formatting such as tables will also be painful to read.

I like big characters. I can be far from my screen to read, use a low brightness and never have tired eyes.

I just checked on my phone some random opened web page: with my settings (which are far from the default - I raise the DPI setting and the font size so I have small UI elements but big texts), it displays 45 characters per line on portrait mode. Actually the font size is a bit too high, but I don't really care as far as most web pages are readable. I'm fine with scrolling the occasional big HTML table, and will change the settings if this becomes annoying.

So, yes, sometimes, my screen displays less than 80 characters and is perfectly usable. And this fact is not really of my correspondent's business, whether they choose to manually wrap at 80 characters, 72 characters, 42 characters or some other arbitrary number of characters. Actually, nobody knows that apart from people who read this comment. I display text as I see fit (and this is totally an intended pun).

You’re missing the point that anything longer than 80 chars is harder for the human. Ideally it should be 65.

That said, wrapping is better left to the mail client, and let the user adjust their window to suit. My chief gripe at this point is that some email clients (gmail anyway) will get confused by outsized inline images and wrap on them, even if that means letting text drift off the side of the screen!

Have you ever seen someone with poor eyesight use a smart phone?

Plaintext email is really troublesome if one wants to mail in an right-to-left language. There's simply no compatible way to override the direction/embedding without HTML * , so content is often scrambled.

Many mailers won't even align to right automatically if all input is in an right-to-left language. In practice, HTML email is the only compatible way to get a semi-decent experience for these languages.

* To answer the obvious: the unicode bidi override characters are not a solution. They are often stripped out, and editing zero-width characters is a very 'pleasant' experience.

I came here to say exactly this. It's even harder for the real right-to-left use in the ones I speak, where we frequently mix Hebrew/Arabic with English, for using certain words that just don't exist.

Plaintext mailers completely mangle emails like this, making them beyond unreadable. Mutt to its credit does the best job.

Where are these characters stripped out? I can see that these create security issues with urls that get rendered with changed field order to look benign.

I meant stripped from the mail body - though I suspect these programs would also strip them out of the other fields (I haven't checked that). In general, working with zero-width characters is a bad idea from both security and usability POV and is not a practical solution.

The result is that the only reasonable and compatible way to mix LTR (left-to-right, like English) and RTL (right-to-left, as with ME languages) is with HTML email. Note that in most cases rendering is an LTR context, so even sending RTL on its own will fare poorly.

What a load of bollocks. The arguments against come down to, 'you are an idiot who can't figure out phishing links' and, well, that's it. Something about marketing emails. Stupid. Luddite. I'm surprised they don't insist you use a monospace type face in your email reader to give it that late eighties feel.

I have always used HTML email, even when it was new and poorly supported. I want people who read my email to see a nice appearance. I like bold face and sometimes images.

"Strongly preferred". An appeal to the Authority Fallacy is an indication of a weak argument. Or, no argument at all.

I think this opinion is strongly worded and might get some heat, but I think you touch on something important.

Plaintext email often serves as an in group shibboleth to distinguish “us” from “the other lusers”. Does it have merit beyond that, or do these articles just reinforce that?

I think the main issue at play here is quoting. In particular, how bad rich text/html mail programs are at dealing with inline quoting. In my opinion, that’s the main “feature” of email communication that has been lost over the years. On the top replies make it difficult to follow a nested thread of emails.

If html email clients handled this better, I don’t think there would be as much of a problem. I think you’re right though that plain text acts as a bit of a shibboleth to differentiate “advanced” users vs luddites. But the main thing that I’ve heard people complain about with respect to html email is the loss of inline quoting.

Plaintext has its issues too— in particular long line soft wrapping. Which some would argue would be better supported if html email hadn’t become so popular.

I absolutely agree -- the aspect of email I miss from the good ol' days was well-trimmed replies and doing so inline. Threaded inboxes and smart trimming helps, but not completely.

However I think that HTML clients handle this well enough but the etiquette has been completely lost.

    Because it messes up the order in which people normally read text.
    > Why is top-posting such a bad thing?
    >> Top-posting.
    >>> What is the most annoying thing in e-mail?

The cultural aspect of this web page is pretty clear in that the author even formats his HTML to look like plaintext, which is completely unnecessary from a technical perspective. In fact it took extra effort to do that, as opposed to just allowing each browser to supply its default font.

People who fall for phishing are not idiots. Even technical people can be fooled by clever spear phishing.

This is true, but it's also true that plain text emails do not prevent phishing.

No, but I think it's fair to say that they make it more difficult.

If an HTML phishing email is hiding an obviously malicious URL behind an image or button, then yeah, that URL would be more visible in a plain text email.

But it's also visible in the address bar of the browser after you click it... and people will fill in the form anyway.

Plain text doesn't solve complacency and distraction, it doesn't solve URL composition tricks and redirect wrappers, it doesn't solve spoofing, and it doesn't solve malicious attachments.

If Google's account emails were all plain text, I'm sure phishers would figure out how to make them look as identical to Google's emails as possible, and still get some people.

IMO we already know some good ways to mitigate phishing, but their implementation is spotty: DMARC, hardware token 2FA, and good IT practices in terms of patching, privilege, and backups.

You're right. That was too strongly said. Some people are naive or make a mistake. However, nobody I know lacks for emphatic instruction to never, ever click a link on an email. If your bank wants you to login, use your own bookmark.

HTML emails usually load remote (tracking) images.

Even with "load remote images" turned off, Apple Mail will "helpfully" load them anyway if you forward an email.

I’d love someone to convince me I’m wrong - but I think we’ve lost this fight.

Years of use of plaintext hostile clients by people who read our emails means bottom posting or inline replies are seen as extremely strange, and impossible when you have one of those “seven email deep” threads forwarded to you. (I know, I know, “snip it down”, but sometimes I just don’t have those minutes in my day ;))

Wrapping as well has given me trouble - I'm not sure what I settled on but I went through a period of having some users see my emails come across poorly formatted. And to that note, IIRC Outlook doesn’t do a passable job with plaintext mail, instead shoving monotype text in an ugly system font. The last time I checked I don’t think it converted > into quoting and just vomited them up.

I don’t know what the solution is beyond reluctantly accepting that we have to both consume AND produce HTML email now, and make tools that do it gracefully.

I would agree I gave this fight up sometime in early 2000s.

Since email is only valuable as a network, it didn’t make a lot of sense to me to constantly argue with colleagues to send plain text + html, let alone to only send plain text. Ultimately, I decided using elm was my issue, and they were doing the natural thing.

There's no losing as long as you're being the change you want to see. I will always send plaintext emails and I have the technical skill to dig into the raw email and decode the encoded HTML data manually or rip out the relevant authorization URL/strings.

You’ve just made the problem an externality. While you have the skill and desire to do that - and to be clear, as a mu user I do the same dance when I need - inbound messages are rarely the problem for me.

What is a problem is outbound messages. When I try to do (what I think is) the right thing and trim the message and reply inline or bottom post, confusion abounds. I’ve had messages missed because the recipients told me they thought I accidentally sent an empty reply and didn’t scroll past the “on July 24th, superkuh wrote:”

Whose fault is that? Is it the 20 people on the distribution list who learned email protocol from years of Outlook and not “the right places?” I don’t feel comfortable pushing that blame onto them.

> I’ve had messages missed because the recipients told me they thought I accidentally sent an empty reply and didn’t scroll past the "on July 24th, superkuh wrote:"

A common way to handle this when writing to people who aren't likely to expect an inline response is to put "Responses inline below:" at the very beginning, and then respond inline as usual.

I'll admit that, in the past, I passively-agressively did things like respond to emails inline and then use my editor to remove all quoted text before sending my reply.

My god, this is never going to die, is it?

I mean, I get it. There are some things about plaintext that are nice, or that really appeal to the kind of people who read HN. I used to have arguments about this, too -- but it was 20 years ago. Today, the ship has fucking SAILED.

And you know what? It's GREAT. I send formatted email constantly -- and they're better for it. Being able to embed screenshots is awesome. Being able to use color, or bold, or italics, makes a difference in communication.

It's done. I'm not going back to plaintext, and I can't imagine most people will, either. There's no good reason to (in particular, the downfalls of HTML the author lists are all either easily solved or are issues orthogonal to the format of the email.)

> Being able to embed screenshots is awesome. Being able to use color, or bold, or italics, makes a difference in communication.

Yet, you cannot do any of that on HN (other than a limited case like italic). But, we can communicate just fine without those features.

I suppose it's really a difference of a read once message versus having a discussion. In a read once message, you can format it like you describe. That's how most blogs and web pages work. But if you want to have a discussion, then plain text with very limited markup works best since it minimizes the required vertical scrolling and it allows you to see the overall discussion since you can view more messages in the given screen space.

Communicating just fine is not the same as communicating at optimum.

In the analog world, you could just hand over a white, plaintext birthday card. Or you could give one with a motive, color, some doodles and maybe a memorable photograph attached.

Which one is more memorable?

"It's used by marketing." is not an arguments against it. We have sophisticated spam filters. Update your rules then.

       iiiiiiiiiiiiiiiiiii
     |||||||H|A|P|P|Y|||||||
   __|_____________________|__
  |\/\/\/\/\/\/\/\/\\/\/\/\/\/|
  |||||||B|I|R|T|H|D|A|Y|||||||
  |,,,,,,,,,,,,,,,,,,,,,,,,,,,|
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@

That would be a wide cake for older people :P

Just make sure it's less than 72 years^wcolumns!

I would say that the birthday card example is a read once message example, and not something that's going to be discussed at length like a patch on a development mailing list.

Go and visit a forum where embedded images are allowed and tell me that there is any sort of "optimum" discussion over there.

In the end what happens is people use text overlays in the IMAGES in order to reply to each other.

Since you edited your response to mention the birthday card:

Yea - on the one hand you can leave a boring "Happy Birthday" message with lots of glitter to make it memorable.

Or you can make the message memorable.

Some forums actually work a lot better WITH embedded images.

To pick just one example[1]: a lawn forum where people will try to ask a question, or share an experience, and go back and forth trying to describe the details. A photo cuts that pain out and enriches the conversation.

[1] https://thelawnforum.com/viewtopic.php?f=2&t=11802

That's a great example because besides the excellent use of pictures, it features terrible use of text -- the subject is "Going reel low"

An internet forum (presumably we're referring to a public forum here) is a very different communication medium than email (especially when used in a professional context)

I've seen professionally-oriented PHP forums and they are no better than any casual-interest oriented PHP forum.

Tons of visual clutter with all kinds of rectangles nested inside each other all over the screen with little apparent purpose for any of them. Join dates of users are given higher visual precedence to the date a comment was made (why is the join date of a user even visible on a discussion page at all?? That's pointless clutter!) 90% of users attaching signatures to every comment they leave with the signature body being longer than whatever remark they left, and often being filled with shitty animated gifs that look like they were stolen from somebody's geocities page.

It's a trash medium. Fundamentally flawed. Trying to fix typical PHP forums is like trying to polish a turd.

> An internet forum (presumably we're referring to a public forum here) is a very different communication medium than email

Not really. Take a look at any email discussion like the Linux kernel mailing list or the git mailing list. Same thing with newsgroups (usenet).

Yes really. Take a look at the mails I use to discuss things with my customers.

Newsgroups aren't exactly vibrant any more, sadly.

> Same thing with newsgroups (usenet).

good lord, how old are you?

I was participating in rec.games.roguelike.development until 2011 or so. Some of those communities lasted a lot longer than most would expect.

> In the end what happens is people use text overlays in the IMAGES in order to reply to each other.

Oh my god. At my work, HR likes their email super-formatted to a degree that's not portably achievable with even hand-written HTML. The solution someone once came up with? Their email consists of a single embedded image the size of a typical monitor. All text, all information is in that image. They also have a requirement for everyone to use their standard format for "professional" signatures in their own mail. Of course, those are also embedded images. In a discussion, with each reply of each person, the corresponding signature image is included.

I wish I could tell them that email only allows for plain text, but of course that's not the case.

Given it's HR, could a case not be made for accessibility which an embedded image doesn't allow.. they might be responsive if talking in HR terms and priorities.

> In the end what happens is people use text overlays in the IMAGES in order to reply to each other.

That doesn't sound optimum use of image at all.

> Or you can make the message memorable.

And use image that make it even more memorable at the same time.

Text and images are tools, both can be misused, but that doesn't means that they are bad. Remember SMS text? Works for sure, clearly not optimal, yet text is pretty good to make message memorable.

I can explain in a thousand word an issue on a page, but you can also just share a screenshot. That's an optimum use of images. Sure you could just write "see screenshot #1", "see screenshot #2", etc.. but I'm pretty sure you'll agree that it's not optimum.

Optimum for me would be links along with client integration to open said links inline. Links for example in a plaintext email are clickable - not because of HTML, but client integration. The same can be done on image links.

That way the big screenshots don't destroy the flow of text like in http://example.jpg [+] (open inline) and instead information is condensed and digested in the most optimum way possible.

Rebuttal: Yahoo! Answers is text only.

It's not text or images that make forum content good or bad or memorable. It's good people doing good work. And different people work well in different media. Saying that text is the only legitimate form of media is both ignorant and disrespectful.

I'd argue that that's a shortcoming of the platform and not the medium in that context. Having the ability and abusing it are two completely different things.

And we got along 'just fine' before computers were invented. Should we stop all progress because we don't really 'need' any new stuff we are inventing?

> But, we can communicate just fine without those features.

Surely professional communication has a different use case and requirements than random musings on an internet forum.

My experience has been that some professionals are not actually very good at communicating in the first place. They won't read a detailed email, and instead prefer body language and rapport to substance. Perhaps the need for pictures and fonts in an email is related to this problem.

>Yet, you cannot do any of that on HN (other than a limited case like italic). But, we can communicate just fine without those features.

Can we?

Comments can't have tables, so you almost never see any actually tabular data like statistics. I frequently see people misstating copied across data, or getting confused by things that would be simple in a table.

Quoting from the article is very difficult, as laws and guidance often use formatting despite being very simple documents. I've run into this a few times when trying to quote GDPR guidance, and people very often misunderstand quotes.

People frequently struggle making lists, or having problems with ambiguity about which point a comment is replying to.

Code snippets just don't work on mobile.

> then plain text with very limited markup works best since it minimizes the required vertical scrolling and it allows you to see the overall discussion

Sure, if your discussion is short and shallow point-scoring! For in-depth discussion headings or any structure at all is really important.

> Comments can't have tables, so you almost never see any actually tabular data like statistics. I frequently see people misstating copied across data, or getting confused by things that would be simple in a table.

It can be done in plain text, but I don't commonly see it. For example:

  Column 1    Column 2
  first       second
  third       fourth

> Quoting from the article is very difficult, as laws and guidance often use formatting despite being very simple documents. I've run into this a few times when trying to quote GDPR guidance, and people very often misunderstand quotes.

I have quoted statutes from federal and state laws numerous times as part of a discussions where copying and pasting the text into a plain text format works. For example, a bullet point becomes an asterisk.

> People frequently struggle making lists, or having problems with ambiguity about which point a comment is replying to.

I think it's a lack of convention. I spent a lot of time on email lists, forums and newsgroups and have seen various conventions, but most people didn't struggle to make lists. The most common convention was just to use numbering or asterisks to indicate items in a list:

  * item 1
  * item 2
  3. item 3
  4. item 4

> Code snippets just don't work on mobile.

Code is one type of text that shouldn't be soft-wrapped, but the lines are frequently too long to render without wrapping on a mobile.

> Sure, if your discussion is short and shallow point-scoring

Not all online discussions are like that. For example, look at the mailing lists for the Linux kernel and git. I've also seen many substantial discussions on sites like this and reddit. In the past, I've learned a lot from newsgroups (usenet).

The OP's point is that it might be better if HN allowed slightly more formatting than it does. Personally, while I wouldn't want full-bore HTML, I'd like to see a more substantial subset of Markdown[1] supported. Your own examples of tables, lists, and block quotes would look a lot better if they were, you know, actual tables, lists, and block quotes.

[1]: Markdown isn't perfect, but it's pretty well-known, and by design mimics a lot of conventions that came from plain text email to start with.

> Your own examples of tables, lists, and block quotes would look a lot better if they were, you know, actual tables, lists, and block quotes.

I would agree with what you said about tables (which, in my experience, is an uncommon use case), but the rest can easily be rendered in plain text. Block quotes, in particular, could be done by indenting the text by several spaces (or a tab), just like it's done on HN.

FWIW, your plain-text table is not as accessible with a screen reader as an HTML one. For the past two decades or so, screen readers have had commands for navigating tables, reading the row and column headers, etc. But those only work with something like HTML or a Word document, where the structure is well-defined.

Format is a kind of moderation and guidance. With email, anything goes, but it's usually direct communication, where the rules are organically decided between the participants. With a zillion participants, that can't happen, so limiting the options is useful.

I don't see the point of email, I can communicate just fine by letter, by radio, by semaphore, by morse code (actually I suck at Morse).

>Yet, you cannot do any of that on HN (other than a limited case like italic). But, we can communicate just fine without those features.

And a message board is absolutely NOT email, so this is totally irrelevant.

> Being able to use color, or bold, or italics, makes a difference in communication.

It really does. Color, especially helps people find the relevant/critical part.

It's true, in fact here's a good example of someone using color to improve their communication:

https://useplaintext.email/

>"But if plaintext is so good, why is this page written in HTML?"

>This is a reference document, not an email, you twit.

Abot 25% of the emails I write, and 90% of the important ones, are reference material for the people that get them. Screenshots, hghlights, and links to external documentation all make my email communication better, faster, and more useful to the recipients.

I suspect you are being downvoted because people don't realize you are quoting the document. It's a shame that HN features articles that are written in a style that doesn't follow the basic standards of civility and quality that is expected of comments.

You could also skip the irrelevant parts. That too makes it easy to find the relevant part :-)

Unless the recepient is color blind or has another impairment. Also instead of highlighting important parts, one might focus on important parts in the first place.

That said there are valid uses for formatting. But unfortunately most of the formatted mails are harder to digest than needed. Especially if it becomes a longer exchange and people start highlighting in quoted mails.

No, this is not true at all. People will _only_ read the color part and skip anything else, which is equally bad to not finding it immediately, if not worse.

And there are also color blind people for whom the color might be even worse than the lack of it.

Yes. The argument almost defeats itself: why do you waste my time with irrelevant stuff? Why did you make read a whole page of details before coming to the critical point?

That has been my experience: make your messages as short and straight to the point as possible. Put the most important stuff first and the gory details only the curious will read, last. That goes for documentation too.

HTML mail gives the illusion that fancy formatting can make up for mediocre writing skills. That's sad, because no amount of bold face, color or indentation can fix an inconsistently structured piece.

You learn that stuff at school, make your tuition fees (and/or the time you have been forced to invested in it instead of being young and having fun) worth it.

What I hate about HTML email is that it tends to set its own font size, sometimes even font face. Like... Keep your dirty hands away from my config of how I like my mails to be displayed when I read them. But no, every mail is now a snowflake and has to have its own styling, even though it doesn't provide any value.

In retrospect, Markdown should have been lingua franca for rich email.

It won't die, because the argument has the same merit today that it always has. That being said, I think it's useful to attach images to an email (not necessarily embed them in the content of the email, but attach them for sure).

IMO HTML email is worse today than it's ever been. Often when I get an HTML email it takes me longer to parse it. On the bright side, the presence of HTML is a decent indicator of a marketing email that can safely be ignored.

>the presence of HTML is a decent indicator of a marketing email that can safely be ignored.

Enable that as a filter, and you'd get fired SO FAST in most of the places I work.

> There's no good reason to

I used html for years. Once my email volume reached a certain point, I went back to plain text because I can read it and respond to it much faster.

Neither you nor the poster provide a reason why. Why is it better? How does plain text make it faster to respond? Or even faster to read?

A well formatted html email has the potential to be much more readable than any plaintext one. The issues come in execution.

I find that a very large percentage of the html email I receive is actually hurting readability by way of formatting.

On top of that, a sizable percentage who send html email fail to take accessibility into account and leave out important elements like alt tags.

> I find that a very large percentage of the html email I receive is actually hurting readability by way of formatting.

This is exactly right. In principle, html is just as convenient, but in practice it regularly fails. Something I really hate is a message with big images that add nothing. If I have to scan a message to figure out what's being said, there's a high probability I will leave it for later, which means it never gets read at all.

I would say that the real performance drain is top posting, which seems to go hand in hand with HTML emails.

With top posting, in order to read a mail - especially one that is a few levels deep in a thread - becomes an exercise in jumping back and forth, trying to find context and make sense of who replies to what, finding relevant sentences (often hidden in a mess of signatures).

With bottom posting and proper curated quoting, context is a glance away, and it's easy to see who said what in reply to what.

I'm sure this would be possible with HTML mails as well, but I've never seen it happen. It's all just a mess of hard to find information in the least sensible order imaginable.

Top posting is orthogonal to the email's format. I've received plenty of top posts in plain text way back when.

Not doing top posting literally has confused recipients of my mails (almost all instances).

So now I'm a top poster as well: i use emails to communicate, not to confuse.

A: Because it messes up the order in which people normally read text.

Q: Why is top-posting such a bad thing?

A: Top-posting.

Q: What is the most annoying thing in email?

No. Always top post. This isn't 1990s USENET.

The reason why is because many clients fold emails that have redundant text in them -- and may hide bottom or interleaved posts within the fold.

Modern clients assume the "Outlook style" -- HTML formatted email, top posting. If you want your message to be read, use this style.

> proper curated quoting

Indeed, it would be nice if the netizens of the world would wake up to this. Sadly, I think it's unlikely to improve any time soon and so I'll stick to top posting and threading in the email client.

it's 99% psychological but I also 100% agree. Just posted a top level comment about how it has absolutely changed my life with regards to email. If you're having trouble keeping up with email and aren't afraid of the command line i _highly_ recommend using a cli client. Neomutt is a bitch to set up because there aren't any good action oriented docs, but it's been worth every bit of effort. There are other clients that are much easier to set up (like alpine) but neomutt has so much power and for me being able to write in markdown and convert to HTML for normal folks was a requirement.

the 1% that isn't psychological is how much faster _everything_ is when dealing with a plaintext client (neomutt in my case). "Power Users" use the keyboard to navigate gmail. Normal (neo)mutt users use those _all_ the time and they're faster because there's so much less for the computer to do with each keystroke.

  images loading..2%
  images loading..15%
  images loading..29%
  images loading..42%
  images loading..58%
  images loading..74%
  images loading..89%
  images loading..100%
   ____________________________________
  |                                    |
  |                                O O |
  |                                 O  |
  |                                \_/ |
  |             MY LOGO                |
  |          My catchphrase            |
  |                                    |
  |                                    |
  |                                    |
  |------------------------------------|
  |                                    |
  |  Hi josho!                         |
  |                                    |
  |  This is why it's slower to read!  |
  |                                    |
  |____________________________________|

This isn't a thing, which makes me think you're arguing in bad faith.

Clients load images asynchronously, and no personal email is sent with a logo and catchphrase header. I've never seen that in my entire life and I've been using email with a lot of people, for a long time.

Formatting is an issue however, and the addition of formatting to email can be useful and add to the conversation.

To take the hn example again, the text portion of your comment is broken on mobile because hn doesn't support proper formatting. This has made your comment harder to read.

A decent email client will load images asynchronously. Many can also be configured to not load remote content at all until you allow it.

Your comment is plain text and it's terrible to read. So if anything, you're making the opposite point!

I consider this to be more like a polemic to shift the overton window of acceptable email restrictions.

Probably much of what we enable in email could be restricted without loss of actual useful features. Each feature adds attack surface, complexity, and compatibility concerns that can be avoided by using the simplest possible subset of features.

Agreed. I just hate the backgrounds some people put in email. In those cases I swicth to plain text in the response.

Please relax and think of the commenting guide lines.

I don't want your formatted html, nor does my client render it. You can attach screenshots or link to them.

> There's no good reason to

There's no good reason for using anything other than plaintext in email. You can use slack, riot, or other chatrooms for the rest.

Our offices don't use any of that chatroom crud and I'm extremely thankful for the lack of extra imposed distractions, not to mention the horror stories of being reachable 24/7 because of Slack/Riot/etc.

Why require another medium for communication when email works just fine? What is the point in joining a chatroom to talk to one person only to be spammed by everyone else in the room? For those cases where email is insufficient, walking over and talking or making a phone/video call are IMHO better.

> being reachable 24/7

Email and phone are in the same boat, or none of them if you simply turn off the alerts.

> another medium for communication when email works just fine

When the topic at hand can only be resolved by many round trips, chat is faster because you don't bounce through different interfaces to read vs type.

> talk to one person only to be spammed by everyone else in the room

Direct message, not a room.

> walking over and talking or making a phone/video call

That is much more likely (perhaps even guaranteed) to be an interrupt, while chat allows the recipient to choose precisely what things interrupt them.

> Why require another medium for communication when email works just fine?

I’m guessing you’ve never actually worked with these chat clients yet?

The difference is light and day. Of course there is annoying parts, but like plaintext email I guess, just having everyone write in the same format soothes the brain.

And no awkward quotes or history in every damn email (because your client is going to mess up that thread!).

Having slack doesn't necessarily mean having to be reachable 24/7. Chatrooms fill the use case of day-to-day chat and other more short-lived information.

As for distractions, that comes down to bad work culture. Hacker News & Lobste.rs are far more distracting for me. I simply get around to slack/email when I get around to it, with the exception of my boss pinging me. Thankfully he only messages me for important things.

If you email me I'm going to assume it's something actually important / something that will have some longevity vs some question on slack. Since people wear headphones due to idiotic open workspace culture, messaging someone on slack is far easier than walking up to them (unless your question is actually important/urgent, of which most are not).

Your phone or video call better be very important. Those are blockers, especially video calls. I prefer to call the latter time-wasters since, well, they're almost always a complete waste of my time. The only useful video calls I've done are with syncing up with another developer, which I cannot do locally now that I work remotely. Aside from this I prefer leaving the luxury of video calls for my parents.

>HTML as a vector for phishing

I would disagree, You can make Text-only links look fairly harmless too. The issue is more often that people do not look at all, even in text-mail, what the link points to, not that they can't see it (plus you can hover and the browser still shows the URL once you open it)

>Privacy invasion and tracking

Only if you use an ancient and outdated client that doesn't block external resources by default or proxies them over another server.

>Mail client vulnerabilities

Only an issue if the client rolls their own HTML renderer. Outlook uses the IE Trident Engine, Thunderbird uses Firefox' engine, Gmail transforms using the Chromium engine internally. That means the email client is usually as secure as the respective browser, unless you use a mail client that rolls their own engine.

>HTML emails are less accessible

Possibly, depends on the sender. You can make them more accessible than Text though because you can prevent the screenreader from trying to read out the link or irrelevant information.

>Some clients can't display HTML emails at all

Most mail clients will usually bundle a text-version of the mail, some MTAs also do this on their own. Doesn't really matter in practise since 99.99% of people use a mail client that can display HTML.

It feels a bit like complaining that people on the highway drive so fast that you can't properly merge into the rightmost lane with your oldtimer car.

>Rich text isn't that great, anyway

And tbh, this last one basically seals it; this is a website made to rant from the personal perspective of someone who blocks mails containing any HTML from their services and has quite the history of throwing people using their lib under the bus over personal preferences.

I don't see how any of this is relevant when even the site itself admits that using a multipart mail with both text and HTML is sufficient, why should I even begin to send plaintext instead of doing that?

Unless your mailclient is garbage, it handles multipart and will understand the mail.

I'll address more of your comment later, but for now let's start here:

>Only an issue if the client rolls their own HTML renderer. Outlook uses the IE Trident Engine, Thunderbird uses Firefox' engine, Gmail transforms using the Chromium engine internally. That means the email client is usually as secure as the respective browser, unless you use a mail client that rolls their own engine.

This is not true. You can't just drop a modern web browser into an email client and have it magically be secure - if you do, your client will be broken and insecure. A huge number of browser features have to be removed - loading external images, stylesheets. scripts, images in stylesheets (except datas URLs, so add a special codepath for that). Things like animations aren't desirable, nor forms, etc. The list of things you have to turn off is huge and getting longer with each browser release. And you had better keep up with those releases, as each one fixes a half dozen security bugs which are inevitable in a technology whose specification alone is a million lines.

That stuff is actually not that hard, mozilla's engine has compile flags for that stuff and the patches you have to make are minimal. There are a few methods for runtime restrictions too, they're quite extensive in their capabilities and sufficient for sandboxing a mail.

Mozilla's engine is a giant multi-million lines-of-code ball of C++ and Rust and JavaScript weighing in at nearly 200 MiB - not including dependencies. And what if I don't want to support the browser monoculture? Implementing a new one is a daunting task (nigh impossible), but rendering plaintext is easy peasy.

Mutt is 1 megabyte.

HTML email in practice doesn't need much more than what w3m supports, in some places less - no need for w3m's frame, cookie, or FTP support. w3m is smaller than mutt.

Limiting HTML mail to an agreed subset could actually be a winnable fight compared to more impractical suggestions.

As someone who uses w3m to read HTML emails sometimes, it's very hit and miss. Perhaps 50% of emails are easily readable in w3m, on a good day.

>> Some clients can't display HTML emails at all

> Most mail clients will usually bundle a text-version of the mail, some MTAs also do this on their own.

This assumes there is a proper text part (one that actually includes the content of the mail body).

That does not seem like much of an assumption; all modern mail clients that I am aware of do this.

The problem isn't the clients, it's the senders. And as someone who uses Mutt, the vast majority of HTML emails don't have usable plaintext versions.

What kind of mail client doesn't send mail? I am talking about someone using a mail client to draft and send an email.

Unless you violate accessibility laws or your email client is shit, there is a text part or the HTML part is screen-reader compatible.

Hahaha, that's rich. Those laws are not enforced. I actually consulted with a blind friend when writing that up and he agrees that every HTML email is a nightmare for him. Top posting too.

However, a significant portion of HTML mail I receive happily violates "accessibility laws" and omit to provide a text-only part. I know that, since I actually rely on accessibility to do my daily work.

To clarify, is your problem with HTML emails that omit a text/plain part, or only HTML emails that have images with no alt text? If the latter, I think the solution is to advocate for accessibility in HTML emails, not plain-text emails. After all, well-structured hypertext has its own accessibility benefits, since most current screen readers have lots of commands for navigating that structure. This is why I disagree with advocating for plain-text email in the name of accessibility, as this campaign does.

Screen readers should be able to deal with HTML-only mails for the most part, otherwise you should send the sender of that mail a reminder about those laws.

How do they manage to do that? Embed the text as an image?

> You can make Text-only links look fairly harmless too.

Could you give an example? As far as I know, you cannot do something like making a link look like it belongs to a completely different domain.

Examples from what I've seen:

    https://account:paypal.com.login@verified-account.com/phish

This, to the untrained eye, might at first glance look like a paypal.com link. In fact, it belongs to verified-account.com and it abuses the capability of URLs to contain a username and password to make it look legit.

Wow, I knew Firefox warns for these by default so I thought nobody would ever use this for a phishing attack anymore but it looks like Chrome just meekly follows the standard. That's too bad, really, this is a very easy way to create very realistic phishing mails.

Don't even need that account: at start, this works in chrome:

https://www.paypal.com@google.com

In Firefox it tells me:

    You are about to log in to the site “google.com” with the username “www%2Epaypal%2Ecom”, but the website does not require authentication. This may be an attempt to trick you.
    
    Is “google.com” the site you want to visit?

From the error message it sounds like if this was an attacker controlled site configured to require authentication it wouldn't trigger? If so it's not that useful a defense since whether to require auth is entirely under the attacker's control.

Gold star for Firefox! That's an excellent feature.

I'd say domain name squatting.

For example

https://login.banksofamerica.com

There are a lot of homoglyph url tricks. It turns out there are even online attack generators for these, so you can see for yourself:

https://www.irongeek.com/homoglyph-attack-generator.php

https://adlinkurl.com/blog/2-homoglyph-url-spoofer

glyphs that look similar in most fonts: appIIe[.]com payaI[.]com

They look different in monospace, but I know Gmail renders plaintext mail with a normal sans-serif.

You can also just spell things mildly wrong. People often auto-correct spelling in their mind without realizing it, ex: microsott[.]com

Note I added [] to avoid linking the sites. Those domains look like they're squatted by suspicious customers already.

Finally back at a computer, can reply to this in full now:

>I would disagree, You can make Text-only links look fairly harmless too. The issue is more often that people do not look at all, even in text-mail, what the link points to, not that they can't see it (plus you can hover and the browser still shows the URL once you open it)

It would be difficult to argue that it's not at least more difficult to phish people with plain text.

>Only if you use an ancient and outdated client that doesn't block external resources by default or proxies them over another server.

This works until you click any link in the typical marketing email, or click "show images" to make the email readable. Remember that you have to train these careful behaviors into non-technical end-users.

>You can make them more accessible than Text though because you can prevent the screenreader from trying to read out the link or irrelevant information

This only sounds useful for spam or marketing emails (which are the same thing 99 times out of 100).

>It feels a bit like complaining that people on the highway drive so fast that you can't properly merge into the rightmost lane with your oldtimer car.

This is an uncharitable interpretation. We don't use these email clients because we're old fogeys, but because they're better and more efficient for our workflow and needs.

For the vast majority of people html formatting is better and more efficient for their communication needs. Bold and highlighted text, section headers, tables and inline images are all very very standard and useful things to have in emails. These are not niche use cases.

I have never seen an email with a table in it, HTML or not.

Inline images are not useful, just attach them. Leave your giant signature with your company logo at the door.

What's left is section headers and bold text. Use asterisks for emphasis and # for section headers and you can communicate quite effectively. We seem to manage pretty well here on Hacker News without most of these features, wouldn't you say?

I often use inline images in emails, for the same reason I put images inline in other writing. I recently wrote an email summarizing some debugging I had done so someone else could pick it up. It looked like:

    text describing steps

      image of graph
      link to graph source

    more text

      another graph
      link to graph source

    etc

We're all using email clients that display messages like this well, and it makes communicating complex ideas much faster.

I'd give up HTML email if I could still have format=flowed and inline images, but that's not what's on offer.

HTML mails are routinely formatted using tables since that is what most mail clients correctly understand, it's essentially the design standard there.

People manage on HN but on reddit people freely use these formattings fairly regularly and nobody seems to complain about that.

Heck, using the markdown standard for formatting is already going away from text/plain and towards text/markdown, which isn't strictly plaintext.

I routinely insert org-mode tables into emails I send at work (now that I think about it, that's a little funny, given that I'm consistently pro-HTML-email in these threads).

Does outlook not use microsoft word as the html render now?

Last I know is they use Trident, though it's possible they switched considering that IE is going the way of the Dodo.

My understanding is that the MS Word HTML renderer is based on ~IE5.5.

One reason I would add is archiving. Having managed some large, archived mailing lists, one of the headaches is dealing with formatted text. Even plaintext can be a pain in this regard (differences between email chain formatting, fixed-width lengths, etc.). HTML is even more troublesome...

In terms of phishing, plain text emails can still carry malicious attachments, which can be very dangerous.

Plain text does not prevent phishing!

    Your paypal account was deactivated, please visit
    https://www.paypal.com@google.com to reactivate it.

Looks phishy, no?

I just want to put it out there, that regardless of if this is a "fight worth fighting" or not. Email was a nightmare for me. I could not keep up. Coworkers would catch themselves and laugh when they asked if I'd gotten an email.

Switching to neomutt has changed everything for me. I now mmaintain Inbox Zero.

I write in markdown. I convert it into a multipart email with HTML in one keystroke for everyone else.

Other benefits:

I don't know this for a fact, but i suspect that HTML email has got to _suck_ for visually impaired people using screen readers.

plaintext email means no tracking by marketers, or facebook, or anyone else.

plaintext emails are also _way_ shorter. There is so much less crap to mentally deal with when all the marketing BS has been stripped away.

plaintext emails give you a glimpse into just how much you're tracked too. Nevermind the privacy aspects of seeing the real url, you see that the "real" url is multiple lines long because of all the tracking they've embedded in it. It makes you think twice before clicking it.

What is it about neomutt that allows you to be that efficient with your emails?

For me it's not mutt so much as being able to write and edit in vim. I can reply in-line, quickly chop out chunks of text etc etc.

I'm not one to shout at people for not using plain text etc but I personally quite like it.

For the convenience of anyone that may consider licensing and language it's written in a relevant part of their choice of software, here's the list of recommended e-mail clients in the submission with licensing and programming language info:

- aerc: MIT, Go

- alpine: Apache 2.0 (parts 4-clause BSD), C

- claws mail: GPLv3, C

- Gnus: LGPLv2+, elisp

- KMail: GPLv2 (parts GFDLv1.2, parts LGPLv2.1), C++

- mutt: GPLv2, C

- SquirrelMail: GPLv2, PHP

Side note:

> (context: ProtonMail) It's also recommended that you visit Settings → Account → Identity and remove the default email signature.

It bears noting that free accounts on ProtonMail cannot remove the ProtonMail advertisement in the signature, cf. [1].

[1] https://www.reddit.com/r/ProtonMail/comments/5ageqz/question...

I would also reccoment Wanderlust [0]: GPLv2+, elisp

[0]: https://github.com/wanderlust/wanderlust

Can you fill out this survey for me?

https://paste.sr.ht/~sircmpwn/be4f2eee45046e069a4bb175d9d539...

My own client:

lumail, c++, gpl

https://github.com/lumail/lumail

It would be great if you inserted a screenshot of your client in action in the README.md. In my experience screenshots have excellent information density when it comes to evaluating software :)

The website has this page of simple screenshots:

https://lumail.org/screenshots/

Can you fill out this survey for me?

https://paste.sr.ht/~sircmpwn/be4f2eee45046e069a4bb175d9d539...

No instructions on how/where to reply so here you go!

1. What is your mail client?

Lumail. Console based. lumail.org / github.com/lumail/lumail

2. Can you give me plain english instructions for composing plaintext emails by default?

Lumail is a console-based client, much like mutt. To compose an email your editor is launched. If no editor is configured vim will be used.

Plaintext composition is the only thing that is supported.

3. Does it hard-wrap your plaintext emails at 72 columns?

The mail client doesn't, since it opens a temporary file with your configured editor. You could configure your editor to enable/disable wrapping ..

4. Does it support format=flowed?

As above.

5. When replying to a message, does it put your reply above or below the quoted message you're repying to by default? Can you change this setting? How?

The editor opens a temporary file into which the quoted body of the mail you're replying to has been placed.

I configure my editor to be `vim +/^$ ++1` which puts the cursor above the mail, but below the headers.

You could do something similar to place the cursor at the bottom, but that would require a suitable editor-specific command to be set.

Thanks! Since you use vim by default and vim does the right thing by default, I added your client to the list of just-works clients.

I greatly prefer top posting because it emphasizes what I'm looking for in a email reply which is new information. Moreover, modern email clients automatically hide the quoted text so only the reply, with the new information, is visible but context is available if necessary.

For example:

---

Let's meet at 8 pm.

(Show more from person A).

---

Typically, the context will be clear from reading the reply and the sender. If not, I can establish context by clicking on the link:

---

Let's meet at 8 pm.

> Agreed, when should we meet?

>> I think we should meet face-to-face to discuss this.

>>> This is a super-important discussion.

>>>> I propose to implement HTML mails.

>>>>> Plaintext mails suck. I missed important information because the mail used asterisks instead of bold text.

---

With top posting, I can stop reading the previous mails as soon as I understand what's going on. Consider the opposite with bottom posting: Here I would have to read the entire context from the beginning or am at the mercy of how other people edited the context.

EDIT: Put --- on individual lines. Fixed asterisks formatting.

That's only relevant because you're including your whole thread (or part of it, if there's forks) in your email. As far as I know, there's no real reason for people to do this anymore. Email clients should be able to handle email threads themselves, and then the recipient can decide how they want to sort it.

If you're only replying to things that are specifically relevant to the section (what quoting was traditionally used for), then bottom-posting doesn't make sense.

I would like to read more details about "The former is strongly preferred". Why is plain text preferred and by whom?

I had the same reaction and at the bottom it goes more into details of the reasoning why plaintext is better. I, however disagree on pretty much all the points.

Preferred seems like a weird claim. I would have worded it differently:

>Plain text is sufficient for the vast majority of all non-advertising emails.

None of the emails I receive on a daily basis needed to be HTML. The main reason for it, is allowing people to use their company logo in the footer.

https://useplaintext.email/#why-plaintext

There is info about it. "4. Why is plaintext better than HTML?"

Yes, but some of the rationale is up to dispute, or simply out dated. For example, there is not an email client these days that do not render rich text/HTML. Those who do not, will convert it to plain text. Nothing to lose.

> Why is plain text preferred and by whom?

Besides making phishing easier (by disguising links, unless you hover over them), what exactly does HTML add?

Most people simply bang out a bunch of text without any formatting: what does wrapping HTML around that add? I have yet to see a layman someone add useful typographic flourishes to any business communications. Any "advanced" formatting has always come from marketers.

People use bold and italics, section headers, inline images, tables, text highlighting. The list goes on. Is it really that hard to wrap your head around the fact that formatting is useful for communication?

> People use [...]

Not in my experience. They hit reply, type something at the top with whatever the defaults are, and hit send.

> Is it really that hard to wrap your head around the fact that formatting is useful for communication?

I have all of Edward Tufte's books, as well Bringhurst's Typographic Style, and Chicago: I am aware of the usefulness of typography. I simply have not seen it in my day-to-day e-mails at work or in personal life (except for marketing spams).

I see useful text formatting every day in the emails I send and receive. A reasonable person would accept that other people’s use cases and preferences are valid instead of writing haughty diatribes about what the platonic ideal of email should look like.

Keep reading the article:

HTML emails are mainly used for marketing - that is, emails you probably don't want to see in the first place. The few advantages they offer for end-users, such as links, inline images, and bold or italic text, aren't worth the trade-off.

and more at https://useplaintext.email/#why-plaintext

The idea that marketing emails = "you don't want them" is fairly popular in some crowds, but it's contradicted by the tremendous business success of using marketing emails. The reality is that most people want and use marketing emails.

For example, I'm signed up for marketing emails from several airlines and these routinely save me money when booking vacations. Cheap airline tickets are a limited resource, so real-time notification of new availability has financial value to me.

Same with end-of-season sales for clothing I like. One company gives email recipients 1-2 days to shop before the sale is posted publicly on the website and social media.

It also ignores the tremendous popularity of email newsletters, which employ HTML formatting to improve the user experience, exactly the same way content websites do. In fact HTML email newsletters are often better than websites, because email clients don't execute javascript. The advertising is far less intrusive.

but it's contradicted by the tremendous business success of using marketing emails

I know advertising is effective, it IS manipulating me. That's WHY I don't want it. "I don't want them" is not contradicted by the success of marketing, it's reinforced by the success of marketing.

Is this true? All the people I interact with professionally are sending HTML email, probably because they all use Gmail.

Sure, but are they sending it for a concious choice to prefer HTML, or because it's Gmail's default?

Does it matter? The default is HTML, the majority of mail is HTML (or atleast multipart). So why does it matter if GMail defaults to what the majority is doing? Everyone (99.9999% of people) can receive and send HTML, so just do that, it's the informal standard for mail now.

The people you are interacting are not sending HTML email on purpose, but simply by accident because of details. I would hazard to guess that if the default was changed that they would not noticed.

Given all the communications that you receive, how often have typographic 'flourishes' been added in a useful way that would need mark up more advanced that ASCII/Unicode?

Given the following (from the article):

* HTML as a vector for phishing

* Privacy invasion and tracking

* Mail client vulnerabilities

* HTML emails are less accessible

What exactly does adding mark up give you on a day-to-day basis over a text/plain Content-Type?

Do they use formatting?

For myself and the people I work with, most definitely. Bold and italics in particular to highlight/accent certain parts of the text.

This ship has long ago sailed. People are using email less and less these days as it is, anyway. I get personal emails less than once a week now.

You'd be better off pushing people to using email for communication in place of walled-garden IM or social platform du jour (which I also think will be a losing battle in general, but perhaps more worthwhile), in which case being able to make your email look nicer might even be a draw.

The part about ProtonMail and Tutanota seems pretty biased. I would like to hear how the author suggests that they should implement IMAP and SMTP without compromising the encryption.

It sounds like the author prefers dubious advantages to real improved security.

That's quite ridiculous considering that according to him HTML emails are:

>"... a security nightmare, are mostly used for advertising to you and tracking you, are less accessible for many users, and don't offer anything especially great for it."

> the author prefers dubious advantages to real improved security

Encrypting the data transfer doesn’t improve any of the HTML email security issues. So I fail to see how that would be “real improved security”.

But I do share the authors sentiment on the failure to not using open standards of both Protonmail and Tutanota. So maybe I’m biased.

The data in a protonmail account is encrypted with your own key. How is protonmail supposed to encrypt an email if they receive it unencrypted over SMTP?

There are various ways. One would be to use standard imap and decrypt the message on the client. Their bridge sort of does that but with proprietary protocol.

Either way, that has absolutely nothing to do with the security issues of html email. Eg phishing and tracking still works when you decrypt the message and open it.

I'm on mobile so I can't give you an adequte response, but I can link you to a previous commment I wrote on the subject...

Or I would, but pasting seems to be broken on my phone as well. If anyone can search HN for "Sir_Cmpwn Protonmail" and link the relevant comment I'd appreciate it very much.

This one, I believe: https://news.ycombinator.com/item?id=18008123

Thank you!

For Protonmail: maybe using PGP and sending over TLS?? Protonmail bridge basically does this, just over a proprietary protocol.

The page is about setting up email clients to send plain text emails, but most of the reasons given why plaintext is preferable are about receiving email. The remaining reasons are either "rich text isn't that great" or are trivially solved by the client (extracting plain text from a rich text email isn't hard on non-marketing emails).

"How about you get a mail client from this century?"

--Actual response I got when I complained to an IT admin at a former company that Exchange had started eating all plaintext versions of emails

>Mail client vulnerabilities

Yeah, this is the part that is eventually going to bite us ... hard. It is just straight up insane to allow random entities access to the vast attack surface of a web browser. Unfortunately no one seems to even care about present day ongoing attacks. We will have to wait until someone comes up with a worm that takes down email and possibly the whole net.

MIME is hard enough:

https://snyk.io/blog/how-to-crash-an-email-server-with-a-sin...

The attitude of high-skilled tech people to think that their stripped down, interface-less, and brutalist version of something has to be simply better than anything else needs its own German term, something like Schadenfreude or Treppenwitz. I'm sure some of the German readers here can work out something.

Isn't that just elitism/gatekeeping?

Other than that "Hackerwahn" ("hacker mania") sounds like a nice term for this as mostly low-level hackers seem to show this kind of behavior. (Note: This is not meant as an insult or a generalization.)

Yeah, you really have to be a high-skilled h@x0r to write a plain text mail. /s

Not having inline images is an issue though. It helps immensely with readability and usability. Especially with people that aren't as computer-savvy.

Partly because many email-clients will list attachments below the mail content. And since it is standard practice to include the previous mail when responding you have to scroll a kilometer to get to the bottom with the attached images.

That is just unusable. Yes, it is an issue with bad clients and not plaintext. But nonetheless it is a big issue.

I think 95% of the email formatting complaints regarding images are related not to this, but to highly-formatted signatures (usually with a variety of social media links)

Maybe you should read the entire page? It specifically warns against top posting and quoting the entire email you're replying to.

So if people followed this advice you wouldn't have to scroll a kilometer for attachments (unless someone actually wrote an email that long).

I don't know if I've ever seen bottom-posting in my life. They have particular weak arguments against that as well. It is very useful when forwarding a message or including someone else as cc.

It is very useful for you, the sender. It is a nightmare for the receiver. Whenever I receive one of those forwarded top posted thirty mail long horrors I just ignore everything and hope I can guess context from whatever you wrote in the last email. The alternative is to spend an hour deciphering the blob of goo that is actual mail messages mixed with signatures, attachments, all being meaningless replies to questions I haven't yet read - because top posting.

Sending me such a thing is equivalent to telling me "Fuck you, your time is worth nothing to me."

>The alternative is to spend an hour deciphering the blob of goo that is actual mail messages mixed with signatures, attachments

You mention attachments, which implies you've been included in all the previous emails. In which case, your email client should be splitting them (often referred to as "conversation" view).

Otherwise, how does it make any difference if the infinite nesting is at the top or the bottom? Or by "top posting" do you just mean replies without trimming?

I would say that top posting does mean replies without trimming. In theory, they're not the same, of course. In practice, I've seen top posting with trimming a total of... well, zero times.

And in either case, reading something from top to bottom is certainly easier than to read something in the order of: Last 3% of the message, followed by the bits that are 93-97% into the message, followed by the bits that are at 86-93% of the message, followed by the bits... every email is like watching Memento. With each scene in whatever typeface that particular person's email client thought was a good idea to enforce upon me. And sometimes purple.

I feel it is very informative as the recipient.

Yes, everything you need to know ought to be in the mail itself but often you need context or surrounding details or just some information as to why the question arose.

You can in the very most cases figure that out by skimming a couple of previous mails in the thread. Very quick and saves another round trip, which can be very annoying if you are on different time-zones.

When forwarding a message you should include the thread as RFC 2822 attachments (RFC number recited from memory, may be wrong). Your mail client should make this easy for you.

Is it not ironic that the very website promoting the benefits of plain text, uses a textual medium consisting of bold, underlined, colorized, and other font effects? Something that can only be achieved via HTML enhanced emails!

I think footer text might interest you:

> "But if plaintext is so good, why is this page written in HTML?" >This is a reference document, not an email, you twit.

If you block remote image loading (to thwart trackers) and be careful about phishing links, I don't see a need for plain text-only email.

Most people aren't going to change the default configuration of their email client or use caution when dealing with phishing emails.

But if the email is plain text, then that's not an issue.

I think this is unfortunately mostly preaching to the choir. The "industry" is moving in the opposite direction - the page should have a section on "AMP for email".

I hate HTML email with a passion.

In more that 20 years I cannot remember when I last saw a well marked up HTML email that wasn't miss aligned due to missing closing tags or some other stupid mistake. They are always filled with utter useless and distracting crap and for some reason people tend to think that that is better than simply focusing on the flipping point of the message.

And no, I don't want people to embed screenshots in the message body, I much prefer attachments.

Claws-mail has a beautiful setting called: "Render HTML messages as text", and if that doesn't work because the HTML message is too messed up -> Delete to trash!

Edit: People can't figure out how to make relative well formed HTML for the browser, yet someone thought it was a good idea to introduce the mess to email. Go figure!

The issue here is that most people looking for plain text email want to receive plain text email.

These instructions really only help you to send plain text email. It's unclear if the receivers care either way.

I am sympathetic to the issues around HTML email but it's a hard ship to turn.

I consider support for HTML e-mails which is enabled by default a major bug in a mail client.

He forgot about the even worse AMP emails that come out now.

The problems with HTML email originate in the days when clients like Outlook would produce horrendous, non-responsive HTML that were basically entire embedded web pages; the idea that the sender should be able to dictate the font of an email is a bit ridiculous, not to mention the layout, and the result was often broken depending on the email client.

Emails aren't web pages, but they do benefit from formatting (bold, italics, links, paragraphs), all of which lead to better emails overall. After all, everyone has their plaintext style (asterisks for emphasis, or maybe underscores, etc.) and HTML formalizes those conventions in a way that has been standard for decades and even centuries if you consider typesetting in general.

I like the idea of HTML email better than I like the implementation. I'd love to see a minimal HTML subset that only included formatting (including paragraphs, indentation and blockquoting), images and links. No tables, no box model, fonts or styling. We can keep full HTML for fancy marketing emails, but letter-form email should be simple and impossible to abuse.

These days, of course, most email is HTML simply because that's the default for almost all email apps (Gmail, Outlook, Spark, Polymail, etc.). It's not true that only marketing emails use HTML, as the author claims.

"After all, everyone has their plaintext style"

This is counter to my own experience. I am using (plain text) email since 27 years. Including inline quoting and avoiding top posting at all costs.

People used bold (not sure how to render a '*' in HN) /italic/ and _underscore_ consistently on lists, newsgroups and -- rarely, as seldomly needed -- in private correspondence.

I learned how to do this by example. Everyone being very disciplined about this in the 90's still.

This started deteriorating rapidly in the wake of eternal September [1] and Outlook becoming the standard client in the corporate world, using HTML as default. Personally I blame Outlook for HTML email hell foremost.

It is very simple to display plain text email, omitting aforementioned formatters and applying them. The same goes for displaying in a proportional font (detecting intended indentations from the original and replicating them with tabs, on the fly).

Using such formatters is just another (and not even alien) form of inline markup. Actually the very one that inspired markdown, ReST, etc.

The only reason people use HTML email is that it's the default. Not that it's better in any way.

The average user simply doesn't know any better.

[1] https://en.wikipedia.org/wiki/Eternal_September

"The only reason people use HTML email is that it's the default. Not that it's better in any way."

There are people in this page of comments right here, explaining their use of HTML, their reasoning for using it, and how it's better in many ways.

>We can keep full HTML for fancy marketing emails, but letter-form email should be simple and impossible to abuse.

You had me convinced up until this part. Marketing emails are, IME, the most prone to being abusive. If anyone deserves to have their fingers rapped every time they try to get fancy with HTML mail, it's the scumbags that send marketing email (which is by definition spam).

I was always a strong advocate for plain text emails. Because for many years my mail client was Mutt, I saw everything plain text. Now that clients are graphical, it bothers me to know others might be reading my plain text emails with a "Times New Roman" font, and not a monospaced (as god intended it to be).

So, to avoid that, I use HTML on my emails. Yes, it makes them a bit bigger. Yes, they go against my very belief. Yet, they look like I want them to be seeing.

Have you thought that others may not want to see your emails as you intended?

End recipients can always overwrite, no?

overwriting HTML styles is harder than setting how to format plaintext. HTML styling has order of magnitude more customization options than plaintext, which has three that I can think of: font, font size, tab width. Almost all clients have customization for plaintext, I haven't seen one that can override HTML customizations.

One interesting anecdote about plain text not being the default in most popular email clients come from my own PublicEmails.com email-to-blog-post project. People would experiment with it and the allowed list of HTML tags for formatting (https://publicemails.com/blog/display/772/37f6f81d9a) but would get confused when the tags would render verbatim instead of being processed correctly. They didn't realize they were in HTML mode by default in most email clients like Gmail, and that they would have to manually switch back to plain text if they wanted to use HTML tags.

I ended up adding a question to the FAQ to address this issue specifically, though people still get confused from time to time. There is a touch of irony about it - to get HTML tags to work, you have to be in plain text, not HTML mode. Once you're in HTML mode all that's needed for formatting is the client's own formatting controls.

I'd like to see formatting for email that doesn't have the security and privacy vulnerabilities and complexity of HTML email. Markdown would be fine. Inline images can refer only to attachments in the same message, not to arbitrary URLs. Maybe some restrictions on links to reduce their effectiveness in phishing emails. It would be fine. It would be everything you actually need.

> I'd like to see formatting for email that doesn't have the security and privacy vulnerabilities and complexity of HTML email. Markdown would be fine

Markdown supports arbitrary HTML, and so has exactly the privacy and security implications of HTML (though there extensions available which limit this, and are standard in some markdown processors and expected by default in some markdown variants.)

Okay, to be pedantic, I mean a subset of Markdown that doesn't allow arbitrary HTML, and may have additional restrictions of the types I mentioned.

Who does this page cater to though? The recommended tools are programs that are packaged for Linux or need compiling[1]. If they want to convince anybody who already does not prefer plaintext then they should be targeting the Windows and macOS crowd.

[1]: Later some tools such as thunderbird or configuration for Apple Mail and Gmail are mentioned. They should be top and center.

I'm surprised by the recommendation to use format=flowed. I set up thunderbird a while back to use the recommendations from the LKML: https://www.kernel.org/doc/html/latest/process/email-clients.... Doesn't format=flowed mangle patches?

I've also disabled wrapping (as recommended in that document), however I'm not a big fan of it. I do think that plain text wrapped at 72 or 80 characters looks much nicer. I wish thunderbird allowed me to select portions of the text to wrap, or to disable wrapping for selected portions (e.g. a code snippet). Is this handled better in other email clients?

Now that page recommends using git send-email, on which the author also made a tutorial: https://git-send-email.io

Thanks for the link - this is indeed my stance, I don't think people should be pasting patches into their daily MUA.

That should be highlighted more. Not using git sendmail is the problem, not format=flowed.

> Doesn't format=flowed mangle patches?

It will because every line would end in a single trailing whitespace character. But that doesn't mean you cannot use Thunderbird with format=flowed enabled to respond to patch emails. Unless you're including a patch in the message and expect someone to use git am to apply it to their local git repo, having format=flowed set won't matter.

> I wish thunderbird allowed me to select portions of the text to wrap, or to disable wrapping for selected portions

You can sort of do it by copying unwrapped text from another program and pasting it into Thunderbird as quoted text (ctrl-shift-o or paste as quotation). But you will need to manually remove the quote markers from the beginning of each line.

If you do format=flowed correctly, then code is not mangled.

However, there is a higher risk (than with hard-wrapped) that users can mangle code with format=flowed.

I think it comes down to a lack of flexibility with the MUA composer. If you're using an editor like vim to compose the email, it would be easy enough to read the patch into the message by running

  :r file-containing-patch

And then visually highlighting text and running:

  :'<,'>s/$/\s/

to append whitespace to lines you don't want to be hard-wrapped in clients that support format=flowed

Un-un-popular opinion: Top-posting is fine. Interleaved posting is great, too. Bottom posting is idiotic.

It seems to me this webpage uses "bottom-posting" to include both what Wikipedia [1] calls bottom-posting and what it calls interleaved posting or inline replying. For example, in the section called "Top posting", the webpage advises you to "Write anything you have to say underneath the quote it pertains to.", which is interleaved posting (unless you only quote one thing).

Is this abuse of language common? Am I actually on the side of bottom-posters because they really mean "write anything you have to say underneath the quote it pertains to" rather than "reply to everything at the bottom"?

[1] https://en.wikipedia.org/wiki/Posting_style

> SquirrelMail

I really REALLY wish they'd make a new release (there is work on still going on but the latest release is from 2013). SquirrelMail is my favorite webmail since it was first available on a shared host i used early 2000s or so. So simple and lightweight. But the lack of releases apparently made Debian to remove it, then followed by several other hosts. I could set up a VPS to have it myself but i do not really want to bother with mail administration (if anything, not wanting to bother with mail was one of the main reasons i switched to shared hosting - which initially had SquirrelMail, to my delight, but sadly got rid of it some months later).

Plaintext email was doomed from the moment it got named "email" rather than "etelegram". Regular mail can include graphics, different fonts, color, bold, etc., so it is natural to expect email to handle that too.

Early email systems could not, but because they ran on systems that could only display simple text, the natural assumption is that they were plain because of technological limitations.

Once GUI systems became the norm, removing that limitation, it was inevitable that email would follow.

This is not to say that HTML email is good. It was inevitable that email would support rich text, inline attachments, and stuff like that that, but HTML did not have to be the way that was done.

> Top posting

> When you reply to an email, many email clients will infer and include a quoted version of the message you're replying to above the text of your reply, or else prompt if the context is ambiguous. This is normal-- it happens in clients that conform to RFC -1 which use data gleaned from your input to prevent long email threads containing the entire history of the discussion in an increasingly long and nested footer on every email. This is called "top post prevention" and is required in all conforming clients. Please email your admin if your client doesn't conform to this specification.

There are just different use cases for plaintext and HTML email. I can't implement plaintext only email in some environments because it just won't work with who I'm communicating with.

> Notice: Use of IMAP and SMTP with Protonmail requires the use of a special third-party bridge. Protonmail is not recommended for this reason.

I am a bit tired of this campaign against Protonmail by Sir_Cmpwn. Yeah you can't use SMTP directly. But if he was being objective would gmail not get a disclaimer "Google read your emails to work out what to sell you, and pass this on to government surveillance too"...Outlook is not recommended because... insert whichever gripe about protocols is on your mind.

Why just only such black and white dilemma?

It could be a different format altogether - something third as the golden mean.

Alternatives: Markdown (we need specification for that) or HTML v2.0 or something else.

Requirements to such format:

- it shall provide only one way of text -> rendering and rendering -> text so WYSIWYG can be implemented in non-controversial manner.

If HTML then HTML v. 2.0 as the last version that supported WYSIWYG editing (as it has no CSS). CSS is allowed to be applied by email agent application (user's theming) but not from the body of the message.

Agree. Hyperlinks and the subset used by term emulators today. For example bold and tables can be rendered on even terminal emulators today. Another issue is probably captioning.

I use Claws Mail with the "Fancy HTML Viewer" plugin -- by default emails get rendered in plaintext but I can hit a few buttons to see the HTML version if I really need to (only happens occasionally). I only compose messages in plaintext, as do most of my coworkers, and it works great. The only thing that's still a problem is top posting... as much as I hate it, I'm not going to be That Guy and reply to a 8-email-deep 6-participant chain at the bottom.

> HTML emails are mainly used for marketing - that is, emails you probably don't want to see in the first place

Wait what?

Maybe you're subscribed to the wrong newsletter, but in my case, I'm subscribed to products / brand I like, I'm aware that I will receive advertisement / product updates and I'm fine with it !

The list of recommended mail clients had nothing for mobile. Is it because good ones don't exist?

I'm a happy GMail (android+webmail) user because the usability is good enough and I don't need to install and configure stuff.

If I wanted to send plaintext email from my Android phone, is there a reasonably easy and usable way to do it?

The claims against Protonmail and Tutanota (possibly others, but the are the two I saw) are from a place of ignorance. Both are the way the re because they are decrypted clientside.

IMAP/SMTP needs a bridge or is inaccessible because of the needed decryption step.

Does anyone else hate when someone assumes their screenwidth and hard wraps at 72 characters?

For me it's not about the screen width. It's simply unergonomic to read wide lines of text. Ever wondered why book pages are vertically-oriented? I don't want my eyes to run a marathon from left to right with each line of text.

Thanks, I apparently found out that Claws Mail had Windows version. Default Windows E-mail client does not support text mode at all and I prefer text mode, so I'll try it.

It's ironic to me that useplaintext.email uses formatting and design to communicate intention that would be impossible in a plaintext email

This whole discussion is making me hesitate to actually switch from plain text to html emails… unforeseen consequences!

Why is this a Show HN? It's just a web page, isn't it?

Probably because the first email client linked is his new plaintext and patch oriented email client aerc?

It actually looks pretty nice and supports maildir, so I might run a backup and point it at mine for a couple days to see how it holds up.

Probably because Sir_Cmpwn just made it. Considering his other e-mail-related website[1], I'd say that's why.

[1] https://git-send-email.io/

Yeah but it's not really a project he's showing of, just a rant about people sending HTML emails.

That's not what Show HN is for. I don't submit my articles that way.

It's for things (apps etc.) you can try out. Not for essays.

Yeah, but you're not Sir_Cmpwn. At this point, Sir_Cmpwn is practically a celebrity here with all the perks that this entails.

You can apply the information on this page to configuring your mail client (and should!). It's also intended to serve as a one stop resource for cataloguing plaintext support in most, if not all, mail clients, in the future.

Still no Show HN. You've been here long enough to know that.

This belongs in my ~/.signature

Reply on news.ycombinator.com