Re: bincdrop - a (courier) maildrop replacment

Peter Stuge <[email protected]> Mon, 25 Jul 2005 13:12:30 +0200
Newsgroups gmane.mail.imap.binc.devel
Message-ID <[email protected]>
On Mon, Jul 25, 2005 at 08:58:36AM +0200, Jerry Lundström wrote:
> Peter Stuge wrote:
> >This is for draft-managesieve. I don't like that design too much,
> 
> I totally agree with you that the draft is horrible. It is some
> what sad that they happen to make a email filtering script and not
> a good way to interface with them on a imap server.

My point exactly.


> >I like Sieve itself a lot, but the best thing would be if we could
> >figure out a mail architecture agnostic way to store the scripts,
> >to go with the ditto filtering system.
> 
> My idea was a filter directory in the root of the maildir folder
> that contains mime-tagged files. But that is just an idea.

Sure, as long as someone is looking there, that will work. But what
about compatibility with regard to the Maildir spec? Admittedly, Binc
has already broken that with .binc* files, but I'd like to try and
fix that rather than adding more files in there.


> Do you have any ideas btw?

Well, any number of database engines could be used to store the
scripts, LDAP, SQL, simple dbase, etc. But at least for some that
still means storing a file in the filesystem somewhere, which is what
I want to avoid, at the very least on a per-user level. Perhaps in
the service directory? Or in /etc/bincimapd?

My problem with extra files in the mailbox stems from the fact that I
mostly have virtual users and want to keep the mail directory
structure clean and uncluttered. For sites with mostly real user
accounts the opposite actually makes more sense since users would be
able to work on the files/scripts in any way they please.

I can imagine that virtual mail management packages get cranky if
there's too many unexpected files around too but I don't know of an
example at the moment.

Andreas, have you thought about generalizing metadata somehow,
perhaps even moving it completely into some DBMS that is easy to work
with? I'm using SQLite for a project now and it's small and quick and
public domain. :) But like I said, there are many options, and
something like the metadata backend that Jerry was thinking about for
bincdrop would be great to have in bincimapd as well.


//Peter