Changes have been made in Git for this ticket:

Fix maildrop rules without conditions (almarin@um.es, Bug #8103).

http://git.horde.org/diff.php/ingo/docs/CHANGES?rt=horde-git&r1=82c209c8e71b9473af38085588bda376ab370f98&r2=14e76278f3f4a3f9ce9ff2c56f12c899c74386a4
http://git.horde.org/diff.php/ingo/lib/Script/maildrop.php?rt=horde-git&r1=82c209c8e71b9473af38085588bda376ab370f98&r2=14e76278f3f4a3f9ce9ff2c56f12c899c74386a4

Committed, thanks.



If you have a chance, can you take a look at the other open bugs of 
the maildrop driver?

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/ingo/docs/CHANGES?rt=horde&r1=1.55.2.119&r2=1.55.2.120&ty=u
http://cvs.horde.org/diff.php/ingo/lib/Script/maildrop.php?rt=horde&r1=1.7.2.13&r2=1.7.2.14&ty=u

I'm so sorry Jan.



I tested the modification in our current version, and later i 
generated the patch making modifications in CVS HEAD version, but 
actually i did not test the patch because it was very simple. But i 
made a stupid mistake.



I attach the correct and tested patch.

Did you actually test the patch? This is how maildrop scripts look like now:



430: ##### Horde Bugs #####

431: if( \

432:    /^From:\s*bugs@horde\.org$/:h \

433: if( \

434: exception {

435:    to INBOX.horde.bugs

436: }

I don't think so.



The patch checks if any condition exists:



  if (count($this->_conditions) > 0) {



In that case, it add 'if' statments and the conditions.



I don't know if i'm missing something, but the patch is working for me.



In fact, i think that actual condition looks weird:



if (count($this->_conditions > 1)) {



Comparing an array with a number before count?

This breaks all rules *with* conditions.

You are right, an unconditional rule should be valid. Let me try 
another patch for maildrop driver

It is perfectly valid having no conditions. The rule should be 
executed unconditionally then. If this doesn't work in maildrop, then 
the maildrop driver has to fixed instead.

Not exactly. Update made in #5641 ensures that a defined condition is 
not empty, but doesn't ensures that the rule has at least one condition.

Hasn't this been fixed with bug #5641 already?

Hi,



Now it is possible to create filters without any condition. With 
maildrop backend, it generates filters like:



##### New Rule #####

if( \

)

exception {

    to "${DEFAULT}"

}



And that generates a maildrop error beause of a mailfilter parsing error.



I think it makes sense to deny any rule without conditions. I attach a 
patch to do it.