Re: bincdrop - a (courier) maildrop replacment

Peter Stuge <[email protected]> Sat, 23 Jul 2005 06:28:02 +0200
Newsgroups gmane.mail.imap.binc.devel
Message-ID <[email protected]>
On Fri, Jul 22, 2005 at 12:10:14PM -0500, Gary wrote:
> J> clients that support sieve would connect to a sieve daemon and
> J> talk a protocol to change their filter settings.

This is for draft-managesieve. I don't like that design too much, nor
having the scripts stored in the filesystem. They kind of go
together. The problem I see is that there's no way to build
(portable) tools around them since the sieve RFC is independent
of all mail architectures. That makes it a two-edged sword..

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.

I guess an implementation of managesieve will abstract it away, but..
Mh, I don't know..


> J> kmail is the only client I am aware of that supports sieve.. and
> J> I've never used cyrus, so I'm not sure how WELL it supports it  
> 
> Mulberry also supports it (in Linux/Unix, OSX, or Windows
> versions), in fact, this client will generate the script for you. 
> Cyrus supports it fully, as that is what Fastmail.fm uses as their
> backend IMAP.

I would really have liked to see managesieve as an IMAP extension.


On another note, this is kind of related to the folder hooks that I
care a lot for. :) Is the intention to implement Sieve in bincdrop
and only bincdrop and use it only for incoming mail? Would there be a
point in having Sieve filters on all folder? In that case, one could
use folder hooks to outsource all message delivery from bincimapd to
bincdrop.


Flame away! :)


//Peter