Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[Bill Cole]

On 11 Feb 2018, at 9:54 (-0500), Benny Pedersen wrote:

first query would be valid for 300 secs, but that is imho still not 
free, problem is that keeping low ttls does not change how dns works, 
any auth dns servers will upate on soa serial anyway, the crime comes 
in when sa using remote dns servers that ignore soa serial updates


in that case ttls would keep spammers listed for 300 secs only


That's not how DNS TTLs work.

When a record's TTL elapses in the local name cache, it is dropped. The 
next query for that name and record type causes the resolver to make 
another query to the authoritative nameservers, which will return the 
same record whose TTL expired unless it has been removed from the zone. 
No standards-conforming DNS resolver returns NXDOMAIN based on the lack 
of a non-expired record in its cache and an unchanged SOA serial above 
the name. That would make no sense at all and require many more SOA 
queries than actually happen.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[Benny Pedersen]

Dave Warren skrev den 2018-02-06 20:39:


How low are the TTLs? I'm seeing 300 seconds on 127.0.0.2 which is
more than sufficient time for a single message to finish processing,
such that multiple queries from one message would absolutely be cached
(or more likely, the first would still be pending and the second would
get the same answer as the first).


first query would be valid for 300 secs, but that is imho still not 
free, problem is that keeping low ttls does not change how dns works, 
any auth dns servers will upate on soa serial anyway, the crime comes in 
when sa using remote dns servers that ignore soa serial updates


in that case ttls would keep spammers listed for 300 secs only

and thats why i say 300 secs helps spammers


;; ANSWER SECTION:
2.0.0.127.bb.barracudacentral.org. 300 IN A 127.0.0.2

Maybe the TTLs are different for other records?


300 is imho to low to anything thats called free

i would like to accept free if it was 3600


I am also noticing very intermittent response times, sometimes taking
over a second to get a response, other times taking under 50ms.


rndc querylog is my friend

i just like to start a debate on why 300 is accepted as free, it does 
matter for non datafeeds users, but for datafeeds it does not matter at 
all

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[RW]

On Tue, 6 Feb 2018 11:38:42 -0500
Alex wrote:


> On Tue, Feb 6, 2018 at 8:44 AM, David Jones  wrote:
ustomer's compromised accounts.
> >
> > Leave out the RCVD_IN_BRBL rule above and change the
> > RCVD_IN_BRBL_LASTEXT score to 1.4 to keep things the same.  
> 

> If you think the RCVD_IN_BRBL rule is a good one, I'd like to use it,
> and while I've implemented much of your approach, I can't implement
> all of it. 

I've been doing deep XBL checks for years (they come free with the zen
look-ups). Initially I found that they did have a low FP rate, but
that's changed as more of my mail comes through mobile (cellular)
networks that use NAT to support millions of users on thousands of IPv4
addresses. I'm seeing about 10% of ham submitted from these networks
hitting my deep XBL rule. 


> Can I also ask again about reasonable RCVD_IN_LASHBACK and
> RCVD_IN_LASHBACK_LASTEXT scores?

If you're going to create deep versions of more than one list it doesn't
make sense to score them individually. The dominant cause of FPs on such
rules is dynamic IP address reuse, being in more than one list
doesn't say anything about that. Allowing a large score to build-up
from multiple deep rules is reckless. 

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[Alex]

Hi,

>>> whitelist_auth *@bounce.mail.salesforce.com
>>> whitelist_auth *@sendgrid.net
>>> whitelist_auth *@*.mcdlv.net
>>
>>
>> I've seen enough spam sent through all three - both by way of whole
>> apparently spammer-owned accounts and cracked-but-otherwise-legitimate
>> accounts - that I would never blanket-whitelist whole bulk email providers.
>>
>> Legitimate mail sent through them generally gets through anyway IME.
>
> An alternative is to use "def_whitelist_auth" instead of "whitelist_auth"
> That gives a -7.5 point bump to usually good sources which may occasionally
> get abused.
>
> That way if one of their accounts gets p0wned your anti-phish rules have a
> chance of pulling the junk into the spam-tagged range.

Phishing is a significant concern for us. Whether or not the phish
came through the customer of one of these senders or through the
senders themselves, whitelisting these senders only facilitates more
phishes. There was a period when it was about one being reported by a
particularly large customer per day. Telling my customers that we've
contacted the provider and reported the spam just isn't good enough.

We also received a phish through freshdesk.com which is on the
def_whitelist. It's also on the DKIMWL_WL, subtracting another -3.5
points. It was also listed in RCVD_IN_HOSTKARMA_W, but also in
LASHBACK_LASTEXT and invaluement, but not enough to compensate for the
negative points.

I suspect it was a compromised freshdesk trial account that was
managed by amazonaws and sendgrid before passing through
smtp.freshdesk.com, both of which weren't whitelisted at the time.

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[David B Funk]

On Tue, 6 Feb 2018, Kris Deugau wrote:


Alex wrote:

These phishes we've received were all from otherwise trusted sources
like salesforce, amazonses and sendgrid. These are examples that I
believe were previously whitelisted because of having received a phish
through these systems but have no been disabled.

whitelist_auth *@bounce.mail.salesforce.com
whitelist_auth *@sendgrid.net
whitelist_auth *@*.mcdlv.net


