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

[Jesse Thompson <[e-mail]>]

On 8/18/20 3:54 AM, Alessandro Vesely wrote:
> On Tue 18/Aug/2020 01:39:16 +0200 Jesse Thompson wrote:
>> 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.)
> 
> 
> Much *needed*?  Oh, well...

Anecdotally.  My family can attest, if that helps ;-)


>> 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.
> 
> 
> Yes, domain spoofing is common.  You don't need to be PayPal to be spoofed.  Then, one can say it's an innocuous kind of abuse.  Since you're not PayPal, it's just noise.  Yet, in a perfect word, I'd opt to avoid it.

Yes, I just can't prove it to the extent that the people saying we're "misdeploying" DMARC would expect me to.  How do I tell the difference between a faculty member innocently using Gmail to send from their personal address within our domain vs. a bad actor doing the same to send spear phishing to a peer at another university?  In my mind, I should just assume that it's a problem, or is potentially a problem, so I'd rather nip it in the bud by deploying DMARC on domains used by users.


>> 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.
> 
> 
> Nice synthesis.  They believe DMARC works as advertised.  What does it take to believe that DMARC /could/ work as advertised?

It seems like we're close.  I am glad that you are pushing back (in the other thread) on the notion that DMARC shouldn't be useful for all types of domains.


>> 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)
> 
> 
> This is a good idea even without DMARC concerns.

Yes, and those departments that we have converted to subdomains seem to be happy with the result.  It usually takes some convincing, however.  People tend to have a strong preference to associate with the brand of the org domain (which is where we have our users).


>> * 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)
> 
> 
> This sound just like an email-client configuration problem.  It shouldn't be so hard.

Gmail is the most common "client" allowing users to submit mail outside of our supported submission pathways.  In theory, Google could make some improvements to Gmailify (to support more OAuth scenarios) and actively transition their legacy users to reconfigure their Gmail settings to properly use our domain, but it's not a high priority for Google (paraphrasing Brandon; hopefully accurately)

It's not much different than people innocently using any random ESP to send newsletters from their personal address.  Because all of these "clients" allow non-authenticated submission of our domain, users have come to expect it to work and they don't want to be told otherwise.


>> The latter scenario is interesting because a single user sending from a random place doesn't really show up in DMARC aggregate reports.
> 
> 
> Why not?  If they send to DMARC-compliant receivers, their aggregate reports should show records without the right MSA signature, not even failed, and foreign domain authentications only.  That doesn't tell which users misconfigured their client, but gives a good idea of the level of user education one has achieved.

Right, you only get metrics indicating a relative volume of users who may fall into various camps.  It is complicated when the domain is also used for transactional mail; which is something that happens entirely out of our control specifically because DMARC enforcement wasn't in place when email was invented.  

This is where the DMARC reporting analysis services come into play, since they do a good job at identifying the ESPs (from the raw data) that are sending the non-compliant mail.  But again, aggregate reports don't show the left hand side of the address, so they can't be used to identify specific users.  To get that, you need forensic reports, or use SPF macros; both options having their pitfalls.


> It should also show which domains users tend to use for submission, in case an organization wants to automate third-party authorization...

Yes, aggregate reports are great at identifying which of our domains have successfully isolated transactional mail and have set up third-party authorization.  

If we see from aggregates that pharmacy.wisc.edu is using an ESP but have neglected setting up SPF/DKIM per the ESP's instructions, then we know who to reach out to and how to help them.  They're already on the right track, anyway.  That's the happy path.  There are many other scenarios.

Jesse