- From: Brian Stafford <brian stafford office-logic com>
- To: Pawel Salek <pawsa TheoChem kth se>
- Cc: Jules Bean <jules jellybean co uk>,Chris Petit <bluemist1 home com>, Michael Duelli <m duelli web de>,Balsa Mailing Liste <balsa-list gnome org>
- Subject: Re: Filter
- Date: Thu, 14 Dec 2000 14:07:48 +0000
Pawel Salek wrote:
> I wonder how does client-side sieve work? If the mail (downloaded by balsa
> from a POP maildrop) can be piped to sieve-capable delivery agent, there
> is no problem at all: it is sufficient to change "procmail -f" to
> "sieve-mda" and it will work fine (or make this string configurable).
With the CMU Sieve API, a "Sieve interpreter" object is allocated and
callbacks into the application to fetch the message headers and bodies
are registered. Similarly action callbacks are used to implement
the sieve actions within the application. CMU Sieve itself need know
nothing about how the application implements mailboxes.
Unlike procmail or other delivery programs, this is clearly not limited
to appending messages into the mailbox formats the delivery program
understands and then trying to persuade an application to resync with the
mailbox storage. Good example - procmail does not deliver to IMAP served
mailboxes on a remote server, Sieve linked into Balsa would have no problem
with this. Procmail cannot read from one mailbox and filter into others;
again Sieve+Balsa no problem.
> I would be happy to see a separate tool (written in pyton/tcl/whatever,
> perhaps) for configuring your most-favourite-mail-filtering-agent. One
> could choose the MFA in preferences and pressing "configure MFA" button
> would fire proper configuration tool.
My feeling is that Sieve should form the basis of Balsa's mail filtering and
that a GTK interface to Sieve scripts should also be part of Balsa. This
doesn't rule out other filtering mechanisms but sieve should be the default.
> IMO, the choice of MFA depends on environment one works in. sieve is
> probably the future but before it becomes wide-spread, procmail should be
> supported as well.
At a guess, procmail rc files would usually need to be rewritten anyway
since the existing ones are all pre-delivery and Balsa is post-delivery.
I don't think much would be lost forcing users to change now rather than
at some point in the future. Procmail scripts are something of a
write-only language and not very useful or even comprehensible to
non-programmers. It is this class of user who have mostly been denied
the benefits of UA filtering (and are presumably among Balsa's target
audience) due to the lack of easily configurable tools.
] [Thread Prev