[Tickets #5816] Re: Added more tests to maildrop Script and fixed REJECT action

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=5816
-----------------------------------------------------------------------
 Ticket             | 5816
 Updated By         | horde at nospam.obeliks.de
 Summary            | Added more tests to maildrop Script and fixed REJECT action
 Queue              | Ingo
 Version            | HEAD
 Type               | Enhancement
 State              | Feedback
 Priority           | 2. Medium
 Owners             | Chuck Hagenbuch
-----------------------------------------------------------------------


horde at nospam.obeliks.de (2007-12-26 15:18) wrote:

> We're getting much closer to release. Any updates on a patch?

I'm sorry, my time is quite limited right now, since I'm very near to the
deadline of a project myself. I certainly can't provide a solution for a
more sophisticated expression model, like for example in Sieve support.

Improving support for black/whitelist isn't that hard in concept though.
It would be best not to match against a header value, but against the
predefined $FROM-Variable (cp.
http://www.courier-mta.org/maildrop/maildropfilter.html) that contains the
sender _address_ only.
This would however require a condition that isn't based on regular
expressions being matched against the header lines, but a condition like
($FROM eq "address1"), which is why I though creating a more flexible
recipe/condition model would be the right way to go.

To work around that, the easiest and most elegant way would probably be to
create a new Maildrop_ListRecipe class, that inherits from Maildrop_Recipe
and overrides addCondition() as well as generate() (the latter can be
copied nearly 100%, just the condition->text transformation has to be
altered -- maybe it would be better to change it in the original
Maildrop_Recipe and only have to change both addCondition()
implementations).

I'm sorry I can't provide a patch right now, maybe I can help out for the
next release. If nobody can be found doing this work until the next
release, it would probably still be best to revert to the old
"contains"-Condition for While/Blacklists.