Re: Fwd: [ANNOUNCE] : Filters patch against 1.2.0 [e allaud wanadoo fr]
- From: Brian Stafford <brian stafford uklinux net>
- To: "M . Thielker" <balsa t-data com>
- Cc: balsa-list gnome org
- Subject: Re: Fwd: [ANNOUNCE] : Filters patch against 1.2.0 [e.allaud@wanadoo.fr]
- Date: Mon, 24 Sep 2001 15:38:37 +0100
On Mon, 24 September 15:04 M . Thielker wrote:
> Hi,
>
> On 2001.09.24 10:28 wil wrote:
> > I agree that we should leave filtering to procmail, it is designed for
> > that
> > and is very good at it. However, granted that there may be some new comers
> > who need the UI, Raven's suggestion of a separate frontend / UI for
> > procmail config would be cool. (It might have already been done).
>
> No, I cannot agree with that. Most important is the fact, that procmail does
> not have a way to use IMAP mailboxes. Second is the convenience of, for
> example, having context menus on adresses with options like "Sort all mail
> from this address into folder..." - not easily possible with procmail. Balsa
> is, IMHO, _not_ just for us here who know what procmail is, but it's also
> for users who formerly used Windows, installed a Linux distribution
> out-of-the-box and want to do email.
> I still believe that procmail support should be in Balsa as well, for
> procmail can do things that would be hard or impossible to implment in
> Balsa, or aren't desired there (bloat is the word).
> So, easy filtering within Balsa for those who either need to have filters
> work on IMAP mailboxes or don't know about procmail, external procmail
> filtering for those who need the extra funtionality or are already using
> procmail and want to keep it, that's the way to go, I think.
>
> Melanie
I agree with Melanie here - except for the procmail bit. Procmail is
a horrible program and it should not be used if it can be avoided.
For filtering within balsa why not go with the standard and use Sieve?
Its described in RFC 3028 and it is a proposed standard. An implementation
of sieve is available in the Cyrus project. It is used by the Cyrus imap
server.
Furthermore sieve is designed to be usable both within a MUA and an MTA.
There is a sieve upload protocol for use with MTAs and IMAP servers that
support it. If balsa had a GUI for generating sieve filters and support for
the sieve upload, not only could it specify its own internal filters but it
would provide an interface to local MTA and IMAP server filtering.
Sieve is an elegant language whereas procmail filters are written in modem
noise (just like sendmail rules). The way that procmail REs are used to
match header lines is just wrong. Why else are they so complex? Lets move
on to read/write languages, not write-only ones. I consider that effort
producing a frone end GUI for procmail is wasted effort. Put the effort
into supporting sieve instead.
Please don't respond by saying there isn't much deployment of sieve.
Sieve is still quite new. The IETF estimates taht from an RFC's publication
there is a delay of at least 3 - 5 years to moderate deployment. Someone
has to go first and I don't see why that someone shouldn't be the open source
community.
Surely Balsa must be one of the more influential MUAs in the open source
world? Let's lead by example for once instead of following the crowd.
The greatest barrier to deployment is that everyone sits around waiting for
someone else to go first!
Brian Stafford
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]