Re: Last Call: draft-klensin-rfc2821bis
Ned Freed <ned.freed@mrochek.com> Mon, 24 March 2008 21:59 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 57F4C28C421; Mon, 24 Mar 2008 14:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.397
X-Spam-Level:
X-Spam-Status: No, score=-100.397 tagged_above=-999 required=5 tests=[AWL=0.040, 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 L+oss3Yd-44K; Mon, 24 Mar 2008 14:59:35 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2DFD28C2DA; Mon, 24 Mar 2008 14:59:30 -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 82C4728C2D0 for <ietf@core3.amsl.com>; Mon, 24 Mar 2008 14:59:29 -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 iDKDwI0aln9J for <ietf@core3.amsl.com>; Mon, 24 Mar 2008 14:59:28 -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 81EC328C1B2 for <ietf@ietf.org>; Mon, 24 Mar 2008 14:59:27 -0700 (PDT)
MIME-version: 1.0
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MSSXX1HJ8G0000UY@mauve.mrochek.com> for ietf@ietf.org; Mon, 24 Mar 2008 14:57:02 -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 14:56:57 -0700 (PDT)
Message-id: <01MSSXWZKKZ800007A@mauve.mrochek.com>
Date: Mon, 24 Mar 2008 14:46:47 -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:17:48 -0700" <BF8F31B9-DC05-4088-A353-3FE8F0CA876A@mail-abuse.org>
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> <01MSSRIT6XVG00007A@mauve.mrochek.com> <BF8F31B9-DC05-4088-A353-3FE8F0CA876A@mail-abuse.org>
To: Douglas Otis <dotis@mail-abuse.org>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1206395823; h=Date: From:Subject:MIME-version:Content-type; b=D+WBUHAmb2PeQKjswfDa/X+xr lwxsxolg4LNr6NVBCamAuDNxKCzqlOAFAVEFYwqjnmCDcTldfTDZgb2vCy8dg==
Cc: John C Klensin <john-ietf@jck.com>, Ned Freed <ned.freed@mrochek.com>, John Leslie <john@jlc.net>, 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
> On Mar 24, 2008, at 11:42 AM, Ned Freed wrote: > >> 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. > Anyone who relies upon just publishing AAAA records to enable the > discovery of their receiving MTAs are unlikely to find this to be > widely interoperable. Until such time that A records for discovery > have been deprecated, the A record method of discovery or email- > address domain validation continues to be used. MX records have been > in use for a period long enough to safely rule out new explicitly > "implied" MX records. The choice seems rather clear, especially in > the face of undesired traffic created by implied use of address > records. Please don't add AAAA or any future address record to a list > of records likely to be abused by spammers. I'm afraid this is nothing but a strawman. Nowhere did I say _how_ the ambiguity should be resolved, only that it needs to be resolved one way or the other. If the consensus is that better interoperability can be had by banning bare AAAA records that's perfectly fine with me. What is not fine is saying "maybe bare AAAA works, maybe it doesn't, good luck and be happy". That's what I understood was being advocated and why I jumped into this now. > >>> 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. > Clarity can be established and interoperability _improved_ by limiting > discovery to just A and MX records. Perhaps a note might be included > that at some point in the future MX records may become required. Again, I have no problem with this approach if that's what the consensus is. > >> 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. > While there are some that use A records, which remains largely due to > prior practices, these prior practices did _not_ include the use of > AAAA records. Which is really irrelevant since the point I was addressing is the idea of banning the bare A practice oing forward. > >> 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. > To avoid ambiguity, A and not AAAA records would be an accurate > statement of prior practices. Agreed. > > 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. > Agreed, but making assurances regarding use of AAAA records for the > purpose of discovery is ill advised, to say the least. > >> (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.) > As more SMTP domains attempt to publish policies of various sorts, > validation of the domain will also likely depend upon finding > requisite discovery records. Adding AAAA and all future address > records to a list of SMTP discovery records fails miserably at taking > advantage of the MX record replacing the function of the generic A > record. Another point in favor of not allowing bare AAAA records for mail routing. > >> 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. > To say that AAAA records can be used for discovery would be equally > wrong from an interoperability standpoint. The only valid solution > would be to indicate that AAAA records as a discovery mechanism may > not be supported and should not be used for this purpose. Use MX > records instead. Which is perfectly fine as far as I'm concerned. The question is whether there's a consensus to resolve the ambiguity in this fashion. Ned _______________________________________________ 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