http://bugzilla.spamassassin.org/show_bug.cgi?id=3417
------- Additional Comments From [EMAIL PROTECTED] 2004-05-26 12:32 ------- Subject: Re: New Rule: Checking sender IP against MX records From: [EMAIL PROTECTED] On Wed, May 26, 2004 at 12:09:53AM -0700, [EMAIL PROTECTED] wrote: > I am looking forward that somebody check effectifly of this rule. Just so we can clear this up, I started running this on my past 2 day's worth of mail. The original code 1) doesn't work directly with 3.0, and after fixing that, 2) got 0 hits for me after ~3k mails. So I went through and streamlined it a bit, fixed a few logic issues, etc. It's now getting some hits, though not a lot. I'll send up a patch for the EvalTest shortly. Thing to note: The IETF draft is meant to be an anti-forging system, but the rule is meant to be a net-based whitelist -- basically: don't forge, get negative points. They're distinctly different ideas. So let's ignore the draft and the MX overload issues. After 1000 mails, I stopped, since I only had 172 ham in the past 2 days (27.5k spam btw). I didn't want the results to get too skewed. 92 ham hits, 15 spam hits. The ~50% ham hit rate is nice, but since there are spam hits, there's no way you would want to use this as a whitelist. More on that below. The rule, as proposed, looks through all the untrusted received headers, and uses the header From domain, so it's trivial for a spammer to put in any matching forged From and Received header and hit the rule. Definitely not a good whitelist. If you limit the rule to the first untrusted received header only, it becomes harder to forge, but makes the results even worse as well: 29 ham hits, 15 spam hits. Compare this to SPF PASS results over the same 1000 mails: 15 ham hits, 0 spam hits. SPF FAIL results: 0 ham, 29 spam. SPF requires much fewer DNS requests and is therefore significantly faster than the MX version, BTW. In the end, we get back to the fact that anti-forging and anti-spam are 2 distinctly different ideas. The MX rule (as well as SPF PASS rules) don't indicate anything about spaminess. All they indicate is that the sender address isn't forged. This means you still have to scan the message, and spammers can simply go back to not forging the address (which is the goal of such mechanisms). Therefore, having it as a whitelist is just incentive for the spammers to stop forging (good), which will then help them bypass the spam filters (bad). This is why things like SPF_PASS are forced to a score of -0.001. It's good as an indicator for other rules/used in meta rules, but not as a whitelist. What you really want to do is flag when you know forging occurs -- give a penalty if an address is forged. You definitely can't do that right now with the MX version or the proposed rule -- the vast majority of MX records indicate the receiver _only_ (which is what MX is meant to do). Therefore, you can't have a rule that says "add 4 points if the sender IP isn't a MX for the domain". It would flag so much ham as to be useless. With SPF however, the owner of the domain can specify how they want others to treat mail from their domain: there's no overloading, there's no guessing, and it works right now. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
