Re: [dmarc-ietf] Domains and tree walk
In article you write: >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). I figure they're collecting reports to see where their mail is going. That's what I do. The reports are interesting even if you have no intention of ever publishing a policy other than p=none. >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. Hahaha. It means they published SPF and DMARC p=reject records and checked it off. I've been dealing with fairly important mail to my users falling on the floor ever since. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Domains and tree walk
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, superu...@gmail.com 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Domains and tree walk
On Tue, Dec 1, 2020 at 9:50 PM John Levine wrote: > In organizations that are not universities, the entity that > is responsible for the registered domain generally sets policies for > the whole organization, and a good deal of the DMARC design is there > to let them figure out who is sending mail with their name on it from > any of their subdomains and identify and adjust senders whose mail > doesn't match the policy. > > 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. -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.h...@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Domains and tree walk
In article you write: >I know of no other >standard that requires this type of relationship. Here at the IETF, the CAA DNS record that specifies which certificate authority can sign for what domains does a tree walk. If there is a CAA record at example.org it controls signing of foo.example.org and foo.bar.example.org and so forth unless they have their own CAA record. Every applicaton of the public suffix list implicitly does something akin to a tree walk. Its original application was to control cross-site web cookies, to say whether www.foo.co.uk can drop a cookie at foo.co.uk (yes) or co.uk (no). > This is something new. It will require administrators to continually check > what their >sub- and supra-domains are doing in order to escape interference by >DMARC records they did not create. I think this is unreasonable. Only >domains interested in applying DMARC should be involved with DMARC. ... Well, it's not that new since we published the DMARC spec five years ago, but this is what I have referred to as the Holy Roman Empire problem. In organizations that are not universities, the entity that is responsible for the registered domain generally sets policies for the whole organization, and a good deal of the DMARC design is there to let them figure out who is sending mail with their name on it from any of their subdomains and identify and adjust senders whose mail doesn't match the policy. We realize that universities are different, organized along the lines of the Holy Roman Empire, and the Elector of Central Asian Cross-Disciplinary Studies feels very strongly about any incursion on their autonomy including their mail setup. 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. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
