Re: bincdrop - a (courier) maildrop replacment

Peter Stuge wrote:
> On Mon, Jul 25, 2005 at 08:58:36AM +0200, Jerry Lundström wrote:
>>>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.

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. Maybe we 
should only have one file named "filter" and have the scripts in MIME parts.

>>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 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.

> 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.

> 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/. .

> 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 that the 
  files should be accessable without locking. Having DBM files doesnt do 
it and will break almost every distributed filesystem setup. I would go 
for the database backend if you want other types of storage, an 
interface that you say for example:

StorageDirEntries entries = StorageBackend.getDirEntries("Maildir/new");

And that can redirect that request to the filesystem or a LDAP database 
etc etc etc...

Regards,
Jerry

-- 
Jerry Lundström
Sektionen för IT och media, Stockholms universitet
+46 (0)8 16 19 99 / http://www.it.su.se