Re: Last Call: draft-klensin-rfc2821bis

John C Klensin <john-ietf@jck.com> Wed, 26 March 2008 08:44 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietfarch-ietf-archive@core3.amsl.com
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467E628C3CE; Wed, 26 Mar 2008 01:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.257
X-Spam-Level:
X-Spam-Status: No, score=-100.257 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_52=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmbb2yOQ2m7I; Wed, 26 Mar 2008 01:44:10 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D3D28C421; Wed, 26 Mar 2008 01:44:10 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EAFF28C3EE for <ietf@core3.amsl.com>; Wed, 26 Mar 2008 01:44:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwxyjXWKYZBO for <ietf@core3.amsl.com>; Wed, 26 Mar 2008 01:44:07 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 206063A67EA for <ietf@ietf.org>; Wed, 26 Mar 2008 01:44:07 -0700 (PDT)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1JeRCZ-0008Pm-Jl; Wed, 26 Mar 2008 04:41:43 -0400
Date: Wed, 26 Mar 2008 04:41:42 -0400
From: John C Klensin <john-ietf@jck.com>
To: Bill Manning <bmanning@ISI.EDU>, SM <sm@resistor.net>
Subject: Re: Last Call: draft-klensin-rfc2821bis
Message-ID: <E8BC25B9A77418AAFBDCE171@p3.JCK.COM>
In-Reply-To: <20080326072725.GA730@boreas.isi.edu>
References: <20080325133807.GA12616@boreas.isi.edu> <200803252230.m2PMURNF072389@drugs.dv.isc.org> <20080326023244.GB26917@boreas.isi.edu> <6.2.5.6.2.20080325212302.02a7ac70@resistor.net> <20080326072725.GA730@boreas.isi.edu>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--On Wednesday, 26 March, 2008 00:27 -0700 Bill Manning
<bmanning@ISI.EDU> wrote:

> 	what this daft is trying to do is force the presumptive
> 	existance of an MX in a zone into an explict rule that 
> 	forces the existance of an MX, else SMTP fails.

While several people have suggested that, it is not what the
draft says and would be a significantly incompatible change.
What the draft basically says is that, if there is no MX record
present, one should go looking for the same domain name with an
address record type and, if such a thing is found, construe the
address record as if it were associated with an MX record with
preference of zero.

With one qualification, that has been the rule ever since RFC
974 was written.  That rule was reaffirmed in RFC 1123.  There
was no change to it in 2821.

At the time 974 and 1123 were written, the only sort of address
record in Class=IN was an A RR, and those documents used "A RR"
terminology.  The change in 2821bis essentially substituted the
phrase "address record" (or "address RR") for "A record" because
(i) that seemed to be consensus on the list at that time and
(ii) there is significant, although not universal, existing
practice that is consistent with treating IPv4 (A) and IPv6
(AAAA) RRs the same way, at least with regard to SMTP.

With that change to "address record", if no MX record is found,
the SMTP client is required to look for DNS names with either A
or AAAA RRs, rather than A RRs only.

As far as I can tell, the _only_ real question here is whether
that "either type of address record can be used as an implicit
mail destination if no MX record is present" rule, which is now
in the text, is the correct one.   If it is not, then the only
other option is to try to keep the implicit destination rule to
A (IPv4) records only, which would essentially require that an
MX record be present if one wanted to deliver mail to an IPv6
host.

The questions of whether MX records should be generally
required, what happens when an application chooses to ignore the
MUST NOT rule in Section 5.1 and use address records when an MX
record is present, and a number of other issues are, it seems to
me, very interesting but not relevant here... if only because
they would constitute very significant and incompatible changes
from 2821 and to the installed base.  There is, separately, some
language in Section 2.3.5 about the types of domain names that
can be used as FQDNs in mail sessions; I don't believe those
rules are affected by this discussion either.

>> We could look at the question by asking whether the fallback
>> MX  behavior should be an operational decision.  But then we
>> would be  treating IPv4 and IPv6 differently.
> 
> 	IPv4 and IPv6 are different.

Bill, I don't know what you are advocating any more.  It seems
to me that, by saying that you want to be able to run a mail
server without MX records and with IPv6 only (I think you said
that, but maybe I understood), you are asking for exactly the
behavior that is now in the specification, i.e., that either A
or AAAA RRs can be used to form an implicit MX.   For this
purpose, that makes IPv6 and IPv4-related DNS records pretty
much the same, no matter what the differences are between the
protocols.

In addition, the applications area has been told, repeatedly,
that its protocols should, by default, treat IPv6 like IPv4,
keeping any differences in treatment to a minimum.  So, saying
"IPv4 and IPv6 are different" at this stage, while true, does
not seem sufficiently explanatory to be a useful contribution to
the discussion.

     john



_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf