Re: Filter

[Brian Stafford <brian stafford office-logic com>]

First, I forgot to mention the filtering language being developed
on the ietf-mta-filters list is called Sieve.

Jules Bean wrote:
> 
> On Wed, Dec 13, 2000 at 03:35:06PM +0000, Brian Stafford wrote:
> > It cannot be used to filter mailboxes fetched from a POP server.
> 
> Many people happily and succesfully use a fetchmail/procmail
> combination to satisfy all their multiple email account filtering
> needs.

This is true - I do it myself.  fetchmail fetches mail using POP and
transfers it to sendmail using SMTP which delivers the mail using
procmail; pre delivery filtering again.  Somewhat round the houses,
not functionality built into procmail and certainly not functionality
in the user agent.

> Personally, I like 'during-delivery' mail filtering.  In particular, I
> don't need sophisticated mail-filtering in my MUA, because I don't
> want my MUA to do that job.  If my MUA becomes my filterer, then I am
> forced to keep using that MUA.

Using Sieve would break that dependence.  As it becomes more widely
implemented, the scripts can be used with other MUA ot MTAs.

>  I prefer to be able to use different
> MUAs in different locations (e.g. at sites without my favourite MUA
> installed). For that reason, I use a form of 'during-delivery' mail
> filtering, and exim filter file. Then I use IMAP to access mail from
> any host.

I like to keep my mailboxes on an IMAP server where possible.  Pre-
delivery filters are good for this type of thing since the mail is
filtered before the user agent gets involved.  However sometimes I move
mail between mailboxes and sometimes I want to automate this.  User
agent filters, especially if they can be easily constructed would be
useful for this.

> I think the dominant paradigm is store-mail-locally,
> access-new-mail-with-POP.

IMAP is a mailbox access protocol.  The server maintains the mailbox
access and storage.  The client is not ever required to store mail
locally, the server must provide long term mail box storage.

POP, OTOH, is much simpler and is only useful for accessing a temporary
holding area for mailboxes prior to the mail being downloaded by a user
agent.

Since most people download their mail from their ISP, POP is more
appropriate than IMAP - probably why ISPs dont bother with IMAP.

>  IMO, there is currently an elegant solution
> to that problem with fetchmail and procmail. 

A solution.  I can't bring myself to say that anything to do with
procmail could be described as elegant!

> If those are too hard to
> configure, the right approach might be to implement nice front-ends to
> fetchmail and procmail, and let the MUA deal with the things it's good
> at.

Which brings me back to Sieve.  Sieve is a much more elegant way to
specify mail filters than procmail.  I believe that it is inherently
more flexible and reliable, easier to generate from a GUId front end
and the design process has seen significant peer review within the
email standards community.

Lets forget the procmail dinosaur and go for the Sieve mammal.  Put the
effort into implementing a GUI for Sieve.  The generated scripts could
then be used directly or passed off to an MTA with Sieve capability (e.g.
sendmail + Cyrus IMAP's deliver) or even to a third party product
implementing sieve.

--
Brian Stafford