[SURBL-Discuss] Re: ANNOUNCE: Mail::SpamAsssassin::SpamCopURI 0.11

Simon Byrnand simon at igrin.co.nz
Thu Apr 22 16:41:43 CEST 2004

At 15:27 22/04/2004, Jeff Chan wrote:

>On Wednesday, April 21, 2004, 7:55:33 PM, Simon Byrnand wrote:
> > At 14:39 22/04/2004, Eric Kolve wrote:
> >>I can add something that will cache on a per test basis the results
> >>from the queries so the above scenario should be knocked down
> >>to just 3 queries instead of 120.  I have been a little hesitant to
> >>cache misses since I could see where a miss could become a hit later on,
> >>but since I would only be caching per test this shouldn't be an issue.
> > You mean 6 queries ? Assuming you still test both 2nd level and 3rd level
> > possibilities seperately, as now.
>It sounds like Eric is changing SpamCopURI to test on the number
>of levels depending on ccTLD membership, which is probably fine,
>therefore it would do 3 queries.

A thought just struck me...

At the moment it is not entirely foolproof to figure out how many layers 
there are on a given ccTLD domain name, and at surbl.org in your backend 
processing system you have a list which you have scraped together from 
various sources, and updated manually etc.

As Eric pointed out in a previous message, trying to do the "right thing" 
on the client end for stripping the domain name accurately would mean 
duplicating the knowledge of that list in the client - something which 
could change from time to time....and if you get it wrong you potentially 
miss some hits.

Is there any way that you could automatically publish that information in 
the surbl itself ? Perhaps a client could retrieve a list of current ccTLD 
designations and whether they are 2nd level or 3rd level etc, and 
persistently cache that for a few hours to a day, and refer to that during 

That way, as errors in the ccTLD designations come to light, or registrars 
add new ones etc the changes could be automatically propogated down to the 

It's not the sort of thing that would need checking every lookup, probably 
once a day would be fine, and could be handled in a similar way to how the 
razor client keeps a note of the last time it downloaded the list of 
discovery servers, when the time limit expires, the surbl client attempts 
to download the latest list.

Another good thing would be that using this information at the client end 
would be optional...

I wonder if it would be worth it though, or maybe more trouble than just 
doing two queries as now ?


More information about the Discuss mailing list