<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet href="http://bugs.horde.org/themes/feed-rss.xsl" type="text/xsl"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
 <channel>
  <title>spam-filtering for maildrop</title>
  <pubDate>Fri, 04 Jul 2008 11:26:40 -0400</pubDate>
  <link>http://bugs.horde.org/ticket/5843</link>
  <atom:link rel="self" type="application/rss+xml" title="spam-filtering for maildrop" href="http://bugs.horde.org/ticket/5843/rss" />
  <description>spam-filtering for maildrop</description>

  
  
  <item>
   <title>Attached for your consideration:  a patch to ingo/lib/Script</title>
   <description>Attached for your consideration:  a patch to ingo/lib/Script/maildrop.php to allow maildrop scripts to use the INGO_STORAGE_ACTION_SPAM action.  As of now, it does 'string' and not 'numeric' comparisons.</description>
   <pubDate>Tue, 30 Oct 2007 12:57:45 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/5843#t38250</link>
  </item>
  <item>
   <title>Can it do string comparisons unconditionally instead of brea</title>
   <description>Can it do string comparisons unconditionally instead of breaking if numeric comparisons are requested, then?

Also, what's the +2 for? (after $spam-&gt;getSpamLevel())</description>
   <pubDate>Tue, 30 Oct 2007 13:50:12 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/5843#t38255</link>
  </item>
  <item>
   <title>&gt; Can it do string comparisons unconditionally instead of br</title>
   <description>&gt; Can it do string comparisons unconditionally instead of breaking if 
&gt; numeric comparisons are requested, then?

Certainly, I did not know where or how to set that.  We use string comparisons, so numeric was not of such importance to us.  I had not gotten to seeing whether maildrop was capable of them, but figured it would be useful to post what I had.
&gt;
&gt; Also, what's the +2 for? (after $spam-&gt;getSpamLevel())

On the list I commented that we add two to normalize spam scores for our customers and should not have been included.</description>
   <pubDate>Tue, 30 Oct 2007 14:58:30 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/5843#t38259</link>
  </item>
  <item>
   <title>&gt; Certainly, I did not know where or how to set that.  We us</title>
   <description>&gt; Certainly, I did not know where or how to set that.  We use string 
&gt; comparisons, so numeric was not of such importance to us.  I had not 
&gt; gotten to seeing whether maildrop was capable of them, but figured it 
&gt; would be useful to post what I had.

According to http://www.courier-mta.org/maildrop/maildropfilter.html &gt;= should be just fine.</description>
   <pubDate>Wed, 31 Oct 2007 15:19:04 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/5843#t38278</link>
  </item>
  <item>
   <title>Committed, thanks!</title>
   <description>Committed, thanks!</description>
   <pubDate>Wed, 31 Oct 2007 15:24:57 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/5843#t38281</link>
  </item>
  <item>
   <title>Actually, this patch will not work at all. 

The way maild</title>
   <description>Actually, this patch will not work at all. 

The way maildrop condition generation works atm, each condition starts with /^ 
(see this line: $string .= '/^' . $condition['field'] . ':\\s*';),
which starts a regular expression. 
Like I said in bug #5816, implementing numerical comparisons would require more changes to the script.

In a maildrop script, a numerical comparison (e.g. &gt;=) for a certain header field (e.g. HeaderName) and a certain value (e.g. 5, from (int)$condition['value']) would best be implemented as 
(/^HeaderName:\s*(\d+(\.\d+)?)/h &amp;&amp; $MATCH1 &gt;= 5)

