I mentioned this before (
http://lists.exim.org/lurker/message/20100126.210310.48d418c8.en.html ) but
never took it any further, i.e. opened a bug or anything. So here it is for
discussion.
The problem basically is that:
* there are two different kinds of "string list" used in Exim;
* the spec doesn't differentiate between the two kinds;
* the behaviour of one of the two kinds is non-trivial and not documented in
the spec.
Detail:
On the one hand we have "plain" string lists, which are never subject to the
matching code in match.c: e.g. tls_on_connect_ports, local_interfaces. The
list construction logic applies (as per spec "6.19. List construction" and
"6.20. Changing list separators") but once the strings have been parsed out
then the logic applied to each string is specific to whatever option is being
set (e.g. for tls_on_connect_ports each entry in the list must be an integer).
On the other hand we have "matching" string lists against which the matching
code fires with type==MCL_STRING (e.g. acl "authenticated", acl "encrypted").
In these lists, various special things happen that don't happen for "plain"
string lists. See the spec, "10. Domain, host, address, and local part
lists", except what you want to read about is a /string/ list, which isn't
documented.
Hence the odd behaviour discussed in the above exim-users thread.
So what's the solution?
Clearly we can't just change "matching" string lists into "plain" string
lists, because that would break the (defined) behaviour of things like
"authenticated = *" in ACLs. So for sure, the spec should be updated to
differentiate between the two different kinds of string lists, and the
behaviour of "matching" string lists needs to be documented.
What I'm not so clear on is whether or not the behaviour of "matching" string
lists should actually change.
Thoughts?
--
Dave Evans
http://djce.org.uk/
http://djce.org.uk/pgpkey
