Re: Filtering Options?

[Thomas Kim <takim fas harvard edu>]

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.

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.

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.

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.

Also grokking code,

tom