Coffey, Neal wrote:
Well, partly it failed because you set your limit to 4 instead of 5.
You take a risk of false positives by doing that, since the rulesets are
optimised with a score of 5 in mind.
However, the "real" culprit seems to be SARE_FORGED_CITI, which is
defined thusly:
I'm sorry, apparently I wasn't technical enough. Yes, I can read. And
I already opened up and looked at the rule, and I can't figure out why
it failed. Please skip the duh answers.
And god no, I never use 5 as the tag level. Hell, I run 2.9 on a number
of my accounts... Don't try to make something that is an adjustable
user policy into a Don't Change This.
-----------------------
header __RCVD_CITIBNK Received =~
/(?:citi(?:bank|cards|corp|bankcards)|acxiom|c2it)\.com/i
header __FROM_CITIBNK From =~ /citi(?:bank)?\.com/i
uri __URI_CITIBNK /citi(?:bank)?\.com/i
meta SARE_FORGED_CITI (__FROM_CITIBNK && __URI_CITIBNK &&
!__RCVD_CITIBNK)
-----------------------
We see this in your headers from that email...
Received: from bigfootinteractive.com
(arm184.bigfootinteractive.com
[206.132.3.184]) by triceratops.lizardarts.com (8.13.8/8.13.8)
...and come to the conclusion that this email does, in fact, have forged
Citibank headers. In this case, it's a legitimate email, but it's still
forged. Shame on Citibank.
That's not the RCVD_CITIBNK rule I'm using. I have the latest, which is
200607251600.cf. The latest rule is
meta __RCVD_CITIBNK (__RCVD_CITIBNK_A || __RCVD_CITIBNK_B ||
__RCVD_CHASE_B)
RCVD_CHASE_B (which should probably be renamed RCVD_BIGFOOT) is
header __RCVD_CHASE_B Received =~ /\bbigfootinteractive\.com/i
And thus, the rule should not match. Which is why this confused me.
My suggestion for working around this? Create a meta rule that negates
SARE_FORGED_CITI.
No, the real fix is for the rule to work. Don't add breakage to breakage.
--
Jo Rhett
Network/Software Engineer
Net Consonance
