Live data from Hacker News

Use plaintext email

useplaintext.email

231–240 of 345 posts

Re: Use plaintext email

#231

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

Re: Use plaintext email

#232

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

Re: Use plaintext email

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

Re: Use plaintext email

#234

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.

Re: Use plaintext email

#235
post #219

Earlier quoted context omitted.

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

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

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.

Re: Use plaintext email

#236
post #31

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

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

Re: Use plaintext email

#237

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

Can you fill out this survey for me?

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

Re: Use plaintext email

#239
post #195

Earlier quoted context omitted.

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

Re: Use plaintext email

#240

Earlier quoted context omitted.

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

So you have never received a message like this in your inbox. No notifications from various services/companies you use on a daily basis. Who's arguing in bad faith again?

The post is arguing that individuals should switch to sending traditional plain text email, and recommending mail clients that support it well.

Yes, many companies make painful HTML emails, but that's orthagonal to this discussion.

Post reply on HN