Re: bincdrop - a (courier) maildrop replacment

On Mon, Jul 25, 2005 at 01:27:05PM +0200, Jerry Lundström wrote:
> >>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.
> 
> Well, the .binc* is a nono and the Maildir spec says its ok to
> store files in Maildir/. with alphanumeric (or atleast thats what
> every one does) so I don't see why we can't store our filter there
> also.

You are of course right and I'm busy taking the foot out of my mouth.

--8<-- cr.yp.to/proto/maildir.html:
Can a maildir contain more than tmp, new, cur?
Yes:

   * .qmail: used to do direct deliveries with qmail-local.
   * bulletintime: empty file, used by system-wide bulletin programs.
   * bulletinlock: empty file, used by system-wide bulletin programs.
   * seriallock: empty file, used to serialize AutoTURN. 
-->8--


> Maybe we should only have one file named "filter" and have the
> scripts in MIME parts.

At least name it sievefilter.
Sure, MIME will work, except that it's hard to work with for everyone
else, who don't have a nice MIME parser at hand. :)


> >>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?
> 
> Sure, having a database backend that can store data in a directional 
> structure is a fine idea

Doesn't have to be directory based - the username is a unique
identifier.


> but hello? users filter files in /etc ? =)))
> I don't know how many users you have but I'm dealing with around
> 50.000 and several machines.

Yeah, sorry, disregard that /etc thing. :) I wasn't thinking
straight.


> >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.
> 
> Erhm, I dont really get you here, what is the problem with virtual
> users having their filters inside the Maildir. The point of sieve
> is to have the scripts managed remotly via the IMAPd.

..except that it isn't. I wish it was.

Or is there more than one "managesieve draft" ? Perhaps I've been
reading the wrong document? :) See my other message from a few
minutes ago.


> >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.
> 
> Not really, there is alot of program already today that adds
> bunches of files directly into the Maildir/. .

And that is fine. Strike that complaint of mine.


> >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.
> 
> No thanks, you are forgetting the idea behind Maildir and it is

Sorry, I should have been more clear. I didn't mean for storing mail
but for storing binc's internal metadata, to get rid of .binc* files.

The mail storage is already abstracted in bincimapd. :)


//Peter