Previously, Nick Jennings wrote:
:>
:> Argh! I despise procmail, yes its powerfull, and can do alot, but
:> it's severly anoying. I think it _IS_ a mail clients job to do filtering,
:> after all, it checks the /var/spool/mail/<username> for new mail and drops
:> in in your inbox, if it drops it in the inbox, why not instead drop it in
:> some other box and let you know?
Uh, no, a mail client _does not_ check for new mail and drop it in my
inbox - a mail client has nothing at all to do with the delivery of mail.
The MDA does that (sendmail, procmail, fetchmail, etc).
:> Thats why I started writing my own mail client, so the filtering
:> would be easy to use, and built into the client, so you dont have to hassle
:> with procmail. Since I started using Mutt, I stopped developing this mail
:> client, but now I might start again, or maybe add this feature to mutt, is
:> there a reason why this is something that is continuously not a feature in
:> UNIX mail clients? yes procmail is powerfull, but its far too much of a
:> hassle for just setting up a simple filter, something in the muttrc like
:> this:
It's not a feature because it's not the job of a mail client to deliver
mail. There are a lot of things mail clients don't do - delivering mail
is one of them.
:>
:> newmail-hook ([EMAIL PROTECTED]) +mutt-users-mail
What's so hard about:
:0:
* ^Sender: [EMAIL PROTECTED]
mutt-users-mail
I really don't think that was too hard.
:> would be simple enough and very easy to impliment. It could just search the
:> headers for that pattern, not even the body (since that would slow it down
:> more). Sure its not as powerfull as procmail can get, but its certainly
:> better for simple filtering wich is what most people need to do anyways.
It may be simple and easy to impliment, but it would be bloat and you'd be
making mutt do something it is not meant to do.
Shawn
--
Predestination was doomed from the start.