I've seen enough spam sent through all three - both by way of whole 
apparently spammer-owned accounts and cracked-but-otherwise-legitimate 
accounts - that I would never blanket-whitelist whole bulk email providers.


Legitimate mail sent through them generally gets through anyway IME.


An alternative is to use "def_whitelist_auth" instead of "whitelist_auth"
That gives a -7.5 point bump to usually good sources which may occasionally get 
abused.


That way if one of their accounts gets p0wned your anti-phish rules have a 
chance of pulling the junk into the spam-tagged range.



--
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[David Jones]

On 02/06/2018 01:28 PM, Alex wrote:

Hi,


ifplugin Mail::SpamAssassin::Plugin::DNSEval

header  __RCVD_IN_BRBL  eval:check_rbl('brbl',
'bb.barracudacentral.org')
tflags  __RCVD_IN_BRBL  net

header  __RCVD_IN_BRBL_2eval:check_rbl_sub('brbl',
'127.0.0.2')
metaRCVD_IN_BRBL__RCVD_IN_BRBL_2 &&
!RCVD_IN_BRBL_LASTEXT
describeRCVD_IN_BRBLReceived is listed in Barracuda RBL
bb.barracudacentral.org
score   RCVD_IN_BRBL1.2
tflags  RCVD_IN_BRBLnet

header  RCVD_IN_BRBL_LASTEXT
eval:check_rbl('brbl-lastexternal',
'bb.barracudacentral.org')
describeRCVD_IN_BRBL_LASTEXTLast external is listed in
Barracuda
RBL bb.barracudacentral.org
score   RCVD_IN_BRBL_LASTEXT2.2
tflags  RCVD_IN_BRBL_LASTEXTnet

endif




You don't think these scores are a bit high for a normal installation?
The current default score for RCVD_IN_BRBL_LASTEXT is 1.4 and
RCVD_IN_BRBL doesn't otherwise exist.

Also, does someone have a recommended score for the lashback RBL? I've
had it in testing for quite some time and would like to put it into
production with reasonable values...



Ok, ok.  Uncle. (Waving white flag.)  I have been sufficiently flogged so
I
have learned my lesson.  :)  This works in my highly customized SA
platform
where I have to do outbound mail filtering so deep Received header
checking
is valuable to block spam from my customer's compromised accounts.

Leave out the RCVD_IN_BRBL rule above and change the RCVD_IN_BRBL_LASTEXT
score to 1.4 to keep things the same.



I didn't mean to imply I don't agree or otherwise support your
approach. It was just unclear that this was in conjunction with that
approach of using higher spam rule scores to offset lower ham rule
scores or if it was recommended for everyone.

If you think the RCVD_IN_BRBL rule is a good one, I'd like to use it,
and while I've implemented much of your approach, I can't implement
all of it. My users raise holy hell when they receive even one phish
from an otherwise trustworthy source that's been whitelisted. It hits
on a ton of email at both ends of the spectrum - most are either very
low scoring or are already spam.



First let me say that my method for many whitelist_auth entries does not
allow for any phishing emails so if I find any of those, they do not get a
whitelist_auth entry.  With a properly tuned MTA in front of SA, the only
phishing or blatant spam should be coming from compromised accounts or
zero-hour spam which are going to be difficult to block anyway.


Yes, I should have mentioned that as well. We're not whitelisting any
end-user level accounts.

These phishes we've received were all from otherwise trusted sources
like salesforce, amazonses and sendgrid. These are examples that I
believe were previously whitelisted because of having received a phish
through these systems but have no been disabled.

whitelist_auth *@bounce.mail.salesforce.com
whitelist_auth *@sendgrid.net
whitelist_auth *@*.mcdlv.net



I have never received phishing emails from trusted senders like those. 
If I did, then they would not be considered a trusted sender.  We have 
received unsolicited junk emails from customers of theirs after someone 
sold our email addresses to some so-called "double opt-in" email lists 
that we never opted into.  I have been reporting this abuse and those 
rogue customers are immediately locked/blocked/disabled/etc. which helps 
all of us.  I have never received a malicious/infected/spoofing email 
from those, just harmless junk email.



My method should only be whitelist_auth'ing system-generated/bulk emails
from reputable senders that handle abuse reports quickly and shouldn't match
compromised accounts and "freemail" domains.  It will also match commonly
spoofed domains like fedex.com, ups.com, and banks to help block those
phishing emails.


This also requires supporting rules that add significant points based
on their name most simply, or other more complicated rules to catch
more sophisticated phish attempts. Spammers hitting our systems are
far more sophisticated than just using "UPS" in the subject or
pretending to be from ups.com.



Sure.  What I have found effective is to train your Bayes with all 
spoofing emails so high BAYES rule hits will add points.  The authentic 
emails will score very low from the whitelist_auth entry.  Add in some 
custom regex rules in the subject and body for variations of 
misspellings of the spoofed brand or new zero-hour findings and this is 
the best protection I have been able to come up with for new 
spoofing/spam campaigns.




Can I also ask again about reasonable RCVD_IN_LASHBACK and
RCVD_IN_LASHBACK_LASTEXT scores?



