Hacker News Reader

Comment by tqwhite | Hacker News Reader

What a load of bollocks. The arguments against come down to, 'you are an idiot who can't figure out phishing links' and, well, that's it. Something about marketing emails. Stupid. Luddite. I'm surprised they don't insist you use a monospace type face in your email reader to give it that late eighties feel.

I have always used HTML email, even when it was new and poorly supported. I want people who read my email to see a nice appearance. I like bold face and sometimes images.

"Strongly preferred". An appeal to the Authority Fallacy is an indication of a weak argument. Or, no argument at all.

View on HN

I think this opinion is strongly worded and might get some heat, but I think you touch on something important.

Plaintext email often serves as an in group shibboleth to distinguish “us” from “the other lusers”. Does it have merit beyond that, or do these articles just reinforce that?

I think the main issue at play here is quoting. In particular, how bad rich text/html mail programs are at dealing with inline quoting. In my opinion, that’s the main “feature” of email communication that has been lost over the years. On the top replies make it difficult to follow a nested thread of emails.

If html email clients handled this better, I don’t think there would be as much of a problem. I think you’re right though that plain text acts as a bit of a shibboleth to differentiate “advanced” users vs luddites. But the main thing that I’ve heard people complain about with respect to html email is the loss of inline quoting.

Plaintext has its issues too— in particular long line soft wrapping. Which some would argue would be better supported if html email hadn’t become so popular.

I absolutely agree -- the aspect of email I miss from the good ol' days was well-trimmed replies and doing so inline. Threaded inboxes and smart trimming helps, but not completely.

However I think that HTML clients handle this well enough but the etiquette has been completely lost.

    Because it messes up the order in which people normally read text.
    > Why is top-posting such a bad thing?
    >> Top-posting.
    >>> What is the most annoying thing in e-mail?

The cultural aspect of this web page is pretty clear in that the author even formats his HTML to look like plaintext, which is completely unnecessary from a technical perspective. In fact it took extra effort to do that, as opposed to just allowing each browser to supply its default font.

People who fall for phishing are not idiots. Even technical people can be fooled by clever spear phishing.

You're right. That was too strongly said. Some people are naive or make a mistake. However, nobody I know lacks for emphatic instruction to never, ever click a link on an email. If your bank wants you to login, use your own bookmark.

This is true, but it's also true that plain text emails do not prevent phishing.

No, but I think it's fair to say that they make it more difficult.

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, and it doesn't solve malicious attachments.

If Google's account emails were all plain text, I'm sure phishers would figure out how to make them look as identical to Google's emails as possible, and still get some people.

IMO we already know some good ways to mitigate phishing, but their implementation is spotty: DMARC, hardware token 2FA, and good IT practices in terms of patching, privilege, and backups.

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 require the ability to verify message ID's and also return some kind of Content Security Policy equivilent.

Every mail message gets assigned an ID. When you receive a message from support@paypal.com, it would be nice if your mail client could connect to paypal.com and ask if the message ID was legitimate and it would reply that it was, and that the only URL's whitelisted in the email would be example.com, anotherexample.com, etc.

Some downsides that would need to be addressed is that this would mean email clients would inadvertently expose their IP address to the sending server, and some thought would have to be used to prevent fraudulent emails from just replaying existing message ID's.

I just feel like there is a possible solution that the industry isn't seeing or implementing.

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.

HTML emails usually load remote (tracking) images.

Even with "load remote images" turned off, Apple Mail will "helpfully" load them anyway if you forward an email.

Reply on news.ycombinator.com