In message <Pine.SOL.3.96.970422082921.8497C-100000@???>,
Philip Hazel writes:
> ... but require_files is already expanded, so that should work!
Yep, it *does* work with require_files as I said, because that option just
happens to expand its string argument --- indeed, it is the *only* generic
director option that does so according to spec.txt, so I had no option but
to use it despite the contortions of having to make it fail by supplying it
with a path "/fail" so that it would barf because of file non-existence.
[I think you mistook my reference to "local_parts" as an intention to
validate local parts on input. Nope. I was merely trying to use the
fail-director functionality of the option by expanding its argument to
a string that does NOT match the local part, but it didn't work because
the string doesn't get expanded.]
I could have used "local_parts" or "prefix" or most other options that
can cause director bypass by making their matches fail through appropriate
use of $lookup return values if only their argument string-lists were
expanded, but they're not, according to the spec, which is precisely the
point that I was making. The existing design makes it quite difficult to
use the string and lookup facilities much because there are so few places
where strings are expanded. More (preferably universal) expansion would
be a good thing to make string behaviour consistent throughout the config,
and I bet you wouldn't notice the impact on performance at all simply
because MTA performance is always very i/o-intensive.
> > I hope that this explains it a bit better, Philip. Any thoughts on
> > that generic failure control mechanism that I mentioned? Exim seems
> > to be growing lots of special cases but few generic mechanisms. If
> > you gave us some more generic machinery, it might *reduce* your high
> > workload as well as making Exim more orthogonal in its configuration.
>
> I certainly agree with that concept. I do try to think of generic
> mechanisms where I can, and they do indeed help.
Thinking a bit more about what I proposed in that message, the statement
require "<condition-string>" "<failure-reason-string>"
isn't consistent with existing Exim configure syntax, but it would be
consistent and much clearer if one changed the above to (say)
reason = "<failure-reason-string>",
require = "<condition-string>"
so that if the "require" fails then the previously-set reason is used
in the error response if no_more is in operation. One might extend this
generic mechanism in a variety of ways that could prove useful, eg.:
failcode = "<failure-code-string>"
errors_to = "<address-string>" (not just in forwardfile)
use_rule = "<rewrite-rule-label>" (needs rw rules labeled)
By the way, errors_to is shown as expanded in the example for aliasfile
but is not described as expanded in the spec, nor in that for forwardfile.
And, even more generic, harking back to our discussion on rewriting,
%<variable-name> = "<variable-value>"
where the %<variable-name> is used on startup to create a per-message
variable which then becomes available across all drivers to control
behaviour as the message passes through the MTA. In the simple case
addressed last week, this would allow booleans asserted in a director
to control a new phase of rewriting on output, eg. to tailor the sender
address as a function of the destination domain. The variables could
either be stored in the message envelope file or in a dbm database,
and a dynamic variable name store wouldn't be needed because the set
of variables defined in the config is fixed.
So many ideas, so few people to implement them ... :-)
Regards,
Rich.
--
########### Dr. Rich Artym ================ PGP public key available
# galacta # Email : rich@??? 158.152.156.137
# ->demon # Web : http://www.galacta.demon.co.uk - temp page only
# ->ampr # AMPR : rich@g7exm[.uk].ampr.org 44.131.164.1 BBS:GB7MSW
# ->NTS # Fun : Unix, X, TCP/IP, kernel, O-O, C++, SoftEng, Nano
########### More fun: Regional IP Coordinator Hertfordshire + N.London
