Mailing List Archive

------- 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 #2 from holmgren@lysator.liu.se 2007-01-31 11:59 -------
On Wednesday 31 January 2007 11:12, ph10@hermes.cam.ac.uk wrote:
> > The semantics described in sections 10.9
> > through 10.17 should work, at least when the item being checked is an IP
> > address.
>
> So use match_ip!

But match_ip only accepts IP addresses/networks in the list, and I can't
understand why the same matching as with the hosts ACL condition can't be
used here, but with an arbitrary address to check.

> > What have I missed? Even if it's not entirely clear how to specify
> > cleanly how this test should work, it should be possible to decide on a
> > sufficiently meaningful specification.
>
> That's the point. I felt that it was indeed not clear how to specify this
> cleanly.

Can you elaborate? Do you have any examples of particularly dirty situations?
Should a domain name that resolves to multiple IP addresses have to have
*all* those IP addresses match the host list?

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #3 from ph10@hermes.cam.ac.uk 2007-01-31 14:47 -------
On Wed, 31 Jan 2007, holmgren@lysator.liu.se wrote:

> But match_ip only accepts IP addresses/networks in the list, and I can't
> understand why the same matching as with the hosts ACL condition can't be
> used here, but with an arbitrary address to check.

Given that you have to give a "key" to a match_xxx operator, you should
know whether you are giving it an IP address or a host name. So you
should be able to choose match_ip or match_domain accordingly.

The thing about

hosts = <hostlist>

in an ACL is that there is an "implied" identification for the host,
consisting of both the name and the IP address and Exim uses one or the
other, as needed, depending on the host list item. Actually, that isn't
the whole story, because the invention of query-style lookups spoilt it.
I wouldn't do it this way if I were starting again now.

> Can you elaborate? Do you have any examples of particularly dirty situations?
> Should a domain name that resolves to multiple IP addresses have to have
> *all* those IP addresses match the host list?

That's the kind of question that makes it messy. I can write

hosts = 192.168.1.1

in an ACL, and it will compare the IP address of the client to
192.168.1.1. But what should happen if I write

${if match_host{a.b.c.d}{192.168.1.1}...

? Or indeed

${if match_host{192.168.1.1}{a.b.c.d}...

? Or even

${if match_host{192.168.1.1}{*.b.c.d}...

? I felt that having the separate match_ip and match_domain was cleaner
and avoided these kinds of complication.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #4 from holmgren@lysator.liu.se 2007-02-03 11:06 -------
On Wednesday 31 January 2007 15:47, ph10@hermes.cam.ac.uk wrote:
> > But match_ip only accepts IP addresses/networks in the list, and I can't
> > understand why the same matching as with the hosts ACL condition can't be
> > used here, but with an arbitrary address to check.
>
> Given that you have to give a "key" to a match_xxx operator, you should
> know whether you are giving it an IP address or a host name. So you
> should be able to choose match_ip or match_domain accordingly.

But it doesn't help! I'm not even sure I want to give a host name on the LHS,
but I want to be able to use named host lists on the RHS of the equation.

> The thing about
>
> hosts = <hostlist>
>
> in an ACL is that there is an "implied" identification for the host,
> consisting of both the name and the IP address and Exim uses one or the
> other, as needed, depending on the host list item.

I'm not convinced: when a client connects, all Exim knows is the IP address. A
reverse DNS lookup is performed in order to get a host name. I can't see how
the IP address of a connected client is any different from an arbitrary IP
address. (Exim could optionally let the admin use the HELO name as the host
name, as if it had been obtained from DNS (the requirement in both cases is
that a forward lookup of the host name must yield the original IP address),
but Exim doesn't do that (yet).

One technical difference is that Exim always looks up the host name if the
connecting IP is in host_lookup. Checking arbitrary hosts with match_host
means extra DNS lookups, which should probably be cached. But that is merely
a technical issue, not a fundamental problem.

> > Can you elaborate? Do you have any examples of particularly dirty
> > situations? Should a domain name that resolves to multiple IP addresses
> > have to have *all* those IP addresses match the host list?
>
> That's the kind of question that makes it messy. I can write
>
> hosts = 192.168.1.1
>
> in an ACL, and it will compare the IP address of the client to
> 192.168.1.1. But what should happen if I write
>
> ${if match_host{a.b.c.d}{192.168.1.1}...

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

${if forany {${lookup dnsdb{>:a.b.c.d}}} {match_host{$item}{192.168.1.1}}...

And I'm not really sure what to use it for anyway. Host names typically come
from reverse lookups of IP addresses, and comparing the address to the host
list directly makes more sense.

> ? Or indeed
>
> ${if match_host{192.168.1.1}{a.b.c.d}...
>
> ? Or even
>
> ${if match_host{192.168.1.1}{*.b.c.d}...
>
> ?

Exactly the same as if you wrote

host = a.b.c.d

or, respectively,

host = *.b.c.d

in an ACL and the client IP address is 192.168.1.1. The fact that there is no
1:1 mapping between IP addresses and FQDNs already makes this unclean. It
doesn't get any less clean just because the matching is in a string
expansion.

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #5 from ph10@hermes.cam.ac.uk 2007-02-05 10:11 -------
On Sat, 3 Feb 2007, holmgren@lysator.liu.se wrote:

> > The thing about
> >
> > hosts = <hostlist>
> >
> > in an ACL is that there is an "implied" identification for the host,
> > consisting of both the name and the IP address and Exim uses one or the
> > other, as needed, depending on the host list item.
>
> I'm not convinced: when a client connects, all Exim knows is the IP
> address. A reverse DNS lookup is performed in order to get a host
> name. I can't see how the IP address of a connected client is any
> different from an arbitrary IP address.

Aha! I think I understand now the point you are trying to make.

> 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.

Philip

--
Configure bugmail: http://www.exim.org/bugzilla/userprefs.cgi?tab=email

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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@lysator.liu.se 2007-02-10 11:54 -------
On Monday 05 February 2007 11:11, ph10@hermes.cam.ac.uk 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

--
## List details at http://www.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##