Jo Rhett wrote: > Included below is a legitimate e-mail on a legitimate payment that I > did make. > > I've looked at the rule, and I can't figure out why it failed. >
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: ----------------------- 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. My suggestion for working around this? Create a meta rule that negates SARE_FORGED_CITI. header __FROM_CITI_BFI Received =~ /bigfootinteractive\.com/I meta CITI_FROM_BFI (SARE_FORGED_CITI && __FROM_CITI_BFI) score CITI_FROM_BFI -4.0 describe CITI_FROM_BFI CitiBank tells BFI to forge their headers (Side note: Times I mistyped "BFI" as "BIF" -- about 10) You could probably also rewrite SARE_FORGED_CITI, but that might break if the author of the SARE ruleset changes it behind the scenes in a later release.
