On Wed, 19 Jan 2000, Philip Hazel wrote:
> > Moving the +allow_unknown to before the old net_reject_except info
> > fixed the problem
>
> I'm surprised! That should make no difference. Are you sure the DNS
> didn't get fixed?
Actually, the problem appears to be that I am an idiot AND that there is
something like what I misreported, but instead was with host_accept_relay.
convert4r3 created
host_accept_relay = " *.cranfield.ac.uk:*.cran.ac.uk : 138.250.0.0/16"
while if I fix that to
host_accept_relay = "138.250.0.0/16 : *.cranfield.ac.uk:*.cran.ac.uk "
I no longer get the error. The log message should have made it clear,
seeing (after I posted my previous message) that it specifically mentioned
relaying. I also was not as careful with my -bh test as I should have
been (not noticing that this was a relay control issue).
(And yes, the above is what I want. There are some machines with
cranfield.ac.uk names which are not in 138.250, and I want those to be
allowed to relay iff they do have a proper lookup.)
I'll run a -bh test with a test config in a moment and pass that on.
> The best solution is
> host_reject_recipients = "! 138.250.0.0/16 : \
> TABLES/nets_reject : \
> +allow_unknown: \
> partial-lsearch;TABLES/hosts_reject"
>
> Because it then does all the IP address checking first, and if it finds
> its answer there, it never needs to do a host lookup at all.
Indeed. That does make sense. I am already doing a name lookup on
everything, so I don't lose much by not ordering things sensibly, but
I will fix that in case down the line, I stop looking everything up.
Once everything is running v3.* the files nets_reject and hosts_reject may
get merged with the +allow_unknown in the file after the nets and before
the hosts.
-j
--
Jeffrey Goldberg +44 (0)1234 750 111 x 2826
Cranfield Computer Centre FAX 751 814
J.Goldberg@??? http://WWW.Cranfield.ac.uk/public/cc/cc047/
Relativism is the triumph of authority over truth, convention over justice.
