> All, > > A little background: > > In prior versions of DMARC, one was encouraged to use a "public suffix list" > to determine where the apex of an organizational domain was (thus assuming > that the highest a search could go was at the public suffix). > > DMARCbis changed this, saying basically that you should traverse upward > through the DNS until you encounter a tag with psd=n (indicating that you're > an apex of an organization), or psd=y (indicating that you're the "public > suffix" (e.g. .com, .org, etc). This then requires that every public suffix > domain should insert a new _dmarc TXT record. Because many cctlds are > bureaucratic and complicate, adoption for this will be somewhat unpredictable.
We began switching to DMARCbis, and set "psd=n" and removed "pct=" (etc.), on over 500 domain names on the first day it was released. So far we haven't noticed any problems, aside from various online reporting services caliming that our DMARC policies are invalid, but we know this is because they don't process for DMARCbis yet.. > DMARCbis also deprecates the pct= value that's used to determine how fully a > potential quarantine/reject policy should be applied, replacing it with t=y > and t=n (testing=yes, no). > > Since DMARCbis (rfc9989/9990/9991) change the tags that are used in the > _dmarc.domain TXT record, as well as requiring some new tags at the public > suffix domain, I've started querying on a regular basis both the contents of > the public suffix, it occurs to me that operators (and maintainers) of DMARC > software should have no idea when to change their behaviors, and no resource > to which to point operators as to how widely adopted these new tags are. > > To that end, I've started doing two things: > > 1) Walking the umbrella top 1m domains looking for evidence of both the old, > and new tags. > > 2) Going over the existing public suffix list (which should never be in the > Umbrella 1m), which was the old nominal source for this info, and looking for > evidence of psd=y. > > It's my plan to make the data (current state, trends over time) publicly > available. In the interests of good science, I'm also open-sourcing the > software I'm using to poll (it'll be in the contrib folder of the OpenDMARC > repo). I'll make a short reply to this thread once I have a domain kicked > up, but getting the polling running first seemed more prudent. > > If anyone has any other useful statistics worth gathering, I'd love to hear > from you. > > -Dan > (data follows) > > === > > Current state of things: > > Public Suffix List: > > Suffixes queried : 10211 > Errors : 398 > Have DMARC : 1545 (15.1%) > Have psd= : 8 (0.5% of DMARC) > psd=y : 8 > psd=n : 0 > > Umbrella 1m: > > Domains queried : 1000005 > Errors : 12394 > Have DMARC : 110837 (11.1%) > Have pct= : 34219 (30.9% of DMARC) > Have psd= : 19 (0.0% of DMARC) > psd=y : 2 > psd=n : 17 > Have t= : 12 (0.0% of DMARC) > t=y : 0 > t=n : 12 > > Also, some interesting stats (people who have set a policy but set pct= to > 100, which is basically a no-op), or people who set p=none, in which case > pct= is typically ignored. > > p=reject/quarantine with pct=100 (no-op) : 23008 > p=none with pct= (no effect) : 8343 > > Note this one interesting entry which has psd=y, but is not a psd. > > base44.app v=DMARC1; p=reject; sp=reject; np=reject; psd=y; > rua=mailto:[email protected] Thanks for reporting on this. Do you have the report automated for public access, or is there a script somewhere that can be used to run these reports independently? -- Postmaster - [email protected] Randolf Richardson, CNA - [email protected] Inter-Corporate Computer & Network Services, Inc. Vancouver, Beautiful British Columbia, Canada https://www.inter-corporate.com/ _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
