Re: Filters [Was [ANNOUNCE] Filters patch
- From: Brian Stafford <brian stafford uklinux net>
- To: Emmanuel <e allaud wanadoo fr>
- Cc: balsa-list gnome org
- Subject: Re: Filters [Was [ANNOUNCE] Filters patch
- Date: Thu, 27 Sep 2001 14:04:21 +0100
On Wed, 26 September 16:39 Emmanuel wrote:
> Hi all,
> just to sum up how I see filters for now and how they should evolve (the
> thread was so long that I think this is necessary, at least for me).
> First I think the real need for built-in filters in Balsa is to filter
> mailboxes to find messages meeting certain criteria (typically when you
> have huge mailboxes, it's now almost imposible to find a precise message or
> even a thread).
Not just that. Sometimes there is a need to filter a large mailbox to "fan
out" its contents to other mailboxes. Having done that the original mailbox
might be disposed of. I would also like to be able to eliminate duplicates
when doing this (i.e. two messages with the same Message-Id but received via
different paths). This is quite different to searching as you describe
and is more like filtering during delivery. Unlike delivery, only a UA
can do this.
> And if you have coded filters for that purpose, it is not so much work to
> have them filter on incoming mails (pop3 is OK for now, I don't know how to
> do it for others, eg this seems impossible for local mailboxes). Obviously
> this is not a replacement of procmail, it's an alternative. We can even
> export balsa filters as a procmailrc file if this seems useful.
I still think any support for procmail is a retrograde step. Besides
REs are hard to generate automatically or to present meaningfully via a
GUI interface. I feel that the effort involved in generating procmailrc
files would be better directed at replacing the procmail program with a
sieve capable version. Assuming a sieve API I reckon re-implementing procmail
amounts to the same effort as generating scripts that it can use. Furthermore
this path leads to standards compliance and interoperability.
> About sieve format : I think for now that we can export built-in filters to
> sieve, and even store built-in filters in sieve format. But I think that
> this should be done only if we want that balsa built-in filters can be used
> for delivery (ie in a MTA-MDA fashion). Indeed sieve is a bit over-design
> for "message lookup" filters, IMHO.
The point about sieve is that it is universal and it is a standard. Whether
sieve is over-designed for one particular application is irrelevant. I don't
think there is any need to worry whether sieve is "too much". There will always
be a user who needs the flexibility and for whom it does not go far enough.
Brian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]