Hacker News Reader

Comment by snowwrestler | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com