Re: [EXIM] Negation in domain/host/net/address lists

Top Page
Delete this message
Reply to this message
Author: Georg von Zezschwitz
Date:  
To: Philip Hazel
CC: Georg von Zezschwitz, exim-users
Subject: Re: [EXIM] Negation in domain/host/net/address lists
On Tue, Mar 16, 1999 at 03:37:28PM +0000, Philip Hazel wrote:
> But that is *exactly* what I am suggesting!! Just that in the Exim case it
> would appear as (for example)
>


Right.

I read the posting and looked for a '!'-rule, but I did not the
thread (nor the subject)

RTFT / RTFS :-)

> I think you have missed the point here. Some ISP have hundreds, or even
> thousands of individual networks. It is quite slow to read through a
> list of items like 195.222.192.0/24 to check all of them. Several times
> I have been asked for a way of speeding this up. The proposal is that
> you should be able (in *addition* to what is above) to say
>
> host_accept = net_24-dbm;/some/dbm/file
>
> and it would do a single lookup in the file to test one IP address. If
> you have a mixture of different length networks, you need to do several
> lookups. This would only be worth doing if the numbers were big.


I consider this approach is dong something by configuration syntax
what should be done by implementation. Our ciscos *do* have a
pretty long netlist, but the configuration-file remains a flat
list (though the cisco is fast :-)).

E.g., "precompiling" such netlists towards a 4-Byte IP-adress /
netmask sequence binary file, building up binary trees or whatever,
would be an approach to keep config-files simple, but to enfasten
the processing. On the other hand, ISPs with many networks might
have the time to set up the stuff like suggested. Anyway: Those
ISPs usually have many different networks being sized from /24 to
/21. It will still be difficult to automatically dump the

 network 194.127.100.0
 network 194.77.160.0
 network 193.98.8.0 mask 255.255.252.0
 network 193.101.62.0 mask 255.255.254.0
 network 193.102.128.0 mask 255.255.252.0     


stuff from the BGP setup to a good config for exim. Either you'd
have to split up everything to Class-C-networks, or you have to use
many different sizes for net_xxxx-dbm.

> > Another idea are named acls. In our configuration, the same
> > acl is used 5 times:
> >
> >    smtp_reserve_nets = "/usr/local/lib/exim/netlist"
> >    receiver_verify_except_nets = "/usr/local/lib/exim/netlist"
> >    rfc1413_except_nets = "/usr/local/lib/exim/netlist"
> >    sender_net_accept_relay = "/usr/local/lib/exim/netlist"
> >    smtp_etrn_nets = "/usr/local/lib/exim/netlist"

>
> You could make use of a macro for this if you wanted to.
>
> > (with a cache for the last 2 or 3 ip-numbers)
> > could speed up things and make configurations more
> > transparent.
>
> I can't see how caching will help. Those lists are all used in entirely
> different circumstances. Remember, there is no central Exim process.


During the normal cause of an ESMTP incoming seession all the
4 later ones will be evaluated, am I wrong?

Of cause, the meaning is different.
But very often the netlist has a very simple use: To decide between
outside and inside. I'm dreaming of Linux distributions that ask
you first: "What's your local / inside network?" and set up
Exim, Squid, INN and all that stuff upon this single, simple
information.

The basic idea of the upper configuration is simple:

- All rights and maximum speed to our customers
- More "expensive" checks only to incoming connections from
the outside:
Mailserver don't really suffer in a psychological way under
some delay :-)

I don't think the cache should be hold for longer than one (non-daemon)
process lasts. But within this process the IP-number could be cached.

Greetings,


Georg

--
*** Exim information can be found at http://www.exim.org/ ***