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

Eric Kolve ekolve at comcast.net
Wed Apr 21 21:44:11 CEST 2004

On Wed, Apr 21, 2004 at 08:27:58PM -0700, 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.
> > And as far as caching goes, it shouldn't be a problem, because you just 
> > want to avoid doing a whole string of identical dns lookups - only cache 
> > identical lookups, and the caching should only last for one run of SA 
> > processing one message...(We assume that no new blacklist records appear in 
> > the middle of processing a specific message, or that if they do we don't 
> > care ;-)
> Yes, it's not clear if "per test" means per message, but it would
> seem so.  That too should be fine.  I don't think we should worry
> too much about the boundary condition of the SURBL changing in
> the middle of message processing, which seems like it would be
> uncommon.  Per-message caching is already a big help.
'per test' literally means per test.  So if you run three eval:check_spamcop_uri_rbl 
tests, then you will have at most three queries for the same domain.

I would cache per message, but there isn't a good place to cache this data.
I have access to PerMsgStatus, but its not a good idea to start
shoving stuff into that hash as other code depends on its structure.


> Jeff C.
> _______________________________________________
> Discuss mailing list
> Discuss at lists.surbl.org
> http://lists.surbl.org/mailman/listinfo/discuss

More information about the Discuss mailing list