Bug 6768 - Patchy checking of authentication
Summary: Patchy checking of authentication
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
: 6767 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-02-24 16:51 UTC by RW
Modified: 2012-05-09 15:09 UTC (History)
3 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status
Squirrelmail email from 41.0.0.0 domain text/plain None Mark London [NoCLA]

Note You need to log in before you can comment on or make changes to this bug.
Description RW 2012-02-24 16:51:36 UTC
Mostly rules aimed at direct-to-mx spam sources should avoid hitting authenticated submissions. Quite a lot of rules of this type are using neither an "auth=" check nor a meta with __LAST_EXTERNAL_RELAY_NO_AUTH.


RDNS_NONE or __RDNS_NONE
FAKE_HELO_MAIL_COM_DOM
HELO_DYNAMIC_DIALIN
HELO_DYNAMIC_HEXIP
HELO_DYNAMIC_SPLIT_IP
DOS_RCVD_IP_TWICE_C
FH_HELO_ALMOST_IP
FH_HELO_ENDS_DOT
FH_HELO_EQ_610HEX
FH_HELO_EQ_CHARTER
FH_HELO_EQ_D_D_D_D
FH_HOST_EQ_DYNAMICIP
FH_HOST_EQ_PACBELL_D
FH_HOST_EQ_VERIZON_P
FORGED_RELAY_MUA_TO_MX
FSL_HELO_BARE_IP_1
FSL_HELO_DEVICE
FSL_HELO_NON_FQDN_1
FSL_HELO_SETUP
HELO_FRIEND
HELO_LH_HOME
HELO_LOCALHOST
HELO_OEM
RDNS_LOCALHOST
__DOS_SINGLE_EXT_RELAY
FM_FAKE_HELO_VERIZON
__HELO_NO_DOMAIN
__NSL_RCVD_FROM_41
Comment 1 Henrik Krohns 2012-02-24 17:06:14 UTC
*** Bug 6767 has been marked as a duplicate of this bug. ***
Comment 2 Henrik Krohns 2012-02-24 17:18:22 UTC
Thinking about it, you might very well be right.
Comment 3 Mark London 2012-05-08 15:25:28 UTC
Spammers from the 41 ip range are constantly using authenticated squirrelmail
accounts (or at least inserting fake headers), so that __NSL_RCVD_FROM_41 is not being triggered.  I think that especially for __NSL_RCVD_FROM_41, it should be triggered, regardless of how it originates.
Comment 4 John Hardin 2012-05-08 17:43:44 UTC
(In reply to comment #3)
> Spammers from the 41 ip range are constantly using authenticated squirrelmail
> accounts (or at least inserting fake headers), so that __NSL_RCVD_FROM_41 is
> not being triggered.  I think that especially for __NSL_RCVD_FROM_41, it should
> be triggered, regardless of how it originates.

Can you attach a sample of one such that __NSL_RCVD_FROM_41 /by itself/ misses? The few samples I have of a squirrelmail spam from the 41 netblock all do hit that subrule.

I don't think the inclusion of subrules in RW's list makes sense, they are expected to be incomplete and may have lots of FPs. 

I could see __NSL_RCVD_FROM_41 missing a squirrel email from the 41 netblock if it was meta'd with some other rule that is taking the "SquirrelMail authenticated user mumble" into account. That's hardly a problem in the __NSL_RCVD_FROM_41 subrule; that's a problem in whatever is considering "SquirrelMail authenticated user mumble" as equivalent to a trusted auth at the recipient.
Comment 5 Mark London 2012-05-08 18:55:30 UTC
Created attachment 5058 [details]
Squirrelmail email from 41.0.0.0 domain

Attached is an example.

We are running redhat 6, spamassassin-3.3.1-2

- Mark
Comment 6 John Hardin 2012-05-08 21:08:22 UTC
(In reply to comment #5)
> Created attachment 5058 [details]
> Squirrelmail email from 41.0.0.0 domain
> 
> Attached is an example.
> 
> We are running redhat 6, spamassassin-3.3.1-2
> 
> - Mark

That message hits for me:

  May  8 13:49:34.056 [24371] dbg: rules: ran header rule __NSL_RCVD_FROM_41 ======> got hit: " ip=41."

What are you expecting to see that you aren't, that makes you believe __NSL_RCVD_FROM_41 is missing?
Comment 7 Mark London 2012-05-08 21:20:58 UTC
If I take out the header line that has Squirrelmail in it (right after the "from 41... line", the rule triggers properly for me.

It must have something to do with the spamassassin rpm built for redhat.  I installed a clean version of their rpm on a workstation, and I get the same result.  I'll try figure out what is going on.
Comment 8 John Hardin 2012-05-08 21:53:02 UTC
(In reply to comment #7)
> If I take out the header line that has Squirrelmail in it (right after the
> "from 41... line", the rule triggers properly for me.

That sounds like the header parser is getting confused by the Squirrelmail text and not even adding that Received header to X-Spam-Relays-External. I don't recall any bugs like that, but I haven't been following parser bugs too closely.

I was going to suggest checking the definition of your __NSL_RCVD_FROM_41 rule, as it used to be:

  header   __NSL_RCVD_FROM_41     Received =~ /[([]41\./

and that wouldn't hit because of the blank, but simply removing the Squirrelmail text wouldn't magically make that rule start working...
Comment 9 John Hardin 2012-05-09 15:09:59 UTC
Related issues in bugzilla: bug#3236 bug#3302 bug#6549 (still open)

I don't think the discussion of SquirrelMail effects is relevant to this bug.