Re: sa-compile will not configure

[Ian Zimmerman]

On 2017-04-20 17:31, Robert Steinmetz AIA wrote:

> >>> thelma@thelma:~$ echo $PATH

BTW, do you have any connection to the Thelma who's asking a constant
stream of close-to-newbie questions in the Gentoo user mailing list?

It's not that common a name, so forgive me for the short-circuit in my
brain :-)

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign:
http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html

Re: False Positives from yahoo due to FORGED_MUA_MOZILLA

[Lyle Evans]

At 01:00 PM 4/20/2017, John Hardin wrote:

On Thu, 20 Apr 2017, Merijn van den Kroonenberg wrote:


On Thu, 20 Apr 2017 10:41:21 -0400
Lyle Evans wrote:


I have been getting false positives from Yahoo due to
FORGED_MUA_MOZILLA hitting on a new X-Mailer line added by Yahoo
about 3/31/17

The X-Mailer line reads:

X-Mailer: WebService/1.1.9272 YahooMailNeo Mozilla/5.0 (Windows NT
10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/56.0.2924.87 Safari/537.36

/DCE\)/

My guess is that they are including the http user-agent header of the
browser that connected to their webmail server.


Correct, I also noticed this a few days ago. Maybe the rule could be
changed to exclude yahoo...but maybe other webmail applications do this
too, not sure.


Excluding when verified from Yahoo would be the proper approach.


I added && !__FROM_YAHOO_COM (from 20_headers.cf) to FORGED_MUA_MOZILLA
giving

FORGED_MUA_MOZILLA (__MOZILLA_MUA && !__UNUSABLE_MSGID && 
!__MOZILLA_MSGID && !__FROM_YAHOO_COM )


I am testing that now,
any comments or suggestions for improvement are welcome.

Lyle Evans


Unfortunately masscheck is down for migration so any global fix 
won't go out anytime soon...



--
 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



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: False Positives from yahoo due to FORGED_MUA_MOZILLA

[Lyle Evans]

At 01:00 PM 4/20/2017, John Hardin wrote:

On Thu, 20 Apr 2017, Merijn van den Kroonenberg wrote:


On Thu, 20 Apr 2017 10:41:21 -0400
Lyle Evans wrote:


I have been getting false positives from Yahoo due to
FORGED_MUA_MOZILLA hitting on a new X-Mailer line added by Yahoo
about 3/31/17

The X-Mailer line reads:

X-Mailer: WebService/1.1.9272 YahooMailNeo Mozilla/5.0 (Windows NT
10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/56.0.2924.87 Safari/537.36

/DCE\)/

My guess is that they are including the http user-agent header of the
browser that connected to their webmail server.


Correct, I also noticed this a few days ago. Maybe the rule could be
changed to exclude yahoo...but maybe other webmail applications do this
too, not sure.


Excluding when verified from Yahoo would be the proper approach.


I added && !__FROM_YAHOO_COM (from 20_headers.cf) to FORGED_MUA_MOZILLA
giving

FORGED_MUA_MOZILLA (__MOZILLA_MUA && !__UNUSABLE_MSGID && 
!__MOZILLA_MSGID && !__FROM_YAHOO_COM )


I am testing that now,
any comments or suggestions for improvement are welcome.

Lyle Evans


Unfortunately masscheck is down for migration so any global fix 
won't go out anytime soon...



--
 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




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: sa-compile will not configure

[Robert Steinmetz AIA]

Thank you Bill,

I checked all of the permissions at every level, they were all 755 
except for as noted, which I changed. to 755

It works now.

I'll re-check this in the morning and run security scans to make sure 
everything is tied down..


I appreciate your help.


Bill Cole wrote:

On 20 Apr 2017, at 16:16, Robert Steinmetz AIA wrote:


Thank you Bill,

That has given me a clue. I ran the commands below:


thelma@thelma:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games:/usr/local/games:/snap/bin 



thelma@thelma:~$ ls -ld /usr/local/sbin
drwxr-xr-x 2 root root 48 Mar 11  2007 /usr/local/sbin

thelma@thelma:~$ ls -ld /usr/local/bin
drwxr-xr-x 2 root root 48 Mar 11  2007 /usr/local/bin


