Hacker News Reader

Comment by no_gravity | Hacker News Reader

One reason is that SPF already accomplishes good enough sender identification without any hassle on the user side.

When you get an email from joe@example.com and example.com is trustworthy and uses SPF, then you know that the sender in fact was joe@example.com

It's easy enough to set up SPF for any domain.

Gmail, Yahoo, Outlook etc all use it.

View on HN

SPF can be a massive hassle since it's based on which server is sending emails, rather than which organisation is sending emails. Change some server and your SPF breaks. In a large organisations there can be a bunch of different ways of sending emails (main app uses SendGrid, marketing team uses SureyMonkey, some 3rdparty tool uses something else, etc.) In practice, I see administrators get SPF wrong all the time, which is why it's rare to see a hard-reject policy.

In addition, the limitations of DKIM also apply to SPF:

> DKIM is useful, but limited. All it does is verify that an email which claims to be from paypal.com is really from paypal.com. What it lacks is the ability to show warnings such as “this email wasn’t signed, do you want to trust it?” and “this signature isn’t recognized, yikes!”

> What it lacks is the ability to show warnings such as “this email wasn’t signed, do you want to trust it?” and “this signature isn’t recognized, yikes!”

Such a warning already exists: https://lifehacker.com/stop-looking-like-a-phisher-in-gmail-...

SPF is in general unusable because there are sufficient domains of sufficiently high value that don't have properly configured SPF records.

Source: spent years maintaining a broken or missing SPF whitelist..

I don't see how this would be different with PGP.

Reply on news.ycombinator.com