'Sieve support in KMail'

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

List:       kmail-devel
Subject:    Sieve support in KMail
From:       Martijn Klingens <klingens () kde ! org>
Date:       2005-06-05 11:06:59
Message-ID: 200506051306.59886.klingens () kde ! org
[Download RAW message or body]

Hiya,

Last week at the KDE PIM developer meeting me, Ingo and Thomas Zander sat 
around to discuss the Sieve support in KMail. Sieve is a language for 
defining filter rules on the mail server, so supporting it would give KMail 
the ability to create server-side filter rules. Sieve is supported by a 
number of mail servers, the most common of them being the Cyrus MTA.

This will be a pretty long mail, so if you have no interest in server-side 
filters at all you can safely skip this mail. If you do have an interest in 
serverside rules, but in protocols other than Sieve you might still want to 
read on though.

Current status
------------------
There is already a bit of Sieve support in KDE. There's the sieve:/ ioslave 
that's being used to manipulate the Sieve filters through the Managesieve 
protocol.

Also, there's the Vacation ("Out of office reply") support in KMail 3.4, which 
is also based around Sieve and kio-sieve. It uses the Sieve parser that's in 
libksieve, so parsing the grammar of the language is basically done already.

What is not there, and what is my personal itch for working on this, is the 
support for managing serverside filter rules from within KMail. KMail's 
filter dialog might not be the most userfriendly one around (though trunk is 
massively improved to 3.4 though by splitting of the Advanced stuff into its 
own tab!), but having to edit my filter rules through Squirrelmail's 
Avelsieve plugin is getting more and more cumbersome the more filters I have.

KMail doesn't have the notion of 'serverside' filters yet, so an extra 
abstraction layer is needed to make it distinct between local and remote 
filters.

Short-term goals (KDE 3.5)
----------------------------------------
Given the little time I can afford to spend on KMail I don't expect to have 
any real Sieve support in KDE 3.5. However, a lot of the groundwork can be 
done already without ending up with 'half-finished' features by the time we 
are nearing the release.

If needed I can switch to a work branch in svn anytime, but I want to use the 
3.5 branch as long as possible because it ensures a lot more testing and 
saves me all the merging headaches.

I'm not going to list the goals in more detail, since it's basically the 
subset of the mid-term goals below that I can implement in the 3.5 timeframe.

Mid-term goals (KDE 4.0)
----------------------------------------
For KDE 4 I hope to have full support for Sieve in KMail. This boils down to 
the following:

- Sieve only supports a subset of what KMail can do with filters. The first 
filter that is not supported serverside will break the filterchain, and all 
subsequent filters are handled clientside. GUI-wise this is implemented by 
prefixing all filters with an icon that can warn the user when something is 
wrong and detailed information when the user clicks the filter in question.

- Any mail filters that are created in KMail and can also be handled by Sieve 
are uploaded to the server automatically. The 'server supports sieve' 
checkbox controls the use of Sieve. Filters are also created clientside, to 
cover the case of multiple accounts of which only a subset supports Sieve.

- Ideally the uploaded filters are optionally stored in a format compatible 
with other clients. However, some clients use really strange syntax to store 
Sieve scripts. (E.g. Squirrelmail's Avelsieve doesn't have a real Sieve 
parser, but stores the filters in its own format in a comment field. Changing 
the Sieve filter without updating the comment breaks the plugin.) Therefore, 
it's something I would like to have, but might not be able to achieve. Given 
the Sieve support of other mail clients out there we can get away with this 
at the current point in time.

- The Sieve filters will only support what KMail already supports as filter 
criteria. Sieve has quite a number of extensions, and some of them are not at 
all supported by KMail. The ability to refuse mail for example can 
technically be implemented reliably in Sieve (depending on the SMTP server 
implementation) and as such we'd need to reintroduce the Bounce action again. 
For KDE 4.0 I don't plan to support all those. If someone gets around to do 
it, cool, but it's not an official goal of mine.

- Ideally any changes done on the server from another client are merged back 
into KMail. This has a couple of technical challenges though, notably filters 
that use Sieve syntax that we don't support yet. I'm not sure what to do with 
this. There are quite some options here, and I'm still far away from this 
problem to really worry about it already.

Long-term goals (KDE 4.x)
-------------------------------------------------------------------------------
There are more kinds of serverside rules besides Sieve. Think procmail, MS 
Exchange or Novell Groupwise for example. It would be nice to support those 
as well, which requires the filter code to support even more abstractions. I 
am not going to implement filters other than Sieve, but I'm happy to help 
others to create the abstractions needed. (Writing the code in a generic way 
from scratch is possible, but a lot more work and I prefer being pragmatic 
here.)

Other stuff that fits here are advanced Sieve features that are nice to have 
but not critical enough for the first public release.

Final words
-------------------------------------------------------
I have the nagging feeling that I forgot some more stuff, but I can't figure 
out what. If you have questions, ask. Otherwise I'll continue my work.

Once again, don't expect too much results soon. It's a fair amount of work and 
I don't have much time to spend on it. This is more a heads-up that I'm 
working on it. If you want to help out (the discussion came up on IRC a 
couple of days ago, so apparently there is some more interest), drop me a 
line so the work can be coordinated. This also applies if you have interest 
in filters != Sieve because then much of the abstraction work for that has to 
be move forward from KDE 4.1+ to 3.5 or 4.0.

-- 
Martijn
_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel
[prev in list] [next in list] [prev in thread] [next in thread] 