It really depends on how much customization you have done to SA and how much
your mail flow can handle bumping up scores.  If you do some log analysis
and find that RCVD_IN_LASHBACK and RCVD_IN_LASHBACK_LASTEXT are pretty
accurate for your mail flow, then you 

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[Kris Deugau]

Alex wrote:

These phishes we've received were all from otherwise trusted sources
like salesforce, amazonses and sendgrid. These are examples that I
believe were previously whitelisted because of having received a phish
through these systems but have no been disabled.

whitelist_auth *@bounce.mail.salesforce.com
whitelist_auth *@sendgrid.net
whitelist_auth *@*.mcdlv.net


I've seen enough spam sent through all three - both by way of whole 
apparently spammer-owned accounts and cracked-but-otherwise-legitimate 
accounts - that I would never blanket-whitelist whole bulk email providers.


Legitimate mail sent through them generally gets through anyway IME.

-kgd

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[Dave Warren]

On 2018-02-05 09:12, Benny Pedersen wrote:

Kevin A. McGrail skrev den 2018-02-05 16:53:


I don't think that will apply will it because it will be looking up
something like 1.2.3.4.bb.barracuda.blah which isn't cached.


the first qurry can make a qurry with very low ttl, so it would not be 
cached, that means number 2 query still mkae dns query to that zone :(


How low are the TTLs? I'm seeing 300 seconds on 127.0.0.2 which is more 
than sufficient time for a single message to finish processing, such 
that multiple queries from one message would absolutely be cached (or 
more likely, the first would still be pending and the second would get 
the same answer as the first).


;; ANSWER SECTION:
2.0.0.127.bb.barracudacentral.org. 300 IN A 127.0.0.2

Maybe the TTLs are different for other records?

I am also noticing very intermittent response times, sometimes taking 
over a second to get a response, other times taking under 50ms.

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[Alex]

Hi,

> ifplugin Mail::SpamAssassin::Plugin::DNSEval
>
> header  __RCVD_IN_BRBL  eval:check_rbl('brbl',
> 'bb.barracudacentral.org')
> tflags  __RCVD_IN_BRBL  net
>
> header  __RCVD_IN_BRBL_2eval:check_rbl_sub('brbl',
> '127.0.0.2')
> metaRCVD_IN_BRBL__RCVD_IN_BRBL_2 &&
> !RCVD_IN_BRBL_LASTEXT
> describeRCVD_IN_BRBLReceived is listed in Barracuda RBL
> bb.barracudacentral.org
> score   RCVD_IN_BRBL1.2
> tflags  RCVD_IN_BRBLnet
>
> header  RCVD_IN_BRBL_LASTEXT
> eval:check_rbl('brbl-lastexternal',
> 'bb.barracudacentral.org')
> describeRCVD_IN_BRBL_LASTEXTLast external is listed in
> Barracuda
> RBL bb.barracudacentral.org
> score   RCVD_IN_BRBL_LASTEXT2.2
> tflags  RCVD_IN_BRBL_LASTEXTnet
>
> endif



 You don't think these scores are a bit high for a normal installation?
 The current default score for RCVD_IN_BRBL_LASTEXT is 1.4 and
 RCVD_IN_BRBL doesn't otherwise exist.

 Also, does someone have a recommended score for the lashback RBL? I've
 had it in testing for quite some time and would like to put it into
 production with reasonable values...

>>>
>>> Ok, ok.  Uncle. (Waving white flag.)  I have been sufficiently flogged so
>>> I
>>> have learned my lesson.  :)  This works in my highly customized SA
>>> platform
>>> where I have to do outbound mail filtering so deep Received header
>>> checking
>>> is valuable to block spam from my customer's compromised accounts.
>>>
>>> Leave out the RCVD_IN_BRBL rule above and change the RCVD_IN_BRBL_LASTEXT
>>> score to 1.4 to keep things the same.
>>
>>
>> I didn't mean to imply I don't agree or otherwise support your
>> approach. It was just unclear that this was in conjunction with that
>> approach of using higher spam rule scores to offset lower ham rule
>> scores or if it was recommended for everyone.
>>
>> If you think the RCVD_IN_BRBL rule is a good one, I'd like to use it,
>> and while I've implemented much of your approach, I can't implement
>> all of it. My users raise holy hell when they receive even one phish
>> from an otherwise trustworthy source that's been whitelisted. It hits
>> on a ton of email at both ends of the spectrum - most are either very
>> low scoring or are already spam.
>>
>
> First let me say that my method for many whitelist_auth entries does not
> allow for any phishing emails so if I find any of those, they do not get a
> whitelist_auth entry.  With a properly tuned MTA in front of SA, the only
> phishing or blatant spam should be coming from compromised accounts or
> zero-hour spam which are going to be difficult to block anyway.

Yes, I should have mentioned that as well. We're not whitelisting any
end-user level accounts.

These phishes we've received were all from otherwise trusted sources
like salesforce, amazonses and sendgrid. These are examples that I
believe were previously whitelisted because of having received a phish
through these systems but have no been disabled.

whitelist_auth *@bounce.mail.salesforce.com
whitelist_auth *@sendgrid.net
whitelist_auth *@*.mcdlv.net

