Re: Invoice phish

[Rupert Gallagher]

Is O365 freemail now? Free from Microsoft is an oxymoron.

Re: training bayes database

[Matthew Broadhead]

On 09/05/18 09:09, Reio Remma wrote:

On 09.05.18 9:57, Matthew Broadhead wrote:

BAYES_00=-1.9


I've personally set *bayes_sql_override_username = amavis* in my local.cf

If at all possible, run amavisd with SA bayes debug to see if/how it's 
using the database.


Good luck,
Reio



Thanks Reio, I was just trying your debug suggestion now.  my local.cf 
had vmail commented out so i added amavis

#bayes_sql_override_username vmail
bayes_sql_override_username amavis

Re: training bayes database

[Matthew Broadhead]

(1)

[root@ns1 ~]# sudo -H -u amavis bash -c '/usr/bin/sa-learn --dump magic'
0.000  0  3  0  non-token data: bayes db version
0.000  0  32225  0  non-token data: nspam
0.000  0 440420  0  non-token data: nham
0.000  0 159483  0  non-token data: ntokens
0.000  0 1525435204  0  non-token data: oldest atime
0.000  0 1525848687  0  non-token data: newest atime
0.000  0  0  0  non-token data: last journal 
sync atime

0.000  0 1525824089  0  non-token data: last expiry atime
0.000  0 443565  0  non-token data: last expire 
atime delta
0.000  0  0  0  non-token data: last expire 
reduction count


(2)

as you say i think it is amavis user

(3)

your message has

X-Spam-Status: No, score=-18.15 tagged_above=-999 required=6.2
    tests=[AM.WBL=-3, BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25,
    MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001,
    URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5]
    autolearn=ham autolearn_force=no

(4)

around 50 users.  they are all working in same industry


On 08/05/18 21:08, John Hardin wrote:

On Tue, 8 May 2018, Matthew Broadhead wrote:

system setup centos-release-7-4.1708.el7.centos.x86_64, 
spamassassin-3.4.0-2.el7.x86_64, amavisd-new-2.11.0-3.el7.noarch


/etc/mail/spamassassin/local.cf:
required_hits 5
report_safe 0
rewrite_header Subject [SPAM]

use_bayes  1
bayes_auto_learn   1
bayes_auto_expire  1

# Store bayesian data in MySQL
bayes_store_module Mail::SpamAssassin::BayesStore::MySQL
bayes_sql_dsn       DBI:mysql:sa_bayes:localhost:3306

it is storing the info to the database ok.  but it doesn't seem to be 
filtering any mail.


(1) What is the output of: /usr/bin/sa-learn --dump magic

(2) What user are you running sa-learn as for training, and what user 
is spamd running as?


(3) Are you seeing any BAYES_nn rule hits on messages at all, on 
either ham or spam?


