Created attachment 5515 [details]
Disable Barracuda from force_active

IMHO Barracuda BL should be disabled from general rules, once registered the ip address on their web site anybody could reenable the rule.

I don't think they require registration or block all unregistered DNS queries.  I have been using them for years without knowing that I needed to register.

If someone from Barracudacentral.org contacts us and asks for this to be disabled in the default SA rulesets, then we should honor their request.  Until then, my vote is to leave it enabled to help with spam fighting.

They have asked us to disable this, with this language:
"IP addresses not listed may be blocked, rate controlled or otherwise denied access without warning."

They are very clear that they reserve the right to disable access arbitrarily and with no notice. It's great that they haven't apparently done this yet, or we'd have bigger problems, but we shouldn't rely on this in the default configuration when they've clearly asked us not to do it.

Sometimes ago my SA failed to query barracudanetworks because of the issue, once registered my ip it worked, at least an entry on the FAQ could be useful.

I will apply the patch and commit it but what is the proper way for users to enable it again in their local.cf?  We should document this next to a commented out line that would enable it again in the local.cf.  I can do this documentation once I know the best way to handle this so that we disable it for existing SA instances via sa-update but going forward it is easy to enable in the local.cf.

Despite my efforts to reach Barracuda, I have been completely unable to get a response.  I have no guidance beyond removing them from the stock rules.

I need some guidance from those more experienced/knowledgeable about the best way to handle this.  Is this patch the best way to do it so that it can be enabled in the local.cf easily by uncommenting something?

I would have disabled it by setting a score to zero but that is probably not the best way to do this in the stock SA rulesets provide by sa-update.

In order to disable this in the default SA ruleset, do we need an entry in the tgz file's local.cf to score these rules as zero.  Then the user's own local.cf would have a non-zero score to enable it again?

Thinking about it aloud, do we want/need a way to disable a rule without setting its score to 0 ?
This way we could push scores based on corpora whenever somebody will enable that rule.

Atm I see no other way than adding an entry in the tgz file's local.cf to score these rules as zero.

I would just delete the whole rule.  There are instructions other places to install and configure the RBL.  

They simply do not meet the requirements to be in our rules and they haven't responded to fix it.

let it RIP :=)

# cat local.cf

dns_query_restriction deny barracudacentral.org

# comment above line if you want support....

(In reply to Benny Pedersen from comment #11)
> let it RIP :=)
> 
> # cat local.cf
> 
> dns_query_restriction deny barracudacentral.org
> 
> # comment above line if you want support....

Likely dns_query_restriction deny bb.barracudacentral.org is all that's needed. It was special for SA to not require an IP registration.

i do as writed, it works for me

no more queery fails in my bind9 logs

is the subdomain still aktive working with that deny ?

if thats so, is this a bug in sa ?

