http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5817
------- Additional Comments From [EMAIL PROTECTED] 2008-02-13 17:26 ------- (In reply to comment #7) > The rule is in the 70_other.cf file in my sandbox (available via svn). Ah, there it is. Thanks. > The rule checks for suspected forged received headers by checking if external > received headers contain (dot-)quads that are duplicated one after another. > Hence the name DOS_FORGED_RCVD_QUADS. The rule is Sendmail-ish specific and > relies on the IP having no rDNS. In your examples above the IPs do have rDNS > so the rule wouldn't fire. > > I've just added a generic version of this rule, DOS_RCVD_IP_TWICE, that will > fire on your examples. > FWIW, you could implement the plugin via a couple of rules and achieve the > same > result. I'd either do that (and hopefully it'll be self documenting) or at > least document what you're trying to achieve (and why) in your plugin. Damn, you are quite efficient in demotivating me... :/ You're probably right that one could accomplish the same with rules only. I forgot about that meta header entirely, when I started hacking. Doh! However, there are quite some significant differences between the rule you mentioned above, and my plugin. First, I explicitely limit the untrusted relays to be exactly 2. I don't want to FP on mail processing or generating external entities, like mailing list server or automatic notifications of any kind (including bugzilla). I don't want to catch anything in the chain actually, but direct MUA to MX msgs with a "second" forged relay. Also, even that resulted in 0.3% FP hits. While that might not be much, it was unsatisfying and suboptimal. ;) After some checking of the remaining info, the HELO seemed to be key. A non-empty, non-IP HELO was almost exclusivly characeristic for ham, eliminating all FPs and resulting in a mere 1% less accuracy on spam. Btw, my ham corpus consists of directly sent mail only. No mailing list stuff or something, which sure would not hit with my constraint of exactly 2 untrusted relays. I am confident about my plugin/rule, and currently score it at 3.0, given my test results and that this trick seems to be rather new to get around the MUA to MX style rules. It sure does hit galore for, especially with a current wave of low scoring spam (read: almost no hits but Bayes). Regarding documentation: Sure! I just meant to publish it early and get some discussion and opinions. I already wrote some doc, however, mostly suited for me as a reminder. If the plugin would be welcome and accepted, I'll invest further work to document inline and point out the details. For now, I figured the discussion in here should be sufficient for documenting the reasoning. Also, still, this was quite some fun. :) And I am rather positive, that trying the very same stunt in rules only, would have been harder. At least for me. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