OK, it MAY be that perl is also looking up the tree. If /usr/local is 
world-writable, then these 2 effectively are also (since they could be 
renamed and replaced with evil twins.)




thelma@thelma:~$ ls -ld /usr/sbin
drwxr-xr-x 2 root root 11752 Apr 18 13:06 /usr/sbin

thelma@thelma:~$ ls -ld /usr/bin
drwxr-xr-x 4 root root 72872 Apr 18 16:44 /usr/bin


The above note about /usr/local also applies to /usr


thelma@thelma:~$ ls -ld /usr/sbin
drwxr-xr-x 2 root root 11752 Apr 18 13:06 /usr/sbin


I think you meant /sbin here.


thelma@thelma:~$ ls -ld /bin
drwxrwxrwx 3 root root 4352 Apr 15 19:06 /bin


That's a problem. Enough of a problem that if this system has any 
other users who could have logged in OR any remote-accessible services 
that might be attack paths, you should reload from bare metal. Having 
/bin (or /sbin, /usr/bin, or /usr/sbin) world-writable essentially 
hands over control to anyone who knows about the flaw, wants the 
machine, and has some way to get in.


I have no idea how /bin could have become world-writable short of 
administrative malpractice or a prior malicious system compromise.



 ls -ld /usr/bin/X11
lrwxrwxrwx 1 root root 1 Mar 11  2007 /usr/bin/X11 -> .


That's a weird Ubuntu (or Debian?) quirk. It shouldn't be necessary 
but it probably shouldn't be fiddled with either, except maybe to 
'chmod -h o-w /usr/bin/X11' (to remove the world-writable permission 
from the symlink.)



ls -ld /usr/games
drwxr-xr-x 2 root root 784 Apr 15 18:17 /usr/games

ls -ld /usr/local/games
drwxr-xr-x 2 root root 48 Mar 11  2007 /usr/local/games

ls -ld /snap/bin
ls: cannot access '/snap/bin': No such file or directory

Note that /snap/bin doesn't exist and  /usr/bin/X11 links to "."

I added  /snap/bin as an empty directory but it still fails


I've not seen that in a default $PATH. Is it something you use 
locally? Here again, the permissions of directories up to the root MAY 
be taken into account by perl for untainting purposes, I'm not sure. 
There's  no sound reason for /, /usr, or any directory whose contents 
you care about to be world-writable without the "sticky" bit set (as 
with /tmp and /var/tmp) so you could safely do this:


   chmod -h o-w $( echo $PATH | tr ':' ' ' )





--
Rob

Re: False Positives from yahoo due to FORGED_MUA_MOZILLA

[John Hardin]

On Thu, 20 Apr 2017, Lyle Evans wrote:


At 01:00 PM 4/20/2017, John Hardin wrote:

On Thu, 20 Apr 2017, Merijn van den Kroonenberg wrote:

> > On Thu, 20 Apr 2017 10:41:21 -0400
> > Lyle Evans wrote:
> > 
> > > I have been getting false positives from Yahoo due to

> > > FORGED_MUA_MOZILLA hitting on a new X-Mailer line added by Yahoo
> > > about 3/31/17
> > > 
> > > The X-Mailer line reads:
> > > 
> > > X-Mailer: WebService/1.1.9272 YahooMailNeo Mozilla/5.0 (Windows NT

> > > 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
> > > Chrome/56.0.2924.87 Safari/537.36
> > /DCE\)/
> > 
> > My guess is that they are including the http user-agent header of the

> > browser that connected to their webmail server.
> 
> Correct, I also noticed this a few days ago. Maybe the rule could be

> changed to exclude yahoo...but maybe other webmail applications do this
> too, not sure.

Excluding when verified from Yahoo would be the proper approach.


I added && !__FROM_YAHOO_COM (from 20_headers.cf) to FORGED_MUA_MOZILLA
giving

FORGED_MUA_MOZILLA (__MOZILLA_MUA && !__UNUSABLE_MSGID && 
!__MOZILLA_MSGID && !__FROM_YAHOO_COM )


I am testing that now,
any comments or suggestions for improvement are welcome.


