http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5817
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Poorly faked MTA Received |Poorly faked MTA Received
|headers (Plugin) |headers (MUA to MX)
------- Additional Comments From [EMAIL PROTECTED] 2008-02-15 04:16 -------
Thanks, Daryl. :) Although, I hope you didn't believe I'd not hack on that
right away, no matter the time. ;) Shortly after my last comment, I got a first
rule somewhat working. It was mostly the testing, that had to wait until
today...
So, here are two variants of the Forged Relay, MUA to MX as ordinary rules:
header FORGED_RELAY_MUA_TO_MX X-Spam-Relays-Untrusted =~
/^\[ ip=(?!127)([\d.]+) [^\[]*\[ ip=\1 [^\[]+ helo=(!(?!127)| )[^\[]+$/
# __RELAYS_IP_MATCH, __RELAYS_THREE_PLUS and __RELAY_MUA_HELO_IP_OR_NONE
# respectively (shortened to avoid wrapping)
header __A X-Spam-Relays-Untrusted =~ /^\[ ip=(?!127)([\d.]+) [^\[]*\[ ip=\1 /
header __B X-Spam-Relays-Untrusted =~ /(\[.+){3}/
header __C X-Spam-Relays-Untrusted =~ / helo=(!(?!127)| )[^\[]+$/
meta FORGED_RELAY_MUA_TO_MX __A && !__B && __C
Quite embarrassing -- though at least it wouldn't have been that easy to spot
the constraint of the helo IP without my custom dbg printing in the plugin.
Anyway, all three variants result in the exact same hits on my test corpora.
Caveat: Similar to your original rule, this doesn't check all of IP_PRIVATE, but
localhosts only for simplicity.
The long names for the broken down in chunks meta rule should be pretty self
explanatory. They ensure all three constraints are satisfied: The IPs of the two
untrusted relays are identical, there are exactly two untrusted relays, and the
first relays HELO either is a non-localhost IP or none. (Btw, you checked the
wrong relays HELO. ;)
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