> My method should only be whitelist_auth'ing system-generated/bulk emails
> from reputable senders that handle abuse reports quickly and shouldn't match
> compromised accounts and "freemail" domains.  It will also match commonly
> spoofed domains like fedex.com, ups.com, and banks to help block those
> phishing emails.

This also requires supporting rules that add significant points based
on their name most simply, or other more complicated rules to catch
more sophisticated phish attempts. Spammers hitting our systems are
far more sophisticated than just using "UPS" in the subject or
pretending to be from ups.com.

>> Can I also ask again about reasonable RCVD_IN_LASHBACK and
>> RCVD_IN_LASHBACK_LASTEXT scores?
>>
>
> It really depends on how much customization you have done to SA and how much
> your mail flow can handle bumping up scores.  If you do some log analysis
> and find that RCVD_IN_LASHBACK and RCVD_IN_LASHBACK_LASTEXT are pretty
> accurate for your mail flow, then you can bump it up like I have to 2.2 and
> 4.2 respectively.
>
> DISCLAIMER:  I am not recommending this for everyone so no flaming.  Set
> these scores low and test for a few weeks or months to see how your mail
> logs line up with real spam then increase the scores as you see fit. Again,
> I do outbound mail filtering for my customers so the deep Received header
> inspection is helpful to determine compromised accounts and keep my mail
> servers off of RBLs.

Are there any numbers available from anyone's masschecks?

Thank you as always for your support.

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[David Jones]

On 02/06/2018 10:38 AM, Alex wrote:

Hi,

On Tue, Feb 6, 2018 at 8:44 AM, David Jones  wrote:

On 02/05/2018 09:07 PM, Alex wrote:


Hi,


ifplugin Mail::SpamAssassin::Plugin::DNSEval

header  __RCVD_IN_BRBL  eval:check_rbl('brbl',
'bb.barracudacentral.org')
tflags  __RCVD_IN_BRBL  net

header  __RCVD_IN_BRBL_2eval:check_rbl_sub('brbl',
'127.0.0.2')
metaRCVD_IN_BRBL__RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT
describeRCVD_IN_BRBLReceived is listed in Barracuda RBL
bb.barracudacentral.org
score   RCVD_IN_BRBL1.2
tflags  RCVD_IN_BRBLnet

header  RCVD_IN_BRBL_LASTEXT eval:check_rbl('brbl-lastexternal',
'bb.barracudacentral.org')
describeRCVD_IN_BRBL_LASTEXTLast external is listed in
Barracuda
RBL bb.barracudacentral.org
score   RCVD_IN_BRBL_LASTEXT2.2
tflags  RCVD_IN_BRBL_LASTEXTnet

endif



You don't think these scores are a bit high for a normal installation?
The current default score for RCVD_IN_BRBL_LASTEXT is 1.4 and
RCVD_IN_BRBL doesn't otherwise exist.

Also, does someone have a recommended score for the lashback RBL? I've
had it in testing for quite some time and would like to put it into
production with reasonable values...



Ok, ok.  Uncle. (Waving white flag.)  I have been sufficiently flogged so I
have learned my lesson.  :)  This works in my highly customized SA platform
where I have to do outbound mail filtering so deep Received header checking
is valuable to block spam from my customer's compromised accounts.

Leave out the RCVD_IN_BRBL rule above and change the RCVD_IN_BRBL_LASTEXT
score to 1.4 to keep things the same.


I didn't mean to imply I don't agree or otherwise support your
approach. It was just unclear that this was in conjunction with that
approach of using higher spam rule scores to offset lower ham rule
scores or if it was recommended for everyone.

If you think the RCVD_IN_BRBL rule is a good one, I'd like to use it,
and while I've implemented much of your approach, I can't implement
all of it. My users raise holy hell when they receive even one phish
from an otherwise trustworthy source that's been whitelisted. It hits
on a ton of email at both ends of the spectrum - most are either very
low scoring or are already spam.



First let me say that my method for many whitelist_auth entries does not 
allow for any phishing emails so if I find any of those, they do not get 
a whitelist_auth entry.  With a properly tuned MTA in front of SA, the 
only phishing or blatant spam should be coming from compromised accounts 
or zero-hour spam which are going to be difficult to block anyway.


My method should only be whitelist_auth'ing system-generated/bulk emails 
from reputable senders that handle abuse reports quickly and shouldn't 
match compromised accounts and "freemail" domains.  It will also match 
commonly spoofed domains like fedex.com, ups.com, and banks to help 
block those phishing emails.



Can I also ask again about reasonable RCVD_IN_LASHBACK and
RCVD_IN_LASHBACK_LASTEXT scores?



It really depends on how much customization you have done to SA and how 
much your mail flow can handle bumping up scores.  If you do some log 
analysis and find that RCVD_IN_LASHBACK and RCVD_IN_LASHBACK_LASTEXT are 
pretty accurate for your mail flow, then you can bump it up like I have 
to 2.2 and 4.2 respectively.


DISCLAIMER:  I am not recommending this for everyone so no flaming.  Set 
these scores low and test for a few weeks or months to see how your mail 
logs line up with real spam then increase the scores as you see fit. 
Again, I do outbound mail filtering for my customers so the deep 
Received header inspection is helpful to determine compromised accounts 
and keep my mail servers off of RBLs.



ifplugin Mail::SpamAssassin::Plugin::DNSEval

