>>>>> "Greg" == Greg A Woods <woods@???> writes:
>> trinity.supernews.net (which HELOs as trinity.supernews.net,
>> because that is its principal hostname) is on two networks for the
>> purposes of redundancy; it has two IPs, 216.168.1.22 and
>> 216.168.2.22. Which one gets used for an outgoing connection
>> depends on whether the network happens to be broken at the time
>> and if so, in what way. (generally it's 216.168.1.22 that gets
>> used.)
Greg> You don't seem to understand the meaning of "principal host
Greg> domain name" as it is interpreted for RFC 1123 Section 5.2.5.
I understand it very well thank you.
Greg> This is odd because that very same section gives you this
Greg> definition in these plain words:
Greg> The HELO receiver MAY verify that the HELO parameter really
Greg> corresponds to the IP address of the sender.
The HELO parameter really does correspond to the IP address of the
sender.
Greg> I.e. the principal host domain name that "MUST" be used when an
Greg> SMTP client identifies itself with a HELO/EHLO command is one
Greg> which the receiving-SMTP can resolve to an A record which
Greg> matches the client connection source address.
This is indeed the case.
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. It's also likely to be false in many common
cases that occur in practice (two examples already given in this
thread).
Regarding RFCs: they exist to promote interoperability rather than to
set absolute standards; this is why it is not IETF policy to do
conformance testing but rather interoperability testing. Deliberately
breaking interoperability in order to "force" the remote site to
adhere to your interpretation of the RFCs _is itself a violation of
those same RFCs_.
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> Note that a host domain name may resolve to multiple A records
Greg> but it is only necessary that one of them match. Indeed this
Greg> is the way you must configure your DNS if you are using a
Greg> multi-homed host (i.e. a host which might originate connections
Greg> from multiple source addresses).
There is, to the best of my (extensive) knowledge, no requirement in
any specification that I must configure my DNS any differently to the
way it is configured now.
>> Now, the rDNS for those two IPs is different so that they can be
>> distinguished where necessary (it is quite normal practice to
>> distinguish the rDNS names for multiple interfaces on a host):
>>
>> 216.168.1.22 is trinity.ranger.supernews.net
>> 216.168.2.22 is trinity.delta.supernews.net
Greg> This is all fine and good. However should you choose to do the
Greg> right thing and define a third name that your mailer can use
Greg> regardless of which source address is assigned to its
Greg> connection then you'll need to add two more PTRs, one for each
Greg> address, each of which point to the new third name.
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. If multiple PTR records are
present, such programs will use an arbitrary one. 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.
(Recording the rDNS name, in logfiles for example, without also
recording the IP address is evil and dangerous, but not actually all
that uncommon.)
[snip silly example]
I mentioned your suggested scheme to a number of other experienced
mail and DNS admins and they were unanimous in their disapproval. I'm
also informed that you've had this debate on the mailing lists of
other MTAs, and accordingly I suspect that there is no point in
pursuing the matter unless any exim-specific matters arise. I will,
however, suggest that you never send email to any of our domains, as we
would find that annoying.
Greg> This is the way the DNS was designed to be used for multi-homed
Greg> hosts.
If that were the case I would expect it to be documented as such,
which it is not.
--
Andrew, Supernews
