[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Sieve in Kmail (was; Re: KIOSlave questions)
From:       Hamish Rodda <meddie () yoyo ! cc ! monash ! edu ! au>
Date:       2001-12-28 15:05:32
[Download RAW message or body]

> On Monday 23 December 2001, Marc Mutz wrote:
>I think you should name the protocol "cyrus-managesieve" or "timsieve",
>then. Less conflicts in case an official sieve management protocol
>comes up later...

Makes sense, no probs. I actually found the submission to the IETF here: 
http://www.ietf.org/internet-drafts/draft-martin-managesieve-03.txt
It appears to be an interim measure to be replaced eventually by ACAP (rfc 
#2244, http://www.ietf.org/rfc/rfc2244.txt).

The ioslave is basically done, if anyone is interested in it, send me an 
email.

>> I know this is off-topic, but has there been any discussion of using
>> Sieve in KMail? I'm just reading the archives now and couldn't find
>> much mention of it...
>
>Problem here is that Sieve in itself (as defined in the rfc) is pretty
>poor. The only thing we could use it for is was to let the user create
>scipts visually and post them to the server. And only to Cyrus ones',
>else she'd had to figure out how to do it herself.
>
>For client-side filtering, Sieve isn't an option. Some commands require
>the interpreter to know the envelope address, something the MUA often
>doesn't see.

The Sieve standard marks this capability as optional, and scripts must specify 
[requires "envelope";] if they want to use it at the start anyway.  Sieve was 
designed to be applicable to client-side filtering as well, although it is 
not designed with extended functionality in mind that technically-minded 
people might expect.

> Also, the set of useful actions is too limited and I'm not
>a big fan of creating a bunch of kde.kmail.foo actions.

I had a look through Kmail's current capabilities, and pretty much all of 
those that sieve is missing (if you include capabilities introduced by the 
extensions below) require local actions to be taken, such as executing a 
program, changing local message flags etc. (in which case a kde.kmail.foo 
extension would be justified), or actually modifying the message (altering 
the header), which could be appropriate for a generalised extension to sieve.

Plus, sieve contains a few additional capabilities, such as nested if / else 
blocks.

>I just checked the IANA registry of Sieve extensions and it still
>contains only the rfc3028 ones - almost one year after rfc3028 was
>published!

These "Internet Drafts" may not be official documents (actually some have 
expired) but they at least indicate that development is active...

Sieve -- Subaddress Extension
http://www.ietf.org/internet-drafts/draft-murchison-sieve-subaddress-03.txt

Sieve -- Regular Expression Extension
http://www.ietf.org/internet-drafts/draft-murchison-sieve-regex-04.txt

Sieve -- An extension for providing instant notifications
http://www.ietf.org/internet-drafts/draft-martin-sieve-notify-01.txt

Sieve Extension: Relational Tests
http://www.ietf.org/internet-drafts/draft-segmuller-sieve-relation-01.txt

(now expired) Sieve -- IMAP flag Extension
http://www.imc.org/ietf-mta-filters/mail-archive/msg00879.html


>So, while we eventually will have Sieve support, I think it isn't clear
>enough yet as to how that support should look like.

Fair enough. I am interested in implementing it for my own use, so if that 
happens I could bring it back to see if kmail is interested - sound like a 
good plan?

Hamish

(PS. I love the IMAP support now as compared to 2.2 - great job! :)

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]