header  __RCVD_IN_LASHBACK  eval:check_rbl('lashback', 
'ubl.unsubscore.com.')
describe	__RCVD_IN_LASHBACK	Received is listed in Lashback 
ubl.unsubscore.com

tflags  __RCVD_IN_LASHBACK  net

header  __RCVD_IN_LASHBACK_2eval:check_rbl_sub('lashback', 
'127.0.0.2')
metaRCVD_IN_LASHBACK__RCVD_IN_LASHBACK_2 && 
!RCVD_IN_LASHBACK_LASTEXT
describeRCVD_IN_LASHBACKReceived is listed in Lashback 
ubl.unsubscore.com
score   RCVD_IN_LASHBACK2.2
tflags  RCVD_IN_LASHBACKnet

header		RCVD_IN_LASHBACK_LASTEXT	eval:check_rbl('lashback-lastexternal', 
'ubl.unsubscore.com.')
describe 	RCVD_IN_LASHBACK_LASTEXT	Last external is listed in Lashback 
ubl.unsubscore.com

score   RCVD_IN_LASHBACK_LASTEXT4.2
tflags  RCVD_IN_LASHBACK_LASTEXTnet

endif


--
David Jones

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[Alex]

Hi,

On Tue, Feb 6, 2018 at 8:44 AM, David Jones  wrote:
> On 02/05/2018 09:07 PM, Alex wrote:
>>
>> Hi,
>>
>>> ifplugin Mail::SpamAssassin::Plugin::DNSEval
>>>
>>> header  __RCVD_IN_BRBL  eval:check_rbl('brbl',
>>> 'bb.barracudacentral.org')
>>> tflags  __RCVD_IN_BRBL  net
>>>
>>> header  __RCVD_IN_BRBL_2eval:check_rbl_sub('brbl',
>>> '127.0.0.2')
>>> metaRCVD_IN_BRBL__RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT
>>> describeRCVD_IN_BRBLReceived is listed in Barracuda RBL
>>> bb.barracudacentral.org
>>> score   RCVD_IN_BRBL1.2
>>> tflags  RCVD_IN_BRBLnet
>>>
>>> header  RCVD_IN_BRBL_LASTEXT eval:check_rbl('brbl-lastexternal',
>>> 'bb.barracudacentral.org')
>>> describeRCVD_IN_BRBL_LASTEXTLast external is listed in
>>> Barracuda
>>> RBL bb.barracudacentral.org
>>> score   RCVD_IN_BRBL_LASTEXT2.2
>>> tflags  RCVD_IN_BRBL_LASTEXTnet
>>>
>>> endif
>>
>>
>> You don't think these scores are a bit high for a normal installation?
>> The current default score for RCVD_IN_BRBL_LASTEXT is 1.4 and
>> RCVD_IN_BRBL doesn't otherwise exist.
>>
>> Also, does someone have a recommended score for the lashback RBL? I've
>> had it in testing for quite some time and would like to put it into
>> production with reasonable values...
>>
>
> Ok, ok.  Uncle. (Waving white flag.)  I have been sufficiently flogged so I
> have learned my lesson.  :)  This works in my highly customized SA platform
> where I have to do outbound mail filtering so deep Received header checking
> is valuable to block spam from my customer's compromised accounts.
>
> Leave out the RCVD_IN_BRBL rule above and change the RCVD_IN_BRBL_LASTEXT
> score to 1.4 to keep things the same.

I didn't mean to imply I don't agree or otherwise support your
approach. It was just unclear that this was in conjunction with that
approach of using higher spam rule scores to offset lower ham rule
scores or if it was recommended for everyone.

If you think the RCVD_IN_BRBL rule is a good one, I'd like to use it,
and while I've implemented much of your approach, I can't implement
all of it. My users raise holy hell when they receive even one phish
from an otherwise trustworthy source that's been whitelisted. It hits
on a ton of email at both ends of the spectrum - most are either very
low scoring or are already spam.

Can I also ask again about reasonable RCVD_IN_LASHBACK and
RCVD_IN_LASHBACK_LASTEXT scores?

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[David Jones]

On 02/05/2018 09:07 PM, Alex wrote:

Hi,


ifplugin Mail::SpamAssassin::Plugin::DNSEval

header  __RCVD_IN_BRBL  eval:check_rbl('brbl',
'bb.barracudacentral.org')
tflags  __RCVD_IN_BRBL  net

header  __RCVD_IN_BRBL_2eval:check_rbl_sub('brbl',
'127.0.0.2')
metaRCVD_IN_BRBL__RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT
describeRCVD_IN_BRBLReceived is listed in Barracuda RBL
bb.barracudacentral.org
score   RCVD_IN_BRBL1.2
tflags  RCVD_IN_BRBLnet

header  RCVD_IN_BRBL_LASTEXT eval:check_rbl('brbl-lastexternal',
'bb.barracudacentral.org')
describeRCVD_IN_BRBL_LASTEXTLast external is listed in Barracuda
RBL bb.barracudacentral.org
score   RCVD_IN_BRBL_LASTEXT2.2
tflags  RCVD_IN_BRBL_LASTEXTnet

endif


You don't think these scores are a bit high for a normal installation?
The current default score for RCVD_IN_BRBL_LASTEXT is 1.4 and
RCVD_IN_BRBL doesn't otherwise exist.

