[Mailman-Developers] Use of the public suffix list

[Alessandro Vesely]

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
--