Re: Last Call: draft-klensin-rfc2821bis

Ned Freed <ned.freed@mrochek.com> Mon, 24 March 2008 18:56 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 77AC73A6E9F; Mon, 24 Mar 2008 11:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.389
X-Spam-Level:
X-Spam-Status: No, score=-100.389 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 beDd1XYoMUgg; Mon, 24 Mar 2008 11:56:14 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D9A13A6E90; Mon, 24 Mar 2008 11:56:14 -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 B0A083A6E90 for <ietf@core3.amsl.com>; Mon, 24 Mar 2008 11:56:13 -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 sNaEqxr-a-Jc for <ietf@core3.amsl.com>; Mon, 24 Mar 2008 11:56:12 -0700 (PDT)
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 47BD53A6E83 for <ietf@ietf.org>; Mon, 24 Mar 2008 11:56:12 -0700 (PDT)
MIME-version: 1.0
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MSSRIVBLYO0000BT@mauve.mrochek.com> for ietf@ietf.org; Mon, 24 Mar 2008 11:53:48 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MSSR02T9OG00007A@mauve.mrochek.com>; Mon, 24 Mar 2008 11:53:43 -0700 (PDT)
Message-id: <01MSSRIT6XVG00007A@mauve.mrochek.com>
Date: Mon, 24 Mar 2008 11:42:11 -0700
From: Ned Freed <ned.freed@mrochek.com>
Subject: Re: Last Call: draft-klensin-rfc2821bis
In-reply-to: "Your message dated Mon, 24 Mar 2008 14:33:38 -0400" <20080324183338.GB25340@verdi>
References: <200803202203.m2KM32hA031011@drugs.dv.isc.org> <DCDDC87913F69C0517A88E8B@p3.JCK.COM> <A4667B79-FD0D-451A-95ED-664755C3B9A0@mail-abuse.org> <CE4BCFBF455606AD222F42A3@p3.JCK.COM> <20080324183338.GB25340@verdi>
To: John Leslie <john@jlc.net>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1206384829; h=Date: From:Subject:MIME-version:Content-type; b=HLxzBdoR4VURpKJ4EhqaM+av5 pG4SktEA/rVU9fKk/NlHPK27T/BPPoqLbBnOpMbb/7mZzcVhqLXs77QVXP0EQ==
Cc: John C Klensin <john-ietf@jck.com>, Douglas Otis <dotis@mail-abuse.org>, ietf list <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

> John C Klensin <john-ietf@jck.com> wrote:
> > --On Saturday, 22 March, 2008 23:02 -0700 Douglas Otis
> > <dotis@mail-abuse.org> wrote:
> >
> >> The "update" of RFC2821 is making a _significant_
> >> architectural change to SMTP by explicitly stating AAAA
> >> records are within a list of SMTP server discovery records.
> >
> > Well, to be very precise, 2821 is ambiguous on the subject.

>    Agreed.

> > Some people have read (and implemented) it as if the text said
> > "address records", implying a default MX for the AAAA case as
> > well as the A one.   Others have read it more narrowly and only
> > supporting the default for A RRs.    To the extent to which
> > 2821bis is expected to eliminate ambiguities that were present
> > in 2821, it had to say something on this subject.

>    It might, however, be best to simply document the ambiguity.
> I suspect that implementation reports would show some implementations
> querying for both AAAA and A RRs, while others query only for A RRs.
> I am not convinced that 2821bis _should_ try to resolve this.

I don't think we have a choice. it is obvious that this ambiguity can lead to
interoperability problems, and that means this has to be resolved if the
document is to obtain draft standard status.

> > If it says "address records" (as the current text does),

>    Actually, it says "address RR" (if I understand what text we're
> discussing). I believe we're discussing Section 5.1 of

> http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis-09.txt

> where it says
> "
> " The lookup first attempts to locate an MX record associated with the
> " name.  If a CNAME record is found instead, the resulting name is
> " processed as if it were the initial name.  If no MX records are
> " found, but an address RR (i.e., either an IPv4 A RR or an IPv6 AAAA
> " RR, or their successors) is found, the address RR is treated as if it
> " was associated with an implicit MX RR, with a preference of 0,
> " pointing to that host.

> (Please correct me if I misunderstand what text we're discussing.)

> > you (and perhaps Mark and others) dislike the consequences and
> > claim "significant architectural change". If it is changed to
> > explicitly indicate that only A RRs can be used to imply an
> > MX record, then I assume that those who read 2821 the other way
> > and are now supporting AAAA records to generate an implied MX
> > would claim "significant architectural change".

>    Indeed, that seems likely (though not demonstrated).

>    But regardeless, we're on shaky ground if we try to force either
> kind of implementation to change. May I suggest a different starting
> point:

On the contrary, it is expected that options can be eliminated from
documents moving to draft, especially if in doing so an interoperability
problem is removed.

>    I think there's very strong consensus that the presence of an
> MX RR demonstrates the intention to receive email addressed to the
> domain in question. I don't think there's any consensus that the
> presence of an AAAA or A RR demonstrates such an intent.

Perhaps, but the fact remains that MX-less configurations are currently legal
and in use.

>    There is, however, considerable history that the presence of an
> address RR _in_combination_with_ a process listening on port 25
> of the IP address in question indicates a willingness to receive
> email for a domain identical to the domain of that address RR.

OK...

>    Whether or not we have any consensus that this historical
> practice should be deprecated (I would vote YES!), rfc2821-bis
> is not, IMHO, the right place to deprecate it.

On this we agree. We haven't gone through any sort of consensus process on this
and since there is no justification for deprecating use of A-record-only
configurations as part of a move to draft this cannot be done at time.

>    (If I may digress a bit, let me explain that this implied-MX rule
> is a real pain to me as an ISP, in that we maintain a SMTP server
> on the same IP address as a number of virtual web services; and
> the implied-MX rule brings us rather significant spam traffic that
> I'd _much_ rather be sending to a different IP address than the web-
> server for the domain in question.)

>    Getting back to my point, what would be wrong with changing this
> language in Section 5.1 to document the ambiguity instead of trying
> (probably unsuccessfully) to prescibe a single way of resolving it?

See above. This would be fine if the document were intended for proposed but it
is not. I suppose we could ask for an exception to be made but frankly I see no
grounds for granting one.

				Ned

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