Also, does someone have a recommended score for the lashback RBL? I've
had it in testing for quite some time and would like to put it into
production with reasonable values...



Ok, ok.  Uncle. (Waving white flag.)  I have been sufficiently flogged 
so I have learned my lesson.  :)  This works in my highly customized SA 
platform where I have to do outbound mail filtering so deep Received 
header checking is valuable to block spam from my customer's compromised 
accounts.


Leave out the RCVD_IN_BRBL rule above and change the 
RCVD_IN_BRBL_LASTEXT score to 1.4 to keep things the same.


--
David Jones

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[Matus UHLAR - fantomas]

David Jones skrev den 2018-02-05 15:09:


ifplugin Mail::SpamAssassin::Plugin::DNSEval

header  __RCVD_IN_BRBL  eval:check_rbl('brbl',
'bb.barracudacentral.org')
tflags  __RCVD_IN_BRBL  net

header  __RCVD_IN_BRBL_2eval:check_rbl_sub('brbl', 
'127.0.0.2')
metaRCVD_IN_BRBL__RCVD_IN_BRBL_2 && 
!RCVD_IN_BRBL_LASTEXT

describeRCVD_IN_BRBLReceived is listed in Barracuda RBL
bb.barracudacentral.org
score   RCVD_IN_BRBL1.2
tflags  RCVD_IN_BRBLnet

header  RCVD_IN_BRBL_LASTEXT
eval:check_rbl('brbl-lastexternal', 'bb.barracudacentral.org')
describeRCVD_IN_BRBL_LASTEXTLast external is listed in
Barracuda RBL bb.barracudacentral.org
score   RCVD_IN_BRBL_LASTEXT2.2
tflags  RCVD_IN_BRBL_LASTEXTnet

endif


On 05.02.18 16:26, Benny Pedersen wrote:
this rule makes 2 dns querys, waste of cpu performance, i would 
suggest to drop the lastextnal,


this rule checks all untrusted IPs, while lastexternal uses only one (often
the most important - IP that sent mail to your systems).

also, because of caching, brbl-lastexternal result will be cached.
b.barracudacentral.org uses ttl of 300, which should be cached during the
mail processing.

if you want to spare DNS queries, leave only lastexternal.

so its only if ip is listed yes or 
no, 50% dns querys saved, and still same hits on listed ips, why do 
we need to help spammers ?


network checks including DNS lookups help much in spam processing, after
bayes they are second best mechanism to detect spam.

NOT using them is helping spammers.

--
Matus UHLAR - fantomas, uh...@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.
Atheism is a non-prophet organization. 

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[Alex]

Hi,

> ifplugin Mail::SpamAssassin::Plugin::DNSEval
>
> header  __RCVD_IN_BRBL  eval:check_rbl('brbl',
> 'bb.barracudacentral.org')
> tflags  __RCVD_IN_BRBL  net
>
> header  __RCVD_IN_BRBL_2eval:check_rbl_sub('brbl',
> '127.0.0.2')
> metaRCVD_IN_BRBL__RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT
> describeRCVD_IN_BRBLReceived is listed in Barracuda RBL
> bb.barracudacentral.org
> score   RCVD_IN_BRBL1.2
> tflags  RCVD_IN_BRBLnet
>
> header  RCVD_IN_BRBL_LASTEXT eval:check_rbl('brbl-lastexternal',
> 'bb.barracudacentral.org')
> describeRCVD_IN_BRBL_LASTEXTLast external is listed in Barracuda
> RBL bb.barracudacentral.org
> score   RCVD_IN_BRBL_LASTEXT2.2
> tflags  RCVD_IN_BRBL_LASTEXTnet
>
> endif

You don't think these scores are a bit high for a normal installation?
The current default score for RCVD_IN_BRBL_LASTEXT is 1.4 and
RCVD_IN_BRBL doesn't otherwise exist.

Also, does someone have a recommended score for the lashback RBL? I've
had it in testing for quite some time and would like to put it into
production with reasonable values...

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[RW]

On Mon, 05 Feb 2018 17:12:08 +0100
Benny Pedersen wrote:

> Kevin A. McGrail skrev den 2018-02-05 16:53:
> 
> > I don't think that will apply will it because it will be looking up
> > something like 1.2.3.4.bb.barracuda.blah which isn't cached.  
> 
> the first qurry can make a qurry with very low ttl, so it would not
> be cached, that means number 2 query still mkae dns query to that
> zone :(

SA sends its DNS requests out early in rapid succession. The chances
are that the local DNS cache would see the second request as a
duplicate of a pending look-up.  In that case caching is not needed.


> > Anyway, we're debating a rule that's removed :)  

> lastexternal is still a mistake imho :=)


lastexternal is correct, that's what RCVD_IN_BRBL_LASTEXT does. Making
use of deep checks on lists containing dynamic addresses is risky, and
likely to vary a lot between different mail flows. 

David's rules are not appropriate as a general replacement for
RCVD_IN_BRBL_LASTEXT IMO.

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[Kevin A. McGrail]

On 2/5/2018 11:32 AM, RW wrote:

