Hacker News Reader

Comment by laumars | Hacker News Reader

I would like to see the replacement of SMTP be designed along with a redesign of e-mails themselves as well.

I'd like to see the HTML that is supported in e-mails standardised, so there's no more issues about which clients will render what. I'd like to see the failure notices standardised, so that invalid e-mail addresses produce a standard "404-like" response, and so on.

The problem isn't so much that we have multiple implementations (I agree that can potentially be a strength). The problem is that there's very little that's consistent across the platforms.

View on HN

I'd like to see the HTML that is supported in e-mails standardised

Count me out. It wasn't even two weeks ago that we had the story here about how The Onion was hacked because somebody clicked on an obfuscated HTML URL in email.

I wonder if this could be fixed by displaying SSL certificate status next to email titles. Much like browsers do for websites. This way before you open or at least before you click anything in the email you can see the validity of the sender.

While we're at it, let's all abandon HTML5 and have every browser doing their own thing, because people occasional fall for fake anti-virus ads. </sarcasm>

We can't stop social engineering like that - it's completely unavoidable. Which is why banks and payment providers regularly tell people not to follow links asking for bank details (etc). Yeah it sucks that The Onion got hacked that way, but your argument is doesn't fix that. Your argument is nothing more than cutting of your nose to spite your face (ie advocating an inconsistent platform for legitimate e-mails despite anchor tags working on every client already).

At least if e-mail was completely redesigned, then we could have banks provide a unique cert that hangs in the e-mail header and can support the authenticity claim of the sender (I'm sure there's ways around that idea I've just presented - but that was just off the top of my head. Any such design would obviously need to be thoroughly thought out)

I think he's saying we should instead have text-only e-mail, because that's both standard and has a tiny attack surface.

That doesn't fix anything either. Many clients make URLs clickable (even with text-only emails) and even if those clients didn't do that, someone will just copy and paste a URL into the address bar without looking. Given that the average user isn't an expert on domain names, it's not actually that hard to trick them into thinking that face.book.com isn't the same as facebook.com (and even those that are savvy enough to know the difference might misread the link and get fooled occasionally).

So like I said before, it's impossible to prevent social engineering.

It's impossible to prevent all cases of social engineering with a purely technical solution, this is true. But that doesn't mean that we should disregard how much easier phishing attacks are with the advent of HTML mail. The goal here is not so much to stop social engineering dead in its tracks as to prevent some of the low-effort attacks that do happen.

But again, I refer you to my HTML5 example. Should we dumb down what websites are capable of rendering to prevent social engineering via the web?

What you're proposing is making things harder to work in the hope that human intelligence will prevail. But the problem is that these cases are where human intelligence has failed, so making things harder is just counter productive. And this is why you can't prevent social engineering from happening and why crippling technology and creating a worse user experience just to try catch a few fringe cases is just a backwards approach to handling the issue.

Instead what we need is methods in place to verify the authenticity of senders and better education to users so that don't make silly mistakes like installing random "virus scanners" from web ads or clicking strange URLs in e-mails (and the URLs themselves could be standardised. eg no sub-domains become clickable, to prevent people falling for face.book.com).

But again, I refer you to my HTML5 example. Should we dumb down what websites are capable of rendering to prevent social engineering via the web?

Strawman; we're talking about email, where the combination of header forging and HTML mis-labeling are what's really dangerous, not web pages.

No, we're talking about social engineering and the principle is the same regardless of whether it's e-mail or websites. You take a page -be that of an e-mail or website- make it look legitimate, and get people to follow dodgy links or download dodgy programs. You see the same thing with Facebook malware as well (which spreads by social engineering). So maybe we should close Facebook apps down.....actually, I'd be in favour of that last point hehehe.

Claiming this is a straw man argument only demonstrates how unwilling you are to view this from another's perspective. At least I've listened to your arguments and come up with potential workarounds.

The very fact that in HTML, a URL can look like a totally legitimate URL (the part between the > and the &lt), and yet the "a href=" could be anything, makes HTML a bad idea for email, where headers can be easily forged. Sure people can (and do) copy and paste, but having it in HTML just makes it that much harder to check a URL. Don't even get me started about the "onmouseover" events that can further obscure the true href.

I'd already addressed the hypertext argument in this discussion somewhere. And that point is one of the reasons why I want HTML standardised in e-mails, so we can remove the potentially harmful things like that from the e-mail spec and make it simpler for developers to create formated content (that's also safe for the end users) which will be rendered correctly across the various clients.

So yes, I do agree with you that anchor tags are misused in phishing mail, but let's make that a reason to fix the specification rather than just ignoring the issues completely (or worse yet, officially removing HTML and then letting 3rd party developers invent their own broken specs and us ending back exactly where were are now).

As for your comment about mouse over events, you can't have Javascript in HTML e-mails so that point is completely irrelevant.

You can't put the genie back in the bottle, unfortunately. Most people use clients that support HTML right now, and a new format that doesn't support some sort of rich text decoration (like HTML) isn't going to become popular enough to matter.

A ridiculously cheap and powerful alternative to HTML (or any other static format for that matter), would be a bytecode format intended to be executed in a sandboxed virtual machine. Possibly something like Flash. That should give you all the bells and whistles you could possibly want with a document format.

Now, there still are some loose ends about various screen sizes, preferred font family and size, and of course allowing textual searches, but those parameters should be few enough to be less problematic that HTML is right now.

Really? Flash is more secure than HTML? Maybe we should just embed Java applets in emails? This still doesn't solve the "click a link that takes them elsewhere" issue that was brought up.

I did say "sandboxed", did I not? Just have your VM refuse to download anything before you click somewhere, and let it compute the relevant URL so it can show it to you the way Firefox does. If this is too harsh, then relax the restriction to only download to, say, the domain name of the current main URL. If this is still too harsh, then have a NoScript like button to relax restrictions manually, on a case by case basis.

It would disable any form of cross scripting by default, which in my opinion is a better state of affairs than HTML alone is right now (now, you can embed an external image in a web page, and bam, Facebook knows what you read).

I'd like to see it standardized that HTML is not supported in e-mails. Email worked fine before HTML came along and all the good email is still HTML-free... in my experience, only robots use HTML.

While the vast majority of my correspondence is plain text formatted. I do think there's a place for markup. Something that can embed images, provide different formatting styling (bold, italics, underline, colours and perhaps even sizes). It's also nice having an option between serif, sans serif and monospaced typefaces.

Then there's hyperlinks. If not like HTML anchor tags were the hypertext is independent to the destination, but still some method to follow links in e-mails as a lot of online registration requires email activation that way.

So do think there is a benefit for some level of markup in e-mails.

> Then there's hyperlinks. If not like HTML anchor tags were the hypertext is independent to the destination, but still some method to follow links in e-mails as a lot of online registration requires email activation that way.

Well, there's the (IIRC) RFC-specified way to write URLs within '<URL:' and '>' pairs, e.g. <URL:https://news.ycombinator.com/>; (interestingly, the HN URL-finder doesn't support that).

There's a million different ways it can be done. I only suggest a HTML-derived format because of familiarity.

Plain text works fine in ASCII world. But if you ever need to read bi-directional emails like I did(e.g. Arabic text with some English words) you will understand the necessity of using HTML in email. Without proper formatting and markup that HTML offers, English words seem to fly around the text and end up at semi-random places.

I wish to see better support for non-ASCII plain text in email clients and web browsers, but until the HTML is all I have.

Reply on news.ycombinator.com