------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
http://www.exim.org/bugzilla/show_bug.cgi?id=457
------- Comment #6 from holmgren@??? 2007-02-10 11:54 -------
On Monday 05 February 2007 11:11, ph10@??? wrote:
> > Looking up the address records of a.b.c.d and comparing each of them to
> > 192.168.1.1 probably makes most sense. But it isn't really necessary to
> > allow host names there if you can say
>
> *That* is the point that was confusing me. I didn't appreciate that you
> were only really talking about
>
> ${if match_host{<ip address>}{<host list>}...
> ^^^^^^^^^^
>
> The problem I have always had with match_host is that I think of a
> client host as "having both an IP address and a name" and the user has
> to specify which (e.g. by saying lsearch or net-lsearch). I was not
> thinking in terms of "match_host starts from just an IP address". If you
> only allow an IP address there, it is as you say, no different from
> "hosts" in an ACL.
I've been thinking and looking at the code some more.
Ordinary host lists (options that take host lists as arguments, plus the hosts
ACL condition) are used in two ways: With hosts connecting to us and with
hosts we are connecting to. Those are about the only possibilities. :-)
When a host contacts us, we initially have an IP address, which is
reverse-looked-up yielding a host name and possibly some aliases. Those are
used when verify_check_this_host() is called with host_name == NULL.
But when we contact a host, we typically initially have a host name (or more,
but they are checked one at a time) from an MX record. The host name is
looked up, hopefully yielding an address (or more, but IIUC each address is
regarded as a separate host, although with the same name as the other). So
that's how we get the dual identity in that case.
Thus, there exist situations in which the host name is the starting point, but
it's not obvious what to do with it - a host is more adequately identified
with its IP address. ${match_host {<hostname>}{<hostlist>}} is therefore out.
For ${match_host {<address>}{<hostlist>}} there is the implementation problem
that the existing code is hardcoded to reverse look up sender_host_address.
Factoring out common code from host_name_lookup() is needed.
Alternatively, match_host can take an address *and* a host name, meaning that
you have to use dnsdb and forany/forall to look up host names or addresses as
needed.
Then we have the problem with query-style lookups...
--
Configure bugmail:
http://www.exim.org/bugzilla/userprefs.cgi?tab=email
