Re: [EXIM] dot-qmail director

Top Page
Delete this message
Reply to this message
Author: Philip Hazel
Date:  
To: Jason Gunthorpe
CC: Piete Brooks, exim-users
Subject: Re: [EXIM] dot-qmail director
On Tue, 17 Mar 1998, Jason Gunthorpe wrote:

> But, I would like to see qmail support in exim because,


I would not object to this, especially if it could be fitted in in some
way that didn't need always to be included in the binary, e.g. as a new
director (as I think you suggested). However, I do not at the moment
have the time to study the qmail specification to determine what would
need to be done or how to do it.

>   1) The exim format provides filtering, we are not interesting in
>      filtering.
>   2) The qmail file is easy to parse correctly in all cases, no
>      'guessing' as with .forward files


I guess :-) you are referring to choosing between an address, a file
name, and a pipe. There is no guessing in Exim filter files, just in
traditional .forward files, whose specification Exim inherited.

>   3) The qmail file supports the extension mechanism as a standard feature,
>      ie jgg-blah@??? can be handled by it's own .qmail file


Note that in Exim this can also be handled by its own .anything-you-like
filter or .forward file. It is all a matter of the Exim configuration.
I'm not quite sure what you mean as "standard". It isn't in the default
exim configuration, but one that supports it is easy to construct.

>   4) The qmail file sets a specific set of environs to make writing 
>      decision filter scripts in shell simple + fast.


I don't have any knowledge of qmail, so I can't really understand what
this is referring to.

> Exim's filter mechanism I would see as being totaly orthogonal to this and
> more complex. That is, the exim filter mechism I see as being more a
> replacement for procmail - the qmail stuff adds features to the mailer
> that are not otherwise possible (#3 pretty much)


Yes, the filtering is sort of procmail-ish, except that it happens at a
different time. Exim can, of course, be run using procmail for local
deliveries. If it's the "one file per address" feature of #3 that you
want, Exim can already do that, as I said above.

> both good and can both co-exist happily, is there any reason exim cannot
> support both?


I can see no reason in principle, but without knowing the specification,
I do not know how great a job it would be in practice. If it turns out
to be, in effect, just a different "forward file language" that has to
be interpreted then it would not be a huge job, by the sound of it.

Perhaps you could summarize to me (not the whole list) what the main
features are?

Philip

-- 
Philip Hazel                   University Computing Service,
ph10@???             New Museums Site, Cambridge CB2 3QG,
P.Hazel@???          England.  Phone: +44 1223 334714



--
*** Exim information can be found at http://www.exim.org/ ***