ietf-smtp
[Top] [All Lists]

Paradigm change?

2008-03-30 21:41:54

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

Using the DNS to _discover_ where to find the preferred server 
for a particular service for a particular domain is a different 
matter from using the DNS to determine whether or not a 
particular server supports a particular service.

   True, but all of us are talking about the first, not the second.
We aren't setting out to ask whether a _server_ supports SMTP --
we're asking what IP address a _domain_ advertises for receiving
SMTP connections.

   The RFC2821 text about implicit MX states a fallback, in the
absence of any MX RR, and it states it in terms of what the
implied MX record must be assumed to be.

(1) I do not agree with Dave that MX records are simply an 
administrative convenience (nor do I read his comment as 
implying that the DNS more generally is just an administrative 
convenience).  I think they are part of the architecture, an 
architecture that clearly includes DNS use.

   Agreed.

I do think there is a case to be made that using MXs to isolate
the location of a mail server from the domain at which the
mail address is located is an administrative convenience,

   I'm not sure I understand. I hope you mean that the domain-name
of the server need not be the same as the domain for which it
receives email, which I consider a rather important architectural
feature.

even though it is, as others have pointed out, critical enough
to important operational service models that identifying and
dismissing MXs that way is, IMO, inappropriate.

   (I'm sure I _don't_ understand that statement.)

However, while the requirement for relaying has become less as
we have evolved toward a fully-connected Internet, if MXs are
relegated to "administrative convenience", we would, IMO, need
to restore the original RFC 821 model of forward and reverse
paths.

   I can imagine other solutions, but I agree that MX RRs were
essential to depretating forward-path.

But that modeling issue doesn't have anything to do with whether 
getting rid of implicit MXs, or restricting them to IPv4, is a 
good idea.

   Agreed, I think...

I do see a reason to do that in principle, but I don't think it
holds up in practice: to the extent that "transport over IPv6"
is a different service than "transport over IPv4",

   (I'm not sure we've yet found a better paradigm than recognizing
them as different -- and assuming the existence of a gateway.)

then one might reasonably have SMTP-related reasons for
preferring one of those services over the other that were 
independent of the considerations of RFC 3484.

   This looks interesting!

That might suggest DNS setups like

  foo.bar.baz.  IN MX 10 v4host.smtp.example.com.
                IN MX 5  v6host.smtp.example.com.
  v4host.smtp.example.com IN A 10.0.0.6
  v6host.smtp.example.com IN AAAA 2001:DB8::6
  ; smtp.example.com  IN AAAA 2001:DB8::6
  ;                   IN A 10.0.0.6

   I may be confused...

   One certainly can use DNS to state a preference for IPv4 or IPv6
and a gateway for the other, but this doesn't look to be doing that.

and, all other things being equal, avoiding the MX default to 
help force people to think about those issues.  But, as others 
have said at more length, it appears to me that the horse is 
long out of the barn.

   The IPv4 horse is "long out of the barn", but not the IPv6 one.

(2) One of the reasons I felt that we should have done "TCPng" 
when we did IPv6 is that I believe, in retrospect, that 
TCP/IP[v4] seriously erred in letting "timeout" or "connection 
reset" be our only real ways to report "service not supported". 

   Agreed that those are not the right wayr: though "connection
reset may be "close enough", "timeout" certainly isn't.

I believe that a server should be able (and required) to return 
a definitive "no service on that port" message at the TCP level 
and perhaps that there should be a definitive way to probe for 
the presence of a service other than opening a TCP connection. 

   Either of those would be an improvement.

I believe that having that type of functionality would be an 
effective way to deal with many of the issues that we are now 
trying to push onto the DNS even though it might raise some 
complex issues about negative response caching and would make 
operations like port scanning more efficient.

   But in our "real world," DNS appears to be our best tool.
And I believe SRV RRs will get us there, though we need to be
patient and might need to tweak their definition.

But that horse is not only out of the barn, it has long since 
disappeared over the horizon.

   "Bring me that horizon!"

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