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/ ***
