[exim-dev] [Bug 457] match_host expansion item

Pàgina inicial
Delete this message
Reply to this message
Autor: bug457
Data:  
A: exim-dev
Assumpte: [exim-dev] [Bug 457] match_host expansion item
------- 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@??? 2007-02-03 11:06 -------
On Wednesday 31 January 2007 15:47, ph10@??? 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