Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson <[e-mail]>]

On 8/7/20 9:32 PM, John Levine wrote:
>> We need spoofing protection for all of our domains without being told we're misdeploying.
>
> I would be interested to better undertstand the meaning of "need"
> here. It is my impression that most people vastly overestimate how
> much of a phish target they are. Paypal and big banks certainly are, 
> other places, a lot less so.

(Sorry, I was on a much-needed vacation.)

Ok, that's fair, I should have realized that one was over-stated.  *Need* would imply that domain-spoofing is more common than it is in reality.

Cybersecurity-minded folk in EDU tend to equate observed inbound phishing with spoofing (even though most phishing is spoofing the display name and message bodies, not the domain) and conclude that they *need* DMARC without really understanding the nuances.  Given the opportunity that DMARC marketing promises, they definitely *want* inbound DMARC enforcement for domain-spoofing of inbound mail (they'll defer to the email-minded folk to figure out the local policy exemptions, ARC, etc), as well as *want* domain policies that prevent the potential domain spoofing scenarios of owned domains (again, the email-minded folk will figure out how to actually "misdeploy" DMARC).  To them, it's just a checkmark towards some "maturity" benchmark that they use to compare to their peers.

Email-minded folk in EDU, knowing that DMARC doesn't really have much practical application to phishing, like having the observability that DMARC provides, as well as the hammer that moving past p=none provides as a way to coerce their complex, decentralized institution into a more sustainable operation: 

* Departments sending transactional email - move them to dedicated subdomains (this is where really complex institutions would benefit from walking the domain tree instead of always inheriting from the org domain)

* People sending user email from random places - move them to authenticated submission (preferably OAuth - since basic authentication is the reason why so many passwords are exposed)

The latter scenario is interesting because a single user sending from a random place doesn't really show up in DMARC aggregate reports.  It may show up in forensic reports, but it is easily lost in the noise.  (SPF macros might be another way to get fine-grained observability, but that's a privacy leakage IMO.)

In the end, it still results in:
* That person wouldn't end up on our radar for communication
* That person wouldn't understand what the message is about, even if we did communicate with them
* That person wouldn't comply, even if they understood
* Once enforcement is in place, that person will complain and leverage every ounce of their political influence to resist.  (It's really fun when your own users threaten lawsuits against you - that doesn't happen in Corporate IT.)

I'm kind of rambling now, I see.  Hope you find it enlightening, regardless!

Jesse