Spf/dkim already authenticates the sender. But it doesn't help if the user doesn't check who the email is from. But in that case gpg would not help that much either.

▲

elric 5 days ago | parent | next [-]

SPF & DKIM are all but worthless in practice, because so many companies send emails from garbage domains, or add large scale marketing platforms (like mailchimp) to their SPF records.

Like Citroen sends software update notifications for their cars from mmy-customerportal.com. That URL looks and sounds like a phisher's paradise. But somehow, it's legit. How can we expect any user to make the right decision when we push this kind of garbage in their face?

▲

JimDabell 5 days ago | parent | next [-]

The problem is there is no continuity. An email from an organisation that has emailed you a hundred times before looks the same as an email from somebody who has never emailed you before. Your inbox is a collection of legitimate email floating in a vast ocean of email of dubious provenance.

I think there’s a fairly straightforward way of fixing this: contact requests for email. The first email anybody sends you has an attachment that requests a token. Mail clients sort these into a “friend request” queue. When the request is accepted, the sender gets the token, and the mail gets delivered to the inbox. From that point on, the sender uses the token. Emails that use tokens can skip all the spam filters because they are known to be sent by authorised senders.

This has the effect of separating inbound email into two collections: the inbox, containing trustworthy email where you explicitly granted authorisation to the sender; and the contact request queue.

If a phisher sends you email, then it will end up in the new request queue, not your inbox. That should be a big glaring warning that it’s not a normal email from somebody you know. You would have to accept their contact request in order to even read the phishing email.

I went into more detail about the benefits of this system and how it can be implemented in this comment:

https://news.ycombinator.com/item?id=44969726

▲

zokier 5 days ago | parent [-]

You don't need complex token arrangements for this. You can just filter emails based on their from addresses.

▲

JimDabell 5 days ago | parent [-]

Unfortunately, it’s not that simple. It’s extremely common for the same organisation to send emails from different addresses, different domains, and different servers, for many different reasons.

▲

waynesonfire 4 days ago | parent [-]

You can just filter emails based on their from addresses.

▲

JimDabell 4 days ago | parent [-]

So if an organisation emails you from no-reply@notifications.example.com, mailing-list@examplemail.com, and bob.smith@examplecorp.com, and the phisher emails you from support@example.help, which filter based on their from addresses makes all the legitimate ones show up as the same sender while excluding the phishing email?

▲

artemisart 4 days ago | parent | next [-]

Why should we expect companies to be able to reuse the correct token if they can't coordinate on using a single domain in the first place?

▲

JimDabell 4 days ago | parent [-]

Your assumption that they use more than one domain by accident due to a lack of coördination is not correct. Separating, e.g. your product email from your mailing list email from your corporate email has a number of benefits.

Anyway, I already mentioned a solid incentive for them to use the correct token. Go back and read my earlier comment.

	▲	cuu508 4 days ago \| parent [-]
		It is correct at least in some cases. https://news.ycombinator.com/item?id=45190323

▲

zahlman 4 days ago | parent | prev [-]

> which filter based on their from addresses makes all the legitimate ones show up as the same sender while excluding the phishing email?

This is the wrong question.

The right question is: what should we do about the fact that the organization has such terrible security practice?

And the answer is: call them on the phone, and tell them that you will not do business with them until they fix their shit.

	▲	jve 4 days ago \| parent \| next [-]
		You're not doing business with NPM by pushing packages there. And who is going to do anything about fixing their stuff when you pay them a mere subscription fee?
	▲	cindyllm 4 days ago \| parent \| prev [-]
		[dead]

▲

zokier 5 days ago | parent | prev [-]

The same problem applies to gpg. If companies can not manage to use consistent from addresses then do you really expect them to do any better with gpg key management?

"All legitimate npm emails are signed with GPG key X" and "All legitimate npm emails come from @npmjs.com" are equally strong statements.

▲

vel0city 5 days ago | parent | prev [-]

There's little reason to think these emails didn't pass SPF/DKIM. They probably "legitimately" own their npmjs[.]help domain and whatever server they used to send the emails is probably approved by them to send for that domain.

	▲	zokier 5 days ago \| parent \| next [-]
		But in the same vein the phishing email can easily be gpg signed too. The problem is to check if the gpg key used to sign the email is legitimate, but that is exactly the same problem as checking if the from address is legitimate.
	▲	mdaniel 4 days ago \| parent \| prev [-]
		No guessing required, DKIM was intact, but it was also sent via a transactional email service, so that's why https://gist.github.com/Qix-/c1f0d4f0d359dffaeec48dbfa1d40ee...