My concern would be how easy it might be to spoof __FROM_YAHOO_COM (which 
I'm not at the moment going evaluate...) If it's a basic "From header 
includes 'yahoo.com'" rule (which is what the name suggests), you might 
want to create a meta of __FROM_YAHOO_COM && (__SPF_PASS || __DKIM_PASS) 
(rule names from memory, that's only to suggest the approach) and then use 
that instead of the bare __FROM_YAHOO_COM.


--
 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
---
  Campuses today are a theatrical mashup of
  1984 and Lord of the Flies, performed by people
  who don't understand these references.   -- David Burge
---
 3 days until Max Planck's 159th birthday

Re: sa-compile will not configure

[Martin Gregorie]

On Thu, 2017-04-20 at 17:07 -0400, Bill Cole wrote:

If your distro has an rkhunter package available, then I'd recommend
that you install it. Once you're happy that your system clean, do its
initial update "rkhunter --propupt" and thereafter make sure its run as
a daily cronjob. This way you should see warnings in your logwatch
report if unexpected changes happen.

The only downside that I've noticed is that you'll probably need to
rerun it in --propupd mode after each system upgrade, but that can be
at least partially automated.


Martin
 

Re: sa-compile will not configure

[Bill Cole]

On 20 Apr 2017, at 16:16, Robert Steinmetz AIA wrote:


Thank you Bill,

That has given me a clue. I ran the commands below:


thelma@thelma:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games:/usr/local/games:/snap/bin

thelma@thelma:~$ ls -ld /usr/local/sbin
drwxr-xr-x 2 root root 48 Mar 11  2007 /usr/local/sbin

thelma@thelma:~$ ls -ld /usr/local/bin
drwxr-xr-x 2 root root 48 Mar 11  2007 /usr/local/bin


OK, it MAY be that perl is also looking up the tree. If /usr/local is 
world-writable, then these 2 effectively are also (since they could be 
renamed and replaced with evil twins.)




thelma@thelma:~$ ls -ld /usr/sbin
drwxr-xr-x 2 root root 11752 Apr 18 13:06 /usr/sbin

thelma@thelma:~$ ls -ld /usr/bin
drwxr-xr-x 4 root root 72872 Apr 18 16:44 /usr/bin


The above note about /usr/local also applies to /usr


thelma@thelma:~$ ls -ld /usr/sbin
drwxr-xr-x 2 root root 11752 Apr 18 13:06 /usr/sbin


I think you meant /sbin here.


thelma@thelma:~$ ls -ld /bin
drwxrwxrwx 3 root root 4352 Apr 15 19:06 /bin


That's a problem. Enough of a problem that if this system has any other 
users who could have logged in OR any remote-accessible services that 
might be attack paths, you should reload from bare metal. Having /bin 
(or /sbin, /usr/bin, or /usr/sbin) world-writable essentially hands over 
control to anyone who knows about the flaw, wants the machine, and has 
some way to get in.


I have no idea how /bin could have become world-writable short of 
administrative malpractice or a prior malicious system compromise.



 ls -ld /usr/bin/X11
lrwxrwxrwx 1 root root 1 Mar 11  2007 /usr/bin/X11 -> .


That's a weird Ubuntu (or Debian?) quirk. It shouldn't be necessary but 
it probably shouldn't be fiddled with either, except maybe to 'chmod -h 
o-w /usr/bin/X11' (to remove the world-writable permission from the 
symlink.)



ls -ld /usr/games
drwxr-xr-x 2 root root 784 Apr 15 18:17 /usr/games

ls -ld /usr/local/games
drwxr-xr-x 2 root root 48 Mar 11  2007 /usr/local/games

ls -ld /snap/bin
ls: cannot access '/snap/bin': No such file or directory

Note that /snap/bin doesn't exist and  /usr/bin/X11 links to "."

I added  /snap/bin as an empty directory but it still fails


I've not seen that in a default $PATH. Is it something you use locally? 
Here again, the permissions of directories up to the root MAY be taken 
into account by perl for untainting purposes, I'm not sure. There's  no 
sound reason for /, /usr, or any directory whose contents you care about 
to be world-writable without the "sticky" bit set (as with /tmp and 
/var/tmp) so you could safely do this:


   chmod -h o-w $( echo $PATH | tr ':' ' ' )

Re: sa-compile will not configure

[Robert Steinmetz AIA]

  
  
Reindl Harald wrote:


  just ask your distribution how they broke your environment
  
  
  this is *not* a spamassassin issue and all the stuuf you do abvoe
  is not supposed to make things better - how do you imagine "I
  deleted the /usr/bin/X11 link and created a new directory
  /usr/bin/X11 but it still failed" has any relation to
  spamassassin?
  

While not a direct Spamassassin issue Sapmassassin is the only
package this problem affects, every other package configures
properly.. It is ultimately a perl issue, but as Bill Cole helpfully
wrote:
The sa-compile script DOES use a SA utility
  function to untaint the whole %ENV hash, but there's a special
  catch for $ENV{'PATH'}: if any directories included are not
  absolute (e.g. commonly '.' and '~/bin') OR are writable by more
  than their owning user & group, $ENV{'PATH'} remains tainted
  and won't be used or passed to child processes. Often a bad
member directory is unobvious because it is a symlink name and
symlinks are usually technically mode 777 because the system
  doesn't use the mode of a symlink itself.
  

I was checking to see if all of the directories in $PATH were OK.. I
posted the entire results of those tests to allow someone more
knowledgeable than I am about Spamassassin and perl to see if there
was another problem. 

The reason for deleting and reinstalling  /usr/bin/X!1 was to test
is a Bill Cole's suggestion that a symbolic link might be the cause
of the issue, I think I've shown it's not.

Which links back to specific Spamassassin code. Determining why that
code is not functioning correctly is the route to solving the whole
problem. If it turns out the Spamassassin code its to blame then it
is a Spamassassin issue.


  

Re: sa-compile will not configure

[Robert Steinmetz AIA]

Thank you Bill,

That has given me a clue. I ran the commands below:


thelma@thelma:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games:/usr/local/games:/snap/bin

thelma@thelma:~$ ls -ld /usr/local/sbin
drwxr-xr-x 2 root root 48 Mar 11  2007 /usr/local/sbin

thelma@thelma:~$ ls -ld /usr/local/bin
drwxr-xr-x 2 root root 48 Mar 11  2007 /usr/local/bin

thelma@thelma:~$ ls -ld /usr/sbin
drwxr-xr-x 2 root root 11752 Apr 18 13:06 /usr/sbin

thelma@thelma:~$ ls -ld /usr/bin
drwxr-xr-x 4 root root 72872 Apr 18 16:44 /usr/bin

thelma@thelma:~$ ls -ld /usr/sbin
drwxr-xr-x 2 root root 11752 Apr 18 13:06 /usr/sbin

thelma@thelma:~$ ls -ld /bin
drwxrwxrwx 3 root root 4352 Apr 15 19:06 /bin

 ls -ld /usr/bin/X11
lrwxrwxrwx 1 root root 1 Mar 11  2007 /usr/bin/X11 -> .

ls -ld /usr/games
drwxr-xr-x 2 root root 784 Apr 15 18:17 /usr/games

ls -ld /usr/local/games
drwxr-xr-x 2 root root 48 Mar 11  2007 /usr/local/games

ls -ld /snap/bin
ls: cannot access '/snap/bin': No such file or directory

Note that /snap/bin doesn't exist and  /usr/bin/X11 links to "."

I added  /snap/bin as an empty directory but it still fails

thelma@thelma:/usr/bin$ ls -ld /snap/bin
drwxr-xr-x 2 root root 48 Apr 20 15:55 /snap/bin

I was little concerned about what to do with /usr/bin/X11

I deleted the /usr/bin/X11 link and created a new directory /usr/bin/X11 
but it still failed.


I deleted the directory and remade the link.

I'd also prefer not to modify sa-compile since the next time there is a 
update it will likely be overwritten.


Hopefully someone can shed a clue

Bill Cole wrote:


Inside a perl script, the execution environment is available in the 
%ENV hash, with variable names as keys, so the execution search path 
"PATH" is "$ENV{'PATH'}". The %ENV hash is considered "tainted" as 
untrustworthy input by perl, so if the interpreter is run with the 
"-T" option, any subprocess launched by perl won't get any environment 
variables unless the script has done something to "untaint" members of 
that hash. The sa-compile script DOES use a SA utility function to 
untaint the whole %ENV hash, but there's a special catch for 
$ENV{'PATH'}: if any directories included are not absolute (e.g. 
commonly '.' and '~/bin') OR are writable by more than their owning 
user & group, $ENV{'PATH'} remains tainted and won't be used or passed 
to child processes. Often a bad member directory is unobvious because 
it is a symlink name and symlinks are usually technically mode 777 
because the system doesn't use the mode of a symlink itself.


What I expect is happening is that there's a problematic directory in 
the $PATH that perl gets when executed, so the blind untainting of 
$ENV{'PATH'} that sa-compile does won't work. The best fix is to find 
the insecure member of $PATH and remove it before trying to run 
sa-compile.

Re: Spam from .br TLDs

[Robert Schetterer]

Am 20.04.2017 um 15:57 schrieb RW:
> On Wed, 19 Apr 2017 17:37:42 +0200
> Heinrich Boeder wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>>
>> Hi all,
>>
>> I tried the Ruleset Robert Schetterer suggested but I still get Spam.
>> The rules barely get a hit. I am pretty sure that the rules are
>> outdated.

Hm, any chance to add rest spam content to the rules ?
Brazil List user alive here ? What about getting the rules up2date

>>
>> I´d also like to avoid excluding Portuguese Mails or Spanish Mails by
>> using ok_languages because I get (wanted) mails with english text and
>> spanish signatures for example. Or would you say that the TextCat
>> Plugin works so well that the chances of a false positive are really
>> low?
> 
> TextCat's UNWANTED_LANGUAGE_BODY rules requires that one or more
> languages are found in the text and none of them is in the ok_languages
> list.  TextCat isn't actually very good, but for me it fails by missing
> spam rather than hitting ham. Anyway it's only 2.8 points so rule FPs
> will rarely translate into a overall FP, but it's enough to combine
> with BAYES_95 or above to get over the 5.0 threshold.
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: False Positives from yahoo due to FORGED_MUA_MOZILLA

[John Hardin]

On Thu, 20 Apr 2017, Merijn van den Kroonenberg wrote:


On Thu, 20 Apr 2017 10:41:21 -0400
Lyle Evans wrote:


I have been getting false positives from Yahoo due to
FORGED_MUA_MOZILLA hitting on a new X-Mailer line added by Yahoo
about 3/31/17

The X-Mailer line reads:

X-Mailer: WebService/1.1.9272 YahooMailNeo Mozilla/5.0 (Windows NT
10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/56.0.2924.87 Safari/537.36

/DCE\)/

My guess is that they are including the http user-agent header of the
browser that connected to their webmail server.



Correct, I also noticed this a few days ago. Maybe the rule could be
changed to exclude yahoo...but maybe other webmail applications do this
too, not sure.


Excluding when verified from Yahoo would be the proper approach.

Unfortunately masscheck is down for migration so any global fix won't go 
out anytime soon...



--
 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
---
  It is criminal to teach a man not to defend himself when he is the
  constant victim of brutal attacks.  -- Malcolm X (1964)
---
 3 days until Max Planck's 159th birthday

Re: sa-compile will not configure

[Bill Cole]

On 19 Apr 2017, at 9:52, Robert Steinmetz wrote:


Robert Steinmetz wrote:

Responding to my own post with new information.
I think I've confirmed that the problem is the $PATH, or the perl 
equivalent.
I added the full path name where the specific commands were called and 
that removed that error. Some of the commands seem to be called from 
other perl scrips so the problem seems to be my perl set up.

But I'm not clear how perl actually sets the path.


Inside a perl script, the execution environment is available in the %ENV 
hash, with variable names as keys, so the execution search path "PATH" 
is "$ENV{'PATH'}". The %ENV hash is considered "tainted" as 
untrustworthy input by perl, so if the interpreter is run with the "-T" 
option, any subprocess launched by perl won't get any environment 
variables unless the script has done something to "untaint" members of 
that hash. The sa-compile script DOES use a SA utility function to 
untaint the whole %ENV hash, but there's a special catch for 
$ENV{'PATH'}: if any directories included are not absolute (e.g. 
commonly '.' and '~/bin') OR are writable by more than their owning user 
& group, $ENV{'PATH'} remains tainted and won't be used or passed to 
child processes. Often a bad member directory is unobvious because it is 
a symlink name and symlinks are usually technically mode 777 because the 
system doesn't use the mode of a symlink itself.


What I expect is happening is that there's a problematic directory in 
the $PATH that perl gets when executed, so the blind untainting of 
$ENV{'PATH'} that sa-compile does won't work. The best fix is to find 
the insecure member of $PATH and remove it before trying to run 
sa-compile.

Re: False Positives from yahoo due to FORGED_MUA_MOZILLA

[RW]

On Thu, 20 Apr 2017 17:02:57 +0200
Merijn van den Kroonenberg wrote:


> > My guess is that they are including the http user-agent header of
> > the browser that connected to their webmail server.
> >  
> 
> Correct, I also noticed this a few days ago. Maybe the rule could be
> changed to exclude yahoo...but maybe other webmail applications do
> this too, not sure.

I don't get much yahoo mail, is this the norm now? 

Re: False Positives from yahoo due to FORGED_MUA_MOZILLA

[Merijn van den Kroonenberg]

> On Thu, 20 Apr 2017 10:41:21 -0400
> Lyle Evans wrote:
>
>> I have been getting false positives from Yahoo due to
>> FORGED_MUA_MOZILLA hitting on a new X-Mailer line added by Yahoo
>> about 3/31/17
>>
>> The X-Mailer line reads:
>>
>> X-Mailer: WebService/1.1.9272 YahooMailNeo Mozilla/5.0 (Windows NT
>> 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
>> Chrome/56.0.2924.87 Safari/537.36
> /DCE\)/
>
> My guess is that they are including the http user-agent header of the
> browser that connected to their webmail server.
>

Correct, I also noticed this a few days ago. Maybe the rule could be
changed to exclude yahoo...but maybe other webmail applications do this
too, not sure.

Re: False Positives from yahoo due to FORGED_MUA_MOZILLA

[RW]

On Thu, 20 Apr 2017 10:41:21 -0400
Lyle Evans wrote:

> I have been getting false positives from Yahoo due to
> FORGED_MUA_MOZILLA hitting on a new X-Mailer line added by Yahoo
> about 3/31/17
> 
> The X-Mailer line reads:
> 
> X-Mailer: WebService/1.1.9272 YahooMailNeo Mozilla/5.0 (Windows NT 
> 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) 
> Chrome/56.0.2924.87 Safari/537.36
/DCE\)/

