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]