Live data from Hacker News

Use plaintext email

useplaintext.email

51–60 of 345 posts

Re: Use plaintext email

#51
post #45

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

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

Re: Use plaintext email

#52
post #45

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

> 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

Re: Use plaintext email

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

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

Re: Use plaintext email

#54
post #8

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

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?

Re: Use plaintext email

#56
post #42

Earlier quoted context omitted.

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.

Clearly I disagree. Feel free to ask the mods to clarify and update the title accordingly.

Re: Use plaintext email

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

Re: Use plaintext email

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

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.

Re: Use plaintext email

#59

Earlier quoted context omitted.

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.

Re: Use plaintext email

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

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

Post reply on HN