[prev in list] [next in list] [prev in thread] [next in thread] 

List:       exim-users
Subject:    Re: [Exim] Exim 4 ideas.
From:       Ruth Ivimey-Cook <Ruth.Ivimey-Cook () arm ! com>
Date:       2001-01-05 19:44:51
[Download RAW message or body]

>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@sharra.demon.co.uk
Technical 
Author, ARM Ltd              ruth.ivimey-cook@arm.com


[prev in list] [next in list] [prev in thread] [next in thread]