(4) How large is your environment (rough # and diversity of users)?

I'm not familiar with SQL Bayes, others may have other 
questions/recommendations.


Some general comments:

I don't recommend using auto-learn for initial bayes training at 
least, particularly in smaller environments. Manual initial training 
with careful review, followed by manual training of misclassifications 
after review, is more reliable. Others may offer different advice, 
particularly for large installs with a diverse user community (which I 
don't manage).


Always keep your training corpora so that you can review and fix 
training errors, and wipe and retrain from scratch if Bayes goes 
completely off the rails for some reason.


If you're not auto-learning, auto-expire is not needed. If you *are*, 
it's recommended to expire from a scheduled job rather than take the 
hit from spamd.

Re: training bayes database

[Reio Remma]

On 09.05.18 9:57, Matthew Broadhead wrote:

BAYES_00=-1.9


I've personally set *bayes_sql_override_username = amavis* in my local.cf

If at all possible, run amavisd with SA bayes debug to see if/how it's 
using the database.


Good luck,
Reio

Re: Invoice phish

[David Jones]

On 05/09/2018 10:59 AM, Alex wrote:

Hi,


https://pastebin.com/raw/TfvhUu0X


...

What I have had to do is basically increase the score on all invoice emails
to try to block the bad ones and then whitelist the good ones.

That email was BCC'd which is another suspicious trait which is why I bump
up the score for MISSING HEADERS.  I have other ways to penalize these
emails at SMTP time based on the number of BCC'd recipients if this were
received by my servers but I can't tell after the fact like this.


Yes, we've similarly created rules for missing headers.


There is so much junk coming out of Office 365 right now from compromised
accounts and otherwise that it's really hard to accurately filtering O365
email.  I have created a rule based on the X-OriginatorOrg: header to start
subtracting points for known OK senders and then bumping up other rule hits
like invoice-related ones that come from O365.  I know this doesn't help
with compromised accounts in known OK Orgs but it definitely cuts down the
majority of the fake invoice emails.

header  __RCVD_OFFICE365Received =~
/\.outbound\.protection\.outlook\.com \[/
header  __RCVD_OFFICE365_PROXY  X-ClientProxiedBy =~ /\.outlook\.com
\(/

header  __OFFICE365_TRUST_ORG   X-OriginatorOrg =~
/^(ena\.com|example\.com)/


You've set this to be your local system, but what if the mail relay
does not process outbound email? What are legitimate values for this
header?



I don't have "ena.com" in my own rule.  Rather I have dozens of others 
listed.  Sorry if this is confusing to imply this is for outbound mail.



In other words, is this helpful if your mail relay doesn't process
your outbound mail?



Yes.  It's not meant for outbound but inbound.  I shouldn't have put 
"ena.com" in there for me but you could put it in there for your local 
rules if you think our email is trustworthy.  :)


--
David Jones

Re: Invoice phish

[John Hardin]

On Wed, 9 May 2018, Alex wrote:


Hi,


Hi,
Does anyone have any special techniques for catching these invoice phish
emails?

https://pastebin.com/raw/TfvhUu0X

I've added a few body rules, and even despite training previous
similar messages as spam, they continue. These emails very closely
resemble legitimate email regarding invoices that purchasing people
fall for them all the time.

Senderscore greater than 90, and routed through O365.

The domain is no longer defined in DNS, but even the x-originating-ip
is not currently listed on any RBL.


Hmmm.

"attached" + "invoice" + no actual attachments? A download URL ain't an
attachment...


Turns out "attach" appears in headers which are apparently processed
by body rules:

body   __LOC_BODY_ATTACH   /.*attach.*/i

I've set it with the asterisks to include the full output in a rule
hit to identify where exactly it's hitting. In this case it hits on
"X-MS-Has-Attach: yes"

Why is this body rule hitting on a header? I thought only Subject was
considered part of the body?


I can't duplicate that here, "body" does not hit on headers.

Subject is included in the body, but *not* the "Subject:" part...

Does your test message have a inline attachment? Are you sure it's 
properly-formed?



--
 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
---
  The ["assault weapons"] ban is the moral equivalent of banning red
  cars because they look too fast.  -- Steve Chapman, Chicago Tribune
---
 405 days since the first commercial re-flight of an orbital booster (SpaceX)

Re: training bayes database

[John Hardin]

Also:

On Wed, 9 May 2018, Matthew Broadhead wrote:


your message has

X-Spam-Status: No, score=-18.15 tagged_above=-999 required=6.2


Setting the threshold higher will result in more spam getting through. The 
scores calculated by the masscheck processes are based on the assumption 
that the threshold is set to 5.0


Is there some specific reason you set the threshold higher than 5.0?

--
 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
---
  Your mouse has moved. Your Windows Operating System must be
  relicensed due to this hardware change. Please contact Microsoft
  to obtain a new activation key. If this hardware change results in
  added functionality you may be subject to additional license fees.
  Your system will now shut down. Thank you for choosing Microsoft.
---
 405 days since the first commercial re-flight of an orbital booster (SpaceX)

Re: Invoice phish

[Alex]

Hi,

>> Hi,
>> Does anyone have any special techniques for catching these invoice phish
>> emails?
>>
>> https://pastebin.com/raw/TfvhUu0X
>>
>> I've added a few body rules, and even despite training previous
>> similar messages as spam, they continue. These emails very closely
>> resemble legitimate email regarding invoices that purchasing people
>> fall for them all the time.
>>
>> Senderscore greater than 90, and routed through O365.
>>
>> The domain is no longer defined in DNS, but even the x-originating-ip
>> is not currently listed on any RBL.
>
> Hmmm.
>
> "attached" + "invoice" + no actual attachments? A download URL ain't an
> attachment...

Turns out "attach" appears in headers which are apparently processed
by body rules:

body   __LOC_BODY_ATTACH   /.*attach.*/i

I've set it with the asterisks to include the full output in a rule
hit to identify where exactly it's hitting. In this case it hits on
"X-MS-Has-Attach: yes"

Why is this body rule hitting on a header? I thought only Subject was
considered part of the body?

Re: Invoice phish

[Alex]

Hi,

> One more thing.  I have expanded my definition of FREEMAIL to any Google and
> Office 365 senders like this:
>
> header  __RCVD_YAHOOReceived =~ /\.yahoo\.com \[/
> header  __RCVD_HOTMAIL  Received =~ /\.hotmail\.com \[/
> header  __RCVD_GOOGLE   Received =~ /\.google\.com \[/
> header  __RCVD_OFFICE365Received =~
> /\.outbound\.protection\.outlook\.com \[/
> header  __RCVD_COX_NET  Received =~ /\.cox\.net \[/
> header  __RCVD_RR_COM   Received =~ /\.rr\.com \[/
> header  __RCVD_CHARTER_NET  Received =~ /\.charter\.net \[/
> header  __RCVD_COMCAST_NET  Received =~ /\.comcast\.net \[/
> header  __RCVD_CENTURYLINK_NET  Received =~ /\.onyx\.syn-alias\.com
> \[/
> header  __RCVD_HUGHES_NET   Received =~ /\(mx\.hughes\.net \[/
>
> meta__RCVD_FREEMAIL (__RCVD_YAHOO || __RCVD_HOTMAIL ||
> __RCVD_GOOGLE || __RCVD_OFFICE365 || __RCVD_COX_NET || __RCVD_CHARTER_NET ||
> __RCVD_COMCAST_NET || __RCVD_RR_COM || __RCVD_CENTURYLINK_NET ||
> __RCVD_HUGHES_NET)
>
> metaENA_FREEMAIL(FREEMAIL_FROM || FREEMAIL_REPLYTO
> || FREEMAIL_FORGED_REPLYTO || __RCVD_FREEMAIL)
> score   ENA_FREEMAIL0.2
>
> Then I use the ENA_FREEMAIL rule in meta rules to bump up the sensitivity of
> mail passing through these sources just like other non-trusted FREEMAIL.

What's the difference between creating new header rules for these or
just adding the domains to the freemail_domains list?

Wouldn't we want to just add them to SA proper so everyone has them?

Re: Invoice phish

[Kris Deugau]

David Jones wrote:

One more thing.  I have expanded my definition of FREEMAIL to any Google 
and Office 365 senders like this:


header  __RCVD_YAHOO    Received =~ /\.yahoo\.com \[/
header  __RCVD_HOTMAIL  Received =~ /\.hotmail\.com \[/
header  __RCVD_GOOGLE   Received =~ /\.google\.com \[/
header  __RCVD_OFFICE365    Received =~ 
/\.outbound\.protection\.outlook\.com \[/


[etc]

NOTE: The Received headers above are Postfix-style so you may have to 
adjust the rule to fit your MTA's style or what you are trying to target.


Use the X-Spam-Relays-* metaheaders SA extracts to match against a 
non-site-specific Received: chain.  I pulled the examples below from the 
local rules here:


header __RCVD_HOTMAIL   X-Spam-Relays-External =~ /^[^\]]+ 
rdns=[\w.-]+\.(?:hotmail|outlook)\.com /
header __RCVD_GOOGLEX-Spam-Relays-External =~ /^[^\]]+ 
rdns=[\w.-]+\.google\.com /
header  __HOST_YAHOOX-Spam-Relays-External =~ /^[^\]]+ rdns=[^ 
]+\.yahoo\.com /
header  __HOST_AOL  X-Spam-Relays-External =~ /^[^\]]+ rdns=[^ 
]+\.aol\.com /


(I really need to clean these up and probably put them in their own 
file, too;  I found overlapping definitions and as above, several naming 
conventions.)


Note that Hotmail/Outlook.com are merged;  for the record the mail flow 
I've seen indicates that it's all one big cluster and the outbound mail 
flows aren't segregated based on sender domain.


-kgd

Re: training bayes database

[Matthew Broadhead]

On 09/05/18 16:03, Reio Remma wrote:

On 09.05.18 16:59, Matthew Broadhead wrote:
setting log_level and sa_debug in /etc/amavisd/amavisd.conf didn't 
seem to make any difference. should i be doing it in 
/etc/mail/spamassassin/local.cf?


See if $sa_debug=1 works (for full debug)? (and restart amavisd).

Reio
ok now i am getting a lot of output.  what am i looking for in 
particular?  is it safe to post those logs on here?


I would grep through it looking for error, fail, warn and bayes. :)

Reio



ok i am getting output for bayes using
tail -f /var/log/maillog | grep bayes

May  9 15:25:07 ns1 amavis[15270]: (15270-01) SA dbg: bayes: database 
connection established
May  9 15:25:07 ns1 amavis[15270]: (15270-01) SA dbg: bayes: found bayes 
db version 3

May  9 15:25:07 ns1 amavis[15270]: (15270-01) SA dbg: bayes: Using userid: 1
May  9 15:25:07 ns1 amavis[15270]: (15270-01) SA dbg: bayes: corpus 
size: nspam = 32226, nham = 440969


then i get loads of
 SA dbg: bayes: header tokens for
and
SA dbg: bayes: token

it looks like it is working.  so maybe it is just not flagging or moving 
the spam?

Re: Invoice phish

[David Jones]

On 05/09/2018 10:02 AM, Alex wrote:

Hi,


One more thing.  I have expanded my definition of FREEMAIL to any Google and
Office 365 senders like this:

header  __RCVD_YAHOOReceived =~ /\.yahoo\.com \[/
header  __RCVD_HOTMAIL  Received =~ /\.hotmail\.com \[/
header  __RCVD_GOOGLE   Received =~ /\.google\.com \[/
header  __RCVD_OFFICE365Received =~
/\.outbound\.protection\.outlook\.com \[/
header  __RCVD_COX_NET  Received =~ /\.cox\.net \[/
header  __RCVD_RR_COM   Received =~ /\.rr\.com \[/
header  __RCVD_CHARTER_NET  Received =~ /\.charter\.net \[/
header  __RCVD_COMCAST_NET  Received =~ /\.comcast\.net \[/
header  __RCVD_CENTURYLINK_NET  Received =~ /\.onyx\.syn-alias\.com
\[/
header  __RCVD_HUGHES_NET   Received =~ /\(mx\.hughes\.net \[/

meta__RCVD_FREEMAIL (__RCVD_YAHOO || __RCVD_HOTMAIL ||
__RCVD_GOOGLE || __RCVD_OFFICE365 || __RCVD_COX_NET || __RCVD_CHARTER_NET ||
__RCVD_COMCAST_NET || __RCVD_RR_COM || __RCVD_CENTURYLINK_NET ||
__RCVD_HUGHES_NET)

metaENA_FREEMAIL(FREEMAIL_FROM || FREEMAIL_REPLYTO
|| FREEMAIL_FORGED_REPLYTO || __RCVD_FREEMAIL)
score   ENA_FREEMAIL0.2

Then I use the ENA_FREEMAIL rule in meta rules to bump up the sensitivity of
mail passing through these sources just like other non-trusted FREEMAIL.


What's the difference between creating new header rules for these or
just adding the domains to the freemail_domains list?



The freemail list are domains from any source.  My rules above are the 
opposite with any domains from/through specific sources that are 
commonly abused.


Microsoft allows customers to sign up an trial O365 potentially abusing 
their platform sending out junk/spam on their own domain.  It would be 
impossible to add every potential domain on the Microsoft platform to 
the freemail domains list.




Wouldn't we want to just add them to SA proper so everyone has them?



If enough people think this is a good idea, we could open a feature 
request to do this properly where any MTA header could be parsed by SA, 
not just Postfix-style Received headers.  Maybe there is already 
something in SA that is very close that can be easily extended.


--
David Jones

Re: training bayes database

[John Hardin]

On Wed, 9 May 2018, Matthew Broadhead wrote:


[root@ns1 ~]# sudo -H -u amavis bash -c '/usr/bin/sa-learn --dump magic'
0.000  0  3  0  non-token data: bayes db version
0.000  0  32225  0  non-token data: nspam
0.000  0 440420  0  non-token data: nham


So you have a bunch of stuff trained, biased towards ham.


(3)

your message has

X-Spam-Status: No, score=-18.15 tagged_above=-999 required=6.2
    tests=[AM.WBL=-3, BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25,


BAYES_00 - bayes *is* working and *is* seeing the trained data.

Can you provide the X-Spam-Status from an obvious spam that got through, 
for comparison?



    MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001,
    URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5]


Side note: you will want to set up a local recursive (NON-FORWARDING!!!) 
DNS server for the MTA's use so you avoid the URIBL_BLOCKED issue. That 
will help quite a lot.



    autolearn=ham autolearn_force=no

(4)

around 50 users.  they are all working in same industry


OK, that's small enough that manual training should not be an issue.

Speculation:

Autotrain has stongly biased your database towards ham.

I *assume* you didn't collect a manual initial training corpus, that you 
just turned on autotrain and let it run from scratch, and that you have no 
manual corpus available to evaluate and verify the ham/spam 
classification.


Recommendation:

(1) Turn off autotrain and autoexpire
(2) Collect and manually review several hundred ham and spam messages and 
do initial retraining from scratch using them

(3) Review Bayes performance
(4) Going forward, train using misses (e.g. a spam with BAYES < 50, or a 
ham with BAYES > 50) - add them to your retained training corpus


You may be able to recruit some clueful, responsible users to help with 
the training, but make sure you review what they submit unless you 
*really* trust their judgement.





On 08/05/18 21:08, John Hardin wrote:

On Tue, 8 May 2018, Matthew Broadhead wrote:

system setup centos-release-7-4.1708.el7.centos.x86_64, 
spamassassin-3.4.0-2.el7.x86_64, amavisd-new-2.11.0-3.el7.noarch


/etc/mail/spamassassin/local.cf:
required_hits 5
report_safe 0
rewrite_header Subject [SPAM]

use_bayes  1
bayes_auto_learn   1
bayes_auto_expire  1

# Store bayesian data in MySQL
bayes_store_module Mail::SpamAssassin::BayesStore::MySQL
bayes_sql_dsn       DBI:mysql:sa_bayes:localhost:3306

it is storing the info to the database ok.  but it doesn't seem to be 
filtering any mail.


(1) What is the output of: /usr/bin/sa-learn --dump magic

(2) What user are you running sa-learn as for training, and what user is 
spamd running as?


(3) Are you seeing any BAYES_nn rule hits on messages at all, on either ham 
or spam?


(4) How large is your environment (rough # and diversity of users)?

I'm not familiar with SQL Bayes, others may have other 
questions/recommendations.


Some general comments:

I don't recommend using auto-learn for initial bayes training at least, 
particularly in smaller environments. Manual initial training with careful 
review, followed by manual training of misclassifications after review, is 
more reliable. Others may offer different advice, particularly for large 
installs with a diverse user community (which I don't manage).


Always keep your training corpora so that you can review and fix training 
errors, and wipe and retrain from scratch if Bayes goes completely off the 
rails for some reason.


If you're not auto-learning, auto-expire is not needed. If you *are*, it's 
recommended to expire from a scheduled job rather than take the hit from 
spamd.






--
 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
---
  Your mouse has moved. Your Windows Operating System must be
  relicensed due to this hardware change. Please contact Microsoft
  to obtain a new activation key. If this hardware change results in
  added functionality you may be subject to additional license fees.
  Your system will now shut down. Thank you for choosing Microsoft.
---
 405 days since the first commercial re-flight of an orbital booster (SpaceX)

Re: training bayes database

[Reio Remma]

> On 9 May 2018, at 18:33, John Hardin  wrote:
> 
> Also:
> 
>> On Wed, 9 May 2018, Matthew Broadhead wrote:
>> 
>> your message has
>> 
>> X-Spam-Status: No, score=-18.15 tagged_above=-999 required=6.2
> 
> Setting the threshold higher will result in more spam getting through. The 
> scores calculated by the masscheck processes are based on the assumption that 
> the threshold is set to 5.0
> 
> Is there some specific reason you set the threshold higher than 5.0?

IIRC 6.2 is the default in amavisd in CentOS 7.

Reio

Re: training bayes database

[John Hardin]

On Wed, 9 May 2018, Reio Remma wrote:


On 9 May 2018, at 18:33, John Hardin  wrote:

Also:


On Wed, 9 May 2018, Matthew Broadhead wrote:

your message has

X-Spam-Status: No, score=-18.15 tagged_above=-999 required=6.2


Setting the threshold higher will result in more spam getting through. The 
scores calculated by the masscheck processes are based on the assumption that 
the threshold is set to 5.0

Is there some specific reason you set the threshold higher than 5.0?


IIRC 6.2 is the default in amavisd in CentOS 7.


Ah. Ok.

That's odd. I would presume Amavis has some mechanism to compensate for 
that.


--
 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
---
  Your mouse has moved. Your Windows Operating System must be
  relicensed due to this hardware change. Please contact Microsoft
  to obtain a new activation key. If this hardware change results in
  added functionality you may be subject to additional license fees.
  Your system will now shut down. Thank you for choosing Microsoft.
---
 405 days since the first commercial re-flight of an orbital booster (SpaceX)

Re: Invoice phish

[Alex]

Hi,

>> https://pastebin.com/raw/TfvhUu0X
>>
...
> What I have had to do is basically increase the score on all invoice emails
> to try to block the bad ones and then whitelist the good ones.
>
> That email was BCC'd which is another suspicious trait which is why I bump
> up the score for MISSING HEADERS.  I have other ways to penalize these
> emails at SMTP time based on the number of BCC'd recipients if this were
> received by my servers but I can't tell after the fact like this.

Yes, we've similarly created rules for missing headers.

> There is so much junk coming out of Office 365 right now from compromised
> accounts and otherwise that it's really hard to accurately filtering O365
> email.  I have created a rule based on the X-OriginatorOrg: header to start
> subtracting points for known OK senders and then bumping up other rule hits
> like invoice-related ones that come from O365.  I know this doesn't help
> with compromised accounts in known OK Orgs but it definitely cuts down the
> majority of the fake invoice emails.
>
> header  __RCVD_OFFICE365Received =~
> /\.outbound\.protection\.outlook\.com \[/
> header  __RCVD_OFFICE365_PROXY  X-ClientProxiedBy =~ /\.outlook\.com
> \(/
>
> header  __OFFICE365_TRUST_ORG   X-OriginatorOrg =~
> /^(ena\.com|example\.com)/

You've set this to be your local system, but what if the mail relay
does not process outbound email? What are legitimate values for this
header?

In other words, is this helpful if your mail relay doesn't process
your outbound mail?

Re: Invoice phish

[David Jones]

On 05/09/2018 03:03 AM, Rupert Gallagher wrote:

Is O365 freemail now? Free from Microsoft is an oxymoron.


If you look at the comments in the rule files (20_freemail_domains.cf) 
you will find that FREEMAIL is actually any mail provider that is 
commonly abused and often sends spam.  O365 does fall into this category.


--
David Jones

Re: Mysterious false positives in inbox

[Reio Remma]

Wild stab - maybe they're entering the system already with ***SPAM*** in 
the subject?


With amavisd-new it's amavisd that modifies the subject, local.cf 
shouldn't have an effect on that.


Good luck,
Reio

On 09.05.18 14:02, Eggert Ehmke wrote:


Hello,

I have spamassassin 3.4.1 / amavisd / postfix / dovecot installed on 
my Debian 9.4 server. I also run a mailman mailing list. Most of the 
time, all runs very well, but occasionally I get mails marked 
***SPAM*** in my inbox. These are indeed no spam, but valid mails 
forwarded by mailman. Training seems to have no effect.


The mails in question have those header entries:

X-Virus-Scanned: Debian amavisd-new at 

X-Spam-Flag: NO

X-Spam-Score: -1

X-Spam-Level:

X-Spam-Status: No, score=-1 tagged_above=-999 required=3 
tests=[ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001] autolearn=disabled


With those entries, why is the ***SPAM*** put into the subject line??

In /etc/spamassassin/local.cf are these entries:

rewrite_header Subject ***SPAM*** report_safe 0 trusted_networks of my other server> required_score 2.0 use_bayes 1 bayes_auto_learn 1 
ifplugin Mail::SpamAssassin::Plugin::Shortcircuit shortcircuit 
ALL_TRUSTED on endif # 
Mail::SpamAssassin::Plugin::Shortcircuit Any idea?


Eggert

Re: training bayes database

[Matthew Broadhead]

On 09/05/18 15:48, Reio Remma wrote:

On 09.05.18 16:33, Matthew Broadhead wrote:

On 08/05/18 21:53, Reio Remma wrote:

On 08.05.2018 22:08, John Hardin wrote:

On Tue, 8 May 2018, Matthew Broadhead wrote:

system setup centos-release-7-4.1708.el7.centos.x86_64, 
spamassassin-3.4.0-2.el7.x86_64, amavisd-new-2.11.0-3.el7.noarch


/etc/mail/spamassassin/local.cf:
required_hits 5
report_safe 0
rewrite_header Subject [SPAM]

use_bayes  1
bayes_auto_learn   1
bayes_auto_expire  1

# Store bayesian data in MySQL
bayes_store_module Mail::SpamAssassin::BayesStore::MySQL
bayes_sql_dsn   DBI:mysql:sa_bayes:localhost:3306

it is storing the info to the database ok.  but it doesn't seem to 
be filtering any mail.


(1) What is the output of: /usr/bin/sa-learn --dump magic

(2) What user are you running sa-learn as for training, and what 
user is spamd running as?


(3) Are you seeing any BAYES_nn rule hits on messages at all, on 
either ham or spam?


You'll probably need to look at your amavisd-new config.

To debug SpamAssassin via amavisd, you need to set the following in 
amavisd.conf and then look at what's happening in /var/log/maillog


$log_level = 5;
$sa_debug = '1,bayes';

By not filtering do you mean bayes specifically isn't working, 
SpamAssassin in general isn't working via amavisd-new or ...?


Good luck,
Reio


setting log_level and sa_debug in /etc/amavisd/amavisd.conf didn't 
seem to make any difference.  should i be doing it in 
/etc/mail/spamassassin/local.cf?


See if $sa_debug=1 works (for full debug)? (and restart amavisd).

Reio
ok now i am getting a lot of output.  what am i looking for in 
particular?  is it safe to post those logs on here?

Re: training bayes database

[Reio Remma]

On 09.05.18 16:59, Matthew Broadhead wrote:
setting log_level and sa_debug in /etc/amavisd/amavisd.conf didn't 
seem to make any difference. should i be doing it in 
/etc/mail/spamassassin/local.cf?


See if $sa_debug=1 works (for full debug)? (and restart amavisd).

Reio
ok now i am getting a lot of output.  what am i looking for in 
particular?  is it safe to post those logs on here?


I would grep through it looking for error, fail, warn and bayes. :)

Reio

Mysterious false positives in inbox

[Eggert Ehmke]

Hello, 

I have spamassassin 3.4.1 / amavisd / postfix / dovecot installed on my Debian 
9.4 server. I 
also run a mailman mailing list. Most of the time, all runs very well, but 
occasionally I get 
mails marked ***SPAM*** in my inbox. These are indeed no spam, but valid mails 
forwarded by mailman. Training seems to have no effect.

The mails in question have those header entries:
X-Virus-Scanned: Debian amavisd-new at 
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 tagged_above=-999 required=3 tests=[ALL_TRUSTED=-1, 
SHORTCIRCUIT=-0.0001] autolearn=disabled

With those entries, why is the ***SPAM*** put into the subject line??

In /etc/spamassassin/local.cf are these entries:

rewrite_header Subject ***SPAM*** 

Eggert

Re: Mysterious false positives in inbox

[Eggert Ehmke]

The mail also originated from the same server.
 Ok, I look into the amavisd config.

Thanks,
Eggert

Am Mittwoch, 9. Mai 2018, 14:06:08 CEST schrieb Reio Remma:
> Wild stab - maybe they're entering the system already with ***SPAM*** in
> the subject?
> 
> With amavisd-new it's amavisd that modifies the subject, local.cf
> shouldn't have an effect on that.
> 
> Good luck,
> Reio
> 
> On 09.05.18 14:02, Eggert Ehmke wrote:
> > Hello,
> > 
> > I have spamassassin 3.4.1 / amavisd / postfix / dovecot installed on
> > my Debian 9.4 server. I also run a mailman mailing list. Most of the
> > time, all runs very well, but occasionally I get mails marked
> > ***SPAM*** in my inbox. These are indeed no spam, but valid mails
> > forwarded by mailman. Training seems to have no effect.
> > 
> > The mails in question have those header entries:
> > 
> > X-Virus-Scanned: Debian amavisd-new at 
> > 
> > X-Spam-Flag: NO
> > 
> > X-Spam-Score: -1
> > 
> > X-Spam-Level:
> > 
> > X-Spam-Status: No, score=-1 tagged_above=-999 required=3
> > tests=[ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001] autolearn=disabled
> > 
> > With those entries, why is the ***SPAM*** put into the subject line??
> > 
> > In /etc/spamassassin/local.cf are these entries:
> > 
> > rewrite_header Subject ***SPAM*** report_safe 0 trusted_networks  > of my other server> required_score 2.0 use_bayes 1 bayes_auto_learn 1
> > ifplugin Mail::SpamAssassin::Plugin::Shortcircuit shortcircuit
> > ALL_TRUSTED on endif #
> > Mail::SpamAssassin::Plugin::Shortcircuit Any idea?
> > 
> > Eggert

Re: training bayes database

[Reio Remma]

On 09.05.18 16:33, Matthew Broadhead wrote:

On 08/05/18 21:53, Reio Remma wrote:

On 08.05.2018 22:08, John Hardin wrote:

On Tue, 8 May 2018, Matthew Broadhead wrote:

system setup centos-release-7-4.1708.el7.centos.x86_64, 
spamassassin-3.4.0-2.el7.x86_64, amavisd-new-2.11.0-3.el7.noarch


/etc/mail/spamassassin/local.cf:
required_hits 5
report_safe 0
rewrite_header Subject [SPAM]

use_bayes  1
bayes_auto_learn   1
bayes_auto_expire  1

# Store bayesian data in MySQL
bayes_store_module Mail::SpamAssassin::BayesStore::MySQL
bayes_sql_dsn   DBI:mysql:sa_bayes:localhost:3306

it is storing the info to the database ok.  but it doesn't seem to 
be filtering any mail.


(1) What is the output of: /usr/bin/sa-learn --dump magic

(2) What user are you running sa-learn as for training, and what 
user is spamd running as?


(3) Are you seeing any BAYES_nn rule hits on messages at all, on 
either ham or spam?


You'll probably need to look at your amavisd-new config.

To debug SpamAssassin via amavisd, you need to set the following in 
amavisd.conf and then look at what's happening in /var/log/maillog


$log_level = 5;
$sa_debug = '1,bayes';

By not filtering do you mean bayes specifically isn't working, 
SpamAssassin in general isn't working via amavisd-new or ...?


Good luck,
Reio


setting log_level and sa_debug in /etc/amavisd/amavisd.conf didn't 
seem to make any difference.  should i be doing it in 
/etc/mail/spamassassin/local.cf?


See if $sa_debug=1 works (for full debug)? (and restart amavisd).

Reio

Re: training bayes database

[Matthew Broadhead]

On 08/05/18 21:53, Reio Remma wrote:

On 08.05.2018 22:08, John Hardin wrote:

On Tue, 8 May 2018, Matthew Broadhead wrote:

system setup centos-release-7-4.1708.el7.centos.x86_64, 
spamassassin-3.4.0-2.el7.x86_64, amavisd-new-2.11.0-3.el7.noarch


/etc/mail/spamassassin/local.cf:
required_hits 5
report_safe 0
rewrite_header Subject [SPAM]

use_bayes  1
bayes_auto_learn   1
bayes_auto_expire  1

# Store bayesian data in MySQL
bayes_store_module Mail::SpamAssassin::BayesStore::MySQL
bayes_sql_dsn       DBI:mysql:sa_bayes:localhost:3306

it is storing the info to the database ok.  but it doesn't seem to 
be filtering any mail.


(1) What is the output of: /usr/bin/sa-learn --dump magic

(2) What user are you running sa-learn as for training, and what user 
is spamd running as?


(3) Are you seeing any BAYES_nn rule hits on messages at all, on 
either ham or spam?


You'll probably need to look at your amavisd-new config.

To debug SpamAssassin via amavisd, you need to set the following in 
amavisd.conf and then look at what's happening in /var/log/maillog


$log_level = 5;
$sa_debug = '1,bayes';

By not filtering do you mean bayes specifically isn't working, 
SpamAssassin in general isn't working via amavisd-new or ...?


Good luck,
Reio


setting log_level and sa_debug in /etc/amavisd/amavisd.conf didn't seem 
to make any difference.  should i be doing it in 
/etc/mail/spamassassin/local.cf?

Re: Mysterious false positives in inbox

[Ian Zimmerman]

On 2018-05-09 13:08, Eggert Ehmke wrote:

> > Wild stab - maybe they're entering the system already with
> > ***SPAM*** in the subject?

> The mail also originated from the same server.

All the more reason to suspect the "wild stab" is correct.

In my experience this is quite common on some poorly configured mailing
list servers.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

Re: Invoice phish

[Alex]

Hi,

>>> header  __RCVD_OFFICE365Received =~
>>> /\.outbound\.protection\.outlook\.com \[/
>>> header  __RCVD_OFFICE365_PROXY  X-ClientProxiedBy =~
>>> /\.outlook\.com
>>> \(/
>>>
>>> header  __OFFICE365_TRUST_ORG   X-OriginatorOrg =~
>>> /^(ena\.com|example\.com)/
>>
>>
>> You've set this to be your local system, but what if the mail relay
>> does not process outbound email? What are legitimate values for this
>> header?
>>
>
> I don't have "ena.com" in my own rule.  Rather I have dozens of others
> listed.  Sorry if this is confusing to imply this is for outbound mail.
>
>> In other words, is this helpful if your mail relay doesn't process
>> your outbound mail?
>>
>
> Yes.  It's not meant for outbound but inbound.  I shouldn't have put
> "ena.com" in there for me but you could put it in there for your local rules
> if you think our email is trustworthy.  :)

I think I'm still a little confused. I did a quick search on existing
email received with that header, and it's a hugely varied list with an
equal amount trustworthy as untrustworthy. I don't think it's feasible
to maintain a list of trustworthy domains for this header, unless I'm
missing something?

Also, the youngliving.com domain that was listed in my spample still
isn't blacklisted on any legitimate list. This looks to be a
legitimate domain with a compromised account. You had mentioned your
rules don't really work on compromised accounts from legitimate
domains, but also that it cuts down on invoice spam.

Is this one of those cases where your rules don't really help?





>
> --
> David Jones

Re: training bayes database

[Matthew Broadhead]

On 09/05/18 16:37, Reindl Harald wrote:


Am 09.05.2018 um 16:28 schrieb Matthew Broadhead:

it looks like it is working.  so maybe it is just not flagging or moving
the spam?

in a differnt post you showed this status header which *clearly* shows
bayes is working - bayes alone don't flag, the total socre does, moving
don't happen at all on this layer - other software like sieve is
responsible for acting on the headers of a message

quoting URIBL_BLOCKED is a joke - setup a *recursion* *non-forwarding*
nameserver, no dnsmasq or such crap

http://uribl.com/refused.shtml

with your setup you excedd *obviously* rate-limits and have most
DNSBL/URIBL not working and so you can't expect useful results at all

X-Spam-Status: No, score=-18.15 tagged_above=-999 required=6.2
 tests=[AM.WBL=-3, BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25,
 MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001,
 URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5]
 autolearn=ham autolearn_force=no


i followed the guidance at that url and it gave me
[root@ns1 ~]# host -tTXT 2.0.0.127.multi.uribl.com
2.0.0.127.multi.uribl.com descriptive text "127.0.0.1 -> Query Refused. 
See http://uribl.com/refused.shtml for more information [Your DNS IP: 
213.171.193.134]"


i guess my dns is set to use my isp's dns server.  do i need to set up 
dns relay on my machine so it comes from my ip?


there is no way we send more than 500k emails from our domain so i 
should qualify for the free lookup?

Re: training bayes database

[David Jones]

On 05/09/2018 01:29 PM, Matthew Broadhead wrote:

On 09/05/18 16:37, Reindl Harald wrote:


Am 09.05.2018 um 16:28 schrieb Matthew Broadhead:

it looks like it is working.  so maybe it is just not flagging or moving
the spam?

in a differnt post you showed this status header which *clearly* shows
bayes is working - bayes alone don't flag, the total socre does, moving
don't happen at all on this layer - other software like sieve is
responsible for acting on the headers of a message

quoting URIBL_BLOCKED is a joke - setup a *recursion* *non-forwarding*
nameserver, no dnsmasq or such crap

http://uribl.com/refused.shtml

with your setup you excedd *obviously* rate-limits and have most
DNSBL/URIBL not working and so you can't expect useful results at all

X-Spam-Status: No, score=-18.15 tagged_above=-999 required=6.2
 tests=[AM.WBL=-3, BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25,
 MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001,
 URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5]
 autolearn=ham autolearn_force=no


i followed the guidance at that url and it gave me
[root@ns1 ~]# host -tTXT 2.0.0.127.multi.uribl.com
2.0.0.127.multi.uribl.com descriptive text "127.0.0.1 -> Query Refused. 
See http://uribl.com/refused.shtml for more information [Your DNS IP: 
213.171.193.134]"


i guess my dns is set to use my isp's dns server.  do i need to set up 
dns relay on my machine so it comes from my ip?


there is no way we send more than 500k emails from our domain so i 
should qualify for the free lookup?


Yes.  Setup BIND, unbound, or pdns_recursor on your SA server that is 
not forwarding to another DNS server then set your /etc/resolv.conf or 
SA dns_server to 127.0.0.1.  This will make your DNS queries isolated 
from your IP to stay under their daily limit.


Keep in mind that if your SA box is behind NAT that is not dedicated to 
your server then other DNS queries could get combined with your shared 
public IP.  This is not likely since others are not going to query 
RBL/URIBL servers but it's possible.  If your SA server is directly on 
the Internet as an edge mail gateway then this won't be a problem.


--
David Jones

Re: Mysterious false positives in inbox

[Eggert Ehmke]

Perhaps this is a misunderstanding.  By "same" I mean "this server". The mail 
was originally received by my server via TLS, processed  by mailman and then 
delivered with the ***SPAM*** subject line to the recipients of the mailing 
list, but not to the Quarantine. One of the recipients is my own mailbox. So 
in any case, the poorly configured server is my own.

Am Mittwoch, 9. Mai 2018, 10:35:34 CEST schrieb Ian Zimmerman:
> On 2018-05-09 13:08, Eggert Ehmke wrote:
> > > Wild stab - maybe they're entering the system already with
> > > ***SPAM*** in the subject?
> > 
> > The mail also originated from the same server.
> 
> All the more reason to suspect the "wild stab" is correct.
> 
> In my experience this is quite common on some poorly configured mailing
> list servers.

Re: Invoice phish

[David Jones]

On 05/09/2018 12:39 PM, Alex wrote:

Hi,


header  __RCVD_OFFICE365Received =~
/\.outbound\.protection\.outlook\.com \[/
header  __RCVD_OFFICE365_PROXY  X-ClientProxiedBy =~
/\.outlook\.com
\(/

header  __OFFICE365_TRUST_ORG   X-OriginatorOrg =~
/^(ena\.com|example\.com)/



You've set this to be your local system, but what if the mail relay
does not process outbound email? What are legitimate values for this
header?



I don't have "ena.com" in my own rule.  Rather I have dozens of others
listed.  Sorry if this is confusing to imply this is for outbound mail.


In other words, is this helpful if your mail relay doesn't process
your outbound mail?



Yes.  It's not meant for outbound but inbound.  I shouldn't have put
"ena.com" in there for me but you could put it in there for your local rules
if you think our email is trustworthy.  :)


I think I'm still a little confused. I did a quick search on existing
email received with that header, and it's a hugely varied list with an
equal amount trustworthy as untrustworthy. I don't think it's feasible
to maintain a list of trustworthy domains for this header, unless I'm
missing something?

Also, the youngliving.com domain that was listed in my spample still
isn't blacklisted on any legitimate list. This looks to be a
legitimate domain with a compromised account. You had mentioned your
rules don't really work on compromised accounts from legitimate
domains, but also that it cuts down on invoice spam.

Is this one of those cases where your rules don't really help?



The problem is anything coming out of O365 is not going to show up on 
traditional IP block lists.  Domain block lists (DBLs) are going to be 
very slow to react and list a domain.  SPFBL would help and IVM might 
quickly list them if there were a URL that could be blocked.


My approach is to bump up the score a little on any invoice-related 
emails and then a little more on "freemail/commonly abused" platforms 
where it's a common source of phishing lately.


Then you only have to maintain the X-OriginatorOrg list for a small 
subset of legit invoice sending domains.


For example, let's say your blocking threshold is the SA default of 5.0. 
 Add a point for all freemail/commonly abused platforms so now their 
threshold is effectively 4.0.  Now add another point for invoice-related 
emails bringing the threshold down to 3.0.


Now legit invoice senders will either score low on their own from good 
reputation, get whitelist_auth/whitelist_from_rcvd entries, or get added 
to the X-OriginatorOrg if they come from O365.


Does that make sense?  This has been working well for me the past couple 
of months after seeing many phishing attacks from O365 compromised 
accounts.  I would rather risk slightly over blocking invoices and 
release/whitelist them later than have a customer get phished and cause 
a lot of financial damage.


I have customers that will blindly pay invoices without matching POs or 
any confirmation if the company name sounds familiar.  I am seeing a lot 
of construction-related phishing emails.  Since there is always 
construction going on, they just assume these are legit.


--
David Jones

Re: training bayes database

[Matthew Broadhead]

On 09/05/18 16:37, Reindl Harald wrote:


Am 09.05.2018 um 16:28 schrieb Matthew Broadhead:

it looks like it is working.  so maybe it is just not flagging or moving
the spam?

in a differnt post you showed this status header which *clearly* shows
bayes is working - bayes alone don't flag, the total socre does, moving
don't happen at all on this layer - other software like sieve is
responsible for acting on the headers of a message

quoting URIBL_BLOCKED is a joke - setup a *recursion* *non-forwarding*
nameserver, no dnsmasq or such crap

http://uribl.com/refused.shtml

with your setup you excedd *obviously* rate-limits and have most
DNSBL/URIBL not working and so you can't expect useful results at all

X-Spam-Status: No, score=-18.15 tagged_above=-999 required=6.2
 tests=[AM.WBL=-3, BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25,
 MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001,
 URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5]
 autolearn=ham autolearn_force=no

ah i got it...https://wiki.apache.org/spamassassin/CachingNameserver

Re: Invoice phish

[David B Funk]

On Wed, 9 May 2018, Vincent Fox wrote:


I see an interesting dichotomy.
Students are on Google, fac/staff on O365 now.

Guess which group is phished most often?

If you said students,  bzzzt. 

It’s the O365 users, by a large margin.  Faculty and staff should be best 
trained.  Also protected by “Advanced Threat Protection”.


Our university drank the Microsoft Kool-Aid completely and threw everybody into 
the O-365 ocean. (except for us already entrenched hold-outs ;).


We've seen a major up-tick of phished O-365 accounts of all flavors (faculty, 
staff, students).


I attribute it to several factors:
1) phish attacks have become increasingly sophisticated (quality of duplicating 
'sign in' sites, looking a institutional service announcements so they can craft 
credible decptive scenarios, etc).


2) the 'Outlook' mail client hides technical details of messages and makes it 
hard to determine the validity of a messages


3) O-365/Exchange has a "Big Brother" attitude to RFC mail info, it wants to 
'bowdlerize' those ugly messages and replace them with simplistic, soothing 
verbiage to not confuse the end users.


4) Less technical sophistication of the server side filtering VS google.

--
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: Invoice phish

[Vincent Fox]

I see an interesting dichotomy.

Students are on Google, fac/staff on O365 now.

Guess which group is phished most often?

If you said students,  bzzzt.

It’s the O365 users, by a large margin.  Faculty and staff should be best 
trained.  Also protected by “Advanced Threat Protection”.

Sent from my iPhone

On May 9, 2018, at 14:23, Rupert Gallagher 
> wrote:

So "free" here refers to something else than paid for service. What does it 
refer to then? Perhaps FREEMAIL is best renamed as CAMP, for Commonly Abused 
Mail Provider.


On Wed, May 9, 2018 at 13:37, David Jones 
> wrote:
On 05/09/2018 03:03 AM, Rupert Gallagher wrote: > Is O365 freemail now? Free 
from Microsoft is an oxymoron. If you look at the comments in the rule files 
(20_freemail_domains.cf) you will find that FREEMAIL is actually any mail 
provider that is commonly abused and often sends spam. O365 does fall into this 
category. -- David Jones

Re: Invoice phish

[Rupert Gallagher]

So "free" here refers to something else than paid for service. What does it 
refer to then? Perhaps FREEMAIL is best renamed as CAMP, for Commonly Abused 
Mail Provider.

On Wed, May 9, 2018 at 13:37, David Jones  wrote:

> On 05/09/2018 03:03 AM, Rupert Gallagher wrote: > Is O365 freemail now? Free 
> from Microsoft is an oxymoron. If you look at the comments in the rule files 
> (20_freemail_domains.cf) you will find that FREEMAIL is actually any mail 
> provider that is commonly abused and often sends spam. O365 does fall into 
> this category. -- David Jones