On Thu 02/Nov/2017 03:31:46 +0100 Stephen J. Turnbull wrote: > 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.
Yes, RDAP is WHOIS with a machine-readable format. In both cases, a name retrieved from a public domain name registry (DNR) is an "organizational" domain. Rfc7843 defines a publicIds.type to recognize DNRs. That way, one could work out the PSL based on authoritative sources. To make the method practical, RDAP addresses the bootstrap problem (rfc7484), whereby a client could learn DNR info in one shot. To get a feeling of the state of the project, compare the contents of the following URLs --neither of which is usually up to date: https://www.iana.org/domains/root/db http://data.iana.org/rdap/dns.json The second one is mentioned here: https://github.com/arineng/nicinfo/wiki/RDAP-FAQ >> 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. PSL take the bother of writing "have your app download the list no more than once per day", so a cron job for each client would do. It is more difficult to coordinate apps, so as to download a single copy for all of them, in the unlikely case that more than one app run on the same host. That way, it becomes a potential packaging problem. > 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? No, not really. If anything, I see less and less authenticated mail, both ham and spam. (Possibly an effect of that p=reject?) I know that it is a good thing that DMARC and PSL bring the possibility to learn domain names, but I don't know why. Thank you for sharing your insights Ale -- _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