This would work fine with the current script generation algorithm, except an opening parenthesis would have to be added at the beginning of a condition for numerical comparisons, and the second part of the condition would have to be added AFTER the regular expression is closed and also AFTER the flags are added (which is why I didn't implement this in the above mentioned bug/patch, but tried to restructure the whole thing to make it more readable).

However, If I got that right, the current HEAD of the maildrop.php however will produce something like
/^HeaderName:\s* &gt;= 5/h
which is of course complete bogus.

Please revert the changes until a proper patch is provided.
 </description>
   <pubDate>Sun, 18 Nov 2007 15:44:36 -0500</pubDate>
   <link>http://bugs.horde.org/ticket/5843#t38717</link>
  </item>
  <item>
   <title>I'm sorry, I was mislead by the commit log for the revision </title>
   <description>I'm sorry, I was mislead by the commit log for the revision that referenced this bug...
I was referring to the numerical comparisons added in rev 1.17, not to the spam action. My bad. The point remains still valid of course...</description>
   <pubDate>Sun, 18 Nov 2007 16:20:34 -0500</pubDate>
   <link>http://bugs.horde.org/ticket/5843#t38719</link>
  </item>
  <item>
   <title>Thanks for catching that. I've taken another shot at it base</title>
   <description>Thanks for catching that. I've taken another shot at it based on your example. Can you please check:
http://cvs.horde.org/diff.php/ingo/lib/Script/maildrop.php?r1=1.17&amp;r2=1.18&amp;ty=u

Thanks!</description>
   <pubDate>Mon, 19 Nov 2007 00:24:18 -0500</pubDate>
   <link>http://bugs.horde.org/ticket/5843#t38738</link>
  </item>
  <item>
   <title>&gt; Thanks for catching that. I've taken another shot at it ba</title>
   <description>&gt; Thanks for catching that. I've taken another shot at it based on your 
&gt; example. Can you please check:
&gt; http://cvs.horde.org/diff.php/ingo/lib/Script/maildrop.php?r1=1.17&amp;r2=1.18&amp;ty=u
&gt;
&gt; Thanks!

Looks much better, but it still won't work, if the conditions are joined by OR. I'll take a shot at it these days, some of the refactoring I've planned to do sometime... Hang on ;) If it's urgent, I'm sure we can find a fix without the restructuring.</description>
   <pubDate>Mon, 19 Nov 2007 16:29:45 -0500</pubDate>
   <link>http://bugs.horde.org/ticket/5843#t38771</link>
  </item>
  <item>
   <title>&gt;&gt; Thanks for catching that. I've taken another shot at it b</title>
   <description>&gt;&gt; Thanks for catching that. I've taken another shot at it based on your
&gt;&gt; example. Can you please check:
&gt;&gt; http://cvs.horde.org/diff.php/ingo/lib/Script/maildrop.php?r1=1.17&amp;r2=1.18&amp;ty=u
&gt;&gt;
&gt;&gt; Thanks!
&gt;
&gt; Looks much better, but it still won't work, if the conditions are 
&gt; joined by OR. I'll take a shot at it these days, some of the 
&gt; refactoring I've planned to do sometime... Hang on ;) If it's urgent, 
&gt; I'm sure we can find a fix without the restructuring.

I'm sorry, I just learned that &amp;&amp; has a higher precedence than ||, so your code should work fine even if conditions are joined by OR.

However the 'not equal' test should use != as operator, instead of 
! /Header:.../ &amp;&amp; $MATCH1 == condition, 
because that would indeed not work. Furthermore, 'not equal' must then be excluded from the negation above (line 557 in HEAD). Patch attached.

PS: The patch also removes some duplicated code by defining the numerical relation operators in an instance variable. Remove this if you don't find it appropriate.</description>
   <pubDate>Tue, 20 Nov 2007 13:06:40 -0500</pubDate>
   <link>http://bugs.horde.org/ticket/5843#t38807</link>
  </item>
  <item>
   <title>Looks fine. Committed, thanks!</title>
   <description>Looks fine. Committed, thanks!</description>
   <pubDate>Tue, 20 Nov 2007 16:03:59 -0500</pubDate>
   <link>http://bugs.horde.org/ticket/5843#t38820</link>
  </item>
  

 </channel>
</rss>