Just to clarify, there is no legal or moral obligation to do this, the
'bb' subdomain was created specifically so SA users wouldn't need to
register. Anything you may read on the Barracuda site applies to the
'b' version. Barracuda has given no indication that anything has
changed.


I've been trying to reach Barracuda pretty doggedly about the issue for 
months about the issues with bb requiring registration hence the 
removal.   If you have a contact, get in touch with them and we can 
relight the rule.  I was hoping some discussion on list might get their 
attention.


Regards,
KAM

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[RW]

On Mon, 5 Feb 2018 08:09:55 -0600
David Jones wrote:

> Heads up!  This RBL has been removed from the core SA ruleset.  In 36
> to 48 hours sa-update will remove the RCVD_IN_BRBL_LASTEXT rule after
> it has gone through the masscheck and rule promotion process.
> 
> Details can be found here:
> 
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7417
> 
> To add this rule back manually, you should register here:
> 
> http://barracudacentral.org/account/register

Just to clarify, there is no legal or moral obligation to do this, the
'bb' subdomain was created specifically so SA users wouldn't need to
register. Anything you may read on the Barracuda site applies to the
'b' version. Barracuda has given no indication that anything has
changed.

The issue is that some users have seen look-ups fail and attributed it
to possible rate limiting on non-registered IP addresses.

You should register if you use the 'b' list directly from an MTA. If
you only run the 'bb' version from SA and use fixed IP addresses it
*may* help with reliability if you register. If you run SA client side
on a dynamic address there's no point in registering.

> and add this to your local.cf:

I would suggest people just copy the existing rule as it is.  This list
contains dynamic IP addresses so shouldn't be used for deep look-ups.  
 
> NOTE: recent masscheck processing shows RCVD_IN_BRBL_LASTEXT as the
> most effective non-zero scoring rule to hit spam (43%) so it's
> probably worth adding back to your local.cf on Wednesday or Thursday.

If you don't rename the rule there's no need to wait. 

Note that once it's removed the scores for other rules will adjust to
compensate for its absence, and this *may* lead to more FP's if it's
left at its current score. 

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[Benny Pedersen]

Kevin A. McGrail skrev den 2018-02-05 16:53:


I don't think that will apply will it because it will be looking up
something like 1.2.3.4.bb.barracuda.blah which isn't cached.


the first qurry can make a qurry with very low ttl, so it would not be 
cached, that means number 2 query still mkae dns query to that zone :(



Anyway, we're debating a rule that's removed :)


lastexternal is still a mistake imho :=)

gosh i hate bind9 not have minimal ttl, good thing is that low ttl 
strikes back to badly configured dns zones :=)

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[David Jones]

On 02/05/2018 09:44 AM, Reindl Harald wrote:


Am 05.02.2018 um 16:36 schrieb David Jones:

On 02/05/2018 09:26 AM, Benny Pedersen wrote:

David Jones skrev den 2018-02-05 15:09:


ifplugin Mail::SpamAssassin::Plugin::DNSEval

header  __RCVD_IN_BRBL  eval:check_rbl('brbl',
'bb.barracudacentral.org')
tflags  __RCVD_IN_BRBL  net

header  __RCVD_IN_BRBL_2    eval:check_rbl_sub('brbl', 
'127.0.0.2')
meta    RCVD_IN_BRBL    __RCVD_IN_BRBL_2 && 
!RCVD_IN_BRBL_LASTEXT

describe    RCVD_IN_BRBL    Received is listed in Barracuda RBL
bb.barracudacentral.org
score   RCVD_IN_BRBL    1.2
tflags  RCVD_IN_BRBL    net

header  RCVD_IN_BRBL_LASTEXT
eval:check_rbl('brbl-lastexternal', 'bb.barracudacentral.org')
describe    RCVD_IN_BRBL_LASTEXT    Last external is listed in
Barracuda RBL bb.barracudacentral.org
score   RCVD_IN_BRBL_LASTEXT    2.2
tflags  RCVD_IN_BRBL_LASTEXT    net

endif


this rule makes 2 dns querys, waste of cpu performance, i would 
suggest to drop the lastextnal, so its only if ip is listed yes or 
no, 50% dns querys saved, and still same hits on listed ips, why do 
we need to help spammers ?


If you are running a local DNS cache like this list and the SA 
documention recommends, does this really matter?  My MTA should have 
already queried this before SA does it so it should be in the local 
DNS cache and not require a full recursive lookup from the SA rule above


1.2 poitns just because the IP of the previous hop is listet is pure 
nonsense and it was even nosense as Barracuda Networks started with that 
bullshit called "deep header inspection"


Barracuda and many other RBL's list here a ton of innocent IP's which 
are nothing else than the endusers range which never should tocu an 
inbound MX itself


so what the hell is the point that you give me 1.2 points because i use 
as i should our MTA from my home-ip to send an ordianry mail?


It can be a sign of a compromised account.  I just saw a compromised 
account coming from Nigeria listed on BRBL through Office 365.  Now that 
O365 is finally adding the "x-originating-ip" header, we can detect 
botnets sending via infected home computers.


Legit emails should have other rules subtracting points so a 1.2 should 
not be a major factor in the score.  My mail platform is scoring real 
spam greater than 18 and usually in the 20's.  I could leave this rule 
out and be fine but most default SA instances would benefit from it.  If 
they want to lower the scores, then make them 0.2 and 1.2 then and use 
them in meta rules.


