> >> There are other ideas buried in the bugs which are more far-reaching.
> >> Reducing the number of languages involved in an exim config was one (I
> >> count: ACL, retries, router-chain, authenticators, exim-filter...).
> >
> > If one is going to go for wholesale configuration rewriting, I would
> > agitate for creating or embedding a real programming language. String
> > expansion plus carefully ordering routers/ACLs/etc can do a great deal,
> > but it is not exactly clear and I think it would be quite improved if
> > you could directly express ACL logic and routing logic.
> >
> > (I suppose the modern low-ish-effort version is embedded Lua with
> > hooks and so on exposed.)
>
> Interesting. What do you feel is lacking from ACLs in making them
> "a real programming language"?
>
> Same question for routers?
Used with their full power, routers encode a series of decisions about
how to handle and manipulate email addresses. However, this encoding
can wind up being extremely unclear, since it is embedded into complex
'condition =' clauses on multiple routers instead of being expressed
clearly and directly. For example, here is part of the conditional
rules for how we deliver email to users:
- if email is not tagged as spam:
- if the user has $HOME/.forward-nonspam, it goes through that
- if the user has $HOME/.forward and no .forward-nonspam, it goes
through .forward
- if email is tagged as spam:
- if the user has $HOME/.forward, it goes through that
- if the user has $HOME/.forward-nonspam and no $HOME/.forward,
the email is discarded
- in either case, if the user has neither version of .forward, the
email is delivered to /var/mail/<user>
And in both .forward variants, if you put your own address in
your .forward or .forward-nonspam it means 'just deliver to
me normally' (in the traditional meaning of this). Eg, it's
valid to have a .forward-nonspam of 'cks' and a .forward of
'/u/cks/Mail/low-priority-spam', so non-spam gets delivered
to my inbox and spam gets written to a file.
It's certainly possible to express this logic in the form of routers
with 'condition =' expressions; we do today. It is, however, not at all
obvious what the logic atually is from reading our exim4.conf (well,
apart from the comments), and there are a number of subtle traps in the
ordering of routers and the exact conditions required. I wrote up one
such trap that we stumbled over here:
https://utcc.utoronto.ca/~cks/space/blog/sysadmin/EximForwardGotcha
I think that being able to express such logic in a direct way would
help make more complicated Exim configurations easier to create,
read, and validate.
Similar issues with complex conditions can arise in ACLs. On our
inbound MX gateway, we have a somewhat tricky set of ACL rules that
are designed to determine the minimum spam filtering level that all of
the recipients of a message have opted into; if all of the recipients
have opted into a sufficiently high level, we can do various sorts of
DATA time scanning and rejection of messages. This works, but it would
be rather simpler if it was easier to express logic directly and to
directly manipulate things like ACL variables with a language that was
really designed for this.
- cks
