ietf-smtp
[Top] [All Lists]

SMTP Service Advertisement

2008-04-11 09:09:06

John C Klensin <john+smtp(_at_)jck(_dot_)com> wrote:

We have tried variations on "look over here (e.g., in the DNS)
to see, definitively, if something is available over there
(e.g., some service)" several times, with similar results.
Those results closely parallel discoveries in [other] areas of
computer science (see e.g., Ed Codd's original paper on
relational database models). If one has two different, but
intimately related, pieces of information that are stored in
different places and often maintained by different people in
different roles, things _will_ get out of synch and to bad
effect.  Often it doesn't even require different people -- it is
just too hard to keep track when things need to be updated in
different types of systems.

   ++observation

Like it or not, there is a big difference between using the DNS
to advertise the availability or location of a service and
believing that the absence of information in the DNS is a
definitive indication that the service doesn't exist at that
node.

   This is such a good statement of the issue that I can't resist
responding to it.

   I don't recall ever seeing a consensus on which of these we
_want_ email to be.

   Clearly, when we write email to 
<somebody(_at_)[123(_dot_)45(_dot_)678(_dot_)9] we
intend it to go to that "machine" _if_ it supports SMTP. (If
whatever server answers on port 25 of that interface doesn't
know what to make of such an address, it is at least _the_
best authority on what to do with it.)

   IMHO, when we write email to <somebody(_at_)ibm(_dot_)com> we want it to
go to an appropriate server for the _domain_ IBM.com. If there
happens to be an A)ddress record for IBM.com, that really isn't
where we want it to go; and we trust IBM.com to do the right
magic in DNS to ensure it instead goes to an "official" SMTP
server.

   That, IMHO, is the perfect example of what John K is saying:
that this sort of DNS magic _will_ get out of sync. Thus, IMHO,
we are ill-advised to design an email system which depends upon
it staying in sync.

   It is easily demonstrated that many cases exist where an
A)ddress RR gets out of sync, and points to some "machine" which
has no clue what to do with email addressed to that domain --
_whether_or_not_ it happens to listen on port 25. Whatever error
it may _or_may_not_ return is unlikely to be helpful to someone
trying to send email to that domain.

   Thus, IMHO, we SHOULD clearly state that <somebody(_at_)example(_dot_)com>
means the email is intended for the _domain_ example.com; and
that if the DNS gets out of sync with the routing, the _DNS_ is
authoritative, not the routing.

   (That still leaves us an opportunity to argue whether the
absence of an MX record indicates the absence of an official
email service, BTW...)

It will be that way until and unless we redesign the network
architecture to treat the DNS as part of TCP or IP such that,
e.g., the act of turning on a listener for a particular service
is the act that creates corresponding records in the DNS.

   John K is baying at the wrong moon, IMHO. Turning on a process
listening on port 25 is quite a different matter than deciding
that you want email coming to a domain.

   Neither can I imagine any case in which it would make sense
to automatically advertise an MX RR when a port 25 service is
detected. (I can barely imagine any _way_ to do this!)

That is the message in the failure of WKS as a definitive
service-availability indicator and what I was trying to point
you to when I pointed you to 1123.

   (I include this only to avoid a charge that I quoted John K
out of context: it's quite unrelated to any point I intended
to make.)

--
John Leslie <john(_at_)jlc(_dot_)net>