Mailing List Archive

Henrik K skrev den 2022-10-11 08:29:
> KAM channel (https://mcgrail.com/template/kam.cf_channel) users might
> want
> to check their rules..
>
> KAM_deadweight2_sub.cf contains this:
>
> meta __RCVD_IN_SORBS 0
> meta __RCVD_IN_ZEN 0
> meta __RCVD_IN_MSPIKE_B 0
> meta __RCVD_IN_MSPIKE_L 0
> meta __RCVD_IN_DNSWL 0
>
> Seems it's been disabling many active and useful DNSBL/WL lookups for a
> long
> time?

X-Spam-Status: No, score=-0.21 tagged_above=-999 required=6.31
tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01,
URIBL_BLOCKED=0.001] autolearn=disabled

apache.org do not disable uribl.com or get datafeed

no one cares

On 10/11/2022 4:03 AM, Benny Pedersen wrote:
> Henrik K skrev den 2022-10-11 08:29:
>> KAM channel (https://mcgrail.com/template/kam.cf_channel) users might
>> want
>> to check their rules..
>>
>> KAM_deadweight2_sub.cf contains this:
>>
>> meta __RCVD_IN_SORBS 0
>> meta __RCVD_IN_ZEN 0
>> meta __RCVD_IN_MSPIKE_B 0
>> meta __RCVD_IN_MSPIKE_L 0
>> meta __RCVD_IN_DNSWL 0
>>
>> Seems it's been disabling many active and useful DNSBL/WL lookups for
>> a long
>> time?
>
> X-Spam-Status: No, score=-0.21 tagged_above=-999 required=6.31
>     tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
>     DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01,
>     URIBL_BLOCKED=0.001] autolearn=disabled
>
> apache.org do not disable uribl.com or get datafeed
>
> no one cares
You seem not to care to report it to the correct place.  Apache.org is
just another user of the tool.  The Project doesn't manage the
installation.  Please report this to Apache Infrastructure.

--
Kevin A. McGrail
KMcGrail@Apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

On 10/11/2022 2:29 AM, Henrik K wrote:
> Seems it's been disabling many active and useful DNSBL/WL lookups for a long
> time?

Correct.  We found they had overlap or didn't add to the accuracy of
categorization so disabling rules is a key part of reducing weight of
rule scanning and improving efficiency.  This is inherent in the KAM
ruleset and has been there for several years.

Regards,
KAM


--
Kevin A. McGrail
KMcGrail@Apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

On Tue, Oct 11, 2022 at 12:33:19PM -0400, Kevin A. McGrail wrote:
>
> On 10/11/2022 2:29 AM, Henrik K wrote:
> > Seems it's been disabling many active and useful DNSBL/WL lookups for a long
> > time?
>
> Correct.? We found they had overlap or didn't add to the accuracy of
> categorization so disabling rules is a key part of reducing weight of rule
> scanning and improving efficiency.? This is inherent in the KAM ruleset and
> has been there for several years.

I know, it makes sense for a few things, but I'm surprised you are disabling
many popular DNSBLs. How much efficiency do you expect from dropping a few
DNS queries? How often do you re-measure the accuracy from all the dropped
rules?

Why not just drop RCVD_IN_ZEN etc from official ruleset then..

Kevin A. McGrail skrev den 2022-10-11 18:30:

>> no one cares
> You seem not to care to report it to the correct place.  Apache.org is
> just another user of the tool.  The Project doesn't manage the
> installation.  Please report this to Apache Infrastructure.

i dont want to spam random email adresses at apache.org thats why i take
it up here in case others could help solve it

in case none can help i would let it be

