[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.
--eric
>
> Jeff C.
>
> _______________________________________________
> Discuss mailing list
> Discuss at lists.surbl.org
> http://lists.surbl.org/mailman/listinfo/discuss
More information about the Discuss
mailing list