Live data from Hacker News

Use plaintext email

useplaintext.email

241–250 of 345 posts

Re: Use plaintext email

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

Re: Use plaintext email

#242
post #144

Earlier quoted context omitted.

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

So loading the text part of emails only. That's precisely the topic of discussion.

Loading asynchronously != not loading at all.

Asking for permission before rendering external images != not loading at all, even though we could live without external images and just include everything inline.

Re: Use plaintext email

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

Re: Use plaintext email

#244

Earlier quoted context omitted.

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

I'm not the original poster however I do believe that the guidelines say to assume good faith.

>Clients load images asynchronously

Many clients actually don't load images by default for privacy reasons requiring another click.

Even if not one reasonably assumes that the image may be relevant and waits for it to load. Half the planet also has a pretty slow connection.

>To take the hn example again, the text portion of your comment is broken on mobile

You see the whole thing either turn your phone sideways or scroll sideways.

Re: Use plaintext email

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

Re: Use plaintext email

#246

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.

Re: Use plaintext email

#247
post #96

Earlier quoted context omitted.

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.

Syntax highlighted code can hardly be considered a "reference document".

For the life of me I can’t remember the syntax for a particular thing I do in the JavaScript console at work. Someone showed me the trick in an email about seven years ago and about once a month I need to do this thing so I search my inbox for the email so I can remember the syntax.

Re: Use plaintext email

#248
post #223

Earlier quoted context omitted.

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.

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

Re: Use plaintext email

#249
post #179
post #162

Earlier quoted context omitted.

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)

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

> Same thing with newsgroups (usenet).

good lord, how old are you?

Post reply on HN