SA Bugzilla – Bug 6768
Patchy checking of authentication
Last modified: 2012-05-09 15:09:59 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
*** Bug 6767 has been marked as a duplicate of this bug. ***
Thinking about it, you might very well be right.
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.
(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.
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
(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?
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.
(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...
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.