On Tue, Oct 20, 2009 at 06:07, Warren Togami <[email protected]> wrote:
> On 10/19/2009 01:40 PM, Karsten Bräckelmann wrote:
>>
>> Warren, since you don't even intend to include these BLs in stock SA, as
>> you mentioned in a follow-up...
>>
>> Please do not use the mass-check contributors for your or the BL's
>> personal statistics, without even asking the contributors. They are a
>> precious resource.
>>
>> The mass-checks are there to evaluate SA rule's performance. They are
>> not free for personal interest. If you want some stats for yourself,
>> please run it on your systems. Don't expect everyone else to do it for
>> you.
>
> I must qualify that my intent was never to test anything purely from
> personal interest or to use everyone else's systems to test rules that may
> never benefit spamassassin in the future.  I am insulted if this is the
> insinuation.
>
> Various BL's I am testing are assessing future suitability for SA.  But as
> noted earlier I am not rushing this, and I certainly do not have illusions
> that we should add as many blacklists as possible.  Currently all of those
> BL's are incapable of the load capacity to become production rules.  They
> are also exhibiting FP problems, which masschecks are helping to identify
> and fix their methodologies.  It took several weeks of masschecks to
> identify PSBL's trap logic bugs.  Finally even if they manage to become
> safer to FP's and with sufficient capacity to handle spamassasin, we may
> still decide it is a bad idea to go production because they are redundant by
> overlap analysis.
>
> It seems the main cause for concern was notification before net rule
> changes.  I will do so in the future.

I think some people's concern was that net rules could find their way into
the sa-update channel, and be used in production.  (This is currently
possible if someone installs trunk and uses sa-update.)  If you use
"tflags nopublish", this risk is avoided, so that may help too.

FWIW, I agree that it's valuable to test these and gather ruleqa stats,
as long as we ensure they are T_ test rules and don't leak to production.

-- 
--j.

Reply via email to