Alessandro Vesely writes:
- The specs say that "DMARC should be amended to use [a method better than PSL] as soon as it is generally available" [1]. I believe that sentence refers to RDAP, which was released more or less at the same time (March 2015) [2].
[1] https://tools.ietf.org/html/rfc7489#appendix-A.6 [2] https://datatracker.ietf.org/wg/weirds/documents/
I see nothing in a quick look at the RDAP spec to suggest that an organizational/administrative domain (AD) field has been defined. It seems like it's just intended to be a replacement for whois, of course allowing extensions like delegating the AD to subdomains (or however that would work -- it's not obvious to me). That presumably would either be registered in the RDAP extensions registry or as a separate RFC. I've seen no discussion of this on DMARC channels either.
Surprisingly, the publisuffix package itself is not upgraded as frequently as the PSL.
I'm not surprised. Most users of the package won't be upgrading that frequently either, I suppose, but will rather be downloading it from the source.
In any case, this isn't a problem for Mailman to deal with; it's easy enough to access the public suffix list. A site could do that as a cron job once a day and almost all Mailman subscribers would be protected due to our "count bounces once per day" algorithm -- only sites with an extremely low bounce threshold would have a problem. I suppose there is a backscatter issue, but it's not clear to me that that is such a big deal.
This isn't a big deal for us at the moment, and my assessment is that it will not be one for the forseeable future. With the exception of WePublished1.3BillionAddressBooksToSpammers!.com and WeDidToo.com, I haven't heard of anybody publishing p=reject except for domains that produce only transactional mailflows. I'm sure there are many others, but I expect that most people will be subscribing to lists with mailboxes whose domains either have their own _dmarc TXT record or have an "obvious" administrative domain, or are "p=none" per default.
Do you have a reason to believe otherwise?
Steve