Re: [DNSOP] Last Call: <draft-ietf-appsawg-nullmx-05.txt> (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
Dave Crocker <dhc@dcrocker.net> Thu, 17 July 2014 21:01 UTC
Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB2F1A00DA; Thu, 17 Jul 2014 14:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZJYpbf2pj3b; Thu, 17 Jul 2014 14:01:44 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104C51B27EC; Thu, 17 Jul 2014 14:01:44 -0700 (PDT)
Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s6HL1d7f014488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 17 Jul 2014 14:01:42 -0700
Message-ID: <53C8394A.6080508@dcrocker.net>
Date: Thu, 17 Jul 2014 13:59:54 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>, ietf@ietf.org
Subject: Re: [DNSOP] Last Call: <draft-ietf-appsawg-nullmx-05.txt> (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
References: <20140703190347.24899.45193.idtracker@ietfa.amsl.com> <7140A115A74391DED82A2028@JcK-HP8200.jck.com>
In-Reply-To: <7140A115A74391DED82A2028@JcK-HP8200.jck.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 17 Jul 2014 14:01:43 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/FZqriPB7w7a0MmBLRObGJqk7CZA
Cc: dnsop@ietf.org, apps-discuss@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
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>
X-List-Received-Date: Thu, 17 Jul 2014 21:01:46 -0000
On 7/17/2014 10:39 AM, John C Klensin wrote: > Hi. For a number of reasons, many of which have been identified > by others, I find this draft and the actions it recommends > distasteful. Since I'm the doc shepherd: I have not seen statements by others indicating that the specification is 'distasteful', although there have been some that seemed to confuse its functionality with that of SPF. Feel free to cite the specific comments by others that classed this as distasteful or the equivalent. > I see it as another step, albeit a small one, in > the direction of prioritizing the prevention of unwanted > messages or connections over successful delivery of legitimate > messages. A statement of "I don't do X" does not 'prioritize' anything. The use of information that says "target address Y will not work because there is not receiver at Y's domain" does not 'prioritize' anything. The specification is nothing more than a vastly more efficient form of getting an SMTP 550 Requested action not taken: mailbox unavailable, except that it is even better than that, because it also precludes waiting days to discover that there's no service to supply even that error message. > Hope, it would be better if the specification were historically > accurate and accurate about the protocols it cites. You do not clearly indicate any historical inaccuracy at issue. > The last sentence of the second paragraph of Section 5 > ("Security Considerations") of the spec says: > > "The normal way to send mail for which a sender wants no > responses remains unchanged, by using an empty > RFC5321.MailFrom address." > > First, two issues of terminology: > > (1) RFC 5321 does not contain or specify notations like > "RFC5321.MailFrom". That notation was introduced in RFC 5598, a > document that was approved as Informational with a consensus > that, IIR, included some significant desire that it not be > normative or casually treated as normative. If this First, so what? Second, a review of the IETF mailing list archive about the document's Last Call, in May of 2009, shows a nicely solid pattern of support for the document's publication. Strange that you would call it into question at this point. > specification wants to use that notation, that is fine. But it > should include an explicit note to that effect in its > introduction or a Terminology section, not bury a "(see > [RFC5598] for the definitions of these terms)" reference in a > parenthetical note in Section 4.1 and then expect readers who > are looking specifically at other sections to pick up on it. If you want specific text changes, please suggest specific text changes. Please do not formulate a requirement for change in a fashion that leaves the authors having to guess whether it will satisfy you. > I believe that the RFC Editor's principle is that, if particular > terminology is needed to correctly understand a specification, > then the reference to the document that defines that terminology > is normative. In this particular case, it seems inconsistent to > consider 2119 normative and 5598 informative since both are used > to define terminology without which the document cannot be > correctly understood. So, you are suggesting that RFC 5598 be a normative reference here? > (2) Second, RFC 5321 does not contain a concept that it calls an > "empty address". The terminology it does use is "null > reverse-path" (See RFC 5321, Section 3.7). Subject to the > above, if the authors want to say "null address in > RFC5321.MailFrom", I don't think that is sufficiently confusing > to be a problem. But "empty address" could be construed as > MAIL FROM: > in the envelope with nothing following it, and that would be bad > news. So you are suggesting: empty RFC5321.MailFrom address -> null ("<>") reverse-path, per 3.6.3 and 6.1 of RFC 5321 > More important, however, RFC 5321 specifies the use of a null > reverse path only for delivery failure and status notifications > and message disposition notifications (see Section 4.5.5 of RFC > 5321) and constrains the recipient address to be used. That > section also says > > "All other types of messages (i.e., any message which is > not required by a Standards-Track RFC to have a null > reverse-path) SHOULD be sent with a valid, non-null > reverse-path." And here I was, thinking that "SHOULD" means it is ok /not/ to do what is being directed, if you have a good reason. Oh, wait... > Specifically referring to Section 3 of > draft-ietf-appsawg-nullmx-05, there is not such thing as a "NULL > MX Resource Record". There is only an MX Resource Record that > this specification proposes to use with a convention involving > specific content in the DATA. One could call that many things, > but "NULL MX Resource Record" isn't one of them. By my reading of that section, it is defining the term, if only by virtue of the way it is used in the name of that section. Perhaps your confusion would be resolved if the term had a comma in it, so: NULL, MX Record? In other words, NULL is an adjective within the term. If you would prefer a different term, please suggest one. > (b) I think I know what the second paragraph of 4.1 in intended > to convey but I have now read it several times and can't be sure > that it what is says. The parenthetical terminology note > doesn't help with readability but the problem exists even > without it. Take a look at the sub-section's title. Note that the first paragraph reviews benefits for an SMTP client and then note that the second paragraph extends into talking about a particular benefit for a receiving SMTP server, per the section's title. NullMX allows a receiving SMTP server to detect when a return-path address uses a domain name that does not receive mail. Hence, at submission time, the receiving server can reject such messages. > (e) The issues identified above aside, the explanation in the > second paragraph of Security COnsiderations (Section 5) is > unsatisfying. If a domain is configured so that some sending > hosts don't receive and some receiving hosts don't send, the > model specified in this document may simply be inappropriate and > shouldn't be used lest it cause lost messages. Why can't that > simply be said, and said clearly (probably in another section > referenced from this one. How would that be better than what is in the current draft? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… John C Klensin
- Re: [DNSOP] Last Call: <draft-ietf-appsawg-nullmx… Dave Crocker
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Murray S. Kucherawy
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… John C Klensin
- Re: [DNSOP] Last Call: <draft-ietf-appsawg-nullmx… Mark Andrews
- Re: [DNSOP] Last Call: <draft-ietf-appsawg-nullmx… Sandy Wills
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Viktor Dukhovni
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Dave Crocker
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… John C Klensin
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Dave Crocker
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Mark Andrews
- Re: [DNSOP] Last Call: <draft-ietf-appsawg-nullmx… Murray S. Kucherawy
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… John Levine
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Tony Finch
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Ted Lemon
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… John C Klensin
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Dave Crocker
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Tony Finch
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Ted Lemon
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… John Levine
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Dave Crocker
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Ted Lemon
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Ted Lemon
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Nico Williams
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Nico Williams
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Dave Crocker
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Ted Lemon
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… ned+ietf
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Hector Santos
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Hector Santos
- summary for Last Call: <draft-ietf-appsawg-nullmx… John Levine
- Re: summary for Last Call: <draft-ietf-appsawg-nu… ned+ietf
- Re: summary for Last Call: <draft-ietf-appsawg-nu… John R Levine
- Re: summary for Last Call: <draft-ietf-appsawg-nu… Dave Cridland
- Re: summary for Last Call: <draft-ietf-appsawg-nu… Tony Finch
- Re: summary for Last Call: <draft-ietf-appsawg-nu… John R Levine
- Re: summary for Last Call: <draft-ietf-appsawg-nu… ned+ietf
- Re: summary for Last Call: <draft-ietf-appsawg-nu… Tony Finch
- Re: summary for Last Call: <draft-ietf-appsawg-nu… ned+ietf
- Re: summary for Last Call: <draft-ietf-appsawg-nu… Tony Finch
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Mark Andrews
- Re: summary for Last Call: <draft-ietf-appsawg-nu… ned+ietf
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Viktor Dukhovni
- Re: summary for Last Call: <draft-ietf-appsawg-nu… Viktor Dukhovni
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Viktor Dukhovni
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… S Moonesamy
- Re: summary for Last Call: <draft-ietf-appsawg-nu… Tony Finch
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Douglas Otis
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Viktor Dukhovni
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Dave Crocker
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… John R Levine
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Scott Kitterman
- Re: summary for Last Call: <draft-ietf-appsawg-nu… ned+ietf
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… John C Klensin
- Re: [apps-discuss] Last Call: <draft-ietf-appsawg… Nico Williams
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Ted Lemon
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Douglas Otis
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… Viktor Dukhovni
- Re: Last Call: <draft-ietf-appsawg-nullmx-05.txt>… John Levine
- Last Call conduct redux (Was: Last Call: <draft-i… Pete Resnick