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: Tone of emails with subject: 'hey'

[Kevin A. McGrail]

On 2/5/2018 6:29 PM, John Hardin wrote:

Any suggestions on where to start? nOOb here!


Do you have Bayes enabled and are you training it? 


Also do you have KAM.cf?

Regards,

kAM

Re: Matching To in Subject

[John Hardin]

On Mon, 5 Feb 2018, Alex wrote:


Hi,
Is it possible to identify if the Subject contains the sender?


You mean like __SUBJ_HAS_FROM_1 ?

I realize this probably isn't a significant spam indicator, but I think 
it would be helpful.


 From: example.com  
 To: mor...@example.com
 Subject: mor...@example.com You have just 15 hours to verify your account


That example is the *recipient*. __TO_IN_SUBJ

Neither one is very useful by itself, they would have to be meta'd with 
other rules, like subject =~ /verify your account/ - which will probably 
be strong enough signs on their own.



I'm also thinking the From with just the domain is a variation of what
we saw a few weeks ago with the attempt to confuse the sender.





--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Maxim IV: Close air support covereth a multitude of sins.
---
 Tomorrow: the first Falcon Heavy test launch

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.

Matching To in Subject

[Alex]

Hi,
Is it possible to identify if the Subject contains the sender? I
realize this probably isn't a significant spam indicator, but I think
it would be helpful.

  From: example.com  
  To: mor...@example.com
  Subject: mor...@example.com You have just 15 hours to verify your account

I'm also thinking the From with just the domain is a variation of what
we saw a few weeks ago with the attempt to confuse the sender.

Re: Tone of emails with subject: 'hey'

[John Hardin]

On Tue, 6 Feb 2018, Philip wrote:

So lately I'm getting LOTS of emails coming directly though the filters so 
most likely time to investigate how to create one.


The subject is always 'hey'

Subject: hey

Date: Mon, 29 Jan 2018 09:07:40 +0300
From: Darya Message-ID: <8f35b00fb4e07d18ce82448ec9747...@112it4u.ro>
X-Mailer: PHPMailer 5.2.22 (https://github.com/PHPMailer/PHPMailer)
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


Any SA hits at all? Please provide at a minimum that header; better, 
upload the entire message (all headers intact) to someplace like pastebin.


Hi josh, my name is Darya and i'm from Russia, but living in the USA. A week 
ago, maybe more, I came across your profile on Facebook and now I wan to know 
you more. I know it sounds a bit strange, but I believe you had something 
like this in your life too :-) If its mutual, email me, this is my email 
danielamar...@rambler.ru and I will send some of my photos also answer any of 
your questions. Waiting for you, XXX Darya


This sort of thing I'd expect Bayes to catch.

112it4u.ro from the message ID has valid NS entries but the reverse PTR is 
invalid.


I don't know whether DNS checks on the hostname in the message-ID would be 
worthwhile...


The email always starts, 'hi {mailbox name}, and the text is mostly the same 
but the name changes now and then and so does the email address.


Any suggestions on where to start? nOOb here!


Do you have Bayes enabled and are you training it?

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Watch... Wallet... Gun... Knee...-- Denny Crane
---
 Tomorrow: the first Falcon Heavy test launch

Tone of emails with subject: 'hey'

[Philip]

So lately I'm getting LOTS of emails coming directly though the filters 
so most likely time to investigate how to create one.


The subject is always 'hey'

Subject: hey

Date: Mon, 29 Jan 2018 09:07:40 +0300
From: Darya Message-ID: <8f35b00fb4e07d18ce82448ec9747...@112it4u.ro>
X-Mailer: PHPMailer 5.2.22 (https://github.com/PHPMailer/PHPMailer)
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi josh, my name is Darya and i'm from Russia, but living in the USA. A 
week ago, maybe more, I came across your profile on Facebook and now I 
wan to know you more. I know it sounds a bit strange, but I believe you 
had something like this in your life too :-) If its mutual, email me, 
this is my email danielamar...@rambler.ru and I will send some of my 
photos also answer any of your questions. Waiting for you, XXX Darya


As far as I can see from the different emails:

X-PHP-Originating-Script: 852:class-phpmailer.php

The number is sequential.

112it4u.ro from the message ID has valid NS entries but the reverse PTR 
is invalid.


The email always starts, 'hi {mailbox name}, and the text is mostly the 
same but the name changes now and then and so does the email address.


Any suggestions on where to start? nOOb here!

Phil

Re: repeating tflags difrective

[Kevin A. McGrail]

On 2/5/2018 11:48 AM, Benny Pedersen wrote:

Kevin A. McGrail skrev den 2018-02-05 10:46:


tflags    TEST_RULE    nice

Then in a later file you decide to add:

tflags TEST_RULE net


tflags TEST_RULE config=inherit net

could be usefull :=)

tflags TEST_RULE config=override net

that way we have a choice to use defaults still


Elegant idea but such an edge case the work isn't justified in my opinion.

Regards,

KAM

Re: repeating tflags difrective

[Benny Pedersen]

Kevin A. McGrail skrev den 2018-02-05 10:46:


tflags    TEST_RULE    nice

Then in a later file you decide to add:

tflags TEST_RULE net


tflags TEST_RULE config=inherit net

could be usefull :=)

tflags TEST_RULE config=override net

that way we have a choice to use defaults still

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

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

[David Jones]

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

and add this to your local.cf:


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


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.


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

--
David Jones

Re: repeating tflags difrective

[Kevin A. McGrail]

On 2/5/2018 4:07 AM, Matus UHLAR - fantomas wrote:
then I repeatedly use the "tflags" directive in official rules and 
locally: 
So I think you are saying you have a rule in one file, for example, a 
default cf file with this line:


tflags    TEST_RULE    nice

Then in a later file you decide to add:

tflags TEST_RULE net

The outcome I expect is that whichever config file is parsed later 
overrides all the flags because the value for that setting is just 
overwritten just like score.  Looking at the code their is nothing 
special that would do otherwise


Regards,
KAM

repeating tflags difrective

[Matus UHLAR - fantomas]

Hello,

then I repeatedly use the "tflags" directive in official rules and locally:

Does second appearance of "tflags" override the old value or just adds new
flags?

in other words:

Do I have to repeat all flags in tflags directive, or is it enough to add
new flag?

there are rules with high negative score that I don't want to trigger
autolearn.
--
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.
A day without sunshine is like, night.