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 processing.
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 clients...
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 ?
Regards, Simon