Live data from Hacker News

Use plaintext email

useplaintext.email

81–90 of 345 posts

Re: Use plaintext email

#81

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 -…

My own client:

lumail, c++, gpl

https://github.com/lumail/lumail

Re: Use plaintext email

#82
post #46

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 yo…

> 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.

Re: Use plaintext email

#83
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.

Re: Use plaintext email

#84
post #7

Earlier quoted context omitted.

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

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

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?

Re: Use plaintext email

#85
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.

Re: Use plaintext email

#86
post #11

>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…

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.

Re: Use plaintext email

#87
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.

Re: Use plaintext email

#88

Earlier quoted context omitted.

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.

> 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.

See also embedding (e.g.) a JPEG in a Word document and then attaching that Word document to an e-mail.

Re: Use plaintext email

#89
post #83

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…

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?

Re: Use plaintext email

#90
post #87

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…

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).

Post reply on HN