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.
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.