My guess is that they are including the http user-agent header of the
browser that connected to their webmail server.

False Positives from yahoo due to FORGED_MUA_MOZILLA

[Lyle Evans]

I have been getting false positives from Yahoo due to FORGED_MUA_MOZILLA
hitting on a new X-Mailer line added by Yahoo
about 3/31/17

The X-Mailer line reads:

X-Mailer: WebService/1.1.9272 YahooMailNeo Mozilla/5.0 (Windows NT 
10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/56.0.2924.87 Safari/537.36


and the Messagid reads:

Message-ID: <909353831.1397505.1490989414...@mail.yahoo.com>


It is triggering the rule FORGED_MUA_MOZILLA from 20_meta_tests.cf


header __MOZILLA_MUA   X-Mailer =~ /\bMozilla\b/
header __MOZILLA_MSGID MESSAGEID =~ 
/^<[A-F\d]{8}\.[A-F1-9][A-F\d]{0,7}\@\S+>$/m
meta   FORGED_MUA_MOZILLA (__MOZILLA_MUA && !__UNUSABLE_MSGID && 
!__MOZILLA_MSGID)

describe FORGED_MUA_MOZILLAForged mail pretending to be from Mozilla

50_scores.cf: score FORGED_MUA_MOZILLA 2.399 1.596 2.399 2.309

I realize that its just 2.309 points but throw in a few other 
miscellaneous hits and you get a

False Positive. (I'll make another post about one of the miscellaneous hits.)

Where __UNUSABLE_MSGID is defined in 20_ratware.cf
# first define situations where servers rewrite message id so we 
can't use message id to detect forgeries


header __HOTMAIL_BAYDAV_MSGID   MESSAGEID =~ 
/^<[A-Z]{3}\d+-(?:DAV|SMTP)\d+[A-Z0-9]{25}\@phx\.gbl>$/m


header __IPLANET_MESSAGING_SERVER Received =~ /iPlanet Messaging Server/

header __LYRIS_EZLM_REMAILER  List-Unsubscribe =~ 
/$/


header __SYMPATICO_MSGIDMESSAGEID =~ 
/^$/m


header __WACKY_SENDMAIL_VERSION Received =~ /\/CWT\/DCE\)/

meta __UNUSABLE_MSGID (__LYRIS_EZLM_REMAILER || 
__GATED_THROUGH_RCVD_REMOVER || __WACKY_SENDMAIL_VERSION || 
__IPLANET_MESSAGING_SERVER || __HOTMAIL_BAYDAV_MSGID || __SYMPATICO_MSGID)


My questions are is anybody else seeing this?
Why the @#$%! is Yahoo doing this?
What is the best fix?
I have temporarily removed the rule.

Thanks
Lyle Evans



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Spam from .br TLDs

[RW]

On Wed, 19 Apr 2017 17:37:42 +0200
Heinrich Boeder wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> 
> Hi all,
> 
> I tried the Ruleset Robert Schetterer suggested but I still get Spam.
> The rules barely get a hit. I am pretty sure that the rules are
> outdated.
> 
> I´d also like to avoid excluding Portuguese Mails or Spanish Mails by
> using ok_languages because I get (wanted) mails with english text and
> spanish signatures for example. Or would you say that the TextCat
> Plugin works so well that the chances of a false positive are really
> low?

TextCat's UNWANTED_LANGUAGE_BODY rules requires that one or more
languages are found in the text and none of them is in the ok_languages
list.  TextCat isn't actually very good, but for me it fails by missing
spam rather than hitting ham. Anyway it's only 2.8 points so rule FPs
will rarely translate into a overall FP, but it's enough to combine
with BAYES_95 or above to get over the 5.0 threshold.

Re: SpamAssassin scoring issues

[RW]

On Thu, 20 Apr 2017 12:08:54 +0200
Ralf Hildebrandt wrote:

> * David Jones :
> 
> > Are you hitting the URIBL_BLOCKED rule?  If so, please follow the
> > link in that reddit article to get rid of that rule hit.  This is
> > very important.  
> 
> Yes, but that's not his problem -- since the URIBL query fails in both
> delivery AND his test.
> 
> The actual differences are that these are NOT firing on delivery:
> 
> 1.9 URIBL_ABUSE_SURBL (OK, his IP might be blocked due to excessive
> queries) 1.2 RCVD_IN_BL_SPAMCOP_NET (that should work!)

I'm not really sure what you are saying here, but abuse is the name of
that particular SURBL list

1.9 URIBL_ABUSE_SURBL  Contains an URL listed in the ABUSE SURBL blocklist


URIBL_BLOCKED is in both tests because the IP address of the shared DNS
server is blocked. 

URIBL_ABUSE_SURBL and RCVD_IN_BL_SPAMCOP_NET are most likely missing in
the first because the IP and URI domain were listed after delivery.
This is very common when you retest after a short delay. 

Re: SpamAssassin scoring issues

[Ralf Hildebrandt]

* David Jones :

> Are you hitting the URIBL_BLOCKED rule?  If so, please follow the
> link in that reddit article to get rid of that rule hit.  This is very 
> important.

Yes, but that's not his problem -- since the URIBL query fails in both
delivery AND his test.

The actual differences are that these are NOT firing on delivery:

1.9 URIBL_ABUSE_SURBL (OK, his IP might be blocked due to excessive queries)
1.2 RCVD_IN_BL_SPAMCOP_NET (that should work!)

-- 
Ralf Hildebrandt   Charite Universitätsmedizin Berlin
ralf.hildebra...@charite.deCampus Benjamin Franklin
https://www.charite.de Hindenburgdamm 30, 12203 Berlin
Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155

Re: SpamAssassin scoring issues

[Ralf Hildebrandt]

* W B :
> Hey all! I'm having issues with SpamAssassin; it's assigning emails scores
> that are way lower than it should. In addition, the scores it's assigning as
> emails come in are different from the results of running SpamAssassin -t on
> that same email after the fact.

So, how is SpamAssassin invoked when mail comes in (which user is
being used to run SA?) and how has it been run when testing?

-- 
Ralf Hildebrandt   Charite Universitätsmedizin Berlin
ralf.hildebra...@charite.deCampus Benjamin Franklin
https://www.charite.de Hindenburgdamm 30, 12203 Berlin
Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155