Re: Filtering Options?

[Jules Bean <jmlb2 hermes cam ac uk>]

Thomas Kim wrote:
> 
> On Thu, May 20, 1999 at 03:32:09PM -0400, ryan wrote:
> > My question is this: so many clients try to re-invent the wheel by coding
> > their own filtering system, something that is admittedly kind of
> > complicated to pull off right -- everyone has their own preference it
> > seems. But procmail is an existing filtering system that has just about
> > everything you would need. Why couldn't Balsa just have a GUI frontend to
> > ~/.procmailrc? The problem is when Balsa is the MTA, procmail wouldn't be
> > invoked... but it could be.
> 
> I had been thinking along similar lines when this issue came up, but in my
> opinion the MUA's role in filtering is distinct from procmail's role because,
> as I understand it:
> 
>         (1) procmail will only act to pre-process mail
>         (2) whereas, it is desirable for the MUA to be more flexible about when
>           mail is shuffled (after being read, after closing, per user
>           command?)  In general, pre-processed filtering seems to me to be a
>           different beast than MUA filtering.
> 

But the MUA can pipe messages back through procmail for later
refiltering.

> Also, someone wrote earlier that they preferred to rely on IMAP's server-side
> filtering functionality.  I'm not familiar with how IMAP handles this, but I
> think client-side filtering is still better suited for reason (2).  Filtering
> in the client also gives the same interface to filtering for both IMAP and
> POP3.

Well - client-side and server-side filtering both have obvious
advantages.  You've listed the advantages of client-side.  The advantage
of server-side is simply that you don't have to download all the
messages!

I get, when I'm on my normal complement of mailing lists (I'm cut back
right now because it's exam term) more than 400 messages a day.  If I
had to download all those messages before they were filtered, accessing
my mailboxes over a modem would be painful.  As it is, when I access my
mailbox over a modem, I can just look at the more interesting mailboxes,
and let the less interesting, higher-volume mailboxes wait until I have
a better connection/cheaper phone calls/more time.


> 
> Also, I agree that POP3 shouldn't be abandoned completely, primarily because
> it would make the messages interface "uneven" in the sense that different
> implementations of the same interface would give different capabilities.  Then
> again, I'm not sure how even the implementations are now.  And I do prefer
> IMAP.

POP3 and IMAP have very different capabilities.  That's the thing that
makes writing a common interface for them tricky.  Nonetheless, I agree
that POP should not be abandoned.

> 
> Finally, I don't think the gnome-mailer project should give balsa too much
> distress because I very much like the front-end to Balsa.  Even if it looks
> like gnome-mailer might displace libmutt, the front-end code itself is
> worthwhile of keeping.

Yeah - but to be honest, writing a front-end doesn't take very long,
anyhow.

Nonetheless, I'm sure balsa's here for a while.

Jules

-- 
/----------------+-------------------------------+---------------------\
|  Jelibean aka  | jules@jellybean.co.uk         |  6 Evelyn Rd        |
|  Jules aka     |                               |  Richmond, Surrey   |
|  Julian Bean   | jmlb2@hermes.cam.ac.uk        |  TW9 2TF *UK*       |
+----------------+-------------------------------+---------------------+
|  War doesn't demonstrate who's right... just who's left.             |
|  When privacy is outlawed... only the outlaws have privacy.          |
\----------------------------------------------------------------------/