>Amalgamating directors and routers
>One big proposed change is the abolition of the distinction between
>directors and routers. They started out very different, but have grown
>more and more similar. There is a lot of duplication in the code, and it
>also seems quite hard to explain the distinction to new Exim users.
Me among them... I'm still not quite sure I've got it right.
>What I propose is to abolish the word `director', and just call all of
>them `routers', unless anybody can come up
routers is good.
>I have an idea for a new, more general feature. I propose a new option
>called domain_list, which takes as its value a name and a string. So, for
>example, you could say
Good.
>Changes to conditional running of routers
>The way that various conditions are applied to routers (and directors in
>the `old world') is complicated, for no particular good reason, as far as
>I can see (it just happened that way). Conceptually, there are three stages:
>· Tests are done before running the driver (e.g. tests on the
>domain). If any of these tests fail, the driver is skipped, and the next
>driver is run.
>· If the initial tests succeed, the current driver is run.
>· If the driver declines to handle the address, more tests are done
>to decide whether to run the next driver or not. At present the only test
>is on whether more is set.
IMO it would be good to make this a lot clearer in the docs, and perhaps
even in the config. Would the following be a good start?
remote_domains:
driver = domainlist
preconditions {
route_list = * $domain bydns
domains = ! +local_domains
}
action {
transport = remote_smtp
}
onfail {
no_more
}
end remote_domains;
How about being able to include in 'onfail' another transport/router
specification:
action {
transport = remote_smtp
}
onfail {
router = make_backup
}
>The confusion is that most of the conditional options such as domains and
>local_part act as `initial tests', but require_files and senders don't.
>(It is documented that verify_sender and verify_recipient are also like
>this, but in fact the documentation is wrong.) If either of the
>require_files or senders tests fail, it is as though the driver declined,
>and the more option is inspected. Of course, in many cases, more is set
>true, so this anomalous behaviour doesn't make any difference.
>Nevertheless, I think things should be regularized.
I must admit most of this has gone way over my head :-(
>Revamping the old directors
>1. A router called redirect
>2. A router called accept
This is good and also clear.
>the same way as is proposed for the new redirect router above. They are
>all replaced by route_data, which is expanded to yield a single set of
>routing data.
I am worried that data (below) and route_data here will become catchall for
loads of stuff and consequently very confusing for new users like me. I am
still wary of the db & expression syntax, partly because I find it unclear
and not very easy to remember. Although I see that "data" is a possible eay
to go, perhaps a more verbose expression syntax (perhaps in addition to,
rather than replacing) could go along with it? For example, from
system_aliases, below:
> data = ${lookup{$local_part}lsearch{/etc/aliases}}
could become
data = from key "local_part" lookup in file "/etc/aliases" with
lsearch;
and
> address_data = ${lookup{$local_part}lsearch{/the/file}{$value}fail}
could become
address_data = from key "local_part" lookup in file "/the/file"
with lsearch, if error fail;
I've just skimmed the surface here and I know a proper syntax is a lot more
work...
>Saving looked up data with an address
>However, the transport can also use the same data, without having to
>specify another lookup, like this:
> local_delivery:
> driver = appendfile
> file = /var/mail/$local_part
> user = ${extract{uid}{$address_data}}
> group = ${extract{gid}{$address_data}}
I like the thought, but am worried about two things:
1. I would like to be able to define my own names, rather than have to use
a fixed name, so if I use this more than once I know the right one is being
used.
2. There must be a wy for the local_delivery to know that address_data
has not been set for this mail (presumably because it took a different
route) rather than use old/incorrect data.
>These options are all replaced with a single option called
>reject_recipient. Or possibly it should be called accept_recipient, and
>define the conditions under which an incoming SMTP recipient is accepted.
>Yes, I think I prefer that.
I do too.
>Here's how the default setting might look under this scheme:
> accept_recipient = address = +local_domains AND verify AND sender_verify
which gets me confused for starters because of the '='. How about:
accept_recipient = address in +local_domains AND verify AND sender_verify
and you have to say priority(in) > priority(AND) > priority(OR). You could
also have 'is' when things aren't lists:
accept_recipient = address is "my.domain" AND verify AND sender_verify
>Autoconf
>Somebody once tried to autoconf Exim, but found it too big a job. I now
>have some experience with using autoconf for PCRE, and I think maybe some
>use could be made of it. I don't, however, believe that all Exim
>build-time configuration should be done that way. The reason is that,
>unlike something like PCRE, there is quite a lot of information that is
>`user choice'. Giving it all as options to a configure command does not
>seem the best way of doing things.
How about looking at using the conf-system from the Linux kernels? It also
has to cope with a lot of user-stuff, is relatively simple to maintain
(IIRC) and exists. I don't know how hard it would be to extract from Linux,
though.
>However, it might be helpful to use autoconf to dig out various bits of
>information about the operating system. At present, the OS/Makefile-*
>files have hard-wired settings, and maybe this information could be
>figured out by running autoconf, which would save having to keep
>maintaining these files.
This seems good to me.
>The simple `log level' approach is too crude. As a result, a number of
>separate `log this' and `log that' options have been created. It would be
>tidier to abolish all this apparatus, and instead go for a bit-pattern to
>control optional logging. You would say something like
> log_selector = 10246
For a project I did, I implemented a slightly more user-friendly scheme.
There is a bitmask, and you can set it to numbers, but normally you use names:
log = all -a -b
log = -all +b +c
log = common
where just "opt" means set logging to this option(set) only, "+opt" adds
the option named 'opt' to the selection, "-opt" means remove it. 'common'
is an alias for a particular selection of items (in this case, presumably
commonly wanted ones). You can use the alias in the same way:
log = all -common
to get the uncommon items. The scheme works fine, although it would perhaps
have been useful to say a given message could be in two log groups at the
same time, so things make sense in all cases. I also had a
level=info/warn/error/fatal, and the usual 'if you say warn, you don't get
info but do get error' rules. This worked OK. I don't know if I can give
you the source: currently it's (c) ARM; if you like I could ask...
Re DNS logging, I've seen on the email list a number of messages where
someone wanted logging of DNS queries that were being done with a
gethostbyname() and so didn't get logged. It would seem to me that exim
could reimplement gethostbyname() using code it already includes, and so
avoid this issue.
>Debugging
>The simple `debug level' approach is also far too crude. It would be
>better to use a bit-pattern to select debugging of various types. For
>example, you might want to turn on DNS resolver debugging but not anything
>else. At
Use the same system for main logging & debug logging, but make it possible
to select the destination independently.
>Documentation
I would suggest using sgml source, seeing as I work as tech-author using
sgml, because you can target several output formats.
Whatever, I would personally vote for 3 formats:
(a) html online, -- very useful for the quick reference, and for
following xrefs around
(b) postscript book -- good for getting the basic understanding.
something to sit down with for a while
(c) unix man-page -- containing basic info and command line opts (order
5-10 pages). Quick reference card kind of thing. Actually I would vote for
2 pages: exim(1) and exim-conf(5).
Regarding content, I would ask for more examples and common setup info.
When I first started, I found it an uphill struggle to find out what I had
to do for my site, what was optional, and how to do it.
Hope this is useful,
Ruth
--
Ruth
Ivimey-Cook ruthc@???
Technical
Author, ARM Ltd ruth.ivimey-cook@???
