In a message dated: Mon, 29 Jan 2001 10:19:55 EST
Jeffry Smith said:
>One thing I'm still waiting for in any e-mail system that includes filtering
>is a tie-in to procmail. Why write your own filtering module instead of a
>front end to procmail (hm. Tie exmh to dotfile-procmail, since both are
>tcl/tk?).
Supposedly the latest release of exmh (2.3) has this built in. However,
here's the problem I see with client "built in" filtering capability; it
relies upon the client being up and running to filter mail. That means that
everything goes into your normal spool directory. The client then needs to
grab that mail and filter it. No running client = no filtered mail. To me,
this is a problem, and one easily solved by de-coupling the filter engine from
the mail client and having it invoked by the transport agent.
Many people may be perfectly content with only filtering mail while their
client is up and running, in which case, the coupling of the client and
filtering agent is fine. However, consider the following scenario:
- You get 400+ e-mails per day
- You're going to be out of the office for 2 weeks
- You want 'vacation' to auto-respond to your mail, but not to
any "list" mail
- You may want to connect via dial-up/vpn and check to see if you
have any "important" mail
Under this scenario, all your mail is either in:
- the default mail queue (usually /var/spool/mail/<username>
- or being filtered because you've left your mail client running.
Leaving your mail client running so that it filters your mail is a risky idea;
what happens if the machine your client is running on crashes while you're
away? You've then got unread mail in 2 places, the default mail queue and
your pre-sorted folders.
If you don't leave your client running, then you've got (400+ * X days) worth
of mail in the default queue. Which means when you fire up your client, you
have to wait for it to suck down all that mail and filter it before you can
really do anything. Over a slow dial-up link you may not want to wait that
long (I'm assuming that the client is being run on the remote machine, not the
local, but regardless, over a dial-up link, it's all slow).
Now, if the filter process is de-coupled from the MUA, then your mail is being
filtered in "real time". When you log in, your client sees the mail after
it's been filtered; there's no waiting. You then can proceed to look at the
mail you want to look at with whichever MUA you wish. For example, I have
procmail sort all my e-mail in "real time". I log in at work and fire up exmh
and read my mail, it's all filtered. I go home, sometimes I fire up exmh from
my workstation with $DISPLAY pointing at my home system, and everythings
pre-filtered. Other times I'm lazy, and I just use the command-line 'mh'
commands. I see exactly the same view as I would under exmh, but exmh isn't
running anywhere. Other times, for kicks, or because I'm bored, I fire up
'mutt' in "mh mode", and see the same view.
With your filtering enging de-coupled from the MUA, you get total MUA
independance. To do otherwise is to increase your dependance upon one
particular MUA. Some may find this acceptable, others like me, find it a
hinderance.
Just my perspective and $.05 worth :)
--
Seeya,
Paul
----
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
