Re: Last Call: draft-klensin-rfc2821bis
John Leslie <john@jlc.net> Mon, 24 March 2008 18:36 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 33FAE28C4A0; Mon, 24 Mar 2008 11:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.514
X-Spam-Level:
X-Spam-Status: No, score=-100.514 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 eR7Gbm6yVoFx; Mon, 24 Mar 2008 11:36:06 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB0F03A6C85; Mon, 24 Mar 2008 11:36:06 -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 E82363A6973 for <ietf@core3.amsl.com>; Mon, 24 Mar 2008 11:36:05 -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 ATa-LYVyxLee for <ietf@core3.amsl.com>; Mon, 24 Mar 2008 11:36:00 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 08B3028C30D for <ietf@ietf.org>; Mon, 24 Mar 2008 11:36:00 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 78B0E33D18; Mon, 24 Mar 2008 14:33:38 -0400 (EDT)
Date: Mon, 24 Mar 2008 14:33:38 -0400
From: John Leslie <john@jlc.net>
To: John C Klensin <john-ietf@jck.com>
Subject: Re: Last Call: draft-klensin-rfc2821bis
Message-ID: <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>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CE4BCFBF455606AD222F42A3@p3.JCK.COM>
User-Agent: Mutt/1.4.1i
Cc: 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. > 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: 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. 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. 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. (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? Thus, I suggest: " ... " 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 ^^ s/is/MAY be/ " was associated with an implicit MX RR, with a preference of 0, " pointing to that host. I think that is a much better description of actual practice. > Given that, the document can't win. The choices are between > ambiguity (which I hope is the lowest preference for all of us) > and picking an option that some people won't like. I do not share John Klensin's distaste for ambiguity in evolving standards. Were we starting afresh, I would put a lot of effort into clarity, but when progressing a decades-old animal like SMTP to Draft Standard, I think compatibility rates higher (and that we're only fooling ourselves to claim that all existing implementations will be changed to reflect what we write). Thus, I believe we'll be better served leaving the choice of whether to infer a non-existent MX record to implementors and administrators. As currently practiced, this implied-MX rule leads to temporary errors (not reported for many hours) on typos, instead of immediate permanent errors. Giving the immediate error, IMHO, should be an option available to administrators. > Even without the anti-spam argument that you raise, I think > there are mail performance and DNS reasons (one cited by Mark) > for declaring the utility of implicit MX records, even those > built on A RRs, to be at an end. I quite agree. (But I don't think 2821-bis can go there.) > ... I'd recommend the BCP path I comments on in an earlier note. To tell truth, I dislike writing I-Ds. But I'd be willing to help in the writing of such a document. Any other volunteers? -- John Leslie <john@jlc.net> _______________________________________________ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- RE: Last Call: draft-klensin-rfc2821bis (Simple M… Hollenbeck, Scott
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Pete Resnick
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Dave Crocker
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Ned Freed
- Lists and aliases (Re: Last Call: draft-klensin-r… Harald Tveit Alvestrand
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Pete Resnick
- Re: Lists and aliases (Re: Last Call: draft-klens… Ned Freed
- Re: Lists and aliases (Re: Last Call: draft-klens… Tony Finch
- Re: Lists and aliases (Re: Last Call: draft-klens… Ned Freed
- Last Call: draft-klensin-rfc2821bis (Simple Mail … Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Pekka Savola
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Douglas Otis
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Douglas Otis
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis John Leslie
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Douglas Otis
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Bill Manning
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Last Call: draft-klensin-rfc2821bis Bill Manning
- Re: Last Call: draft-klensin-rfc2821bis Bill Manning
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Willie Gillespie
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Markku Savela
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- RE: Last Call: draft-klensin-rfc2821bis Hallam-Baker, Phillip
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis SM
- Re: Last Call: draft-klensin-rfc2821bis Bill Manning
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Last Call: draft-klensin-rfc2821bis SM
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis SM
- Re: Last Call: draft-klensin-rfc2821bis Pekka Savola
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Bill Manning
- Implicit MX and A RRs (was: Re: Last Call: draft-… John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Implicit MX and A RRs Tony Hansen
- Re: Last Call: draft-klensin-rfc2821bis John Levine
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Tony Finch
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis John Levine
- Re: Last Call: draft-klensin-rfc2821bis Eliot Lear
- RE: Last Call: draft-klensin-rfc2821bis Tony Hain
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Dave Crocker
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- RE: Last Call: draft-klensin-rfc2821bis Hallam-Baker, Phillip
- Re: Last Call: draft-klensin-rfc2821bis Willie Gillespie
- IPv6 incentive? RE: Last Call: draft-klensin-rfc2… Hallam-Baker, Phillip
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Jim Fenton
- Re: Last Call: draft-klensin-rfc2821bis David Conrad
- RE: Last Call: draft-klensin-rfc2821bis Tony Hain
- Re: Last Call: draft-klensin-rfc2821bis Dave Crocker
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- RE: Last Call: draft-klensin-rfc2821bis Hallam-Baker, Phillip
- RE: Last Call: draft-klensin-rfc2821bis Tony Hain
- RE: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Implicit MX and A RRs John C Klensin
- Re: Implicit MX and A RRs Matti Aarnio
- RE: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Implicit MX and A RRs Tony Finch
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Last Call: draft-klensin-rfc2821bis Joe Abley
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis David Morris
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Implicit MX and A RRs Keith Moore
- RE: Last Call: draft-klensin-rfc2821bis michael.dillon
- Re: Last Call: draft-klensin-rfc2821bis Douglas Otis
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Implicit MX and A RRs Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Pekka Savola
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Pekka Savola
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Dave Crocker
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Theodore Tso
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Henning Schulzrinne
- Re: Last Call: draft-klensin-rfc2821bis John Levine
- Re: Last Call: draft-klensin-rfc2821bis SM
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis SM
- Re: Last Call: draft-klensin-rfc2821bis John Levine
- Re: Last Call: draft-klensin-rfc2821bis Dave Crocker
- Re: Last Call: draft-klensin-rfc2821bis Henning Schulzrinne
- Re: Last Call: draft-klensin-rfc2821bis David Morris
- Re: Last Call: draft-klensin-rfc2821bis Dave Crocker
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Tony Finch
- Re: Last Call: draft-klensin-rfc2821bis Henning Schulzrinne
- Re: Last Call: draft-klensin-rfc2821bis Bill Manning
- Re: Last Call: draft-klensin-rfc2821bis Dave Crocker
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis: closing … Tony Hansen
- Re: Last Call: draft-klensin-rfc2821bis: closing … Dave Crocker
- Re: Last Call: draft-klensin-rfc2821bis: closing … Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis: closing … Lisa Dusseault
- Re: Last Call: draft-klensin-rfc2821bis: closing … Douglas Otis
- Re: Last Call: draft-klensin-rfc2821bis: closing … Hector Santos
- Re: Last Call: draft-klensin-rfc2821bis: closing … Henning Schulzrinne
- Re: Last Call: draft-klensin-rfc2821bis: closing … Dave Crocker
- Re: Last Call: draft-klensin-rfc2821bis: closing … Paul Smith
- Re: Last Call: draft-klensin-rfc2821bis: closing … Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis: closing … Tom.Petch
- Re: Last Call: draft-klensin-rfc2821bis: closing … Hector Santos
- Re: Last Call: draft-klensin-rfc2821bis: closing … Robert A. Rosenberg