On Tue, Oct 11, 2022 at 09:29:18AM +0300, Henrik K wrote:
>
> KAM channel (https://mcgrail.com/template/kam.cf_channel) users might want
> to check their rules..
>
> KAM_deadweight2_sub.cf contains this:
>
> meta __RCVD_IN_SORBS 0
> meta __RCVD_IN_ZEN 0
> meta __RCVD_IN_MSPIKE_B 0
> meta __RCVD_IN_MSPIKE_L 0
> meta __RCVD_IN_DNSWL 0
>
> Seems it's been disabling many active and useful DNSBL/WL lookups for a long
> time?

Ah yeah, now I remember this bug:

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7991

Apparently this isn't a "problem" in 3.4, as the channel can't even override
anything from official rules.. so only affects recent 4.0.0/trunk users.

On 12/10/2022 03:35, Henrik K wrote:

> On Tue, Oct 11, 2022 at 09:29:18AM +0300, Henrik K wrote:
>
>> KAM channel (https://mcgrail.com/template/kam.cf_channel) users might
>> want
>> to check their rules..
>>
>> KAM_deadweight2_sub.cf contains this:
>>
>> meta __RCVD_IN_SORBS 0
>> meta __RCVD_IN_ZEN 0
>> meta __RCVD_IN_MSPIKE_B 0
>> meta __RCVD_IN_MSPIKE_L 0
>> meta __RCVD_IN_DNSWL 0
>>
>> Seems it's been disabling many active and useful DNSBL/WL lookups for
>> a long
>> time?
>
> Ah yeah, now I remember this bug:
>
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7991
>
> Apparently this isn't a "problem" in 3.4, as the channel can't even
> override
> anything from official rules.. so only affects recent 4.0.0/trunk
> users.

or save SA doing extra work, and use the RBL's at MTA level - where they
should be used and have been used for 25 years in the ISP world

--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged
information, therefore at all times remains confidential and subject to
copyright protected under international law. You may not disseminate
this message without the authors express written authority to do so.
If you are not the intended recipient, please notify the sender then
delete all copies of this message including attachments immediately.
Confidentiality, copyright, and legal privilege are not waived or lost
by reason of the mistaken delivery of this message.

>>On Tue, Oct 11, 2022 at 09:29:18AM +0300, Henrik K wrote:
>>>KAM channel (https://mcgrail.com/template/kam.cf_channel) users
>>>might want
>>>to check their rules..
>>>
>>>KAM_deadweight2_sub.cf contains this:
>>>
>>>meta __RCVD_IN_SORBS 0
>>>meta __RCVD_IN_ZEN 0
>>>meta __RCVD_IN_MSPIKE_B 0
>>>meta __RCVD_IN_MSPIKE_L 0
>>>meta __RCVD_IN_DNSWL 0
>>>
>>>Seems it's been disabling many active and useful DNSBL/WL lookups
>>>for a long
>>>time?

>On 12/10/2022 03:35, Henrik K wrote:
>>Ah yeah, now I remember this bug:
>>
>>https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7991
>>
>>Apparently this isn't a "problem" in 3.4, as the channel can't even
>>override
>>anything from official rules.. so only affects recent 4.0.0/trunk
>>users.

that's not nice, I've had pretty much hits from those lists before I started
using 4.x

On 12.10.22 10:41, Noel Butler wrote:
>or save SA doing extra work, and use the RBL's at MTA level - where
>they should be used and have been used for 25 years in the ISP world

you compare uncomparable.

SA does header scanning and can check on non-direct headers, e.g. at the
internal network level.
Also, it can do deep header scanning for open proxies etc.

MTA can't do that.


--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Saving Private Ryan...
Private Ryan exists. Overwrite? (Y/N)

On Wed, Oct 12, 2022 at 10:45:06AM +0200, Matus UHLAR - fantomas wrote:
> On 12.10.22 10:41, Noel Butler wrote:
> > or save SA doing extra work, and use the RBL's at MTA level - where they
> > should be used and have been used for 25 years in the ISP world
>
> you compare uncomparable.
>
> SA does header scanning and can check on non-direct headers, e.g. at the
> internal network level.
> Also, it can do deep header scanning for open proxies etc.

Also, many uses of RBL (e.g. amavis) do not take them as "absolute
truth" to outright refuse to accept mail, but only as additional
clues to programatically increase or decrease spam score by some
amount (different score depending on the RBL, what other rules matched
in addition to RBL etc) and maybe to autolearn to stop same spam from
other IPs which are not yet blacklisted (and report them to RBLs too).

Which is much higher functionality than "this RBL said this IP is
bad, so reject everything from there, regardless if it is good or
bad".

I have lots of free CPU cycles to burn, but I do NOT have human hours
to deal with questions like "where is my mail?" when RBL yields false
positive (Your mail is either in your INBOX, or in your SPAMBOX).

--
Opinions above are GNU-copylefted.

>> On 12.10.22 10:41, Noel Butler wrote:
>> > or save SA doing extra work, and use the RBL's at MTA level - where they
>> > should be used and have been used for 25 years in the ISP world

>On Wed, Oct 12, 2022 at 10:45:06AM +0200, Matus UHLAR - fantomas wrote:
>> you compare uncomparable.
>>
>> SA does header scanning and can check on non-direct headers, e.g. at the
>> internal network level.
>> Also, it can do deep header scanning for open proxies etc.

On 12.10.22 13:08, Matija Nalis wrote:
>Also, many uses of RBL (e.g. amavis) do not take them as "absolute
>truth" to outright refuse to accept mail, but only as additional
>clues to programatically increase or decrease spam score by some
>amount (different score depending on the RBL, what other rules matched
>in addition to RBL etc) and maybe to autolearn to stop same spam from
>other IPs which are not yet blacklisted (and report them to RBLs too).

to be frank, postfix does support this when you use postscreen.

- different weights, even negative, for different lists and mail can be
refused if the resulting score is over a configured value.

But, only at IP directly connecting, which it what makes the main difference
between MTA and SA.

That's why we may use the same DNSBL both at MTA and spamassassin level.

--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
(R)etry, (A)bort, (C)ancer