Re: Filter

["David W. Jablonski" <dave energyfinancesolutions com>]

As I stated above - I totally second this.

Brian Stafford wrote:

> 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
> 
> _______________________________________________
> balsa-list mailing list
> balsa-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/balsa-list


-- 
David W. Jablonski
Wisconsin Energy Conservation Corporation
Systems Administrator
RHCE, MCSE
www.weccusa.org
www.energyfinancesolutions.com