[fc417fc802]

Even that's not sufficient. Consider an email client that doesn't parse images until you interact with the message. So you click on it, realize it's dodgy, but it's too late now because all the complex bug prone machinery has already been triggered.

Or my favorite, I marked an extremely suspicious message with what was almost certainly a malicious attachment as junk in a certain BigTech webmail client (the only other option was phishing which it most certainly was not) and it "helpfully" opened the unsubscribe link in my local browser without first asking me for permission. It's difficult to imagine the level of incompetence and dysfunction required to not only write but review, approve, and deploy such a feature in a security and privacy sensitive context.

[GeekyBear]

The email client I use doesn't display images in an email until I explicitly ask it to.

[marysol5]

Which came as a reaction to "tracking cookies" and the like being added to e-mail.

It was a reaction, not a proactive response.

[fc417fc802]

Rather than tracking cookies it's a form of delivery confirmation via unique url. One of the mitigations is to configure the server to unconditionally fetch (and retain) all embedded media immediately on receipt of the message. Which makes the BigTech example all the more egregious.

[thrownthatway]

That has no bearing on the points made in the comment you replied to.

[gremlinunderway]

Why are you withholding the name of the webmail provider?

Literally the only thing even remotely pressuring these firms to implement better security is bad PR (and it barely does that), so by not being explicit you are bypassing this