On Fri, Dec 17, 2021 at 9:06 PM Scott Kitterman <[email protected]> wrote:
> On Friday, December 17, 2021 8:43:17 PM EST Tim Wicinski wrote: > > On Fri, Dec 17, 2021 at 6:56 PM Douglas Foster < > > > > [email protected]> wrote: > > > That is not my position, and I don't know how you drew that > > > conclusion from those words. > > > > Then my mistake. > > > > > I do take the position that DMARC PASS means "This name correctly > > > represents the stated domain", and NP=TRUE means "This name cannot > > > represent the stated domain because the domain owner never uses that > > > name". I am willing to say that if NP=TRUE produces an accurate > result, > > > I > > > will block the message and I can see no reason why anyone else would do > > > otherwise. > > > > > > DMARC FAIL is an ambiguous result, which was your point. DMARC PASS is > > > not ambiguous. NP=TRUE should be ambiguous if at all possible, > otherwise > > > it adds no value. > > > > > > But back to the actual topic: > > > - Do you believe the NP test can be useful? If so, for what purpose? > > > - What is the optimal test to evaluate NP? How did you reach that > > > conclusion? > > > > I see the NP tag being useful for mid to large organizations that have a > > regular amount of organizational change (mergers, acquisitions, etc). > > A large mostly static organization will not deploy the np tag, because "p > > == sp", where the domain tag = the subdomain tag. > > Larger organizations deploying DMARC usually run into the problem of not > > knowing all the mail flows from all the change, and they end up > > with "p != sp" for some period of time. In these cases, np is really > > useful in preventing attack vectors using subdomains (log4j.example.com) > > from > > being used. > > > > I am sure there are folks who track DMARC record changes over time, but > > back in mid 2020 I pulled a bunch of DMARC records of some alexa top 10K, > > and noticed the number of domains where "p != sp". Doing a quick pull of > > those domains and checking now I see a number of them now show "p == sp", > > which means they feel they have a better understanding of their mail > > flows. > > > > I worked for a large organization which had to set "p != sp" for a period > > of time as they understood things better. They are now a "p == sp" > > organization now, which is good. But having the added bonus of blocking > > invalid subdomains during that migration period I am sure would have > > made folks feel better. > > > > (the other use case for the np tag is around TLDs and also the SLDs like > > co.uk, and Scott is all over that). > > Actually .gov.uk. I'd expect that .co.uk has similar challenges to what > we'd > expect with .com. I knew I'd get something wrong. > > What you describe is something that was in my mind when we defined np=, > despite > the focus on PSD at the time. I think that np= has potentially broad > utility > as a gap filler during the deployment process for large organizations. > As an operations person who has worked with a lot of technical debt, when I saw your idea for np=, *all* I could think of was large organizational issues. > > I think p=reject will be a problem of a lot of organizations for a long > time, > so I think anything we can do to make it easier to have some set of mail > covered by a reject policy is a good thing. > Here is a data point on this. Sometime back in Fall 2020, I was collecting some DMARC DNS records. I was using the alexa-top* lists, which are horrible datasets, because web domains don't always send email and email domains don't have web properties etc. Using the top-1000 domains: 1000 domains 562 domains with DMARC record 318 domains with DMARC record where p != sp Rechecking that same list of domains last night: 371 domains with DMARC record where p != sp 53 domains from this list updated their policies. I did not dive into the specifics, but they mostly appear to have the 'p=' move forward (none->quarantine->reject) while 'sp=' appeared to stay the same. (I see a few where 'p=' moves to reject and 'sp=' moves to none. I can figure this out if interested) To Scotts' point on organizations moving to p=reject will take time, I would agree. But allowing a large organization allow sp=none but np=reject is a huge help. (This also means organizations need to cull the DNS data, but some of us are a bit too obsessive about this) tim
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
