Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> If the sending server doesn't do DKIM, it's fundamentally broken,

No, it just won't get very good deliverability, because everything it talks to is now fundamentally broken.

DKIM shouldn't exist. It was a bad idea from day one.

It adds very little real anti-spam value over SPF, but the worse part is exactly the model you describe. DKIM was a largely undiscussed, back-door change to the attributability and repudiability of email, and at the same time the two-tiered model it created is far, far less effective or usable than just end-to-end signing messages at the MUA.



DKIM isn't an antispam measure, it's an anti-impersonation measure. With DKIM, you can't impersonate a domain, which means you can trust that any email you get from an email provider was sent in accordance with that provider's security policy. In most cases, that policy is "one user owns one localpart and they can only send from it if they have their password". In cases where it's not, this is intentional and known by their users.

If you as a user can't trust your email server, you've already lost, no matter if something is authorized by an outbound email or a click on an inbound link. If your mail server is evil or hacked, it can steal your OTP token or activation link just as easily as it can send an email in your name.

Yes, end to end authentication is definitely better, but this isn't what people are discussing here. With enforced DKIM, "send me an email" has a nearly identical security profile to "I've emailed you a link, click on it". Both are inferior to end-to-end crypto.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: