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

291–300 of 345 posts

Re: Use plaintext email

#291

Post by c-smile »

Why just only such black and white dilemma?

It could be a different format altogether - something third as the golden mean.

Alternatives: Markdown (we need specification for that) or HTML v2.0 or something else.

Requirements to such format:

- it shall provide only one way of text -> rendering and rendering -> text so WYSIWYG can be implemented in non-controversial manner.

If HTML then HTML v. 2.0 as the last version that supported WYSIWYG editing (as it has no CSS). CSS is allowed to be applied by email agent application (user's theming) but not from the body of the message.

Re: Use plaintext email

#292

Post by astrobe_ »

pmlnr wrote: post #149
wyldfire wrote: post #134

Earlier quoted context omitted.

> Being able to use color, or bold, or italics, makes a difference in communication. It really does. Color, especially helps people find the relevant/critical part.

No, this is not true at all. People will _only_ read the color part and skip anything else, which is equally bad to not finding it immediately, if not worse. And there are also color blind people for whom the color might be even worse than the lack of it.

Yes. The argument almost defeats itself: why do you waste my time with irrelevant stuff? Why did you make read a whole page of details before coming to the critical point?

That has been my experience: make your messages as short and straight to the point as possible. Put the most important stuff first and the gory details only the curious will read, last. That goes for documentation too.

HTML mail gives the illusion that fancy formatting can make up for mediocre writing skills. That's sad, because no amount of bold face, color or indentation can fix an inconsistently structured piece.

You learn that stuff at school, make your tuition fees (and/or the time you have been forced to invested in it instead of being young and having fun) worth it.

Re: Use plaintext email

#293

Post by snowwrestler »

deftnerd wrote: post #273
snowwrestler wrote: post #261

Earlier quoted context omitted.

If an HTML phishing email is hiding an obviously malicious URL behind an image or button, then yeah, that URL would be more visible in a plain text email. But it's also visible in the address bar of the browser after you click it... and people will fill in the form anyway. Plain text doesn't solve complacency and distraction, it doesn't solve URL composition tricks and redirect wrappers, it doesn't solve spoofing, an…

Ideally, it would be nice to enable phishing links to be identified before they are clicked. This could prevent the remote server from logging any metadata about the browser accessing the link (date/time, browser type, ip address, etc). It also prevents any possibility of browser vulnerabilities being taken advantage of. What might be an interesting solution is to standardize an addition in the SMTP standard to requi…

This is basically what DMARC is intended to do. The receiving email server checks SPF to see if the sending IP is authorized to send on behalf of the "from" domain. If SPF fails, it checks the DMARC policy to see what to do. If the DMARC policy on that domain is set to "reject," the email is discarded and the user never sees it.

The risk with this system is that, if it is misconfigured at all, some of your legitimate email will get discarded too. Seems like this would also be a risk of your proposed system.

So, for now most folks are either not using DMARC or have their policy set to "none", which generates reports on spoofing but doesn't discard any emails.

And I should be clear here that this only stops domain-based spoofing. Phishing emails can still succeed without that. I could send you an email with the visible "from" address "Paul Graham, YCombinator" or "Paypal Support" and the from email address of dklj09qw43jadj0u9qoi4jjdoi089ue@example.com. If you don't bother to check the email address, you could still get fooled.

Re: Use plaintext email

#294

Post by cylentwolf »

u801e wrote: post #150
masukomi wrote: post #146

Earlier quoted context omitted.

email is a terrible place to keep reference documents. "where's the information on that?" "oh, you should have it in your email somewhere. I think I got one a few months ago about it" no. just. no. If you care _at all_ about your reference documents you get them out of email ASAP. And that's ignoring that anyone can delete old emails and thus not have what you considered a reference doc but they just considered old m…

> email is a terrible place to keep reference documents. Newsgroups are better in that regard. You can reference the message using the message-id value. A lot of newsgroups would have FAQS posted every 30 days or so. A reference document that's periodically updated could be sent the same way.

Isn't this what Slack is trying to do for the workplace? A messaging system that provides reference history?

Re: Use plaintext email

#295

Post by darkpuma »

SifJar wrote: post #162
zepolen wrote: post #157

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…

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)

I've seen professionally-oriented PHP forums and they are no better than any casual-interest oriented PHP forum.

Tons of visual clutter with all kinds of rectangles nested inside each other all over the screen with little apparent purpose for any of them. Join dates of users are given higher visual precedence to the date a comment was made (why is the join date of a user even visible on a discussion page at all?? That's pointless clutter!) 90% of users attaching signatures to every comment they leave with the signature body being longer than whatever remark they left, and often being filled with shitty animated gifs that look like they were stolen from somebody's geocities page.

It's a trash medium. Fundamentally flawed. Trying to fix typical PHP forums is like trying to polish a turd.

Re: Use plaintext email

#297

Post by u801e »

nailer wrote: post #251
u801e wrote: post #158

Earlier quoted context omitted.

The reason it's 72 characters is to allow for quoted text, which gets indented relative to the new text. That would allow a line in an email that's 72 characters long to still fit within 80 characters if it's prefixed with 8 quote characters. For example: >>>>>>>>This line was 72 characters long, but is now 80 characters long instead.

Still looks pretty bad on anything less than 72 characters because there's random newlines in the middle of paragraphs. Content should be separated from presentation. Additionally 72 characters implies monospace fonts which have been shown to be less readable.

> Content should be separated from presentation.

Not necessarily. There are times where text should not be wrapped (code snippets, error messages, or log output), but if text is softwrapped, then there's no way to prevent that text from getting wrapped unless you use some time of mark up like HTML or markdown. This requires that the client supports that type of markup which isn't always the case.

There is an RFC[1] that describes the format=flowed option in the MIME headers that addresses the wrapping issue (where text that should be soft-wrapped should have trailing whitespace at the end of each line). That would work with email clients that support that feature and will still appear to be hard-wrapped to email clients that do not. So, unlike HTML or markdown, we don't require those who use clients that only support plain text to update their clients to support a new feature. We can use that feature in clients that support it and have a sensible fallback for clients that do not.

[1] https://www.ietf.org/rfc/rfc3676.txt

Re: Use plaintext email

#298

Post by abjKT26nO8 »

gdfasfklshg4 wrote: post #125

Does anyone else hate when someone assumes their screenwidth and hard wraps at 72 characters?

For me it's not about the screen width. It's simply unergonomic to read wide lines of text. Ever wondered why book pages are vertically-oriented? I don't want my eyes to run a marathon from left to right with each line of text.

Re: Use plaintext email

#299

Post by u801e »

neuronic wrote: post #155
u801e wrote: post #147

Earlier quoted context omitted.

> Being able to embed screenshots is awesome. Being able to use color, or bold, or italics, makes a difference in communication. Yet, you cannot do any of that on HN (other than a limited case like italic ). But, we can communicate just fine without those features. I suppose it's really a difference of a read once message versus having a discussion. In a read once message, you can format it like you describe. That's…

Communicating just fine is not the same as communicating at optimum. In the analog world, you could just hand over a white, plaintext birthday card. Or you could give one with a motive, color, some doodles and maybe a memorable photograph attached. Which one is more memorable? "It's used by marketing." is not an arguments against it. We have sophisticated spam filters. Update your rules then.

I would say that the birthday card example is a read once message example, and not something that's going to be discussed at length like a patch on a development mailing list.

Re: Use plaintext email

#300

Post by yakubin »

camillomiller wrote: post #142

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.

Yeah, you really have to be a high-skilled h@x0r to write a plain text mail. /s
Post reply on HN