Autor: Andrew - Supernews Data: A: exim-users Assumpte: Re: [Exim] how to configure HELO/EHLO and DNS for multi-homed hosts
>>>>> "Greg" == Greg A Woods <woods@???> writes:
>> What _isn't_ true is that you can do a PTR lookup on the IP to get
>> the name in the HELO. This is not required by any language in any
>> RFC, without creative re-interpretation that ignores completely
>> the intent of the specification. Greg> Sorry to spoil your litle game,
Accepting mail isn't a game to me, though it appears to be for you.
Speaking of which: I thought I informed you that mail from your domain
to ours was unwelcome due to your refusal to accept responses. Please
confine your responses to the list only.
Greg> but you've apparently failed to notice that the SMTP greeting
Greg> name is a host domain name, i.e. something that resolves to at
Greg> least an A RR.
which it does.
Greg> For Reverse DNS to be complete and correct there _MUST_ be a
Greg> PTR for every A RR and vice versa.
but this requirement is only in your mind. It is quite normal these
days for hosts to have thousands of A records pointing to them (I know
of one with well over ten thousand), and no-one would seriously
suggest that such a host should have thousands of PTR records to
correspond. (In fact when misgiuded sites do try and include an
excessive number of PTR records it often causes considerable problems
when the PTR lookup no longer fits in a UDP response.)
Greg> The Reverse DNS is useless and misleading if this is not the
Greg> case.
not at all.
Greg> In fact given the normal use of the Reverse DNS to authenticate
Greg> hostnames, it's impossible to tell the difference between a
Greg> missing PTR and a spoofed hostname.
Leaving aside the inherent insecurity of the DNS which makes any use
of the word "authenticate" in this context somewhat inappropriate,
your statement above is untrue.
There are two standard cases for validating the correspondence between
hostnames and IPs:
1) the protocol provides the hostname; the hostname is valid if an A
record lookup returns an IP matching the connecting client. PTR
records are not useful in this case at all.
2) the protocol does not provide the hostname; the set of possible
hostnames is obtained by PTR lookup on the connecting client IP, and
each is then validated by performing an A record lookup which must
return an IP matching the connecting client.
Both of these methods provide all necessary protection against
hostname spoofing without requiring anything stricter than that all
PTR record values must have a matching A record (which is true of our
DNS). There is not and has never been any requirement for the name of
every A record to appear as the value of some PTR record.
Greg> If you want to connect to any of my systems, using any TCP
Greg> application protocol (not just SMTP, but not yet including
Greg> HTTP), and if you or your ISP publish Reverse DNS for your
Greg> source address, then I will verify its correctness and
Greg> completeness and if that test fails I will reject your
Greg> connections.
you can reject connections to your systems for any reason that pleases
you. However, when you do so in ways that violate a MUST NOT provision
in a protocol, you don't get to complain about any failure to
interoperate (such as inability to send mail to people using callout
verification) that might result.
Greg> Note that this tried and true means of hostname validation has
Greg> been extrememly widely implemented. I believe it may have been
Greg> Steve Bellovin who first suggested it, though the most widely
Greg> used implementation is perhaps that in TCP Wrappers.
TCP Wrappers does not reject connections from our hosts (even in
paranoid mode).
>> It's also likely to be false in many common cases that occur in
>> practice (two examples already given in this thread). Greg> It only causes problems for people who are blind to the fact that
Greg> multiple PTRs are allowed and necessary.
while multiple PTRs are allowed, they are rarely either useful or
necessary, certainly not in this case.
>> Being pedantic about the HELO parameter in SMTP is one of the
>> clearest examples of this. The HELO value is purely documentary,
>> it plays no part in the process of exchanging mail other than to
>> be recorded in logs or Received: headers. Greg> Sorry to blow another hole in your game. HELO is a vital part
Greg> of the SMTP protocol -- it would have been omitted if it were
Greg> not necessary.
Leaving aside the use of EHLO to discover support for extensions,
there is no justification whatsoever for your statement. Many things
are included in SMTP which are not necessary (e.g. HELP and NOOP).
It is quite common for SMTP servers to treat HELO as optional (even
though clients are required to use it). Calling it "vital" is just
absurd.
Greg> (and no, I'm not going to repeat its purposes here again --
Greg> look it up)
cop-out. If you're going to assert that it is "vital", then produce an
example or a logical argument saying so.
My position that it is purely documentary is supported by several
arguments:
1) explicit language of RFC1123 5.2.5 and 5.2.8; RFC 2821 4.1.4 and 4.4;
2) lack of any defined processing for the HELO/EHLO parameter in those
same RFCs and RFC 821;
3) widespread (but not universal) treatment of the command as optional
by SMTP servers
>> No. This is why: because in at least 90% of cases where a PTR lookup
>> is performed, the program doing the lookup is only interested in _a_
>> name for the IP and not _all_ names. Greg> However if you don't have the right name in the PTR RR set, how
Greg> the hell is such a program supposed to find it?
If the program knows what name it is looking for (i.e. it has obtained
a name via some non-DNS method), then it should be using the A record
anyway.
>> If multiple PTR records are present, such programs will use an
>> arbitrary one. Greg> "use"?!?!?! What do you mean by "use"? Most programs search
Greg> the Reverse DNS for matches
it is in fact extremely rare for programs to do that. The most common
use of rDNS, by an extremely large margin, is to call gethostbyaddr()
and look at h->h_name (only).
Greg> $ host -v -A mx1.supernews.net
I do not know what utility you have on your system under the name
"host". On my systems I have the host(1) program from one or other
version of BIND, which does not match your usage.
Greg> Query about mx1.supernews.net for record types A
Greg> Hostname mx1.supernews.net maps to address 216.168.1.22
Greg> Hostname mx1.supernews.net maps to address 216.168.2.22
Greg> Found 2 addresses for mx1.supernews.net
Greg> Checking mx1.supernews.net address 216.168.1.22
Greg> *** mx1.supernews.net address 216.168.1.22 maps to hostname trinity.ranger.supernews.net
Greg> *** Hostname mx1.supernews.net does not belong to address 216.168.1.22
Greg> Checking mx1.supernews.net address 216.168.2.22
Greg> *** mx1.supernews.net address 216.168.2.22 maps to hostname trinity.delta.supernews.net
Greg> *** Hostname mx1.supernews.net does not belong to address 216.168.2.22
Greg> *** Not all addresses for hostname mx1.supernews.net have a matching hostname.
this result is correct. There are enough services on that host that
listing a PTR record for all of them would be ludicrously unwieldy.
>> Using a non-unique value in the PTR record as you suggest would
>> mean that in about half of all cases where the rDNS name was
>> recorded, it would be recorded in such a way that it did not
>> identify the interface used, which defeats the whole purpose of
>> having separate names. Greg> Obviously you don't understand the rules of the "Received:"
Greg> header.
I understand them perfectly. (You apparently don't, since there are at
least two SHOULD NOT violations in yours; "via" and "with" do not take
arbitrary values.)
Greg> As for "the interface used", well if you've not recorded both the
Greg> hostname used/discovered _and_ the IP address, then your logs are as
Greg> good as garbage anyway (at least for the purpose of auditing).
I happen to agree. But it's not only my logs I'm concerned about.
Greg> (and most times the PTR RR set is not rotated since most
Greg> nameservers run versions of BIND that don't do round-robin on
Greg> PTRs)
nonetheless relying on an order dependence between DNS records in the
same RRset is insane.
Greg> (and whether you want the interface name or the service name
Greg> logged depends on your situation, but in the received header
Greg> you definitely wan the common service name logged along with
Greg> the IP address in a comment)
the recommended practice for the Received header is to record the HELO
name in addition to the IP address and possibly a name discovered by
PTR lookup, and this is in fact what most systems approximate.
>> I mentioned your suggested scheme to a number of other experienced
>> mail and DNS admins and they were unanimous in their disapproval. Greg> Well, obviously you and they have not tried it then. It works,
Greg> very well, as it must. There are even similar examples in the
Greg> RFCs.
where?
>> If that were the case I would expect it to be documented as such,
>> which it is not. Greg> It is -- RTFRFCs again!
I have read them numerous times. Neither the DNS specification RFCs
nor the various DNS operational/configuration RFCs support your
position in any way. In particular, when the issue of using A records
for service names is discussed in BCP 17 (RFC 2219), there is no
mention of adding additional PTR records. RFC 1917 requires a PTR
record for each IP, not one for each A record.
In addition, I don't accept non-specific references to RFCs or
interpretations of RFCs from people who engage in bogus interpretation
arguments as you have done in <m19VjqI-000B48C@???> where
you argue that a very explicit MUST NOT rule (from 1123, reiterated in
2821) actually means the reverse. Once you accept such "black = white"
logic there is no limit to what you can argue.