(In reply to Benny Pedersen from comment #13)
> i do as writed, it works for me
> 
> no more queery fails in my bind9 logs
> 
> is the subdomain still aktive working with that deny ?
> 
> if thats so, is this a bug in sa ?

The only domain that is used in stock rules is the bb.  Your suggestion is too broad is my point.  Can you check it with the more surgical deny?

is man page at fail ?

# 
#     dns_query_restriction (allow|deny) domain1 domain2 ...
#         Option allows disabling of rules which would result in a DNS query to
#         one of the listed domains. The first argument must be a literal
#         "allow" or "deny", remaining arguments are domains names.
# 
#         Most DNS queries (with some exceptions) are subject to
#         dns_query_restriction. A domain to be queried is successively
#         stripped-off of its leading labels (thus yielding a series of its
#         parent domains), and on each iteration a check is made against an
#         associative array generated by dns_query_restriction options. Search
#         stops at the first match (i.e. the tightest match), and the matching
#         entry with its "allow" or "deny" value then controls whether a DNS
#         query is allowed to be launched.
# 
#         If no match is found an implicit default is to allow a query. The
#         purpose of an explicit "allow" entry is to be able to override a
#         previously configured "deny" on the same domain or to override an
#         entry (possibly yet to be configured in subsequent config directives)
#         on one of its parent domains. Thus an 'allow zen.spamhaus.org' with a
#         'deny spamhaus.org' would permit DNS queries on a specific DNS BL zone
#         but deny queries to other zones under the same parent domain.
# 
#         Domains are matched case-insensitively, no wildcards are recognized,
#         there should be no leading or trailing dot.
# 
#         Specifying a block on querying a domain name has a similar effect as
#         setting a score of corresponding DNSBL and URIBL rules to zero, and
#         can be a handy alternative to hunting for such rules when a site
#         policy does not allow certain DNS block lists to be queried.
# 
#         Example: dns_query_restriction deny dnswl.org surbl.org
#         dns_query_restriction allow zen.spamhaus.org dns_query_restriction
#         deny spamhaus.org mailspike.net spamcop.net

No idea if the man page is correct.  I'm working another issue right now for SA.

Can you test if dns_query_restriction deny bb.barracudacentral.org works for you?

imo, dns_query_restriction is too "advanced" for the requirement.
Comment out the rule for  1 year - remove rule after that.
Same way we've done with other BLs

Agreed AXB.  I'm just discussing the side thread.

The main difference is that, by using "dns_query_restriction" we can always push scores via updates, if we disable the rule by adding score=0 this won't be possible.

(In reply to Giovanni Bechis from comment #19)
> The main difference is that, by using "dns_query_restriction" we can always
> push scores via updates, if we disable the rule by adding score=0 this won't
> be possible.

We comment the WHOLE rule, NOT set score=0
(Been there, done that for over a decade & got a t-shirt)

I am commenting out everything I can find with BRBL.  "make test" is passing but KAM.cf needs to be cleaned up first before I can commit this to get lint to pass with KAM.cf installed.  I don't want to break every SA instance out there running KAM.cf.

Anything in KAM.cf relying on IN_BRBL and RCVD_IN_BRBL_RELAY needs to be removed before I can commit the commented out BRBL rules.

(In reply to Dave Jones from comment #21)
> KAM.cf needs to be cleaned up first before I can commit this to get lint
> to pass with KAM.cf installed.  I don't want to break every SA instance out
> there running KAM.cf.

I couldn't find any announcement on the Users list that BRBL is being removed; I think it would be prudent to announce that and note that everyone should check their local rules for such dependencies as well, and give some time for that to settle (a week? more?) before committing the change. This isn't time-critical.

Might even cause Barracuda to respond to my inquiries

Funny, I had a draft email ready to send to the users list as soon as the KAM.cf is ready.  Once I commit the commented out BRBL rules, it will take 36 to 48 hours for the ruleset to go out to the world via sa-update.

I will send the email to the users list right after the commit.

(In reply to Dave Jones from comment #25)
> I will send the email to the users list right after the commit.

"We've checked in a potentially breaking change, you have 36-48 hours to see whether it will break your environment before it actually does break your environment."

Is that polite?

Given the gush of duplicate bugs opened for the "Can't locate object method "check_for_forged_gmail_received_headers"" oopsie, I'd feel a lot better if we announced "We are *about* to make a potentially breaking change, please check your local rules for these dependencies and correct them:" and wait a bit before the commit.

As I said, this isn't time-critical. Let's be as polite and proactive as we can.

Sounds like a good plan.  No rush.  We could even wait until next week to let the dust settle on the check_for_forged_gmail_received_headers issue that should be worked out tomorrow.

I was planning on including in my email to the list details on how to register with the BRBL and a sample config to put in a local.cf file to keep the BRBL active as an option to removing it from any local meta rules if people wanted to keep using it.

I will definitely wait until Kevin has some spare time to fix the KAM.cf before committing the commented out BRBL lines.

(In reply to Dave Jones from comment #27)
> Sounds like a good plan.  No rush.  We could even wait until next week to
> let the dust settle on the check_for_forged_gmail_received_headers issue
> that should be worked out tomorrow.
> 
> I was planning on including in my email to the list details on how to
> register with the BRBL and a sample config to put in a local.cf file to keep
> the BRBL active as an option to removing it from any local meta rules if
> people wanted to keep using it.
> 
> I will definitely wait until Kevin has some spare time to fix the KAM.cf
> before committing the commented out BRBL lines.

Dave, the KAM.cf dependencies shouldn't matter.  They apply to people using other BR lists.

When I applied the same changes to my SA 3.4.1 masscheck instance that gathers up ham and spam, it gave a lint error from IN_BRBL and RCVD_IN_BRBL_RELAY dependencies.

Warning or error?

# spamassassin -D --lint
...
Jan 31 10:57:03.918 [19208] dbg: rules: meta test KAM_BAD_DNSWL has undefined dependency 'IN_BRBL'
Jan 31 10:57:03.918 [19208] dbg: rules: meta test KAM_BAD_DNSWL has undefined dependency 'RCVD_IN_BRBL_RELAY'
Jan 31 10:57:03.918 [19208] dbg: rules: meta test KAM_BAD_DNSWL has undefined dependency 'KAM_MESSAGE_EMAILBL_PCCC'
Jan 31 10:57:03.926 [19208] dbg: rules: meta test KAM_RPTR_PASSED has undefined dependency 'IN_BRBL'
Jan 31 10:57:03.926 [19208] dbg: rules: meta test KAM_RPTR_PASSED has undefined dependency 'RCVD_IN_BRBL_RELAY'
...
# echo $?
2

Wait a minute.  I am getting a return code of 2 even with the changes backed out.  I must have another problem that I need to track down.

I removed a patch I was testing to get my lint to produce a zero return code again.  Do these need to be addressed in KAM.cf before we comment the BRBL rules out or just let it ride?

# spamassassin -D --lint 2>&1 | grep BRBL
Feb  2 15:16:01.139 [9353] dbg: rules: meta test KAM_BAD_DNSWL has undefined dependency 'IN_BRBL'
Feb  2 15:16:01.139 [9353] dbg: rules: meta test KAM_BAD_DNSWL has undefined dependency 'RCVD_IN_BRBL_RELAY'
Feb  2 15:16:01.146 [9353] dbg: rules: meta test KAM_RPTR_PASSED has undefined dependency 'IN_BRBL'
Feb  2 15:16:01.146 [9353] dbg: rules: meta test KAM_RPTR_PASSED has undefined dependency 'RCVD_IN_BRBL_RELAY'

(In reply to Dave Jones from comment #33)
> I removed a patch I was testing to get my lint to produce a zero return code
> again.  Do these need to be addressed in KAM.cf before we comment the BRBL
> rules out or just let it ride?
> 
> # spamassassin -D --lint 2>&1 | grep BRBL
> Feb  2 15:16:01.139 [9353] dbg: rules: meta test KAM_BAD_DNSWL has undefined
> dependency 'IN_BRBL'
> Feb  2 15:16:01.139 [9353] dbg: rules: meta test KAM_BAD_DNSWL has undefined
> dependency 'RCVD_IN_BRBL_RELAY'
> Feb  2 15:16:01.146 [9353] dbg: rules: meta test KAM_RPTR_PASSED has
> undefined dependency 'IN_BRBL'
> Feb  2 15:16:01.146 [9353] dbg: rules: meta test KAM_RPTR_PASSED has
> undefined dependency 'RCVD_IN_BRBL_RELAY'

Those warnings exist no matter what as KAM.cf is designed to work on our systems but might generate warnings for others.

In the latest ruleQA run, this is the highest percentage rule with a score for spam at 43 percent.  It's scores are pretty low but some default SA instances could really miss having this rule.

http://ruleqa.spamassassin.org/20180203-r1823022-n/RCVD_IN_BRBL_LASTEXT/detail

Sorry Dave but efficacy is not the concern.  The RBL no longer meets the inclusion requirements because it does not work out of the box.

https://wiki.apache.org/spamassassin/DnsBlocklists

I wasn't suggesting that we keep it only that we may get some users on the mailing list noticing that is has been removed because some spam scores a little lower.

Committed to trunk and 3.4 branch.  Will be sending out the email to the user list shortly.

... trunk]$ svn commit -m "Bug 7417"
Sending        rules/50_scores.cf
Sending        rulesrc/10_force_active.cf
Transmitting file data ..done
Committing transaction...
Committed revision 1823168.


... 3.4]$ svn commit -m "Bug 7417"
Sending        rules/50_scores.cf
Sending        rulesrc/10_force_active.cf
Transmitting file data ..done
Committing transaction...
Committed revision 1823171.

Email sent to the users list.

(In reply to Dave Jones from comment #39)
> Email sent to the users list.

After the commit. And it doesn't say anything about the possibility of breaking local rules and thus causing a lint failure to block the upgrade, though admins should be aware of what their local rules are doing.

Prepare for a bunch of "lint failure blocks upgrade" bugs to be opened.

(In reply to John Hardin from comment #40)
> (In reply to Dave Jones from comment #39)
> > Email sent to the users list.
> 
> After the commit. And it doesn't say anything about the possibility of
> breaking local rules and thus causing a lint failure to block the upgrade,
> though admins should be aware of what their local rules are doing.
> 
> Prepare for a bunch of "lint failure blocks upgrade" bugs to be opened.

Do they cause errors or just warnings?  People use my ruleset all the time which has some missing referenced rules for them.

It's should be warnings only from my testing on my local SA instances before I committed and before I send the email to the user list.

What's a few more warning when we have so many already?

(In reply to Dave Jones from comment #42)
> It's should be warnings only from my testing on my local SA instances before
> I committed and before I send the email to the user list.
> 
> What's a few more warning when we have so many already?

OK. If that's the case then I withdraw my objection.

comment out the rule in 20_bug_5984.cf

also look for any references to RCVD_IN_BRBL_LASTEXT in metas.

*** Bug 7471 has been marked as a duplicate of this bug. ***

(In reply to AXB from comment #44)
> comment out the rule in 20_bug_5984.cf
> 
> also look for any references to RCVD_IN_BRBL_LASTEXT in metas.

Believe all the references are now good.  Only nopublish and commented left.  The JM sandbox had the offending rule.

I removed the force active: publish RCVD_IN_BRBL_LASTEXT

Not sure if a comment is a good idea there.

Deconflicted with others

Committed revision 1823797.