Please create a new ticket.

We are using the maildrop driver (version 1.2) and encountered some 
problems in the script-generation (in the forward-section) the 
attached patch should resolve these problems.

The maildrop driver has been added to Ingo HEAD.

Hi



Since there is no maildrop support in ingo and we are using horde and a

delivery system based on maildrop, I wrote a maildrop driver for ingo

together with my brother. It wasn't that hard since .procmailrc and

.mailfilter syntax looks similar. What I had to change was the handling of

AND and OR-coupeled rules since they can be matched with a simple && or ||

in maildrop.



I don't know if you are interested in my work, but I guess so since I read

that sentence on the project's website:



'A maildrop driver for example would be a nice addition'



Maybe you even want to review the driver and include it in ingo or 
place a link

on the website. I don't know, but anyway, it's attached.



I didn't touch the header of the file and in the comments, I only changed

Procmail to Maildrop. I didn't change the structure of the file, so I left

the original author and version information. I don't know how you handle

this, so i just didn't change anything. At least if the file enters the

official project, it would be very nice to mention our names (Nicolas and

Mathias Weyland) somewhere. And of course, the file can be distributed under

the same license than the rest of the framework.



Here is a list of the things which are not properly solved atm:



- Since there is no c-flag for maildrop (in procmail, that delivers a mail,

but a copy of that mail continues and may be matched by another recipe),

there is a problem with the store-and-forward mechanism. I solved this by

setting $params['action'] to 12 (first one which was free). I guess the

proper way to handle that would be to add a new local variable to the

Maildrop_Recipe class or something similar, but I wanted to sort this out

with the developers before I do this.



- There is no vacation support. I just except my users to read their mails

even if they are in holidays, so I don't have any need for this :). Shouldn't

be hard to implement it, though.



- For now, it does not support any size-tests (procmail doesen't either)



- Lot's of lines have just been commented out instead of deleted.



- some settings still have to containt procmail instead of maildrop in 
backends.conf, I don't know where to change that.



All of the above issues are acceptable for me, but if you really are going

to include the file I'll fix those things.



Some more details: The .mailfilter (or however you call it) file is uploaded

using vfs, just as the .procmailrc file in the driver I used as template.

The files are included by this directive in /etc/maildroprc:



exception {

         include "${HOME}mailfilter"

}



$HOME contains the path to the user's maildir. I'm using this with virtual

users, so $HOME is something like /home/vmail/user@tomain.tld/



Several things are important:



- exception {} makes sure that maildrop does not error if there is no such

file. The mail would get bounced otherwise.



- I called the file ~/mailfilter and not ~/.mailfilter. A .mailfilter file

would get listed in imp's folder list.



- All recipes in the user's mailfilter file are enclosed by exception{}

directives. This is very important since the same I described above would

happen if a user generates a subfolder, adds a rule for it and _removes_

that subfolder _without_ adapting the rule afterward!



And at the end, I have to tell you that this code has been tested only

poorly, it would not surprise me if there are some bugs around, so please

test it before you use it in any productive environement (and give me

feedback :).



Best regards



Matt Weyland