> > Please don't. I suggested before to separate the code that communicates
> > with spamd from the option parsing code. To stay compatible, first try
> > to parse options using the old syntax. If that fails, parse the new
> > syntax, whatever that may be. I suggest attribute-value pairs.
> > That's both backward compatible and easy to use.
>
> Tom's suggestion is, however, more in the spirit of the rest of exim's
> current configuration philosophy.
I disagree. Exim uses positional arguments for expansion operators,
which could be viewed as functions, where most people are used to
positional arguments, but it uses braces instead of colons or spaces.
With very few exceptions, Exim uses colons between list elements, where
all members of the list are of equal type. If positional arguments are
confusing, because a bunch of options are possible, it uses tagged
arguments as attribute-value pairs. These are separated by white space in
expansions, and by slashes in ACL conditions:
The query is a positional argument, it contains the tagged arguments
"user" and "pass", because these are optional:
${lookup ldap
{user="cn=manager,o=University of Cambridge,c=UK" pass=secret
ldap:///o=University%20of%20Cambridge,c=UK?sn?sub?(cn=foo)}
{$value}fail}
The verification type is a positional argument, tagged arguments
are defer_ok and callout:
verify = recipient/defer_ok/callout=10s,defer_ok
Actually, I wonder why it is not
verify = recipient,defer_ok/callout=10s,defer_ok
or
verify = recipient/defer_ok/callout=10s/defer_ok
Perhaps someone else can answer that.
Consider LDAP lookups: I can specify a global list of default servers
(list elements are names, not IP numbers, with the port being specified
after a doubled colon - exiscan uses IP numbers and a space for the port),
but I can also specify a particular LDAP server in LDAP URLs. Additional
parameters, like user credentials, are written as attribute-value pair
after the LDAP URL. I don't have to set a global variable only to use
a lookup in the default server list to return the server I want for one
query.
If Exiscan followed the Exim configuration philosophy, it would use:
scan = spam/spamd=/unix/socket:host1::port1:host2::port2,user=nobody,defer_ok
I could use this for the server list
spam_default_server = /unix/socket:host1::port1:host2::port2
thus being able to leave the spamd argument away in ACL conditions.
Instead Exiscan uses:
spamd_address = 192.168.2.10 783 : 192.168.2.11 783 # unix sockets forbidden in lists
spam = nobody:true
It is different from other parts of Exim, and it does not allow to use
different servers in different queries.
Michael
