> Okay, I have zero interest in filtering based on anything other than To
> Address, everything else can be handled universally by procmail.
Fine -- do it as you want.
> [Why exactly would I want to use exim's filters when I have procmail?]
It's the old question of how big to make the core object, and how much to
devolve to separate processes.
My preference is to keep the important bits fully integrated into the core, so
that error processing can be slicker, more reliable, etc ...
I know of many systems where the interface to external programmes cause
problems in error conditions ...
> So along with generalized filtering exim's forward files provide way to
> separate out extension adresses.
Yes.
> That is nice. But it doesn't help me replace qmail :>
OK -- I missed the point -- what is it you still need to replace qmail ?
> <shrug> The qmail file+procmail combination can do most everything exim's
> filters do
I suspect both can be made to do almost anything [ if one has a sufficiently
contorted mind ], it's a matter of which is clearer to the user.
[ and as above -- whether you trust the interface to cope with errors ]
exim's filtering code started out as a "conditional list of recipients", and
grew ...
> and is simpler to implement in the MTA.
Agreed.
>>> Further more it is substantially more likely for other mailers to
>>> implement support for .qmail (and do it correctly) than it is for exim's
>>> filter mechanism to be supported.
>> Quite possibly.
>> But are there others yet ?
> There is qmail
That I cannot deny ... :-)
> and exim could likely do it quite easially.
OK -- so it's just qmail at the moment ....
> That is 2.
:-)
> Like it or not qmail is becomming widely used
Sure -- so is exim.
> and supporting qmail files would make exim much more attractive to such
> sites.
I'm not sure exim want to "poach" qmail users.
I see it as qmail and exim both wanting to move people off sendmail, but not
fight each other. Horses for courses, but anything is better than sendmail :-)
> If there was some other mailer that supported qmail files and was DFSG free I
> would not be even thinking about Exim.
OK -- so qmail files aren't exactly the new standard yet ...
> To make something usefull someone has to take the first step.
Not sure which step that is ...
> Apparently not, exim can do most things qmail can with it's filter files
> but it is not compatible with anything.
... apart from sendmail, which I agree isn't really "filtering" ...
But then again, neither is qmail ...
> I do not understand this desire to create difference
There is no desire to *CREATE* differences.
There is work involved in *ADDING* new facilities.
Someone has to do them. You don't have the time. PH10 will do almost anything
people ask (he's too helpful!) so I'd rather try to see if qmail files is a
good use of his time.
I get the impression that you think it is, so give him the spec, and I suspect
it'll appears in some future release ...
> when you could easially support something that is actually fairly decent and
> help improve things.
If you gave PH10 the (clean) code to do it, I'm sure it would be in a release
in a week or so. However, if PH10 has to work out the spec and implement it,
it'll take longer.
> DJB I am sure will never support exim's filter methods
Ahh -- PH10 is more user friendly, so increase his workload :-)
> <shrug> What other features are you going to add?
I assume PH10 still has a *LONG* list !!
> A potential user asked for one, I hope you will give it due consideration.
Where "you" is PH10 -- indeed -- sounds like he has (as always).
But he needs help -- I assume you'll reply to him in private as requested.
--
*** Exim information can be found at
http://www.exim.org/ ***