--
David Jones

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[Kevin A. McGrail]

On 2/5/2018 10:36 AM, David Jones wrote:
If you are running a local DNS cache like this list and the SA 
documention recommends, does this really matter?  My MTA should have 
already queried this before SA does it so it should be in the local 
DNS cache and not require a full recursive lookup from the SA rule above. 


I don't think that will apply will it because it will be looking up 
something like 1.2.3.4.bb.barracuda.blah which isn't cached.


Anyway, we're debating a rule that's removed :)


Regards,
KAM

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[Benny Pedersen]

David Jones skrev den 2018-02-05 16:36:


If you are running a local DNS cache like this list and the SA
documention recommends, does this really matter?  My MTA should have
already queried this before SA does it so it should be in the local
DNS cache and not require a full recursive lookup from the SA rule
above.


yes it matters with low ttl, non datafeeds have low ttl, so it does not 
cache much on dns servers, sadly, this can be avoided in spamassassin 
without 2 dns querys


it have always just be low priotet since we all assume datafedds where 
is does not matter



This shouldn't be the case with a local DNS cache with the
/etc/resolv.conf pointed to 127.0.0.1 or SA dns_server pointed to
127.0.0.1.


already done here


can lastexternal be solved to only use one query ?
as is i think spamassassin should be changed so it can if not already


on top of that bb. is for spamassassin, while b. was for mta stage, so 
200% more querys to non datafeeds :/


it should have being one dns zone

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[David Jones]

On 02/05/2018 09:26 AM, Benny Pedersen wrote:

David Jones skrev den 2018-02-05 15:09:


ifplugin Mail::SpamAssassin::Plugin::DNSEval

header  __RCVD_IN_BRBL  eval:check_rbl('brbl',
'bb.barracudacentral.org')
tflags  __RCVD_IN_BRBL  net

header  __RCVD_IN_BRBL_2    eval:check_rbl_sub('brbl', 
'127.0.0.2')

meta    RCVD_IN_BRBL    __RCVD_IN_BRBL_2 && !RCVD_IN_BRBL_LASTEXT
describe    RCVD_IN_BRBL    Received is listed in Barracuda RBL
bb.barracudacentral.org
score   RCVD_IN_BRBL    1.2
tflags  RCVD_IN_BRBL    net

header  RCVD_IN_BRBL_LASTEXT
eval:check_rbl('brbl-lastexternal', 'bb.barracudacentral.org')
describe    RCVD_IN_BRBL_LASTEXT    Last external is listed in
Barracuda RBL bb.barracudacentral.org
score   RCVD_IN_BRBL_LASTEXT    2.2
tflags  RCVD_IN_BRBL_LASTEXT    net

endif


this rule makes 2 dns querys, waste of cpu performance, i would suggest 
to drop the lastextnal, so its only if ip is listed yes or no, 50% dns 
querys saved, and still same hits on listed ips, why do we need to help 
spammers ?




If you are running a local DNS cache like this list and the SA 
documention recommends, does this really matter?  My MTA should have 
already queried this before SA does it so it should be in the local DNS 
cache and not require a full recursive lookup from the SA rule above.



anyway i dont use it, above rule is only optimized for datafeeds, it 
will drain non datafeed clients into hell




This shouldn't be the case with a local DNS cache with the 
/etc/resolv.conf pointed to 127.0.0.1 or SA dns_server pointed to 127.0.0.1.



can lastexternal be solved to only use one query ?

as is i think spamassassin should be changed so it can if not already


--
David Jones

Re: Barracuda Reputation Block List (BRBL) removal from the SA ruleset

[Benny Pedersen]

David Jones skrev den 2018-02-05 15:09:


ifplugin Mail::SpamAssassin::Plugin::DNSEval

header  __RCVD_IN_BRBL  eval:check_rbl('brbl',
'bb.barracudacentral.org')
tflags  __RCVD_IN_BRBL  net

header  __RCVD_IN_BRBL_2eval:check_rbl_sub('brbl', 
'127.0.0.2')
metaRCVD_IN_BRBL__RCVD_IN_BRBL_2 && 
!RCVD_IN_BRBL_LASTEXT

describeRCVD_IN_BRBLReceived is listed in Barracuda RBL
bb.barracudacentral.org
score   RCVD_IN_BRBL1.2
tflags  RCVD_IN_BRBLnet

header  RCVD_IN_BRBL_LASTEXT
eval:check_rbl('brbl-lastexternal', 'bb.barracudacentral.org')
describeRCVD_IN_BRBL_LASTEXTLast external is listed in
Barracuda RBL bb.barracudacentral.org
score   RCVD_IN_BRBL_LASTEXT2.2
tflags  RCVD_IN_BRBL_LASTEXTnet

endif


this rule makes 2 dns querys, waste of cpu performance, i would suggest 
to drop the lastextnal, so its only if ip is listed yes or no, 50% dns 
querys saved, and still same hits on listed ips, why do we need to help 
spammers ?


anyway i dont use it, above rule is only optimized for datafeeds, it 
will drain non datafeed clients into hell


can lastexternal be solved to only use one query ?

as is i think spamassassin should be changed so it can if not already