Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use plaintext email

useplaintext.email

Post reply on HN
Print view View original

91–100 of 345 posts

Re: Use plaintext email

#91

Post by gpapilion »

owenmarshall wrote: post #13

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

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.

Re: Use plaintext email

#92

Post by bdcravens »

tjoff wrote: 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…

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)

Re: Use plaintext email

#93

Post by tyingq »

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.

Re: Use plaintext email

#95

Post by mbreese »

robenkleene wrote: post #73
thatguyagain wrote: post #54

Earlier quoted context omitted.

> "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”?

Or perhaps the parent commenter is part of the lost generation of email users that never properly used quoted replies in email conversations. And this is not necessarily an comment on the age of the parent commenter, but rather about what email programs were common at the time. I blame Outlook mainly for this, but Gmail hasn’t done much to help here either.

The use of quotes in replies is also part of the article and is definitely a better way to go with bottom replies than the current default of top replies.

Re: Use plaintext email

#96

Post by lawn »

upofadown wrote: post #59
wongarsu wrote: post #19

Earlier quoted context omitted.

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.

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.

Re: Use plaintext email

#97

Post by ignaloidas »

mgulick wrote: post #77

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

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

Re: Use plaintext email

#98

Post by chapium »

jraph wrote: 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…

hard wrap at 72 characters seems pretty conservative

Re: Use plaintext email

#99

Post by upofadown »

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

Re: Use plaintext email

#100

Post by _urga »

bo1024 wrote: post #51
jraph wrote: 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

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.

Post reply on HN