On Thu, 18 Mar 1999, Toralf Lund wrote:
> Too bad. Can I store the regular expression in a variable and use it to generate
> a colon separated list _AND_ the LHS of a rewrite rule? (I'll have another look
> in the manual here...)
I've lost the thread here. Let me check - you have some list of domains
(local domains, say) which you want also use for rewriting? And this has
to be an explicit list because it can't easily be written as *.x.y or
something? Suppose your domains were
cat.ex dog.ex rabbit.ex
and you wanted to treat them all as local domains, and rewrite them. Is
that right?
First comment: If you are rewriting these domains, then you don't need
to specify them as local domains or whatever, because they will get
removed by the rewriting process, and so will never been seen during any
delivery process. You can certainly use a rewriting rule of the form
^[^@]+@(cat|dog|rabbit)\.ex $local_part@???
for example, to change any of those domains into "zoo.ex". Then you
would need to have
local_domains = zoo.ex
if you wanted to handle it as a local domain. There is no need to
mention the originals in there.
However, perhaps you want to use that domain list for something else. It
is possible to use the same regex in several places. I have just
realized that the manual is missing a piece of information. It is
permitted to have rewriting rules of the form
*@^regex ....
Therefore, you could do something like this. Define a macro
DOMREGEX = ^(cat|dog|rabbit)\.ex$
and use it in some domain list like this
some_option = DOMREGEX
as well as in a rewriting rule like this
*@DOMREGEX $local_part@???
> I don't know exactly how 'finger' etc. handles this, but the operation is
> transparent with respect to whether NIS is used or not, and speed does not seem
> to be an issue.
The system I am on has over 5,000 users. Several years ago we rewrote
finger to make use of an indexed file for speed.
I expect normal finger calls getpwnam() or other functions that scan the
list of users. This is the right thing to do - there is only one list of
users on a machine, and the getpw.. functions provide a single interface
to it. Exim calls getpwnam() when it is trying to find out if a given
local part is a login name. For alias files, however, it can handle many
different alias files (for different domains, for mailing lists,
whatever).
> We don't have that many users, but far more than a dozen. Also,
> I can't see how a new alias file would make the search that much more efficient,
> as this would grow be nearly as large as the password file. The search may be
> speeded up if the file is indexed, of course, but there are several ways to make
> GECOS searches more efficient, too.
I was thinking of indexed searching.
> Anyhow, we are using NIS (or is it NIS+ these days?), and I would probably use
> ypmake to generate the appropriate files here. Also, a PERL script can easily be
> designed so that it doesn't have to be changed if NIS is enabled or disabled. I
> still don't like this idea, though.
The use of data caches is a well-known and widespread technique for
improving performance. Think of your generated file as a data cache.
Another advantage of it is that it will be a local file on your MTA
host, saving network traffic every time it is referenced.
> It's not an absolute requirement, but it would be neat if we could change the MX
> list without having to re-configure Exim, or even set up hosts listed as low
> priority MXs so that they try to route mails to the higher priority ones, but
> deliver them locally if these are down. How hard would this be?
Exim does all its routing before it attempts any deliveries. Therefore
re-routing on the basis of delivery failure (other than forwarding to
backup hosts) isn't a feature.
> Maybe the default configuration file should contain the above settings, with
> appropriate comments?
You are the first person who has raised this issue. I will consider
putting something in the default configuration.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
--
*** Exim information can be found at
http://www.exim.org/ ***
