Re: [dmarc-ietf] Domains and tree walk

[Jesse Thompson <[e-mail]>]

On 12/1/20 8:50 PM, John Levine wrote:
> On the other hand, I observe that Brown, Cornell, Dartmouth, U Penn,
> and Yale, whose situations are not altogether unlike Columbia's, all
> publish DMARC records. Closer to home so do NYU and CUNY. They all say
> p=none with rua= to collect reports. You might give them a buzz to see
> how it works for them.

The fact that Joseph is here raising valid deployment concerns shouldn't be overshadowed by an assumption that these other universities are ahead of the game.

I participated in a hi-ed cybersecurity committee to create an "email security maturity" rubric - basically just something that CISOs can use to reflect/compare to each other.  I advocated that publishing p=none and consuming the reports is a good first step, but just maturity level 1 (of 5).  

Some university cybersecurity organizations feel like publishing p=none (and, perhaps, not actually looking at the reports) puts them into "compliance" with this DMARC thing that only their email admins really grok. 

I would hesitate to assume that seeing p=none on a domain as an indicator that they are serious about deploying DMARC and reconciling their own Holy Roman Empire conundrums; rather it's there just to not be seen as lagging behind their peers, justifying funding for more SOC staff and perhaps buying some tools (*some* of which, hopefully, may be deployed to actually solve the issues identified in the DMARC reports).

For better or worse, DHS BOD 18-01 mandated that all federal agencies publish p=reject on their domains.  Now, *that* must have forced each agency to figure out how to actually deploy DMARC and deal with the implications.  I applaud the tenacity.


On 12/2/20 10:21 AM, Todd Herr wrote:
> This is, I think, one of the most underappreciated features of DMARC. With p=none, a proper rua= value, and enough time, one can collect all the information needed to address any authentication shortcomings within a designated portion of the DNS namespace before moving forward to p=reject, assuming that that is one's goal with a DMARC implementation. Even for less lofty goals such as ensuring that all mail is properly DKIM signed, or that the SPF record properly enumerates all mail sources, I can't think of a better tool than DMARC aggregate reports for ferreting out that third party that the Marketing department hired to send mail on the company's behalf, or locating that one mail stream emanating from the "server" sitting at the side of Eddie the Engineer's desk.

I agree with all of this.  As I mentioned above, I just question the assumption that seeing p=none in a DMARC record is a good indicator that the organization is actually doing all of the things you enumerate.

It's also pretty clear from my own experience that it's impossible for complex organizations to address all of their non-compliant sources of mail flow.  Eventually, you just need to draw a line in the sand and cause the mail from random campus servers and ESPs who use domains without authorization to be rejected (or quarantined, in our case).  


On 12/2/20 1:48 PM, [e-mail] wrote:
> If DMARC is thus constrained and you have a "p=reject" on "columbia.edu" only, then nothing stops me from generating unauthenticated email with a From field indicating "foobar.columbia.edu" for any subdomain "foobar", whether or not it actually exists in the DNS.

I also advocated that sp=reject would be a sign of a high level of maturity.  I was in the minority and criticized for complicating the situation (only the flagship domain needs protection - said some).  Win some battles, lose some battles.

Regardless, I still feel like the tree walk is better than the org domain model since it would actually allow us to get to sp=reject.  With the org domain model, we'll probably be stuck at sp=none indefinitely.

Jesse