http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5817
------- Additional Comments From [EMAIL PROTECTED] 2008-02-14 18:37 ------- (In reply to comment #8) > Damn, you are quite efficient in demotivating me... :/ That's not my intention at all. It's just not clear to me why you're mixing substr with regexes and then testing if $helo has a value after you've already tried to take a substr of it. I wasn't sure of what you were trying to do or if you were sure that you had achieved what you were trying to do. > 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. Either way works (plugin or header rule) for this criteria. Header rules are just more likely to get tested by us than eval rules, especially when it is possible to do something via a rule. Eval rules (especially when implemented in their own plugins) are expensive in both use and life-cycle management. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
