You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2012/04/01 00:47:34 UTC

[Bug 4385] [review] add .xxx to list of valid TLDs

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=4385

--- Comment #19 from D. Stussy <so...@kd6lvw.ampr.org> 2012-03-31 22:47:34 UTC ---
Registrar boundries - am I drunk?  Hardly.  However, you're not thinking.

The whole reason for pulling the zone is to learn new gTLDs.  ALL GTLDs have as
their registerable unit the 2LD element, so there's NO NEED to consider
registrar boundaries.  Only ccTLDs have those.  Although this will also detect
changes in ccTLDs, that's not its purpose, nor do those change with any
frequency.  Regardless, ccCTLD registrar boundaries cannot be determined
automatically.

As far as AXFR or other transfer goes, one DOES need to fetch the information
somehow whenever it changes.  Blindly transferring it once per day is a waste
of bandwidth - as the root zone may not have changed at all.  Although current
root-zone policy does update the SOA serial every day, such a policy cannot be
relied upon.  All that matters is that when the zone data is updated, the SOA
serial MUST be updated too, and that's when we need to refresh the data.

So why AXFR vs. FTP or some other transfer?  Because a properly set up name
server will perform the transfer for us automatically and ONLY when the SOA
serial changes, thus preventing blind updates to the local copy of the data
(e.g. based on a cron transfer), especially those that happen when the data has
NOT changed.  All we then need check is the file update time of the local file
the zone vs. the file update time of the file containing the processed data (as
an alternative to SOA serial comparison).

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.