Re: Filters [Was [ANNOUNCE] Filters patch

[Brian Stafford <brian stafford uklinux net>]

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