From sm@elandsys.com Sun May 5 23:37:12 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B487621F85F4 for ; Sun, 5 May 2013 23:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuj5GFYvL0dF for ; Sun, 5 May 2013 23:37:12 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C21CE21F85EE for ; Sun, 5 May 2013 23:37:10 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.42]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r466avet025430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 5 May 2013 23:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367822228; bh=XBXwA6mu6MNxWM9WknnqAniL3hQ9qRVOkVOmb12qE5c=; h=Date:To:From:Subject:In-Reply-To:References; b=r5/RHZ1kBWushy3QdmoV7oyy5MENYvbYxm/WAiAwIaQKqLfy6OVgiEMOgojCw+C4g ClFgbtz7x3HFylJjWPep4y46pV5NSwolXTmz1S//bCmccKtV+ESprQsD5JNZ1fS27G WFTS3hwbhzSD5zTZdvn2LqIhhvNKUqtHg9e82G4A= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367822228; i=@elandsys.com; bh=XBXwA6mu6MNxWM9WknnqAniL3hQ9qRVOkVOmb12qE5c=; h=Date:To:From:Subject:In-Reply-To:References; b=ekSprtlLWn/9zqwY6QGXVpuhJpYn8PSxVqEIIgvs7opzdqvrHkUjgZdHJcDYKX1Lp p26oLk+UlNFRGvGsgPmgxZ8oLc1F0HOcsmdcH7C4QYrwJf9ggVfLLrTh9/q9CEaK/V nC7gEUwVe9PirUq1718WQpoOQeqQAnQwqaytSq4A= Message-Id: <6.2.5.6.2.20130505232307.0b7de158@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 05 May 2013 23:33:23 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <6.2.5.6.2.20130430214208.0be80a90@elandnews.com> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <6.2.5.6.2.20130430111045.0a7ebc30@elandnews.com> <3198772.42M6YQxPyW@scott-latitude-e6320> <6.2.5.6.2.20130430172422.0d6ca9c8@resistor.net> <7d677814-3b49-4a87-bfe3-d36c6f14378e@email.android.com> <6.2.5.6.2.20130430214208.0be80a90@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Addressing reviews (was: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 06:37:13 -0000 Hi Scott, The milestone for draft-ietf-spfbis-4408bis-14 is May 2013. The draft has already gone through WGLC. Can you provide an estimate date of when the reviews and comments received during the WGLC can be addressed? Regards, S. Moonesamy (as document shepherd) From SRS0=/FKTo=OZ==stuart@gathman.org Tue May 7 21:59:47 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F158421F8F0D for ; Tue, 7 May 2013 21:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0M3Qe8d6oqxI for ; Tue, 7 May 2013 21:59:46 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id 100C121F8EE8 for ; Tue, 7 May 2013 21:59:45 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (PLAIN sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1367989205; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=3jFQ9MVMVzaqpXiWkxyUYaJiUFjEXLLsJolwq7u6ivo=; b=SByKC0O7BkkYB+pMQrnZgRWJmBI1NMCJpkH7J7Tu+T4qmng6Dkuo6s9onBGY6o/2mq11Gk 4SLefhsst/CAp0EVT9NLz6blRn1CsyftrNElSuJxm40zX941a6skpGG986hHQENBkcQD9K5o BVAEbvrfPNWymLPf+HgENakyic43U= Received: from silver.gathman.org ([IPv6:2001:470:8:809:495a:34ab:4362:cc38]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r484xs3K003400 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 8 May 2013 01:00:05 -0400 Message-ID: <5189DBB3.2030800@gathman.org> Date: Wed, 08 May 2013 00:59:31 -0400 From: Stuart Gathman Organization: BWI Corporation User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130430001101.8968.qmail@joyce.lan> <5030770.G8l1OVMDOL@scott-latitude-e6320> In-Reply-To: <5030770.G8l1OVMDOL@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 05:00:10 -0000 On 04/29/2013 08:42 PM, Scott Kitterman wrote: > On Tuesday, April 30, 2013 12:11:01 AM John Levine wrote: >>>> 'Alternatively, for a server failure (RCODE 2) result, check_host() >>>> >>>>> MAY track failures and treat multiple failures within 24 hours for >>>>> the same domain as "permerror".' >>>>> >>>>> This text is not in RFC 4408. I found a note in Issue #1 [5] and in a >>>>> message [6]. >>>>> >>>>> Are there any implementations that do this? If so, that's the >>>>> justification; it's practical experience. If not, we should consider >>>>> dropping it. >>>> I'll wait for feedback on this. >> Not that I'm aware of. That looks to me like an optimization to do in >> the DNS cache, not in the client. > This was issue #1 in the tracker: > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/1 > > It was discussed as a resolution to an operational issue discovered during SPF > deployment. > This also solves the TIMEOUT for type 99 problem. Reporting a PermError for a broken name server would be very appropriate (and switching to checking TXT first while said failure is cached would also be permissible). From spf2@kitterman.com Wed May 8 08:14:31 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DCF21F9079 for ; Wed, 8 May 2013 08:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEg4IRhuT+an for ; Wed, 8 May 2013 08:14:26 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 42D5621F9356 for ; Wed, 8 May 2013 08:14:26 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6342320E412A; Wed, 8 May 2013 11:14:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368026065; bh=2HZaWgyUt+XCCTNDpbi5xygthKO7OnRlqQZSGd1KAd8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Ow97ppoxPlDyytpz+QTxE5GSGjZlgWzTJdh+Bs/A0wupYU4aaoWh8Ode2yAl6/HAm EWh37YmXeU0WpELn0Z1qyu0Vq8RsMu6pQy1RzRJfEIgbGc/v2WxUsxctGwNIFrO6mJ AGQ+PmxDb545pROVfR5ss5DdNCCwL87syKQ5lugo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 453B820E40F6; Wed, 8 May 2013 11:14:24 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 08 May 2013 11:14:24 -0400 Message-ID: <33369700.0DMhrZAH3v@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <517C453A.4080406@Commerco.Net> References: <20130427185301.28485.qmail@joyce.lan> <517C453A.4080406@Commerco.Net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] IPv4 mapped IPv6 addresses X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 15:14:31 -0000 On Saturday, April 27, 2013 03:38:02 PM Commerco WebMaster wrote: > On 4/27/2013 12:53 PM, John Levine wrote: > >> As I understand it, the idea is that a connection arriving via an > >> IPv6-mapped IPv4 address is supposed to be reported to the accepting > >> application as an IPv4 connection, so SPF would never know about the > >> "IPv6-mapped" part in the first place. > > > > It depends on the implementation. Here in FreeBSD land, the preferred > > way to listen to both IPv4 and IPv6 is to set up two sockets and > > listen to both, but you can also flip a kernel setting, listen on one > > IPv6 socket, and the IPv4 connections will show up in your application > > on mapped addresses. > > > > The current language on page 21 of the draft seems fine to me, at > > worst harmless, and addresses the real situation I described above. > > > > R's, > > John > > +1 Coming back to this a bit late, based on the discussion, I think it makes sense to keep the existing language. Scott K From spf2@kitterman.com Wed May 8 10:14:08 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3B821F8C7D for ; Wed, 8 May 2013 10:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_40=-0.185, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDfIb2apkwLB for ; Wed, 8 May 2013 10:14:03 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7730121F89E2 for ; Wed, 8 May 2013 10:14:03 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9228420E412A; Wed, 8 May 2013 13:14:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368033242; bh=h/q1fCUEiWwr496LPcb7M4cQLC6cmKyNeSW77s1JQPE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UiQJTsHEvUAnSGh7FkQ6dxOUERkIxbkKq+LHk8gng+RzlU/gPmdHXxHHbI0+tD31y skgcpdRli/4ZbFySYGFDEUwazF2R5y/OlSszgRQysxPynF+BMplm1d5amFToEdj2p3 IoN65AXhJ+WV/5jsrsRrq8/ocaH67E8SXZP+TsTo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 737B520E40F6; Wed, 8 May 2013 13:14:02 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 08 May 2013 13:14:01 -0400 Message-ID: <1734898.5zN0vMnxl3@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <20130409062431.GK24624@mx1.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 17:14:08 -0000 On Tuesday, April 23, 2013 11:03:37 AM Murray S. Kucherawy wrote: > On Mon, Apr 8, 2013 at 11:24 PM, Andrew Sullivan wrote: > > Dear colleagues, > > > > This message initiates a two-week working group last call on > > draft-ietf-spfbis-4408bis-14, our only work item. > > > > The draft has been through 14 revisions, and all open issues in the > > tracker are closed. Please review the document and indicate any > > comments you have by sending a note to the mailing list. If you have > > no comments, it is valuable nevertheless to learn that you have read > > the document and support its publication. > > > > WGLC will close at 2014-04-24 00:00 UTC. > > > > SM will be the shepherd for this document. > > Most of this is nits; except as noted, you could ignore it all and I'd be > happy. Nevertheless: > > Section 1: > > The last paragraph makes the claim that domain reputation is likely to be > more accurate than IP reputation. Is it worthwhile to add a sentence or > two explaining why this is true? I don't think so. First, it's speculation and I don't think enough of a case for it can be made without being too long/distracting. Second, it's not part of the protocol, so it not something we should worry about overmuch. > Section 1.1.2: > > Suggest replacing the first sentence with "ABNF is defined in [RFC5234], as > are the tokens ALPHA, ..." As it is now, "ABNF" is not expanded on first > use. Done. > Section 1.1.3: > > Replace the last sentence with: "Note that other terms that might > superficially look like the common terms, such as 'reverse-path', are used > only as they are specified in their defining documents." Done. > Section 2.1: > > I think someone else already mentioned this, but how does encouraging a > second check decrease DNS resource use? I did reply to this already. It's a matter of HELO records generally being much 'cheaper' than mail from records. > Also, suggest replacing the first sentence of the second paragraph with > "Note that requirements for the domain presented in the EHLO or HELO > command are not always clear to the sending party, and SPF verifiers MUST > be prepared for is identity to be an IP address literal, or simply be > malformed." We might even reference the IP address literal ABNF in > RFC5321 here. Done (both changes) > Section 2.2: > > Add to the first paragraph "...or no HELO check was done." or something of > that ilk. Done. > Section 2.3: > > The second paragraph is loaded with negatives "no... neither... nor." > Suggest: "ADMDs can publish SPF records that authorize no hosts to use > their DNS domain names in HELO or MAIL FROM commands during SMTP sessions." I added that, because it's a good point, but it doesn't replace the existing text which attempts to (without being too pointed about receiver policy) say that if you want receivers to be able to reject mail that didn't come from authorized hosts, you need a -all record. Some senders care about supporting these negative assertions, others don't. > Section 2.4: > > Isn't the fourth paragraph implicit in any standards specification? That > is, do we really need it? I see your point, but I think it should actually stay. Consistency of evaluation across multiple implementations is key to the success of the protocol. IIRC, you said during the debate that if you were implementing SPF, you'd ignore the macro requirements. You're, of course, free to do that, just don't say you implemented SPF. > Section 2.5: > > I can't remember if I suggested it previously, but an appendix of RFC5451 > gives a pretty thorough treatment of the notion of doing mail > authentication checks during the SMTP session versus later. It might be > helpful as an informative reference here. Added. > Section 2.6.7: > > Does "permerror" also result when permanent DNS errors occur? Tell me how to figure out when a DNS error is permanent and then maybe. Given what's described in 4.4 Record Lookup, I think only extended SERVFAIL (if the receiver has implemented the temperror -> permerror promotion option) can currently get a permerror. > Section 3.1: > > s/alternate/alternative/ Done. > > Section 4.1: > > The list of check_host() inputs have been repeated here as in Section 2.4. > Do we need both lists? I think not. I made 2.4 reference 4.1 and removed the duplication. > Section 4.4: > > s/suggests on an algorithm/suggests an algorithm/ Done. > > Section 4.6.4: > > I imagine you're going to say that 10 is the limit imposed by most > implementations, but shouldn't we say that there should be a finite, > perhaps configurable limit, and operational experience has shown that 10 is > a reasonable default? No. We need consistent limits because if receivers vary the limits, then there will be inconsistent results and poor interoperability. > Why 20 seconds for the overall run time? This is carried forward from RFC 4408. It was moved from section 10.1 to 4.6.4 as part of issue #6, but the value is unchanged. I'm not aware of any issues with what's defined in 4408. > Section 4.8: > > In the third paragraph, a couple of sentences start with "Domain" when you > actually mean it as a literal parameter name. I suggest using "domain" > (including the quotes) instead. Done. > The "Some implementations ..." sentence seems to be malformed. I can't > parse it. Better? Note: Historically, this document has made no provisions for how to handle domain-specs, or macro-expansions thereof, that are syntactically invalid per , such as names with empty labels (e.g., "foo..example.com") or overlong labels (more than 63 characters). Some implementations choose to treat mechanisms associated with such expansions as no-match and ignore modifiers with such names, others return a "permerror" exception. The outcome for an unexpected domain-spec without macros might even differ from that for an unexpected <target-name> after macro expansion. > Section 5.2: > > s/Check_host/check_host/ (it's not a word that starts sentences and thus > needs capitalization) Done. > Missing end-quote at the end of bullet 3. > Done. > The second-last paragraph is weirdly wrapped. Is the XML ok there? I think I fixed that already based on John Levine's comments. Please double check the new draft. > Section 5.4: > > Should the limits stuff in here be removed, and simply reference Section > 4.6.4 instead? Yes. Done. > Section 5.5: > > The SHOULD NOT in here is puzzling. Does it interfere with > interoperability to use it? It was my impression that it's possible to get > the same functionality some other way, but not that using "ptr" actually > was a bad idea for interoperability reasons. Yes, because it produces inconsistent results and is error prone. Both those things impact interoperability. > Again with the limits stuff, redundant to Section 4.6.4. Done. > Section 5.6: > > For IPv4, shouldn't the CIDR be 1*2DIGIT? For IPv6, shouldn't the CIDR be > 1*3DIGIT? I don't know. It's unchanged from RFC 4408 right now, but I'd like other opinions on changes here (ABNF makes my head hurt). > Section 6.2: > > It just occurred to me that in the earlier sections (2 or 4, in > particular), it's clear that check_host() returns one of the enumerated > result, but it's never made explicit that it also outputs an explanation > string. We might want to mention this earlier than we do now so it's not a > surprise later. It's an optional and somewhat rare output of the protocol, so I think not, but did you have something specific in mind? > > The SHOULD in the fifth paragraph is questionable: How does it describe an > aspect of interoperability? It avoids the risk of a common implementation error in SPF libraries (that process left to right) so it promotes consistent results. It also helps for human readability, but I think it helps the protocol too. > > Last paragraph, s/exp=/exp/ 2x. Done. > Section 7.1: > > ABNF rules say literal strings in productions are case-insensitive. That > means the macro-letter set actually implicitly includes all of the capital > letter equivalents. If we want to constrain it to lowercase only, we need > to use hex notation. OK. If someone would provide those, it would be great. Otherwise, I'll take a shot at it, probably Friday. > Section 7.3: > > "This macro SHOULD NOT be used...." should be in its own paragraph. Also > the second sentence should be "See Section xxx for discussion." Done. > At the end of this section, there are three paragraphs that all start > "Note:". I don't think those tags add anything and suggest they be removed. Done. > Section 8: > > Second paragraph, s/, and where/ and, where/ Done. > Section 8.7: > > Don't the last two sentences say the same thing? Almost. One is error due to macro expansion giving a bogus result. the other is an error due to check_host being handed a bad domain as an input. > Section 9.1: > > Same point about the case-insensitivity of ABNF here. Except for "Received-SPF" is there anything case insensitive there? I'd greatly appreciate text for this too. > The "SPF verifiers MUST make sure..." doesn't seem actionable to me. Do we > really expect Received-SPF generators to be able to identify and exclude > malicious data? I think you have to. I've seen people put html pointing to malicious web sites in SPF records. Thanks to someone privately pointing this class of attack out to me, my SPF validator now properly escapes anything that's retrieved from DNS. > > Section 10: > > s/document/protocol/ (or specification) x3 Done. > Section 10.1.1: > > s/required/necessary/ I went with needed. > Section 10.1.2: > > Add "at the cost of a DNS query per receiver" to the end of the first > sentence. Done. > Section 10.1.3: > > s/to hostname/to the hostname/, s/of domain/of the domain/ Done. > Section 10.2: > > Missing close parenthesis in the first paragraph. I don't see it. I may have fixed it already. Please double check. > Section 10.3: > > Errant period in the first sentence. Fixed. > s/Address/address/ Done. > Section 11.1: > > Aren't the first and third bullets describing the same attack? No. One's a DoS due to lots of mail being sent. The other's a DoS due to the way malicoius SPF records are constructed. Similar, but not the same. > Missing parenthesis at the end of the fourth bullet. Fixed. > Section 11.3: > > Clobbering the DNS at a receiver could also result in delivery of malicious > mail if the receiver is configured to pass on "tempfail" and just add a > header field. Good point. I added a sentence on to bullet two in 11.1. It seemed to fit there. Please let me know what you thing. > Is that second bullet true? It appears to claim that IP address spoofing > is effectively impossible. In any way that would be useful for SPF, it is AFAIK. > Section 11.5: > > This appears to be an incomplete thought. At a minimum, it doesn't flow > nicely into the next subsection. Maybe add a sentence to indicate that > SMTP itself doesn't do anything to validate those parameters? Added. > Section 11.5.2: > > Remove commas around the section reference. Done. > Appendix A: > > Any changes made to ABNF above need to be reflected down here. I believe they are consistent. > Appendix B.3: > > Suggest a reference to RFC5782. Done. > Appendix C: > > s/implmentation/implementation/ Done. > Appendix G: > > Fourth paragraph: As I mentioned above, RFC5451 has an appendix that talks > at length about why you want to do things like SPF checks at the border > rather than inside. Added the reference. > Appendix I: > > The second paragraph claims we're documenting extensions since 4408. Were > there any? Yes. Use of A-R in place of Received-SPF in some cases and the "void lookups" limit. Sorry for the delay in responding. Scott K From dhc@dcrocker.net Wed May 8 12:03:19 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCAE21F86F0 for ; Wed, 8 May 2013 12:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNvvzb5MMCA0 for ; Wed, 8 May 2013 12:03:14 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0DE21F8CE2 for ; Wed, 8 May 2013 12:03:14 -0700 (PDT) Received: from [10.2.4.150] ([64.9.249.123]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r48J33ZH012259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 May 2013 12:03:08 -0700 Message-ID: <518AA161.4060600@dcrocker.net> Date: Wed, 08 May 2013 12:02:57 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott Kitterman References: <20130409062431.GK24624@mx1.yitter.info> <1734898.5zN0vMnxl3@scott-latitude-e6320> In-Reply-To: <1734898.5zN0vMnxl3@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 08 May 2013 12:03:14 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 19:03:19 -0000 On 5/8/2013 10:14 AM, Scott Kitterman wrote: > On Tuesday, April 23, 2013 11:03:37 AM Murray S. Kucherawy wrote: >> On Mon, Apr 8, 2013 at 11:24 PM, Andrew Sullivan > wrote: >> Section 1: >> >> The last paragraph makes the claim that domain reputation is likely to be >> more accurate than IP reputation. Is it worthwhile to add a sentence or >> two explaining why this is true? > > I don't think so. First, it's speculation and I don't think enough of a case > for it can be made without being too long/distracting. Second, it's not part > of the protocol, so it not something we should worry about overmuch. Unfounded speculation in a specification has no utility other than providing opportunities for pure distraction. Good candidate for removal from the text. >> Section 2.1: >> >> I think someone else already mentioned this, but how does encouraging a >> second check decrease DNS resource use? > > I did reply to this already. It's a matter of HELO records generally being > much 'cheaper' than mail from records. I don't understand. >> Section 2.4: >> >> Isn't the fourth paragraph implicit in any standards specification? That >> is, do we really need it? > > I see your point, but I think it should actually stay. Consistency of > evaluation across multiple implementations is key to the success of the > protocol. IIRC, you said during the debate that if you were implementing SPF, > you'd ignore the macro requirements. You're, of course, free to do that, just > don't say you implemented SPF. The problem is that casting it in normative terms means that the spec is pretending it is asserting something distinctive in this context. It might make sense to caution the implementer to validate the function, but it doesn't make sense to phrase this as part of the protocol specification, any more than it makes sense to say that the MUST use a compiler that works well... >> Section 4.6.4: >> >> I imagine you're going to say that 10 is the limit imposed by most >> implementations, but shouldn't we say that there should be a finite, >> perhaps configurable limit, and operational experience has shown that 10 is >> a reasonable default? > > No. We need consistent limits because if receivers vary the limits, then > there will be inconsistent results and poor interoperability. Yeah, that's probably right. My own view is that a recursion limit of 10 is phenomenally expensive (impractical) and a much smaller number would be much better; but I assume that discussion isn't in scope... >> The "Some implementations ..." sentence seems to be malformed. I can't >> parse it. > > Better? > > Note: Historically, this document has made no provisions for how to > handle domain-specs, or macro-expansions thereof, that are > syntactically invalid per , such as names > with empty labels (e.g., "foo..example.com") or overlong labels > (more than 63 characters). Some implementations choose to treat > mechanisms associated with such expansions as no-match and > ignore modifiers with such names, others return a "permerror" > exception. The outcome for an unexpected domain-spec without macros > might even differ from that for an unexpected <target-name> > after macro expansion. Perhaps a bit simpler still: Note: Historically, this document made no provisions for the handling of syntactically invalid domain-specs or macro-expansion, per . Examples include names with empty labels, such as "foo..example.com", and labels that are longer than 63 characters. Some implementations choose to treat such errors at no-match and therefore ignore such names, while others return a "permerror" exception. {I'm lost on the last sentence because I don't know what "unexpected" means in technical terms. } >> Section 11.1: >> >> Aren't the first and third bullets describing the same attack? > > No. One's a DoS due to lots of mail being sent. The other's a DoS due to the > way malicoius SPF records are constructed. Similar, but not the same. it's worth adding text to make this clearer. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Wed May 8 13:42:43 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1677221F8F25 for ; Wed, 8 May 2013 13:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Vyd4VtJuztw for ; Wed, 8 May 2013 13:42:39 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 98E5B21F8EBF for ; Wed, 8 May 2013 13:42:37 -0700 (PDT) Received: (qmail 12261 invoked from network); 8 May 2013 20:42:36 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 8 May 2013 20:42:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=518ab8bb.xn--btvx9d.k1305; i=johnl@user.iecc.com; bh=XVN9owVEqoUocI0ccnwGNl5gFMb4bchC97uk6w5lB3s=; b=Nw1Ds80EM/fNC/GX98uW3gC5PkYEtcDAacoOdGaRlT9Pdw3Sr+uVqdBbR4nWGQwO4thWlPn9afjpD9kv1uGSYFT7QUxIu6y+Xsz9kUEGMHrBcj4vyakGne29SwMAoOAWeXPE6GgXjI/VIpKGeI8eMjh4yvcu/I7yJWR7PnECGOU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=518ab8bb.xn--btvx9d.k1305; olt=johnl@user.iecc.com; bh=XVN9owVEqoUocI0ccnwGNl5gFMb4bchC97uk6w5lB3s=; b=HeOd8xCSA3cMrwZpj2r2DYLsdKodEEiRBIPO6LoJhlYzFstbZWiKc2pCPJMOEoojOB387zhzQ/wo1vf3QAczn/Z81bZYquU50PG5fjcRyhHxn/tXFDQyEr68mngivIu6IhhvpAZPkkpuWXecrj0XUSKKrhFrp/cjA0pJIFosddU= Date: 8 May 2013 20:42:13 -0000 Message-ID: <20130508204213.31359.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <518AA161.4060600@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: dcrocker@bbiw.net Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 20:42:43 -0000 >Yeah, that's probably right. My own view is that a recursion limit of >10 is phenomenally expensive (impractical) and a much smaller number >would be much better; but I assume that discussion isn't in scope... I think you'll find that the libraries have all had a limit of 10 for quite a while, and nothing bad has happened. Also, there are definitely real SPF records with 9 or 10 indirections, typically companies that include an ESP's record that has ranges all over the place. Were we to drop the limit below 10, there would be interop problems. R's, John From spf2@kitterman.com Wed May 8 13:46:49 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F0121F8E49 for ; Wed, 8 May 2013 13:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Cj8TDqxfK+u for ; Wed, 8 May 2013 13:46:44 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D9EFE21F8E56 for ; Wed, 8 May 2013 13:46:43 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0971120E412A; Wed, 8 May 2013 16:46:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368046003; bh=VF2XWy2E/RrByXEzcnjVP6Y1Zi65q+mGnlg/F01sQD8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VeaSXXkKN+rd+sF7KT4Tjid0bSJpKaytVqTPgRHKgsWgy9j4WwnSMA5D5cC3zgNxX LA2HfTf6JyFhb81h+BbAoR33YYgo1Ryk7kK0LcJOQ5nw/tVc3+v0/y4e6zwpKEdPzN S0xIEzpZttSVjuVdb1QZfo/jlfQ7ESLp8J3flxJw= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E3F4420E40F6; Wed, 8 May 2013 16:46:42 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 08 May 2013 16:46:40 -0400 Message-ID: <2275712.VBDSrjNjif@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130508204213.31359.qmail@joyce.lan> References: <20130508204213.31359.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 20:46:49 -0000 On Wednesday, May 08, 2013 08:42:13 PM John Levine wrote: > >Yeah, that's probably right. My own view is that a recursion limit of > >10 is phenomenally expensive (impractical) and a much smaller number > >would be much better; but I assume that discussion isn't in scope... > > I think you'll find that the libraries have all had a limit of 10 for > quite a while, and nothing bad has happened. > > Also, there are definitely real SPF records with 9 or 10 indirections, > typically companies that include an ESP's record that has ranges all > over the place. Were we to drop the limit below 10, there would be > interop problems. Definitely. I'm not so far aware of a domain that couldn't express it's record within the processing limits if they made the effort to try, but there are large ADMDs with records that exceed the limits on a not infrequent basis and ahve to be reminded. Lowering limits is not a realistic option. Scott K From spf2@kitterman.com Wed May 8 14:01:16 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E3E21F8FDC for ; Wed, 8 May 2013 14:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJcMQL5DRKPZ for ; Wed, 8 May 2013 14:01:10 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BED9721F84CE for ; Wed, 8 May 2013 14:01:10 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4AE0820E412A; Wed, 8 May 2013 17:01:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368046870; bh=MO8hLrFkNqlfQIYKOdvZdagCQN4oKXXurPi5ct7pnHM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PeerciuYnjuJg7u1ETizBbwLPBDdyBbrbXz9gXROkrQ9QDSWh0Xt1ferzarzxMfxc 1gqV81oTZC1KeRFDFPbzYTHTd4idJhWIC9meqq90YYy6mXsbSmqb99qC2tqMmkGX8j RhsHBSF9mPbgnCRn41iwj8+eO4ycX5EjGa68nHFE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2BF8920E40F6; Wed, 8 May 2013 17:01:09 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 08 May 2013 17:01:09 -0400 Message-ID: <2574727.jmW99R5cLj@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <518AA161.4060600@dcrocker.net> References: <20130409062431.GK24624@mx1.yitter.info> <1734898.5zN0vMnxl3@scott-latitude-e6320> <518AA161.4060600@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 21:01:16 -0000 On Wednesday, May 08, 2013 12:02:57 PM Dave Crocker wrote: > On 5/8/2013 10:14 AM, Scott Kitterman wrote: > > On Tuesday, April 23, 2013 11:03:37 AM Murray S. Kucherawy wrote: > >> On Mon, Apr 8, 2013 at 11:24 PM, Andrew Sullivan > > > > wrote: > >> Section 1: > >> > >> The last paragraph makes the claim that domain reputation is likely to be > >> more accurate than IP reputation. Is it worthwhile to add a sentence or > >> two explaining why this is true? > > > > I don't think so. First, it's speculation and I don't think enough of a > > case for it can be made without being too long/distracting. Second, it's > > not part of the protocol, so it not something we should worry about > > overmuch. > Unfounded speculation in a specification has no utility other than > providing opportunities for pure distraction. Good candidate for > removal from the text. OK. Ditched the paragraph. > >> Section 2.1: > >> > >> I think someone else already mentioned this, but how does encouraging a > >> second check decrease DNS resource use? > > > > I did reply to this already. It's a matter of HELO records generally > > being > > much 'cheaper' than mail from records. > > I don't understand. I did give a longer answer elsewhere, but I can't find it. Typically records for HELO/EHLO require zero or one additional DNS lookups. If you can reject based on that, you save the cost of looking up the generally more complex/expensive Mail From record. As with many things, if it's cheaper in DNS lookups or not is very scenario dependent, which is why it's not stated as a hard fact. It'll be true sometimes and not others. > >> Section 2.4: > >> > >> Isn't the fourth paragraph implicit in any standards specification? That > >> is, do we really need it? > > > > I see your point, but I think it should actually stay. Consistency of > > evaluation across multiple implementations is key to the success of the > > protocol. IIRC, you said during the debate that if you were implementing > > SPF, you'd ignore the macro requirements. You're, of course, free to do > > that, just don't say you implemented SPF. > > The problem is that casting it in normative terms means that the spec is > pretending it is asserting something distinctive in this context. It > might make sense to caution the implementer to validate the function, > but it doesn't make sense to phrase this as part of the protocol > specification, any more than it makes sense to say that the MUST use a > compiler that works well... OK. I did s/MUST/has to. > >> Section 4.6.4: > >> > >> I imagine you're going to say that 10 is the limit imposed by most > >> implementations, but shouldn't we say that there should be a finite, > >> perhaps configurable limit, and operational experience has shown that 10 > >> is > >> a reasonable default? > > > > No. We need consistent limits because if receivers vary the limits, then > > there will be inconsistent results and poor interoperability. > > Yeah, that's probably right. My own view is that a recursion limit of > 10 is phenomenally expensive (impractical) and a much smaller number > would be much better; but I assume that discussion isn't in scope... See John Levine's reply and mine to him. > >> The "Some implementations ..." sentence seems to be malformed. I can't > >> parse it. > > > > Better? > > > > Note: Historically, this document has made no provisions for > > how to > > handle domain-specs, or macro-expansions thereof, that are > > syntactically invalid per , such as > > names > > with empty labels (e.g., "foo..example.com") or overlong labels > > (more than 63 characters). Some implementations choose to > > treat > > mechanisms associated with such expansions as no-match and > > ignore modifiers with such names, others return a "permerror" > > exception. The outcome for an unexpected domain-spec without > > macros > > might even differ from that for an unexpected > > <target-name> > > after macro expansion. > > Perhaps a bit simpler still: > > Note: Historically, this document made no provisions for the > handling of syntactically invalid domain-specs or macro-expansion, per > . Examples include names with empty labels, such > as "foo..example.com", and labels that are longer than 63 characters. > Some implementations choose to treat such errors at no-match and > therefore ignore such names, while others return a "permerror" exception. > > {I'm lost on the last sentence because I don't know what "unexpected" > means in technical terms. } I concluded it didn't add anything useful. I went with something close to what you provided: Note: This document and its predecessors make no provisions for defining correct handling of syntactically invalid domain-specs or macro-expansion, per . Examples include names with empty labels, such as "foo..example.com", and labels that are longer than 63 characters. Some implementations choose to treat such errors at no-match and therefore ignore such names, while others return a "permerror" exception. I considered saying, "... so senders should not create SPF records that rely on either behavior to achieve the desired result." I decided it probably wasn't needed. Let me know if anyone disagrees. > >> Section 11.1: > >> > >> Aren't the first and third bullets describing the same attack? > > > > No. One's a DoS due to lots of mail being sent. The other's a DoS due to > > the way malicoius SPF records are constructed. Similar, but not the > > same. > it's worth adding text to make this clearer. Done. Scott K From superuser@gmail.com Wed May 8 14:09:28 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F48D21F90F3 for ; Wed, 8 May 2013 14:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=1.267, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tia5LkIuN2tc for ; Wed, 8 May 2013 14:09:26 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id D119E21F90FD for ; Wed, 8 May 2013 14:09:25 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hq12so2399619wib.16 for ; Wed, 08 May 2013 14:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mlm4nokN47Le6wyAr39AOeD+I3GRPGwWT5R0YwK8X3g=; b=BoJGy3jNqeCNI4O0gVnrd+EmNhyLX+Gff4+obHJPPl0yYi8q5gbE8dEDa8W9xdxfv4 iJGGNSOUvwgk2JhQYLvYd0Dh3YTvNoeWXYfAdlGSQLWX58Psdk2s7p0ODwDZwjzJPkgK h9bwKsS0AjvLTvJqUmluloHLlTFkGKLfjLt+NLDbuiijA7K5j5iaOr3e2UBffZztRWuN FAoVCkFqFbUSemjO0P4fWK+QvfZjHTKU0AqdOBpJsKJqPz9kLNZaBzxnsv93No7baEgY gfFygkJJqd6/BZi4ToUfmyKFaM8JQ1gBHM1F3KDpBQi0Yd34gnWTHar88qTYlilZCDH5 lhZA== MIME-Version: 1.0 X-Received: by 10.180.79.69 with SMTP id h5mr24494606wix.14.1368047364998; Wed, 08 May 2013 14:09:24 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Wed, 8 May 2013 14:09:24 -0700 (PDT) In-Reply-To: <1734898.5zN0vMnxl3@scott-latitude-e6320> References: <20130409062431.GK24624@mx1.yitter.info> <1734898.5zN0vMnxl3@scott-latitude-e6320> Date: Wed, 8 May 2013 14:09:24 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d043c062e3a0fcf04dc3b59ef Cc: "spfbis@ietf.org" Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 21:09:28 -0000 --f46d043c062e3a0fcf04dc3b59ef Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 8, 2013 at 10:14 AM, Scott Kitterman wrote: > > The last paragraph makes the claim that domain reputation is likely to be > > more accurate than IP reputation. Is it worthwhile to add a sentence or > > two explaining why this is true? > > I don't think so. First, it's speculation and I don't think enough of a > case > for it can be made without being too long/distracting. Second, it's not > part > of the protocol, so it not something we should worry about overmuch. > I think a simple, brief addition would do it: This is advantageous because reputation of domain names is likely to be more accurate than reputation of host IP addresses since domains are more likely to be stable over the long term. ...or something like that. > Section 2.1: > > > > I think someone else already mentioned this, but how does encouraging a > > second check decrease DNS resource use? > > I did reply to this already. It's a matter of HELO records generally being > much 'cheaper' than mail from records. > As long as the document explains that in a sentence or two, we're good. > > Section 2.3: > > > > The second paragraph is loaded with negatives "no... neither... nor." > > Suggest: "ADMDs can publish SPF records that authorize no hosts to use > > their DNS domain names in HELO or MAIL FROM commands during SMTP > sessions." > > I added that, because it's a good point, but it doesn't replace the > existing > text which attempts to (without being too pointed about receiver policy) > say > that if you want receivers to be able to reject mail that didn't come from > authorized hosts, you need a -all record. Some senders care about > supporting > these negative assertions, others don't. > My comment wasn't so much to correct the text, but to point out that the sentence is hard to read with so many negatives. Doesn't the sentence I proposed say the same thing? > Section 2.4: > > > > Isn't the fourth paragraph implicit in any standards specification? That > > is, do we really need it? > > I see your point, but I think it should actually stay. Consistency of > evaluation across multiple implementations is key to the success of the > protocol. IIRC, you said during the debate that if you were implementing > SPF, > you'd ignore the macro requirements. You're, of course, free to do that, > just > don't say you implemented SPF. > I would agree with all of that except the need to say it in a Proposed Standard. Any other opinions? > > Section 2.6.7: > > > > Does "permerror" also result when permanent DNS errors occur? > > Tell me how to figure out when a DNS error is permanent and then maybe. > Given > what's described in 4.4 Record Lookup, I think only extended SERVFAIL (if > the > receiver has implemented the temperror -> permerror promotion option) can > currently get a permerror. > RCODEs 1, 3, 4, and 5 all look permanent to me as defined in RFC1035, in that a retry is unlikely to yield a different result absent an operator changing some configuration or zone data. 0 is "no error" and 2 is "server failure"; the latter is obviously permanent (but desirable), leaving 2 for the case where a timeout or some other transient thing occurred. > > Why 20 seconds for the overall run time? > > This is carried forward from RFC 4408. It was moved from section 10.1 to > 4.6.4 as part of issue #6, but the value is unchanged. I'm not aware of > any > issues with what's defined in 4408. > I don't have an issue with 20 specifically. I'm just anticipating the "Why 20?" question from someone else. > > > The "Some implementations ..." sentence seems to be malformed. I can't > > parse it. > > Better? > > Note: Historically, this document has made no provisions for how > to > handle domain-specs, or macro-expansions thereof, that are > syntactically invalid per , such as names > with empty labels (e.g., "foo..example.com") or overlong labels > (more than 63 characters). Some implementations choose to treat > mechanisms associated with such expansions as no-match and > ignore modifiers with such names, others return a "permerror" > exception. The outcome for an unexpected domain-spec without > macros > might even differ from that for an unexpected <target-name> > after macro expansion. > Now that I see what it's trying to say, this is fine. Dave's suggestion is fine as well, I think. > > The second-last paragraph is weirdly wrapped. Is the XML ok there? > > I think I fixed that already based on John Levine's comments. Please > double > check the new draft. > Will do when it comes out. > > Section 5.6: > > > > For IPv4, shouldn't the CIDR be 1*2DIGIT? For IPv6, shouldn't the CIDR > be > > 1*3DIGIT? > > I don't know. It's unchanged from RFC 4408 right now, but I'd like other > opinions on changes here (ABNF makes my head hurt). > It's probably not harmful to leave it, really. It's just an observation that 1*DIGIT allows 000000024 (which is probably fine) but also allows 1048576 (which probably isn't). 1*2DIGIT would limit it to 00-99 at least. You could also cover this in prose by saying 1*DIGIT and then in either an ABNF comment ("; blahblah") or in text nearby say that it has to evaluate to an integer from 0 to 32 for v4 and 0 to 128 for v6. > Section 6.2: > > > > It just occurred to me that in the earlier sections (2 or 4, in > > particular), it's clear that check_host() returns one of the enumerated > > result, but it's never made explicit that it also outputs an explanation > > string. We might want to mention this earlier than we do now so it's > not a > > surprise later. > > It's an optional and somewhat rare output of the protocol, so I think not, > but > did you have something specific in mind? > I'm thinking about what we did with DKIM, where we made it very clear that DKIM's primary output is a pass/fail/etc. and the "d=". Anything that outputs something beyond that is an extension outside the scope of the specification. Then again, the premise for doing that was protracted debate about "i=" vs. "d=" (Dave still has the buttons), but that's a different issue. Maybe we don't need to go down this path with SPF if it's not needed, but during my review that memory came up, and I thought it might be useful to consider it. > > ABNF rules say literal strings in productions are case-insensitive. That > > means the macro-letter set actually implicitly includes all of the > capital > > letter equivalents. If we want to constrain it to lowercase only, we > need > > to use hex notation. > > OK. If someone would provide those, it would be great. Otherwise, I'll > take > a shot at it, probably Friday. > The "ascii" man page on your favourite UNIX distribution has them. You're looking for something like: macro-letter = %x73 / %x6c / ... > Section 9.1: > > > > Same point about the case-insensitivity of ABNF here. > > Except for "Received-SPF" is there anything case insensitive there? I'd > greatly appreciate text for this too. > I don't think "From" needs to start with a capital "F" for it to be the one RFC5322 talks about. More generally, I don't think header field names are case-sensitive. Thus, "Received-SPF" is fine as-is. The rest of it is probably also fine, unless for some reason it has to be "pass" and must never be "PASS" or "pAsS", etc. > The "SPF verifiers MUST make sure..." doesn't seem actionable to me. Do > we > > really expect Received-SPF generators to be able to identify and exclude > > malicious data? > > I think you have to. I've seen people put html pointing to malicious web > sites in SPF records. Thanks to someone privately pointing this class of > attack out to me, my SPF validator now properly escapes anything that's > retrieved from DNS. > It's the "malicious data" part that concerns me because what constitutes an effective data attack is very context-sensitive. > > Section 10.2: > > > > Missing close parenthesis in the first paragraph. > > I don't see it. I may have fixed it already. Please double check. > Will do, when it's out. > > Section 11.3: > > > > Clobbering the DNS at a receiver could also result in delivery of > malicious > > mail if the receiver is configured to pass on "tempfail" and just add a > > header field. > > Good point. I added a sentence on to bullet two in 11.1. It seemed to fit > there. Please let me know what you thing. > Will do, when it's out. -MSK --f46d043c062e3a0fcf04dc3b59ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 8, 2013 at 10:14 AM, Scott Kitterman <spf2@k= itterman.com> wrote:
> Th= e last paragraph makes the claim that domain reputation is likely to be
> more accurate than IP reputation. =A0Is it worthwhile to add a sentenc= e or
> two explaining why this is true?

I don't think so. =A0First, it's speculation and I don't = think enough of a case
for it can be made without being too long/distracting. =A0Second, it's = not part
of the protocol, so it not something we should worry about overmuch.

I think a simple, brief addition would do it:= 

This is advantageous because reputation of domain n=
ames is likely to
   be more accurate than reputation of host IP addresses since domains are =
more likely to be stable over the long term.
=A0...or something like t= hat.

> Section 2.1:
>
> I think someone else already mentioned this, but how does encouraging = a
> second check decrease DNS resource use?

I did reply to this already. =A0It's a matter of HELO records gen= erally being
much 'cheaper' than mail from records.

As long as the document explains that in a sentence or two, we'= re good.
=A0
> Section 2.3:
>
> The second paragraph is loaded with negatives "no... neither... n= or."
> Suggest: "ADMDs can publish SPF records that authorize no hosts t= o use
> their DNS domain names in HELO or MAIL FROM commands during SMTP sessi= ons."

I added that, because it's a good point, but it doesn't repla= ce the existing
text which attempts to (without being too pointed about receiver policy) sa= y
that if you want receivers to be able to reject mail that didn't come f= rom
authorized hosts, you need a -all record. =A0Some senders care about suppor= ting
these negative assertions, others don't.

My comment wasn't so much to correct the text, but to point out t= hat the sentence is hard to read with so many negatives.

Doesn't the sentence I proposed say the same thing?
=
> Section 2.4:
>
> Isn't the fourth paragraph implicit in any standards specification= ? =A0That
> is, do we really need it?

I see your point, but I think it should actually stay. =A0Consistency= of
evaluation across multiple implementations is key to the success of the
protocol. =A0IIRC, you said during the debate that if you were implementing= SPF,
you'd ignore the macro requirements. =A0You're, of course, free to = do that, just
don't say you implemented SPF.

I wo= uld agree with all of that except the need to say it in a Proposed Standard= .=A0 Any other opinions?
=A0
> Section 2.6.7:
>
> Does "permerror" also result when permanent DNS errors occur= ?

Tell me how to figure out when a DNS error is permanent and then mayb= e. =A0Given
what's described in 4.4 Record Lookup, I think only extended SERVFAIL (= if the
receiver has implemented the temperror -> permerror promotion option) ca= n
currently get a permerror.

RCODEs 1, 3,= 4, and 5 all look permanent to me as defined in RFC1035, in that a retry i= s unlikely to yield a different result absent an operator changing some con= figuration or zone data.=A0 0 is "no error" and 2 is "server= failure"; the latter is obviously permanent (but desirable), leaving = 2 for the case where a timeout or some other transient thing occurred.
=A0
> = Why 20 seconds for the overall run time?

This is carried forward from RFC 4408. =A0It was moved from section 1= 0.1 to
4.6.4 as part of issue #6, but the value is unchanged. =A0I'm not aware= of any
issues with what's defined in 4408.

I don't have an issue with 20 specifically.=A0 I'm just anticipati= ng the "Why 20?" question from someone else.
=A0

> The "Some implementations ..." sentence seems to be malforme= d. =A0I can't
> parse it.

Better?

=A0 =A0 =A0 =A0 =A0 Note: Historically, this document has made no provision= s for how to
=A0 =A0 =A0 =A0 =A0 handle domain-specs, or macro-expansions thereof, that = are
=A0 =A0 =A0 =A0 =A0 syntactically invalid per <xref target=3D"RFC10= 35"/>, such as names
=A0 =A0 =A0 =A0 =A0 with empty labels (e.g., "foo..example.com") or overlong labels
=A0 =A0 =A0 =A0 =A0 (more than 63 characters). =A0Some implementations choo= se to treat
=A0 =A0 =A0 =A0 =A0 mechanisms associated with such expansions as no-match = and
=A0 =A0 =A0 =A0 =A0 ignore modifiers with such names, others return a "= ;permerror"
=A0 =A0 =A0 =A0 =A0 exception. The outcome for an unexpected domain-spec wi= thout macros
=A0 =A0 =A0 =A0 =A0 might even differ from that for an unexpected &lt;t= arget-name&gt;
=A0 =A0 =A0 =A0 =A0 after macro expansion.

<= div>Now that I see what it's trying to say, this is fine.=A0 Dave's= suggestion is fine as well, I think.
=A0
> The second-last paragraph is weirdly wrapped. =A0Is = the XML ok there?

I think I fixed that already based on John Levine's comments. =A0= Please double
check the new draft.

Will do when it co= mes out.
=A0
= > Section 5.6:
>
> For IPv4, shouldn't the CIDR be 1*2DIGIT? =A0For IPv6, shouldn'= ;t the CIDR be
> 1*3DIGIT?

I don't know. =A0It's unchanged from RFC 4408 right now, but = I'd like other
opinions on changes here (ABNF makes my head hurt).
It's probably not harmful to leave it, really.=A0 It's= just an observation that 1*DIGIT allows 000000024 (which is probably fine)= but also allows 1048576 (which probably isn't).=A0 1*2DIGIT would limi= t it to 00-99 at least.

You could also cover this in prose by saying 1*DIGIT and the= n in either an ABNF comment ("; blahblah") or in text nearby say = that it has to evaluate to an integer from 0 to 32 for v4 and 0 to 128 for = v6.

> Section 6.2:
>
> It just occurred to me that in the earlier sections (2 or 4, in
> particular), it's clear that check_host() returns one of the enume= rated
> result, but it's never made explicit that it also outputs an expla= nation
> string. =A0We might want to mention this earlier than we do now so it&= #39;s not a
> surprise later.

It's an optional and somewhat rare output of the protocol, so I t= hink not, but
did you have something specific in mind?

I'm thinking about what we did with DKIM, where we made it very clear= that DKIM's primary output is a pass/fail/etc. and the "d=3D"= ;.=A0 Anything that outputs something beyond that is an extension outside t= he scope of the specification.=A0 Then again, the premise for doing that wa= s protracted debate about "i=3D" vs. "d=3D" (Dave still= has the buttons), but that's a different issue.

Maybe we don't need to go down this path with SPF if it&= #39;s not needed, but during my review that memory came up, and I thought i= t might be useful to consider it.

=A0
> ABNF rules say literal strings in productions are case-insensitive. = =A0That
> means the macro-letter set actually implicitly includes all of the cap= ital
> letter equivalents. =A0If we want to constrain it to lowercase only, w= e need
> to use hex notation.

OK. =A0If someone would provide those, it would be great. =A0Otherwis= e, I'll take
a shot at it, probably Friday.

The &quo= t;ascii" man page on your favourite UNIX distribution has them.=A0 You= 're looking for something like:

   macro-letter =
    =3D  %x73 / %x6c / ...
> Section 9.1:
>
> Same point about the case-insensitivity of ABNF here.

Except for "Received-SPF" is there anything case insensitiv= e there? =A0I'd
greatly appreciate text for this too.

I don&= #39;t think "From" needs to start with a capital "F" fo= r it to be the one RFC5322 talks about.=A0 More generally, I don't thin= k header field names are case-sensitive.=A0 Thus, "Received-SPF" = is fine as-is.

The rest of it is probably also fine, = unless for some reason it has to be "pass" and must never be &quo= t;PASS" or "pAsS", etc.

> The "SPF verifiers MUST make sure..." doesn't seem actio= nable to me. =A0Do we
> really expect Received-SPF generators to be able to identify and exclu= de
> malicious data?

I think you have to. =A0I've seen people put html pointing to mal= icious web
sites in SPF records. =A0Thanks to someone privately pointing this class of=
attack out to me, my SPF validator now properly escapes anything that's=
retrieved from DNS.

It's the "= malicious data" part that concerns me because what constitutes an effe= ctive data attack is very context-sensitive.
=A0
> Section 10.2:
>
> Missing close parenthesis in the first paragraph.

I don't see it. =A0I may have fixed it already. =A0Please double = check.

Will do, when it's out.
= =A0
> Section 11.3:
>
> Clobbering the DNS at a receiver could also result in delivery of mali= cious
> mail if the receiver is configured to pass on "tempfail" and= just add a
> header field.

Good point. =A0I added a sentence on to bullet two in 11.1. =A0It see= med to fit
there. =A0Please let me know what you thing.

Will do, when it's out.
=A0
-MSK
--f46d043c062e3a0fcf04dc3b59ef-- From vesely@tana.it Thu May 9 08:31:28 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC3521F84F5 for ; Thu, 9 May 2013 08:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.719 X-Spam-Level: X-Spam-Status: No, score=-5.719 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRrdLrv32Rsx for ; Thu, 9 May 2013 08:31:23 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 80B4521F8F4D for ; Thu, 9 May 2013 08:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1368113478; bh=WF6P5p4m71TVVKz2eH/4raO7beq1Yk4woQac3NLFask=; l=1052; h=Date:From:To:References:In-Reply-To; b=WdIkSEiVnK8cB5iFfNc2I1oUEH/CWXYhCfzOZJPe1l9XxN/hWMoL4TaXjk4gh/Ylh oghl0ea+YQoRLOfS31KCSqJXN30Xqi2AQNUTr/zdCxh+S8TIGFNSUkuTbAXF/x5L2V +Sd6RKBjAq0Sg9/XR3VQyQN3GElxRJ16oilfV2Fc= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Thu, 09 May 2013 17:31:17 +0200 id 00000000005DC039.00000000518BC145.00007DEA Message-ID: <518BC146.6060103@tana.it> Date: Thu, 09 May 2013 17:31:18 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130409062431.GK24624@mx1.yitter.info> <1734898.5zN0vMnxl3@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 15:31:28 -0000 On Wed 08/May/2013 23:09:24 +0200 Murray S. Kucherawy wrote: > On Wed, May 8, 2013 at 10:14 AM, Scott Kitterman wrote: >>> ABNF rules say literal strings in productions are >>> case-insensitive. That means the macro-letter set actually >>> implicitly includes all of the capital letter equivalents. If >>> we want to constrain it to lowercase only, we need to use hex >>> notation. >> >> OK. If someone would provide those, it would be great. Otherwise, I'll >> take a shot at it, probably Friday. > > The "ascii" man page on your favourite UNIX distribution has them. You're > looking for something like: > > macro-letter = %x73 / %x6c / ... No, wait. Do we really want that? The syntax of URL escaped expansions is the same as that of lowercase macros. We don't need two parallel sets of production rules, do we? IMHO, adding a comment, e.g. as follows, such suffice. macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / "c" / "r" / "t" / "v" ; uppercase or lowercase, see URL escaping below From superuser@gmail.com Thu May 9 10:55:28 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C49E21F9354 for ; Thu, 9 May 2013 10:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dgw2qO3ZDsBu for ; Thu, 9 May 2013 10:55:27 -0700 (PDT) Received: from mail-da0-x22b.google.com (mail-da0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8D07321F9347 for ; Thu, 9 May 2013 10:55:27 -0700 (PDT) Received: by mail-da0-f43.google.com with SMTP id u7so1735860dae.30 for ; Thu, 09 May 2013 10:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0W/53ShGdf+4ItQav60qTZloNcNxfHKshWehHl6wQIg=; b=qrw71PbIFleeY5QOa08EMtbVsmBepXXddECTMOJqGDzXhgc98elFhLVod1WDFaGrEf jMK3atf9HzmCHKq40vAiJYTLU7KsKLvdN+za9DPMwiOM4NwQz+rvBIDCZmSe+ZLOPBQA PyvwYcwCp3MV7b1aH5L51VBt+huw+MB78S8/MBhEYivWeMQv0gg+zTbtXGQVwLa0fP3X b77fHT2OS/ktdp8uiFWCexKUsewu2a7OubTTC6QHyoSEYkVsw8sVvWzOuG5AjX0SzXK2 TUKJZZrOZFwsGV+MS7eCSb+jUdrinSEa0fXvLMOkqyIUstqUyxpSWw7cH2XhCFGqyR4Q USYw== MIME-Version: 1.0 X-Received: by 10.68.223.10 with SMTP id qq10mr13639727pbc.57.1368122127238; Thu, 09 May 2013 10:55:27 -0700 (PDT) Received: by 10.66.234.40 with HTTP; Thu, 9 May 2013 10:55:26 -0700 (PDT) In-Reply-To: <518BC146.6060103@tana.it> References: <20130409062431.GK24624@mx1.yitter.info> <1734898.5zN0vMnxl3@scott-latitude-e6320> <518BC146.6060103@tana.it> Date: Thu, 9 May 2013 10:55:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=047d7b2e09df674ad404dc4cc1b5 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 17:55:28 -0000 --047d7b2e09df674ad404dc4cc1b5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 9, 2013 at 8:31 AM, Alessandro Vesely wrote: > > macro-letter = %x73 / %x6c / ... > > No, wait. Do we really want that? > We do if current implementations generally do only lowercase macro support. If they're case-insensitive, then what's there is fine. It's my impression that %{S} isn't valid to most implementations. If I'm wrong about that, then I withdraw the suggestion. > The syntax of URL escaped expansions is the same as that of lowercase > macros. We don't need two parallel sets of production rules, do we? > > IMHO, adding a comment, e.g. as follows, such suffice. > > macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / > "c" / "r" / "t" / "v" > ; uppercase or lowercase, see URL escaping below > "uppercase or lowercase" is implicit in ABNF. That's the point of my suggestion. -MSK --047d7b2e09df674ad404dc4cc1b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 9, 2013 at 8:31 AM, Alessandro Vesely <vesely@ta= na.it> wrote:
> =A0 =A0macro-letter =A0 =A0 =3D =A0%x73= / %x6c / ...

No, wait. =A0Do we really want that?

We do i= f current implementations generally do only lowercase macro support.=A0 If = they're case-insensitive, then what's there is fine.=A0 It's my= impression that %{S} isn't valid to most implementations.=A0 If I'= m wrong about that, then I withdraw the suggestion.
=A0
The syntax of URL escaped expansions is the same as that of lowercase
macros. =A0We don't need two parallel sets of production rules, do we?<= br>
IMHO, adding a comment, e.g. as follows, such suffice.

=A0 macro-letter =A0 =A0 =3D "s" / "l" / "o" = / "d" / "i" / "p" / "h" /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "c" / "r" /= "t" / "v"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0; uppercase or lowercase, see UR= L escaping below

=A0"uppercase or = lowercase" is implicit in ABNF.=A0 That's the point of my suggesti= on.

-MSK
--047d7b2e09df674ad404dc4cc1b5-- From vesely@tana.it Fri May 10 02:54:16 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C17621F8B64 for ; Fri, 10 May 2013 02:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.052 X-Spam-Level: X-Spam-Status: No, score=-6.052 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEjv4iGTp-Yv for ; Fri, 10 May 2013 02:54:11 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A640621F859D for ; Fri, 10 May 2013 02:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1368179644; bh=nlSr3/l4elCUmBilrzixza0rB73nhBPwKT+l+oYIoRw=; l=2306; h=Date:From:To:References:In-Reply-To; b=brgKtclo9f1NmATBDkfgc4023FSLoCrVZe5c26qZ8yt3KQrVahYP4cz4J4Dulov/Y JnxvYgNZnzBnEyBCh0vwYgZlfgy9syfQZLiTFJnjpvQ1pro2+pBIE/PU8T7qfEnj6+ JIQuGyKiVCF2MBl7+gjV6YQY4qK9v5ZWja3p9i2A= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Fri, 10 May 2013 11:54:04 +0200 id 00000000005DC035.00000000518CC3BC.00007721 Message-ID: <518CC3BC.3090602@tana.it> Date: Fri, 10 May 2013 11:54:04 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130409062431.GK24624@mx1.yitter.info> <1734898.5zN0vMnxl3@scott-latitude-e6320> <518BC146.6060103@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 09:54:16 -0000 On Thu 09/May/2013 19:55:26 +0200 Murray S. Kucherawy wrote: > On Thu, May 9, 2013 at 8:31 AM, Alessandro Vesely wrote: > >>> macro-letter = %x73 / %x6c / ... >> >> No, wait. Do we really want that? > > We do if current implementations generally do only lowercase macro > support. If they're case-insensitive, then what's there is fine. It's my > impression that %{S} isn't valid to most implementations. If I'm wrong > about that, then I withdraw the suggestion. I agree the case (in)sensitivity can easily get overlooked. Yet, the syntax is the same. Currently, the paragraph that specifies URL escaping makes no reference to any grammar rule, but we could rewrite it as: MACRO-EXPAND macros with an uppercase MACRO-LETTER expand exactly as their lowercased equivalents, and are then URL escaped. URL escaping MUST be performed for characters not in the "unreserved" set, which is defined in [RFC3986]. I don't think that would make it any clearer. Anyway, if we still wanted to rewrite it that way, we could do so without having to define MACRO-LETTER and MACRO-EXPAND, since rule names are case insensitive as well [1]. >> The syntax of URL escaped expansions is the same as that of lowercase >> macros. We don't need two parallel sets of production rules, do we? >> >> IMHO, adding a comment, e.g. as follows, such suffice. >> >> macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / >> "c" / "r" / "t" / "v" >> ; uppercase or lowercase, see URL escaping below > > "uppercase or lowercase" is implicit in ABNF. That's the point of my > suggestion. Yup, the comment turns implicit into explicit. IOW, the grammar is correct but readers overlook it. Hence it's the accompanying text, not the grammar, that we need to amend. I think the reason why that paragraph is overlooked is because it is too far down in the section, not because it misses grammar references. The second part of the comment is an attempt to draw the reader's attention there. -- [1] For example, the rule has uppercase A / MX / PTR / IP4 / IP6, while those terms' definitions are lowercase in the subsections of Section 5 where they are introduced --a change committed on August 16, 2012 (-04), a period we were lowercasing various stuff. From superuser@gmail.com Fri May 10 09:37:13 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F0221F8D00 for ; Fri, 10 May 2013 09:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a6fc-m7U0eD for ; Fri, 10 May 2013 09:37:13 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id AFFAD21F8CEC for ; Fri, 10 May 2013 09:37:12 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id t59so4082138wes.38 for ; Fri, 10 May 2013 09:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MzWzX0bn23OskJid9/MmvrgMFFUhJdwZA9SkMYLuXXA=; b=tABqVWBZW8WVNYcwJsLlqneGRGK4z4i99BpBW7cLOyW82xXm6qqhny2a9quHixxwGb V08WfM4WDKXZ5TUu9WbVQmHOEqHoC9RDmk120jxonlMgm11SsBMtjlwe41aRA4tfRyl3 /4lFXt4YHnYIYeAmIWTolLbgPEwP0PTtIv86pT9oPlKdAvRUotOVcBoFjAOS9esfCayY EUofsmwvRVMdA90ljozA2XyMfdh0o3Eb/nZbnMm/kn6TNfnhyqZtbQo0q6p3ETu9P7R3 Ae2r60YQMoKxOg2xnuFroc/Z3x5UPOYeVW+B/e83De8wux/gcrhBwmjBb7Adfn2qMG6F gybw== MIME-Version: 1.0 X-Received: by 10.194.179.169 with SMTP id dh9mr19622439wjc.15.1368203830132; Fri, 10 May 2013 09:37:10 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Fri, 10 May 2013 09:37:09 -0700 (PDT) In-Reply-To: <518CC3BC.3090602@tana.it> References: <20130409062431.GK24624@mx1.yitter.info> <1734898.5zN0vMnxl3@scott-latitude-e6320> <518BC146.6060103@tana.it> <518CC3BC.3090602@tana.it> Date: Fri, 10 May 2013 09:37:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=089e01419f4a4685c004dc5fc749 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 16:37:13 -0000 --089e01419f4a4685c004dc5fc749 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 10, 2013 at 2:54 AM, Alessandro Vesely wrote: > On Thu 09/May/2013 19:55:26 +0200 Murray S. Kucherawy wrote: > > On Thu, May 9, 2013 at 8:31 AM, Alessandro Vesely > wrote: > > > >>> macro-letter = %x73 / %x6c / ... > >> > >> No, wait. Do we really want that? > > > > We do if current implementations generally do only lowercase macro > > support. If they're case-insensitive, then what's there is fine. It's > my > > impression that %{S} isn't valid to most implementations. If I'm wrong > > about that, then I withdraw the suggestion. > > I agree the case (in)sensitivity can easily get overlooked. Yet, the > syntax is the same. Currently, the paragraph that specifies URL > escaping makes no reference to any grammar rule, but we could rewrite > it as: > > [...] Whoops, I completely missed the thing about uppercase macros are URL escaped. I withdraw the suggestion. -MSK --089e01419f4a4685c004dc5fc749 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 10, 2013 at 2:54 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
On Thu 09/May/2013 19:55:2= 6 +0200 Murray S. Kucherawy wrote:
> On Thu, May 9, 2013 at 8:31 AM, Alessandro Vesely <vesely@tana.it> wrote:
>
>>> =A0 =A0macro-letter =A0 =A0 =3D =A0%x73 / %x6c / ...
>>
>> No, wait. =A0Do we really want that?
>
> We do if current implementations generally do only lowercase macro
> support. =A0If they're case-insensitive, then what's there is = fine. =A0It's my
> impression that %{S} isn't valid to most implementations. =A0If I&= #39;m wrong
> about that, then I withdraw the suggestion.

I agree the case (in)sensitivity can easily get overlooked. =A0Yet, t= he
syntax is the same. =A0Currently, the paragraph that specifies URL
escaping makes no reference to any grammar rule, but we could rewrite
it as:
=A0
[...]

Whoops, I completely missed th= e thing about uppercase macros are URL escaped.=A0 I withdraw the suggestio= n.

-MSK

--089e01419f4a4685c004dc5fc749-- From spf2@kitterman.com Fri May 10 09:54:25 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713C321F8E5B for ; Fri, 10 May 2013 09:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.361 X-Spam-Level: X-Spam-Status: No, score=-3.361 tagged_above=-999 required=5 tests=[AWL=1.238, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avdYVNIJ55pG for ; Fri, 10 May 2013 09:54:20 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4967921F8B64 for ; Fri, 10 May 2013 09:54:20 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4EC1B20E40FC; Fri, 10 May 2013 12:54:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368204859; bh=QQfx1do6GzlHJjfXQCf6U93ctF9cmhYXmAooCk4aEpY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=P/U8JQyRpYJKLbR8FAIwf4ekk+9SGM5PWeLbEabiJW/F4Q/RyDOonpynmJ5KH/V53 d2U1noDhs0qB33gSMk5V3gezh9MWCa9yNVNg6E8l4BYoVn3c4P+J5K3ejD2jrOBcmr N42Twi1/zOPddej0dRiioXcDA06jfnTE1vIEJHU8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 37FA420E40C2; Fri, 10 May 2013 12:54:18 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 10 May 2013 12:54:18 -0400 Message-ID: <3835527.VgQNxOy8dD@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <20130409062431.GK24624@mx1.yitter.info> <518CC3BC.3090602@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 16:54:25 -0000 On Friday, May 10, 2013 09:37:09 AM Murray S. Kucherawy wrote: > On Fri, May 10, 2013 at 2:54 AM, Alessandro Vesely wrote: > > On Thu 09/May/2013 19:55:26 +0200 Murray S. Kucherawy wrote: > > > On Thu, May 9, 2013 at 8:31 AM, Alessandro Vesely > > > > wrote: > > >>> macro-letter = %x73 / %x6c / ... > > >> > > >> No, wait. Do we really want that? > > > > > > We do if current implementations generally do only lowercase macro > > > support. If they're case-insensitive, then what's there is fine. It's > > > > my > > > > > impression that %{S} isn't valid to most implementations. If I'm wrong > > > about that, then I withdraw the suggestion. > > > > I agree the case (in)sensitivity can easily get overlooked. Yet, the > > syntax is the same. Currently, the paragraph that specifies URL > > escaping makes no reference to any grammar rule, but we could rewrite > > it as: > > > > [...] > > Whoops, I completely missed the thing about uppercase macros are URL > escaped. I withdraw the suggestion. Excellent. Sometimes procrastination pays ... Scott K From sm@elandsys.com Mon May 13 21:37:32 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6857011E80F3 for ; Mon, 13 May 2013 21:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qfttWgXe4qa for ; Mon, 13 May 2013 21:37:31 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EA311E80EF for ; Mon, 13 May 2013 21:37:31 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.157.33]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4E4bFX9015059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 May 2013 21:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1368506248; bh=mruYad1lKCI+PPM+tkqQKoC03eQAc1+knEOQvdtT6p0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=eESOSPbodu4TekBYSP1PhSgYtxxDzkhhs3Pv5AbfG542+2aPqFr1sqjAX+7Zi8Kv+ 48rgg2/XiVu6GwDUd0SGMT40J7ctAt1LhuywLkZ2WMTTM9PEtX+Voh3lso8+fhC01I HaI3XfXerOjv5wegjAgpZ3BbKxMiWWveA1m3OzNs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1368506248; i=@elandsys.com; bh=mruYad1lKCI+PPM+tkqQKoC03eQAc1+knEOQvdtT6p0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=gAZRJYBB92/LgSxkNtYAbCh/Yczo7TEQUnTjZH/Ji636Iw1aqD4aXidW7cvr4KALO 4FRMMwAumsRw1+OhGD9aaPBuf2OOEubyRC3073EJtWk5Y43juaBponRRYK4/aT1l5K EBY9xTgxWMJuATbICXwO6PdbiRYIGbRtVdoOfF3M= Message-Id: <6.2.5.6.2.20130513213220.0b8c3c10@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 13 May 2013 21:36:36 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <6.2.5.6.2.20130430111045.0a7ebc30@elandnews.com> <3198772.42M6YQxPyW@scott-latitude-e6320> <6.2.5.6.2.20130430172422.0d6ca9c8@resistor.net> <7d677814-3b49-4a87-bfe3-d36c6f14378e@email.android.com> <6.2.5.6.2.20130430214208.0be80a90@elandnews.com> <6.2.5.6.2.20130505232307.0b7de158@elandnews.com> <6.2.5.6.2.20130507222249.0b9d69f0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Addressing reviews (was: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 04:37:32 -0000 Hi Scott, Can you provide an estimate date of when the reviews and comments received during the WGLC will be addressed? Regards, S. Moonesamy (as document shepherd) From spf2@kitterman.com Mon May 13 22:21:58 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F08321F8ADF for ; Mon, 13 May 2013 22:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMxO1CCDr7XA for ; Mon, 13 May 2013 22:21:53 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5A62F21F8AD8 for ; Mon, 13 May 2013 22:21:53 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 99ECA20E40F9; Tue, 14 May 2013 01:21:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368508912; bh=I63p73GQ3dLOHgK9bxfQ++6f//HfVRzVw9wgtKLUzr8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BCUn51UaM7n5inWtKjkvgpGt7rMWDFS+b/HcoJrrIKsP0T21ROmMux0QHO4HQBNlW O7C+TaENottAi2/BfYmZOOt+CE4pCnlUEvXD273mSEoovysIQL11rIXYFuR3zRxsnK qHA/n3O0Gwu5zzUROr4EIM/xN04DTq7XFCWM/ZxQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7EC0C20E40BE; Tue, 14 May 2013 01:21:52 -0400 (EDT) From: Scott Kitterman To: S Moonesamy Date: Tue, 14 May 2013 01:21:51 -0400 Message-ID: <4504827.dqlBOFqUut@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130513213220.0b8c3c10@elandnews.com> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <6.2.5.6.2.20130513213220.0b8c3c10@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: spfbis@ietf.org Subject: Re: [spfbis] Addressing reviews (was: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 05:21:58 -0000 On Monday, May 13, 2013 09:36:36 PM S Moonesamy wrote: > Hi Scott, > > Can you provide an estimate date of when the reviews and comments > received during the WGLC will be addressed? > > Regards, > S. Moonesamy (as document shepherd) Probably Thursday. Scott K From spf2@kitterman.com Thu May 16 14:45:43 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343D221F8EAF for ; Thu, 16 May 2013 14:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAdzLZ8NpSQs for ; Thu, 16 May 2013 14:45:38 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 909F021F8EAE for ; Thu, 16 May 2013 14:45:37 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 808E220E411A; Thu, 16 May 2013 17:45:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368740736; bh=vNUDXldIuDg+BiLwq+F9+jwd/deQVjY2OIy1wNaKdeE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Gv2a1HPHrQgfxUiRey94S9K6heWf4JLVzm6R94PvldEH5qN7K+wZvy+D8msaz0NWF KS/BT9WSfaOUmxulMGUuVbdYXkWdCBqH4e96kSWnCvB/dwtMZrBodYYB3hl0aDQ/a7 aOkhGHom5Rq2v2Ro1HhEF0Q8NXT7qk6k0HflAsM0= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5A08320E40C6; Thu, 16 May 2013 17:45:35 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 16 May 2013 17:45:35 -0400 Message-ID: <2724237.eQuNQK5KLA@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 21:45:43 -0000 On Tuesday, April 23, 2013 04:08:39 PM S Moonesamy wrote: > Hello, > > Here's my review as Document Shepherd. draft-ietf-spfbis-4408bis is > nearly ready for publication as a Proposed Standard. I took into > consideration the restrictions in the SPFBIS Charter and the > controversial working group discussions in making this assessment. > > In the Abstract: > > "This document describes version 1 of the Sender Policy Framework > (SPF) protocol, whereby an ADMD can explicitly authorize the hosts > that are allowed to use its domain names, and a receiving host can > check such authorization." > > ADMD should be expanded in the above. This was pointed out in a > review posted on August 26, 2012 [1]. Fixed. > In Section 2.1: > > 'It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" > identity, but also separately check the "HELO" identity by applying > the check_host() function (Section 4) to the "HELO" identity as the > .' > > As a note this "RECOMMENDED" is also in RFC 4408. > > 'Note that requirements for the domain presented in the EHLO or HELO > command are not always clear to the sending party, and SPF verifiers > MUST be prepared for the "HELO" identity to be malformed or an IP > address literal.' > > This RFC 2119 "MUST" is not in RFC 4408. It is a substantive change > in my opinion. Fixed. > "This SPF check can only be performed when the "HELO" string is a > valid fully qualified domain." > > What is a valid fully qualified domain? Would s/domain/domain name/ clear it up for you? > In Section 2.2: > > 'SPF verifiers MUST check the ""MAIL FROM" identity if a completed > "HELO" check has not reached a definitive policy result by applying > the check_host() function to the "MAIL FROM" identity as the > .' > > As a note this RFC 2119 MUST is already in RFC 4408. > > In Section 2.3: > > "An SPF-compliant domain MUST have valid SPF records as described in > Section 3." > > As a note the RFC 4408 text is: > > "An SPF-compliant domain MUST publish a valid SPF record as described > in Section 3." > > The RFC 2119 MUST is redundant. Is there a reason to change it? > 'If domain owners choose to publish SPF records and want to support > receivers making negative authorization determinations, then they MUST > publish records that end in "-all", or redirect to other records that > do, otherwise, no definitive determination of authorization can be made.' > > The document uses ADMD while there is "domain owners" in the > above. I suggest reviewing that. Changed > The RFC 2119 MUST is a substantive change. Why is this a MUST? Because it's the literal truth. That's what you have to do to achieve that result. You won't interoperate with receivers in that way effectively if you don't. > In Section 2.4: > > 'At least the "MAIL FROM" identity MUST be checked, but it > is RECOMMENDED that the "HELO" identity also be checked beforehand.' > > There is already a RFC 2119 MUST in Section 2.2. There is also a RFC > 2119 RECOMMENDED in Section 2.1. The above text restates existing > RFC 2119 requirements or recommendations. Modified to make them non-redundant. > 'Without explicit approval of the domain owner, checking other > identities against SPF version 1 records is NOT RECOMMENDED because > there are cases that are known to give incorrect results.' > > How should this explicit approval be sought? This recommendation > does not make sense. What I have now is "Documents that define other identities will have to define the method for explicit approval." > In Section 2.4: > > 'When a mail receiver decides to perform an SPF check, it MUST use a > correctly-implemented check_host() function (Section 4) evaluated > with the correct parameters.' > > This RFC 2119 requirement states the obvious. It basically says that > there is a requirement in draft-ietf-spfbis-4408bis-14 to use a > correct implementation of draft-ietf-spfbis-4408bis-14. This was changed already due to other comments. I think it makes sense now. Please check when -15 is published. > 'Although invalid, malformed, or non-existent domains cause SPF checks > to return "none" because no SPF record can be found, it has long been > the policy of many MTAs to reject email from such domains, especially > in the case of invalid "MAIL FROM". Rejecting email will prevent one > method of circumventing of SPF records.' > > This text is already in RFC 4408. > > "Implementations have to take care to correctly extract the > from the data given with the SMTP MAIL FROM command as many MTAs will > still accept such things as source routes ..." > > The definition of is: > > 'the domain portion of the "MAIL FROM" or "HELO" identity.' > > I am not sure whether it is even a definition. From an > implementation perspective the last paragraph of Section 2.4 is unclear. It seems clear to me. Could you expand on why you think it's problematic or provide recommended text. > In Section 2.5: > > "The authorization check SHOULD be performed during the processing of > the SMTP transaction that sends the mail." > > This RFC 2119 SHOULD is already in RFC 4408. > > 'Performing the authorization other than using the return-path and > client address at the time of the MAIL command during the SMTP > transaction can cause problems, ..' > > Shouldn't that be "authorization check"? Yes. Fixed. > 'Generating non-delivery notifications to forged identities that have > failed the authorization check is a source of backscatter and SHOULD > be avoided.' > > This RFC 2119 SHOULD is not in RFC 4408. The above does not have > anything to do with Sender Policy Framework. It was mentioned during > WG discussions that "SPF can help the backscatter problem" [2]. This > text may have been introduced in response to a review [3]. Is this > an enhancement or a clarification? It's a clarification. > In Section 2.6: > > "An SPF verifier implements something semantically identical to the > function defined there." > > John Levine commented about this during the WGLC [4]. I am listing > this as a reminder for myself. > > In Section 2.6.1: > > 'A result of "none" means either (a) no syntactically valid DNS domain > name was extracted from the SMTP session that could be used as the > one to be authorized, or (b) no TXT records were retrieved from the > DNS that appeared to be intended for use by SPF verifiers.' > > I suggest "DNS TXT records". What is a syntactically valid DNS > domain name? The definition of "none" in RFC 4408 is clear (to me). How could one retrieve anything other than DNS TXT records from the DNS? That seems redundant since it says "retrieved from the DNS". > In Section 2.6.2: > > 'The domain owner has explicitly stated that it is not asserting > whether the IP address is authorized. This result MUST be treated > exactly like the "none" result; the distinction exists only for > informational purposes.' > > As a note, the RFC 2119 MUST is in RFC 4408. The Introduction > Section mentions "ADMDs can authorize hosts to use their domain > names". The above uses "domain owner". Changed to ADMD. Made the same change in 2.6.5 as well. > In Section 2.6.7: > > 'A "permerror" result means the domain's published records could not > be correctly interpreted. This signals an error condition that > definitely requires manual intervention to be resolved.' > > What is "manual intervention" in the above? Would operator intervention or operator action be better? > In Section 3: > > 'An SPF record is a DNS record that declares which hosts are, and are > not, authorized to use a domain name for the "HELO" and "MAIL FROM" > identities.' > > How are hosts which are not authorized to use a domain name listed in > a SPF record? If a record contains something like -a:host.example.com that host is explicitly not authorized. > "The SPF record is a single string of text." > > What is a single string of text? It may be easier to state this in > terms of record format. I think this was addressed in a later comment and it should be improved. > 'ADMDs publishing SPF records SHOULD try to keep the number of > "include" mechanisms and chained "redirect" modifiers to a minimum.' > > What is the minimum? Note that this RFC 2119 SHOULD is in RFC 4408. It's the least an ADMD needs to properly describe the hosts authorized to send mail from their domain. It's minimum in the sense of no more than needed. > 'ADMDs SHOULD also try to minimize the amount of other DNS information > needed to evaluate a record.' > > This RFC 2119 SHOULD is also in RFC 4408. There are two RFC 2119 > SHOULDs in the last paragraph of Section 3. This usage of RFC 2119 > key words does not help the SPF "publisher". In my opinion the > "SHOULD try" in this context uses the RFC 2119 key word in unorthodox ways. I took try out of the section. I think that should do it. > In Section 3.1: > > 'SPF records MUST be published as a DNS TXT (type 16) Resource Record > (RR) [RFC1035] only.' > > I would ask why "MUST be published ... only". By the way, Section 3 > has a reference to Section 4 for record format instead of Section > 3.1. Is that correct? The only is to make it clear that the Type SPF records that were defined in RFC 4408 are no longer part of the protocol. It is correct. The ABNF for the record format is in section 4. > In Section 3.2: > > "A domain name MUST NOT have multiple records that would cause an > authorization check to select more than one record." > > This RFC 2119 MUST NOT was in RFC 4408. Is this to help the SPF > "publisher" and if so, how does it help? 4408 has an implicit requirement for this. In section 4.5, it says: > If the resultant record set includes more than one record, check_host() > produces the "permerror" result. The MUST NOT here makes it clear the condition has to be avoided. It's not a functional change in the protocol. > In Section 3.3: > > "As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS > record can be composed of more than one string." > > See previous comment about " a single string". > > "If a published record contains multiple character-strings, then the > record MUST be treated as if those strings are concatenated together > without adding spaces." > > This RFC 2119 MUST is also in RFC 4408. I suggest removing the > "MUST" in the example. Why? If you don't do it that way, the result is not interoperable. > "TXT records containing multiple strings are useful in constructing > records that would exceed the 255-byte maximum length of a character- > string within a single TXT record." > > I suggest using "octet" instead of "byte". I'll point the working > group to CVE-2008-2469 in case it might wish to consider that issue. The CVE is unrelated. > In Section 4: > > "A compliant SPF implementation MUST do something semantically equivalent > to this description." > > It's unusual to see a "do something" RFC 2119 requirement in a > specification. Is the SPFBIS WG working on compliance for SPF > implementations? It was added as part of making check_host() not a formal API/functional specification. You need an equivalent result, but needn't follow all the steps exactly. Please recommend an alternative. > "Mail receivers that perform this check MUST correctly evaluate the > check_host() function as described here." > > Where does "mail receivers" fit in the Sender Policy Framework? The > "MUST correctly evaluate" is stating the obvious. Receiving ADMDs. Fixed. > "Implementations MAY use a different algorithm than the canonical > algorithm defined here, so long as the results are the same in all > cases." > > Why is this a RFC 2119 MAY? I am aware that the text is in RFC 4408. trying to make it clear there's flexibility for the implementer. Do you think it should be changed? > In Section 4.1: > > ' - the domain that provides the sought-after authorization > information; initially, the domain portion of the "MAIL > FROM" or "HELO" identity.' > > The above text is different from the text in Section 2.4. Yes, but not inconsistent with it. > In Section 4.3: > > "If the is malformed (e.g. label longer than 63 characters, > zero-length label not at the end, etc.)" > > That should be "octets". I recall further discussion about this in a later message in the thread. I'll address it there. > "Properly formed domains are fully qualified email domains as > described in [RFC5321] Section 2.3.5." > > What are "properly qualified email domains"? What it says they are in the reference. > "Internationalized domain names MUST be encoded as A-labels, as > described in Section 2.3 of [RFC5890].on 2.3 of [RFC5890]." > > I'm listing the above and leave it to Area Director guidance. Please > note that it is a new RFC 2119 requirement. It's a new requirement because IDN wasn't addressed in 4408. It's necessary to address it now and the WG agreed this was the best way to do it. > In Section 4.4: > > "In accordance with how the records are published (see Section 3 > above), a DNS query needs to be made for the name, querying > for type TXT only." > > I don't understand the sentence. What don't you understand? > 'Alternatively, for a server failure (RCODE 2) result, check_host() > MAY track failures and treat multiple failures within 24 hours for > the same domain as "permerror".' > > This text is not in RFC 4408. I found a note in Issue #1 [5] and in > a message [6]. Yes. This is a change to address an operational issue found during SPF deployment. > In Section 4.6.2: > > "If there are no more mechanisms, the result is specified in > Section 4.7." > > This sentence does not make sense. If I changed it to "If there are no more mechanisms, the result is the default result as described in section 4.7" would it be clearer? > > In Section 4.6.4: > > "SPF implementations MUST limit the total number of mechanisms and > modifiers ("terms") that cause any DNS query to at most 10 during SPF > evaluation." > > This was discussed on the mailing list [7]. > > "If this number is exceeded during a check, a permerror MUST be > returned." > > I read this as if an implementation-specific limit is reached a > permerror is returned. There are two RFC 2119 MUST in the > above. That can be reduced to one MUST. Is there a problem with it the way it is? > I read the first paragraph of Section 4.6.4. I am not sure how the > absolute requirement will be interpreted by the reader. We worked on making it clearer. If you have suggested improvements, please send them. > 'MTAs or other processors SHOULD impose a limit on the maximum amount > of elapsed time to evaluate check_host(). Such a limit SHOULD allow > at least 20 seconds. If such a limit is exceeded, the result of > authorization SHOULD be "temperror".' > > There are three RFC 2119 SHOULDs in the above. I suggest rewriting > the text to reduce that. They are three different things. Why would rewriting it help? > 'SPF implementations SHOULD limit "void lookups" to two.' > > What are void lookups? The term is defined in the two immediately preceding sentences. > "In this case, a default of two is RECOMMENDED." > > Why is "two" recommended? Because that's the limit that is currently widely deployed (in the perl Mail::SPF implementation) with which there has been good experience. > 'Note that records SHOULD always use either a "redirect" modifier or > an "all" mechanism to explicitly terminate processing.' > > Why is there a RFC 2119 key word in a note? Took out the 2119 word. > In Section 4.8: > > 'e.g., "foo..example.com") or overlong labels (more than 63 > characters).' > > I suggest octets. > > in Section 5: > > 'SPF implementations on IPv6 servers need to handle both "AAAA" and "A" > secords, for clients on IPv4 mapped IPv6 addresses [RFC4291].' > > There is a typo, "records". Already fixed. > I'll flag the above for review by people with IPv6 expertise. What's in -15 is the result of the review and WG feedback. > In Section 5.3: > > 'a = "a" [ ":" domain-spec ] [ dual-cidr-length ]' > > "dual-cidr-length" is introduced in this sub-section. I had to > search through the draft to find out what it means. > > In Section 5.4: > > 'Note regarding implicit MXs: If the has no MX records, > check_host() MUST NOT pretend the target is its single MX, and MUST > NOT default to an A or AAAA lookup on the directly.' > > There are two RFC 2119 MUSTs in the above. This is over-usage of RFC > 2119 key words. This text was in RFC 4408. This is not a divergence > from RFC 5321, it is a contrary to Section 5 of RFC 5321. It's not contrary. It's saying that aspect of 5321 is not relevant to SPF. In any case, changing it would be a substantiative change to the protocol that would require all implementations to be updated. > In Section 5.5: > > "This mechanism SHOULD NOT be used." > > I suggest providing a reason for this. The reason is given in the note at the end of the section. > "To prevent DoS attacks, more than 10 PTR names > MUST NOT be looked up during the evaluation of a "ptr" mechanism > (see Section 4.6.4)." > > The above restates a previous RFC 2119 MUST. > > "If used, proper PTR records MUST be in place for the domain's hosts > and the "ptr" mechanism SHOULD be one of the last mechanisms checked." > > Those RFC 2119 key words are not in RFC 4408. I don't see how this > RFC 2119 change qualifies as a clarification or explanation. For the MUST, it flat out won't work if you don't have those (no interoperation). For the SHOULD, it's an optimization. We can change it if you want. > "It is, however, still in use and part of the SPF protocol, so compliant > check_host() implementations MUST support it." > > What is a compliant check_host() implementation? One that works in accordance with 4408bis. Please suggest an alternative if you don't like that. > In Section 5.6: > > "ip6-network = " > > I suggest that the above reference be verified for correctness. > > In Section 5.7: > > 'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all' > > I'll flag this for review by DNS folks. > > In Section 6: > > 'The modifiers defined in this document ("redirect" and "exp") MAY > appear anywhere in the record, but SHOULD appear at the end, after > all mechanisms.' > > This text is in RFC 4408. I would label the RFC 2119 usage as defective. Why? > In Section 6.2: > > "Since the explanation string is intended for an SMTP response and > [RFC5321] Section 2.4 says that responses are in [US-ASCII], the > explanation string MUST be limited to US-ASCII.' > > It would be easier to defer to RFC 5321 instead of setting a RFC 2119 > requirement in this draft. I note that this requirement was not in RFC > 4408. It's not a new requirement. If you couldn't find it in 4408, then that means we've succeeded in making the actual requirement more clear. > "Software SHOULD make it clear that the explanation string > comes from a third party." > > I could not understand what that means in RFC 2119 terms. The draft > uses RFC 2119 key words by example instead of providing an explanation. I don't understand the comment. > In Section 7.1: > > 'The "toplabel" construction is subject to the LDH rule plus > additional top-level domain (TLD) restrictions.' > > Where can I find these restrictions? Please note that I have read > the Informational RFC. LDH + non-numeric as the RFC says. > In Section 7.3: > > "-exists:%(ir).sbl.spamhaus.example.org" > > I commented about vendor-neutral previously [8]. The above is a way > to get around the objection [9]. I suggest cleaning this up. Took spamhaus out. > "so trailing dots SHOULD NOT be published by domain owners" > > Why is it "domain owners"? Took out everything after published. > "This macro SHOULD NOT be used. See Section 5.5 for the discussion > about why not." > > This comes out as a flippant explanation for the RFC 2119 SHOULD. Please recommend non-flippant text then. It doesn't read that way to me. > "This SHOULD be a fully qualified domain name, but if one does not > exist (as when the checking is done by a MUA) or if policy restrictions > dictate otherwise, the word "unknown" SHOULD be substituted." > > The RFC 2119 key words are in RFC 2119. I don't know what to say. OK. > "When the result of macro expansion is used in a domain name query, if > the expanded domain name exceeds 253 characters (the maximum length > of a domain name), the left side is truncated to fit, by removing > successive domain labels (and their following dots) until the total > length does not exceed 253 characters." > > Where is it specified that the maximum length of a domain name is 253 > characters? This was covered in someone else's response. > "Care has to be taken by the sending ADMD so that macro expansion for > legitimate email does not exceed the 63-character limit on DNS labels." > > Where is that 63-character limit specified? This was covered in someone else's response. > It is odd to have RFC 2119 requirements under a "Notes" heading. They aren't really notes in that sense. If you have a better name for the section, please suggest. > In Section 8.2: > > 'A "neutral" result MUST be treated exactly like the "none" result; > the distinction exists only for informational purposes.' > > Why is an existing RFC 2119 restated? Because of the structure of the document that the WG came up with. I don't find a good way to avoid it and not make it less readable. > In Section 8.5: > > "The domain owner believes the host is not authorized but is not willing > to make a strong policy statement." > > Why is it domain owner? Because conversion to the newer terms was incomplete. I clean up this and some others as well. > In Section 9: > > "An operator could choose to use both to serve different downstream > agents. In such cases, care needs to be taken to ensure both fields > are conveying the same details, or unexpected results can occur." > > This has been discussed on the mailing list. I don't think that it > encourages interoperability but the working group decided otherwise [10]. > > In Section 9.1: > > "The Received-SPF header field is a trace field (see [RFC5322] Section > 3.6.7) and SHOULD be prepended to the existing header, above the > Received: field that is generated by the SMTP receiver." > > "prepended to the existing header" does not sound right. I believe it is. > "It MUST appear above all other Received-SPF fields in the message." > > How does this fit into the previous RFC 2119 SHOULD? It will generally happen as a natural result of following the previous one, but is there in case more than one is added by a single MTA. > in Section 10: > > "This section is not a "how-to" manual, or a "best practices" document, > and it is not a comprehensive list of what such entities SHOULD do in > light of this document." > > What is the meaning of the RFC 2119 SHOULD in the above? Got rid of it. > > In Section 10.1.1: > > There was a comment from Authur Thisell about the table [11] in this > sub-section. There didn't seem to be support for changing it though. > In Section 10.1.2: > > "Publishing SPF records for domains that send no mail is > a well established best practice." > > I am not aware of that best practice. I did a few DNS queries: > > ;; QUESTION SECTION: > ;bing.com. IN TXT > > ;; ANSWER SECTION: > bing.com. 3600 IN TXT "v=msv1 > t=6097A7EA-53F7-4028-BA76-6869CB284C54" > > ;; QUESTION SECTION: > ;com.com. IN TXT > > ;; ANSWER SECTION: > com.com. 293 IN TXT > "google-site-verification:esSnoZdChIkkfCfS9MMgqNhE0yaXfnnZWdZPuBf7e8k" OK. See http://www.bits.org/publications/security/BITSEmailAuthenticationFeb2013.pdf > In Section 10.1.3: > > "SPF functionality is enhanced by administrators ensuring this > identity is set correctly and has an appropriate SPF record." > > How is SPF functionality enhanced? If there's an SPF record for HELO as well as Mail From, then a check can be performed on bounces. > In Section 10.2: > > "As stated elsewhere in this document, there is no normative requirement > for specific handling of a message based on any SPF result." > > The "as stated elsewhere" is vague. It comes up multiple places. Adding several specific reference won't improve the draft. > 'The primary considerations are that SPF might return "pass" for mail > that is ultimately harmful (e.g., spammers that arrange for SPF to > pass using nonsense domain names' > > What are "nonsense" domain names? There was follow-on discussion about this. > In Section 10.3: > > "The mediator can make the newly-posted message be as similar or as > different from the original message as they wish." > > The sentence seems incomplete, i.e. similar to what. The original message. > "For the operation of SPF, the essential concern is the email > address in the 5321.MailFrom command for the new message." > > What does this mean? It means that's the thing that's the most important. > 'Because SPF evaluation is based on the IP Address of the "last" > sending SMTP server, the address of the mediator will be used, rather > than the address of the SMTP server that sent the message to the > mediator.' > > I'll note that this is a mix of RFC 5321 and RFC 5598. The result is > clear or unclear depending on the background of the reader. I guess I have the background for it to be clear. Please suggest an improvement. > In Section 11.5: > > "An SPF compliant receiver gathers information from the SMTP commands > it receives and from the published DNS records of the sending domain > holder" > > I suggest explaining the untrusted part. That's what the section does. > In Section 11.6: > > "Checking SPF records causes DNS queries to be sent to the domain > owner." > > How are DNS queries sent to domain owners? Fixed it. > Section 12: > > I note that Murray S. Kucherawy has contributed significantly to > draft-ietf-spfbis-4408bis. If I am not mistaken it is IETF practice > to acknowledge such contributions. I don't recall who sent text at > the moment. If you did, please send an (off-list) email to the > SPFBIS WG Chairs. There are many, many people who contributed to both 4408 and 4408bis that aren't listed. If someone wants to make a list of people who made a significant contribution, I'll be glad to include it. > In Section 13.1: > > "The format of this type is identical to the TXT RR [RFC1035]" > > The format is not identical, i.e. it's a different RR. I suggest > keeping the IANA Considerations Section simple, i.e. clearly explain > to IANA what action is requested. Yes, it is. > In Section 13.2: > > "Per [RFC3864], the "Received-SPF:" header field is added to the IANA > Permanent Message Header Field Registry." > > Note to self: request removal from the provisional message header > field registry. > > The "status:" should be "standard" Not Standards Track? > In Section 13.3: > > "Their status should not be changed." > > I suggest "Their status is unchanged". BTW, it should be "SPF > Modifier Registry". Fixed > I suggest following RFC 6652 Section 5.1. > An "Updates:" for RFC 6652 may be needed. Why? It's the registry that gets updated, not 6552. > > References: > > Why is RFC 1123 a normative reference? See section 2.4. > > Why is RFC 3864 a normative reference? Because it defines how the Received-SPF registration is done. > > Where can I find "Designated Mailers Protocol"? See draft-fecyk-dsprotocol > > Where can I find "Domain-Authorized SMTP Mail"? I don't have a copy of this. > ABNF: > > Did anyone verify the ABNF? > > In Appendix C: > > In Section E.1: > > 'This would cause a lookup on an DNS white list (DNSWL) and cause a > result of "fail" only for email not either coming from the > domain's mx host(s) (SPF pass) or white listed sources (SPF > neutral).' > > I didn't find any discussion about this on the SPFBIS mailing > list. is there an explanation for this change between RFC 4408 and this > draft? It was pointed out that this is a white list, not a black list. > I note that there are 48 pages in RFC 4408. There are 78 pages in > this draft. A significant amount of text has been added in the > Appendix (over 20 pages). I doubt that the text has been carefully > reviewed. I may be asked for an explanation about all that once the > draft leaves this working group. Why wait? > In Appendix I: > > Appendix I is about "Protocol Status". This draft is intended as a > Proposed Standard. From an IETF perspective that is what it will > be. Describing it as something different can be misleading. > > "[RFC4408] was designed to clearly document the protocol defined by > earlier draft specifications of SPF as used in existing > implementations. This updated specification is intended to clarify > identified ambiguities in [RFC4408], resolve techincal issues > identified in post-RFC 4408 deplyment experience, and document widely > deployed extensions to SPF that have been developed since [RFC4408] > was published." > > Extensions to the SPF protocol are clearly mentioned in the charter > as being out of scope. The "document widely deployed extensions" is > problematic. The charter specifically allows for "addition of any enhancements that have already gained widespread support". > "This document updates and replaces RFC 4408 that was part of a group > of simultaneously published Experimental RFCs (RFC 4405, RFC 4406, > RFC 4407, and RFC 4408) in 2006. At that time the IESG requested the > community observe the success or failure of the two approaches > documented in these RFCs during the two years following publication, > in order that a community consensus could be reached in the future." > > Why is this needed? The SPFBIS WG produced RFC 6686 to resolve the > experiment. Since this is what obsoletes 4408, not everyone will read 6686. > "SPF is widely deployed by large and small email providers alike. > There are multiple, interoperable implementations." > > Someone might point out that this is marketing instead of text > relevant to a protocol. I'll mention that one or more significant > issues (e.g. Issue #9) was identified during the WG > discussions. Issue #9 was not listed as the errata. I suggest > removing the section as it will be less text and there is already two > informative references to help the reader find background information. #9 has been known since before 4408 was published. In 2005 it was the price of admission to the IETF. > Regards, > S. Moonesamy (as document shepherd) > > 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html > 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00928.html > 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg01810.html > 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg03378.html > 5. http://trac.tools.ietf.org/wg/spfbis/trac/ticket/1 > 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg00630.html > 7. http://www.ietf.org/mail-archive/web/spfbis/current/msg00199.html > 8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02279.html > 9. http://www.ietf.org/mail-archive/web/spfbis/current/msg02308.html > 10. http://www.ietf.org/mail-archive/web/spfbis/current/msg02526.html > 11. http://www.ietf.org/mail-archive/web/spfbis/current/msg02763.html > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From marka@isc.org Thu May 16 14:54:42 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFAF21F8733 for ; Thu, 16 May 2013 14:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy-rdYsSiV2G for ; Thu, 16 May 2013 14:54:40 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 79AB621F87D2 for ; Thu, 16 May 2013 14:54:38 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id DB3855F9887; Thu, 16 May 2013 21:54:29 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1368741278; bh=KuQ1hlSOXBTtIbxo9Cv+531Xy43YcK3Dd1mQPGp6bfk=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Arzt6hFxLUOucVWUnYOZUfkLW4VbxEa3Xwmp/03jzV5X6oCgeVZhZLS6Z7l5ZYLKj 7ovfSCetqam5B9WI+CnyfGy9wD3IJPQg0AB1oLlsZ6mgUDiB8sw/SjvtqjRwQGqv/t hd5CLNJA+TjpSGO3/clh6HGGYWyTrMd96m/l1VBM= Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:1dce:b11:d121:8ed7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id F364D216C47; Thu, 16 May 2013 21:54:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 7E55F3460DEC; Fri, 17 May 2013 07:54:23 +1000 (EST) To: Scott Kitterman From: Mark Andrews References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <2724237.eQuNQK5KLA@scott-latitude-e6320> In-reply-to: Your message of "Thu, 16 May 2013 17:45:35 -0400." <2724237.eQuNQK5KLA@scott-latitude-e6320> Date: Fri, 17 May 2013 07:54:23 +1000 Message-Id: <20130516215423.7E55F3460DEC@drugs.dv.isc.org> Cc: spfbis@ietf.org Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 21:54:42 -0000 In message <2724237.eQuNQK5KLA@scott-latitude-e6320>, Scott Kitterman writes: > > "This SPF check can only be performed when the "HELO" string is a > > valid fully qualified domain." > > > > What is a valid fully qualified domain? > > Would s/domain/domain name/ clear it up for you? "com" is a fully qualified domain. Multi-label domain is the term being looked for. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From spf2@kitterman.com Thu May 16 15:01:18 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E4B21F8797 for ; Thu, 16 May 2013 15:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80eUkj4EEvAD for ; Thu, 16 May 2013 15:01:13 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E998921F8733 for ; Thu, 16 May 2013 15:01:12 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 335FF20E411A; Thu, 16 May 2013 18:00:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368741668; bh=ZB1Oe2ovqivgZR4nunpUR0bYlIDIvbXXcsuC0p2Ev60=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EuQmPCbl/FWuPI2PUwkylybIvXYUy7k9KlxV7/iLfAnkGQLK+tbFNgpzyJWE+c7LA Gn6o4rBUu2iZy+0C7GsFhRb4nySmCiiBoNebPX7k7YoJPvoSAurqjdsfyaDW7GKqyO NnHkBVwa/ae+fzBlHtXgX/O2oJU4mP/P06EVSdBs= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 17F5A20E40C6; Thu, 16 May 2013 18:00:57 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 16 May 2013 18:00:57 -0400 Message-ID: <136877248.XUTTK7kNWG@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130516215423.7E55F3460DEC@drugs.dv.isc.org> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <2724237.eQuNQK5KLA@scott-latitude-e6320> <20130516215423.7E55F3460DEC@drugs.dv.isc.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 22:01:18 -0000 On Friday, May 17, 2013 07:54:23 AM Mark Andrews wrote: > In message <2724237.eQuNQK5KLA@scott-latitude-e6320>, Scott Kitterman writes: > > > "This SPF check can only be performed when the "HELO" string is a > > > > > > valid fully qualified domain." > > > > > > What is a valid fully qualified domain? > > > > Would s/domain/domain name/ clear it up for you? > > "com" is a fully qualified domain. Multi-label domain is the term > being looked for. > > Mark Thank you. Incorporated. Scott K From superuser@gmail.com Thu May 16 17:28:16 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B6E11E8132 for ; Thu, 16 May 2013 17:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQC8rxtm1zCc for ; Thu, 16 May 2013 17:28:16 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id B050411E8129 for ; Thu, 16 May 2013 17:28:15 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id p58so69269wes.21 for ; Thu, 16 May 2013 17:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BUak5gTct6UAXGcXYMKgB2OZ2hAUkzUp7NjZP/yoDto=; b=ROuzl4d0Xs0WzrYkjQK+mv+6YaJw7iTRwBBSN7MfPwT3UvpS6IrZ4/I+svO0T+AbR2 hVJW8Kr5xqrsA01ljYDz4AyorJQKnBL942xil+3kpARhj0FcghgMo2c7VJbExNmBRKpY QYL3WAzznWroyNJg4qottpWcxWws7pcrDgdSwmesE99GFNjVEAiuSlpBlZMFie4x0yAE jCNBqRBEK/pJfTc6qIHSRFhCeWAUgVcCjIZcmcVEqkzNpFy7zMxtGuFMwreEaHOAegy3 OZIKl/O0LblfPK2ivbijuXV1PR8gUm2ObKwXVBTagMhKBYYPpFtseTpNEl3cLyYCGJOc osIg== MIME-Version: 1.0 X-Received: by 10.180.210.242 with SMTP id mx18mr29145043wic.14.1368750494841; Thu, 16 May 2013 17:28:14 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Thu, 16 May 2013 17:28:14 -0700 (PDT) In-Reply-To: <20130516215423.7E55F3460DEC@drugs.dv.isc.org> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <2724237.eQuNQK5KLA@scott-latitude-e6320> <20130516215423.7E55F3460DEC@drugs.dv.isc.org> Date: Thu, 16 May 2013 17:28:14 -0700 Message-ID: From: "Murray S. Kucherawy" To: Mark Andrews Content-Type: multipart/alternative; boundary=001a11c262e808006a04dcdf0f17 Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 00:28:17 -0000 --001a11c262e808006a04dcdf0f17 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 16, 2013 at 2:54 PM, Mark Andrews wrote: > > > What is a valid fully qualified domain? > > > > Would s/domain/domain name/ clear it up for you? > > "com" is a fully qualified domain. Multi-label domain is the term > being looked for. > > Interesting. What would be an example of something that a domain name but isn't a fully-qualified domain name? -MSK --001a11c262e808006a04dcdf0f17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --001a11c262e808006a04dcdf0f17-- From doug.mtview@gmail.com Thu May 16 17:54:26 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6A311E8137 for ; Thu, 16 May 2013 17:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ-Jr8-GBhAF for ; Thu, 16 May 2013 17:54:26 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2C92E11E8132 for ; Thu, 16 May 2013 17:54:26 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bv4so105333qab.11 for ; Thu, 16 May 2013 17:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:subject:message-id:date:to :mime-version:x-mailer; bh=RT5+omD/m5ZWIo3opLmtyKQyI+lJsPAl+r3bEfzbd7c=; b=ywkRYUF1yo1w5aQqJhYddI9mWmTL2ozeceOlu2D6rGNvP9wZJKH93BMUXI1B0eicy7 71wwzNtft5m8HNcZk6i6oKRZrtZA/is4+oZ3M2xYNIYXKebTYh3xn/gjXyEfmBjiaNOV pSenoh34ZtYI3jfeuAyRLB4jZ9LTOfIqnb43xuA8ShdoKDvSSQFdz2UqF4atloi/eKrx BuMHWnKrflaOkFS/vttTkmPN208M014CP4rGgGkNWsprcRKUNZNtVYYaGLY8D8LBI77c 4AtwNcdP4d8O7ytKIH+R6VskYtUVTp6vHMAyN4FeJhDZ4wbF2Z1rmnECV572CdFR/Tg6 jVAA== X-Received: by 10.229.170.18 with SMTP id b18mr5293298qcz.5.1368752059955; Thu, 16 May 2013 17:54:19 -0700 (PDT) Received: from [192.168.1.194] (c-24-4-157-244.hsd1.ca.comcast.net. [24.4.157.244]) by mx.google.com with ESMTPSA id i5sm10350121qaf.0.2013.05.16.17.54.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 May 2013 17:54:19 -0700 (PDT) From: Douglas Otis Content-Type: multipart/alternative; boundary="Apple-Mail=_C23CE40A-1C7C-4C92-8DF9-23B403AFD594" Message-Id: Date: Thu, 16 May 2013 17:54:15 -0700 To: "spfbis@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Thu, 16 May 2013 18:37:19 -0700 Subject: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14, X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 00:54:26 -0000 --Apple-Mail=_C23CE40A-1C7C-4C92-8DF9-23B403AFD594 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear SPFbis WG, An I-D has been submitted offering a review of the SPFbis draft. http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-00 Sorry for the delay in preparing this document. There was a fair amount = of botnet activity requiring a fair amount of attention. Regards, Douglas Otis= --Apple-Mail=_C23CE40A-1C7C-4C92-8DF9-23B403AFD594 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Dear SPFbis WG,

An I-D has been submitted offering a review of the SPFbis draft.


Sorry for the delay in preparing this document.  There was a fair amount of botnet activity requiring a fair amount of attention.

Regards,
Douglas Otis
--Apple-Mail=_C23CE40A-1C7C-4C92-8DF9-23B403AFD594-- From doug.mtview@gmail.com Thu May 16 18:08:37 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB6211E8137 for ; Thu, 16 May 2013 18:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsOPH8f57jnw for ; Thu, 16 May 2013 18:08:33 -0700 (PDT) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE7711E8132 for ; Thu, 16 May 2013 18:08:33 -0700 (PDT) Received: by mail-ee0-f45.google.com with SMTP id l10so2139354eei.4 for ; Thu, 16 May 2013 18:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:subject:message-id:date:to :mime-version:x-mailer; bh=XqtIexPA3LMWlZ2KsTLG8Y7k03/qMV0FNBwxJllWbTo=; b=rtngSO+YWcHzywfFGLKynYxzbRDBbs7nQ1LDDOhCXPBI+Hz1DJBSqau56FWhkpU8Jv VtvQtN6yGMeBbM+NcTvdZxk+bCarxl05wZmMdYDiMe+9A9GG/Mr6qG0UmeSnr1af/VqS sWbWt/dZgBwVsa+edO9HRSUXPVzSBhpFRdM3wTFLMDveWflwq6dfwiMn4+4JkOnsdDoG DmYtXskY/ErVsFflAs9Xo8bPsQg9Zf45tPjI8/3Y+dt7nkvYE+/WJ7JwXbfonPVrhhOX WwcjqnjGiOSxBg8T29oEdsAewIIz0YV7zZzwWBF6o1noqmcrIALsD5JRCnf3c2HtMU8N +JVA== X-Received: by 10.14.99.8 with SMTP id w8mr22596777eef.30.1368752912192; Thu, 16 May 2013 18:08:32 -0700 (PDT) Received: from ?IPv6:2601:9:3180:3e:5438:cadf:2caa:f0a? ([2601:9:3180:3e:5438:cadf:2caa:f0a]) by mx.google.com with ESMTPSA id s8sm14767986eeo.4.2013.05.16.18.08.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 May 2013 18:08:31 -0700 (PDT) From: Douglas Otis Content-Type: multipart/alternative; boundary="Apple-Mail=_0258A1DD-8F0F-4B24-8F2F-0277E5ACF058" Message-Id: Date: Thu, 16 May 2013 18:08:27 -0700 To: "spfbis@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Thu, 16 May 2013 18:37:29 -0700 Subject: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 01:08:37 -0000 --Apple-Mail=_0258A1DD-8F0F-4B24-8F2F-0277E5ACF058 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear SPFbis WG, An I-D has been submitted offering a review of the SPFbis draft. http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-00 Sorry for the delay in preparing this document. There was a fair amount = of botnet activity requiring a fair amount of attention. Regards, Douglas Otis= --Apple-Mail=_0258A1DD-8F0F-4B24-8F2F-0277E5ACF058 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Dear SPFbis WG,

An I-D has been submitted offering a review of the SPFbis draft.


Sorry for the delay in preparing this document.  There was a fair amount of botnet activity requiring a fair amount of attention.

Regards,
Douglas Otis
--Apple-Mail=_0258A1DD-8F0F-4B24-8F2F-0277E5ACF058-- From sm@elandsys.com Thu May 16 18:40:55 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B6511E80D9 for ; Thu, 16 May 2013 18:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UTTEY1LKW3k for ; Thu, 16 May 2013 18:40:52 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF19911E80BA for ; Thu, 16 May 2013 18:40:51 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.148.174]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4H1eSGj006789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 May 2013 18:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1368754847; bh=+aAqxzhZOnodyq9x/yHj+kDEEVCtxCagFg5Sdul4rpk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Du10pKZqzlSMmuQtdSG/wN12Ws+eGUVmtnGtZglFy95d+II/0h5ouCTqlUK/U5dvi K6tIyCUF7rzjHCcJwv7KOrIsSSxEd7yBtmzx771WlA1dztrx90ET3xKLOo+4cBHI6C 15itKQIIU9bo5bjYlNwkJ+mu5ScriO9aRuFFDop4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1368754847; i=@elandsys.com; bh=+aAqxzhZOnodyq9x/yHj+kDEEVCtxCagFg5Sdul4rpk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uDPF6TzP9fgFVqBInvOOUQQPee3HUc0p8/JSTDu80WkOcan/pOJd7rdpSm7D20d1b xTslTOu0dE7SjeN1WyAhH23AVS2sIgbWXVNPyj/5sCi3ZeqfW3bB6nsyRAVzB+9oyM y6Scpz3O0k2zonJjsifCQdzh1ZAng2nxEQDYsq6k= Message-Id: <6.2.5.6.2.20130516154521.06ceef08@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 16 May 2013 18:36:14 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <2724237.eQuNQK5KLA@scott-latitude-e6320> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <2724237.eQuNQK5KLA@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 01:40:55 -0000 Hi Scott, Murray Kucherawy, Alessandro Vesely, John Levine and Stuart Gathman commented about this review. I'll cover these comments in my response. By the way if I missed any of the comments please let me know. I'll follow the guidance in the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg03642.html for RFC 2119 key words. At 14:45 16-05-2013, Scott Kitterman wrote: > > "This SPF check can only be performed when the "HELO" string is a > > valid fully qualified domain." > > > > What is a valid fully qualified domain? > >Would s/domain/domain name/ clear it up for you? I'll suggest the following: This SPF check can only be performed when the "HELO" string is a fully-qualified domain name. > > In Section 2.2: > > > > 'SPF verifiers MUST check the ""MAIL FROM" identity if a completed > > "HELO" check has not reached a definitive policy result by applying > > the check_host() function to the "MAIL FROM" identity as the > > .' > > > > As a note this RFC 2119 MUST is already in RFC 4408. > > > > In Section 2.3: > > > > "An SPF-compliant domain MUST have valid SPF records as described in > > Section 3." > > > > As a note the RFC 4408 text is: > > > > "An SPF-compliant domain MUST publish a valid SPF record as described > > in Section 3." > > > > The RFC 2119 MUST is redundant. > >Is there a reason to change it? From a previous comment: 'In a recent conversation, Pete described this as "not really wrong, but it's shouting." I guess that means changing "MUST publish" to "publishes" or something like that. I am ok with the "publishes".' I suggest using that. > > 'If domain owners choose to publish SPF records and want to support > > receivers making negative authorization determinations, then they MUST > > publish records that end in "-all", or redirect to other records that > > do, otherwise, no definitive determination of authorization can be made.' > > > > The document uses ADMD while there is "domain owners" in the > > above. I suggest reviewing that. > >Changed > > > The RFC 2119 MUST is a substantive change. Why is this a MUST? > >Because it's the literal truth. That's what you have to do to achieve that >result. You won't interoperate with receivers in that way effectively if you >don't. I mentioned this in another message: Andrew Sullivan, as an individual, commented about the text ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02784.html ). I suggest going with what was suggested or else the working group will be discussing Issue #33 again. > > In Section 2.4: > > > > 'At least the "MAIL FROM" identity MUST be checked, but it > > is RECOMMENDED that the "HELO" identity also be checked beforehand.' > > > > There is already a RFC 2119 MUST in Section 2.2. There is also a RFC > > 2119 RECOMMENDED in Section 2.1. The above text restates existing > > RFC 2119 requirements or recommendations. > >Modified to make them non-redundant. I suggest including the proposed text for any changes so that the working group is aware of the text will be added to the revision of the draft. > > 'Without explicit approval of the domain owner, checking other > > identities against SPF version 1 records is NOT RECOMMENDED because > > there are cases that are known to give incorrect results.' > > > > How should this explicit approval be sought? This recommendation > > does not make sense. > >What I have now is "Documents that define other identities will have >to define >the method for explicit approval." "out-of-band" or "private" was suggested. I'll use one of them (I do not have any preference): Without out-of-band approval of the ADMD, checking other identities against SPF version 1 records is NOT RECOMMENDED because there are cases that are known to give incorrect results. > > In Section 2.4: > > > > 'When a mail receiver decides to perform an SPF check, it MUST use a > > correctly-implemented check_host() function (Section 4) evaluated > > with the correct parameters.' > > > > This RFC 2119 requirement states the obvious. It basically says that > > there is a requirement in draft-ietf-spfbis-4408bis-14 to use a > > correct implementation of draft-ietf-spfbis-4408bis-14. > >This was changed already due to other comments. I think it makes sense now. >Please check when -15 is published. The comment I read on the mailing list is: "I agree, that sentence can probably go." The other comment was from Alessandro. Does your comment mean that the sentence will be removed or does it mean that text is being proposed? > > 'Although invalid, malformed, or non-existent domains cause SPF checks > > to return "none" because no SPF record can be found, it has long been > > the policy of many MTAs to reject email from such domains, especially > > in the case of invalid "MAIL FROM". Rejecting email will prevent one > > method of circumventing of SPF records.' > > > > This text is already in RFC 4408. > > > > "Implementations have to take care to correctly extract the > > from the data given with the SMTP MAIL FROM command as many MTAs will > > still accept such things as source routes ..." > > > > The definition of is: > > > > 'the domain portion of the "MAIL FROM" or "HELO" identity.' > > > > I am not sure whether it is even a definition. From an > > implementation perspective the last paragraph of Section 2.4 is unclear. > >It seems clear to me. Could you expand on why you think it's problematic or >provide recommended text. I mentioned in a previous comment that " definitions (not sure whether it is a definition) are mentioned in two places. I suggest fixing that and then getting back to the above". > > 'Generating non-delivery notifications to forged identities that have > > failed the authorization check is a source of backscatter and SHOULD > > be avoided.' > > > > This RFC 2119 SHOULD is not in RFC 4408. The above does not have > > anything to do with Sender Policy Framework. It was mentioned during > > WG discussions that "SPF can help the backscatter problem" [2]. This > > text may have been introduced in response to a review [3]. Is this > > an enhancement or a clarification? > >It's a clarification. In a previous comment I mentioned that "my reading of the above is that it is neither an enhancement or a clarification. I suggest removing the text". > > In Section 2.6.1: > > > > 'A result of "none" means either (a) no syntactically valid DNS domain > > name was extracted from the SMTP session that could be used as the > > one to be authorized, or (b) no TXT records were retrieved from the > > DNS that appeared to be intended for use by SPF verifiers.' > > > > I suggest "DNS TXT records". What is a syntactically valid DNS > > domain name? The definition of "none" in RFC 4408 is clear (to me). > >How could one retrieve anything other than DNS TXT records from the >DNS? That >seems redundant since it says "retrieved from the DNS". I left this DNS angle for Andrew to comment. > > In Section 2.6.7: > > > > 'A "permerror" result means the domain's published records could not > > be correctly interpreted. This signals an error condition that > > definitely requires manual intervention to be resolved.' > > > > What is "manual intervention" in the above? > >Would operator intervention or operator action be better? I suggest "operator intervention" (there was a comment about this). > > In Section 3: > > > > 'An SPF record is a DNS record that declares which hosts are, and are > > not, authorized to use a domain name for the "HELO" and "MAIL FROM" > > identities.' > > > > How are hosts which are not authorized to use a domain name listed in > > a SPF record? > >If a record contains something like -a:host.example.com that host is >explicitly not authorized. Ok. > > "The SPF record is a single string of text." > > > > What is a single string of text? It may be easier to state this in > > terms of record format. > >I think this was addressed in a later comment and it should be improved. There was a suggested text: "An SPF policy statement is expressed as a single string of text encoded in a DNS TXT record." and: "The SPF record is a variable length string of octets encoded in a DSN TXT record." > > 'ADMDs publishing SPF records SHOULD try to keep the number of > > "include" mechanisms and chained "redirect" modifiers to a minimum.' > > > > What is the minimum? Note that this RFC 2119 SHOULD is in RFC 4408. > >It's the least an ADMD needs to properly describe the hosts >authorized to send >mail from their domain. It's minimum in the sense of no more than needed. I commented previously about this "I didn't understand that as there wasn't any explanation for the RFC 2119 SHOULD. I suggest adding an explanation or rewriting the text so that the expression (see above) is clear". > > 'ADMDs SHOULD also try to minimize the amount of other DNS information > > needed to evaluate a record.' > > > > This RFC 2119 SHOULD is also in RFC 4408. There are two RFC 2119 > > SHOULDs in the last paragraph of Section 3. This usage of RFC 2119 > > key words does not help the SPF "publisher". In my opinion the > > "SHOULD try" in this context uses the RFC 2119 key word in unorthodox ways. > >I took try out of the section. I think that should do it. There was a comment that: "SHOULD minimize" conflicts with one intended use, namely v=spf1 redirect=_spf.example.com Exemplified in Section 6.1, that use does not attain the minimum. > > In Section 3.1: > > > > 'SPF records MUST be published as a DNS TXT (type 16) Resource Record > > (RR) [RFC1035] only.' > > > > I would ask why "MUST be published ... only". By the way, Section 3 > > has a reference to Section 4 for record format instead of Section > > 3.1. Is that correct? > >The only is to make it clear that the Type SPF records that were >defined in RFC >4408 are no longer part of the protocol. It is correct. The ABNF for the >record format is in section 4. There were two comments: "The reference is indeed incorrect." and: 'Should we say "is described along with its interpretation in Section 4.5"? How about changing the title of Section 4.5 to "Record Format"?' > > In Section 3.2: > > > > "A domain name MUST NOT have multiple records that would cause an > > authorization check to select more than one record." > > > > This RFC 2119 MUST NOT was in RFC 4408. Is this to help the SPF > > "publisher" and if so, how does it help? > >4408 has an implicit requirement for this. In section 4.5, it says: > > > If the resultant record set includes more than one record, check_host() > > produces the "permerror" result. > >The MUST NOT here makes it clear the condition has to be >avoided. It's not a >functional change in the protocol. Ok. > > In Section 3.3: > > > > "As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS > > record can be composed of more than one string." > > > > See previous comment about " a single string". > > > > "If a published record contains multiple character-strings, then the > > record MUST be treated as if those strings are concatenated together > > without adding spaces." > > > > This RFC 2119 MUST is also in RFC 4408. I suggest removing the > > "MUST" in the example. > >Why? If you don't do it that way, the result is not interoperable. I'll take some text from the Responsible Area Director: "MUSTs are normally instructions for protocol actions or implementation coding". I suggest not using it in examples. > > In Section 4: > > > > "A compliant SPF implementation MUST do something semantically > equivalent > > to this description." > > > > It's unusual to see a "do something" RFC 2119 requirement in a > > specification. Is the SPFBIS WG working on compliance for SPF > > implementations? > >It was added as part of making check_host() not a formal API/functional >specification. You need an equivalent result, but needn't follow >all the steps >exactly. Please recommend an alternative. I suggest fixing the "do something" > > "Implementations MAY use a different algorithm than the canonical > > algorithm defined here, so long as the results are the same in all > > cases." > > > > Why is this a RFC 2119 MAY? I am aware that the text is in RFC 4408. > >trying to make it clear there's flexibility for the implementer. Do >you think >it should be changed? I'll leave this as it is, i.e. no change suggested. > > In Section 4.1: > > > > ' - the domain that provides the sought-after authorization > > information; initially, the domain portion of the "MAIL > > FROM" or "HELO" identity.' > > > > The above text is different from the text in Section 2.4. > >Yes, but not inconsistent with it. I suggest having the definition in one place for consistency. What I am looking at is consistency for the reader instead of where I believe that there is inconsistency. > > In Section 4.3: > > > > "If the is malformed (e.g. label longer than 63 characters, > > zero-length label not at the end, etc.)" > > > > That should be "octets". > >I recall further discussion about this in a later message in the >thread. I'll >address it there. Ok. > > "Properly formed domains are fully qualified email domains as > > described in [RFC5321] Section 2.3.5." > > > > What are "properly qualified email domains"? > >What it says they are in the reference. There was the following comment: "Properly formed domains are described in [RFC5321] Section 2.3.5. The wording is not that good but I could not think of anything better." There was another comment: 'The term "email domain" lacks a formal definition, and is used improperly in Section 4.3 since HELO needs not be an email domain in some sense. I'd s/fully qualified email domains/fully-qualified domain names/.' > > "Internationalized domain names MUST be encoded as A-labels, as > > described in Section 2.3 of [RFC5890].on 2.3 of [RFC5890]." > > > > I'm listing the above and leave it to Area Director guidance. Please > > note that it is a new RFC 2119 requirement. > >It's a new requirement because IDN wasn't addressed in 4408. It's necessary >to address it now and the WG agreed this was the best way to do it. Ok. I am leaving this to the Responsible Area Director. > > In Section 4.4: > > > > "In accordance with how the records are published (see Section 3 > > above), a DNS query needs to be made for the name, querying > > for type TXT only." > > > > I don't understand the sentence. > >What don't you understand? I commented previously about this: "I read the first paragraph of Section 4.4 as meaning that the DNS query is for Type TXT only. I suggest explaining that the record lookup is done by query for the SPF record described in Section 3. By the way, the text you suggested for Section 3 fits in nicely". > > 'Alternatively, for a server failure (RCODE 2) result, check_host() > > MAY track failures and treat multiple failures within 24 hours for > > the same domain as "permerror".' > > > > This text is not in RFC 4408. I found a note in Issue #1 [5] and in > > a message [6]. > >Yes. This is a change to address an operational issue found during SPF >deployment. Stuart mentioned that: "This also solves the TIMEOUT for type 99 problem. Reporting a PermError for a broken name server would be very appropriate (and switching to checking TXT first while said failure is cached would also be permissible)". John commented that: "Not that I'm aware of. That looks to me like an optimization to do in the DNS cache, not in the client". In a previous comment I mentioned that: "Are there any implementations that do this? If so, that's the justification; it's practical experience. If not, we should consider dropping it". > > In Section 4.6.2: > > > > "If there are no more mechanisms, the result is specified in > > Section 4.7." > > > > This sentence does not make sense. > >If I changed it to "If there are no more mechanisms, the result is >the default >result as described in section 4.7" would it be clearer? The follow text was proposed in a comment: "After all mechanisms have been processed and no matches are found, the result is determined according to Section 4.7." > > > > In Section 4.6.4: > > > > "SPF implementations MUST limit the total number of mechanisms and > > modifiers ("terms") that cause any DNS query to at most 10 during SPF > > evaluation." > > > > This was discussed on the mailing list [7]. > > > > "If this number is exceeded during a check, a permerror MUST be > > returned." > > > > I read this as if an implementation-specific limit is reached a > > permerror is returned. There are two RFC 2119 MUST in the > > above. That can be reduced to one MUST. > >Is there a problem with it the way it is? Here is my previous comment: For context we are at Section 4.6.4. I'll quote some text from it: "If this number is exceeded during a check, a permerror MUST be returned." 'If this limit is exceeded, the "mx" mechanism MUST produce a "permerror" result.' 'If this limit is exceeded, all records other than the first 10 MUST be ignored.' I prefer not to discuss about the last one (see quoted text) again. In terms of coding it is easier if I am told to return a "permerror" results when DNS limit X is exceeded. That can be specified with one RFC 2119 MUST. I am taking in consideration the SecDir recommendation and interoperability. Speaking of interoperability the following text: 'SPF implementations MUST limit the total number of mechanisms and modifiers ("terms") that cause any DNS query to at most 10 during SPF evaluation.' does not encourage it because of the "at most". Section 4.6.4 does not make things easier for DNS operations as the reader cannot identify the limits easily due to the exceptions. I am ok with the exceptions. What I am suggesting is not to use two RFC 2119 MUST if it there is a way for it to be done with one RFC 2119 MUST. > > I read the first paragraph of Section 4.6.4. I am not sure how the > > absolute requirement will be interpreted by the reader. > >We worked on making it clearer. If you have suggested improvements, please >send them. Could you please provide the proposed text? > > 'MTAs or other processors SHOULD impose a limit on the maximum amount > > of elapsed time to evaluate check_host(). Such a limit SHOULD allow > > at least 20 seconds. If such a limit is exceeded, the result of > > authorization SHOULD be "temperror".' > > > > There are three RFC 2119 SHOULDs in the above. I suggest rewriting > > the text to reduce that. > >They are three different things. Why would rewriting it help? Here is my previous comment: Throughout the document the words "MTA", "other processors", "mail receivers", "SPF implementations" and "SPF verifiers" are used. That looks inconsistent to me. Here's an example of a rewrite: MTA or other processors SHOULD: (a) impose a limit on the maximum amount of elapsed time to evaluate check_host(). (b) allow for at least 20 seconds. (c) return a result of authorization of "temperror". I don't see what Points (a) or (b) has to do with interoperability. Trying to common factor the RFC 2119 SHOULD reduces occurrences of the word instead of addressing the issue. I suggest understanding the intent first before working on the text to be added. Alessandro and Murray did not agree with the above. > > 'SPF implementations SHOULD limit "void lookups" to two.' > > > > What are void lookups? > >The term is defined in the two immediately preceding sentences. Ok. > > "In this case, a default of two is RECOMMENDED." > > > > Why is "two" recommended? > >Because that's the limit that is currently widely deployed (in the perl >Mail::SPF implementation) with which there has been good experience. Ok. > > 'Note that records SHOULD always use either a "redirect" modifier or > > an "all" mechanism to explicitly terminate processing.' > > > > Why is there a RFC 2119 key word in a note? > >Took out the 2119 word. Ok. > > In Section 4.8: > > > > 'e.g., "foo..example.com") or overlong labels (more than 63 > > characters).' > > > > I suggest octets. > > > > in Section 5: > > > > 'SPF implementations on IPv6 servers need to handle both "AAAA" and "A" > > secords, for clients on IPv4 mapped IPv6 addresses [RFC4291].' > > > > There is a typo, "records". > >Already fixed. Ok. > > I'll flag the above for review by people with IPv6 expertise. > >What's in -15 is the result of the review and WG feedback. As a note for the working group, Simon Perreault proposed text about this. > > In Section 5.4: > > > > 'Note regarding implicit MXs: If the has no MX records, > > check_host() MUST NOT pretend the target is its single MX, and MUST > > NOT default to an A or AAAA lookup on the directly.' > > > > There are two RFC 2119 MUSTs in the above. This is over-usage of RFC > > 2119 key words. This text was in RFC 4408. This is not a divergence > > from RFC 5321, it is a contrary to Section 5 of RFC 5321. > >It's not contrary. It's saying that aspect of 5321 is not relevant to SPF. >In any case, changing it would be a substantiative change to the >protocol that >would require all implementations to be updated. There are changes listed in Appendix C. Implementations will have to be updated anyway in my opinion. I'll discuss this matter with the Responsible Area Director. > > In Section 5.5: > > > > "This mechanism SHOULD NOT be used." > > > > I suggest providing a reason for this. > >The reason is given in the note at the end of the section. The following text was suggested: "This mechanism SHOULD NOT be used it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the .arpa name servers." > > "To prevent DoS attacks, more than 10 PTR names > > MUST NOT be looked up during the evaluation of a "ptr" mechanism > > (see Section 4.6.4)." > > > > The above restates a previous RFC 2119 MUST. > > > > "If used, proper PTR records MUST be in place for the domain's hosts > > and the "ptr" mechanism SHOULD be one of the last mechanisms checked." > > > > Those RFC 2119 key words are not in RFC 4408. I don't see how this > > RFC 2119 change qualifies as a clarification or explanation. > >For the MUST, it flat out won't work if you don't have those (no >interoperation). For the SHOULD, it's an optimization. We can change it if >you want. My previous comment was that: "It's a change. I suggest reverting it. Telling people who are using the "ptr" mechanism that they must have PTR records is stating the obvious". > > "It is, however, still in use and part of the SPF protocol, so compliant > > check_host() implementations MUST support it." > > > > What is a compliant check_host() implementation? > >One that works in accordance with 4408bis. Please suggest an alternative if >you don't like that. I am ok with what the working group wants. > > In Section 5.6: > > > > "ip6-network = " > > > > I suggest that the above reference be verified for correctness. > > > > In Section 5.7: > > > > 'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all' > > > > I'll flag this for review by DNS folks. > > > > In Section 6: > > > > 'The modifiers defined in this document ("redirect" and "exp") MAY > > appear anywhere in the record, but SHOULD appear at the end, after > > all mechanisms.' > > > > This text is in RFC 4408. I would label the RFC 2119 usage as defective. > >Why? My previous comment was: "The text tells me that it is ok if the modifiers appear anywhere but they should appear at the end after all mechanisms. It would be clearer to say that it should appear after all mechanisms". > > In Section 6.2: > > > > "Since the explanation string is intended for an SMTP response and > > [RFC5321] Section 2.4 says that responses are in [US-ASCII], the > > explanation string MUST be limited to US-ASCII.' > > > > It would be easier to defer to RFC 5321 instead of setting a RFC 2119 > > requirement in this draft. I note that this requirement was not in RFC > > 4408. > >It's not a new requirement. If you couldn't find it in 4408, then that means >we've succeeded in making the actual requirement more clear. None of the WG participants have pointed out where the actual requirement (RFC "MUST") is in RFC 4408. If the text was in RFC 4408 it would be possible for a WG participant to point me to it. There was a comment about 'this could be expressed non-normatively (e.g. "needs to be")'. > > "Software SHOULD make it clear that the explanation string > > comes from a third party." > > > > I could not understand what that means in RFC 2119 terms. The draft > > uses RFC 2119 key words by example instead of providing an explanation. > >I don't understand the comment. There was a comment from Murray: "we're talking about interoperability between humans here, and not between implementations". > > In Section 7.1: > > > > 'The "toplabel" construction is subject to the LDH rule plus > > additional top-level domain (TLD) restrictions.' > > > > Where can I find these restrictions? Please note that I have read > > the Informational RFC. > >LDH + non-numeric as the RFC says. I'll get back to this issue. > > In Section 7.3: > > > > "-exists:%(ir).sbl.spamhaus.example.org" > > > > I commented about vendor-neutral previously [8]. The above is a way > > to get around the objection [9]. I suggest cleaning this up. > >Took spamhaus out. Ok. > > "so trailing dots SHOULD NOT be published by domain owners" > > > > Why is it "domain owners"? > >Took out everything after published. Ok. > > "This macro SHOULD NOT be used. See Section 5.5 for the discussion > > about why not." > > > > This comes out as a flippant explanation for the RFC 2119 SHOULD. > >Please recommend non-flippant text then. It doesn't read that way to me. "This macro SHOULD NOT be used (See Section 5.5 for discussion). > > "This SHOULD be a fully qualified domain name, but if one does not > > exist (as when the checking is done by a MUA) or if policy restrictions > > dictate otherwise, the word "unknown" SHOULD be substituted." > > > > The RFC 2119 key words are in RFC 2119. I don't know what to say. > >OK. Murray comemnted: "I think that looks fine as-is, though we could change the first SHOULD to "ought to" because it's a transformation of other input and not an implementation choice. (And I assume you mean they were in RFC4408.) > > "When the result of macro expansion is used in a domain name query, if > > the expanded domain name exceeds 253 characters (the maximum length > > of a domain name), the left side is truncated to fit, by removing > > successive domain labels (and their following dots) until the total > > length does not exceed 253 characters." > > > > Where is it specified that the maximum length of a domain name is 253 > > characters? > >This was covered in someone else's response. Ok. > > "Care has to be taken by the sending ADMD so that macro expansion for > > legitimate email does not exceed the 63-character limit on DNS labels." > > > > Where is that 63-character limit specified? > >This was covered in someone else's response. Ok. > > It is odd to have RFC 2119 requirements under a "Notes" heading. > >They aren't really notes in that sense. If you have a better name for the >section, please suggest. I suggest removing all the RFC 2119 requirements in Section 7.3 if the working group cannot find a way to fix this. > > In Section 8.2: > > > > 'A "neutral" result MUST be treated exactly like the "none" result; > > the distinction exists only for informational purposes.' > > > > Why is an existing RFC 2119 restated? > >Because of the structure of the document that the WG came up with. I don't >find a good way to avoid it and not make it less readable. I'll leave this issue open as it was mentioned in the AppsDir review. > > In Section 8.5: > > > > "The domain owner believes the host is not authorized but is not willing > > to make a strong policy statement." > > > > Why is it domain owner? > > Because conversion to the newer terms was incomplete. I clean up this and >some others as well. Ok. > > In Section 9: > > > > "An operator could choose to use both to serve different downstream > > agents. In such cases, care needs to be taken to ensure both fields > > are conveying the same details, or unexpected results can occur." > > > > This has been discussed on the mailing list. I don't think that it > > encourages interoperability but the working group decided otherwise [10]. > > > > In Section 9.1: > > > > "The Received-SPF header field is a trace field (see [RFC5322] Section > > 3.6.7) and SHOULD be prepended to the existing header, above the > > Received: field that is generated by the SMTP receiver." > > > > "prepended to the existing header" does not sound right. > >I believe it is. Murray explained this in a comment about the review. > > "It MUST appear above all other Received-SPF fields in the message." > > > > How does this fit into the previous RFC 2119 SHOULD? > >It will generally happen as a natural result of following the previous one, >but is there in case more than one is added by a single MTA. Murray commented on this. > > in Section 10: > > > > "This section is not a "how-to" manual, or a "best practices" document, > > and it is not a comprehensive list of what such entities SHOULD do in > > light of this document." > > > > What is the meaning of the RFC 2119 SHOULD in the above? > >Got rid of it. Ok. > > > > In Section 10.1.1: > > > > There was a comment from Authur Thisell about the table [11] in this > > sub-section. > >There didn't seem to be support for changing it though. I read RFC 4408 and I did not find any table similar to the one in Section 10.1.1 of draft-ietf-spfbis-4408bis-14. My understanding of "support for changing text" is that the text is proposed on the working group mailing list and it is added if there is agreement. I didn't find any messages about that in the mailing list archives. What I found was a message disagreeing with a change which was made in the draft which was posted together with an explanation about why there was disagreement. In my opinion there wasn't any support for making that change in the draft. > > In Section 10.1.2: > > > > "Publishing SPF records for domains that send no mail is > > a well established best practice." > > > > I am not aware of that best practice. I did a few DNS queries: > > > > ;; QUESTION SECTION: > > ;bing.com. IN TXT > > > > ;; ANSWER SECTION: > > bing.com. 3600 IN TXT "v=msv1 > > t=6097A7EA-53F7-4028-BA76-6869CB284C54" > > > > ;; QUESTION SECTION: > > ;com.com. IN TXT > > > > ;; ANSWER SECTION: > > com.com. 293 IN TXT > > "google-site-verification:esSnoZdChIkkfCfS9MMgqNhE0yaXfnnZWdZPuBf7e8k" > >OK. See >http://www.bits.org/publications/security/BITSEmailAuthenticationFeb2013.pdf I suggest "good practice" as mentioned by Alessandro. > > In Section 10.1.3: > > > > "SPF functionality is enhanced by administrators ensuring this > > identity is set correctly and has an appropriate SPF record." > > > > How is SPF functionality enhanced? > >If there's an SPF record for HELO as well as Mail From, then a check can be >performed on bounces. Ok. > > In Section 10.2: > > > > "As stated elsewhere in this document, there is no normative requirement > > for specific handling of a message based on any SPF result." > > > > The "as stated elsewhere" is vague. > >It comes up multiple places. Adding several specific reference won't improve >the draft. I suggest adding a reference to Section 8 (subject to the AppsDir review being addressed). > > 'The primary considerations are that SPF might return "pass" for mail > > that is ultimately harmful (e.g., spammers that arrange for SPF to > > pass using nonsense domain names' > > > > What are "nonsense" domain names? > >There was follow-on discussion about this. "discardable" was suggested. > > In Section 10.3: > > > > "The mediator can make the newly-posted message be as similar or as > > different from the original message as they wish." > > > > The sentence seems incomplete, i.e. similar to what. > >The original message. Ok. > > "For the operation of SPF, the essential concern is the email > > address in the 5321.MailFrom command for the new message." > > > > What does this mean? > >It means that's the thing that's the most important. Ok if the working group agrees. > > 'Because SPF evaluation is based on the IP Address of the "last" > > sending SMTP server, the address of the mediator will be used, rather > > than the address of the SMTP server that sent the message to the > > mediator.' > > > > I'll note that this is a mix of RFC 5321 and RFC 5598. The result is > > clear or unclear depending on the background of the reader. > >I guess I have the background for it to be clear. Please suggest an >improvement. I suggest leaving it as it if there isn't any disagreement. > > In Section 11.5: > > > > "An SPF compliant receiver gathers information from the SMTP commands > > it receives and from the published DNS records of the sending domain > > holder" > > > > I suggest explaining the untrusted part. > >That's what the section does. There was a comment: "A second sentence indicating most of that input is unverified is probably in order, with references if possible". > > In Section 11.6: > > > > "Checking SPF records causes DNS queries to be sent to the domain > > owner." > > > > How are DNS queries sent to domain owners? > >Fixed it. Ok. > > Section 12: > > > > I note that Murray S. Kucherawy has contributed significantly to > > draft-ietf-spfbis-4408bis. If I am not mistaken it is IETF practice > > to acknowledge such contributions. I don't recall who sent text at > > the moment. If you did, please send an (off-list) email to the > > SPFBIS WG Chairs. > >There are many, many people who contributed to both 4408 and 4408bis that >aren't listed. If someone wants to make a list of people who made a >significant contribution, I'll be glad to include it. My understanding is that it is the task of the document editor to keep track of contributions and contributors. There is a message at http://www.ietf.org/mail-archive/web/spfbis/current/msg03059.html where it is mentioned that: "2. Scott, in collaboration with Murray Kucherawy (who proposed the original reorganization), undertakes the reorganization and creates the next WG document." > > In Section 13.2: > > > > "Per [RFC3864], the "Received-SPF:" header field is added to the IANA > > Permanent Message Header Field Registry." > > > > Note to self: request removal from the provisional message header > > field registry. > > > > The "status:" should be "standard" > >Not Standards Track? I verified this again; it's "standard". > > In Section 13.3: > > > > "Their status should not be changed." > > > > I suggest "Their status is unchanged". BTW, it should be "SPF > > Modifier Registry". > >Fixed Ok. > > I suggest following RFC 6652 Section 5.1. > > > An "Updates:" for RFC 6652 may be needed. > >Why? It's the registry that gets updated, not 6552. I'll ask the Area Director. > > > > References: > > > > Why is RFC 1123 a normative reference? > >See section 2.4. Ok. > > > > Why is RFC 3864 a normative reference? > >Because it defines how the Received-SPF registration is done. Ok. > > Where can I find "Designated Mailers Protocol"? > >See draft-fecyk-dsprotocol Ok. As a note for the working group, I could not find the draft. > > > > Where can I find "Domain-Authorized SMTP Mail"? > >I don't have a copy of this. I suggest dropping the reference. > > In Appendix C: > > > > In Section E.1: > > > > 'This would cause a lookup on an DNS white list (DNSWL) and cause a > > result of "fail" only for email not either coming from the > > domain's mx host(s) (SPF pass) or white listed sources (SPF > > neutral).' > > > > I didn't find any discussion about this on the SPFBIS mailing > > list. is there an explanation for this change between RFC 4408 and this > > draft? > >It was pointed out that this is a white list, not a black list. I suggest dropping this change as it was not discussed within the working group. > > I note that there are 48 pages in RFC 4408. There are 78 pages in > > this draft. A significant amount of text has been added in the > > Appendix (over 20 pages). I doubt that the text has been carefully > > reviewed. I may be asked for an explanation about all that once the > > draft leaves this working group. > >Why wait? I am not the person doing the IESG evaluation. > > In Appendix I: > > > > Appendix I is about "Protocol Status". This draft is intended as a > > Proposed Standard. From an IETF perspective that is what it will > > be. Describing it as something different can be misleading. > > > > "[RFC4408] was designed to clearly document the protocol defined by > > earlier draft specifications of SPF as used in existing > > implementations. This updated specification is intended to clarify > > identified ambiguities in [RFC4408], resolve techincal issues > > identified in post-RFC 4408 deplyment experience, and document widely > > deployed extensions to SPF that have been developed since [RFC4408] > > was published." > > > > Extensions to the SPF protocol are clearly mentioned in the charter > > as being out of scope. The "document widely deployed extensions" is > > problematic. > >The charter specifically allows for "addition of any enhancements >that have already gained widespread support". I read the discussion about the charter again. It is my understanding that extensions to the SPF protocol is out-of-scope. The working group did not add a work item during the chartering discussion as it was considered as an extension to the protocol. > > "This document updates and replaces RFC 4408 that was part of a group > > of simultaneously published Experimental RFCs (RFC 4405, RFC 4406, > > RFC 4407, and RFC 4408) in 2006. At that time the IESG requested the > > community observe the success or failure of the two approaches > > documented in these RFCs during the two years following publication, > > in order that a community consensus could be reached in the future." > > > > Why is this needed? The SPFBIS WG produced RFC 6686 to resolve the > > experiment. > >Since this is what obsoletes 4408, not everyone will read 6686. There is an informative reference to RFC 6686. I don't see why the text mentioned above is needed. > > "SPF is widely deployed by large and small email providers alike. > > There are multiple, interoperable implementations." > > > > Someone might point out that this is marketing instead of text > > relevant to a protocol. I'll mention that one or more significant > > issues (e.g. Issue #9) was identified during the WG > > discussions. Issue #9 was not listed as the errata. I suggest > > removing the section as it will be less text and there is already two > > informative references to help the reader find background information. > >#9 has been known since before 4408 was published. In 2005 it was the price >of admission to the IETF. My suggestion as document shepherd is to avoid that discussion. The draft will face a very difficult Last Call as it is and more controversies won't make matters any better. Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Thu May 16 19:46:06 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD8C21F8EAE for ; Thu, 16 May 2013 19:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svMiqKVwNt9n for ; Thu, 16 May 2013 19:46:05 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0F421F8E4C for ; Thu, 16 May 2013 19:46:05 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.148.174]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4H2jglU021031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 May 2013 19:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1368758760; bh=RGPUvcxbisVqZ8ULf5OeBoooaimjx1W0ZGYxKUH694Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xIvo/BGCM+BPsWUNK9e4NRaxzNLUlrWx9JEogEtMTXRMnJZtWoVHGZnLjDdz1HQBm TlVnt9lKvY4mXZMFLLTkAoORQ6hywaeO0YugkHmNyxN1TWZQu53ul9jCyYyYdIksWE MZalUoWpURNjh+ZMaftUURrMaAETPBzJQGeVtdsM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1368758760; i=@elandsys.com; bh=RGPUvcxbisVqZ8ULf5OeBoooaimjx1W0ZGYxKUH694Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xi3pgG9u/X4JrowaMKYUupGrZDDecqj4dtp0lzFNpVTXru0alQlxTEVrBlM5WxaCS 9Dd8ZmUvOFxyzPP3jIuRSFPAlSuxiUn+CKQnSZLLPQ/InZ91syFWtURva5B3YRShUL wrNZDTBa3lxSZlCI/yoVy2pcdYxoMKTcWhurJoqc= Message-Id: <6.2.5.6.2.20130516193913.0c7b4ab0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 16 May 2013 19:45:13 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Douglas Otis Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 02:46:06 -0000 At 18:08 16-05-2013, Douglas Otis wrote: >An I-D has been submitted offering a review of the SPFbis draft. > >http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-00 > >Sorry for the delay in preparing this document. There was a fair >amount of botnet activity requiring a fair amount of attention. There are still some previous reviews to address. I am waiting for that to be done. I suggest that the working group does not discuss about draft-otis-spfbis-macros-nixed-00 for now. Please note that the comments in draft-otis-spfbis-macros-nixed-00 are not being ignored. Regards, S. Moonesamy (as SFBIS WG co-chair) From marka@isc.org Thu May 16 20:02:41 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D5F11E80F1 for ; Thu, 16 May 2013 20:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoUpqX7h9dJu for ; Thu, 16 May 2013 20:02:40 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 06D1F11E80A3 for ; Thu, 16 May 2013 20:02:39 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 9A74AC958E; Fri, 17 May 2013 03:01:52 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1368759756; bh=GEsE9tTFHOiskvv/zmIlQoaex0K+GRgZgK1M4DO+Wok=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=obEB4qlf2Ind9wtcfjy4VBCo/qoTVTX36bTGkSLb6fp4gYxdOXbavmJmfII9sgZme iX06wJBNB+swFRvkjh8bb7TUizaoP76mX2aE7PuVC/eayBeBTuSAaIczG43YLpOBz/ 6IPgvGqFHme/Azmsgl67VMBOPslUm+kJU7vQFJHE= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Fri, 17 May 2013 03:01:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B45F5216C43; Fri, 17 May 2013 03:01:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 818D4346C0D1; Fri, 17 May 2013 13:01:43 +1000 (EST) To: "Murray S. Kucherawy" From: Mark Andrews References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <2724237.eQuNQK5KLA@scott-latitude-e6320> <20130516215423.7E55F3460DEC@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 16 May 2013 17:28:14 -0700." Date: Fri, 17 May 2013 13:01:43 +1000 Message-Id: <20130517030143.818D4346C0D1@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 03:02:41 -0000 In message , "Murray S. Kucherawy" writes: > --001a11c262e808006a04dcdf0f17 > Content-Type: text/plain; charset=ISO-8859-1 > > On Thu, May 16, 2013 at 2:54 PM, Mark Andrews wrote: > > > > > What is a valid fully qualified domain? > > > > > > Would s/domain/domain name/ clear it up for you? > > > > "com" is a fully qualified domain. Multi-label domain is the term > > being looked for. > > Interesting. What would be an example of something that a domain name but > isn't a fully-qualified domain name? foo in foo.bar.example.net foo.bar in foo.bar.example.net foo.bar.example in foo.bar.example.net foo is unqualified foo.bar is partially qualified foo.bar.example is partially qualified Now w.r.t. SMTP HELO/EHLO you have no way of determining if a name is partially qualified or not. Additionally there isn't any reliable way to qualify a name if you could. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From spf2@kitterman.com Thu May 16 23:37:56 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9C321F9344 for ; Thu, 16 May 2013 23:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UvIgUBaUSUx for ; Thu, 16 May 2013 23:37:42 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9E98121F91D8 for ; Thu, 16 May 2013 23:37:41 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8472D20E411A; Fri, 17 May 2013 02:37:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368772660; bh=tw5kCxsWtyDLbdfI5/CZ6ISZ37K9XxwmNf5obzJ0ARk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=URd68VQ8bC/znr11EZEbHD+4UbntBed3WU+QdztInKmNa7xwsrr+zXC7lkExh9OfZ HIbrCDY6B9BHgiPqESaC8gS/YQf3we3ajbNfXmn+MrESHMltJPD1f4eqduiVpRPDSu 3mNzwabPRHWE+WZgiAKBHgjpQEFdHXhvIyi0O51E= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3746B20E40C6; Fri, 17 May 2013 02:37:39 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 02:37:39 -0400 Message-ID: <1972467.x8au6JTDZS@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130516154521.06ceef08@resistor.net> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <2724237.eQuNQK5KLA@scott-latitude-e6320> <6.2.5.6.2.20130516154521.06ceef08@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 06:37:56 -0000 On Thursday, May 16, 2013 06:36:14 PM S Moonesamy wrote: > Hi Scott, > > Murray Kucherawy, Alessandro Vesely, John Levine and Stuart Gathman > commented about this review. I'll cover these comments in my > response. By the way if I missed any of the comments please let me know. > > I'll follow the guidance in the message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg03642.html for > RFC 2119 key words. > > At 14:45 16-05-2013, Scott Kitterman wrote: > > > "This SPF check can only be performed when the "HELO" string is a > > > > > > valid fully qualified domain." > > > > > > What is a valid fully qualified domain? > > > >Would s/domain/domain name/ clear it up for you? > > I'll suggest the following: > > This SPF check can only be performed when the "HELO" string is a > fully-qualified domain name. Done. > > > In Section 2.2: > > > 'SPF verifiers MUST check the ""MAIL FROM" identity if a completed > > > > > > "HELO" check has not reached a definitive policy result by applying > > > the check_host() function to the "MAIL FROM" identity as the > > > .' > > > > > > As a note this RFC 2119 MUST is already in RFC 4408. > > > > > > In Section 2.3: > > > "An SPF-compliant domain MUST have valid SPF records as described in > > > > > > Section 3." > > > > > > As a note the RFC 4408 text is: > > > "An SPF-compliant domain MUST publish a valid SPF record as described > > > > > > in Section 3." > > > > > > The RFC 2119 MUST is redundant. > > > >Is there a reason to change it? > > From a previous comment: > > 'In a recent conversation, Pete described this as "not really wrong, but > it's shouting." I guess that means changing "MUST publish" to > "publishes" or something like that. > > I am ok with the "publishes".' > > I suggest using that. Done. > > > 'If domain owners choose to publish SPF records and want to support > > > > > > receivers making negative authorization determinations, then they > > > MUST > > > publish records that end in "-all", or redirect to other records > > > that > > > > > > do, otherwise, no definitive determination of authorization can be > > > made.' > > > > > > The document uses ADMD while there is "domain owners" in the > > > above. I suggest reviewing that. > > > >Changed > > > > > The RFC 2119 MUST is a substantive change. Why is this a MUST? > > > >Because it's the literal truth. That's what you have to do to achieve that > >result. You won't interoperate with receivers in that way effectively if > >you don't. > > I mentioned this in another message: > > Andrew Sullivan, as an individual, commented about the text ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02784.html > ). I suggest going with what was suggested or else the working > group will be discussing Issue #33 again. OK. I still find it confusing that things that are needed for the protocol to function are not considered requirements, but changed. > > > In Section 2.4: > > > 'At least the "MAIL FROM" identity MUST be checked, but it > > > > > > is RECOMMENDED that the "HELO" identity also be checked beforehand.' > > > > > > There is already a RFC 2119 MUST in Section 2.2. There is also a RFC > > > 2119 RECOMMENDED in Section 2.1. The above text restates existing > > > RFC 2119 requirements or recommendations. > > > >Modified to make them non-redundant. > > I suggest including the proposed text for any changes so that the > working group is aware of the text will be added to the revision of the > draft. That's not always easy to do. In this case, it would be hard to evaluate out of context, so I think it's best to wait for the next revision. > > > 'Without explicit approval of the domain owner, checking other > > > > > > identities against SPF version 1 records is NOT RECOMMENDED because > > > there are cases that are known to give incorrect results.' > > > > > > How should this explicit approval be sought? This recommendation > > > does not make sense. > > > >What I have now is "Documents that define other identities will have > >to define > >the method for explicit approval." > > "out-of-band" or "private" was suggested. I'll use one of them (I do > not have any preference): > Without out-of-band approval of the ADMD, checking other identities > against SPF version 1 records is NOT RECOMMENDED because there are > cases that are known to give incorrect results. I don't think that's correct. One could get a new modifier added to the SPF modifier registry that would indicate a record can be used for other purposes. There are no such other purposes defined at the moment, but there's absolutely no need for out-of-band/private methods to accomplish this goal. > > > In Section 2.4: > > > 'When a mail receiver decides to perform an SPF check, it MUST use a > > > > > > correctly-implemented check_host() function (Section 4) evaluated > > > with the correct parameters.' > > > > > > This RFC 2119 requirement states the obvious. It basically says that > > > there is a requirement in draft-ietf-spfbis-4408bis-14 to use a > > > correct implementation of draft-ietf-spfbis-4408bis-14. > > > >This was changed already due to other comments. I think it makes sense > >now. Please check when -15 is published. > > The comment I read on the mailing list is: > > "I agree, that sentence can probably go." > > The other comment was from Alessandro. Does your comment mean that > the sentence will be removed or does it mean that text is being proposed? It means it was changed based on other comments. Please look at -15 and see if you still think it's a problem. > > > 'Although invalid, malformed, or non-existent domains cause SPF > > > checks > > > > > > to return "none" because no SPF record can be found, it has long > > > been > > > the policy of many MTAs to reject email from such domains, > > > especially > > > in the case of invalid "MAIL FROM". Rejecting email will prevent > > > one > > > method of circumventing of SPF records.' > > > > > > This text is already in RFC 4408. > > > > > > "Implementations have to take care to correctly extract the > > > > > > from the data given with the SMTP MAIL FROM command as many MTAs > > > will > > > still accept such things as source routes ..." > > > > > > The definition of is: > > > 'the domain portion of the "MAIL FROM" or "HELO" identity.' > > > > > > I am not sure whether it is even a definition. From an > > > implementation perspective the last paragraph of Section 2.4 is unclear. > > > >It seems clear to me. Could you expand on why you think it's problematic > >or provide recommended text. > > I mentioned in a previous comment that " definitions (not > sure whether it is a definition) are mentioned in two places. I > suggest fixing that and then getting back to the above". I don't understand what you think is wrong. Repeating the comment won't help. I did read it. I don't understand it. > > > 'Generating non-delivery notifications to forged identities that have > > > > > > failed the authorization check is a source of backscatter and SHOULD > > > be avoided.' > > > > > > This RFC 2119 SHOULD is not in RFC 4408. The above does not have > > > anything to do with Sender Policy Framework. It was mentioned during > > > WG discussions that "SPF can help the backscatter problem" [2]. This > > > text may have been introduced in response to a review [3]. Is this > > > an enhancement or a clarification? > > > >It's a clarification. > > In a previous comment I mentioned that "my reading of the above is > that it is neither an enhancement or a clarification. I suggest > removing the text". So you think it's not something that should be avoided? > > > In Section 2.6.1: > > > 'A result of "none" means either (a) no syntactically valid DNS > > > domain > > > > > > name was extracted from the SMTP session that could be used as the > > > one to be authorized, or (b) no TXT records were retrieved from the > > > DNS that appeared to be intended for use by SPF verifiers.' > > > > > > I suggest "DNS TXT records". What is a syntactically valid DNS > > > domain name? The definition of "none" in RFC 4408 is clear (to me). > > > >How could one retrieve anything other than DNS TXT records from the > >DNS? That > >seems redundant since it says "retrieved from the DNS". > > I left this DNS angle for Andrew to comment. OK. > > > In Section 2.6.7: > > > 'A "permerror" result means the domain's published records could not > > > > > > be correctly interpreted. This signals an error condition that > > > definitely requires manual intervention to be resolved.' > > > > > > What is "manual intervention" in the above? > > > >Would operator intervention or operator action be better? > > I suggest "operator intervention" (there was a comment about this). OK. Changed. > > > In Section 3: > > > 'An SPF record is a DNS record that declares which hosts are, and are > > > > > > not, authorized to use a domain name for the "HELO" and "MAIL FROM" > > > identities.' > > > > > > How are hosts which are not authorized to use a domain name listed in > > > a SPF record? > > > >If a record contains something like -a:host.example.com that host is > >explicitly not authorized. > > Ok. > > > > "The SPF record is a single string of text." > > > > > > What is a single string of text? It may be easier to state this in > > > terms of record format. > > > >I think this was addressed in a later comment and it should be improved. > > There was a suggested text: > > "An SPF policy statement is expressed as a single string of text encoded > in a DNS TXT record." > > and: > > "The SPF record is a variable length string of octets encoded in > a DSN TXT record." I split the difference and put in: The SPF record is expressed as a single string of text encoded in a DNS TXT record. > > > 'ADMDs publishing SPF records SHOULD try to keep the number of > > > > > > "include" mechanisms and chained "redirect" modifiers to a minimum.' > > > > > > What is the minimum? Note that this RFC 2119 SHOULD is in RFC 4408. > > > >It's the least an ADMD needs to properly describe the hosts > >authorized to send > >mail from their domain. It's minimum in the sense of no more than needed. > > I commented previously about this "I didn't understand that as there > wasn't any explanation for the RFC 2119 SHOULD. I suggest adding an > explanation or rewriting the text so that the expression (see above) > is clear". I'm failing to understand how to clarify that use the minimum means use as little as you can. It's basically just explaining the dictionary to the reader, so I think I don't understand what you think needs changing. > > > 'ADMDs SHOULD also try to minimize the amount of other DNS > > > information > > > > > > needed to evaluate a record.' > > > > > > This RFC 2119 SHOULD is also in RFC 4408. There are two RFC 2119 > > > SHOULDs in the last paragraph of Section 3. This usage of RFC 2119 > > > key words does not help the SPF "publisher". In my opinion the > > > "SHOULD try" in this context uses the RFC 2119 key word in unorthodox > > > ways. > > > >I took try out of the section. I think that should do it. > > There was a comment that: > > "SHOULD minimize" conflicts with one intended use, namely > > v=spf1 redirect=_spf.example.com > > Exemplified in Section 6.1, that use does not attain the minimum. If it makes sense to use the redirect then that's the minimum. If we truly wanted the absolute minimum physically possible, we'd only have ip4, ip4, and maybe include mechanisms. I don't think there's a conflict. > > > In Section 3.1: > > > 'SPF records MUST be published as a DNS TXT (type 16) Resource Record > > > > > > (RR) [RFC1035] only.' > > > > > > I would ask why "MUST be published ... only". By the way, Section 3 > > > has a reference to Section 4 for record format instead of Section > > > 3.1. Is that correct? > > > >The only is to make it clear that the Type SPF records that were > >defined in RFC > >4408 are no longer part of the protocol. It is correct. The ABNF for the > >record format is in section 4. > > There were two comments: > > "The reference is indeed incorrect." > > and: > > 'Should we say "is described along with its interpretation in Section > 4.5"? How about changing the title of Section 4.5 to "Record Format"?' Changing the title to Record Format would be wrong because it's not just the format. I changed it to "The record format and the process for selecting records is described in ..." > > > In Section 3.2: > > > "A domain name MUST NOT have multiple records that would cause an > > > > > > authorization check to select more than one record." > > > > > > This RFC 2119 MUST NOT was in RFC 4408. Is this to help the SPF > > > "publisher" and if so, how does it help? > > > >4408 has an implicit requirement for this. In section 4.5, it says: > > > If the resultant record set includes more than one record, check_host() > > > produces the "permerror" result. > > > >The MUST NOT here makes it clear the condition has to be > >avoided. It's not a > >functional change in the protocol. > > Ok. > > > > In Section 3.3: > > > "As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS > > > > > > record can be composed of more than one string." > > > > > > See previous comment about " a single string". > > > > > > "If a published record contains multiple character-strings, then the > > > > > > record MUST be treated as if those strings are concatenated together > > > without adding spaces." > > > > > > This RFC 2119 MUST is also in RFC 4408. I suggest removing the > > > "MUST" in the example. > > > >Why? If you don't do it that way, the result is not interoperable. > > I'll take some text from the Responsible Area Director: > > "MUSTs are normally instructions for protocol actions or > implementation coding". > > I suggest not using it in examples. OK. I changed it to "is equivalent to:" > > > In Section 4: > > > "A compliant SPF implementation MUST do something semantically > > > > equivalent > > > > > to this description." > > > > > > It's unusual to see a "do something" RFC 2119 requirement in a > > > specification. Is the SPFBIS WG working on compliance for SPF > > > implementations? > > > >It was added as part of making check_host() not a formal API/functional > >specification. You need an equivalent result, but needn't follow > >all the steps > >exactly. Please recommend an alternative. > > I suggest fixing the "do something" OK. I changed it to produce results. > > > "Implementations MAY use a different algorithm than the canonical > > > > > > algorithm defined here, so long as the results are the same in all > > > cases." > > > > > > Why is this a RFC 2119 MAY? I am aware that the text is in RFC 4408. > > > >trying to make it clear there's flexibility for the implementer. Do > >you think > >it should be changed? > > I'll leave this as it is, i.e. no change suggested. > > > > In Section 4.1: > > > ' - the domain that provides the sought-after authorization > > > > > > information; initially, the domain portion of the "MAIL > > > FROM" or "HELO" identity.' > > > > > > The above text is different from the text in Section 2.4. > > > >Yes, but not inconsistent with it. > > I suggest having the definition in one place for consistency. What I > am looking at is consistency for the reader instead of where I > believe that there is inconsistency. They are talking about different things relative to domains, so given the organization, I don't see an easy way to do that. I'm open to suggestions. > > > In Section 4.3: > > > "If the is malformed (e.g. label longer than 63 characters, > > > > > > zero-length label not at the end, etc.)" > > > > > > That should be "octets". > > > >I recall further discussion about this in a later message in the > >thread. I'll > >address it there. > > Ok. > > > > "Properly formed domains are fully qualified email domains as > > > > > > described in [RFC5321] Section 2.3.5." > > > > > > What are "properly qualified email domains"? > > > >What it says they are in the reference. > > There was the following comment: > > "Properly formed domains are described in [RFC5321] Section 2.3.5. > > The wording is not that good but I could not think of anything better." > > There was another comment: > > 'The term "email domain" lacks a formal definition, and is used > improperly in Section 4.3 since HELO needs not be an email domain in some > sense. I'd s/fully qualified email domains/fully-qualified domain names/.' OK. I took email out. > > > "Internationalized domain names MUST be encoded as A-labels, as > > > described in Section 2.3 of [RFC5890].on 2.3 of [RFC5890]." > > > > > > I'm listing the above and leave it to Area Director guidance. Please > > > note that it is a new RFC 2119 requirement. > > > >It's a new requirement because IDN wasn't addressed in 4408. It's > >necessary to address it now and the WG agreed this was the best way to do > >it. > Ok. I am leaving this to the Responsible Area Director. > > > > In Section 4.4: > > > "In accordance with how the records are published (see Section 3 > > > > > > above), a DNS query needs to be made for the name, querying > > > for type TXT only." > > > > > > I don't understand the sentence. > > > >What don't you understand? > > I commented previously about this: "I read the first paragraph of > Section 4.4 as meaning that the DNS query is for Type TXT only. I > suggest explaining that the record lookup is done by query for the > SPF record described in Section 3. By the way, the text you suggested > for Section 3 fits in nicely". Sorry, still confused. "I read the first paragraph of Section 4.4 as meaning that the DNS query is for Type TXT only." That's correct, so I think you do understand the sentence. > > > 'Alternatively, for a server failure (RCODE 2) result, check_host() > > > > > > MAY track failures and treat multiple failures within 24 hours for > > > the same domain as "permerror".' > > > > > > This text is not in RFC 4408. I found a note in Issue #1 [5] and in > > > a message [6]. > > > >Yes. This is a change to address an operational issue found during SPF > >deployment. > > Stuart mentioned that: "This also solves the TIMEOUT for type 99 > problem. Reporting a PermError for a broken name server would be very > appropriate (and switching to checking TXT first while said failure > is cached would also be permissible)". > > John commented that: "Not that I'm aware of. That looks to me like > an optimization to do in the DNS cache, not in the client". > > In a previous comment I mentioned that: "Are there any > implementations that do this? If so, that's the justification; it's > practical experience. If not, we should consider dropping it". There was an issue. We discussed possible solutions (my initial hope was to make all SERVFAIL responses permerror) and this was the best solution we came up with. Because we want consistent results across implementations it's not just a local cache optimization. I think we should leave it since I don't want to redo the entire process of solving the issue again. > > > In Section 4.6.2: > > > "If there are no more mechanisms, the result is specified in > > > > > > Section 4.7." > > > > > > This sentence does not make sense. > > > >If I changed it to "If there are no more mechanisms, the result is > >the default > >result as described in section 4.7" would it be clearer? > > The follow text was proposed in a comment: > > "After all mechanisms have been processed and no matches are found, the > result is determined according to Section 4.7." OK, but you didn't answer the question. Would the text I proposed clarify things for you? I like it better than the comment you brought up because I think it's clearer, so I'd prefer to use it if you think it's OK. > > > In Section 4.6.4: > > > "SPF implementations MUST limit the total number of mechanisms and > > > > > > modifiers ("terms") that cause any DNS query to at most 10 during > > > SPF > > > evaluation." > > > > > > This was discussed on the mailing list [7]. > > > > > > "If this number is exceeded during a check, a permerror MUST be > > > > > > returned." > > > > > > I read this as if an implementation-specific limit is reached a > > > permerror is returned. There are two RFC 2119 MUST in the > > > above. That can be reduced to one MUST. > > > >Is there a problem with it the way it is? > > Here is my previous comment: > > For context we are at Section 4.6.4. I'll quote some text from it: > > "If this number is exceeded during a check, a permerror MUST be returned." > > 'If this limit is exceeded, the "mx" mechanism MUST produce a > "permerror" result.' > > 'If this limit is exceeded, all records other than the first 10 > MUST be ignored.' > > I prefer not to discuss about the last one (see quoted text) again. > In terms of coding it is easier if I am told to return a "permerror" > results when DNS limit X is exceeded. That can be specified with one > RFC 2119 MUST. I am taking in consideration the SecDir > recommendation and interoperability. Speaking of interoperability > the following text: > > 'SPF implementations MUST limit the total number of mechanisms and > modifiers ("terms") that cause any DNS query to at most 10 during SPF > evaluation.' > > does not encourage it because of the "at most". Section 4.6.4 does > not make things easier for DNS operations as the reader cannot > identify the limits easily due to the exceptions. I am ok with the > exceptions. What I am suggesting is not to use two RFC 2119 MUST if > it there is a way for it to be done with one RFC 2119 MUST. They are different limits that you have to code differently, so I think combining them would reduce clarity for implementers. > > > I read the first paragraph of Section 4.6.4. I am not sure how the > > > absolute requirement will be interpreted by the reader. > > > >We worked on making it clearer. If you have suggested improvements, please > >send them. > > Could you please provide the proposed text? No, I don't have any more proposed text. I was saying the WG has already worked over trying to clarify this section. I think we've done our best, to clearly express something that is complicated. I don't think "do it better" is going to result in further improvements, so if you have an idea how to improve it, please provide it. > > > 'MTAs or other processors SHOULD impose a limit on the maximum amount > > > > > > of elapsed time to evaluate check_host(). Such a limit SHOULD allow > > > at least 20 seconds. If such a limit is exceeded, the result of > > > authorization SHOULD be "temperror".' > > > > > > There are three RFC 2119 SHOULDs in the above. I suggest rewriting > > > the text to reduce that. > > > >They are three different things. Why would rewriting it help? > > Here is my previous comment: > > Throughout the document the words "MTA", "other processors", "mail > receivers", "SPF implementations" and "SPF verifiers" are used. That > looks inconsistent to me. > > Here's an example of a rewrite: > > MTA or other processors SHOULD: > > (a) impose a limit on the maximum amount of elapsed time to > evaluate check_host(). > > (b) allow for at least 20 seconds. > > (c) return a result of authorization of "temperror". I don't find that any clearer, probably less so than what's in the draft now. > > I don't see what Points (a) or (b) has to do with interoperability. > Trying to common factor the RFC 2119 SHOULD reduces occurrences of > the word instead of addressing the issue. I suggest understanding the > intent first before working on the text to be added. They are about defining some consistent limits/expectations in order to avoid both impedance between senders and receivers and the potential security implications of not implementing proper limits. > Alessandro and Murray did not agree with the above. OK. It's from RFC 4408, so I don't think it should be changed: > MTAs or other processors MAY also impose a limit on the maximum > amount of elapsed time to evaluate check_host(). Such a limit SHOULD > allow at least 20 seconds. If such a limit is exceeded, the result > of authorization SHOULD be "TempError". > > > 'SPF implementations SHOULD limit "void lookups" to two.' > > > > > > What are void lookups? > > > >The term is defined in the two immediately preceding sentences. > > Ok. > > > > "In this case, a default of two is RECOMMENDED." > > > > > > Why is "two" recommended? > > > >Because that's the limit that is currently widely deployed (in the perl > >Mail::SPF implementation) with which there has been good experience. > > Ok. > > > > 'Note that records SHOULD always use either a "redirect" modifier or > > > > > > an "all" mechanism to explicitly terminate processing.' > > > > > > Why is there a RFC 2119 key word in a note? > > > >Took out the 2119 word. > > Ok. > > > > In Section 4.8: > > > 'e.g., "foo..example.com") or overlong labels (more than 63 > > > > > > characters).' > > > > > > I suggest octets. > > > > > > in Section 5: > > > 'SPF implementations on IPv6 servers need to handle both "AAAA" and > > > "A" > > > > > > secords, for clients on IPv4 mapped IPv6 addresses [RFC4291].' > > > > > > There is a typo, "records". > > > >Already fixed. > > Ok. > > > > I'll flag the above for review by people with IPv6 expertise. > > > >What's in -15 is the result of the review and WG feedback. > > As a note for the working group, Simon Perreault proposed text about this. There were several suggestions, some of them inconsistent with actual practice experienced by some WG members with real operating systems. I chose to go with the text that supported getting interoperable results regardless of OS. > > > In Section 5.4: > > > 'Note regarding implicit MXs: If the has no MX records, > > > > > > check_host() MUST NOT pretend the target is its single MX, and MUST > > > NOT default to an A or AAAA lookup on the directly.' > > > > > > There are two RFC 2119 MUSTs in the above. This is over-usage of RFC > > > 2119 key words. This text was in RFC 4408. This is not a divergence > > > from RFC 5321, it is a contrary to Section 5 of RFC 5321. > > > >It's not contrary. It's saying that aspect of 5321 is not relevant to SPF. > >In any case, changing it would be a substantiative change to the > >protocol that > >would require all implementations to be updated. > > There are changes listed in Appendix C. Implementations will have to > be updated anyway in my opinion. I'll discuss this matter with the > Responsible Area Director. What is there to discuss? It's NOT a change from 4408? Changing it from what's there now would be out of scope for our charter. > > > In Section 5.5: > > > "This mechanism SHOULD NOT be used." > > > > > > I suggest providing a reason for this. > > > >The reason is given in the note at the end of the section. > > The following text was suggested: > > "This mechanism SHOULD NOT be used it is not as reliable as other > mechanisms in cases of DNS errors, and it places a large burden on the > .arpa name servers." In -14, it already says: > Note: This mechanism is slow, it is not as reliable as other > mechanisms in cases of DNS errors, and it places a large burden on > the .arpa name servers. What should I change? > > > "To prevent DoS attacks, more than 10 PTR names > > > > > > MUST NOT be looked up during the evaluation of a "ptr" mechanism > > > (see Section 4.6.4)." > > > > > > The above restates a previous RFC 2119 MUST. > > > > > > "If used, proper PTR records MUST be in place for the domain's hosts > > > > > > and the "ptr" mechanism SHOULD be one of the last mechanisms > > > checked." > > > > > > Those RFC 2119 key words are not in RFC 4408. I don't see how this > > > RFC 2119 change qualifies as a clarification or explanation. > > > >For the MUST, it flat out won't work if you don't have those (no > >interoperation). For the SHOULD, it's an optimization. We can change it > >if you want. > > My previous comment was that: "It's a change. I suggest reverting it. > Telling people who are using the "ptr" mechanism that they must have > PTR records is stating the obvious". Obvious to you. Not obvious to everyone. > > > "It is, however, still in use and part of the SPF protocol, so > > > compliant > > > check_host() implementations MUST support it." > > > > > > What is a compliant check_host() implementation? > > > >One that works in accordance with 4408bis. Please suggest an alternative > >if you don't like that. > > I am ok with what the working group wants. > > > > In Section 5.6: > > > "ip6-network = " > > > > > > I suggest that the above reference be verified for correctness. > > > > > > In Section 5.7: > > > 'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all' > > > > > > I'll flag this for review by DNS folks. > > > > > > In Section 6: > > > 'The modifiers defined in this document ("redirect" and "exp") MAY > > > > > > appear anywhere in the record, but SHOULD appear at the end, after > > > all mechanisms.' > > > > > > This text is in RFC 4408. I would label the RFC 2119 usage as > > > defective. > > > >Why? > > My previous comment was: "The text tells me that it is ok if the > modifiers appear anywhere but they should appear at the end after all > mechanisms. It would be clearer to say that it should appear after > all mechanisms". That is defective use of 2119 language? I disagree that that would be clearer. > > > In Section 6.2: > > > "Since the explanation string is intended for an SMTP response and > > > [RFC5321] Section 2.4 says that responses are in [US-ASCII], the > > > explanation string MUST be limited to US-ASCII.' > > > > > > It would be easier to defer to RFC 5321 instead of setting a RFC 2119 > > > requirement in this draft. I note that this requirement was not in RFC > > > 4408. > > > >It's not a new requirement. If you couldn't find it in 4408, then that > >means we've succeeded in making the actual requirement more clear. > > None of the WG participants have pointed out where the actual > requirement (RFC "MUST") is in RFC 4408. If the text was in RFC 4408 > it would be possible for a WG participant to point me to it. There > was a comment about 'this could be expressed non-normatively (e.g. > "needs to be")'. If it's not ASCII, it won't interoperate (at all). Isn't that exactly where 2119 language is supposed to be used? Regardless of how it's worded in 4408, putting non-ASCII characters in explanation strings does not and has never worked. At most it's making something explicit that was implicit before, which is a good clarification I'd think. > > > "Software SHOULD make it clear that the explanation string > > > comes from a third party." > > > > > > I could not understand what that means in RFC 2119 terms. The draft > > > uses RFC 2119 key words by example instead of providing an explanation. > > > >I don't understand the comment. > > There was a comment from Murray: "we're talking about > interoperability between humans here, and not between implementations". We're talking about avoiding security issues caused by the humans getting confused. > > > In Section 7.1: > > > 'The "toplabel" construction is subject to the LDH rule plus > > > > > > additional top-level domain (TLD) restrictions.' > > > > > > Where can I find these restrictions? Please note that I have read > > > the Informational RFC. > > > >LDH + non-numeric as the RFC says. > > I'll get back to this issue. > > > > In Section 7.3: > > > "-exists:%(ir).sbl.spamhaus.example.org" > > > > > > I commented about vendor-neutral previously [8]. The above is a way > > > to get around the objection [9]. I suggest cleaning this up. > > > >Took spamhaus out. > > Ok. > > > > "so trailing dots SHOULD NOT be published by domain owners" > > > > > > Why is it "domain owners"? > > > >Took out everything after published. > > Ok. > > > > "This macro SHOULD NOT be used. See Section 5.5 for the discussion > > > > > > about why not." > > > > > > This comes out as a flippant explanation for the RFC 2119 SHOULD. > > > >Please recommend non-flippant text then. It doesn't read that way to me. > > "This macro SHOULD NOT be used (See Section 5.5 for discussion). Done. > > > "This SHOULD be a fully qualified domain name, but if one does not > > > > > > exist (as when the checking is done by a MUA) or if policy > > > restrictions > > > dictate otherwise, the word "unknown" SHOULD be substituted." > > > > > > The RFC 2119 key words are in RFC 2119. I don't know what to say. > > > >OK. > > Murray comemnted: "I think that looks fine as-is, though we could > change the first SHOULD to "ought to" because it's a transformation > of other input and not an implementation choice. (And I assume you > mean they were in RFC4408.) Since the values end up in log files and Received-SPF/authentication results header fields that are provided to be processed on other systems, it is an interoperability issue. Having consistency helps interoperability. I'd prefer to leave it. > > > "When the result of macro expansion is used in a domain name query, > > > if > > > > > > the expanded domain name exceeds 253 characters (the maximum length > > > of a domain name), the left side is truncated to fit, by removing > > > successive domain labels (and their following dots) until the total > > > length does not exceed 253 characters." > > > > > > Where is it specified that the maximum length of a domain name is 253 > > > characters? > > > >This was covered in someone else's response. > > Ok. > > > > "Care has to be taken by the sending ADMD so that macro expansion for > > > > > > legitimate email does not exceed the 63-character limit on DNS > > > labels." > > > > > > Where is that 63-character limit specified? > > > >This was covered in someone else's response. > > Ok. > > > > It is odd to have RFC 2119 requirements under a "Notes" heading. > > > >They aren't really notes in that sense. If you have a better name for the > >section, please suggest. > > I suggest removing all the RFC 2119 requirements in Section 7.3 if > the working group cannot find a way to fix this. Why? How about if we call it "Details" instead of Notes? > > > In Section 8.2: > > > 'A "neutral" result MUST be treated exactly like the "none" result; > > > the distinction exists only for informational purposes.' > > > > > > Why is an existing RFC 2119 restated? > > > >Because of the structure of the document that the WG came up with. I don't > >find a good way to avoid it and not make it less readable. > > I'll leave this issue open as it was mentioned in the AppsDir review. > > > > In Section 8.5: > > > "The domain owner believes the host is not authorized but is not > > > willing > > > > > > to make a strong policy statement." > > > > > > Why is it domain owner? > > > > Because conversion to the newer terms was incomplete. I clean up this > > and > > > >some others as well. > > Ok. > > > > In Section 9: > > > "An operator could choose to use both to serve different downstream > > > > > > agents. In such cases, care needs to be taken to ensure both fields > > > are conveying the same details, or unexpected results can occur." > > > > > > This has been discussed on the mailing list. I don't think that it > > > encourages interoperability but the working group decided otherwise > > > [10]. > > > > > > In Section 9.1: > > > "The Received-SPF header field is a trace field (see [RFC5322] > > > Section > > > > > > 3.6.7) and SHOULD be prepended to the existing header, above the > > > Received: field that is generated by the SMTP receiver." > > > > > > "prepended to the existing header" does not sound right. > > > >I believe it is. > > Murray explained this in a comment about the review. > > > > "It MUST appear above all other Received-SPF fields in the message." > > > > > > How does this fit into the previous RFC 2119 SHOULD? > > > >It will generally happen as a natural result of following the previous one, > >but is there in case more than one is added by a single MTA. > > Murray commented on this. > > > > in Section 10: > > > "This section is not a "how-to" manual, or a "best practices" > > > document, > > > > > > and it is not a comprehensive list of what such entities SHOULD do > > > in > > > light of this document." > > > > > > What is the meaning of the RFC 2119 SHOULD in the above? > > > >Got rid of it. > > Ok. > > > > In Section 10.1.1: > > > > > > There was a comment from Authur Thisell about the table [11] in this > > > sub-section. > > > >There didn't seem to be support for changing it though. > > I read RFC 4408 and I did not find any table similar to the one in > Section 10.1.1 of draft-ietf-spfbis-4408bis-14. My understanding of > "support for changing text" is that the text is proposed on the > working group mailing list and it is added if there is agreement. I > didn't find any messages about that in the mailing list > archives. What I found was a message disagreeing with a change which > was made in the draft which was posted together with an explanation > about why there was disagreement. In my opinion there wasn't any > support for making that change in the draft. The text came from Alessandro and was discussed on the list. Arthur's comment came later. The table is new, but is only a new expression of information that was in 4408. It does not create any new requirements. > > > In Section 10.1.2: > > > "Publishing SPF records for domains that send no mail is > > > > > > a well established best practice." > > > > > > I am not aware of that best practice. I did a few DNS queries: > > > > > > ;; QUESTION SECTION: > > > ;bing.com. IN TXT > > > > > > ;; ANSWER SECTION: > > > bing.com. 3600 IN TXT "v=msv1 > > > t=6097A7EA-53F7-4028-BA76-6869CB284C54" > > > > > > ;; QUESTION SECTION: > > > ;com.com. IN TXT > > > > > > ;; ANSWER SECTION: > > > com.com. 293 IN TXT > > > "google-site-verification:esSnoZdChIkkfCfS9MMgqNhE0yaXfnnZWdZPuBf7e8k" > > > >OK. See > >http://www.bits.org/publications/security/BITSEmailAuthenticationFeb2013.pd > >f > I suggest "good practice" as mentioned by Alessandro. What's wrong with the way it is? I think the current text is accurate. > > > In Section 10.1.3: > > > "SPF functionality is enhanced by administrators ensuring this > > > identity is set correctly and has an appropriate SPF record." > > > > > > How is SPF functionality enhanced? > > > >If there's an SPF record for HELO as well as Mail From, then a check can be > >performed on bounces. > > Ok. > > > > In Section 10.2: > > > "As stated elsewhere in this document, there is no normative > > > requirement > > > > > > for specific handling of a message based on any SPF result." > > > > > > The "as stated elsewhere" is vague. > > > >It comes up multiple places. Adding several specific reference won't > >improve the draft. > > I suggest adding a reference to Section 8 (subject to the AppsDir > review being addressed). The next sentence has a reference to Section 8. > > > 'The primary considerations are that SPF might return "pass" for mail > > > > > > that is ultimately harmful (e.g., spammers that arrange for SPF to > > > pass using nonsense domain names' > > > > > > What are "nonsense" domain names? > > > >There was follow-on discussion about this. > > "discardable" was suggested. I went with disposable, since discardable is a specific term of art in other email authentication related documents and I don't want to create potential for confusion. > > > In Section 10.3: > > > "The mediator can make the newly-posted message be as similar or as > > > > > > different from the original message as they wish." > > > > > > The sentence seems incomplete, i.e. similar to what. > > > >The original message. > > Ok. > > > > "For the operation of SPF, the essential concern is the email > > > > > > address in the 5321.MailFrom command for the new message." > > > > > > What does this mean? > > > >It means that's the thing that's the most important. > > Ok if the working group agrees. > > > > 'Because SPF evaluation is based on the IP Address of the "last" > > > > > > sending SMTP server, the address of the mediator will be used, > > > rather > > > than the address of the SMTP server that sent the message to the > > > mediator.' > > > > > > I'll note that this is a mix of RFC 5321 and RFC 5598. The result is > > > clear or unclear depending on the background of the reader. > > > >I guess I have the background for it to be clear. Please suggest an > >improvement. > > I suggest leaving it as it if there isn't any disagreement. > > > > In Section 11.5: > > > "An SPF compliant receiver gathers information from the SMTP commands > > > > > > it receives and from the published DNS records of the sending domain > > > holder" > > > > > > I suggest explaining the untrusted part. > > > >That's what the section does. > > There was a comment: "A second sentence indicating most of that > input is unverified is probably in order, with references if possible". I think the section explains exactly that, so some text would help. > > > In Section 11.6: > > > "Checking SPF records causes DNS queries to be sent to the domain > > > owner." > > > > > > How are DNS queries sent to domain owners? > > > >Fixed it. > > Ok. > > > > Section 12: > > > > > > I note that Murray S. Kucherawy has contributed significantly to > > > draft-ietf-spfbis-4408bis. If I am not mistaken it is IETF practice > > > to acknowledge such contributions. I don't recall who sent text at > > > the moment. If you did, please send an (off-list) email to the > > > SPFBIS WG Chairs. > > > >There are many, many people who contributed to both 4408 and 4408bis that > >aren't listed. If someone wants to make a list of people who made a > >significant contribution, I'll be glad to include it. > > My understanding is that it is the task of the document editor to > keep track of contributions and contributors. There is a message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg03059.html > where it is mentioned that: > > "2. Scott, in collaboration with Murray Kucherawy (who proposed > the original reorganization), undertakes the reorganization and > creates the next WG document." I think to single out one person in this way would be unfair to other people that made significant contributions. The original 4408 acknowledgements weren't done this way and so I think it's literally impossible to properly develop an acknowledgements section that would be fairly done. This is not to knock down Murray's contribution, which I agree has been significant. There was a thread about this on the IETF main list in late March. Working groups vary significantly. What's in the draft for acknowledgements has been there, virtually unchanged since last summer. If you really want a reasonable list of contributors, we'll need to discuss a new schedule because this won't finish in May. > > > In Section 13.2: > > > "Per [RFC3864], the "Received-SPF:" header field is added to the IANA > > > > > > Permanent Message Header Field Registry." > > > > > > Note to self: request removal from the provisional message header > > > field registry. > > > > > > The "status:" should be "standard" > > > >Not Standards Track? > > I verified this again; it's "standard". Fixed. > > > In Section 13.3: > > > "Their status should not be changed." > > > > > > I suggest "Their status is unchanged". BTW, it should be "SPF > > > Modifier Registry". > > > >Fixed > > Ok. > > > > I suggest following RFC 6652 Section 5.1. > > > > > > An "Updates:" for RFC 6652 may be needed. > > > >Why? It's the registry that gets updated, not 6552. > > I'll ask the Area Director. > > > > References: > > > > > > Why is RFC 1123 a normative reference? > > > >See section 2.4. > > Ok. > > > > Why is RFC 3864 a normative reference? > > > >Because it defines how the Received-SPF registration is done. > > Ok. > > > > Where can I find "Designated Mailers Protocol"? > > > >See draft-fecyk-dsprotocol > > Ok. As a note for the working group, I could not find the draft. First Google hit for draft-fecyk-dsprotocol is: http://tools.ietf.org/html/draft-fecyk-dsprotocol-04 > > > Where can I find "Domain-Authorized SMTP Mail"? > > > >I don't have a copy of this. > > I suggest dropping the reference. SPF did not spring from nothing. It gathered a number of concepts, added a few things, and managed to be successful. I think it would be more appropriate to leave it as it shows part of the trace back to the origin of the protocol. > > > In Appendix C: > > > > > > In Section E.1: > > > 'This would cause a lookup on an DNS white list (DNSWL) and cause a > > > > > > result of "fail" only for email not either coming from the > > > domain's mx host(s) (SPF pass) or white listed sources (SPF > > > neutral).' > > > > > > I didn't find any discussion about this on the SPFBIS mailing > > > list. is there an explanation for this change between RFC 4408 and this > > > draft? > > > >It was pointed out that this is a white list, not a black list. > > I suggest dropping this change as it was not discussed within the > working group. Yes. It was. > > > I note that there are 48 pages in RFC 4408. There are 78 pages in > > > this draft. A significant amount of text has been added in the > > > Appendix (over 20 pages). I doubt that the text has been carefully > > > reviewed. I may be asked for an explanation about all that once the > > > draft leaves this working group. > > > >Why wait? > > I am not the person doing the IESG evaluation. OK. I misunderstood your comment. I think you're wrong about the lack of review though. > > > In Appendix I: > > > > > > Appendix I is about "Protocol Status". This draft is intended as a > > > Proposed Standard. From an IETF perspective that is what it will > > > be. Describing it as something different can be misleading. > > > > > > "[RFC4408] was designed to clearly document the protocol defined by > > > > > > earlier draft specifications of SPF as used in existing > > > implementations. This updated specification is intended to clarify > > > identified ambiguities in [RFC4408], resolve techincal issues > > > identified in post-RFC 4408 deplyment experience, and document > > > widely > > > deployed extensions to SPF that have been developed since [RFC4408] > > > was published." > > > > > > Extensions to the SPF protocol are clearly mentioned in the charter > > > as being out of scope. The "document widely deployed extensions" is > > > problematic. > > > >The charter specifically allows for "addition of any enhancements > >that have already gained widespread support". > > I read the discussion about the charter again. It is my > understanding that extensions to the SPF protocol is > out-of-scope. The working group did not add a work item during the > chartering discussion as it was considered as an extension to the protocol. It was also not widely deployed. Should I take authentication-results out of the draft then? > > > "This document updates and replaces RFC 4408 that was part of a group > > > > > > of simultaneously published Experimental RFCs (RFC 4405, RFC 4406, > > > RFC 4407, and RFC 4408) in 2006. At that time the IESG requested > > > the > > > community observe the success or failure of the two approaches > > > documented in these RFCs during the two years following publication, > > > in order that a community consensus could be reached in the future." > > > > > > Why is this needed? The SPFBIS WG produced RFC 6686 to resolve the > > > experiment. > > > >Since this is what obsoletes 4408, not everyone will read 6686. > > There is an informative reference to RFC 6686. I don't see why the > text mentioned above is needed. I think the section is incomplete without it. > > > "SPF is widely deployed by large and small email providers alike. > > > > > > There are multiple, interoperable implementations." > > > > > > Someone might point out that this is marketing instead of text > > > relevant to a protocol. I'll mention that one or more significant > > > issues (e.g. Issue #9) was identified during the WG > > > discussions. Issue #9 was not listed as the errata. I suggest > > > removing the section as it will be less text and there is already two > > > informative references to help the reader find background information. > > > >#9 has been known since before 4408 was published. In 2005 it was the > >price of admission to the IETF. > > My suggestion as document shepherd is to avoid that discussion. The > draft will face a very difficult Last Call as it is and more > controversies won't make matters any better. I'm not the one claiming it was discovered by the WG. I'm not sure what controversy you think I'm adding. Scott K From spf2@kitterman.com Thu May 16 23:48:11 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD2A21F930C for ; Thu, 16 May 2013 23:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HajdbhBLMnpt for ; Thu, 16 May 2013 23:48:06 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 423A921F92CB for ; Thu, 16 May 2013 23:48:06 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C8D2220E411A; Fri, 17 May 2013 02:48:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368773285; bh=U3eJEob4YVJ9q5Ex+BqlXerw4f7l7znDeyKmmp/Aw00=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MO12YXUtswDfAg79ojaJppBmFj5StPtk1J6noNtpwC8cGoe6WKR8owhSyUffVQoSX 6r/5aQnEKyA80P5sgksKLQnTGLZ5z7DUqFGpbDK5/IgqxPcT16fgFW37UH6F2/0mv4 oiaUUyl7VxEModgLvpV7o08oJjBNEysn4faRH3x8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B2BDB20E40C6; Fri, 17 May 2013 02:48:05 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 02:48:04 -0400 Message-ID: <342196331.8PjgpiStlt@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130424002629.13505.qmail@joyce.lan> References: <20130424002629.13505.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 06:48:11 -0000 On Wednesday, April 24, 2013 12:26:29 AM John Levine wrote: > >The "Some implementations ..." sentence seems to be malformed. I can't > >parse it. > > That whole paragraph could be replaced by "the result of evaluating > check_host() with a syntactically invalid domain is undefined." Perfect. Thanks and done locally. Scott K From spf2@kitterman.com Thu May 16 23:57:18 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFDB21F92CB for ; Thu, 16 May 2013 23:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3gjgaBc2LAa for ; Thu, 16 May 2013 23:57:13 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC0E21F92FC for ; Thu, 16 May 2013 23:57:13 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DF4C920E411A; Fri, 17 May 2013 02:57:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368773832; bh=TEe5K4LTFUX/FGHK83R/P67wXPO2R2oHXtjDRO7DzEc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=juce9daRqpmPQ9OjdCtiXZLcfXL8q+FzSvhM1d7kEUB829ahdZTwReOEAASe10QzN gRK9WzDwKJswPc0M8ByrQhCiCmxUd+/lPGBRfA1Je5z5idRxfMOH6KZHD9ZFlqEhl0 TeB25YVjncO6+yFc10CWUu+tYs774Y0fd76Ctn24= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C5AAF20E40C6; Fri, 17 May 2013 02:57:12 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 02:57:12 -0400 Message-ID: <2482672.7TKMx18iAE@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 06:57:18 -0000 On Monday, April 29, 2013 01:21:22 AM Murray S. Kucherawy wrote: > > "TXT records containing multiple strings are useful in constructing > > records that would exceed the 255-byte maximum length of a character- > > string within a single TXT record." > > > > I suggest using "octet" instead of "byte". I'll point the working group > > to CVE-2008-2469 in case it might wish to consider that issue. > > How is an octet different from a byte in this context? This strikes me as > a stylistic issue at best. > > In Section 4.3: > > "If the is malformed (e.g. label longer than 63 characters, > > > > zero-length label not at the end, etc.)" > > > > That should be "octets". > > Since the DNS is all in ASCII, they're synonymous. That said, we may as > well be consistent. I've gone through and searched for both byte and character (there were both) and made them octets (when character was relevant to this, it's used in other ways too, so we're consistent. Scott K From spf2@kitterman.com Fri May 17 00:00:27 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E2E21F9223 for ; Fri, 17 May 2013 00:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQHElNaZCknh for ; Fri, 17 May 2013 00:00:22 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF5621F9227 for ; Fri, 17 May 2013 00:00:22 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B066C20E411A; Fri, 17 May 2013 03:00:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368774021; bh=wsemxwtIsnP5PSViEohMPkSZUhKI1umP24PAWOeFd6I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SwHSwc1AzWfWh9bmZNZlc96JLq3aYM9jbRP2o9rH5t3OXsq+a7TqCFhTPL+tbW94q X864mi4J9I7sbdJyKnH6ynRZnppZ8ORSZii0upwrepgpegPF4LwgRfPIpBAIkhBLBV Enufownv1t+JST5l7sw34lDWWS9l2oyaop+4JpnE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9ACFE20E40C6; Fri, 17 May 2013 03:00:21 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 03:00:20 -0400 Message-ID: <2145066.lUzkP57SLe@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 07:00:27 -0000 On Monday, April 29, 2013 01:21:22 AM Murray S. Kucherawy wrote: > > In Section 5.4: > > 'Note regarding implicit MXs: If the has no MX records, > > check_host() MUST NOT pretend the target is its single MX, and MUST > > NOT default to an A or AAAA lookup on the directly.' > > > > There are two RFC 2119 MUSTs in the above. This is over-usage of RFC 2119 > > key words. This text was in RFC 4408. This is not a divergence from RFC > > 5321, it is a contrary to Section 5 of RFC 5321. > > I believe the advice should remain, but it could be simplified: > > "Note regarding implicit MXes: If the has no MX records, > check_host() MUST NOT apply the implicit MX rules of RFC5321 by querying > for an A record for the same name." Thanks. Done. Scott K From spf2@kitterman.com Fri May 17 00:10:16 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962DF21F93D1 for ; Fri, 17 May 2013 00:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJf-c8Yt3Tcf for ; Fri, 17 May 2013 00:10:12 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6989621F93BD for ; Fri, 17 May 2013 00:10:12 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A5A8820E411A; Fri, 17 May 2013 03:10:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368774611; bh=b4K3o4LNNrYAZPXasMEihnnXDRBjvtbl1r5aP3uyoyQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hvH52yoiPR+QViA49tPYPW83i0Nc4SdPoHkddtfsuC1tIRqCsyYHB1qVs5OoiduL2 IUvVTfvgqksGZUTjmed0vmZ22nyKK2cOhcB4zZ+UG/b4pppkCYxOfx3p1ZEJAVCTB/ Tizu7AIU76kiUKAz5Rh7id+yr4M4v1B986X9fAKI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8FDDC20E40C6; Fri, 17 May 2013 03:10:11 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 03:10:10 -0400 Message-ID: <2551938.EPWvkJSS3a@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <517E856A.6060205@dcrocker.net> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <517E856A.6060205@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 07:10:16 -0000 On Monday, April 29, 2013 07:36:26 AM Dave Crocker wrote: > > "This SPF check can only be performed when the "HELO" string is a > > valid fully qualified domain." > > > > What is a valid fully qualified domain? > > Internet Users' Glossary", FYI 18, RFC 1983 > http://tools.ietf.org/html/rfc1983 > > Fully Qualified Domain Name (FQDN) > The FQDN is the full name of a system, rather than just its > hostname. For example, "venera" is a hostname and > "venera.isi.edu" is an FQDN. See also: hostname, Domain Name > System. > > I suggest merely citing this RFC. Done. > > "Implementations have to take care to correctly extract the > > from the data given with the SMTP MAIL FROM command as many MTAs > >will > > still accept such things as source routes ..." > > > > The definition of is: > > > > 'the domain portion of the "MAIL FROM" or "HELO" identity.' > > > > I am not sure whether it is even a definition. From an > > implementation perspective the last paragraph of Section 2.4 is > >unclear.> > > I don't agree. I imagine by now you're aware of what this is for; can > > you suggest some other text that accomplishes the intent? > > On reflection, it might avoid some reader confusion to define have the > label be something like , so that isn't overloaded > with a specialized definition for this document. I don't think it's that specialized. I think such a change would cause people to wonder how it was different and cause more confusion than it resolved. Scott K From spf2@kitterman.com Fri May 17 00:19:18 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE1C21F8D00 for ; Fri, 17 May 2013 00:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gpyb+A4Xca5Q for ; Fri, 17 May 2013 00:19:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 18DEC21F8A6B for ; Fri, 17 May 2013 00:19:14 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 941A820E411A; Fri, 17 May 2013 03:19:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368775153; bh=PZkT7X1ptgPsTPC9RWkETtdRS3UyM2r5RjPL15V+/5w=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Grf3+kRocFPrQz6mMI49g5BHlEMafjW/O6oqcE/RPOD9A+BntBSnhes5yzlOADGlR tv5w4QUT5UEGR1AH/Q48m2aThgfv84G/t+bA3kFGP2OU26iPT7s3xwRLtDdkIN5dwh 6Rq8b3o+80SgnEmBjVMiWYkDU/w/+Bd+0v9ePv38= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6D8E520E40C6; Fri, 17 May 2013 03:19:13 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 03:19:12 -0400 Message-ID: <2421340.Boky7kAc7z@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <517E9280.6040102@tana.it> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <517E9280.6040102@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 07:19:18 -0000 On Monday, April 29, 2013 05:32:16 PM Alessandro Vesely wrote: > On Mon 29/Apr/2013 10:21:22 +0200 Murray S. Kucherawy wrote: > > Scott and I talked a bit about some of these points, and I thought it > > might > > help if I went through the whole thing and commented on it. I hope this > > is > > helpful. I've chopped out stuff where I have no specific response or > > opinion about the points made, so this is only a nearly-complete reply. > > I add a few lines, in case consensus needs to be gauged. > > > On Tue, Apr 23, 2013 at 4:08 PM, S Moonesamy wrote: > >> In the Abstract: > >> "This document describes version 1 of the Sender Policy Framework > >> > >> (SPF) protocol, whereby an ADMD can explicitly authorize the hosts > >> that are allowed to use its domain names, and a receiving host can > >> check such authorization." > >> > >> ADMD should be expanded in the above. This was pointed out in a review > >> posted on August 26, 2012 [1]. > > > > Agree. > > +1, good style. > > >> In Section 2.1: > >> 'It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" > >> > >> identity, but also separately check the "HELO" identity by applying > >> the check_host() function (Section 4) to the "HELO" identity as the > >> .' > >> > >> As a note this "RECOMMENDED" is also in RFC 4408. > > > > You made these notes throughout your review. I take it there's no action > > for the WG here; you are just auditing "out loud" what normative things in > > 4408bis were also present as-is in 4408, and which have changed. > > > >> 'Note that requirements for the domain presented in the EHLO or HELO > >> > >> command are not always clear to the sending party, and SPF verifiers > >> MUST be prepared for the "HELO" identity to be malformed or an IP > >> address literal.' > >> > >> This RFC 2119 "MUST" is not in RFC 4408. It is a substantive change in > >> my > >> opinion. > > > > This was probably at my suggestion. The issue here is that RFC2119 > > doesn't > > say "must" has any different meaning than "MUST" does, so we should either > > be consistant and uppercase-ize it, or use some other word. > > +1 for some other word. > > > In any event, I don't agree that this is actually a substantive change. > > +1, sanitizing input is part of any protocol. > > >> "This SPF check can only be performed when the "HELO" string is a > >> > >> valid fully qualified domain." > >> > >> What is a valid fully qualified domain? > > > > I believe it means "a name comprising a sequence of DNS labels, separated > > by dot characters, which when queried resolve to an A or MX record". It > > may have a proper definition in some other RFC too. Should we add one in > > the Introduction or Definitions? > > "What is a Fully Qualified Domain Name?" is the title of Section 5.2 > of RFC 1594. > > >> In Section 2.3: > >> "An SPF-compliant domain MUST have valid SPF records as described in > >> > >> Section 3." > >> > >> As a note the RFC 4408 text is: > >> "An SPF-compliant domain MUST publish a valid SPF record as described > >> > >> in Section 3." > >> > >> The RFC 2119 MUST is redundant. > > > > In a recent conversation, Pete described this as "not really wrong, but > > it's shouting." I guess that means changing "MUST publish" to "publishes" > > or something like that. > > +1, that would be the definition of an SPF-compliant domain. > > >> 'If domain owners choose to publish SPF records and want to support > >> > >> receivers making negative authorization determinations, then they MUST > >> publish records that end in "-all", or redirect to other records that > >> do, > >> otherwise, no definitive determination of authorization can be made.' > >> > >> The document uses ADMD while there is "domain owners" in the above. I > >> suggest reviewing that. > > > > I think they're synonymous. Going with ADMD is probably a good idea. > > Just mentioning that they they are synonyms, e.g. in the 1st paragraph > of the introduction, might be handier to readers who are not familiar > with the term. > > >> The RFC 2119 MUST is a substantive change. Why is this a MUST? > > > > It is the only way within the protocol to cause negative authorization > > determinations to occur. It is an interoperability requirement. I > > believe > > this is correct. > > +1, an equivalent wording could be: > > An SPF-compliant domain needing to support receivers making > negative authorization determinations MUST... > > >> In Section 2.4: > >> 'At least the "MAIL FROM" identity MUST be checked, but it > >> > >> is RECOMMENDED that the "HELO" identity also be checked beforehand.' > >> > >> There is already a RFC 2119 MUST in Section 2.2. There is also a RFC > >> 2119 > >> RECOMMENDED in Section 2.1. The above text restates existing RFC 2119 > >> requirements or recommendations. > > > > I agree; the redundancy should be resolved. The cited sentence in 2.4 can > > probably go. > > -1, Section 2.4 is the proper place to say that. Sections 2.1 and 2.2 > should be just definitions. They are garbled and it's they who > deserve corrections. > > >> 'Without explicit approval of the domain owner, checking other > >> > >> identities against SPF version 1 records is NOT RECOMMENDED because > >> there are cases that are known to give incorrect results.' > >> > >> How should this explicit approval be sought? This recommendation does > >> not > >> make sense. > > > > Adding "out-of-band" or "private" after "explicit" would probably clear > > this one up. > > How about defining the concept of (private or standard) "extension"? > > >> In Section 2.4: > >> 'When a mail receiver decides to perform an SPF check, it MUST use a > >> > >> correctly-implemented check_host() function (Section 4) evaluated > >> with the correct parameters.' > >> > >> This RFC 2119 requirement states the obvious. It basically says that > >> there is a requirement in draft-ietf-spfbis-4408bis-14 to use a correct > >> implementation of draft-ietf-spfbis-4408bis-14. > > > > I agree, that sentence can probably go. > > +1 > > >> "Implementations have to take care to correctly extract the > >> > >> from the data given with the SMTP MAIL FROM command as many MTAs will > >> still accept such things as source routes ..." > >> > >> The definition of is: > >> 'the domain portion of the "MAIL FROM" or "HELO" identity.' > >> > >> I am not sure whether it is even a definition. From an implementation > >> perspective the last paragraph of Section 2.4 is unclear. > > > > I don't agree. I imagine by now you're aware of what this is for; can you > > suggest some other text that accomplishes the intent? > > I don't think we need to specify how to treat archaic input. To > mention it is right and proper, though. > > >> 'Performing the authorization other than using the return-path and > >> > >> client address at the time of the MAIL command during the SMTP > >> transaction can cause problems, ..' > >> > >> Shouldn't that be "authorization check"? > > > > Yes. > > +1 > > >> 'Generating non-delivery notifications to forged identities that have > >> > >> failed the authorization check is a source of backscatter and SHOULD > >> be avoided.' > >> > >> This RFC 2119 SHOULD is not in RFC 4408. The above does not have > >> anything > >> to do with Sender Policy Framework. It was mentioned during WG > >> discussions > >> that "SPF can help the backscatter problem" [2]. This text may have been > >> introduced in response to a review [3]. Is this an enhancement or a > >> clarification? > > > > I think it documents operational experience acquired since RFC4408 was > > published. As for whether RFC2119 language is appropriate, I agree that > > it > > isn't; it has nothing to do with SPF itself, though it is a side effect of > > its use. I suggest changing SHOULD to "needs to". > > +1, note that both RFC 5321 (silent dropping of messages should be > considered) and RFC 3464 (should take appropriate precautions) have > lowercase "should". > > >> In Section 2.6: > >> "An SPF verifier implements something semantically identical to the > >> > >> function defined there." > >> > >> John Levine commented about this during the WGLC [4]. I am listing this > >> as a reminder for myself. > > > > I agree with John. > > +1 for "semantically equivalent". > > >> In Section 2.6.1: > >> 'A result of "none" means either (a) no syntactically valid DNS domain > >> > >> name was extracted from the SMTP session that could be used as the > >> one to be authorized, or (b) no TXT records were retrieved from the > >> DNS that appeared to be intended for use by SPF verifiers.' > >> > >> I suggest "DNS TXT records". What is a syntactically valid DNS domain > >> name? The definition of "none" in RFC 4408 is clear (to me). > > > > "DNS TXT records" is fine but probably not necessary at this point in the > > document. > > +1 > > > We discussed the "syntactically valid" thing above. > > > > This definition of "none" is more precise than it was in RFC4408. The > > 4408 > > > > definition was: > > A result of "None" means that no records were published by the domain > > or that no checkable sender domain could be determined from the given > > identity. The checking software cannot ascertain whether or not the > > client host is authorized. > > > > This text did not account for the notion that TXT records were returned > > that didn't start "v=spf1". It also wasn't clear about what "checkable" > > meant. I believe the bis definition is better. > > +1 > > >> In Section 2.6.2: > >> 'The domain owner has explicitly stated that it is not asserting > >> > >> whether the IP address is authorized. This result MUST be treated > >> exactly like the "none" result; the distinction exists only for > >> informational purposes.' > >> > >> As a note, the RFC 2119 MUST is in RFC 4408. The Introduction Section > >> mentions "ADMDs can authorize hosts to use their domain names". The > >> above > >> uses "domain owner". > > > > Covered earlier. > > > >> In Section 2.6.7: > >> 'A "permerror" result means the domain's published records could not > >> > >> be correctly interpreted. This signals an error condition that > >> definitely requires manual intervention to be resolved.' > >> > >> What is "manual intervention" in the above? > > > > "Operator intervention" might be more consistent with common IETF usage. > > Either wording tends to imply that it is clear who should do what in > order to resolve the permerror. That's not always the case (e.g. > multiple void lookups). > > >> In Section 3: > >> 'An SPF record is a DNS record that declares which hosts are, and are > >> > >> not, authorized to use a domain name for the "HELO" and "MAIL FROM" > >> identities.' > >> > >> How are hosts which are not authorized to use a domain name listed in a > >> SPF record? > > > > It's implicit in that the set that is not authorized is the complement to > > the set that is authorized. If we want to make it clear, we could say > > "which hosts are, and thus also which are not," or something like that. > > Well, not authorized is "-", authorized is "+", but we cannot make it > clear without mentioning the other qualifiers too. I suggest leaving > that as is. > > >> "The SPF record is a single string of text." > >> > >> What is a single string of text? It may be easier to state this in terms > >> of record format. > > > > I don't think that statement is unclear, but I agree with the improvement > > suggestion. Maybe: > > > > "An SPF policy statement is expressed as a single string of text encoded > > in > > a DNS TXT record." > > Leave off "single string" (Section 3.3 title is "Multiple Strings in a > Single DNS record"). We could reuse "string of octects" from RFC > 1035, e.g.: > > The SPF record is a variable length string of octets encoded in > a DSN TXT record. > > >> 'ADMDs publishing SPF records SHOULD try to keep the number of > >> > >> "include" mechanisms and chained "redirect" modifiers to a minimum.' > >> > >> What is the minimum? Note that this RFC 2119 SHOULD is in RFC 4408. > > > > There isn't a specific minimum. The expression means "don't use this > > technique unless you absolutely need it". > > Yes, that sense is conveyed with "SHOULD try" --must consider some > alternative ways that result in a smaller number of include/redirect. > > >> 'ADMDs SHOULD also try to minimize the amount of other DNS information > >> > >> needed to evaluate a record.' > >> > >> This RFC 2119 SHOULD is also in RFC 4408. There are two RFC 2119 SHOULDs > >> in the last paragraph of Section 3. This usage of RFC 2119 key words > >> does > >> not help the SPF "publisher". In my opinion the "SHOULD try" in this > >> context uses the RFC 2119 key word in unorthodox ways. > > > > I agree with "SHOULD try", as that's arguably not actionable. "SHOULD > > minimize" is probably fine, however. > > "SHOULD minimize" conflicts with one intended use, namely > > v=spf1 redirect=_spf.example.com > > Exemplified in Section 6.1, that use does not attain the minimum. > > >> In Section 3.1: > >> 'SPF records MUST be published as a DNS TXT (type 16) Resource Record > >> > >> (RR) [RFC1035] only.' > >> > >> I would ask why "MUST be published ... only". By the way, Section 3 has > >> a > >> reference to Section 4 for record format instead of Section 3.1. Is that > >> correct? > > > > The text is not incorrect, but it's also not necessary. Dropping "only" > > is > > probably sufficient. > > +1, we don't need to stress that the other type was discontinued. > > > The reference is indeed incorrect. > > Should we say "is described along with its interpretation in Section > 4.5"? How about changing the title of Section 4.5 to "Record Format"? > > >> In Section 3.2: > >> "A domain name MUST NOT have multiple records that would cause an > >> > >> authorization check to select more than one record." > >> > >> This RFC 2119 MUST NOT was in RFC 4408. Is this to help the SPF > >> "publisher" and if so, how does it help? > > > > I believe it is an advisory to publishers of the consequences of having > > more than one "v=spf1" record published. > > Yup > > >> In Section 3.3: > >> "As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS > >> > >> record can be composed of more than one string." > >> > >> See previous comment about " a single string". > > > > This use is correct, as it describes the fact that there are many ways to > > encode a single high-level string into multiple low-level > > "character-strings" as defined in RFC1035. > > +1, but I wouldn't mention the level of strings in the I-D... > > >> "If a published record contains multiple character-strings, then the > >> > >> record MUST be treated as if those strings are concatenated together > >> without adding spaces." > >> > >> This RFC 2119 MUST is also in RFC 4408. I suggest removing the "MUST" in > >> the example. > > > > I disagree. It's required for interoperability. > > +1, are there DNS libraries that do otherwise? > > >> "TXT records containing multiple strings are useful in constructing > >> > >> records that would exceed the 255-byte maximum length of a character- > >> string within a single TXT record." > >> > >> I suggest using "octet" instead of "byte". I'll point the working group > >> to CVE-2008-2469 in case it might wish to consider that issue. > > > > How is an octet different from a byte in this context? This strikes me as > > a stylistic issue at best. > > +1 for s/byte/octet/, even if it's stylistic: > > The size of the byte has historically been hardware dependent and > no definitive standards existed that mandated the size. > http://en.wikipedia.org/wiki/Byte > > >> In Section 4: > >> "A compliant SPF implementation MUST do something semantically > >> > >> equivalent to this description." > >> > >> It's unusual to see a "do something" RFC 2119 requirement in a > >> specification. Is the SPFBIS WG working on compliance for SPF > >> implementations? > > > > RFC6376 is an example of a standards track document that uses RFC2119 MUST > > in this way. I'm sure I've seen others but I can't think of them at this > > hour. I think it's fine. > > Would it be better to s/do something/behave in a way/? > > >> "Mail receivers that perform this check MUST correctly evaluate the > >> > >> check_host() function as described here." > >> > >> Where does "mail receivers" fit in the Sender Policy Framework? The > >> "MUST > >> correctly evaluate" is stating the obvious. > > > > I'm not understanding how the answer to the first question isn't obvious. > > > > I agree with the second point. > > I propose to remove that sentence. > > >> "Implementations MAY use a different algorithm than the canonical > >> > >> algorithm defined here, so long as the results are the same in all > >> cases." > >> > >> Why is this a RFC 2119 MAY? I am aware that the text is in RFC 4408. > > > > This seems to me to be another stylistic question, since MAY in RFC2119 > > terms doesn't mean much. > > It helps understanding the previous MUST, they are two poles that > implementations have to stay in between. > > >> In Section 4.1: > >> ' - the domain that provides the sought-after authorization > >> > >> information; initially, the domain portion of the "MAIL > >> FROM" or "HELO" identity.' > >> > >> The above text is different from the text in Section 2.4. > > > > I think I agree; I would prefer to have it defined in one place, and have > > other points in the document reference it. > > +1, Section 2.4 can refer to Section 4.1. However, Section 2.4 needs > to mention how the parameter should be set in each of the checks. > > >> In Section 4.3: > >> "If the is malformed (e.g. label longer than 63 characters, > >> > >> zero-length label not at the end, etc.)" > >> > >> That should be "octets". > > > > Since the DNS is all in ASCII, they're synonymous. That said, we may as > > well be consistent. > > Yeah, but ASCII is 7-bit... > > >> "Properly formed domains are fully qualified email domains as > >> > >> described in [RFC5321] Section 2.3.5." > >> > >> What are "properly qualified email domains"? > > > > Is the reference defining that term not appropriate? > > IMHO the reference is fine. The term "email domain" lacks a formal > definition, and is used improperly in Section 4.3 since HELO needs not > be an email domain in some sense. I'd s/fully qualified email > domains/fully-qualified domain names/. > > >> "Internationalized domain names MUST be encoded as A-labels, as > >> described in Section 2.3 of [RFC5890].on 2.3 of [RFC5890]." > >> > >> I'm listing the above and leave it to Area Director guidance. Please > >> note > >> that it is a new RFC 2119 requirement. > > > > I'm pretty sure RFC4408 pre-dates most of the IDN work, so this is a > > modernization step. I think it's important to include, and it also does > > the same thing DKIM did, which is now Draft Standard. If we don't, > > there's > > no guidance for use of SPF in the IDN context. The alternative is to spin > > up another document (which we're not chartered to do) that discusses use > > of > > SPF in the IDN context. > > Fully agree with Murray. However, it is not layer-wise clear whether > any A-label conversion is to be carried out as initial processing > within check_host(). > > >> In Section 4.4: > >> "In accordance with how the records are published (see Section 3 > >> > >> above), a DNS query needs to be made for the name, querying > >> for type TXT only." > >> > >> I don't understand the sentence. > > > > Query the HELO domain or the MAIL FROM domain, as described in Section 3. > > In this case, I'd keep the trailing "only" as is. > > >> 'Alternatively, for a server failure (RCODE 2) result, check_host() > >> > >> MAY track failures and treat multiple failures within 24 hours for > >> the same domain as "permerror".' > >> > >> This text is not in RFC 4408. I found a note in Issue #1 [5] and in a > >> message [6]. > > > > Are there any implementations that do this? If so, that's the > > justification; it's practical experience. If not, we should consider > > dropping it. > > +1 for dropping it. This would be needed for type 99, where bad > firewall rules could produce effects similar to network errors except > that they'd never get resolved. For "normal" SERVFAIL cases, the > meaning of temperror as derived from RFC 2308 is just fine. > > >> In Section 4.6.2: > >> "If there are no more mechanisms, the result is specified in > >> > >> Section 4.7." > >> > >> This sentence does not make sense. > > > > How about: "After all mechanisms have been processed and no matches are > > found, the result is determined according to Section 4.7." > > +1, better style. > > >> "If this number is exceeded during a check, a permerror MUST be > >> returned." > >> > >> I read this as if an implementation-specific limit is reached a permerror > >> is returned. There are two RFC 2119 MUST in the above. That can be > >> reduced to one MUST. > > > > I'm not sure I agree. SecDir has pushed the fixed query limit on other > > topics in the past, which is the first MUST, and the second MUST > > prescribes > > a specific result that has to occur when the limit is reached which is > > important for interoperability. > > +1, while it is possible to say "MUST return permerror if more than > 10", the resulting text would be less readable. > > >> 'MTAs or other processors SHOULD impose a limit on the maximum amount > >> > >> of elapsed time to evaluate check_host(). Such a limit SHOULD allow > >> at least 20 seconds. If such a limit is exceeded, the result of > >> authorization SHOULD be "temperror".' > >> > >> There are three RFC 2119 SHOULDs in the above. I suggest rewriting the > >> text to reduce that. > > > > All three of them seem to be important interoperability points. We could > > common factor the SHOULD and then present three bullets in a list, but the > > meaning is the same. > > +1, for the same readability reason. > > >> 'SPF implementations SHOULD limit "void lookups" to two.' > >> > >> What are void lookups? > > > > Last paragraph of Section 4.6. > > > >> "In this case, a default of two is RECOMMENDED." > >> > >> Why is "two" recommended? > > > > Interoperability; if one is two while another is 10, different SPF results > > can be returned. > > This is a protocol change, marked as such in Appendix C, 2nd bullet. > > >> 'Note that records SHOULD always use either a "redirect" modifier or > >> > >> an "all" mechanism to explicitly terminate processing.' > >> > >> Why is there a RFC 2119 key word in a note? > > > > Since the explanation I've been given is that it's better for human > > debugging, I think I agree since the advice is not specific to the > > protocol > > itself. > > Scott removed the "Note that". > > >> In Section 4.8: > >> 'e.g., "foo..example.com") or overlong labels (more than 63 > >> > >> characters).' > >> > >> I suggest octets. > > > > Again, synonymous. > > +1 for SM, again. > > >> in Section 5: > >> 'SPF implementations on IPv6 servers need to handle both "AAAA" and "A" > >> > >> secords, for clients on IPv4 mapped IPv6 addresses [RFC4291].' > >> > >> There is a typo, "records". > >> > >> I'll flag the above for review by people with IPv6 expertise. > > > > This was covered in a different thread. I believe a proposed text fix was > > made that people seemed to like. > > > >> In Section 5.3: > >> 'a = "a" [ ":" domain-spec ] [ dual-cidr-length ]' > >> > >> "dual-cidr-length" is introduced in this sub-section. I had to search > >> through the draft to find out what it means. > > > > That happens sometimes. :-) > > > >> In Section 5.4: > >> 'Note regarding implicit MXs: If the has no MX records, > >> > >> check_host() MUST NOT pretend the target is its single MX, and MUST > >> NOT default to an A or AAAA lookup on the directly.' > >> > >> There are two RFC 2119 MUSTs in the above. This is over-usage of RFC > >> 2119 > >> key words. This text was in RFC 4408. This is not a divergence from RFC > >> 5321, it is a contrary to Section 5 of RFC 5321. > > > > I believe the advice should remain, but it could be simplified: > > > > "Note regarding implicit MXes: If the has no MX records, > > check_host() MUST NOT apply the implicit MX rules of RFC5321 by querying > > for an A record for the same name." > > +1, s/A/A or AAAA/ > > >> In Section 5.5: > >> "This mechanism SHOULD NOT be used." > >> > >> I suggest providing a reason for this. > > > > The very next sentence is "See below for discussion." > > > >> "To prevent DoS attacks, more than 10 PTR names > >> > >> MUST NOT be looked up during the evaluation of a "ptr" mechanism > >> (see Section 4.6.4)." > >> > >> The above restates a previous RFC 2119 MUST. > > > > Agreed. > > +1, since we collected those limits. I propose to replace the second > sentence in that bullet with something like: > > This is where to apply the rule of Section 4.6.4 to ignore records > other than the first 10. > > >> "If used, proper PTR records MUST be in place for the domain's hosts > >> > >> and the "ptr" mechanism SHOULD be one of the last mechanisms checked." > >> > >> Those RFC 2119 key words are not in RFC 4408. I don't see how this RFC > >> 2119 change qualifies as a clarification or explanation. > > > > It was "must" vs. MUST in RFC4408. It's otherwise unchanged. > > > >> "It is, however, still in use and part of the SPF protocol, so > >> compliant > >> check_host() implementations MUST support it." > >> > >> What is a compliant check_host() implementation? > > > > One that complies with this specification. > > > >> In Section 5.6: > >> "ip6-network = " > >> > >> I suggest that the above reference be verified for correctness. > > > > Looks right to me. The CIDR expression is in the optional token next to > > it, so this has to be just a plain IPv6 address, so that's the right > > reference. > > I'd rather import IPv6address and IPv4address from > http://tools.ietf.org/html/rfc3986#section-3.2.2 > > >> In Section 5.7: > >> 'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{**d} -all' > >> > >> I'll flag this for review by DNS folks. > > > > What's the specific question being asked of DNSDIR here? > > > >> In Section 6: > >> 'The modifiers defined in this document ("redirect" and "exp") MAY > >> > >> appear anywhere in the record, but SHOULD appear at the end, after > >> all mechanisms.' > >> > >> This text is in RFC 4408. I would label the RFC 2119 usage as defective. > > > > Why? > > > >> In Section 6.2: > >> "Since the explanation string is intended for an SMTP response and > >> > >> [RFC5321] Section 2.4 says that responses are in [US-ASCII], the > >> explanation string MUST be limited to US-ASCII.' > >> > >> It would be easier to defer to RFC 5321 instead of setting a RFC 2119 > >> requirement in this draft. I note that this requirement was not in RFC > >> 4408. > > > > I agree that this could be expressed non-normatively (e.g. "needs to be"). > > -1, it means the value of "exp" must be ASCII. > > >> "Software SHOULD make it clear that the explanation string > >> > >> comes from a third party." > >> > >> I could not understand what that means in RFC 2119 terms. The draft uses > >> RFC 2119 key words by example instead of providing an explanation. > > > > I agree; we're talking about interoperability between humans here, and not > > between implementations. > > +1, something like "implementers are advised to make it clear..." > > >> In Section 7.1: > >> 'The "toplabel" construction is subject to the LDH rule plus > >> > >> additional top-level domain (TLD) restrictions.' > >> > >> Where can I find these restrictions? Please note that I have read the > >> Informational RFC. > > > > I'm pretty sure it's referring to common TLD conventions. > > The "LDH rule" is explained in the Informational RFC. It is the > Letter-Digit-Hyphen convention defined in RFC 952 and later modified > by RFC 1123 [http://www.icann.org/en/node/1145376] > > >> in Section 10: > >> "This section is not a "how-to" manual, or a "best practices" document, > >> > >> and it is not a comprehensive list of what such entities SHOULD do in > >> light of this document." > >> > >> What is the meaning of the RFC 2119 SHOULD in the above? > > > > Agreed, it's inappropriate here. > > I think Scott removed it already. > > >> In Section 10.1.2: > >> "Publishing SPF records for domains that send no mail is > >> > >> a well established best practice." > >> > >> I am not aware of that best practice. I did a few DNS queries: > >> > >> ;; QUESTION SECTION: > >> ;bing.com. IN TXT > >> > >> ;; ANSWER SECTION: > >> bing.com. 3600 IN TXT "v=msv1 > >> t=6097A7EA-53F7-4028-BA76-**6869CB284C54" > >> > >> ;; QUESTION SECTION: > >> ;com.com. IN TXT > >> > >> ;; ANSWER SECTION: > >> com.com. 293 IN TXT "google-site-verification:** > >> esSnoZdChIkkfCfS9MMgqNhE0yaXfn**nZWdZPuBf7e8k" > > > > What are you saying here? This is an existence proof of non-mailing > > domains that don't publish SPF records, but it doesn't contradict the > > statement made in the draft. > > It doesn't mean there's a BCP. s/best/good/? > > >> In Section 13.1: > >> "The format of this type is identical to the TXT RR [RFC1035]" > >> > >> The format is not identical, i.e. it's a different RR. I suggest keeping > >> the IANA Considerations Section simple, i.e. clearly explain to IANA what > >> action is requested. > > > > The format is indeed identical, right down to the octet. > > The format of RDATA, that is. I'd leave the definition of the > obsolete type with the obsolete RFC 4408. > > >> In Section E.1: > >> 'This would cause a lookup on an DNS white list (DNSWL) and cause a > >> > >> result of "fail" only for email not either coming from the > >> domain's mx host(s) (SPF pass) or white listed sources (SPF > >> neutral).' > >> > >> I didn't find any discussion about this on the SPFBIS mailing list. is > >> there an explanation for this change between RFC 4408 and this draft? > > > > It was in 9.3 in the previous document and has been reworded a little. > > It's otherwise unchanged. > > See http://www.ietf.org/mail-archive/web/spfbis/current/msg02276.html > > >> In Appendix I: > >> > >> Appendix I is about "Protocol Status". This draft is intended as a > >> Proposed Standard. From an IETF perspective that is what it will be. > >> > >> Describing it as something different can be misleading. > >> > >> "[RFC4408] was designed to clearly document the protocol defined by > >> > >> earlier draft specifications of SPF as used in existing > >> implementations. This updated specification is intended to clarify > >> identified ambiguities in [RFC4408], resolve techincal issues > >> identified in post-RFC 4408 deplyment experience, and document widely > >> deployed extensions to SPF that have been developed since [RFC4408] > >> was published." > > > > There are two typos in there (techincal, deplyment). > > > >> Extensions to the SPF protocol are clearly mentioned in the charter as > >> being out of scope. The "document widely deployed extensions" is > >> problematic. > > > > Agreed. > > Yes, in some sense. I'd s/extensions/changes/. I've been through this, and I think that either through sm referring to some of your comments or other discussions, we've been through these issues already. If I missed something, please let me know. Scott K From spf2@kitterman.com Fri May 17 00:26:53 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834E721F93D8 for ; Fri, 17 May 2013 00:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGek3PQ3o7q3 for ; Fri, 17 May 2013 00:26:48 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E83CB21F93D1 for ; Fri, 17 May 2013 00:26:30 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B644D20E411A; Fri, 17 May 2013 03:26:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368775588; bh=SQbck6MVap23ka5dQCvGr0Tkc8uymO+neiRCmL9I2m8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=e4m2G7/B+Ga1Zw9u3WVLyzwVlt2KMuagk55F/W0/vbPW7dlH7jujIIDUNsnvLTmpD 2yiC9eGN3k3WyWKsHBkfcLCoK20G7faewC4Cv9hNBwHcxLsFhA6/QkuVQhcthoip7t E9X2w57K1WOk2YbBmNbjjVc67Cax7zhFy949sPGo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9FE4820E40C6; Fri, 17 May 2013 03:26:28 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 03:26:19 -0400 Message-ID: <2757085.At1oRR7laG@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130430112315.0a7ee3e8@elandnews.com> References: <6.2.5.6.2.20130430112315.0a7ee3e8@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Fwd: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 07:26:53 -0000 On Tuesday, April 30, 2013 11:24:00 AM S Moonesamy wrote: > >Date: Fri, 26 Apr 2013 12:58:48 -0400 > >From: Phillip Hallam-Baker > >To: "iesg@ietf.org" , > > draft-ietf-spfbis-4408bis.all@tools.ietf.org, > > "secdir@ietf.org" > >Subject: draft-ietf-spfbis-4408bis-14 > > > > > >I have reviewed this document as part of the security directorate's > >ongoing effort to review all IETF documents being processed by the > >IESG. These comments were written primarily for the benefit of the > >security area directors. Document editors and WG chairs should treat > >these comments just like any other last call comments. > > > > > >The document is clear and describes the SPF mechanism effectively. > >The only quibble that I could find is that repeated mentions are > >made of limiting the number of 'DNS queries' without specifying > >whether these are individual queries or recursive. The count will > >come out rather differently if looking up > >TXT/x.example.com counts as one lookup or > >three. I think it is reasonably clear that this is one but could not > >find an explicit statement to that effect. I'm not aware of anyone ever thinking it was three. I'd appreciate advice on addressing this. Scott K From superuser@gmail.com Fri May 17 01:35:27 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2FA21F9246 for ; Fri, 17 May 2013 01:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngSrX6G+xWmR for ; Fri, 17 May 2013 01:35:23 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9236921F930C for ; Fri, 17 May 2013 01:35:22 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so3131477wgh.0 for ; Fri, 17 May 2013 01:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=v/rPnL5BkoeHk2fPaaKJv+cf5+m0nBWmzpvzNGCA+Dc=; b=NDRKegbcezA8GMz+6sLOG97JKV9oPL/SElKlboUTeUPv399F6Jn0xXvb+FyhOOd0El WCC7dVbD36IzHjnnRrd3lVe8ITl3qSoN6Wm4KTctzrgVGC2FdBAVQgJ3QN/pOG7OFYG5 I+8/M8DZSwBjbIbGJjSGeA8EbSqO2VJt+hoXuZJKoVrD6H8leIY55rWYRLOXNNTkp2hj uSgsepzrkXyc13ZhTXdWfTWOQvqgR1nzfqbc8Z1NCHPGF45wLQskVePBWxQWWfMpKx0R nohEVNU3fDQxP1duxd2e+Cu/f/ddJb46VYKDSWtfHDc23PjvtsCRT8J636rA2tVniWVe 2XzA== MIME-Version: 1.0 X-Received: by 10.180.37.133 with SMTP id y5mr31619573wij.20.1368779721654; Fri, 17 May 2013 01:35:21 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Fri, 17 May 2013 01:35:21 -0700 (PDT) In-Reply-To: <1972467.x8au6JTDZS@scott-latitude-e6320> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <2724237.eQuNQK5KLA@scott-latitude-e6320> <6.2.5.6.2.20130516154521.06ceef08@resistor.net> <1972467.x8au6JTDZS@scott-latitude-e6320> Date: Fri, 17 May 2013 01:35:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=e89a8f50335a15c92b04dce5dd93 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 08:35:27 -0000 --e89a8f50335a15c92b04dce5dd93 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 16, 2013 at 11:37 PM, Scott Kitterman wrote: > > > > 'If domain owners choose to publish SPF records and want to > support > > > > > > > > receivers making negative authorization determinations, then they > > > > MUST > > > > publish records that end in "-all", or redirect to other records > > > > that > > > > > > > > do, otherwise, no definitive determination of authorization can be > > > > made.' > > > > > > > > The document uses ADMD while there is "domain owners" in the > > > > above. I suggest reviewing that. > > > > > >Changed > > > > > > > The RFC 2119 MUST is a substantive change. Why is this a MUST? > > > > > >Because it's the literal truth. That's what you have to do to achieve > that > > >result. You won't interoperate with receivers in that way effectively > if > > >you don't. > > > > I mentioned this in another message: > > > > Andrew Sullivan, as an individual, commented about the text ( > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02784.html > > ). I suggest going with what was suggested or else the working > > group will be discussing Issue #33 again. > > OK. I still find it confusing that things that are needed for the > protocol to > function are not considered requirements, but changed. > Andrew's message drew the distinction between saying "necessary" and "MUST". There must be a nuance in there that I'm missing, because they're essentially synonymous to me; in fact, "-all" is the only way to achieve the stated goal for either party to the communication, so "MUST" seems proper to me, though either solution is also fine. Andrew, would you care to elaborate? > > > > 'Without explicit approval of the domain owner, checking other > > > > > > > > identities against SPF version 1 records is NOT RECOMMENDED > because > > > > there are cases that are known to give incorrect results.' > > > > > > > > How should this explicit approval be sought? This recommendation > > > > does not make sense. > > > > > >What I have now is "Documents that define other identities will have > > >to define > > >the method for explicit approval." > > > > "out-of-band" or "private" was suggested. I'll use one of them (I do > > not have any preference): > > > Without out-of-band approval of the ADMD, checking other identities > > against SPF version 1 records is NOT RECOMMENDED because there are > > cases that are known to give incorrect results. > > I don't think that's correct. One could get a new modifier added to the > SPF > modifier registry that would indicate a record can be used for other > purposes. > There are no such other purposes defined at the moment, but there's > absolutely > no need for out-of-band/private methods to accomplish this goal. > I'm confused now about what we're trying to say. I think the RFC is trying to say that it's a bad idea to try to check identifiers other than HELO and MAIL FROM using the check_host() function, unless you really know what you're doing and so does the sender. Is that correct? If not, what's the intent? Maybe with that clarified, I can suggest an alternative. > > > > 'Although invalid, malformed, or non-existent domains cause SPF > > > > checks > > > > > > > > to return "none" because no SPF record can be found, it has long > > > > been > > > > the policy of many MTAs to reject email from such domains, > > > > especially > > > > in the case of invalid "MAIL FROM". Rejecting email will prevent > > > > one > > > > method of circumventing of SPF records.' > > > > > > > > This text is already in RFC 4408. > > > > > > > > "Implementations have to take care to correctly extract the > > > > > > > > > from the data given with the SMTP MAIL FROM command as many MTAs > > > > will > > > > still accept such things as source routes ..." > > > > > > > > The definition of is: > > > > 'the domain portion of the "MAIL FROM" or "HELO" identity.' > > > > > > > > I am not sure whether it is even a definition. From an > > > > implementation perspective the last paragraph of Section 2.4 is > unclear. > > > > > >It seems clear to me. Could you expand on why you think it's > problematic > > >or provide recommended text. > > > > I mentioned in a previous comment that " definitions (not > > sure whether it is a definition) are mentioned in two places. I > > suggest fixing that and then getting back to the above". > > I don't understand what you think is wrong. Repeating the comment won't > help. > I did read it. I don't understand it. > I believe the issue is that the token is defined in two places in the bis draft, namely 2.4 and 4.1. We should consolidate them and ensure the consolidated one is complete. > > > > 'Generating non-delivery notifications to forged identities that > have > > > > > > > > failed the authorization check is a source of backscatter and > SHOULD > > > > be avoided.' > > > > > > > > This RFC 2119 SHOULD is not in RFC 4408. The above does not have > > > > anything to do with Sender Policy Framework. It was mentioned during > > > > WG discussions that "SPF can help the backscatter problem" [2]. This > > > > text may have been introduced in response to a review [3]. Is this > > > > an enhancement or a clarification? > > > > > >It's a clarification. > > > > In a previous comment I mentioned that "my reading of the above is > > that it is neither an enhancement or a clarification. I suggest > > removing the text". > > So you think it's not something that should be avoided? > I think it's something to be avoided, but the choice of generating an NDN has nothing to do with the SPF protocol itself. It's a local policy matter. I agree with strong language, but not SHOULD. > > > > 'ADMDs publishing SPF records SHOULD try to keep the number of > > > > > > > > "include" mechanisms and chained "redirect" modifiers to a > minimum.' > > > > > > > > What is the minimum? Note that this RFC 2119 SHOULD is in RFC 4408. > > > > > >It's the least an ADMD needs to properly describe the hosts > > >authorized to send > > >mail from their domain. It's minimum in the sense of no more than > needed. > > > > I commented previously about this "I didn't understand that as there > > wasn't any explanation for the RFC 2119 SHOULD. I suggest adding an > > explanation or rewriting the text so that the expression (see above) > > is clear". > > I'm failing to understand how to clarify that use the minimum means use as > little as you can. It's basically just explaining the dictionary to the > reader, so I think I don't understand what you think needs changing. > I think the issue here is that use of normative language ought to be associated with something more definitive than "a minimum", which is a bit mushy. Since there are caps on DNS query counts established elsewhere, does this SHOULD accomplish anything? On the other hand, I think we're not required to justify normative language that's just repeated from RFC4408, so we shouldn't burn too many cycles here. > > > > In Section 4.1: > > > > ' - the domain that provides the sought-after > authorization > > > > > > > > information; initially, the domain portion of the > "MAIL > > > > FROM" or "HELO" identity.' > > > > > > > > The above text is different from the text in Section 2.4. > > > > > >Yes, but not inconsistent with it. > > > > I suggest having the definition in one place for consistency. What I > > am looking at is consistency for the reader instead of where I > > believe that there is inconsistency. > > They are talking about different things relative to domains, so given the > organization, I don't see an easy way to do that. I'm open to suggestions. > The definition in 2.4 is less complete than that in 4.1, and also there are references to the one in 2.4. I propose copying the 4.1 version on top of the 2.4 version, remove the 4.1 definitions and have them refer to 2.4. > > > > In Section 4.4: > > > > "In accordance with how the records are published (see Section 3 > > > > > > > > above), a DNS query needs to be made for the name, > querying > > > > for type TXT only." > > > > > > > > I don't understand the sentence. > > > > > >What don't you understand? > > > > I commented previously about this: "I read the first paragraph of > > Section 4.4 as meaning that the DNS query is for Type TXT only. I > > suggest explaining that the record lookup is done by query for the > > SPF record described in Section 3. By the way, the text you suggested > > for Section 3 fits in nicely". > > Sorry, still confused. "I read the first paragraph of Section 4.4 as > meaning > that the DNS query is for Type TXT only." That's correct, so I think you > do > understand the sentence. > Given the choice to drop type 99 entirely, the word "only" can probably go. Other than that I don't see what part of the quoted sentence is ambiguous. How else might it be interpreted? > > > > > 'Alternatively, for a server failure (RCODE 2) result, > check_host() > > > > > > > > MAY track failures and treat multiple failures within 24 hours > for > > > > the same domain as "permerror".' > > > > > > > > This text is not in RFC 4408. I found a note in Issue #1 [5] and in > > > > a message [6]. > > > > > >Yes. This is a change to address an operational issue found during SPF > > >deployment. > > > > Stuart mentioned that: "This also solves the TIMEOUT for type 99 > > problem. Reporting a PermError for a broken name server would be very > > appropriate (and switching to checking TXT first while said failure > > is cached would also be permissible)". > > > > John commented that: "Not that I'm aware of. That looks to me like > > an optimization to do in the DNS cache, not in the client". > > > > In a previous comment I mentioned that: "Are there any > > implementations that do this? If so, that's the justification; it's > > practical experience. If not, we should consider dropping it". > > There was an issue. We discussed possible solutions (my initial hope was > to > make all SERVFAIL responses permerror) and this was the best solution we > came > up with. Because we want consistent results across implementations it's > not > just a local cache optimization. I think we should leave it since I don't > want to redo the entire process of solving the issue again. > I understand the intent, but there's quite a bit of onus on us to show that this is important enough to include. Are there implementations that do this, which would be evidence that it's important? > > > > In Section 4.6.2: > > > > "If there are no more mechanisms, the result is specified in > > > > > > > > Section 4.7." > > > > > > > > This sentence does not make sense. > > > > > >If I changed it to "If there are no more mechanisms, the result is > > >the default > > >result as described in section 4.7" would it be clearer? > > > > The follow text was proposed in a comment: > > > > "After all mechanisms have been processed and no matches are found, > the > > result is determined according to Section 4.7." > > OK, but you didn't answer the question. Would the text I proposed clarify > things for you? I like it better than the comment you brought up because I > think it's clearer, so I'd prefer to use it if you think it's OK. > I think they're synonymous. > > > > In Section 4.6.4: > > > > "SPF implementations MUST limit the total number of mechanisms and > > > > > > > > modifiers ("terms") that cause any DNS query to at most 10 during > > > > SPF > > > > evaluation." > > > > > > > > This was discussed on the mailing list [7]. > > > > > > > > "If this number is exceeded during a check, a permerror MUST be > > > > > > > > returned." > > > > > > > > I read this as if an implementation-specific limit is reached a > > > > permerror is returned. There are two RFC 2119 MUST in the > > > > above. That can be reduced to one MUST. > > > > > >Is there a problem with it the way it is? > > > > Here is my previous comment: > > > > For context we are at Section 4.6.4. I'll quote some text from it: > > > > "If this number is exceeded during a check, a permerror MUST be > returned." > > > > 'If this limit is exceeded, the "mx" mechanism MUST produce a > > "permerror" result.' > > > > 'If this limit is exceeded, all records other than the first 10 > > MUST be ignored.' > > > > I prefer not to discuss about the last one (see quoted text) again. > > In terms of coding it is easier if I am told to return a "permerror" > > results when DNS limit X is exceeded. That can be specified with one > > RFC 2119 MUST. I am taking in consideration the SecDir > > recommendation and interoperability. Speaking of interoperability > > the following text: > > > > 'SPF implementations MUST limit the total number of mechanisms and > > modifiers ("terms") that cause any DNS query to at most 10 during SPF > > evaluation.' > > > > does not encourage it because of the "at most". Section 4.6.4 does > > not make things easier for DNS operations as the reader cannot > > identify the limits easily due to the exceptions. I am ok with the > > exceptions. What I am suggesting is not to use two RFC 2119 MUST if > > it there is a way for it to be done with one RFC 2119 MUST. > > They are different limits that you have to code differently, so I think > combining them would reduce clarity for implementers. > I agree that there are actually three different things being limited here: - the mechanism count - the MX query count - the resulting A query count The "at most" thing is interesting. If I limit the DNS count to 2, for example, I'm still compliant but would likely get very different results than an implementation with a limit of 10. That's the same logic that we applied to say you can't go over that limit either. > > > 'MTAs or other processors SHOULD impose a limit on the maximum > amount > > > > > > > > of elapsed time to evaluate check_host(). Such a limit SHOULD > allow > > > > at least 20 seconds. If such a limit is exceeded, the result of > > > > authorization SHOULD be "temperror".' > > > > > > > > There are three RFC 2119 SHOULDs in the above. I suggest rewriting > > > > the text to reduce that. > > > > > >They are three different things. Why would rewriting it help? > > > > Here is my previous comment: > > > > Throughout the document the words "MTA", "other processors", "mail > > receivers", "SPF implementations" and "SPF verifiers" are used. That > > looks inconsistent to me. > > > > Here's an example of a rewrite: > > > > MTA or other processors SHOULD: > > > > (a) impose a limit on the maximum amount of elapsed time to > > evaluate check_host(). > > > > (b) allow for at least 20 seconds. > > > > (c) return a result of authorization of "temperror". > > I don't find that any clearer, probably less so than what's in the draft > now. > It's a common-factoring of the noun and SHOULD with otherwise identical meaning. Seems a stylistic choice to me more than anything else. > > > > "To prevent DoS attacks, more than 10 PTR names > > > > > > > > MUST NOT be looked up during the evaluation of a "ptr" mechanism > > > > (see Section 4.6.4)." > > > > > > > > The above restates a previous RFC 2119 MUST. > > > > > > > > "If used, proper PTR records MUST be in place for the domain's > hosts > > > > > > > > and the "ptr" mechanism SHOULD be one of the last mechanisms > > > > checked." > > > > > > > > Those RFC 2119 key words are not in RFC 4408. I don't see how this > > > > RFC 2119 change qualifies as a clarification or explanation. > > > > > >For the MUST, it flat out won't work if you don't have those (no > > >interoperation). For the SHOULD, it's an optimization. We can change > it > > >if you want. > > > > My previous comment was that: "It's a change. I suggest reverting it. > > Telling people who are using the "ptr" mechanism that they must have > > PTR records is stating the obvious". > > Obvious to you. Not obvious to everyone. > I think this is what Pete described as "shouting", i.e., using MUST where "needs to" is fine. PTR isn't part of SPF itself. > > > In Section 5.6: > > > > "ip6-network = " > > > > > > > > I suggest that the above reference be verified for correctness. > > > > > > > > In Section 5.7: > > > > 'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all' > > > > > > > > I'll flag this for review by DNS folks. > > > > > > > > In Section 6: > > > > 'The modifiers defined in this document ("redirect" and "exp") MAY > > > > > > > > appear anywhere in the record, but SHOULD appear at the end, > after > > > > all mechanisms.' > > > > > > > > This text is in RFC 4408. I would label the RFC 2119 usage as > > > > defective. > > > > > >Why? > > > > My previous comment was: "The text tells me that it is ok if the > > modifiers appear anywhere but they should appear at the end after all > > mechanisms. It would be clearer to say that it should appear after > > all mechanisms". > > That is defective use of 2119 language? I disagree that that would be > clearer. > "MAY" is essentially meaningless except perhaps to emphasize that the implementer has a choice with no protocol consequence. You could make it "can" and have the same effect. > > > > In Section 6.2: > > > > "Since the explanation string is intended for an SMTP response and > > > > [RFC5321] Section 2.4 says that responses are in [US-ASCII], the > > > > explanation string MUST be limited to US-ASCII.' > > > > > > > > It would be easier to defer to RFC 5321 instead of setting a RFC 2119 > > > > requirement in this draft. I note that this requirement was not in > RFC > > > > 4408. > > > > > >It's not a new requirement. If you couldn't find it in 4408, then that > > >means we've succeeded in making the actual requirement more clear. > > > > None of the WG participants have pointed out where the actual > > requirement (RFC "MUST") is in RFC 4408. If the text was in RFC 4408 > > it would be possible for a WG participant to point me to it. There > > was a comment about 'this could be expressed non-normatively (e.g. > > "needs to be")'. > > If it's not ASCII, it won't interoperate (at all). Isn't that exactly > where > 2119 language is supposed to be used? Regardless of how it's worded in > 4408, > putting non-ASCII characters in explanation strings does not and has never > worked. At most it's making something explicit that was implicit before, > which is a good clarification I'd think. > I support this change of adding MUST. An SPF implementer does not necessarily know how the mechanism by which SMTP will be accessed to relay the result, and we don't specify anything about encoding special characters to 7-bit. We could MUST this, or we could MUST an RFC2047-style encoding or escaping of some kind. Guess which one I prefer. The other alternative I can think of is to drop the MUST here but make it clear that if the explanation string isn't 7-bit clean, someone's going to have to make it SMTP-compliant somehow before it's returned in the SMTP reply. > > > > "Software SHOULD make it clear that the explanation string > > > > comes from a third party." > > > > > > > > I could not understand what that means in RFC 2119 terms. The draft > > > > uses RFC 2119 key words by example instead of providing an > explanation. > > > > > >I don't understand the comment. > > > > There was a comment from Murray: "we're talking about > > interoperability between humans here, and not between implementations". > > We're talking about avoiding security issues caused by the humans getting > confused. > If this document defines a protocol that operates between senders and receivers, then wrapping explanation text (which is for humans) in more explanation text is out of scope, at least in a normative sense. That said, this was in RFC4408 and is unchanged here. I don't think it's worth our energy at this stage. > > > > > "This SHOULD be a fully qualified domain name, but if one does not > > > > > > > > exist (as when the checking is done by a MUA) or if policy > > > > restrictions > > > > dictate otherwise, the word "unknown" SHOULD be substituted." > > > > > > > > The RFC 2119 key words are in RFC 2119. I don't know what to say. > > > > > >OK. > > > > Murray comemnted: "I think that looks fine as-is, though we could > > change the first SHOULD to "ought to" because it's a transformation > > of other input and not an implementation choice. (And I assume you > > mean they were in RFC4408.) > > Since the values end up in log files and Received-SPF/authentication > results > header fields that are provided to be processed on other systems, it is an > interoperability issue. Having consistency helps interoperability. I'd > prefer to leave it. > My point here is that the first SHOULD is essentially saying "the hostname of the machine SHOULD be an FQDN", but this is ineffective because the person configuring this host might not know a thing about SPF or this requirement and call the machine "banana". What does the SPF module do with this SHOULD now? "ought to", "is typically", "is ideally", etc. > > > > It is odd to have RFC 2119 requirements under a "Notes" heading. > > > > > >They aren't really notes in that sense. If you have a better name for > the > > >section, please suggest. > > > > I suggest removing all the RFC 2119 requirements in Section 7.3 if > > the working group cannot find a way to fix this. > > Why? How about if we call it "Details" instead of Notes? > Macro Processing Details Dumping the RFC2119 language in there is a bad idea. It's all interoperability stuff. > > > > > In Section 8.2: > > > > 'A "neutral" result MUST be treated exactly like the "none" > result; > > > > the distinction exists only for informational purposes.' > > > > > > > > Why is an existing RFC 2119 restated? > > > > > >Because of the structure of the document that the WG came up with. I > don't > > >find a good way to avoid it and not make it less readable. > > > > I'll leave this issue open as it was mentioned in the AppsDir review. > I'll help with this if needed. > > > > In Section 10.1.1: > > > > > > > > There was a comment from Authur Thisell about the table [11] in this > > > > sub-section. > > > > > >There didn't seem to be support for changing it though. > > > > I read RFC 4408 and I did not find any table similar to the one in > > Section 10.1.1 of draft-ietf-spfbis-4408bis-14. My understanding of > > "support for changing text" is that the text is proposed on the > > working group mailing list and it is added if there is agreement. I > > didn't find any messages about that in the mailing list > > archives. What I found was a message disagreeing with a change which > > was made in the draft which was posted together with an explanation > > about why there was disagreement. In my opinion there wasn't any > > support for making that change in the draft. > > The text came from Alessandro and was discussed on the list. Arthur's > comment > came later. The table is new, but is only a new expression of information > that was in 4408. It does not create any new requirements. > When we developed RFC6686, there were several people who responded well to the introduction of tables to show our survey results. I seem to recall people liking this table in here as well, though I admit not having looked at the archives tonight. If it can be confirmed that the details in the table match the prose, I think it's fine to leave it in. > > > > In Section 10.1.2: > > > > "Publishing SPF records for domains that send no mail is > > > > > > > > a well established best practice." > > > > > > > > I am not aware of that best practice. I did a few DNS queries: > > > > > > > > ;; QUESTION SECTION: > > > > ;bing.com. IN TXT > > > > > > > > ;; ANSWER SECTION: > > > > bing.com. 3600 IN TXT "v=msv1 > > > > t=6097A7EA-53F7-4028-BA76-6869CB284C54" > > > > > > > > ;; QUESTION SECTION: > > > > ;com.com. IN TXT > > > > > > > > ;; ANSWER SECTION: > > > > com.com. 293 IN TXT > > > > > "google-site-verification:esSnoZdChIkkfCfS9MMgqNhE0yaXfnnZWdZPuBf7e8k" > > > > > >OK. See > > > > http://www.bits.org/publications/security/BITSEmailAuthenticationFeb2013.pd > > >f > > I suggest "good practice" as mentioned by Alessandro. > > What's wrong with the way it is? I think the current text is accurate. > The OpenDKIM SPF data recorded 1157 domains with "v=spf1 -all" records. > > > > In Section 11.5: > > > > "An SPF compliant receiver gathers information from the SMTP > commands > > > > > > > > it receives and from the published DNS records of the sending > domain > > > > holder" > > > > > > > > I suggest explaining the untrusted part. > > > > > >That's what the section does. > > > > There was a comment: "A second sentence indicating most of that > > input is unverified is probably in order, with references if possible". > > I think the section explains exactly that, so some text would help. > I think it falls short, because it's not clear to a neophyte reader that those data are essentially untrustable. So append: All of these pieces of information are generated by actors outside of the authority of the receiver, and thus are not guaranteed to be accurate or legitimate. > > > Where can I find "Designated Mailers Protocol"? > > > > > >See draft-fecyk-dsprotocol > > > > Ok. As a note for the working group, I could not find the draft. > > First Google hit for draft-fecyk-dsprotocol is: > > http://tools.ietf.org/html/draft-fecyk-dsprotocol-04 > > RFC5451 cites a dnsop I-D that expired a long time ago, so there's precedent for referring to that even though it's long dead. > > > > Where can I find "Domain-Authorized SMTP Mail"? > > > > > >I don't have a copy of this. > > > > I suggest dropping the reference. > > SPF did not spring from nothing. It gathered a number of concepts, added a > few things, and managed to be successful. I think it would be more > appropriate to leave it as it shows part of the trace back to the origin of > the protocol. > I would suggest the co-chairs consult the AD or the RFC Editor about what can be done in a situation where it's appropriate to cite known prior work where an actual reference is no longer available. > > > > I note that there are 48 pages in RFC 4408. There are 78 pages in > > > > this draft. A significant amount of text has been added in the > > > > Appendix (over 20 pages). I doubt that the text has been carefully > > > > reviewed. I may be asked for an explanation about all that once the > > > > draft leaves this working group. > > > > > >Why wait? > > > > I am not the person doing the IESG evaluation. > > OK. I misunderstood your comment. I think you're wrong about the lack of > review though. > I concur; there have been several reviews, including by AppsDir. A non-trivial amount of the bulk is the reorganization, which added a lot of blank space around a lot of new section headings. I can't identify any gigantic but gratuitous changes. > > > > > In Appendix I: > > > > > > > > Appendix I is about "Protocol Status". This draft is intended as a > > > > Proposed Standard. From an IETF perspective that is what it will > > > > be. Describing it as something different can be misleading. > > > > > > > > "[RFC4408] was designed to clearly document the protocol defined > by > > > > > > > > earlier draft specifications of SPF as used in existing > > > > implementations. This updated specification is intended to > clarify > > > > identified ambiguities in [RFC4408], resolve techincal issues > > > > identified in post-RFC 4408 deplyment experience, and document > > > > widely > > > > deployed extensions to SPF that have been developed since > [RFC4408] > > > > was published." > My browser identifies two typos in there ("techincal", "deplyment"). > > > > > > > > Extensions to the SPF protocol are clearly mentioned in the charter > > > > as being out of scope. The "document widely deployed extensions" is > > > > problematic. > > > > > >The charter specifically allows for "addition of any enhancements > > >that have already gained widespread support". > > > > I read the discussion about the charter again. It is my > > understanding that extensions to the SPF protocol is > > out-of-scope. The working group did not add a work item during the > > chartering discussion as it was considered as an extension to the > protocol. > > It was also not widely deployed. Should I take authentication-results out > of > the draft then? > Personally, I think this whole appendix can be tagged with "[For IESG information only]" and removed prior to publication. It's the kind of thing we usually include in shepherd writeups and not in the RFCs themselves. -MSK --e89a8f50335a15c92b04dce5dd93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 16, 2013 at 11:37 PM, Scott Kitterman <spf2@= kitterman.com> wrote:
> > > =A0 =A0'If domain owners = choose to publish SPF records and want to support
> > >
> > > =A0 =A0 receivers making negative authorization determinatio= ns, then they
> > > =A0 =A0 MUST
> > > =A0 =A0 publish records that end in "-all", or red= irect to other records
> > > =A0 =A0 that
> > >
> > > do, otherwise, no definitive determination of authorization = can be
> > > made.'
> > >
> > > The document uses ADMD while there is "domain owners&qu= ot; in the
> > > above. =A0I suggest reviewing that.
> >
> >Changed
> >
> > > The RFC 2119 MUST is a substantive change. =A0Why is this a = MUST?
> >
> >Because it's the literal truth. =A0That's what you have to= do to achieve that
> >result. =A0You won't interoperate with receivers in that way e= ffectively if
> >you don't.
>
> I mentioned this in another message:
>
> Andrew Sullivan, as an individual, commented about the text (
> http://www.ietf.org/mail-archive/web/spfbis/curre= nt/msg02784.html
> =A0 ). I suggest going with what was suggested or else the working
> group will be discussing Issue #33 again.

OK. =A0I still find it confusing that things that are needed for the = protocol to
function are not considered requirements, but changed.

Andrew's message drew the distinction between saying &q= uot;necessary" and "MUST".=A0 There must be a nuance in ther= e that I'm missing, because they're essentially synonymous to me; i= n fact, "-all" is the only way to achieve the stated goal for eit= her party to the communication, so "MUST" seems proper to me, tho= ugh either solution is also fine.=A0 Andrew, would you care to elaborate? =A0
> > > =A0 =A0'Without explicit approval of t= he domain owner, checking other
> > >
> > > =A0 =A0 identities against SPF version 1 records is NOT RECO= MMENDED because
> > > =A0 =A0 there are cases that are known to give incorrect res= ults.'
> > >
> > > How should this explicit approval be sought? =A0This recomme= ndation
> > > does not make sense.
> >
> >What I have now is "Documents that define other identities wi= ll have
> >to define
> >the method for explicit approval."
>
> "out-of-band" or "private" was suggested. =A0I'= ;ll use one of them (I do
> not have any preference):

> =A0 =A0 =A0Without out-of-band approval of the ADMD, checking other id= entities
> =A0 =A0 =A0against SPF version 1 records is NOT RECOMMENDED because th= ere are
> =A0 =A0 =A0cases that are known to give incorrect results.

I don't think that's correct. =A0One could get a new modifier= added to the SPF
modifier registry that would indicate a record can be used for other purpos= es.
There are no such other purposes defined at the moment, but there's abs= olutely
no need for out-of-band/private methods to accomplish this goal.

I'm confused now about what we're trying = to say. =A0 I think the RFC is trying to say that it's a bad idea to tr= y to check identifiers other than HELO and MAIL FROM using the check_host()= function, unless you really know what you're doing and so does the sen= der.=A0 Is that correct?=A0 If not, what's the intent?=A0 Maybe with th= at clarified, I can suggest an alternative.
=A0
> > > =A0 =A0'Alth= ough invalid, malformed, or non-existent domains cause SPF
> > > =A0 =A0checks
> > >
> > > =A0 =A0 to return "none" because no SPF record can= be found, it has long
> > > =A0 =A0 been
> > > =A0 =A0 the policy of many MTAs to reject email from such do= mains,
> > > =A0 =A0 especially
> > > =A0 =A0 in the case of invalid "MAIL FROM". =A0Rej= ecting email will prevent
> > > =A0 =A0 one
> > > =A0 =A0 method of circumventing of SPF records.'
> > >
> > > This text is already in RFC 4408.
> > >
> > > =A0 =A0"Implementations have to take care to correctly = extract the <domain>
> > >
> > > =A0 =A0 from the data given with the SMTP MAIL FROM command = as many MTAs
> > > =A0 =A0 will
> > > =A0 =A0 still accept such things as source routes ..."<= br> > > >
> > > The definition of <domain> is:
> > > =A0 =A0'the domain portion of the "MAIL FROM" = or "HELO" identity.'
> > >
> > > I am not sure whether it is even a definition. =A0From an > > > implementation perspective the last paragraph of Section 2.4= is unclear.
> >
> >It seems clear to me. =A0Could you expand on why you think it'= s problematic
> >or provide recommended text.
>
> I mentioned in a previous comment that "<domain> definition= s (not
> sure whether it is a definition) are mentioned in two places. =A0I
> suggest fixing that and then getting back to the above".

I don't understand what you think is wrong. =A0Repeating the comm= ent won't help.
I did read it. =A0I don't understand it.

I believe the issue is that the <domain> token is defined in tw= o places in the bis draft, namely 2.4 and 4.1.=A0 We should consolidate the= m and ensure the consolidated one is complete.


> > > =A0 =A0'Generating non-delivery notifications to forged = identities that have
> > >
> > > =A0 =A0 failed the authorization check is a source of backsc= atter and SHOULD
> > > =A0 =A0 be avoided.'
> > >
> > > This RFC 2119 SHOULD is not in RFC 4408. =A0The above does n= ot have
> > > anything to do with Sender Policy Framework. =A0It was menti= oned during
> > > WG discussions that "SPF can help the backscatter probl= em" [2]. =A0This
> > > text may have been introduced in response to a review [3]. = =A0Is this
> > > an enhancement or a clarification?
> >
> >It's a clarification.
>
> In a previous comment I mentioned that "my reading of the above i= s
> that it is neither an enhancement or a clarification. =A0I suggest
> removing the text".

So you think it's not something that should be avoided?

I think it's something to be avoided, but th= e choice of generating an NDN has nothing to do with the SPF protocol itsel= f.=A0 It's a local policy matter.=A0 I agree with strong language, but = not SHOULD.
=A0
> > > =A0 =A0'ADMD= s publishing SPF records SHOULD try to keep the number of
> > >
> > > =A0 =A0 "include" mechanisms and chained "red= irect" modifiers to a minimum.'
> > >
> > > What is the minimum? =A0Note that this RFC 2119 SHOULD is in= RFC 4408.
> >
> >It's the least an ADMD needs to properly describe the hosts > >authorized to send
> >mail from their domain. =A0It's minimum in the sense of no mor= e than needed.
>
> I commented previously about this "I didn't understand that a= s there
> wasn't any explanation for the RFC 2119 SHOULD. =A0I suggest addin= g an
> explanation or rewriting the text so that the expression (see above) > is clear".

I'm failing to understand how to clarify that use the minimum mea= ns use as
little as you can. =A0It's basically just explaining the dictionary to = the
reader, so I think I don't understand what you think needs changing.

I think the issue here is that use of nor= mative language ought to be associated with something more definitive than = "a minimum", which is a bit mushy.=A0 Since there are caps on DNS= query counts established elsewhere, does this SHOULD accomplish anything?<= br>
On the other hand, I think we're not required to justify= normative language that's just repeated from RFC4408, so we shouldn= 9;t burn too many cycles here.
=A0
> > > In Section 4.1:
> > > =A0 =A0'<domain> - the domain that provides the so= ught-after authorization
> > >
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0information; initially, the d= omain portion of the "MAIL
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0FROM" or "HELO"= ; identity.'
> > >
> > > The above text is different from the text in Section 2.4. > >
> >Yes, but not inconsistent with it.
>
> I suggest having the definition in one place for consistency. =A0What = I
> am looking at is consistency for the reader instead of where I
> believe that there is inconsistency.

They are talking about different things relative to domains, so given= the
organization, I don't see an easy way to do that. =A0I'm open to su= ggestions.

The definition in 2.4 is les= s complete than that in 4.1, and also there are references to the one in 2.= 4.=A0 I propose copying the 4.1 version on top of the 2.4 version, remove t= he 4.1 definitions and have them refer to 2.4.
=A0
> > > In Section 4.4:
> > > =A0 =A0"In accordance with how the records are publishe= d (see Section 3
> > >
> > > =A0 =A0 above), a DNS query needs to be made for the <dom= ain> name, querying
> > > =A0 =A0 for type TXT only."
> > >
> > > I don't understand the sentence.
> >
> >What don't you understand?
>
> I commented previously about this: "I read the first paragraph of=
> Section 4.4 as meaning that the DNS query is for Type TXT only. I
> suggest explaining that the record lookup is done by query for the
> SPF record described in Section 3. By the way, the text you suggested<= br> > for Section 3 fits in nicely".

Sorry, still confused. =A0 "I read the first paragraph of Sectio= n 4.4 as meaning
that the DNS query is for Type TXT only." =A0That's correct, so I = think you do
understand the sentence.

Given the choi= ce to drop type 99 entirely, the word "only" can probably go.=A0 = Other than that I don't see what part of the quoted sentence is ambiguo= us.=A0 How else might it be interpreted?
=A0

> > > =A0 =A0'Alternatively, for a server failure (RCODE 2) re= sult, check_host()
> > >
> > > =A0 =A0 MAY track failures and treat multiple failures withi= n 24 hours for
> > > =A0 =A0 the same domain as "permerror".'
> > >
> > > This text is not in RFC 4408. =A0I found a note in Issue #1 = [5] and in
> > > a message [6].
> >
> >Yes. =A0This is a change to address an operational issue found dur= ing SPF
> >deployment.
>
> Stuart mentioned that: "This also solves the TIMEOUT for type 99<= br> > problem. Reporting a PermError for a broken name server would be very<= br> > appropriate (and switching to checking TXT first while said failure > is cached would also be permissible)".
>
> John commented that: =A0"Not that I'm aware of. =A0That looks= to me like
> an optimization to do in the DNS cache, not in the client".
>
> In a previous comment I mentioned that: "Are there any
> implementations that do this? If so, that's the justification; it&= #39;s
> practical experience. If not, we should consider dropping it".
There was an issue. =A0We discussed possible solutions (my initial ho= pe was to
make all SERVFAIL responses permerror) and this was the best solution we ca= me
up with. =A0Because we want consistent results across implementations it= 9;s not
just a local cache optimization. =A0I think we should leave it since I don&= #39;t
want to redo the entire process of solving the issue again.

I understand the intent, but there= 9;s quite a bit of onus on us to show that this is important enough to incl= ude.=A0 Are there implementations that do this, which would be evidence tha= t it's important?
=A0
> > > In Section 4.6.2:
> > > =A0 =A0"If there are no more mechanisms, the result is = specified in
> > >
> > > =A0 =A0 Section 4.7."
> > >
> > > This sentence does not make sense.
> >
> >If I changed it to "If there are no more mechanisms, the resu= lt is
> >the default
> >result as described in section 4.7" would it be clearer?
>
> The follow text was proposed in a comment:
>
> =A0 =A0"After all mechanisms have been processed and no matches a= re found, the
> =A0 =A0 result is determined according to Section 4.7."

OK, but you didn't answer the question. =A0Would the text I propo= sed clarify
things for you? =A0I like it better than the comment you brought up because= I
think it's clearer, so I'd prefer to use it if you think it's O= K.

I think they're synonymous.
= =A0
> > > In Section 4.6.4:
> > > =A0 =A0"SPF implementations MUST limit the total number= of mechanisms and
> > >
> > > =A0 =A0 modifiers ("terms") that cause any DNS que= ry to at most 10 during
> > > =A0 =A0 SPF
> > > =A0 =A0 evaluation."
> > >
> > > This was discussed on the mailing list [7].
> > >
> > > =A0 =A0"If this number is exceeded during a check, a pe= rmerror MUST be
> > >
> > > returned."
> > >
> > > I read this as if an implementation-specific limit is reache= d a
> > > permerror is returned. =A0There are two RFC 2119 MUST in the=
> > > above. =A0That can be reduced to one MUST.
> >
> >Is there a problem with it the way it is?
>
> Here is my previous comment:
>
> For context we are at Section 4.6.4. =A0I'll quote some text from = it:
>
> =A0 "If this number is exceeded during a check, a permerror MUST = be returned."
>
> =A0 'If this limit is exceeded, the "mx" mechanism MUST = produce a
> =A0 =A0"permerror" result.'
>
> =A0 'If this limit is exceeded, all records other than the first 1= 0
> =A0 =A0MUST be ignored.'
>
> I prefer not to discuss about the last one (see quoted text) again. > In terms of coding it is easier if I am told to return a "permerr= or"
> results when DNS limit X is exceeded. That can be specified with one > RFC 2119 MUST. =A0I am taking in consideration the SecDir
> recommendation and interoperability. =A0Speaking of interoperability > the following text:
>
> =A0 =A0'SPF implementations MUST limit the total number of mechani= sms and
> =A0 =A0 modifiers ("terms") that cause any DNS query to at m= ost 10 during SPF
> =A0 =A0 evaluation.'
>
> does not encourage it because of the "at most". Section 4.6.= 4 does
> not make things easier for DNS operations as the reader cannot
> identify the limits easily due to the exceptions. I am ok with the
> exceptions. What I am suggesting is not to use two RFC 2119 MUST if > it there is a way for it to be done with one RFC 2119 MUST.

They are different limits that you have to code differently, so= I think
combining them would reduce clarity for implementers.
=
I agree that there are actually three different things being limi= ted here:

- the mechanism count
- the MX query count
- the resulting A query count

The "at most" thing is interesting.=A0 If I limit the= DNS count to 2, for example, I'm still compliant but would likely get = very different results than an implementation with a limit of 10.=A0 That&#= 39;s the same logic that we applied to say you can't go over that limit= either.

> > > =A0 =A0'MTAs or other processo= rs SHOULD impose a limit on the maximum amount
> > >
> > > =A0 =A0 of elapsed time to evaluate check_host(). =A0Such a = limit SHOULD allow
> > > =A0 =A0 at least 20 seconds. =A0If such a limit is exceeded,= the result of
> > > =A0 =A0 authorization SHOULD be "temperror".'<= br> > > >
> > > There are three RFC 2119 SHOULDs in the above. =A0I suggest = rewriting
> > > the text to reduce that.
> >
> >They are three different things. =A0Why would rewriting it help? >
> Here is my previous comment:
>
> Throughout the document the words "MTA", "other process= ors", "mail
> receivers", "SPF implementations" and "SPF verifie= rs" are used. That
> looks inconsistent to me.
>
> Here's an example of a rewrite:
>
> =A0 =A0MTA or other processors SHOULD:
>
> =A0 =A0(a) impose a limit on the maximum amount of elapsed time to
> evaluate check_host().
>
> =A0 =A0(b) allow for at least 20 seconds.
>
> =A0 =A0(c) return a result of authorization of "temperror".<= br>
I don't find that any clearer, probably less so than what's i= n the draft now.

It's a common-fact= oring of the noun and SHOULD with otherwise identical meaning.=A0 Seems a s= tylistic choice to me more than anything else.
=A0
> > > =A0 =A0"To = prevent DoS attacks, more than 10 PTR names
> > >
> > > =A0 =A0 MUST NOT be looked up during the evaluation of a &qu= ot;ptr" mechanism
> > > =A0 =A0 (see Section 4.6.4)."
> > >
> > > The above restates a previous RFC 2119 MUST.
> > >
> > > =A0 =A0"If used, proper PTR records MUST be in place fo= r the domain's hosts
> > >
> > > =A0 =A0 and the "ptr" mechanism SHOULD be one of t= he last mechanisms
> > > =A0 =A0 checked."
> > >
> > > Those RFC 2119 key words are not in RFC 4408. =A0I don't= see how this
> > > RFC 2119 change qualifies as a clarification or explanation.=
> >
> >For the MUST, it flat out won't work if you don't have tho= se (no
> >interoperation). =A0For the SHOULD, it's an optimization. =A0W= e can change it
> >if you want.
>
> My previous comment was that: "It's a change. I suggest rever= ting it.
> Telling people who are using the "ptr" mechanism that they m= ust have
> PTR records is stating the obvious".

Obvious to you. =A0Not obvious to everyone.

=
I think this is what Pete described as "shouting", i.e= ., using MUST where "needs to" is fine.=A0 PTR isn't part of = SPF itself.

> > > In Section 5.6:
> > > =A0 =A0"ip6-network =A0 =A0 =A0=3D <as per [RFC 4291= ], section 2.2>"
> > >
> > > I suggest that the above reference be verified for correctne= ss.
> > >
> > > In Section 5.7:
> > > =A0 =A0'v=3Dspf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all= 9;
> > >
> > > I'll flag this for review by DNS folks.
> > >
> > > In Section 6:
> > > =A0 =A0'The modifiers defined in this document ("re= direct" and "exp") MAY
> > >
> > > =A0 =A0 appear anywhere in the record, but SHOULD appear at = the end, after
> > > =A0 =A0 all mechanisms.'
> > >
> > > This text is in RFC 4408. =A0I would label the RFC 2119 usag= e as
> > > defective.
> >
> >Why?
>
> My previous comment was: "The text tells me that it is ok if the<= br> > modifiers appear anywhere but they should appear at the end after all<= br> > mechanisms. It would be clearer to say that it should appear after
> all mechanisms".

That is defective use of 2119 language? =A0I disagree that that would= be
clearer.

"MAY" is essentially= meaningless except perhaps to emphasize that the implementer has a choice = with no protocol consequence.=A0 You could make it "can" and have= the same effect.
=A0
> > > In Section 6.2:
> > > =A0 =A0"Since the explanation string is intended for an= SMTP response and
> > > =A0 =A0 [RFC5321] Section 2.4 says that responses are in [US= -ASCII], the
> > > =A0 =A0 explanation string MUST be limited to US-ASCII.'=
> > >
> > > It would be easier to defer to RFC 5321 instead of setting a= RFC 2119
> > > requirement in this draft. =A0I note that this requirement w= as not in RFC
> > > 4408.
> >
> >It's not a new requirement. =A0If you couldn't find it in = 4408, then that
> >means we've succeeded in making the actual requirement more cl= ear.
>
> None of the WG participants have pointed out where the actual
> requirement (RFC "MUST") is in RFC 4408. =A0If the text was = in RFC 4408
> it would be possible for a WG participant to point me to it. =A0 There=
> was a comment about 'this could be expressed non-normatively (e.g.=
> "needs to be")'.

If it's not ASCII, it won't interoperate (at all). =A0Isn'= ;t that exactly where
2119 language is supposed to be used? =A0Regardless of how it's worded = in 4408,
putting non-ASCII characters in explanation strings does not and has never<= br> worked. =A0At most it's making something explicit that was implicit bef= ore,
which is a good clarification I'd think.

I support this change of adding MUST.=A0 An SPF implementer does not = necessarily know how the mechanism by which SMTP will be accessed to relay = the result, and we don't specify anything about encoding special charac= ters to 7-bit.=A0 We could MUST this, or we could MUST an RFC2047-style enc= oding or escaping of some kind.=A0 Guess which one I prefer.

The other alternative I can think of is to drop the MUST her= e but make it clear that if the explanation string isn't 7-bit clean, s= omeone's going to have to make it SMTP-compliant somehow before it'= s returned in the SMTP reply.


> > > =A0 =A0"Software SHOULD make it clear that the explanat= ion string
> > > =A0 =A0 comes from a third party."
> > >
> > > I could not understand what that means in RFC 2119 terms. = =A0The draft
> > > uses RFC 2119 key words by example instead of providing an e= xplanation.
> >
> >I don't understand the comment.
>
> There was a comment from Murray: =A0"we're talking about
> interoperability between humans here, and not between implementations&= quot;.

We're talking about avoiding security issues caused by the humans= getting
confused.

If this document defines a protoco= l that operates between senders and receivers, then wrapping explanation te= xt (which is for humans) in more explanation text is out of scope, at least= in a normative sense.

That said, this was in RFC4408 and is unchanged here.=A0 I don't th= ink it's worth our energy at this stage.
=A0
> > > =A0 =A0"This SHOULD be a fully qualified domain name, b= ut if one does not
> > >
> > > =A0 =A0 exist (as when the checking is done by a MUA) or if = policy
> > > =A0 =A0 restrictions
> > > =A0 =A0 dictate otherwise, the word "unknown" SHOU= LD be substituted."
> > >
> > > The RFC 2119 key words are in RFC 2119. =A0I don't know = what to say.
> >
> >OK.
>
> Murray comemnted: "I think that looks fine as-is, though we could=
> change the first SHOULD to "ought to" because it's a tra= nsformation
> of other input and not an implementation choice. =A0(And I assume you<= br> > mean they were in RFC4408.)

Since the values end up in log files and Received-SPF/authentication = results
header fields that are provided to be processed on other systems, it is an<= br> interoperability issue. =A0Having consistency helps interoperability. =A0I&= #39;d
prefer to leave it.

My point here is th= at the first SHOULD is essentially saying "the hostname of the machine= SHOULD be an FQDN", but this is ineffective because the person config= uring this host might not know a thing about SPF or this requirement and ca= ll the machine "banana".=A0 What does the SPF module do with this= SHOULD now?

"ought to", "is typically", "is ide= ally", etc.

=A0
> > > It is odd to have RFC 2119 requirements un= der a "Notes" heading.
> >
> >They aren't really notes in that sense. =A0If you have a bette= r name for the
> >section, please suggest.
>
> I suggest removing all the RFC 2119 requirements in Section 7.3 if
> the working group cannot find a way to fix this.

Why? =A0How about if we call it "Details" instead of Notes?=

Macro Processing Details

=
Dumping the RFC2119 language in there is a bad idea.=A0 It's all i= nteroperability stuff.
=A0

> > > In Section 8.2:
> > > =A0 =A0'A "neutral" result MUST be treated exa= ctly like the "none" result;
> > > =A0 =A0 the distinction exists only for informational purpos= es.'
> > >
> > > Why is an existing RFC 2119 restated?
> >
> >Because of the structure of the document that the WG came up with.= =A0I don't
> >find a good way to avoid it and not make it less readable.
>
> I'll leave this issue open as it was mentioned in the AppsDir revi= ew.

I'll help with this= if needed.
=A0
> > > In Section 10.1.1:
> > >
> > > There was a comment from Authur Thisell about the table [11]= in this
> > > sub-section.
> >
> >There didn't seem to be support for changing it though.
>
> I read RFC 4408 and I did not find any table similar to the one in
> Section 10.1.1 of draft-ietf-spfbis-4408bis-14. =A0My understanding of=
> "support for changing text" is that the text is proposed on = the
> working group mailing list and it is added if there is agreement. =A0I=
> didn't find any messages about that in the mailing list
> archives. =A0What I found was a message disagreeing with a change whic= h
> was made in the draft which was posted together with an explanation > about why there was disagreement. =A0In my opinion there wasn't an= y
> support for making that change in the draft.

The text came from Alessandro and was discussed on the list. = =A0Arthur's comment
came later. =A0The table is new, but is only a new expression of informatio= n
that was in 4408. =A0It does not create any new requirements.

When we developed RFC6686, there were several people= who responded well to the introduction of tables to show our survey result= s.=A0 I seem to recall people liking this table in here as well, though I a= dmit not having looked at the archives tonight.=A0 If it can be confirmed t= hat the details in the table match the prose, I think it's fine to leav= e it in.
=A0
> > > In Section 10.1.2:
> > > =A0 =A0"Publishing SPF records for domains that send no= mail is
> > >
> > > =A0 =A0 a well established best practice."
> > >
> > > I am not aware of that best practice. =A0I did a few DNS que= ries:
> > >
> > > ;; QUESTION SECTION:
> > > ;bing.com.= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IN =A0 =A0 =A0TXT
> > >
> > > ;; ANSWER SECTION:
> > > bing.com. = =A0 =A0 =A0 =A0 =A0 =A0 =A0 3600 =A0 =A0IN =A0 =A0 =A0TXT =A0 =A0 "v= =3Dmsv1
> > > t=3D6097A7EA-53F7-4028-BA76-6869CB284C54"
> > >
> > > ;; QUESTION SECTION:
> > > ;com.com. = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IN =A0 =A0 =A0TXT
> > >
> > > ;; ANSWER SECTION:
> > > com.com. = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0293 =A0 =A0 IN =A0 =A0 =A0TXT
> > > "google-site-verification:esSnoZdChIkkfCfS9MMgqNhE0yaXf= nnZWdZPuBf7e8k"
> >
> >OK. =A0See
> >http://www.bits.org/publications/se= curity/BITSEmailAuthenticationFeb2013.pd
> >f
> I suggest "good practice" as mentioned by Alessandro.

What's wrong with the way it is? =A0I think the current text is a= ccurate.

The OpenDKIM SPF data recorded= 1157 domains with "v=3Dspf1 -all" records.
=A0
> > > In Section 11.5:
> > > =A0 =A0"An SPF compliant receiver gathers information f= rom the SMTP commands
> > >
> > > =A0 =A0 it receives and from the published DNS records of th= e sending domain
> > > =A0 =A0 holder"
> > >
> > > I suggest explaining the untrusted part.
> >
> >That's what the section does.
>
> There was a comment: =A0"A second sentence indicating most of tha= t
> input is unverified is probably in order, with references if possible&= quot;.

I think the section explains exactly that, so some text would h= elp.

I think it falls short, because it= 's not clear to a neophyte reader that those data are essentially untru= stable.

So append:

All of these pieces of informat= ion are generated by actors outside of the authority of the receiver, and t= hus are not guaranteed to be accurate or legitimate.

> > > Where can I find "Designated Mailers Protocol"?
> >
> >See draft-fecyk-dsprotocol
>
> Ok. =A0As a note for the working group, I could not find the draft.
First Google hit for draft-fecyk-dsprotocol is:

http://tools.ietf.org/html/draft-fecyk-dsprotocol-04


RFC5451 cites = a dnsop I-D that expired a long time ago, so there's precedent for refe= rring to that even though it's long dead.
=A0
> > > Where can I find "Domain-Authorized SMTP Mail"? > >
> >I don't have a copy of this.
>
> I suggest dropping the reference.

SPF did not spring from nothing. =A0It gathered a number of concepts,= added a
few things, and managed to be successful. =A0I think it would be more
appropriate to leave it as it shows part of the trace back to the origin of=
the protocol.

I would suggest the co-ch= airs consult the AD or the RFC Editor about what can be done in a situation= where it's appropriate to cite known prior work where an actual refere= nce is no longer available.
=A0
> > > I note that there are 48 pages in RFC 4408= . =A0There are 78 pages in
> > > this draft. =A0A significant amount of text has been added i= n the
> > > Appendix (over 20 pages). =A0I doubt that the text has been = carefully
> > > reviewed. =A0I may be asked for an explanation about all tha= t once the
> > > draft leaves this working group.
> >
> >Why wait?
>
> I am not the person doing the IESG evaluation.

OK. =A0I misunderstood your comment. =A0I think you're wrong abou= t the lack of
review though.

I concur; there have bee= n several reviews, including by AppsDir.=A0 A non-trivial amount of the bul= k is the reorganization, which added a lot of blank space around a lot of n= ew section headings.

I can't identify any gigantic but gratuitous changes.
=A0

> > > In Appendix I:
> > >
> > > Appendix I is about "Protocol Status". =A0This dra= ft is intended as a
> > > Proposed Standard. From an IETF perspective that is what it = will
> > > be. =A0Describing it as something different can be misleadin= g.
> > >
> > > =A0 =A0"[RFC4408] was designed to clearly document the = protocol defined by
> > >
> > > =A0 =A0 earlier draft specifications of SPF as used in exist= ing
> > > =A0 =A0 implementations. =A0This updated specification is in= tended to clarify
> > > =A0 =A0 identified ambiguities in [RFC4408], resolve techinc= al issues
> > > =A0 =A0 identified in post-RFC 4408 deplyment experience, an= d document
> > > =A0 =A0 widely
> > > =A0 =A0 deployed extensions to SPF that have been developed = since [RFC4408]
> > > =A0 =A0 was published."

=
My browser identifies two typos in there ("techincal",= "deplyment").
=A0
> > >
> > > Extensions to the SPF protocol are clearly mentioned in the = charter
> > > as being out of scope. =A0The "document widely deployed= extensions" is
> > > problematic.
> >
> >The charter specifically allows for "addition of any enhancem= ents
> >that have already gained widespread support".
>
> I read the discussion about the charter again. =A0It is my
> understanding that extensions to the SPF protocol is
> out-of-scope. =A0The working group did not add a work item during the<= br> > chartering discussion as it was considered as an extension to the prot= ocol.

It was also not widely deployed. =A0Should I take authentication-resu= lts out of
the draft then?

Personally, I think this who= le appendix can be tagged with "[For IESG information only]" and = removed prior to publication.=A0 It's the kind of thing we usually incl= ude in shepherd writeups and not in the RFCs themselves.

-MSK
--e89a8f50335a15c92b04dce5dd93-- From spf2@kitterman.com Fri May 17 06:59:01 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED2A21F933B for ; Fri, 17 May 2013 06:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTJ0umHQ2L-X for ; Fri, 17 May 2013 06:58:57 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3E94721F9301 for ; Fri, 17 May 2013 06:58:57 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 866CE20E40FE; Fri, 17 May 2013 09:58:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368799136; bh=bhMHsu0p5EwZN4XH8rYcMvy2AfUdcRXG3oZEnN94nNg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PFKewOpSUOswFcWefdDpua7aXDr5WN/huJ4VwN3JRVuygcLT0z1/DrdYu1jkt39uq glEYCkaKyq8JQCeaRO5Apfpme5ZTAPP8C3F7hk/9kIVTS44bvR0soQ1O2F/MNPj50s QbxRQ7fy9ENdiwaxDHD1QeSQ8GMJphvOLVPFKusI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6A06120E40F6; Fri, 17 May 2013 09:58:55 -0400 (EDT) From: Scott Kitterman To: "spfbis@ietf.org" Date: Fri, 17 May 2013 09:58:55 -0400 Message-ID: <2434269.5GrKsYB81B@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <1972467.x8au6JTDZS@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 13:59:02 -0000 On Friday, May 17, 2013 01:35:21 AM Murray S. Kucherawy wrote: > On Thu, May 16, 2013 at 11:37 PM, Scott Kitterman wrote: Snipped down to only the items I think I need to reply to. > > > > > 'Without explicit approval of the domain owner, checking other > > > > > identities against SPF version 1 records is NOT RECOMMENDED > > because > > > > > there are cases that are known to give incorrect results.' > > > > > > > > > > How should this explicit approval be sought? This recommendation > > > > > does not make sense. > > > > > > > >What I have now is "Documents that define other identities will have > > > >to define the method for explicit approval." > > > > > > "out-of-band" or "private" was suggested. I'll use one of them (I do > > > > > > not have any preference): > > > Without out-of-band approval of the ADMD, checking other identities > > > against SPF version 1 records is NOT RECOMMENDED because there are > > > cases that are known to give incorrect results. > > > > I don't think that's correct. One could get a new modifier added to the > > SPF > > modifier registry that would indicate a record can be used for other > > purposes. > > There are no such other purposes defined at the moment, but there's > > absolutely > > no need for out-of-band/private methods to accomplish this goal. > > I'm confused now about what we're trying to say. I think the RFC is > trying to say that it's a bad idea to try to check identifiers other than > HELO and MAIL FROM using the check_host() function, unless you really know > what you're doing and so does the sender. Is that correct? If not, what's > the intent? Maybe with that clarified, I can suggest an alternative. Close. It goes a bit further. SPF records have to be interpreted in the context of SPF. As a receiver, that's ALL you can know. It's not possible for receivers to accurately translate something written in an SPF context to another one. Any such use has to be opt-in so that there's an explicit statement from the sender that their SPF record is suitable for the alternative use. As an example, DMARC is very careful to stay on the (in my opinion) correct side of this line be taking the results of an SPF check as is as one of the inputs and using the additional factor of identity alignment to consider if the SPF input supports a DMARC pass (I know that DMARC is OT for this group, but it's a current example). > > > > > 'Although invalid, malformed, or non-existent domains cause SPF > > > > > checks > > > > > to return "none" because no SPF record can be found, it has long > > > > > been > > > > > the policy of many MTAs to reject email from such domains, > > > > > especially > > > > > in the case of invalid "MAIL FROM". Rejecting email will > > > > > prevent > > > > > one > > > > > method of circumventing of SPF records.' > > > > > > > > > > This text is already in RFC 4408. > > > > > > > > > > "Implementations have to take care to correctly extract the > > > > > > > > > > > from the data given with the SMTP MAIL FROM command as many MTAs > > > > > will > > > > > still accept such things as source routes ..." > > > > > > > > > > The definition of is: > > > > > 'the domain portion of the "MAIL FROM" or "HELO" identity.' > > > > > > > > > > I am not sure whether it is even a definition. From an > > > > > implementation perspective the last paragraph of Section 2.4 is > > unclear. > > > > > >It seems clear to me. Could you expand on why you think it's > > problematic > > > >or provide recommended text. > > > > > > I mentioned in a previous comment that " definitions (not > > > sure whether it is a definition) are mentioned in two places. I > > > suggest fixing that and then getting back to the above". > > > > I don't understand what you think is wrong. Repeating the comment won't > > help. I did read it. I don't understand it. > > I believe the issue is that the token is defined in two places in > the bis draft, namely 2.4 and 4.1. We should consolidate them and ensure > the consolidated one is complete. Here's that last paragraph of 2.4: > Implementations have to take care to correctly extract the > from the data given with the SMTP MAIL FROM command as many MTAs will > still accept such things as source routes (see [RFC5321], Appendix > C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). > These archaic features have been maliciously used to bypass security > systems. I think it's a cautionary tale, not a definition. This could be moved to 4.1, I suppose, but I don't see what it adds to do so. > > > > > 'Generating non-delivery notifications to forged identities that > > have failed the authorization check is a source of backscatter and > > > > SHOULD be avoided.' > > > > > > > > > > This RFC 2119 SHOULD is not in RFC 4408. The above does not have > > > > > anything to do with Sender Policy Framework. It was mentioned > > > > > during > > > > > WG discussions that "SPF can help the backscatter problem" [2]. > > > > > This > > > > > text may have been introduced in response to a review [3]. Is this > > > > > an enhancement or a clarification? > > > > > > > >It's a clarification. > > > > > > In a previous comment I mentioned that "my reading of the above is > > > that it is neither an enhancement or a clarification. I suggest > > > removing the text". > > > > So you think it's not something that should be avoided? > > I think it's something to be avoided, but the choice of generating an NDN > has nothing to do with the SPF protocol itself. It's a local policy > matter. I agree with strong language, but not SHOULD. OK. Would you please suggest strong, but not 2119 text? It would be a help. > > > > > 'ADMDs publishing SPF records SHOULD try to keep the number of > > > > > "include" mechanisms and chained "redirect" modifiers to a > > minimum.' > > > > > > > What is the minimum? Note that this RFC 2119 SHOULD is in RFC 4408. > > > > > > > >It's the least an ADMD needs to properly describe the hosts > > > >authorized to send > > > >mail from their domain. It's minimum in the sense of no more than > > needed. > > > > > I commented previously about this "I didn't understand that as there > > > wasn't any explanation for the RFC 2119 SHOULD. I suggest adding an > > > explanation or rewriting the text so that the expression (see above) > > > is clear". > > > > I'm failing to understand how to clarify that use the minimum means use as > > little as you can. It's basically just explaining the dictionary to the > > reader, so I think I don't understand what you think needs changing. > > I think the issue here is that use of normative language ought to be > associated with something more definitive than "a minimum", which is a bit > mushy. Since there are caps on DNS query counts established elsewhere, > does this SHOULD accomplish anything? > > On the other hand, I think we're not required to justify normative language > that's just repeated from RFC4408, so we shouldn't burn too many cycles > here. I'll leave it then, I guess. An example of something that is not the minimum is v=spf1 a mx ptr ?all where a and mx point to the same host and that host has a PTR match for the domain too. Such records are quite common as they are the default output of some SPF record generation wizards. With such a record, there's triple the DNS lookups for every mail that doesn't pass to no purpose. > > > > > In Section 4.1: > > > > > ' - the domain that provides the sought-after > > authorization > > > > > information; initially, the domain portion of the > > "MAIL > > > > > FROM" or "HELO" identity.' > > > > > > > > > > The above text is different from the text in Section 2.4. > > > > > > > >Yes, but not inconsistent with it. > > > > > > I suggest having the definition in one place for consistency. What I > > > am looking at is consistency for the reader instead of where I > > > believe that there is inconsistency. > > > > They are talking about different things relative to domains, so given the > > organization, I don't see an easy way to do that. I'm open to > > suggestions. > > The definition in 2.4 is less complete than that in 4.1, and also there are > references to the one in 2.4. I propose copying the 4.1 version on top of > the 2.4 version, remove the 4.1 definitions and have them refer to 2.4. I'm still not seeing 2.4 as a definition. If there is a consolidation needed, I think 4.1 is the right place for it. If someone can specify exactly what text in 2.4 is definitional, I'll try and consolidate it into 2.4 (and check the references). > > > > > 'Alternatively, for a server failure (RCODE 2) result, > > check_host() > > > > > MAY track failures and treat multiple failures within 24 hours > > for > > > > > the same domain as "permerror".' > > > > > > > > > > This text is not in RFC 4408. I found a note in Issue #1 [5] and in > > > > > a message [6]. > > > > > > > >Yes. This is a change to address an operational issue found during SPF > > > >deployment. > > > > > > Stuart mentioned that: "This also solves the TIMEOUT for type 99 > > > problem. Reporting a PermError for a broken name server would be very > > > appropriate (and switching to checking TXT first while said failure > > > is cached would also be permissible)". > > > > > > John commented that: "Not that I'm aware of. That looks to me like > > > an optimization to do in the DNS cache, not in the client". > > > > > > In a previous comment I mentioned that: "Are there any > > > implementations that do this? If so, that's the justification; it's > > > practical experience. If not, we should consider dropping it". > > > > There was an issue. We discussed possible solutions (my initial hope was > > to > > make all SERVFAIL responses permerror) and this was the best solution we > > came > > up with. Because we want consistent results across implementations it's > > not > > just a local cache optimization. I think we should leave it since I don't > > want to redo the entire process of solving the issue again. > > I understand the intent, but there's quite a bit of onus on us to show that > this is important enough to include. Are there implementations that do > this, which would be evidence that it's important? I didn't implement it yet because coming into the working group, I'd thought the solution to the problem in question was to convert serve fail from temperror to permerror in general (which proved to be wrong). I believe Stuart is working on this now and if he doesn't, I will. I can tell you that the issue we are trying to resolve is the reason I don't configure software I've written to defer on temperror by default. I used to and it caused problems. >From my point of view, we have a new proposed solution that the WG developed to a long standing issue. It seems a bit odd to then demand that it can only be part of the output of the WG if someone else implemented it. So I can show that the problem it's addressing is real. As written, it's fully backward compatible, so adding it causes no harm. Part of what we are supposed to be doing is addressing lessons learned from the experimental period and that is exactly what this is. > > > > > In Section 4.6.4: > > > > > "SPF implementations MUST limit the total number of mechanisms > > > > > and > > > > > modifiers ("terms") that cause any DNS query to at most 10 > > > > > during > > > > > SPF > > > > > evaluation." > > > > > > > > > > This was discussed on the mailing list [7]. > > > > > > > > > > "If this number is exceeded during a check, a permerror MUST be > > > > > returned." > > > > > > > > > > I read this as if an implementation-specific limit is reached a > > > > > permerror is returned. There are two RFC 2119 MUST in the > > > > > above. That can be reduced to one MUST. > > > > > > > >Is there a problem with it the way it is? > > > > > > Here is my previous comment: > > > > > > For context we are at Section 4.6.4. I'll quote some text from it: > > > "If this number is exceeded during a check, a permerror MUST be > > returned." > > > > > 'If this limit is exceeded, the "mx" mechanism MUST produce a > > > "permerror" result.' > > > 'If this limit is exceeded, all records other than the first 10 > > > MUST be ignored.' > > > > > > I prefer not to discuss about the last one (see quoted text) again. > > > In terms of coding it is easier if I am told to return a "permerror" > > > results when DNS limit X is exceeded. That can be specified with one > > > RFC 2119 MUST. I am taking in consideration the SecDir > > > recommendation and interoperability. Speaking of interoperability > > > > > > the following text: > > > 'SPF implementations MUST limit the total number of mechanisms and > > > modifiers ("terms") that cause any DNS query to at most 10 during > > > SPF > > > evaluation.' > > > > > > does not encourage it because of the "at most". Section 4.6.4 does > > > not make things easier for DNS operations as the reader cannot > > > identify the limits easily due to the exceptions. I am ok with the > > > exceptions. What I am suggesting is not to use two RFC 2119 MUST if > > > it there is a way for it to be done with one RFC 2119 MUST. > > > > They are different limits that you have to code differently, so I think > > combining them would reduce clarity for implementers. > > I agree that there are actually three different things being limited here: > > - the mechanism count > - the MX query count > - the resulting A query count > > The "at most" thing is interesting. If I limit the DNS count to 2, for > example, I'm still compliant but would likely get very different results > than an implementation with a limit of 10. That's the same logic that we > applied to say you can't go over that limit either. I'm OK with dropping at most. Any objections? > > > > > 'MTAs or other processors SHOULD impose a limit on the maximum > > amount > > > > > of elapsed time to evaluate check_host(). Such a limit SHOULD > > allow > > > > > at least 20 seconds. If such a limit is exceeded, the result of > > > > > authorization SHOULD be "temperror".' > > > > > > > > > > There are three RFC 2119 SHOULDs in the above. I suggest rewriting > > > > > the text to reduce that. > > > > > > > >They are three different things. Why would rewriting it help? > > > > > > Here is my previous comment: > > > > > > Throughout the document the words "MTA", "other processors", "mail > > > receivers", "SPF implementations" and "SPF verifiers" are used. That > > > looks inconsistent to me. > > > > > > Here's an example of a rewrite: > > > MTA or other processors SHOULD: > > > > > > (a) impose a limit on the maximum amount of elapsed time to > > > evaluate check_host(). > > > > > > (b) allow for at least 20 seconds. > > > > > > (c) return a result of authorization of "temperror". > > > > I don't find that any clearer, probably less so than what's in the draft > > now. > > It's a common-factoring of the noun and SHOULD with otherwise identical > meaning. Seems a stylistic choice to me more than anything else. I understand. I don't think it's helpful here. There seems to be an idea that the fewer times 2119 words appear in the draft the better. While we want to avoid over specifying, cases like this don't actually change the requirements. I think clarity is more important than consolidation and I find the current wording clearer. If other people think the refactored version is clearer then I'll change it, but I think it's a mistake to change it just to reduce the count of 2119 words in the draft. > > > > > "To prevent DoS attacks, more than 10 PTR names > > > > > MUST NOT be looked up during the evaluation of a "ptr" mechanism > > > > > (see Section 4.6.4)." > > > > > > > > > > The above restates a previous RFC 2119 MUST. > > > > > > > > > > "If used, proper PTR records MUST be in place for the domain's > > hosts > > > > > > > and the "ptr" mechanism SHOULD be one of the last mechanisms > > > > > checked." > > > > > > > > > > Those RFC 2119 key words are not in RFC 4408. I don't see how this > > > > > RFC 2119 change qualifies as a clarification or explanation. > > > > > > > >For the MUST, it flat out won't work if you don't have those (no > > > >interoperation). For the SHOULD, it's an optimization. We can change > > > it f you want. > > > > > > My previous comment was that: "It's a change. I suggest reverting it. > > > Telling people who are using the "ptr" mechanism that they must have > > > PTR records is stating the obvious". > > > > Obvious to you. Not obvious to everyone. > > I think this is what Pete described as "shouting", i.e., using MUST where > "needs to" is fine. PTR isn't part of SPF itself. OK. Changed. > > > > > In Section 6: > > > > > 'The modifiers defined in this document ("redirect" and "exp") > > > > > MAY > > > > > appear anywhere in the record, but SHOULD appear at the end, > > after > > > > > all mechanisms.' > > > > > > > > > > This text is in RFC 4408. I would label the RFC 2119 usage as > > > > > defective. > > > > > > > >Why? > > > > > > My previous comment was: "The text tells me that it is ok if the > > > modifiers appear anywhere but they should appear at the end after all > > > mechanisms. It would be clearer to say that it should appear after > > > all mechanisms". > > > > That is defective use of 2119 language? I disagree that that would be > > clearer. > > "MAY" is essentially meaningless except perhaps to emphasize that the > implementer has a choice with no protocol consequence. You could make it > "can" and have the same effect. There's an inverse requirement on implementers that SPF verifiers can't assume modifiers are in any particular place in the record. So the fact that this MAY happen has an effect on verifier implementation requirements (and it would affect interoperability if they don't consider it). > > > > > In Section 6.2: > > > > > "Since the explanation string is intended for an SMTP response > > > > > and > > > > > [RFC5321] Section 2.4 says that responses are in [US-ASCII], the > > > > > explanation string MUST be limited to US-ASCII.' > > > > > > > > > > It would be easier to defer to RFC 5321 instead of setting a RFC > > > > > 2119 > > > > > requirement in this draft. I note that this requirement was not in > > RFC > > > > > 4408. > > > > > > > >It's not a new requirement. If you couldn't find it in 4408, then that > > > >means we've succeeded in making the actual requirement more clear. > > > > > > None of the WG participants have pointed out where the actual > > > requirement (RFC "MUST") is in RFC 4408. If the text was in RFC 4408 > > > it would be possible for a WG participant to point me to it. There > > > was a comment about 'this could be expressed non-normatively (e.g. > > > "needs to be")'. > > > > If it's not ASCII, it won't interoperate (at all). Isn't that exactly > > where > > 2119 language is supposed to be used? Regardless of how it's worded in > > 4408, > > putting non-ASCII characters in explanation strings does not and has never > > worked. At most it's making something explicit that was implicit before, > > which is a good clarification I'd think. > > I support this change of adding MUST. An SPF implementer does not > necessarily know how the mechanism by which SMTP will be accessed to relay > the result, and we don't specify anything about encoding special characters > to 7-bit. We could MUST this, or we could MUST an RFC2047-style encoding > or escaping of some kind. Guess which one I prefer. > > The other alternative I can think of is to drop the MUST here but make it > clear that if the explanation string isn't 7-bit clean, someone's going to > have to make it SMTP-compliant somehow before it's returned in the SMTP > reply. I don't think that's an alternative because it's inconsistent with current practice. I don't think we have a choice other than ASCII, however we choose to word it. > > > > > "Software SHOULD make it clear that the explanation string > > > > > comes from a third party." > > > > > > > > > > I could not understand what that means in RFC 2119 terms. The draft > > > > > uses RFC 2119 key words by example instead of providing an > > explanation. > > > > > >I don't understand the comment. > > > > > > There was a comment from Murray: "we're talking about > > > interoperability between humans here, and not between implementations". > > > > We're talking about avoiding security issues caused by the humans getting > > confused. > > If this document defines a protocol that operates between senders and > receivers, then wrapping explanation text (which is for humans) in more > explanation text is out of scope, at least in a normative sense. > > That said, this was in RFC4408 and is unchanged here. I don't think it's > worth our energy at this stage. OK. > > > > > "This SHOULD be a fully qualified domain name, but if one does > > > > > not > > > > > exist (as when the checking is done by a MUA) or if policy > > > > > restrictions > > > > > dictate otherwise, the word "unknown" SHOULD be substituted." > > > > > > > > > > The RFC 2119 key words are in RFC 2119. I don't know what to say. > > > > > > > >OK. > > > > > > Murray comemnted: "I think that looks fine as-is, though we could > > > change the first SHOULD to "ought to" because it's a transformation > > > of other input and not an implementation choice. (And I assume you > > > mean they were in RFC4408.) > > > > Since the values end up in log files and Received-SPF/authentication > > results > > header fields that are provided to be processed on other systems, it is an > > interoperability issue. Having consistency helps interoperability. I'd > > prefer to leave it. > > My point here is that the first SHOULD is essentially saying "the hostname > of the machine SHOULD be an FQDN", but this is ineffective because the > person configuring this host might not know a thing about SPF or this > requirement and call the machine "banana". What does the SPF module do > with this SHOULD now? > > "ought to", "is typically", "is ideally", etc. What the first SHOULD is trying to say is about how you expand the macro (use hostname -f and not hostname). > > > > > It is odd to have RFC 2119 requirements under a "Notes" heading. > > > > > > > >They aren't really notes in that sense. If you have a better name for > > the > > > >section, please suggest. > > > > > > I suggest removing all the RFC 2119 requirements in Section 7.3 if > > > the working group cannot find a way to fix this. > > > > Why? How about if we call it "Details" instead of Notes? > > Macro Processing Details > > Dumping the RFC2119 language in there is a bad idea. It's all > interoperability stuff. Thanks. Changed. > > > > > In Section 8.2: > > > > > 'A "neutral" result MUST be treated exactly like the "none" > > result; > > > > > > > the distinction exists only for informational purposes.' > > > > > Why is an existing RFC 2119 restated? > > > > > > > >Because of the structure of the document that the WG came up with. I > > don't > > > >find a good way to avoid it and not make it less readable. > > > > > > I'll leave this issue open as it was mentioned in the AppsDir review. > > I'll help with this if needed. Thanks. > > > > > In Section 10.1.1: > > > > > > > > > > There was a comment from Authur Thisell about the table [11] in this > > > > > sub-section. > > > > > > > >There didn't seem to be support for changing it though. > > > > > > I read RFC 4408 and I did not find any table similar to the one in > > > Section 10.1.1 of draft-ietf-spfbis-4408bis-14. My understanding of > > > "support for changing text" is that the text is proposed on the > > > working group mailing list and it is added if there is agreement. I > > > didn't find any messages about that in the mailing list > > > archives. What I found was a message disagreeing with a change which > > > was made in the draft which was posted together with an explanation > > > about why there was disagreement. In my opinion there wasn't any > > > support for making that change in the draft. > > > > The text came from Alessandro and was discussed on the list. Arthur's > > comment > > came later. The table is new, but is only a new expression of information > > that was in 4408. It does not create any new requirements. > > When we developed RFC6686, there were several people who responded well to > the introduction of tables to show our survey results. I seem to recall > people liking this table in here as well, though I admit not having looked > at the archives tonight. If it can be confirmed that the details in the > table match the prose, I think it's fine to leave it in. I checked. It does. > > > > > In Section 10.1.2: > > > > > "Publishing SPF records for domains that send no mail is > > > > > > > > > > a well established best practice." > > > > > > > > > > I am not aware of that best practice. I did a few DNS queries: > > > > > > > > > > ;; QUESTION SECTION: > > > > > ;bing.com. IN TXT > > > > > > > > > > ;; ANSWER SECTION: > > > > > bing.com. 3600 IN TXT "v=msv1 > > > > > t=6097A7EA-53F7-4028-BA76-6869CB284C54" > > > > > > > > > > ;; QUESTION SECTION: > > > > > ;com.com. IN TXT > > > > > > > > > > ;; ANSWER SECTION: > > > > > com.com. 293 IN TXT > > > > "google-site-verification:esSnoZdChIkkfCfS9MMgqNhE0yaXfnnZWdZPuBf7e8k" > > > > > >OK. See > > > > http://www.bits.org/publications/security/BITSEmailAuthenticationFeb2013.p > > d > > > > > >f > > > > > > I suggest "good practice" as mentioned by Alessandro. > > > > What's wrong with the way it is? I think the current text is accurate. > > The OpenDKIM SPF data recorded 1157 domains with "v=spf1 -all" records. The source of your domain list was from domains seen in email, right? So that's 1157 cases where they got it wrong. I don't think your survey would have caught correct uses of it (or do I misremember how you got your domain list)? > > > > > In Section 11.5: > > > > > "An SPF compliant receiver gathers information from the SMTP > > commands > > > > > it receives and from the published DNS records of the sending > > domain > > > > > holder" > > > > > > > > > > I suggest explaining the untrusted part. > > > > > > > >That's what the section does. > > > > > > There was a comment: "A second sentence indicating most of that > > > input is unverified is probably in order, with references if possible". > > > > I think the section explains exactly that, so some text would help. > > I think it falls short, because it's not clear to a neophyte reader that > those data are essentially untrustable. > > So append: > > All of these pieces of information are generated by actors outside of the > authority of the receiver, and thus are not guaranteed to be accurate or > legitimate. Added. Thanks. > > > > Where can I find "Designated Mailers Protocol"? > > > > > > > >See draft-fecyk-dsprotocol > > > > > > Ok. As a note for the working group, I could not find the draft. > > > > First Google hit for draft-fecyk-dsprotocol is: > > > > http://tools.ietf.org/html/draft-fecyk-dsprotocol-04 > > RFC5451 cites a dnsop I-D that expired a long time ago, so there's > precedent for referring to that even though it's long dead. > > > > > > Where can I find "Domain-Authorized SMTP Mail"? > > > > > > > >I don't have a copy of this. > > > > > > I suggest dropping the reference. > > > > SPF did not spring from nothing. It gathered a number of concepts, added > > a > > few things, and managed to be successful. I think it would be more > > appropriate to leave it as it shows part of the trace back to the origin > > of > > the protocol. > > I would suggest the co-chairs consult the AD or the RFC Editor about what > can be done in a situation where it's appropriate to cite known prior work > where an actual reference is no longer available. OK. > > > > > In Appendix I: > > > > > > > > > > Appendix I is about "Protocol Status". This draft is intended as a > > > > > Proposed Standard. From an IETF perspective that is what it will > > > > > be. Describing it as something different can be misleading. > > > > > > > > > > "[RFC4408] was designed to clearly document the protocol defined > > by > > > > > earlier draft specifications of SPF as used in existing > > > > > implementations. This updated specification is intended to > > clarify > > > > > identified ambiguities in [RFC4408], resolve techincal issues > > > > > identified in post-RFC 4408 deplyment experience, and document > > > > > widely > > > > > deployed extensions to SPF that have been developed since > > [RFC4408] > > > > > was published." > > My browser identifies two typos in there ("techincal", "deplyment"). Fixed. Thanks. > > > > > Extensions to the SPF protocol are clearly mentioned in the charter > > > > > as being out of scope. The "document widely deployed extensions" is > > > > > problematic. > > > > > > > >The charter specifically allows for "addition of any enhancements > > > >that have already gained widespread support". > > > > > > I read the discussion about the charter again. It is my > > > understanding that extensions to the SPF protocol is > > > out-of-scope. The working group did not add a work item during the > > > chartering discussion as it was considered as an extension to the > > protocol. > > It was also not widely deployed. Should I take authentication-results out > > of > > the draft then? > > Personally, I think this whole appendix can be tagged with "[For IESG > information only]" and removed prior to publication. It's the kind of > thing we usually include in shepherd writeups and not in the RFCs > themselves. Which one are we on? Appendix J is intended to be removed before publication. Scott K From johnl@iecc.com Fri May 17 06:57:03 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B6921F95E2 for ; Fri, 17 May 2013 06:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKSTzWB2Kph4 for ; Fri, 17 May 2013 06:57:02 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 741D321F95C4 for ; Fri, 17 May 2013 06:57:02 -0700 (PDT) Received: (qmail 49455 invoked from network); 17 May 2013 13:57:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent:cleverness; s=c12c.5196372d.k1305; bh=q8pz5++nD0uCkTUCuI6HYyoNQELPSqrCwxvNXQuNLKc=; b=X7gI5LFkemA2H+0H6YWeXjvGOLd+PqUrD8YNkZnpnGNm9pijnP4yNtpGQoErr7ZREKYgZ5kNPFtlwK5Ed6BlVaUQGBW9LWwMo8/9Jp4+DzL7xS9TFFMR2WS7Aln6U1MxhJhedz3uTEcys9QnAk5rbxxJxuKPD0ofSL33JjBvz4Q= Received: (ofmipd 127.0.0.1); 17 May 2013 13:56:39 -0000 Date: 17 May 2013 09:57:01 -0400 Message-ID: From: "John R. Levine" To: spfbis@ietf.org User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 17 May 2013 08:08:43 -0700 Subject: Re: [spfbis] Fwd: draft-ietf-spfbis-4408bis-14 (fwd) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 13:57:03 -0000 >>>The document is clear and describes the SPF mechanism effectively. >>>The only quibble that I could find is that repeated mentions are >>>made of limiting the number of 'DNS queries' without specifying >>>whether these are individual queries or recursive. ... >I'm not aware of anyone ever thinking it was three. I'd appreciate advice on >addressing this. Phill is technically right, but I agree with you that I have never heard anybody else interpret it his way. From the point of view of someone implementing an SPF checker, the queries go off to the local resolver and you can't even tell whether it recursed or used a cached copy or whatever. So I'd leave it alone. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From SRS0=o+ToS=PC==stuart@gathman.org Fri May 17 09:35:05 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BC821F9668 for ; Fri, 17 May 2013 09:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hW8hIu2dFP0x for ; Fri, 17 May 2013 09:35:04 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id 3245621F9667 for ; Fri, 17 May 2013 09:35:04 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (PLAIN sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1368808523; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=ULdP+JgXfPo+IlOcpzwWgpIzMKp70huD5tdFGIbsK7M=; b=YGqY0NWpLOPZks0/2dy+pvwQkPeIeLB0a2t7riBUpBr/eHeKb1GIKuznFaghY8+iiv9u71 ileZFMWX+Y7CEcxlfWcVk2MLlJS5Q4SDe+habASTvvnSr6LKxGw9k3PGSafOSvHY49MNsBKN /wLvUe726/BAVkFDczNG7tYwWjrbo= Received: from sdg.bmsi.com ([IPv6:2001:470:8:488:40d8:f2ae:75be:69d2]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r4HGZNXr002982 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 17 May 2013 12:35:23 -0400 Message-ID: <51965C1A.1020203@gathman.org> Date: Fri, 17 May 2013 12:34:09 -0400 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130424002629.13505.qmail@joyce.lan> <342196331.8PjgpiStlt@scott-latitude-e6320> In-Reply-To: <342196331.8PjgpiStlt@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 16:38:39 -0000 On 05/17/2013 02:47 AM, Scott Kitterman expounded in part: > On Wednesday, April 24, 2013 12:26:29 AM John Levine wrote: >>> The "Some implementations ..." sentence seems to be malformed. I can't >>> parse it. >> That whole paragraph could be replaced by "the result of evaluating >> check_host() with a syntactically invalid domain is undefined." > Perfect. Thanks and done locally. > I thought 4408 made the result of a syntactically invalid domain "None". There is code in pyspf and rfc4408 test suite that ensures the result is None for too long labels, and such. rfc4408 4.3: If the is malformed (label longer than 63 characters, zero-length label not at the end, etc.) or is not a fully qualified domain name, or if the DNS lookup returns "domain does not exist" (RCODE 3), check_host() immediately returns the result "None". From spf2@kitterman.com Fri May 17 10:04:25 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3793221F97A0 for ; Fri, 17 May 2013 10:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.663 X-Spam-Level: X-Spam-Status: No, score=-3.663 tagged_above=-999 required=5 tests=[AWL=0.936, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPBGV8AEA3dW for ; Fri, 17 May 2013 10:04:21 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CE9E921F977C for ; Fri, 17 May 2013 10:04:20 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E234120E40FE; Fri, 17 May 2013 13:04:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368810259; bh=jxAaJMU0XobK/lVLcZGwvYAFOg5VyKfx+I9VAFRf1mE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=oxATbHSNxDaiPGfk1F4NqRMVtafjNELetm4v1px96NUdZMvz/8tc/+S/+hFQesgiP wNhjzkRlCglW1Gk5jL8yL3iyaYSeRti+Lp3nJw2PfHOd03Jm1/hqAPyBBnba1qwmr+ XJ5zqccHNYsMXPAY/PpeSOjb9GbqyVNT29fS7ITI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C4D3E20E40F6; Fri, 17 May 2013 13:04:19 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 13:04:18 -0400 Message-ID: <1744498.RZtYgTOBXh@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <20130409062431.GK24624@mx1.yitter.info> <1734898.5zN0vMnxl3@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 17:04:25 -0000 On Wednesday, May 08, 2013 02:09:24 PM Murray S. Kucherawy wrote: > On Wed, May 8, 2013 at 10:14 AM, Scott Kitterman wrote: > > > The last paragraph makes the claim that domain reputation is likely to > > > be > > > more accurate than IP reputation. Is it worthwhile to add a sentence or > > > two explaining why this is true? > > > > I don't think so. First, it's speculation and I don't think enough of a > > case > > for it can be made without being too long/distracting. Second, it's not > > part > > of the protocol, so it not something we should worry about overmuch. > > I think a simple, brief addition would do it: > > This is advantageous because reputation of domain names is likely to > be more accurate than reputation of host IP addresses since domains > are more likely to be stable over the long term. > > ...or something like that. I think that would have been fine. I already took it out. Do you think I should put it back? > > Section 2.1: > > > I think someone else already mentioned this, but how does encouraging a > > > second check decrease DNS resource use? > > > > I did reply to this already. It's a matter of HELO records generally > > being > > much 'cheaper' than mail from records. > > As long as the document explains that in a sentence or two, we're good. Here's what I added: ... (if a conclusive determination about the message can be made based on a check of "HELO", then the use of DNS resources to process the typically more complex "MAIL FROM" can be avoided). > > > Section 2.3: > > > > > > The second paragraph is loaded with negatives "no... neither... nor." > > > Suggest: "ADMDs can publish SPF records that authorize no hosts to use > > > their DNS domain names in HELO or MAIL FROM commands during SMTP > > > > sessions." > > > > I added that, because it's a good point, but it doesn't replace the > > existing > > text which attempts to (without being too pointed about receiver policy) > > say > > that if you want receivers to be able to reject mail that didn't come from > > authorized hosts, you need a -all record. Some senders care about > > supporting > > these negative assertions, others don't. > > My comment wasn't so much to correct the text, but to point out that the > sentence is hard to read with so many negatives. > > Doesn't the sentence I proposed say the same thing? Almost. It loses the nuance that this is only appropriate for hosts that send no mail. You'd think that'd be obvious, but it's not. > > Section 2.4: > > > Isn't the fourth paragraph implicit in any standards specification? > > > That > > > is, do we really need it? > > > > I see your point, but I think it should actually stay. Consistency of > > evaluation across multiple implementations is key to the success of the > > protocol. IIRC, you said during the debate that if you were implementing > > SPF, > > you'd ignore the macro requirements. You're, of course, free to do that, > > just > > don't say you implemented SPF. > > I would agree with all of that except the need to say it in a Proposed > Standard. Any other opinions? I didn't here much in the way of opinions on this. Since it's carried forward from 4408, I'll leave it for now. > > > Section 2.6.7: > > > > > > Does "permerror" also result when permanent DNS errors occur? > > > > Tell me how to figure out when a DNS error is permanent and then maybe. > > Given > > > > what's described in 4.4 Record Lookup, I think only extended SERVFAIL (if > > the > > receiver has implemented the temperror -> permerror promotion option) can > > currently get a permerror. > > RCODEs 1, 3, 4, and 5 all look permanent to me as defined in RFC1035, in > that a retry is unlikely to yield a different result absent an operator > changing some configuration or zone data. 0 is "no error" and 2 is "server > failure"; the latter is obviously permanent (but desirable), leaving 2 for > the case where a timeout or some other transient thing occurred. This is a good point. 3 is permanent, but it's not an error. It's no data. Currently the draft says anything other than 0 or 3 is a temperror. 5 could be temporary, I'd think (query refused due to overload maybe?) Looking at http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-parameters-6, I agree that many of these DNS errors could be permanent, but the spec calls for temperror in these cases. The only temporary errors that turned out to really be permanent that I've seen in the wild are some SERVFAIL (2). If we were starting from scratch, I'd probably classify many of the other rcodes as permanent errors, but we aren't. Absent some evidence of this causing real world problems, I think we need to leave it the way it is. > > > Why 20 seconds for the overall run time? > > > > This is carried forward from RFC 4408. It was moved from section 10.1 to > > 4.6.4 as part of issue #6, but the value is unchanged. I'm not aware of > > any > > issues with what's defined in 4408. > > I don't have an issue with 20 specifically. I'm just anticipating the "Why > 20?" question from someone else. Because it's been that way for a long time and seems to work. IIRC, at the time, it was the shortest time we could get some agreement around. If it were just me, I'd pick a number closer to 2 than 20. > > > The "Some implementations ..." sentence seems to be malformed. I can't > > > parse it. > > > > Better? > > > > Note: Historically, this document has made no provisions for how > > > > to > > > > handle domain-specs, or macro-expansions thereof, that are > > syntactically invalid per , such as > > names > > with empty labels (e.g., "foo..example.com") or overlong labels > > (more than 63 characters). Some implementations choose to treat > > mechanisms associated with such expansions as no-match and > > ignore modifiers with such names, others return a "permerror" > > exception. The outcome for an unexpected domain-spec without > > > > macros > > > > might even differ from that for an unexpected > > <target-name> > > after macro expansion. > > Now that I see what it's trying to say, this is fine. Dave's suggestion is > fine as well, I think. Thanks. > > > The second-last paragraph is weirdly wrapped. Is the XML ok there? > > > > I think I fixed that already based on John Levine's comments. Please > > double > > check the new draft. > > Will do when it comes out. > > > > Section 5.6: > > > > > > For IPv4, shouldn't the CIDR be 1*2DIGIT? For IPv6, shouldn't the CIDR > > > > be > > > > > 1*3DIGIT? > > > > I don't know. It's unchanged from RFC 4408 right now, but I'd like other > > opinions on changes here (ABNF makes my head hurt). > > It's probably not harmful to leave it, really. It's just an observation > that 1*DIGIT allows 000000024 (which is probably fine) but also allows > 1048576 (which probably isn't). 1*2DIGIT would limit it to 00-99 at least. > > You could also cover this in prose by saying 1*DIGIT and then in either an > ABNF comment ("; blahblah") or in text nearby say that it has to evaluate > to an integer from 0 to 32 for v4 and 0 to 128 for v6. Maybe import the definitions in http://www.ietf.org/rfc/rfc3986.txt instead? > > Section 6.2: > > > It just occurred to me that in the earlier sections (2 or 4, in > > > particular), it's clear that check_host() returns one of the enumerated > > > result, but it's never made explicit that it also outputs an explanation > > > string. We might want to mention this earlier than we do now so it's > > > > not a > > > > > surprise later. > > > > It's an optional and somewhat rare output of the protocol, so I think not, > > but did you have something specific in mind? > > I'm thinking about what we did with DKIM, where we made it very clear that > DKIM's primary output is a pass/fail/etc. and the "d=". Anything that > outputs something beyond that is an extension outside the scope of the > specification. Then again, the premise for doing that was protracted > debate about "i=" vs. "d=" (Dave still has the buttons), but that's a > different issue. > > Maybe we don't need to go down this path with SPF if it's not needed, but > during my review that memory came up, and I thought it might be useful to > consider it. I think it's enough of a corner case we should leave it. > > > ABNF rules say literal strings in productions are case-insensitive. > > > That > > > means the macro-letter set actually implicitly includes all of the > > > > capital > > > > > letter equivalents. If we want to constrain it to lowercase only, we > > > > need > > > > > to use hex notation. > > > > OK. If someone would provide those, it would be great. Otherwise, I'll > > take > > a shot at it, probably Friday. > > The "ascii" man page on your favourite UNIX distribution has them. You're > looking for something like: > > macro-letter = %x73 / %x6c / ... We resolved this already, right? > > Section 9.1: > > > Same point about the case-insensitivity of ABNF here. > > > > Except for "Received-SPF" is there anything case insensitive there? I'd > > greatly appreciate text for this too. > > I don't think "From" needs to start with a capital "F" for it to be the one > RFC5322 talks about. More generally, I don't think header field names are > case-sensitive. Thus, "Received-SPF" is fine as-is. > > The rest of it is probably also fine, unless for some reason it has to be > "pass" and must never be "PASS" or "pAsS", etc. > > > The "SPF verifiers MUST make sure..." doesn't seem actionable to me. Do > > we > > > > > really expect Received-SPF generators to be able to identify and exclude > > > malicious data? > > > > I think you have to. I've seen people put html pointing to malicious web > > sites in SPF records. Thanks to someone privately pointing this class of > > attack out to me, my SPF validator now properly escapes anything that's > > retrieved from DNS. > > It's the "malicious data" part that concerns me because what constitutes an > effective data attack is very context-sensitive. Do you still think it needs a change? Scott K From spf2@kitterman.com Fri May 17 10:06:19 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFC421F97B0 for ; Fri, 17 May 2013 10:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiKswDJxSkfV for ; Fri, 17 May 2013 10:06:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 35BC321F97A9 for ; Fri, 17 May 2013 10:06:14 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BA2F520E40FE; Fri, 17 May 2013 13:06:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368810373; bh=XbBHK+WP/68V81Mv3iCDDMM9VxnUbeqcajgO+1KXC98=; h=From:To:Subject:Date:In-Reply-To:References:From; b=POIJ4nFsgpptSllKl3qVJ8or2ns3ALX3Bw5m8d+sDLLkbeUkKK7f+FVib39Xjv3Cx yYfYGSu9bRGZrm2Tf3zzaS2COo8M7Ons+NRQpXGEn0vENn+2MmqDmaoPpZDyYvnjF/ F70ZX/aZJWx3J+7D8pgIRlZPPqec/pIYsrTIJ4t4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A1BFA20E40F6; Fri, 17 May 2013 13:06:13 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 13:06:13 -0400 Message-ID: <4307445.bIVyi0DuB3@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <51965C1A.1020203@gathman.org> References: <20130424002629.13505.qmail@joyce.lan> <342196331.8PjgpiStlt@scott-latitude-e6320> <51965C1A.1020203@gathman.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 17:06:19 -0000 On Friday, May 17, 2013 12:34:09 PM Stuart D Gathman wrote: > On 05/17/2013 02:47 AM, Scott Kitterman expounded in part: > > On Wednesday, April 24, 2013 12:26:29 AM John Levine wrote: > >>> The "Some implementations ..." sentence seems to be malformed. I can't > >>> parse it. > >> > >> That whole paragraph could be replaced by "the result of evaluating > >> check_host() with a syntactically invalid domain is undefined." > > > > Perfect. Thanks and done locally. > > I thought 4408 made the result of a syntactically invalid domain > "None". There is code in pyspf and rfc4408 test suite that ensures the > result is None for too long labels, and such. IIRC, the test suite has a non-preferred, but acceptable alternative. > rfc4408 4.3: > If the is malformed (label longer than 63 characters, > zero-length label not at the end, etc.) or is not a fully qualified > domain name, or if the DNS lookup returns "domain does not exist" (RCODE > 3), check_host() immediately returns the result "None". The trick is that not everyone does that. Sometimes you get a permerror out of it, so you can't rely on it. Scott K From spf2@kitterman.com Fri May 17 10:10:56 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CAE21F97B4 for ; Fri, 17 May 2013 10:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-6alKY6CqZl for ; Fri, 17 May 2013 10:10:51 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B3E0A21F97B3 for ; Fri, 17 May 2013 10:10:51 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4017D20E40FE; Fri, 17 May 2013 13:10:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368810651; bh=frzNg+HtTPiXmJmNcw6C9W3+Sts1SHM2K9hk3luKo7g=; h=From:To:Subject:Date:From; b=UofjQ6u2C8VsutbMlWKWIqQZhPYDkItwX4mg9TSIpT+B8DLs5JwTbvkIjXJexXUPH woaCdHOI9EAldJA6UEOlvO+OAd80NTUVQVDNyizcfL1b/uYTdxU/+Atmsmcnv6G6x8 3cw3uhCgU5WXX6ErcbJBMxzUvRiOROS+/dwzYAdo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2846520E40F6; Fri, 17 May 2013 13:10:50 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 13:10:50 -0400 Message-ID: <2434290.IfmuWxVHGh@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] WGLC Reviews/Comments X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 17:10:57 -0000 I think I'm caught up now. If I missed something that still needs change/discussion, please let us know. Scott K From superuser@gmail.com Fri May 17 10:55:13 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE35221F9669 for ; Fri, 17 May 2013 10:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.243 X-Spam-Level: X-Spam-Status: No, score=-3.243 tagged_above=-999 required=5 tests=[AWL=1.356, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrurG4sMUYIj for ; Fri, 17 May 2013 10:54:58 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id ADE4D21F966C for ; Fri, 17 May 2013 10:54:57 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id j13so711855wgh.1 for ; Fri, 17 May 2013 10:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=q4mOezxw1vODCgyifjFtfof2MHAWShjn6qk79GLQlI8=; b=hMxYUQfa9qtPthB64laAvsAjo6Peuqvt+r+/gcU944MZkdOxek5mlk3Bn5L3VTX/X4 gK5sQmDQwwg0RD9ILpSr4D7RUvqvaeV2SUIOgWPNbpxaVhULsaqEneWQUDdo8pnaG6cD 4Iccq17OpP91uDlyExz7ZLqbGHmfPniC5DK0uNcQIPuu5YyoJv6PdkLLHkL9BVpKDe78 XYLff6QQgIP+2l6yi1a6saYlRY9/lisyEEb1HjsS62MjzLrk1NQ75c7nFcPhLokrSIHQ k1Ehys0u2ig8M5Nkz/hPv/6MZwuRqoCPULHN2UDbLpjKHTcUWJ4ISrElJs5sLpMarIkv 9UDQ== MIME-Version: 1.0 X-Received: by 10.180.79.69 with SMTP id h5mr35412868wix.14.1368813292491; Fri, 17 May 2013 10:54:52 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Fri, 17 May 2013 10:54:52 -0700 (PDT) In-Reply-To: <1744498.RZtYgTOBXh@scott-latitude-e6320> References: <20130409062431.GK24624@mx1.yitter.info> <1734898.5zN0vMnxl3@scott-latitude-e6320> <1744498.RZtYgTOBXh@scott-latitude-e6320> Date: Fri, 17 May 2013 10:54:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d043c062e101c2304dcedae92 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 17:55:14 -0000 --f46d043c062e101c2304dcedae92 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 17, 2013 at 10:04 AM, Scott Kitterman wrote: > On Wednesday, May 08, 2013 02:09:24 PM Murray S. Kucherawy wrote: > > On Wed, May 8, 2013 at 10:14 AM, Scott Kitterman > wrote: > > > > The last paragraph makes the claim that domain reputation is likely > to > > > > be > > > > more accurate than IP reputation. Is it worthwhile to add a > sentence or > > > > two explaining why this is true? > > > > > > I don't think so. First, it's speculation and I don't think enough of > a > > > case > > > for it can be made without being too long/distracting. Second, it's > not > > > part > > > of the protocol, so it not something we should worry about overmuch. > > > > I think a simple, brief addition would do it: > > > > This is advantageous because reputation of domain names is likely to > > be more accurate than reputation of host IP addresses since domains > > are more likely to be stable over the long term. > > > > ...or something like that. > > I think that would have been fine. I already took it out. Do you think I > should put it back? > I do. > > > Section 2.1: > > > > I think someone else already mentioned this, but how does > encouraging a > > > > second check decrease DNS resource use? > > > > > > I did reply to this already. It's a matter of HELO records generally > > > being > > > much 'cheaper' than mail from records. > > > > As long as the document explains that in a sentence or two, we're good. > > Here's what I added: > > ... (if a conclusive determination about the message can be made based on a > check of "HELO", then the use of DNS resources to process the typically > more > complex "MAIL FROM" can be avoided). > I suspect that's better as its own sentence rather than something parenthetical, but the text is right. > > > > > Section 2.3: > > > > > > > > The second paragraph is loaded with negatives "no... neither... nor." > > > > Suggest: "ADMDs can publish SPF records that authorize no hosts to > use > > > > their DNS domain names in HELO or MAIL FROM commands during SMTP > > > > > > sessions." > > > > > > I added that, because it's a good point, but it doesn't replace the > > > existing > > > text which attempts to (without being too pointed about receiver > policy) > > > say > > > that if you want receivers to be able to reject mail that didn't come > from > > > authorized hosts, you need a -all record. Some senders care about > > > supporting > > > these negative assertions, others don't. > > > > My comment wasn't so much to correct the text, but to point out that the > > sentence is hard to read with so many negatives. > > > > Doesn't the sentence I proposed say the same thing? > > Almost. It loses the nuance that this is only appropriate for hosts that > send > no mail. You'd think that'd be obvious, but it's not. > So: ADMDs that wish to declare that no hosts are authorized to use their DNS domain names in the HELO or MAIL FROM commands during SMTP sessions can publish SPF records that say so. > > Section 2.4: > > > > Isn't the fourth paragraph implicit in any standards specification? > > > > That > > > > is, do we really need it? > > > > > > I see your point, but I think it should actually stay. Consistency of > > > evaluation across multiple implementations is key to the success of the > > > protocol. IIRC, you said during the debate that if you were > implementing > > > SPF, > > > you'd ignore the macro requirements. You're, of course, free to do > that, > > > just > > > don't say you implemented SPF. > > > > I would agree with all of that except the need to say it in a Proposed > > Standard. Any other opinions? > > I didn't here much in the way of opinions on this. Since it's carried > forward > from 4408, I'll leave it for now. > Rats. Since we're looking for text to slash in response to the bloat complaint, this is a prime candidate. > > > > Section 2.6.7: > > > > > > > > Does "permerror" also result when permanent DNS errors occur? > > > > > > Tell me how to figure out when a DNS error is permanent and then maybe. > > > Given > > > > > > what's described in 4.4 Record Lookup, I think only extended SERVFAIL > (if > > > the > > > receiver has implemented the temperror -> permerror promotion option) > can > > > currently get a permerror. > > > > RCODEs 1, 3, 4, and 5 all look permanent to me as defined in RFC1035, in > > that a retry is unlikely to yield a different result absent an operator > > changing some configuration or zone data. 0 is "no error" and 2 is > "server > > failure"; the latter is obviously permanent (but desirable), leaving 2 > for > > the case where a timeout or some other transient thing occurred. > > This is a good point. > > 3 is permanent, but it's not an error. It's no data. Currently the draft > says anything other than 0 or 3 is a temperror. > True, NODATA isn't an error, but it is final. > > 5 could be temporary, I'd think (query refused due to overload maybe?) > Overload is supposed to be SERVFAIL, I think. Andrew? I think 5 is used for policy things like "You're not allowed to know that." > Looking at > http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-parameters-6, > I agree that many of these DNS errors could > be permanent, but the spec calls for temperror in these cases. > > The only temporary errors that turned out to really be permanent that I've > seen in the wild are some SERVFAIL (2). > As in a server that constantly returns SERVFAIL? I imagine that just like in any context, a temporary error that's constantly returned is eventually de facto treated as permanent insofar as the client gives up and goes away. > > If we were starting from scratch, I'd probably classify many of the other > rcodes as permanent errors, but we aren't. Absent some evidence of this > causing real world problems, I think we need to leave it the way it is. > I think this is an error that warrants correction. It might be interesting to know what some implementations have done here, e.g., if implementers decided to implement based on RFC1035 rather than RFC4408. > > > > > Why 20 seconds for the overall run time? > > > > > > This is carried forward from RFC 4408. It was moved from section 10.1 > to > > > 4.6.4 as part of issue #6, but the value is unchanged. I'm not aware > of > > > any > > > issues with what's defined in 4408. > > > > I don't have an issue with 20 specifically. I'm just anticipating the > "Why > > 20?" question from someone else. > > Because it's been that way for a long time and seems to work. IIRC, at the > time, it was the shortest time we could get some agreement around. If it > were > just me, I'd pick a number closer to 2 than 20. > I suggest a sentence saying this was chosen arbitrarily, or based on the fact that SMTP sessions that take longer than this are quite unusual, or something. > > > > The second-last paragraph is weirdly wrapped. Is the XML ok there? > > > > > > I think I fixed that already based on John Levine's comments. Please > > > double > > > check the new draft. > > > > Will do when it comes out. > > > > > > Section 5.6: > > > > > > > > For IPv4, shouldn't the CIDR be 1*2DIGIT? For IPv6, shouldn't the > CIDR > > > > > > be > > > > > > > 1*3DIGIT? > > > > > > I don't know. It's unchanged from RFC 4408 right now, but I'd like > other > > > opinions on changes here (ABNF makes my head hurt). > > > > It's probably not harmful to leave it, really. It's just an observation > > that 1*DIGIT allows 000000024 (which is probably fine) but also allows > > 1048576 (which probably isn't). 1*2DIGIT would limit it to 00-99 at > least. > > > > You could also cover this in prose by saying 1*DIGIT and then in either > an > > ABNF comment ("; blahblah") or in text nearby say that it has to evaluate > > to an integer from 0 to 32 for v4 and 0 to 128 for v6. > > Maybe import the definitions in http://www.ietf.org/rfc/rfc3986.txtinstead? > I looked through the collected grammar in there and didn't see anything that covered CIDR expressions. Now that my eyes have un-crossed, did you have specific one(s) there in mind? > > macro-letter = %x73 / %x6c / ... > > We resolved this already, right? > Yes, disregard. > > > The "SPF verifiers MUST make sure..." doesn't seem actionable to me. > Do > > > we > > > > > > > really expect Received-SPF generators to be able to identify and > exclude > > > > malicious data? > > > > > > I think you have to. I've seen people put html pointing to malicious > web > > > sites in SPF records. Thanks to someone privately pointing this class > of > > > attack out to me, my SPF validator now properly escapes anything that's > > > retrieved from DNS. > > > > It's the "malicious data" part that concerns me because what constitutes > an > > effective data attack is very context-sensitive. > > Do you still think it needs a change? > Yes, but it's not a hill on which I plan to die. I'd love to hear what others think though. -MSK --f46d043c062e101c2304dcedae92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 17, 2013 at 10:04 AM, Scott Kitterman <spf2@= kitterman.com> wrote:
On Wednesday, May 08, 2013= 02:09:24 PM Murray S. Kucherawy wrote:
> On Wed, May 8, 2013 at 10:14 AM, Scott Kitterman <spf2@kitterman.com> wrote:
> > > The last paragraph makes the claim that domain reputation is= likely to
> > > be
> > > more accurate than IP reputation. =A0Is it worthwhile to add= a sentence or
> > > two explaining why this is true?
> >
> > I don't think so. =A0First, it's speculation and I don= 9;t think enough of a
> > case
> > for it can be made without being too long/distracting. =A0Second,= it's not
> > part
> > of the protocol, so it not something we should worry about overmu= ch.
>
> I think a simple, brief addition would do it:
>
> This is advantageous because reputation of domain names is likely to > =A0 =A0be more accurate than reputation of host IP addresses since dom= ains
> are more likely to be stable over the long term.
>
> =A0...or something like that.

I think that would have been fine. =A0I already took it out. =A0Do yo= u think I
should put it back?

I do.
=A0
> > Section 2.1:
> > > I think someone else already mentioned this, but how does en= couraging a
> > > second check decrease DNS resource use?
> >
> > I did reply to this already. =A0It's a matter of HELO records= generally
> > being
> > much 'cheaper' than mail from records.
>
> As long as the document explains that in a sentence or two, we're = good.

Here's what I added:

... (if a conclusive determination about the message can be made based on a=
check of "HELO", then the use of DNS resources to process the typ= ically more
complex "MAIL FROM" can be avoided).

I suspect that's better as its own sentence rather than somethi= ng parenthetical, but the text is right.
=A0

> > > Section 2.3:
> > >
> > > The second paragraph is loaded with negatives "no... ne= ither... nor."
> > > Suggest: "ADMDs can publish SPF records that authorize = no hosts to use
> > > their DNS domain names in HELO or MAIL FROM commands during = SMTP
> >
> > sessions."
> >
> > I added that, because it's a good point, but it doesn't r= eplace the
> > existing
> > text which attempts to (without being too pointed about receiver = policy)
> > say
> > that if you want receivers to be able to reject mail that didn= 9;t come from
> > authorized hosts, you need a -all record. =A0Some senders care ab= out
> > supporting
> > these negative assertions, others don't.
>
> My comment wasn't so much to correct the text, but to point out th= at the
> sentence is hard to read with so many negatives.
>
> Doesn't the sentence I proposed say the same thing?

Almost. =A0It loses the nuance that this is only appropriate for host= s that send
no mail. =A0You'd think that'd be obvious, but it's not.

So:

ADMDs that wish to decl= are that no hosts are authorized to use their DNS domain names in the HELO = or MAIL FROM commands during SMTP sessions can publish SPF records that say= so.

> > Section 2.4:
> > > Isn't the fourth paragraph implicit in any standards spe= cification?
> > > That
> > > is, do we really need it?
> >
> > I see your point, but I think it should actually stay. =A0Consist= ency of
> > evaluation across multiple implementations is key to the success = of the
> > protocol. =A0IIRC, you said during the debate that if you were im= plementing
> > SPF,
> > you'd ignore the macro requirements. =A0You're, of course= , free to do that,
> > just
> > don't say you implemented SPF.
>
> I would agree with all of that except the need to say it in a Proposed=
> Standard. =A0Any other opinions?

I didn't here much in the way of opinions on this. =A0Since it= 9;s carried forward
from 4408, I'll leave it for now.

R= ats.=A0 Since we're looking for text to slash in response to the bloat = complaint, this is a prime candidate.

=A0
> > > Section 2.6.7:
> > >
> > > Does "permerror" also result when permanent DNS er= rors occur?
> >
> > Tell me how to figure out when a DNS error is permanent and then = maybe.
> > =A0Given
> >
> > what's described in 4.4 Record Lookup, I think only extended = SERVFAIL (if
> > the
> > receiver has implemented the temperror -> permerror promotion = option) can
> > currently get a permerror.
>
> RCODEs 1, 3, 4, and 5 all look permanent to me as defined in RFC1035, = in
> that a retry is unlikely to yield a different result absent an operato= r
> changing some configuration or zone data. =A00 is "no error"= and 2 is "server
> failure"; the latter is obviously permanent (but desirable), leav= ing 2 for
> the case where a timeout or some other transient thing occurred.

This is a good point.

3 is permanent, but it's not an error. =A0It's no data. =A0Currentl= y the draft
says anything other than 0 or 3 is a temperror.

True, NODATA isn't an error, but it is final.
=A0
=

5 could be temporary, I'd think (query refused due to overload maybe?)<= br>

=A0Overload is supposed to be SERVFAIL,= I think.=A0 Andrew?

I think 5 is used for policy things = like "You're not allowed to know that."



Looking at http://www.iana.org/assign= ments/dns-parameters/dns-parameters.xml#dns-parameters-6, I agree that = many of these DNS errors could
be permanent, but the spec calls for temperror in these cases.

The only temporary errors that turned out to really be permanent that I'= ;ve
seen in the wild are some SERVFAIL (2).

As in a server that constantly returns SERVFAIL?=A0 I imagine that just li= ke in any context, a temporary error that's constantly returned is even= tually de facto treated as permanent insofar as the client gives up and goe= s away.
=A0

If we were starting from scratch, I'd probably classify many of the oth= er
rcodes as permanent errors, but we aren't. =A0Absent some evidence of t= his
causing real world problems, I think we need to leave it the way it is.
=

I think this is an error that warrants cor= rection.=A0 It might be interesting to know what some implementations have = done here, e.g., if implementers decided to implement based on RFC1035 rath= er than RFC4408.
=A0

> > > Why 20 seconds for the overall run time?
> >
> > This is carried forward from RFC 4408. =A0It was moved from secti= on 10.1 to
> > 4.6.4 as part of issue #6, but the value is unchanged. =A0I'm= not aware of
> > any
> > issues with what's defined in 4408.
>
> I don't have an issue with 20 specifically. =A0I'm just antici= pating the "Why
> 20?" question from someone else.

Because it's been that way for a long time and seems to work. =A0= IIRC, at the
time, it was the shortest time we could get some agreement around. =A0If it= were
just me, I'd pick a number closer to 2 than 20.
I suggest a sentence saying this was chosen arbitrarily, or ba= sed on the fact that SMTP sessions that take longer than this are quite unu= sual, or something.
=A0
> > > The second-last paragraph is weirdly wrapp= ed. =A0Is the XML ok there?
> >
> > I think I fixed that already based on John Levine's comments.= =A0 Please
> > double
> > check the new draft.
>
> Will do when it comes out.
>
> > > Section 5.6:
> > >
> > > For IPv4, shouldn't the CIDR be 1*2DIGIT? =A0For IPv6, s= houldn't the CIDR
> >
> > be
> >
> > > 1*3DIGIT?
> >
> > I don't know. =A0It's unchanged from RFC 4408 right now, = but I'd like other
> > opinions on changes here (ABNF makes my head hurt).
>
> It's probably not harmful to leave it, really. =A0It's just an= observation
> that 1*DIGIT allows 000000024 (which is probably fine) but also allows=
> 1048576 (which probably isn't). =A01*2DIGIT would limit it to 00-9= 9 at least.
>
> You could also cover this in prose by saying 1*DIGIT and then in eithe= r an
> ABNF comment ("; blahblah") or in text nearby say that it ha= s to evaluate
> to an integer from 0 to 32 for v4 and 0 to 128 for v6.

Maybe import the definitions in http://www.ietf.org/rfc/rfc3986.txt instea= d?

I looked through the collected gramm= ar in there and didn't see anything that covered CIDR expressions.=A0 N= ow that my eyes have un-crossed, did you have specific one(s) there in mind= ?
=A0
> =A0 =A0macro-letter =A0 =A0 =3D =A0%x73 / %x6c / ...=

We resolved this already, right?

= Yes, disregard.
=A0
> > The "SPF verifiers MUST make sure..."= doesn't seem actionable to me. =A0Do
> > we
> >
> > > really expect Received-SPF generators to be able to identify= and exclude
> > > malicious data?
> >
> > I think you have to. =A0I've seen people put html pointing to= malicious web
> > sites in SPF records. =A0Thanks to someone privately pointing thi= s class of
> > attack out to me, my SPF validator now properly escapes anything = that's
> > retrieved from DNS.
>
> It's the "malicious data" part that concerns me because = what constitutes an
> effective data attack is very context-sensitive.

Do you still think it needs a change?

=
Yes, but it's not a hill on which I plan to die.=A0 I'd love t= o hear what others think though.

-MSK
--f46d043c062e101c2304dcedae92-- From doug.mtview@gmail.com Fri May 17 10:56:21 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D3021F966F for ; Fri, 17 May 2013 10:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLSKf9AYXR3o for ; Fri, 17 May 2013 10:56:21 -0700 (PDT) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id C094F21F9668 for ; Fri, 17 May 2013 10:56:10 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id un1so3495882pbc.26 for ; Fri, 17 May 2013 10:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=PI5K4iynveyNmpwmh1boObs4DQUtXID9JXGlQwfiu68=; b=LWqSpZ6F6ZGdWGcySKEopHi+CctArCkkRK/R3L6P6hy59kuLZlyBnYIgoxDwtaBiQA lxiMxNC19mMhHudDqJ05VOEpvePLpWzPvkc75bmGMtO0XyCN5YNdgqHvEJMbZJazPZyG qaGt8diuulX691PqbxHRN8G1x/f08EPhc7iurwzfa6cZ9Sxa46bmwll8BSy0Ze6nxn3r T1FiXmGLT2ucdoYwoUb8o6pZqlAXpVnPGLyUow/gBk6IyB76t6qXWwws26LGelUxKQHS ls+6GG1s6UfnA29OZCo7rrVBD2OzC2MiqNIdIpqkUXt09puvWig4HkDCj0YLay7cNnkb 0yHg== X-Received: by 10.68.212.72 with SMTP id ni8mr25838522pbc.114.1368813370520; Fri, 17 May 2013 10:56:10 -0700 (PDT) Received: from ?IPv6:2601:9:3180:3e:ec29:6b88:53d8:c31e? ([2601:9:3180:3e:ec29:6b88:53d8:c31e]) by mx.google.com with ESMTPSA id bs2sm13091445pad.17.2013.05.17.10.56.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 May 2013 10:56:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Douglas Otis In-Reply-To: <2434290.IfmuWxVHGh@scott-latitude-e6320> Date: Fri, 17 May 2013 10:56:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2434290.IfmuWxVHGh@scott-latitude-e6320> To: Scott Kitterman X-Mailer: Apple Mail (2.1503) Cc: spfbis@ietf.org Subject: Re: [spfbis] WGLC Reviews/Comments X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 17:56:21 -0000 On May 17, 2013, at 10:10 AM, Scott Kitterman = wrote: > I think I'm caught up now. If I missed something that still needs=20 > change/discussion, please let us know. Dear Scott, The nixed macro I-D will cleaned up, and your inputs even off-list would = be helpful. Regards, Douglas Otis= From spf2@kitterman.com Fri May 17 11:16:54 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C11C21F9701 for ; Fri, 17 May 2013 11:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.72 X-Spam-Level: X-Spam-Status: No, score=-3.72 tagged_above=-999 required=5 tests=[AWL=0.879, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rm+5Crg3hj9S for ; Fri, 17 May 2013 11:16:49 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B5AED21F9700 for ; Fri, 17 May 2013 11:16:49 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DE4C720E40FE; Fri, 17 May 2013 14:16:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368814608; bh=V7P4itmQ1c4TnOMPTRJHFDkcS/ygNqnkuE9quz+02pA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iTpqgq5WLGjdN7RBbqZ2HgOWpUJnCDtGGG2jk3njRMtDZ93i0ksNOMPsem9q0SNeN LARYhE3T6z6JaGKZ9iNPjD7i6aNpPdYpYp+4jg4hTV2fX4bUQT4/EX4G+dPXL2yj7L TVVDCRtL4Qe55L8TQA8owpcPl10PsqEyIBoJINTk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C05E320E40F6; Fri, 17 May 2013 14:16:48 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 14:16:47 -0400 Message-ID: <3959121.TAYYFWDYSi@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <20130409062431.GK24624@mx1.yitter.info> <1744498.RZtYgTOBXh@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 18:16:54 -0000 On Friday, May 17, 2013 10:54:52 AM Murray S. Kucherawy wrote: > On Fri, May 17, 2013 at 10:04 AM, Scott Kitterman wrote: > > On Wednesday, May 08, 2013 02:09:24 PM Murray S. Kucherawy wrote: > > > On Wed, May 8, 2013 at 10:14 AM, Scott Kitterman > > > > wrote: > > > > > The last paragraph makes the claim that domain reputation is likely > > to be > > > > > more accurate than IP reputation. Is it worthwhile to add a > > sentence or > > > > > two explaining why this is true? > > > > > > > > I don't think so. First, it's speculation and I don't think enough of > > a case > > > > for it can be made without being too long/distracting. Second, it's > > not part > > > > of the protocol, so it not something we should worry about overmuch. > > > > > > I think a simple, brief addition would do it: > > > > > > This is advantageous because reputation of domain names is likely to > > > be more accurate than reputation of host IP addresses since domains > > > are more likely to be stable over the long term. > > > ...or something like that. > > > > I think that would have been fine. I already took it out. Do you think I > > should put it back? > > I do. OK. Done. > > > > Section 2.1: > > > > > I think someone else already mentioned this, but how does > > encouraging a > > > > > second check decrease DNS resource use? > > > > > > > > I did reply to this already. It's a matter of HELO records generally > > > > being > > > > much 'cheaper' than mail from records. > > > > > > As long as the document explains that in a sentence or two, we're good. > > > > Here's what I added: > > > > ... (if a conclusive determination about the message can be made based on > > a check of "HELO", then the use of DNS resources to process the typically > > more complex "MAIL FROM" can be avoided). > > I suspect that's better as its own sentence rather than something > parenthetical, but the text is right. OK. Changed. > > > > > Section 2.3: > > > > > > > > > > The second paragraph is loaded with negatives "no... neither... > > > > > nor." > > > > > Suggest: "ADMDs can publish SPF records that authorize no hosts to > > > > use > > > > > > > their DNS domain names in HELO or MAIL FROM commands during SMTP > > > > > > > > sessions." > > > > > > > > I added that, because it's a good point, but it doesn't replace the > > > > existing > > > > text which attempts to (without being too pointed about receiver > > > > policy) > > > > > > say > > > > that if you want receivers to be able to reject mail that didn't come > > > > from > > > > > > authorized hosts, you need a -all record. Some senders care about > > > > supporting > > > > these negative assertions, others don't. > > > > > > My comment wasn't so much to correct the text, but to point out that the > > > sentence is hard to read with so many negatives. > > > > > > Doesn't the sentence I proposed say the same thing? > > > > Almost. It loses the nuance that this is only appropriate for hosts that > > send > > no mail. You'd think that'd be obvious, but it's not. > > So: > > ADMDs that wish to declare that no hosts are authorized to use their DNS > domain names in the HELO or MAIL FROM commands during SMTP sessions can > publish SPF records that say so. Based on this, I changed it to: ADMDs that wish to declare that no hosts are authorized to use their DNS domain names in the HELO or MAIL FROM commands during SMTP sessions can publish SPF records that say so for domain names that are neither used in the domain part of email addresses nor expected to originate mail. > > > Section 2.4: > > > > > Isn't the fourth paragraph implicit in any standards specification? > > > > > That > > > > > is, do we really need it? > > > > > > > > I see your point, but I think it should actually stay. Consistency of > > > > evaluation across multiple implementations is key to the success of > > > > the > > > > protocol. IIRC, you said during the debate that if you were > > > > implementing > > > > > > SPF, > > > > you'd ignore the macro requirements. You're, of course, free to do > > > > that, > > > > > > just > > > > don't say you implemented SPF. > > > > > > I would agree with all of that except the need to say it in a Proposed > > > Standard. Any other opinions? > > > > I didn't here much in the way of opinions on this. Since it's carried > > forward > > from 4408, I'll leave it for now. > > Rats. Since we're looking for text to slash in response to the bloat > complaint, this is a prime candidate. > > > > > > Section 2.6.7: > > > > > > > > > > Does "permerror" also result when permanent DNS errors occur? > > > > > > > > Tell me how to figure out when a DNS error is permanent and then > > > > maybe. > > > > > > > > Given > > > > > > > > what's described in 4.4 Record Lookup, I think only extended SERVFAIL > > > > (if > > > > > > the > > > > receiver has implemented the temperror -> permerror promotion option) > > > > can > > > > > > currently get a permerror. > > > > > > RCODEs 1, 3, 4, and 5 all look permanent to me as defined in RFC1035, in > > > that a retry is unlikely to yield a different result absent an operator > > > changing some configuration or zone data. 0 is "no error" and 2 is > > > > "server > > > > > failure"; the latter is obviously permanent (but desirable), leaving 2 > > > > for > > > > > the case where a timeout or some other transient thing occurred. > > > > This is a good point. > > > > 3 is permanent, but it's not an error. It's no data. Currently the draft > > says anything other than 0 or 3 is a temperror. > > True, NODATA isn't an error, but it is final. > > > 5 could be temporary, I'd think (query refused due to overload maybe?) > > Overload is supposed to be SERVFAIL, I think. Andrew? > > I think 5 is used for policy things like "You're not allowed to know that." > > > Looking at > > http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-para > > meters-6, I agree that many of these DNS errors could > > be permanent, but the spec calls for temperror in these cases. > > > > The only temporary errors that turned out to really be permanent that I've > > seen in the wild are some SERVFAIL (2). > > As in a server that constantly returns SERVFAIL? I imagine that just like > in any context, a temporary error that's constantly returned is eventually > de facto treated as permanent insofar as the client gives up and goes away. > > > If we were starting from scratch, I'd probably classify many of the other > > rcodes as permanent errors, but we aren't. Absent some evidence of this > > causing real world problems, I think we need to leave it the way it is. > > I think this is an error that warrants correction. It might be interesting > to know what some implementations have done here, e.g., if implementers > decided to implement based on RFC1035 rather than RFC4408. All of the ones I know of make anything not 0 or 3 a temperror. I agree it's wrong, but is it an error that, in operation, causes any problems? If not, I don't think we should fix it. > > > > > Why 20 seconds for the overall run time? > > > > > > > > This is carried forward from RFC 4408. It was moved from section 10.1 > > > > to > > > > > > 4.6.4 as part of issue #6, but the value is unchanged. I'm not aware > > > > of > > > > > > any > > > > issues with what's defined in 4408. > > > > > > I don't have an issue with 20 specifically. I'm just anticipating the > > > > "Why > > > > > 20?" question from someone else. > > > > Because it's been that way for a long time and seems to work. IIRC, at > > the > > time, it was the shortest time we could get some agreement around. If it > > were > > just me, I'd pick a number closer to 2 than 20. > > I suggest a sentence saying this was chosen arbitrarily, or based on the > fact that SMTP sessions that take longer than this are quite unusual, or > something. The number was extracted from the usual location. OK, not that. Is it common to justify design decisions like this in the draft of the text? Might this be better for sm's write up than the actual draft? > > > > > The second-last paragraph is weirdly wrapped. Is the XML ok there? > > > > > > > > I think I fixed that already based on John Levine's comments. Please > > > > double > > > > check the new draft. > > > > > > Will do when it comes out. > > > > > > > > Section 5.6: > > > > > > > > > > For IPv4, shouldn't the CIDR be 1*2DIGIT? For IPv6, shouldn't the > > > > CIDR > > > > > > be > > > > > > > > > 1*3DIGIT? > > > > > > > > I don't know. It's unchanged from RFC 4408 right now, but I'd like > > > > other > > > > > > opinions on changes here (ABNF makes my head hurt). > > > > > > It's probably not harmful to leave it, really. It's just an observation > > > that 1*DIGIT allows 000000024 (which is probably fine) but also allows > > > 1048576 (which probably isn't). 1*2DIGIT would limit it to 00-99 at > > > > least. > > > > > You could also cover this in prose by saying 1*DIGIT and then in either > > > > an > > > > > ABNF comment ("; blahblah") or in text nearby say that it has to > > > evaluate > > > to an integer from 0 to 32 for v4 and 0 to 128 for v6. > > > > Maybe import the definitions in > > http://www.ietf.org/rfc/rfc3986.txtinstead? > > I looked through the collected grammar in there and didn't see anything > that covered CIDR expressions. Now that my eyes have un-crossed, did you > have specific one(s) there in mind? I was looking at 3.2.2, which (you are correct) defines IPv4/IPv6, but not CIDR (I lost track of which one we were discussing), sorry. Unfortunately RFC 4632 doesn't have an ABNF. > > > macro-letter = %x73 / %x6c / ... > > > > We resolved this already, right? > > Yes, disregard. > > > > > The "SPF verifiers MUST make sure..." doesn't seem actionable to me. > > > > Do > > > > > > we > > > > > > > > > really expect Received-SPF generators to be able to identify and > > > > exclude > > > > > > > malicious data? > > > > > > > > I think you have to. I've seen people put html pointing to malicious > > > > web > > > > > > sites in SPF records. Thanks to someone privately pointing this class > > > > of > > > > > > attack out to me, my SPF validator now properly escapes anything > > > > that's > > > > retrieved from DNS. > > > > > > It's the "malicious data" part that concerns me because what constitutes > > > > an > > > > > effective data attack is very context-sensitive. > > > > Do you still think it needs a change? > > Yes, but it's not a hill on which I plan to die. I'd love to hear what > others think though. OK. I'll keep waiting. Scott K From superuser@gmail.com Fri May 17 11:18:35 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB7621F9051 for ; Fri, 17 May 2013 11:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NKCvOlnfBM4 for ; Fri, 17 May 2013 11:18:33 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id EEF1421F8FFA for ; Fri, 17 May 2013 11:18:32 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id p57so2303050wes.18 for ; Fri, 17 May 2013 11:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mmw9DsczHTngt0935wogS0vSNEyh4s2guHLbr7PdEBE=; b=cfLJGFQvcdeGQb63++58/Qfd9BU7emv5milGw5MYjR3t8BLhop+6v00vI59vH43apa fTIHvMVhuqKx8eCfI2Woho1SNckVOr3FO0lpyhRajs9BgmXcMp95Sal9MoSRqKShxdsv ny8R3YkrcP8Jee8ylkdz96537+lTSPA27HTZnHHEHUsxm7m08vA01yuD2ovJXZpwn4Qf WGxYzPPBUdWTQrZ33UzEYtIJIWOhpE9ZXDcNDz2rjC3jCAt3K4Lp42yizRooiDQTAajp SkbdaEUG638QCTZJWLK2f9d+46SlCSuFrGgqiN68T+0pHGkfn4R+3xe98VdxzcLkwXjv o6kg== MIME-Version: 1.0 X-Received: by 10.195.12.135 with SMTP id eq7mr2120348wjd.17.1368814712059; Fri, 17 May 2013 11:18:32 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Fri, 17 May 2013 11:18:31 -0700 (PDT) In-Reply-To: <2434269.5GrKsYB81B@scott-latitude-e6320> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <1972467.x8au6JTDZS@scott-latitude-e6320> <2434269.5GrKsYB81B@scott-latitude-e6320> Date: Fri, 17 May 2013 11:18:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7bb04b24acfe5a04dcee027b Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 18:18:35 -0000 --047d7bb04b24acfe5a04dcee027b Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 17, 2013 at 6:58 AM, Scott Kitterman wrote: > > I'm confused now about what we're trying to say. I think the RFC is > > trying to say that it's a bad idea to try to check identifiers other than > > HELO and MAIL FROM using the check_host() function, unless you really > know > > what you're doing and so does the sender. Is that correct? If not, > what's > > the intent? Maybe with that clarified, I can suggest an alternative. > > Close. It goes a bit further. SPF records have to be interpreted in the > context of SPF. As a receiver, that's ALL you can know. It's not possible > for receivers to accurately translate something written in an SPF context > to > another one. Any such use has to be opt-in so that there's an explicit > statement from the sender that their SPF record is suitable for the > alternative use. > What's an example of unacceptable use? I'm possibly not understanding exactly what "SPF context" means. > I believe the issue is that the token is defined in two places in > > the bis draft, namely 2.4 and 4.1. We should consolidate them and ensure > > the consolidated one is complete. > > Here's that last paragraph of 2.4: > > > Implementations have to take care to correctly extract the > > from the data given with the SMTP MAIL FROM command as many MTAs will > > still accept such things as source routes (see [RFC5321], Appendix > > C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). > > These archaic features have been maliciously used to bypass security > > systems. > > I think it's a cautionary tale, not a definition. This could be moved to > 4.1, > I suppose, but I don't see what it adds to do so. > That's not the part of 2.4 I mean. 2.4 contains: - the domain portion of the "MAIL FROM" or "HELO" identity. Meanwhile 4.1 contains: - the domain that provides the sought-after authorization information; initially, the domain portion of the "MAIL FROM" or "HELO" identity. They're not exactly the same. It's cleaner to define in one place, completely, and then replace the other one with a reference to that definition. > > > > > > > 'Generating non-delivery notifications to forged identities > that > > > have failed the authorization check is a source of backscatter and > > > > > SHOULD be avoided.' > > > > > > > > > > > > This RFC 2119 SHOULD is not in RFC 4408. The above does not have > > > > > > anything to do with Sender Policy Framework. It was mentioned > > > > > > during > > > > > > WG discussions that "SPF can help the backscatter problem" [2]. > > > > > > This > > > > > > text may have been introduced in response to a review [3]. Is > this > > > > > > an enhancement or a clarification? > > > > > > > > > >It's a clarification. > > > > > > > > In a previous comment I mentioned that "my reading of the above is > > > > that it is neither an enhancement or a clarification. I suggest > > > > removing the text". > > > > > > So you think it's not something that should be avoided? > > > > I think it's something to be avoided, but the choice of generating an NDN > > has nothing to do with the SPF protocol itself. It's a local policy > > matter. I agree with strong language, but not SHOULD. > > OK. Would you please suggest strong, but not 2119 text? It would be a > help. > Sure: Generating non-delivery notifications to forged identities that have failed the authorization check often constitutes backscatter, i.e., inactionable, nuisance rejection notices. Operators are [strongly] advised to avoid such practices. > > > > > > In Section 4.1: > > > > > > ' - the domain that provides the sought-after > > > authorization > > > > > > information; initially, the domain portion of the > > > "MAIL > > > > > > FROM" or "HELO" identity.' > > > > > > > > > > > > The above text is different from the text in Section 2.4. > > > > > > > > > >Yes, but not inconsistent with it. > > > > > > > > I suggest having the definition in one place for consistency. What I > > > > am looking at is consistency for the reader instead of where I > > > > believe that there is inconsistency. > > > > > > They are talking about different things relative to domains, so given > the > > > organization, I don't see an easy way to do that. I'm open to > > > suggestions. > > > > The definition in 2.4 is less complete than that in 4.1, and also there > are > > references to the one in 2.4. I propose copying the 4.1 version on top > of > > the 2.4 version, remove the 4.1 definitions and have them refer to 2.4. > > I'm still not seeing 2.4 as a definition. If there is a consolidation > needed, > I think 4.1 is the right place for it. If someone can specify exactly what > text in 2.4 is definitional, I'll try and consolidate it into 2.4 (and > check > the references). > I think I provided that above. Hope that clarifies things. > From my point of view, we have a new proposed solution that the WG > developed > to a long standing issue. It seems a bit odd to then demand that it can > only > be part of the output of the WG if someone else implemented it. > I'm not making that demand, but I do think it bolsters our position if it's seen real world action. I don't have any objection to including it. We just need to be prepared to push on it if the WG agrees that it's what we want to say and it's met with resistance. > > > > > > In Section 6: > > > > > > 'The modifiers defined in this document ("redirect" and "exp") > > > > > > MAY > > > > > > appear anywhere in the record, but SHOULD appear at the end, > > > after > > > > > > all mechanisms.' > > > > > > > > > > > > This text is in RFC 4408. I would label the RFC 2119 usage as > > > > > > defective. > > > > > > > > > >Why? > > > > > > > > My previous comment was: "The text tells me that it is ok if the > > > > modifiers appear anywhere but they should appear at the end after all > > > > mechanisms. It would be clearer to say that it should appear after > > > > all mechanisms". > > > > > > That is defective use of 2119 language? I disagree that that would be > > > clearer. > > > > "MAY" is essentially meaningless except perhaps to emphasize that the > > implementer has a choice with no protocol consequence. You could make it > > "can" and have the same effect. > > There's an inverse requirement on implementers that SPF verifiers can't > assume > modifiers are in any particular place in the record. So the fact that > this MAY > happen has an effect on verifier implementation requirements (and it would > affect > interoperability if they don't consider it). > Yeah. Ultimately I don't feel strongly about it. I'm fine with it as it is, but it might be another instance of "shouting". > > > > > > "This SHOULD be a fully qualified domain name, but if one does > > > > > > not > > > > > > exist (as when the checking is done by a MUA) or if policy > > > > > > restrictions > > > > > > dictate otherwise, the word "unknown" SHOULD be substituted." > > > > > > > > > > > > The RFC 2119 key words are in RFC 2119. I don't know what to > say. > > > > > > > > > >OK. > > > > > > > > Murray comemnted: "I think that looks fine as-is, though we could > > > > change the first SHOULD to "ought to" because it's a transformation > > > > of other input and not an implementation choice. (And I assume you > > > > mean they were in RFC4408.) > > > > > > Since the values end up in log files and Received-SPF/authentication > > > results > > > header fields that are provided to be processed on other systems, it > is an > > > interoperability issue. Having consistency helps interoperability. > I'd > > > prefer to leave it. > > > > My point here is that the first SHOULD is essentially saying "the > hostname > > of the machine SHOULD be an FQDN", but this is ineffective because the > > person configuring this host might not know a thing about SPF or this > > requirement and call the machine "banana". What does the SPF module do > > with this SHOULD now? > > > > "ought to", "is typically", "is ideally", etc. > > What the first SHOULD is trying to say is about how you expand the macro > (use > hostname -f and not hostname). > My point is that there are some hosts for which "hostname -f" and "hostname" produce the same single-label output. Lots of Windows hosts are called "localhost", for example, and have no idea what their domain name is (and don't need to). > > > > > > In Section 8.2: > > > > > > 'A "neutral" result MUST be treated exactly like the "none" > > > result; > > > > > > > > > the distinction exists only for informational purposes.' > > > > > > Why is an existing RFC 2119 restated? > > > > > > > > > >Because of the structure of the document that the WG came up with. > I > > > don't > > > > >find a good way to avoid it and not make it less readable. > > > > > > > > I'll leave this issue open as it was mentioned in the AppsDir review. > > > > I'll help with this if needed. > > Thanks. > If you email me the current XML (when you're ready to take a break from it) I'll take a run at that. > > > > > > In Section 10.1.2: > > > > > > "Publishing SPF records for domains that send no mail is > > > > > > > > > > > > a well established best practice." > > > > > > > > > > > > I am not aware of that best practice. I did a few DNS queries: > > > > > > > > > > > > ;; QUESTION SECTION: > > > > > > ;bing.com. IN TXT > > > > > > > > > > > > ;; ANSWER SECTION: > > > > > > bing.com. 3600 IN TXT "v=msv1 > > > > > > t=6097A7EA-53F7-4028-BA76-6869CB284C54" > > > > > > > > > > > > ;; QUESTION SECTION: > > > > > > ;com.com. IN TXT > > > > > > > > > > > > ;; ANSWER SECTION: > > > > > > com.com. 293 IN TXT > > > > > > "google-site-verification:esSnoZdChIkkfCfS9MMgqNhE0yaXfnnZWdZPuBf7e8k" > > > > > > > >OK. See > > > > > > > http://www.bits.org/publications/security/BITSEmailAuthenticationFeb2013.p > > > d > > > > > > > >f > > > > > > > > I suggest "good practice" as mentioned by Alessandro. > > > > > > What's wrong with the way it is? I think the current text is accurate. > > > > The OpenDKIM SPF data recorded 1157 domains with "v=spf1 -all" records. > > The source of your domain list was from domains seen in email, right? So > that's 1157 cases where they got it wrong. I don't think your survey would > have caught correct uses of it (or do I misremember how you got your domain > list)? > I'm missing something. I thought the point was to find instances where there's been a declaration via SPF that "this domain sends no mail". Isn't "v=spf1 -all" the way to do that? > Personally, I think this whole appendix can be tagged with "[For IESG > > information only]" and removed prior to publication. It's the kind of > > thing we usually include in shepherd writeups and not in the RFCs > > themselves. > > Which one are we on? Appendix J is intended to be removed before > publication. > Appendix I. Protocol Status. -MSK --047d7bb04b24acfe5a04dcee027b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 17, 2013 at 6:58 AM, Scott Kitterman <spf2@k= itterman.com> wrote:
> I'm confused now= about what we're trying to say. =A0 I think the RFC is
> trying to say that it's a bad idea to try to check identifiers oth= er than
> HELO and MAIL FROM using the check_host() function, unless you really = know
> what you're doing and so does the sender. =A0Is that correct? =A0I= f not, what's
> the intent? =A0Maybe with that clarified, I can suggest an alternative= .

Close. =A0It goes a bit further. =A0SPF records have to be inte= rpreted in the
context of SPF. =A0As a receiver, that's ALL you can know. =A0It's = not possible
for receivers to accurately translate something written in an SPF context t= o
another one. =A0Any such use has to be opt-in so that there's an explic= it
statement from the sender that their SPF record is suitable for the
alternative use.

What's an example = of unacceptable use?=A0 I'm possibly not understanding exactly what &qu= ot;SPF context" means.

> I believe the issue is that the <domain> token is defined in two= places in
> the bis draft, namely 2.4 and 4.1. =A0We should consolidate them and e= nsure
> the consolidated one is complete.

Here's that last paragraph of 2.4:

> =A0 =A0Implementations have to take care to correctly extract the <= domain>
> =A0 =A0from the data given with the SMTP MAIL FROM command as many MTA= s will
> =A0 =A0still accept such things as source routes (see [RFC5321],= Appendix
> =A0 =A0C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]).=
> =A0 =A0These archaic features have been maliciously used to bypass sec= urity
> =A0 =A0systems.

I think it's a cautionary tale, not a definition. =A0This could be move= d to 4.1,
I suppose, but I don't see what it adds to do so.
=
That's not the part of 2.4 I mean.=A0 2.4 contains:
<= br>
  <domain> - the domain portion of the "MAIL =
FROM" or "HELO" identity.

Meanwhile 4.1 contains:

   <domain&=
gt; - the domain that provides the sought-after authorization
              information; initially, the domain portion of the "MAIL
              FROM" or "HELO" identity.
They're not exactly the same.=A0 It's cleaner to d= efine <domain> in one place, completely, and then replace the other o= ne with a reference to that definition.
=A0

> > > > > =A0 =A0'Generating non-delivery notifications = to forged identities that
> > have =A0failed the authorization check is a source of backscatter= and
> > > > SHOULD =A0be avoided.'
> > > > >
> > > > > This RFC 2119 SHOULD is not in RFC 4408. =A0The ab= ove does not have
> > > > > anything to do with Sender Policy Framework. =A0It= was mentioned
> > > > > during
> > > > > WG discussions that "SPF can help the backsca= tter problem" [2].
> > > > > This
> > > > > text may have been introduced in response to a rev= iew [3]. =A0Is this
> > > > > an enhancement or a clarification?
> > > >
> > > >It's a clarification.
> > >
> > > In a previous comment I mentioned that "my reading of t= he above is
> > > that it is neither an enhancement or a clarification. =A0I s= uggest
> > > removing the text".
> >
> > So you think it's not something that should be avoided?
>
> I think it's something to be avoided, but the choice of generating= an NDN
> has nothing to do with the SPF protocol itself. =A0It's a local po= licy
> matter. =A0I agree with strong language, but not SHOULD.

OK. =A0Would you please suggest strong, but not 2119 text? =A0It woul= d be a help.

Sure:

Ge= nerating non-delivery notifications to forged identities that have failed t= he authorization check often constitutes backscatter, i.e., inactionable, n= uisance rejection notices.=A0 Operators are [strongly] advised to avoid suc= h practices.
=A0
> > > > > In Section 4.1:
> > > > > =A0 =A0'<domain> - the domain that provi= des the sought-after
> > authorization
> > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0information; initia= lly, the domain portion of the
> > "MAIL
> > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0FROM" or "= ;HELO" identity.'
> > > > >
> > > > > The above text is different from the text in Secti= on 2.4.
> > > >
> > > >Yes, but not inconsistent with it.
> > >
> > > I suggest having the definition in one place for consistency= . =A0What I
> > > am looking at is consistency for the reader instead of where= I
> > > believe that there is inconsistency.
> >
> > They are talking about different things relative to domains, so g= iven the
> > organization, I don't see an easy way to do that. =A0I'm = open to
> > suggestions.
>
> The definition in 2.4 is less complete than that in 4.1, and also ther= e are
> references to the one in 2.4. =A0I propose copying the 4.1 version on = top of
> the 2.4 version, remove the 4.1 definitions and have them refer to 2.4= .

I'm still not seeing 2.4 as a definition. =A0If there is a consol= idation needed,
I think 4.1 is the right place for it. =A0If someone can specify exactly wh= at
text in 2.4 is definitional, I'll try and consolidate it into 2.4 (and = check
the references).

I think I provided tha= t above.=A0 Hope that clarifies things.
=A0
>From my point of view, we have a new proposed solution that the WG develope= d
to a long standing issue. =A0It seems a bit odd to then demand that it can = only
be part of the output of the WG if someone else implemented it.

I'm not making that demand, but I do think it = bolsters our position if it's seen real world action.=A0 I don't ha= ve any objection to including it.=A0 We just need to be prepared to push on= it if the WG agrees that it's what we want to say and it's met wit= h resistance.
=A0
&= gt; > > > > In Section 6:
> > > > > =A0 =A0'The modifiers defined in this document= ("redirect" and "exp")
> > > > > =A0 =A0MAY
> > > > > =A0 =A0 appear anywhere in the record, but SHOULD = appear at the end,
> > after
> > > > > =A0 =A0 all mechanisms.'
> > > > >
> > > > > This text is in RFC 4408. =A0I would label the RFC= 2119 usage as
> > > > > defective.
> > > >
> > > >Why?
> > >
> > > My previous comment was: "The text tells me that it is = ok if the
> > > modifiers appear anywhere but they should appear at the end = after all
> > > mechanisms. It would be clearer to say that it should appear= after
> > > all mechanisms".
> >
> > That is defective use of 2119 language? =A0I disagree that that w= ould be
> > clearer.
>
> "MAY" is essentially meaningless except perhaps to emphasize= that the
> implementer has a choice with no protocol consequence. =A0You could ma= ke it
> "can" and have the same effect.

There's an inverse requirement on implementers that SPF verifiers= can't assume
modifiers are in any particular place in the record. =A0So the fact that th= is MAY
happen has an effect on verifier implementation requirements (and it would = affect
interoperability if they don't consider it).

<= /div>
Yeah.=A0 Ultimately I don't feel strongly about it.=A0 I'= m fine with it as it is, but it might be another instance of "shouting= ".
=A0
> > &g= t; > > =A0 =A0"This SHOULD be a fully qualified domain name, but= if one does
> > > > > =A0 =A0not
> > > > > =A0 =A0 exist (as when the checking is done by a M= UA) or if policy
> > > > > =A0 =A0 restrictions
> > > > > =A0 =A0 dictate otherwise, the word "unknown&= quot; SHOULD be substituted."
> > > > >
> > > > > The RFC 2119 key words are in RFC 2119. =A0I don&#= 39;t know what to say.
> > > >
> > > >OK.
> > >
> > > Murray comemnted: "I think that looks fine as-is, thoug= h we could
> > > change the first SHOULD to "ought to" because it&#= 39;s a transformation
> > > of other input and not an implementation choice. =A0(And I a= ssume you
> > > mean they were in RFC4408.)
> >
> > Since the values end up in log files and Received-SPF/authenticat= ion
> > results
> > header fields that are provided to be processed on other systems,= it is an
> > interoperability issue. =A0Having consistency helps interoperabil= ity. =A0I'd
> > prefer to leave it.
>
> My point here is that the first SHOULD is essentially saying "the= hostname
> of the machine SHOULD be an FQDN", but this is ineffective becaus= e the
> person configuring this host might not know a thing about SPF or this<= br> > requirement and call the machine "banana". =A0What does the = SPF module do
> with this SHOULD now?
>
> "ought to", "is typically", "is ideally"= , etc.

What the first SHOULD is trying to say is about how you expand the ma= cro (use
hostname -f and not hostname).

My point= is that there are some hosts for which "hostname -f" and "h= ostname" produce the same single-label output.=A0 Lots of Windows host= s are called "localhost", for example, and have no idea what thei= r domain name is (and don't need to).
=A0
> > > > > In Section 8.2:
> > > > > =A0 =A0'A "neutral" result MUST be t= reated exactly like the "none"
> > result;
> >
> > > > > =A0 =A0 the distinction exists only for informatio= nal purposes.'
> > > > > Why is an existing RFC 2119 restated?
> > > >
> > > >Because of the structure of the document that the WG cam= e up with. =A0I
> > don't
> > > >find a good way to avoid it and not make it less readabl= e.
> > >
> > > I'll leave this issue open as it was mentioned in the Ap= psDir review.
>
> I'll help with this if needed.

Thanks.

If you email me the curre= nt XML (when you're ready to take a break from it) I'll take a run = at that.
=A0
> > > > > In Section 10.1.2:
> > > > > =A0 =A0"Publishing SPF records for domains th= at send no mail is
> > > > >
> > > > > =A0 =A0 a well established best practice." > > > > >
> > > > > I am not aware of that best practice. =A0I did a f= ew DNS queries:
> > > > >
> > > > > ;; QUESTION SECTION:
> > > > > ;bin= g.com. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IN =A0 =A0 =A0TXT
> > > > >
> > > > > ;; ANSWER SECTION:
> > > > > bing= .com. =A0 =A0 =A0 =A0 =A0 =A0 =A0 3600 =A0 =A0IN =A0 =A0 =A0TXT =A0 =A0= "v=3Dmsv1
> > > > > t=3D6097A7EA-53F7-4028-BA76-6869CB284C54"
> > > > >
> > > > > ;; QUESTION SECTION:
> > > > > ;com.= com. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IN =A0 =A0 =A0TXT
> > > > >
> > > > > ;; ANSWER SECTION:
> > > > > com.c= om. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0293 =A0 =A0 IN =A0 =A0 =A0TXT
> >
> > "google-site-verification:esSnoZdChIkkfCfS9MMgqNhE0yaXfnnZWd= ZPuBf7e8k"
> >
> > > >OK. =A0See
> >
> > http://www.bits.org/publications/se= curity/BITSEmailAuthenticationFeb2013.p
> > d
> >
> > > >f
> > >
> > > I suggest "good practice" as mentioned by Alessand= ro.
> >
> > What's wrong with the way it is? =A0I think the current text = is accurate.
>
> The OpenDKIM SPF data recorded 1157 domains with "v=3Dspf1 -all&q= uot; records.

The source of your domain list was from domains seen in email, right?= =A0So
that's 1157 cases where they got it wrong. =A0I don't think your su= rvey would
have caught correct uses of it (or do I misremember how you got your domain=
list)?

I'm missing something.=A0 I thoug= ht the point was to find instances where there's been a declaration via= SPF that "this domain sends no mail".=A0 Isn't "v=3Dspf= 1 -all" the way to do that?

> Personally, I think this whole appendix can be tagged with= "[For IESG
> information only]" and removed prior to publication. =A0It's = the kind of
> thing we usually include in shepherd writeups and not in the RFCs
> themselves.

Which one are we on? =A0Appendix J is intended to be removed before p= ublication.

Appendix I. Protocol Status= .

-MSK
--047d7bb04b24acfe5a04dcee027b-- From spf2@kitterman.com Fri May 17 11:27:49 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8D021F96B0 for ; Fri, 17 May 2013 11:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.779 X-Spam-Level: X-Spam-Status: No, score=-2.779 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2chAjmhm4MzQ for ; Fri, 17 May 2013 11:27:44 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 94BF021F961C for ; Fri, 17 May 2013 11:27:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1132820E40FE; Fri, 17 May 2013 14:27:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368815264; bh=8FwVMeoeQAHOUrNrR3/m3fYpby9i4v0M+QQ3hTyJbDc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=X65w8ZcXFZ8y5Dapgu12W9FY4IbiSFBCrx0yrBxtAvQmMXz6Nz73YEzv4ktWJUPgH IjOUj3boWKfV3x+MFVsgshFYtKf6NQz3WpMVC0buH4rL0zvtH/5706dWd80MMFFBuA O/0djm5tL6wXfq/fo0uCZqXo5UlF9erR29EujUOs= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E8AA320E40F6; Fri, 17 May 2013 14:27:43 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 14:27:43 -0400 Message-ID: <2482747.saR6I5RxRN@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <2434290.IfmuWxVHGh@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC Reviews/Comments X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 18:27:49 -0000 On Friday, May 17, 2013 10:56:07 AM Douglas Otis wrote: > On May 17, 2013, at 10:10 AM, Scott Kitterman wrote: > > I think I'm caught up now. If I missed something that still needs > > change/discussion, please let us know. > > Dear Scott, > > The nixed macro I-D will cleaned up, and your inputs even off-list would be > helpful. We've been asked not to address that now, so I'm focusing on the existing WGLC comments at the moment. Scott K From spf2@kitterman.com Fri May 17 11:41:49 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495CD21F9705 for ; Fri, 17 May 2013 11:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.768 X-Spam-Level: X-Spam-Status: No, score=-2.768 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyWgxkoncFvr for ; Fri, 17 May 2013 11:41:44 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 60F6121F9702 for ; Fri, 17 May 2013 11:41:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E22C220E40FE; Fri, 17 May 2013 14:41:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368816103; bh=vqsLUw0aLtjELQM5r+kQdajOF9bvzoHK1KAmzyGF14Q=; h=From:To:Subject:Date:In-Reply-To:References:From; b=HdLgZkOgP13hpY1LJVsNw/c5ghJy4wgvJ5hlbw66NMT2O9NQKtmyhyrjt++4ZmACQ bf2vx8JgFKtFj3kLHYp9R9c8za7EFlOMdiJk6G3NGZNkdcTfp1vZ72VyEcvB26cO67 ZveZBj5ROCyj7XXhwnCspF6cov+Sr5FMhc3HuSKQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C6F7420E40F6; Fri, 17 May 2013 14:41:43 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 14:41:43 -0400 Message-ID: <2042974.EAbD7S3bRR@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <2434269.5GrKsYB81B@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 18:41:49 -0000 On Friday, May 17, 2013 11:18:31 AM Murray S. Kucherawy wrote: > On Fri, May 17, 2013 at 6:58 AM, Scott Kitterman wrote: > > > I'm confused now about what we're trying to say. I think the RFC is > > > trying to say that it's a bad idea to try to check identifiers other > > > than > > > HELO and MAIL FROM using the check_host() function, unless you really > > > > know what you're doing and so does the sender. Is that correct? If not, > > what's > > > the intent? Maybe with that clarified, I can suggest an alternative. > > > > Close. It goes a bit further. SPF records have to be interpreted in the > > context of SPF. As a receiver, that's ALL you can know. It's not > > possible > > for receivers to accurately translate something written in an SPF context > > to > > another one. Any such use has to be opt-in so that there's an explicit > > statement from the sender that their SPF record is suitable for the > > alternative use. > > What's an example of unacceptable use? I'm possibly not understanding > exactly what "SPF context" means. The classic one is Sender ID. As I mentioned, I think DMARC very carefully drove right up to the line and stayed on the right side of it. If instead of evaluating SPF against mail from and then taking that as an input to (as part of DMARC) consider that an 'authenticated' identifier to be evaluated for identifier alignment, DMARC had just done an SPF like test using 5322.From, I think that would have been wrong. I've seen people try to match SPF results against domains extracted from Received header fields. There have been other ideas over the years. I don't remember them all. > > I believe the issue is that the token is defined in two places in > > > > > the bis draft, namely 2.4 and 4.1. We should consolidate them and > > > ensure > > > the consolidated one is complete. > > > > Here's that last paragraph of 2.4: > > > Implementations have to take care to correctly extract the > > > from the data given with the SMTP MAIL FROM command as many MTAs will > > > still accept such things as source routes (see [RFC5321], Appendix > > > C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). > > > These archaic features have been maliciously used to bypass security > > > systems. > > > > I think it's a cautionary tale, not a definition. This could be moved to > > 4.1, > > I suppose, but I don't see what it adds to do so. > > That's not the part of 2.4 I mean. 2.4 contains: > > - the domain portion of the "MAIL FROM" or "HELO" identity. > > Meanwhile 4.1 contains: > > - the domain that provides the sought-after authorization > information; initially, the domain portion of the "MAIL > FROM" or "HELO" identity. > > They're not exactly the same. It's cleaner to define in one > place, completely, and then replace the other one with a reference to that > definition. OK, sorry for being dense. Now I get it. I actually did this already and lost track. It's just in 4.1 now. > > > > > > > 'Generating non-delivery notifications to forged identities > > > > that > > > > > > have failed the authorization check is a source of backscatter and > > > > > > > > > > SHOULD be avoided.' > > > > > > > > > > > > > This RFC 2119 SHOULD is not in RFC 4408. The above does not > > > > > > > have > > > > > > > anything to do with Sender Policy Framework. It was mentioned > > > > > > > during > > > > > > > WG discussions that "SPF can help the backscatter problem" [2]. > > > > > > > This > > > > > > > text may have been introduced in response to a review [3]. Is > > > > this > > > > > > > > > an enhancement or a clarification? > > > > > > > > > > > >It's a clarification. > > > > > > > > > > In a previous comment I mentioned that "my reading of the above is > > > > > that it is neither an enhancement or a clarification. I suggest > > > > > removing the text". > > > > > > > > So you think it's not something that should be avoided? > > > > > > I think it's something to be avoided, but the choice of generating an > > > NDN > > > has nothing to do with the SPF protocol itself. It's a local policy > > > matter. I agree with strong language, but not SHOULD. > > > > OK. Would you please suggest strong, but not 2119 text? It would be a > > help. > > Sure: > > Generating non-delivery notifications to forged identities that have failed > the authorization check often constitutes backscatter, i.e., inactionable, > nuisance rejection notices. Operators are [strongly] advised to avoid such > practices. Thank you. Here's what I have now: Generating non-delivery notifications to forged identities that have failed the authorization check often constitutes backscatter, i.e., inactionable, nuisance rejection notices. Operators are strongly advised to avoid such practices. Section 2 of describes backscatter and the problems it causes. > > > > > > > In Section 4.1: > > > > > > > ' - the domain that provides the sought-after > > > > > > > > authorization > > > > > > > > > > > information; initially, the domain portion of the > > > > > > > > "MAIL > > > > > > > > > > > FROM" or "HELO" identity.' > > > > > > > > > > > > > > The above text is different from the text in Section 2.4. > > > > > > > > > > > >Yes, but not inconsistent with it. > > > > > > > > > > I suggest having the definition in one place for consistency. What > > > > > I > > > > > am looking at is consistency for the reader instead of where I > > > > > believe that there is inconsistency. > > > > > > > > They are talking about different things relative to domains, so given > > > > the > > > > > > organization, I don't see an easy way to do that. I'm open to > > > > suggestions. > > > > > > The definition in 2.4 is less complete than that in 4.1, and also there > > > > are > > > > > references to the one in 2.4. I propose copying the 4.1 version on top > > > > of > > > > > the 2.4 version, remove the 4.1 definitions and have them refer to 2.4. > > > > I'm still not seeing 2.4 as a definition. If there is a consolidation > > needed, > > I think 4.1 is the right place for it. If someone can specify exactly > > what > > text in 2.4 is definitional, I'll try and consolidate it into 2.4 (and > > check > > the references). > > I think I provided that above. Hope that clarifies things. Yes. Sorted now. > > From my point of view, we have a new proposed solution that the WG > > developed > > to a long standing issue. It seems a bit odd to then demand that it can > > only > > be part of the output of the WG if someone else implemented it. > > I'm not making that demand, but I do think it bolsters our position if it's > seen real world action. I don't have any objection to including it. We > just need to be prepared to push on it if the WG agrees that it's what we > want to say and it's met with resistance. I think it's far better than leaving eventually permanent temperrors in the sending mail queue for the queue life. If someone has a better way to deal with it, then please suggest it. I don't particularly like the solution, I just think it's better than anything else we've got. > > > > > > > In Section 6: > > > > > > > 'The modifiers defined in this document ("redirect" and > > > > > > > "exp") > > > > > > > MAY > > > > > > > > > > > > > > appear anywhere in the record, but SHOULD appear at the end, > > > > > > > > after > > > > > > > > > > > all mechanisms.' > > > > > > > > > > > > > > This text is in RFC 4408. I would label the RFC 2119 usage as > > > > > > > defective. > > > > > > > > > > > >Why? > > > > > > > > > > My previous comment was: "The text tells me that it is ok if the > > > > > modifiers appear anywhere but they should appear at the end after > > > > > all > > > > > mechanisms. It would be clearer to say that it should appear after > > > > > all mechanisms". > > > > > > > > That is defective use of 2119 language? I disagree that that would be > > > > clearer. > > > > > > "MAY" is essentially meaningless except perhaps to emphasize that the > > > implementer has a choice with no protocol consequence. You could make > > > it > > > "can" and have the same effect. > > > > There's an inverse requirement on implementers that SPF verifiers can't > > assume > > modifiers are in any particular place in the record. So the fact that > > this MAY > > happen has an effect on verifier implementation requirements (and it would > > affect > > interoperability if they don't consider it). > > Yeah. Ultimately I don't feel strongly about it. I'm fine with it as it > is, but it might be another instance of "shouting". > OK. I'll see if others share your concern. > > > > > > > "This SHOULD be a fully qualified domain name, but if one > > > > > > > does > > > > > > > not > > > > > > > > > > > > > > exist (as when the checking is done by a MUA) or if policy > > > > > > > restrictions > > > > > > > dictate otherwise, the word "unknown" SHOULD be > > > > > > > substituted." > > > > > > > > > > > > > > The RFC 2119 key words are in RFC 2119. I don't know what to > > > > say. > > > > > > > >OK. > > > > > > > > > > Murray comemnted: "I think that looks fine as-is, though we could > > > > > change the first SHOULD to "ought to" because it's a transformation > > > > > of other input and not an implementation choice. (And I assume you > > > > > mean they were in RFC4408.) > > > > > > > > Since the values end up in log files and Received-SPF/authentication > > > > results > > > > header fields that are provided to be processed on other systems, it > > > > is an > > > > > > interoperability issue. Having consistency helps interoperability. > > > > I'd > > > > > > prefer to leave it. > > > > > > My point here is that the first SHOULD is essentially saying "the > > > > hostname > > > > > of the machine SHOULD be an FQDN", but this is ineffective because the > > > person configuring this host might not know a thing about SPF or this > > > requirement and call the machine "banana". What does the SPF module do > > > with this SHOULD now? > > > > > > "ought to", "is typically", "is ideally", etc. > > > > What the first SHOULD is trying to say is about how you expand the macro > > (use > > hostname -f and not hostname). > > My point is that there are some hosts for which "hostname -f" and > "hostname" produce the same single-label output. Lots of Windows hosts are > called "localhost", for example, and have no idea what their domain name is > (and don't need to). Right. Those are the ones you call "unknown". > > > > > > > In Section 8.2: > > > > > > > 'A "neutral" result MUST be treated exactly like the "none" > > > > > > > > result; > > > > > > > > > > > the distinction exists only for informational purposes.' > > > > > > > > > > > > > > Why is an existing RFC 2119 restated? > > > > > > > > > > > >Because of the structure of the document that the WG came up with. > > > > I > > > > > > don't > > > > > > > > > >find a good way to avoid it and not make it less readable. > > > > > > > > > > I'll leave this issue open as it was mentioned in the AppsDir > > > > > review. > > > > > > I'll help with this if needed. > > > > Thanks. > > If you email me the current XML (when you're ready to take a break from it) > I'll take a run at that. Will do. > > > > > > > In Section 10.1.2: > > > > > > > "Publishing SPF records for domains that send no mail is > > > > > > > > > > > > > > a well established best practice." > > > > > > > > > > > > > > I am not aware of that best practice. I did a few DNS queries: > > > > > > > > > > > > > > ;; QUESTION SECTION: > > > > > > > ;bing.com. IN TXT > > > > > > > > > > > > > > ;; ANSWER SECTION: > > > > > > > bing.com. 3600 IN TXT "v=msv1 > > > > > > > t=6097A7EA-53F7-4028-BA76-6869CB284C54" > > > > > > > > > > > > > > ;; QUESTION SECTION: > > > > > > > ;com.com. IN TXT > > > > > > > > > > > > > > ;; ANSWER SECTION: > > > > > > > com.com. 293 IN TXT > > > > > > > > "google-site-verification:esSnoZdChIkkfCfS9MMgqNhE0yaXfnnZWdZPuBf7e8k" > > > > > > > > > >OK. See > > > > http://www.bits.org/publications/security/BITSEmailAuthenticationFeb2013.p > > > > > > d > > > > > > > > > >f > > > > > > > > > > I suggest "good practice" as mentioned by Alessandro. > > > > > > > > What's wrong with the way it is? I think the current text is > > > > accurate. > > > > > > The OpenDKIM SPF data recorded 1157 domains with "v=spf1 -all" records. > > > > The source of your domain list was from domains seen in email, right? So > > that's 1157 cases where they got it wrong. I don't think your survey > > would > > have caught correct uses of it (or do I misremember how you got your > > domain > > list)? > > I'm missing something. I thought the point was to find instances where > there's been a declaration via SPF that "this domain sends no mail". Isn't > "v=spf1 -all" the way to do that? Yes, but if you're selecting from domains that have sent mail, there's a sampling bias. > > Personally, I think this whole appendix can be tagged with "[For IESG > > > > > information only]" and removed prior to publication. It's the kind of > > > thing we usually include in shepherd writeups and not in the RFCs > > > themselves. > > > > Which one are we on? Appendix J is intended to be removed before > > publication. > > Appendix I. Protocol Status. OK. I'd figured that would stay in because I think it's useful to see how we got where we are. If others agree it's better to come out, I don't object strongly. Scott K From superuser@gmail.com Fri May 17 11:45:45 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F2221F96E5 for ; Fri, 17 May 2013 11:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OcZPAuksbiU for ; Fri, 17 May 2013 11:45:45 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7592821F9704 for ; Fri, 17 May 2013 11:45:41 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so3793805wgh.24 for ; Fri, 17 May 2013 11:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=E2BNt+SKZk99i9WKZORBfLHfjxxSkkL3Fhqt/nMzjcw=; b=Rqp83BPgA966c7jP29/NXod2+mlOImN5EmcTwrrr3Ke92ycqN3Z6LhOfrwvIgQoss1 CHWJ65uhAoi2r4aNB00Wh/kdy70ILM4o/iGk0NvWnX7IdjRS2MkB9uwEdfrDPRyDvUKp znQCrPVjYEh24jDsatAr8Orz7rY8/iVZuCljLMO48aljF6u1QzOdA6nr+pW44ydeUtyB dv/EwHtIWcZlaoEL1UKnrJconqpJRSYXUDQnoLBSJQQaiz6honQJ+7OCC1Nd0aQ7p7fX 8JAgQ77rRmJFJCajVojx60ULhzT49I0QllxBnsRMMNJcQUR9iBnsNj7bo3woyEqtGNG3 ruQQ== MIME-Version: 1.0 X-Received: by 10.194.108.231 with SMTP id hn7mr2240528wjb.59.1368816340607; Fri, 17 May 2013 11:45:40 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Fri, 17 May 2013 11:45:40 -0700 (PDT) In-Reply-To: <3959121.TAYYFWDYSi@scott-latitude-e6320> References: <20130409062431.GK24624@mx1.yitter.info> <1744498.RZtYgTOBXh@scott-latitude-e6320> <3959121.TAYYFWDYSi@scott-latitude-e6320> Date: Fri, 17 May 2013 11:45:40 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7bf10b00beaa7d04dcee63dd Cc: "spfbis@ietf.org" Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 18:45:46 -0000 --047d7bf10b00beaa7d04dcee63dd Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 17, 2013 at 11:16 AM, Scott Kitterman wrote: > Based on this, I changed it to: > > ADMDs that wish to declare that no hosts are authorized to use > their > DNS domain names in the HELO or MAIL FROM commands during SMTP > sessions can publish SPF records that say so for domain names > that > are neither used in the domain part of email addresses nor > expected > to originate mail. > Better. Could be better still if it weren't one sentence spanning five lines, but I can live with it. > > > Looking at > > > > http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-para > > > meters-6, I agree that many of these DNS errors could > > > be permanent, but the spec calls for temperror in these cases. > > > > > > The only temporary errors that turned out to really be permanent that > I've > > > seen in the wild are some SERVFAIL (2). > > > > As in a server that constantly returns SERVFAIL? I imagine that just > like > > in any context, a temporary error that's constantly returned is > eventually > > de facto treated as permanent insofar as the client gives up and goes > away. > > > > > If we were starting from scratch, I'd probably classify many of the > other > > > rcodes as permanent errors, but we aren't. Absent some evidence of > this > > > causing real world problems, I think we need to leave it the way it is. > > > > I think this is an error that warrants correction. It might be > interesting > > to know what some implementations have done here, e.g., if implementers > > decided to implement based on RFC1035 rather than RFC4408. > > All of the ones I know of make anything not 0 or 3 a temperror. I agree > it's > wrong, but is it an error that, in operation, causes any problems? If > not, I > don't think we should fix it. > I guess. I'd rather it be correct, and the operations ADs or DNSDIR review might pick on this, but maybe not. > The number was extracted from the usual location. > > OK, not that. > > Is it common to justify design decisions like this in the draft of the > text? > In my experience, it's essential, even if it's from the usual location. "We picked this number as a guess and it seemed to work well" is fine, but how do we know 15 or 25 wouldn't have been better choices? We might be challenged on that if we don't say something. > Might this be better for sm's write up than the actual draft? > No. The shepherd writeup would be where he says something like "Consensus agreed with 20, but there were several people who felt it should be {lower, higher, random, purple}." It's information for the IESG, but it's not something your average reader will go and find. > > I looked through the collected grammar in there and didn't see anything > > that covered CIDR expressions. Now that my eyes have un-crossed, did you > > have specific one(s) there in mind? > > I was looking at 3.2.2, which (you are correct) defines IPv4/IPv6, but not > CIDR > (I lost track of which one we were discussing), sorry. > > Unfortunately RFC 4632 doesn't have an ABNF. > So back to my suggestion: What about 1*2DIGIT and 1*3DIGIT? -MSK --047d7bf10b00beaa7d04dcee63dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 17, 2013 at 11:16 AM, Scott Kitterman <spf2@= kitterman.com> wrote:
Based on this, I changed it to:

=A0 =A0 =A0 =A0 =A0 ADMDs that wish to declare that no hosts are authorized= to use their
=A0 =A0 =A0 =A0 =A0 DNS domain names in the HELO or MAIL FROM commands duri= ng SMTP
=A0 =A0 =A0 =A0 =A0 sessions can publish SPF records that say so for = domain names that
=A0 =A0 =A0 =A0 =A0 are neither used in the domain part of email addresses = nor expected
=A0 =A0 =A0 =A0 =A0 to originate mail.

= Better.=A0 Could be better still if it weren't one sentence spanning fi= ve lines, but I can live with it.
=A0
> > Looking at
> > http://www.iana.org/assignments/dns= -parameters/dns-parameters.xml#dns-para
> > meters-6, I agree that many of these DNS errors could
> > be permanent, but the spec calls for temperror in these cases. > >
> > The only temporary errors that turned out to really be permanent = that I've
> > seen in the wild are some SERVFAIL (2).
>
> As in a server that constantly returns SERVFAIL? =A0I imagine that jus= t like
> in any context, a temporary error that's constantly returned is ev= entually
> de facto treated as permanent insofar as the client gives up and goes = away.
>
> > If we were starting from scratch, I'd probably classify many = of the other
> > rcodes as permanent errors, but we aren't. =A0Absent some evi= dence of this
> > causing real world problems, I think we need to leave it the way = it is.
>
> I think this is an error that warrants correction. =A0It might be inte= resting
> to know what some implementations have done here, e.g., if implementer= s
> decided to implement based on RFC1035 rather than RFC4408.

All of the ones I know of make anything not 0 or 3 a temperror.= =A0I agree it's
wrong, but is it an error that, in operation, causes any problems? =A0If no= t, I
don't think we should fix it.

I gue= ss.=A0 I'd rather it be correct, and the operations ADs or DNSDIR revie= w might pick on this, but maybe not.
=A0
The number was extracted from the usual location.

OK, not that.

Is it common to justify design decisions like this in the draft of the text= ?

In my experience, it's essential,= even if it's from the usual location.=A0 "We picked this number a= s a guess and it seemed to work well" is fine, but how do we know 15 o= r 25 wouldn't have been better choices?=A0 We might be challenged on th= at if we don't say something.
=A0
Might this be better for sm's write up than the actual draft?

No.=A0 The shepherd writeup would be where he sa= ys something like "Consensus agreed with 20, but there were several pe= ople who felt it should be {lower, higher, random, purple}." It's = information for the IESG, but it's not something your average reader wi= ll go and find.


> I looked through the collected grammar in there and didn't see any= thing
> that covered CIDR expressions. =A0Now that my eyes have un-crossed, di= d you
> have specific one(s) there in mind?

I was looking at 3.2.2, which (you are correct) defines IPv4/IP= v6, but not CIDR
(I lost track of which one we were discussing), sorry.

Unfortunately RFC 4632 doesn't have an ABNF.

<= /div>
So back to my suggestion: What about 1*2DIGIT and 1*3DIGIT?
-MSK

--047d7bf10b00beaa7d04dcee63dd-- From spf2@kitterman.com Fri May 17 11:48:08 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2CA21F9704 for ; Fri, 17 May 2013 11:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.758 X-Spam-Level: X-Spam-Status: No, score=-2.758 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IleSQW5BxdUO for ; Fri, 17 May 2013 11:48:03 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C6C1F21F9705 for ; Fri, 17 May 2013 11:47:58 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 51A4020E40FE; Fri, 17 May 2013 14:47:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368816478; bh=GS25euc61pi8DbBhA0zIv8C30YiEtUtJD6KWOL7amuQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JBnv8gmZDH3QTY4/1n3nIqlYlZ4YKtKm7RQ0V+p11iYC26zPAacXRI7VQ1KaAQZI6 HtxgPjmFfr+z04lPCP+zT5WKajVrwq3nhJP2BSaQMgDGsojQls6B5UQ8gkrlxmB3uR BkljPVHBgFU1zjFuOg/MypQbF2AJnNz03uR8Y5A4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 392D820E40F6; Fri, 17 May 2013 14:47:57 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 14:47:57 -0400 Message-ID: <2790823.coJ4TMYc0t@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <20130409062431.GK24624@mx1.yitter.info> <3959121.TAYYFWDYSi@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 18:48:08 -0000 On Friday, May 17, 2013 11:45:40 AM Murray S. Kucherawy wrote: > On Fri, May 17, 2013 at 11:16 AM, Scott Kitterman wrote: > > Based on this, I changed it to: > > ADMDs that wish to declare that no hosts are authorized to use > > > > their > > > > DNS domain names in the HELO or MAIL FROM commands during SMTP > > sessions can publish SPF records that say so for domain names > > > > that > > > > are neither used in the domain part of email addresses nor > > > > expected > > > > to originate mail. > > Better. Could be better still if it weren't one sentence spanning five > lines, but I can live with it. > > > > > Looking at > > > > http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-para > > > > > > meters-6, I agree that many of these DNS errors could > > > > be permanent, but the spec calls for temperror in these cases. > > > > > > > > The only temporary errors that turned out to really be permanent that > > > > I've > > > > > > seen in the wild are some SERVFAIL (2). > > > > > > As in a server that constantly returns SERVFAIL? I imagine that just > > > > like > > > > > in any context, a temporary error that's constantly returned is > > > > eventually > > > > > de facto treated as permanent insofar as the client gives up and goes > > > > away. > > > > > > If we were starting from scratch, I'd probably classify many of the > > > > other > > > > > > rcodes as permanent errors, but we aren't. Absent some evidence of > > > > this > > > > > > causing real world problems, I think we need to leave it the way it > > > > is. > > > > > > I think this is an error that warrants correction. It might be > > > > interesting > > > > > to know what some implementations have done here, e.g., if implementers > > > decided to implement based on RFC1035 rather than RFC4408. > > > > All of the ones I know of make anything not 0 or 3 a temperror. I agree > > it's > > wrong, but is it an error that, in operation, causes any problems? If > > not, I > > don't think we should fix it. > > I guess. I'd rather it be correct, and the operations ADs or DNSDIR review > might pick on this, but maybe not. > > > The number was extracted from the usual location. > > > > OK, not that. > > > > Is it common to justify design decisions like this in the draft of the > > text? > > In my experience, it's essential, even if it's from the usual location. > "We picked this number as a guess and it seemed to work well" is fine, but > how do we know 15 or 25 wouldn't have been better choices? We might be > challenged on that if we don't say something. OK. I'm a bit tired of staring at 4408bis XML at the moment, so when I send you the XML, please take a shot at it. > > Might this be better for sm's write up than the actual draft? > > No. The shepherd writeup would be where he says something like "Consensus > agreed with 20, but there were several people who felt it should be {lower, > higher, random, purple}." It's information for the IESG, but it's not > something your average reader will go and find. > > > > I looked through the collected grammar in there and didn't see anything > > > that covered CIDR expressions. Now that my eyes have un-crossed, did > > > you > > > have specific one(s) there in mind? > > > > I was looking at 3.2.2, which (you are correct) defines IPv4/IPv6, but not > > CIDR > > (I lost track of which one we were discussing), sorry. > > > > Unfortunately RFC 4632 doesn't have an ABNF. > > So back to my suggestion: What about 1*2DIGIT and 1*3DIGIT? OK. Please do that too. Scott K From superuser@gmail.com Fri May 17 11:52:21 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4852F21F972B for ; Fri, 17 May 2013 11:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cusx-ewfu5NK for ; Fri, 17 May 2013 11:52:16 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E1CC021F971B for ; Fri, 17 May 2013 11:52:14 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id n11so207384wgh.13 for ; Fri, 17 May 2013 11:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hR/jhar5QC/q1ZSnXESxXltKqQERHhqgGM34yW5oaW8=; b=y7IFxa+NqaflXGSGT+V8fSJiBSn5A/PQ82Fle1iexl5HmiYbOLwRPVFAxwmsQ1nSQ+ sujDZUkEsa6IXOA/ROXZTWm6/8PtiePDl2XUX5gCOAUe/P2trC0pvk6ndGNJ3DIQa1Jw vJekBn2ChlB2sMqeFkv7WQfE7u1MD3jzVvosKt7QLGUjym5PiW1HkHA2Ywa4CO/27oOH I8X9aIFNr4SiFCYRW4XkkBWgNGzZm8fyROTjF5l11ZYp8ml0Ob5bxLCuHV8bUPd4rIIN F4cd3Ev+/JehiQwoBWJYXwlTm9NgHSwLqxphea49U+Yu7StSpCqf/OMgbX6hRG1aieE/ GfNw== MIME-Version: 1.0 X-Received: by 10.195.12.135 with SMTP id eq7mr2272272wjd.17.1368816733835; Fri, 17 May 2013 11:52:13 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Fri, 17 May 2013 11:52:13 -0700 (PDT) In-Reply-To: <2042974.EAbD7S3bRR@scott-latitude-e6320> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <2434269.5GrKsYB81B@scott-latitude-e6320> <2042974.EAbD7S3bRR@scott-latitude-e6320> Date: Fri, 17 May 2013 11:52:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7bb04b242ed89e04dcee7bc7 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 18:52:21 -0000 X-List-Received-Date: Fri, 17 May 2013 18:52:21 -0000 --047d7bb04b242ed89e04dcee7bc7 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 17, 2013 at 11:41 AM, Scott Kitterman wrote: > > What's an example of unacceptable use? I'm possibly not understanding > > exactly what "SPF context" means. > > The classic one is Sender ID. As I mentioned, I think DMARC very carefully > drove right up to the line and stayed on the right side of it. If instead > of > evaluating SPF against mail from and then taking that as an input to (as > part > of DMARC) consider that an 'authenticated' identifier to be evaluated for > identifier alignment, DMARC had just done an SPF like test using > 5322.From, I > think that would have been wrong. I've seen people try to match SPF > results > against domains extracted from Received header fields. > > There have been other ideas over the years. I don't remember them all. > Right, so "Don't use SPF to evaluate things other than MAIL FROM and HELO unless both the sender and receiver have agreed out-of-band that doing so is appropriate for that mail stream." That's the intended sentiment? > Thank you. Here's what I have now: > > Generating non-delivery notifications to forged identities that > have > failed the authorization check often constitutes backscatter, > i.e., > inactionable, nuisance rejection notices. Operators are strongly > advised to avoid such practices. Section 2 of target="RFC3834"/> describes backscatter and the problems it > causes. > Nice. > > From my point of view, we have a new proposed solution that the WG > > > developed > > > to a long standing issue. It seems a bit odd to then demand that it > can > > > only > > > be part of the output of the WG if someone else implemented it. > > > > I'm not making that demand, but I do think it bolsters our position if > it's > > seen real world action. I don't have any objection to including it. We > > just need to be prepared to push on it if the WG agrees that it's what we > > want to say and it's met with resistance. > > I think it's far better than leaving eventually permanent temperrors in the > sending mail queue for the queue life. If someone has a better way to deal > with it, then please suggest it. I don't particularly like the solution, I > just think it's better than anything else we've got. > +1. It has to have consensus though, so what do others think? > > My point is that there are some hosts for which "hostname -f" and > > "hostname" produce the same single-label output. Lots of Windows hosts > are > > called "localhost", for example, and have no idea what their domain name > is > > (and don't need to). > > Right. Those are the ones you call "unknown". > I get that part, but that has nothing to do with the first SHOULD, only the second. > > I'm missing something. I thought the point was to find instances where > > there's been a declaration via SPF that "this domain sends no mail". > Isn't > > "v=spf1 -all" the way to do that? > > Yes, but if you're selecting from domains that have sent mail, there's a > sampling bias. > They're domains present in mail my reporting sites received. Some of them were obviously forgeries because they violated the published SPF rule. -MSK --047d7bb04b242ed89e04dcee7bc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 17, 2013 at 11:41 AM, Scott Kitterman <spf2@= kitterman.com> wrote:
> What's an example= of unacceptable use? =A0I'm possibly not understanding
> exactly what "SPF context" means.

The classic one is Sender ID. =A0As I mentioned, I think DMARC very c= arefully
drove right up to the line and stayed on the right side of it. =A0If instea= d of
evaluating SPF against mail from and then taking that as an input to (as pa= rt
of DMARC) consider that an 'authenticated' identifier to be evaluat= ed for
identifier alignment, DMARC had just done an SPF like test using 5322.From,= I
think that would have been wrong. =A0I've seen people try to match SPF = results
against domains extracted from Received header fields.

There have been other ideas over the years. =A0I don't remember them al= l.

Right, so "Don't use SPF to= evaluate things other than MAIL FROM and HELO unless both the sender and r= eceiver have agreed out-of-band that doing so is appropriate for that mail = stream."=A0 That's the intended sentiment?
=A0
Thank you. =A0Here's what I= have now:

=A0 =A0 =A0 =A0 =A0 Generating non-delivery notifications to forged identit= ies that have
=A0 =A0 =A0 =A0 =A0 failed the authorization check often constitutes backsc= atter, i.e.,
=A0 =A0 =A0 =A0 =A0 inactionable, nuisance rejection notices. =A0Operators = are strongly
=A0 =A0 =A0 =A0 =A0 advised to avoid such practices. Section 2 of <= ;xref
=A0 =A0 =A0 =A0 =A0 target=3D"RFC3834"/> describes backscatter= and the problems it causes.

Nice.
=
> > From my point of view, we have a new proposed solution that the W= G
> > developed
> > to a long standing issue. =A0It seems a bit odd to then demand th= at it can
> > only
> > be part of the output of the WG if someone else implemented it. >
> I'm not making that demand, but I do think it bolsters our positio= n if it's
> seen real world action. =A0I don't have any objection to including= it. =A0We
> just need to be prepared to push on it if the WG agrees that it's = what we
> want to say and it's met with resistance.

I think it's far better than leaving eventually permanent temperr= ors in the
sending mail queue for the queue life. =A0If someone has a better way to de= al
with it, then please suggest it. =A0I don't particularly like the solut= ion, I
just think it's better than anything else we've got.

+1.=A0 It has to have consensus though, so what do ot= hers think?
=A0
> My point is that there are some hosts for which "hostname -f"= ; and
> "hostname" produce the same single-label output. =A0Lots of = Windows hosts are
> called "localhost", for example, and have no idea what their= domain name is
> (and don't need to).

Right. =A0Those are the ones you call "unknown".
<= /blockquote>

I get that part, but that has nothing to do= with the first SHOULD, only the second.
=A0
> I'm missing something. =A0I thought the point was to find instance= s where
> there's been a declaration via SPF that "this domain sends no= mail". =A0Isn't
> "v=3Dspf1 -all" the way to do that?

Yes, but if you're selecting from domains that have sent ma= il, there's a
sampling bias.

They're domains pres= ent in mail my reporting sites received.=A0 Some of them were obviously for= geries because they violated the published SPF rule.
=A0
-MSK
--047d7bb04b242ed89e04dcee7bc7-- From spf2@kitterman.com Fri May 17 12:59:52 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0EF21F949F for ; Fri, 17 May 2013 12:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHytzc+9iYQK for ; Fri, 17 May 2013 12:59:43 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 40EAD21F944C for ; Fri, 17 May 2013 12:59:42 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5883820E40FE; Fri, 17 May 2013 15:59:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368820781; bh=sdDsMMnxyPhRerJDy5vQcmQ9ReIcOmWzJv85XGacHBo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pprDp0W9cmAs3yMlr1W3UydWM0CFnhNzasLUtDe6cylYAU1X1SBDCCAAegre04HKp VhQcZuOLvNOqwyBRCS6qgYtfXpqpFsMYDPT2BZiFBu4XWaTQ8sIaofS7Xo/8+pqCpF gO6cth+EPfyTDOuQG2xDmpXM5xzYuARBn8U2jTWU= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3D60420E40F6; Fri, 17 May 2013 15:59:40 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 15:59:39 -0400 Message-ID: <2556780.as7Q8xqjOf@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <2042974.EAbD7S3bRR@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 19:59:52 -0000 On Friday, May 17, 2013 11:52:13 AM Murray S. Kucherawy wrote: > On Fri, May 17, 2013 at 11:41 AM, Scott Kitterman wrote: > > > What's an example of unacceptable use? I'm possibly not understanding > > > exactly what "SPF context" means. > > > > The classic one is Sender ID. As I mentioned, I think DMARC very > > carefully > > drove right up to the line and stayed on the right side of it. If instead > > of > > evaluating SPF against mail from and then taking that as an input to (as > > part > > of DMARC) consider that an 'authenticated' identifier to be evaluated for > > identifier alignment, DMARC had just done an SPF like test using > > 5322.From, I > > think that would have been wrong. I've seen people try to match SPF > > results > > against domains extracted from Received header fields. > > > > There have been other ideas over the years. I don't remember them all. > > Right, so "Don't use SPF to evaluate things other than MAIL FROM and HELO > unless both the sender and receiver have agreed out-of-band that doing so > is appropriate for that mail stream." That's the intended sentiment? Except for the out of band part. It could be a new in-band modifier that gets defined in the future. > > Thank you. Here's what I have now: > > Generating non-delivery notifications to forged identities that > > > > have > > > > failed the authorization check often constitutes backscatter, > > > > i.e., > > > > inactionable, nuisance rejection notices. Operators are > > strongly > > advised to avoid such practices. Section 2 of > target="RFC3834"/> describes backscatter and the problems it > > > > causes. > > Nice. > > > > From my point of view, we have a new proposed solution that the WG > > > > > > > developed > > > > to a long standing issue. It seems a bit odd to then demand that it > > > > can > > > > > > only > > > > be part of the output of the WG if someone else implemented it. > > > > > > I'm not making that demand, but I do think it bolsters our position if > > > > it's > > > > > seen real world action. I don't have any objection to including it. We > > > just need to be prepared to push on it if the WG agrees that it's what > > > we > > > want to say and it's met with resistance. > > > > I think it's far better than leaving eventually permanent temperrors in > > the > > sending mail queue for the queue life. If someone has a better way to > > deal > > with it, then please suggest it. I don't particularly like the solution, > > I > > just think it's better than anything else we've got. > > +1. It has to have consensus though, so what do others think? It seemed like people were OK with it when I put it in. > > > My point is that there are some hosts for which "hostname -f" and > > > "hostname" produce the same single-label output. Lots of Windows hosts > > are > > > called "localhost", for example, and have no idea what their domain name > > is > > > (and don't need to). > > > > Right. Those are the ones you call "unknown". > > I get that part, but that has nothing to do with the first SHOULD, only the > second. OK. I see your point now. SHOULD could be replaced with 'is normally'. If you agree, please go ahead and change it. > > > I'm missing something. I thought the point was to find instances where > > > there's been a declaration via SPF that "this domain sends no mail". > > Isn't > > > > > "v=spf1 -all" the way to do that? > > > > Yes, but if you're selecting from domains that have sent mail, there's a > > sampling bias. > > They're domains present in mail my reporting sites received. Some of them > were obviously forgeries because they violated the published SPF rule. OK. Thanks, Scott K From sm@elandsys.com Fri May 17 13:07:33 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B33B21F94D0 for ; Fri, 17 May 2013 13:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kc-Q9kqizEgG for ; Fri, 17 May 2013 13:07:31 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6B821F9488 for ; Fri, 17 May 2013 13:07:30 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.153.229]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4HK787N003646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 May 2013 13:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1368821245; bh=63Q4UUwrFuzOm5obL54ZNJLFTJ8y4hTHUl5HYiooheY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TdQF6YqwxwPZDcSBH6VKdhtT+82p5F66cyNAlpy32JJeb8Dq+X5vOlxrmY5pka0hm ZzYtt6EKTUMr4H27EZY0okd/vii/de7kOE8C+/m4yWwyeLSVBs8rJp+0pmqtgDOXMN s0cg4LpmfPZRU90L8HkSfqeuZWmTn868AAVd45h8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1368821245; i=@elandsys.com; bh=63Q4UUwrFuzOm5obL54ZNJLFTJ8y4hTHUl5HYiooheY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=X0LTBBqibUQaO4f3liQMGOXPmmoVQCGpN+EDI73oufpoAi04T9+hs5t6/g02c5kjt fYP+AnyoCFzfkdwaX/MOFNTFBQzh3MnlMlM+dvlg6suHHHyZKUrvJtSlAVdJNQMeQ0 qqyEmQuF5gIlpTP8IM33pANBpsAFSBO1ss67pLyk= Message-Id: <6.2.5.6.2.20130517084156.0c3e9128@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 17 May 2013 11:52:07 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <1972467.x8au6JTDZS@scott-latitude-e6320> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <2724237.eQuNQK5KLA@scott-latitude-e6320> <6.2.5.6.2.20130516154521.06ceef08@resistor.net> <1972467.x8au6JTDZS@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 20:07:33 -0000 HI Scott, At 23:37 16-05-2013, Scott Kitterman wrote: >OK. I still find it confusing that things that are needed for the >protocol to >function are not considered requirements, but changed. Thanks. >That's not always easy to do. In this case, it would be hard to evaluate out >of context, so I think it's best to wait for the next revision. I understand that it is not always easy to do. When revising a draft it is better that the editors keep a list showing how each comment was addressed and what the revised text is so that an Area Director raising an issue can see how the issue was addressed. That list can be forwarded to the reviewer (e.g. directorate, Area Director, anyone doing a detailed review). When it is done on the working group mailing list there is a record of the issues being addressed as they do not have to be revisited. There was a comment about issues in a draft (see http://www.ietf.org/mail-archive/web/ietf/current/msg79096.html ). The external view is: "I have not followed this discussion, but my cursory read of the tracker ticket shows the WG blew off the issue by claiming that historical unsophisticated attacks can be easily thwarted, while completely ignoring the case where the target domains exist." Irrespective of whether that is correct or not it may end up as more work for you and for the working group. > > "out-of-band" or "private" was suggested. I'll use one of them (I do > > not have any preference): > > > Without out-of-band approval of the ADMD, checking other identities > > against SPF version 1 records is NOT RECOMMENDED because there are > > cases that are known to give incorrect results. > >I don't think that's correct. One could get a new modifier added to the SPF >modifier registry that would indicate a record can be used for other >purposes. >There are no such other purposes defined at the moment, but there's >absolutely >no need for out-of-band/private methods to accomplish this goal. The issue was how can explicit approval be sought. Murray suggested 'Adding "out-of-band" or "private" after "explicit" would probably clear this one up'. I didn't see any comments from John or Stuart. Alessandro commented as follows: 'How about defining the concept of (private or standard) "extension"?'. Extensions are out-of-scope for SPFBIS. I'll suggest the following for the second paragraph of Section 2.4: Checking other identities against SPF version 1 records is NOT RECOMMENDED because there are cases that are known to give incorrect results. For example, almost all mailing lists rewrite the "MAIL FROM" identity (see Section 10.3), but some do not change any other identities in the message. A document that defines other identity will have to specify how the identity is used. I tried to capture what is mentioned in your explanation. It's basically "no need for out-of-band/private methods". > > > > In Section 2.4: > > > > 'When a mail receiver decides to perform an SPF check, it MUST use a > > > > > > > > correctly-implemented check_host() function (Section 4) evaluated > > > > with the correct parameters.' > > > > > > > > This RFC 2119 requirement states the obvious. It basically says that > > > > there is a requirement in draft-ietf-spfbis-4408bis-14 to use a > > > > correct implementation of draft-ietf-spfbis-4408bis-14. > > > > > >This was changed already due to other comments. I think it makes sense > > >now. Please check when -15 is published. > > > > The comment I read on the mailing list is: > > > > "I agree, that sentence can probably go." > > > > The other comment was from Alessandro. Does your comment mean that > > the sentence will be removed or does it mean that text is being proposed? > >It means it was changed based on other comments. Please look at -15 and see >if you still think it's a problem. I went through the mailing list archive and I only found two comments about this issue. I'll suggest the following text for the fourth paragraph of Section 2.4: A SPF verifier performs an SPF check using the check_host() function (Section 4). The SPF check it has to be performed as specified so that the correct semantics are preserved between publisher and receiver. I would rewrite the next sentence as: To make the SPF check, the SPF verifier MUST evaluate the check_host() function with the arguments set as follows: That sentence could be moved to the previous paragraph. You then get the arguments (for the function) together with the check_host() function. > > I mentioned in a previous comment that " definitions (not > > sure whether it is a definition) are mentioned in two places. I > > suggest fixing that and then getting back to the above". > >I don't understand what you think is wrong. Repeating the comment >won't help. >I did read it. I don't understand it. The following is from Section 2.4: ' - the domain portion of the "MAIL FROM" or "HELO" identity.' and this is from Section 4.1: ' - the domain that provides the sought-after authorization information; initially, the domain portion of the "MAIL FROM" or "HELO" identity.' I suggest choosing one of the above text for "" and using it in both sections. >So you think it's not something that should be avoided? It's not that I don't think that the problem should not be avoided. I read the SPFBIS charter and I didn't find any text about addressing every mail-related problem. That is why I suggested removing the last paragraph of Section 2.5: "Generating non-delivery notifications to forged identities that have failed the authorization check is a source of backscatter and SHOULD be avoided. Section 2 of [RFC3834] describes backscatter and the problems it causes." >I split the difference and put in: > >The SPF record is expressed as a single string of text encoded in a DNS TXT >record. Ok (subject to Andrew's comments). >I'm failing to understand how to clarify that use the minimum means use as >little as you can. It's basically just explaining the dictionary to the >reader, so I think I don't understand what you think needs changing. Fro context this is about the first paragraph of Section 3: 'ADMDs publishing SPF records SHOULD try to keep the number of "include" mechanisms and chained "redirect" modifiers to a minimum. ADMDs SHOULD also try to minimize the amount of other DNS information needed to evaluate a record. Section 4.6.4 and Section 10.1.1 provide some suggestions on how to achieve this.' I'll give the rewrite a try: ADMDs publishing SPF records ought to keep the amount of DNS information needed to evaluate a record to a minimum. Section 4.6.4 provides some suggestions about "include" mechanisms and chained "redirect" modifiers. >If it makes sense to use the redirect then that's the minimum. If we truly >wanted the absolute minimum physically possible, we'd only have ip4, ip4, and >maybe include mechanisms. I don't think there's a conflict. I tried to address this above (see suggested text). > > > > In Section 3.1: > > > > 'SPF records MUST be published as a DNS TXT (type 16) > Resource Record > > > > > > > > (RR) [RFC1035] only.' > > > > > > > > I would ask why "MUST be published ... only". By the way, Section 3 > > > > has a reference to Section 4 for record format instead of Section > > > > 3.1. Is that correct? > > > > > >The only is to make it clear that the Type SPF records that were > > >defined in RFC > > >4408 are no longer part of the protocol. It is correct. The ABNF for the > > >record format is in section 4. > > > > There were two comments: > > > > "The reference is indeed incorrect." > > > > and: > > > > 'Should we say "is described along with its interpretation in Section > > 4.5"? How about changing the title of Section 4.5 to "Record Format"?' > >Changing the title to Record Format would be wrong because it's not just the >format. I changed it to "The record format and the process for selecting >records is described in ..." The issue was that the reference was incorrect. Here is the text from Section 3: 'The SPF record is a single string of text. The record format is described below in Section 4.' The title of Section 4 is "The check_host() Function". >OK. I changed it to "is equivalent to:" Thanks. >OK. I changed it to produce results. Ok (subject to reading the sentence) >They are talking about different things relative to domains, so given the >organization, I don't see an easy way to do that. I'm open to suggestions. I commented on the in Section 4.1. I'll repeat what I mentioned for Section 2.4: The following is from Section 2.4: ' - the domain portion of the "MAIL FROM" or "HELO" identity.' and this is from Section 4.1: ' - the domain that provides the sought-after authorization information; initially, the domain portion of the "MAIL FROM" or "HELO" identity.' I suggest choosing one of the above text for "" and using it in both sections. >OK. I took email out. Ok (subject to reading the sentence). >Sorry, still confused. "I read the first paragraph of Section 4.4 >as meaning >that the DNS query is for Type TXT only." That's correct, so I think you do >understand the sentence. I'll defer to Andrew on this. > > > > 'Alternatively, for a server failure (RCODE 2) result, check_host() > > > > > > > > MAY track failures and treat multiple failures within 24 hours for > > > > the same domain as "permerror".' > > > > > > > > This text is not in RFC 4408. I found a note in Issue #1 [5] and in > > > > a message [6]. > > > > > >Yes. This is a change to address an operational issue found during SPF > > >deployment. > > > > Stuart mentioned that: "This also solves the TIMEOUT for type 99 > > problem. Reporting a PermError for a broken name server would be very > > appropriate (and switching to checking TXT first while said failure > > is cached would also be permissible)". > > > > John commented that: "Not that I'm aware of. That looks to me like > > an optimization to do in the DNS cache, not in the client". > > > > In a previous comment I mentioned that: "Are there any > > implementations that do this? If so, that's the justification; it's > > practical experience. If not, we should consider dropping it". > >There was an issue. We discussed possible solutions (my initial hope was to >make all SERVFAIL responses permerror) and this was the best solution we came >up with. Because we want consistent results across implementations it's not >just a local cache optimization. I think we should leave it since I don't >want to redo the entire process of solving the issue again. I asked whether there were any implementations that do the following: 'Alternatively, for a server failure (RCODE 2) result, check_host() MAY track failures and treat multiple failures within 24 hours for the same domain as "permerror".' Stuart Gathman is listed as the author of pySPF. He mentioned that: '"This also solves the TIMEOUT for type 99 problem. Reporting a PermError for a broken name server would be very appropriate (and switching to checking TXT first while said failure is cached would also be permissible)"'. As an individual I prefer not to do the entire process again. Given that this is tied to another controversial discussion I have to list the issue as unresolved. >OK, but you didn't answer the question. Would the text I proposed clarify >things for you? I like it better than the comment you brought up because I >think it's clearer, so I'd prefer to use it if you think it's OK. I am ok if you prefer to use the text you proposed. > > > > In Section 4.6.4: > > > > "SPF implementations MUST limit the total number of mechanisms and > > > > > > > > modifiers ("terms") that cause any DNS query to at most 10 during > > > > SPF > > > > evaluation." > > > > > > > > This was discussed on the mailing list [7]. > > > > > > > > "If this number is exceeded during a check, a permerror MUST be > > > > > > > > returned." > > > > > > > > I read this as if an implementation-specific limit is reached a > > > > permerror is returned. There are two RFC 2119 MUST in the > > > > above. That can be reduced to one MUST. > > > > > >Is there a problem with it the way it is? > > > > Here is my previous comment: > > > > For context we are at Section 4.6.4. I'll quote some text from it: > > > > "If this number is exceeded during a check, a permerror MUST be > returned." > > > > 'If this limit is exceeded, the "mx" mechanism MUST produce a > > "permerror" result.' > > > > 'If this limit is exceeded, all records other than the first 10 > > MUST be ignored.' > > > > I prefer not to discuss about the last one (see quoted text) again. > > In terms of coding it is easier if I am told to return a "permerror" > > results when DNS limit X is exceeded. That can be specified with one > > RFC 2119 MUST. I am taking in consideration the SecDir > > recommendation and interoperability. Speaking of interoperability > > the following text: > > > > 'SPF implementations MUST limit the total number of mechanisms and > > modifiers ("terms") that cause any DNS query to at most 10 during SPF > > evaluation.' > > > > does not encourage it because of the "at most". Section 4.6.4 does > > not make things easier for DNS operations as the reader cannot > > identify the limits easily due to the exceptions. I am ok with the > > exceptions. What I am suggesting is not to use two RFC 2119 MUST if > > it there is a way for it to be done with one RFC 2119 MUST. > >They are different limits that you have to code differently, so I think >combining them would reduce clarity for implementers. I suggest that the working group reviews that text. In my opinion the "at most" can interpreted as setting a number less than 10 and that can cause an interoperability issue. > > > > I read the first paragraph of Section 4.6.4. I am not sure how the > > > > absolute requirement will be interpreted by the reader. > > > > > >We worked on making it clearer. If you have suggested > improvements, please > > >send them. > > > > Could you please provide the proposed text? > >No, I don't have any more proposed text. I was saying the WG has already >worked over trying to clarify this section. I think we've done our best, to >clearly express something that is complicated. I don't think "do it better" >is going to result in further improvements, so if you have an idea how to >improve it, please provide it. I'll list Section 4.6.4 as an unresolved issue. >I don't find that any clearer, probably less so than what's in the draft now. Ok. >They are about defining some consistent limits/expectations in order to avoid >both impedance between senders and receivers and the potential security >implications of not implementing proper limits. I'll discuss Section 4.6.4 in a separate message >There were several suggestions, some of them inconsistent with >actual practice >experienced by some WG members with real operating systems. I chose to go >with the text that supported getting interoperable results regardless of OS. Ok. > > > > In Section 5.4: > > > > 'Note regarding implicit MXs: If the has no > MX records, > > > > > > > > check_host() MUST NOT pretend the target is its single MX, and MUST > > > > NOT default to an A or AAAA lookup on the directly.' > > > > > > > > There are two RFC 2119 MUSTs in the above. This is over-usage of RFC > > > > 2119 key words. This text was in RFC 4408. This is not a divergence > > > > from RFC 5321, it is a contrary to Section 5 of RFC 5321. > > > > > >It's not contrary. It's saying that aspect of 5321 is not > relevant to SPF. > > >In any case, changing it would be a substantiative change to the > > >protocol that > > >would require all implementations to be updated. > > > > There are changes listed in Appendix C. Implementations will have to > > be updated anyway in my opinion. I'll discuss this matter with the > > Responsible Area Director. > >What is there to discuss? It's NOT a change from 4408? Changing it from >what's there now would be out of scope for our charter. Here is the text from the last paragraph of Section 5.4 of RFC 4408: 'Note regarding implicit MXs: If the has no MX records, check_host() MUST NOT pretend the target is its single MX, and MUST NOT default to an A lookup on the directly. This behavior breaks with the legacy "implicit MX" rule. See [RFC2821], Section 5. If such behavior is desired, the publisher should specify an "a" directive.' And the text from the draft: 'Note regarding implicit MXs: If the has no MX records, check_host() MUST NOT pretend the target is its single MX, and MUST NOT default to an A or AAAA lookup on the directly. This behavior diverges from the legacy "implicit MX" rule, (See [RFC5321], Section 5. If such behavior is desired, the publisher will have to specify an "a" directive).' I compared two sentences: 1. This behavior breaks with the legacy "implicit MX" rule. 2. This behavior diverges from the legacy "implicit MX" rule I consider this as a change. I would like to discuss the matter with the Responsible Area Director. > > > > In Section 5.5: > > > > "This mechanism SHOULD NOT be used." > > > > > > > > I suggest providing a reason for this. > > > > > >The reason is given in the note at the end of the section. > > > > The following text was suggested: > > > > "This mechanism SHOULD NOT be used it is not as reliable as other > > mechanisms in cases of DNS errors, and it places a large burden on the > > .arpa name servers." > >In -14, it already says: > > > Note: This mechanism is slow, it is not as reliable as other > > mechanisms in cases of DNS errors, and it places a large burden on > > the .arpa name servers. > >What should I change? I mentioned the suggested text previously. In the first paragraph of Section 5.5: Existing text: This mechanism SHOULD NOT be used. See below for discussion. Suggested text: This mechanism SHOULD NOT be used it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the .arpa name servers. > > > > "To prevent DoS attacks, more than 10 PTR names > > > > > > > > MUST NOT be looked up during the evaluation of a "ptr" mechanism > > > > (see Section 4.6.4)." > > > > > > > > The above restates a previous RFC 2119 MUST. > > > > > > > > "If used, proper PTR records MUST be in place for the domain's hosts > > > > > > > > and the "ptr" mechanism SHOULD be one of the last mechanisms > > > > checked." > > > > > > > > Those RFC 2119 key words are not in RFC 4408. I don't see how this > > > > RFC 2119 change qualifies as a clarification or explanation. > > > > > >For the MUST, it flat out won't work if you don't have those (no > > >interoperation). For the SHOULD, it's an optimization. We can change it > > >if you want. > > > > My previous comment was that: "It's a change. I suggest reverting it. > > Telling people who are using the "ptr" mechanism that they must have > > PTR records is stating the obvious". > >Obvious to you. Not obvious to everyone. I suggest reverting the change. > > > > "It is, however, still in use and part of the SPF protocol, so > > > > compliant > > > > check_host() implementations MUST support it." > > > > > > > > What is a compliant check_host() implementation? > > > > > >One that works in accordance with 4408bis. Please suggest an alternative > > >if you don't like that. > > > > I am ok with what the working group wants. > > > > > > In Section 5.6: > > > > "ip6-network = " > > > > > > > > I suggest that the above reference be verified for correctness. > > > > > > > > In Section 5.7: > > > > 'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all' > > > > > > > > I'll flag this for review by DNS folks. > > > > > > > > In Section 6: > > > > 'The modifiers defined in this document ("redirect" and "exp") MAY > > > > > > > > appear anywhere in the record, but SHOULD appear at the end, after > > > > all mechanisms.' > > > > > > > > This text is in RFC 4408. I would label the RFC 2119 usage as > > > > defective. > > > > > >Why? > > > > My previous comment was: "The text tells me that it is ok if the > > modifiers appear anywhere but they should appear at the end after all > > mechanisms. It would be clearer to say that it should appear after > > all mechanisms". > >That is defective use of 2119 language? I disagree that that would be >clearer. I'll list this as an unresolved issue. > > > > In Section 6.2: > > > > "Since the explanation string is intended for an SMTP response and > > > > [RFC5321] Section 2.4 says that responses are in [US-ASCII], the > > > > explanation string MUST be limited to US-ASCII.' > > > > > > > > It would be easier to defer to RFC 5321 instead of setting a RFC 2119 > > > > requirement in this draft. I note that this requirement was not in RFC > > > > 4408. > > > > > >It's not a new requirement. If you couldn't find it in 4408, then that > > >means we've succeeded in making the actual requirement more clear. > > > > None of the WG participants have pointed out where the actual > > requirement (RFC "MUST") is in RFC 4408. If the text was in RFC 4408 > > it would be possible for a WG participant to point me to it. There > > was a comment about 'this could be expressed non-normatively (e.g. > > "needs to be")'. > >If it's not ASCII, it won't interoperate (at all). Isn't that exactly where >2119 language is supposed to be used? Regardless of how it's worded in 4408, >putting non-ASCII characters in explanation strings does not and has never >worked. At most it's making something explicit that was implicit before, >which is a good clarification I'd think. The Responsible Area Director has commented about RFC 2119 language. I suggest referring to his message for any question about RFC 2119 language. I also suggest removing the RFC 2119 language. > > > > "Software SHOULD make it clear that the explanation string > > > > comes from a third party." > > > > > > > > I could not understand what that means in RFC 2119 terms. The draft > > > > uses RFC 2119 key words by example instead of providing an explanation. > > > > > >I don't understand the comment. > > > > There was a comment from Murray: "we're talking about > > interoperability between humans here, and not between implementations". > >We're talking about avoiding security issues caused by the humans getting >confused. I'll list this as an unresolved issue. >Since the values end up in log files and Received-SPF/authentication results >header fields that are provided to be processed on other systems, it is an >interoperability issue. Having consistency helps interoperability. I'd >prefer to leave it. I'll list this as an unresolved issue (the text is: This SHOULD be a fully qualified domain name, but if one does not exist (as when the checking is done by a MUA) or if policy restrictions dictate otherwise, the word "unknown" SHOULD be substituted.) ). >Why? How about if we call it "Details" instead of Notes? There was a suggestion (from you if I recall correctly in another message). I suggest using that if the working group agrees. > > I read RFC 4408 and I did not find any table similar to the one in > > Section 10.1.1 of draft-ietf-spfbis-4408bis-14. My understanding of > > "support for changing text" is that the text is proposed on the > > working group mailing list and it is added if there is agreement. I > > didn't find any messages about that in the mailing list > > archives. What I found was a message disagreeing with a change which > > was made in the draft which was posted together with an explanation > > about why there was disagreement. In my opinion there wasn't any > > support for making that change in the draft. > >The text came from Alessandro and was discussed on the >list. Arthur's comment >came later. The table is new, but is only a new expression of information >that was in 4408. It does not create any new requirements. I don't see agreement for that table. >What's wrong with the way it is? I think the current text is accurate. I don't see anything in the charter about working on a best practice document. I suggest choosing "good practice" if the working group really wants that text. >I went with disposable, since discardable is a specific term of art in other >email authentication related documents and I don't want to create potential >for confusion. ok. > > > > In Section 11.5: > > > > "An SPF compliant receiver gathers information from the > SMTP commands > > > > > > > > it receives and from the published DNS records of the > sending domain > > > > holder" > > > > > > > > I suggest explaining the untrusted part. > > > > > >That's what the section does. > > > > There was a comment: "A second sentence indicating most of that > > input is unverified is probably in order, with references if possible". > >I think the section explains exactly that, so some text would help. I'll list issue as unresolved. >I think to single out one person in this way would be unfair to other people >that made significant contributions. The original 4408 acknowledgements >weren't done this way and so I think it's literally impossible to properly >develop an acknowledgements section that would be fairly done. This >is not to >knock down Murray's contribution, which I agree has been significant. > >There was a thread about this on the IETF main list in late March. Working >groups vary significantly. What's in the draft for acknowledgements has been >there, virtually unchanged since last summer. If you really want a >reasonable >list of contributors, we'll need to discuss a new schedule because this won't >finish in May. I'll wait for input from Andrew and the Responsible Area Director. > > Ok. As a note for the working group, I could not find the draft. > >First Google hit for draft-fecyk-dsprotocol is: > >http://tools.ietf.org/html/draft-fecyk-dsprotocol-04 Thanks. > > > > Where can I find "Domain-Authorized SMTP Mail"? > > > > > >I don't have a copy of this. > > > > I suggest dropping the reference. > >SPF did not spring from nothing. It gathered a number of concepts, added a >few things, and managed to be successful. I think it would be more >appropriate to leave it as it shows part of the trace back to the origin of >the protocol. I suggest adding text about that if it is important. I suggest removing the reference as nobody has been able to provide the document being referenced. > > > > In Appendix C: > > > > > > > > In Section E.1: > > > > 'This would cause a lookup on an DNS white list (DNSWL) and cause a > > > > > > > > result of "fail" only for email not either coming from the > > > > domain's mx host(s) (SPF pass) or white listed sources (SPF > > > > neutral).' > > > > > > > > I didn't find any discussion about this on the SPFBIS mailing > > > > list. is there an explanation for this change between RFC > 4408 and this > > > > draft? > > > > > >It was pointed out that this is a white list, not a black list. > > > > I suggest dropping this change as it was not discussed within the > > working group. > >Yes. It was. As I didn't find that discussion I can only conclude that it has not been discussed within the working group. I suggest dropping the change. > > > > In Appendix I: > > > > > > > > Appendix I is about "Protocol Status". This draft is intended as a > > > > Proposed Standard. From an IETF perspective that is what it will > > > > be. Describing it as something different can be misleading. > > > > > > > > "[RFC4408] was designed to clearly document the protocol defined by > > > > > > > > earlier draft specifications of SPF as used in existing > > > > implementations. This updated specification is intended to clarify > > > > identified ambiguities in [RFC4408], resolve techincal issues > > > > identified in post-RFC 4408 deplyment experience, and document > > > > widely > > > > deployed extensions to SPF that have been developed since [RFC4408] > > > > was published." > > > > > > > > Extensions to the SPF protocol are clearly mentioned in the charter > > > > as being out of scope. The "document widely deployed extensions" is > > > > problematic. > > > > > >The charter specifically allows for "addition of any enhancements > > >that have already gained widespread support". > > > > I read the discussion about the charter again. It is my > > understanding that extensions to the SPF protocol is > > out-of-scope. The working group did not add a work item during the > > chartering discussion as it was considered as an extension to the protocol. > >It was also not widely deployed. Should I take authentication-results out of >the draft then? I did not mention "authentication-results" in my comment. My comment was about Appendix I. In my opinion "extension" is out-of-scope. > > > > "This document updates and replaces RFC 4408 that was part > of a group > > > > > > > > of simultaneously published Experimental RFCs (RFC 4405, RFC 4406, > > > > RFC 4407, and RFC 4408) in 2006. At that time the IESG requested > > > > the > > > > community observe the success or failure of the two approaches > > > > documented in these RFCs during the two years following > publication, > > > > in order that a community consensus could be reached in > the future." > > > > > > > > Why is this needed? The SPFBIS WG produced RFC 6686 to resolve the > > > > experiment. > > > > > >Since this is what obsoletes 4408, not everyone will read 6686. > > > > There is an informative reference to RFC 6686. I don't see why the > > text mentioned above is needed. > >I think the section is incomplete without it. The reference mentions "Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments". I suggest removing the text. Regards, S. Moonesamy (as document shepherd) From johnl@iecc.com Fri May 17 13:48:26 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F26D21F885A for ; Fri, 17 May 2013 13:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.541 X-Spam-Level: X-Spam-Status: No, score=-110.541 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omc68wQDUORC for ; Fri, 17 May 2013 13:48:21 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B74A121F8E6E for ; Fri, 17 May 2013 13:48:20 -0700 (PDT) Received: (qmail 38577 invoked from network); 17 May 2013 20:48:19 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 May 2013 20:48:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51969793.xn--hew.k1305; i=johnl@user.iecc.com; bh=HYtDJ4IdaUM5rX+Mje7kZG3fzuAVESltUWS/xqkIMJU=; b=mx3KaKqpdq0yInWMrd5+huNJ77CLXkOTzMu7oM3mAsS+T28fBjOQa066V2u/mJArFd3aT8s1VSSpG96CWLSzBfjpvJQXr5p86lRd8pY0V0gTurVjAbOKyO7MGiHAmTgqRaicF2q3B2CN06C4ljAphEpI3Ek1x05vqjOm76iPPKk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51969793.xn--hew.k1305; olt=johnl@user.iecc.com; bh=HYtDJ4IdaUM5rX+Mje7kZG3fzuAVESltUWS/xqkIMJU=; b=RBH2ABCLwER7KEFcI8GzJF0EQfYetJsgebwmAAkQBfH4hRnvIdgZJi82ZJWZaheBuRzEgTaQWA/hduDBKYAxLLGIZfQcgn6NVse6P6KnKwsu/WXmwrM0AY4nD8ohQdS0DuuqRUj16f/NRol5eqXsyGuV4g3r6prgPoBQXNcAD5w= Date: 17 May 2013 20:47:57 -0000 Message-ID: <20130517204757.64157.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <2556780.as7Q8xqjOf@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: spf2@kitterman.com Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 20:48:26 -0000 >> Right, so "Don't use SPF to evaluate things other than MAIL FROM and HELO >> unless both the sender and receiver have agreed out-of-band that doing so >> is appropriate for that mail stream." That's the intended sentiment? > >Except for the out of band part. It could be a new in-band modifier that gets >defined in the future. Anything defined in the future would update the spec, so we don't have to worry about it. If (as I understand it) the only current way to agree to use SPF on other stuff is out of band, just say so. >> > I think it's far better than leaving eventually permanent temperrors in the >> > sending mail queue for the queue life. If someone has a better way to deal >> > with it, then please suggest it. I don't particularly like the solution, >>> > I just think it's better than anything else we've got. >> >> +1. It has to have consensus though, so what do others think? > >It seemed like people were OK with it when I put it in. Oops, I missed this. My position is that the queue lifetime is the length it is for a reason, and it's a mistake to shortcircuit that. Stuff will stay in the outbound queue for the full lifetime if there are DNS temperror problems with the MX lookup, or the A records the MX points to. Why should SPF temperrors be different? R's, John From spf2@kitterman.com Fri May 17 13:51:36 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30BD21F898B for ; Fri, 17 May 2013 13:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kz1AVXdV-TP for ; Fri, 17 May 2013 13:51:28 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id AAB8621F96A2 for ; Fri, 17 May 2013 13:51:27 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DE4CB20E40FE; Fri, 17 May 2013 16:51:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368823886; bh=ElGNEhK2SHIkAepA8NNbn6Sh1pbpwNLNnkowVLsMfA0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=I1i41/dfwBC8uU3CxaTRdSfCzoNF+rO4kH0fafVEFuXQ9vKRTb4o6geFg7uo09sGv qxN6eeeN0QNjB83p1gpTdAMx+UddvUnZbxaLXsvioDgYcOzAF8T+O/9rTDl/8accBx Unp6A7vT6Yx8B5v41Sbvh0eBz3WHglcsnjdWB6g8= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id BF3D820E40F6; Fri, 17 May 2013 16:51:26 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 16:51:25 -0400 Message-ID: <1808846.3L9zQIcVOx@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130517084156.0c3e9128@resistor.net> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <1972467.x8au6JTDZS@scott-latitude-e6320> <6.2.5.6.2.20130517084156.0c3e9128@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 20:51:36 -0000 On Friday, May 17, 2013 11:52:07 AM S Moonesamy wrote: > HI Scott, > > At 23:37 16-05-2013, Scott Kitterman wrote: > >OK. I still find it confusing that things that are needed for the > >protocol to > >function are not considered requirements, but changed. > > Thanks. > > >That's not always easy to do. In this case, it would be hard to evaluate > >out of context, so I think it's best to wait for the next revision. > > I understand that it is not always easy to do. When revising a draft > it is better that the editors keep a list showing how each comment > was addressed and what the revised text is so that an Area Director > raising an issue can see how the issue was addressed. That list can > be forwarded to the reviewer (e.g. directorate, Area Director, anyone > doing a detailed review). When it is done on the working group > mailing list there is a record of the issues being addressed as they > do not have to be revisited. > > There was a comment about issues in a draft (see > http://www.ietf.org/mail-archive/web/ietf/current/msg79096.html > ). The external view is: > > "I have not followed this discussion, but my cursory read of the tracker > ticket shows the WG blew off the issue by claiming that historical > unsophisticated attacks can be easily thwarted, while completely > ignoring the case where the target domains exist." > > Irrespective of whether that is correct or not it may end up as more > work for you and for the working group. > > > > "out-of-band" or "private" was suggested. I'll use one of them (I do > > > > > > not have any preference): > > > Without out-of-band approval of the ADMD, checking other identities > > > against SPF version 1 records is NOT RECOMMENDED because there are > > > cases that are known to give incorrect results. > > > >I don't think that's correct. One could get a new modifier added to the > >SPF modifier registry that would indicate a record can be used for other > >purposes. > >There are no such other purposes defined at the moment, but there's > >absolutely > >no need for out-of-band/private methods to accomplish this goal. > > The issue was how can explicit approval be sought. Murray suggested > 'Adding "out-of-band" or "private" after "explicit" would probably > clear this one up'. I didn't see any comments from John or > Stuart. Alessandro commented as follows: 'How about defining the > concept of (private or standard) "extension"?'. Extensions are > out-of-scope for SPFBIS. > > I'll suggest the following for the second paragraph of Section 2.4: > > Checking other identities against SPF version 1 records is NOT > RECOMMENDED because there are cases that are known to give > incorrect results. For example, almost all mailing lists > rewrite the "MAIL FROM" identity (see Section 10.3), but some > do not change any other identities in the message. A document > that defines other identity will have to specify how the identity > is used. > > I tried to capture what is mentioned in your explanation. It's > basically "no need for out-of-band/private methods". Based on the follow-up with msk, the draft now reads: Without explicit approval of the publishing ADMD, checking other identities against SPF version 1 records is NOT RECOMMENDED because there are cases that are known to give incorrect results. For example, almost all mailing lists rewrite the "MAIL FROM" identity (see Section 10.3), but some do not change any other identities in the message. Documents that define other identities will have to define the method for explicit approval. This is very close to what you suggest. Do you think this is OK? > > > > > In Section 2.4: > > > > > 'When a mail receiver decides to perform an SPF check, it MUST > > > > > use a > > > > > > > > > > correctly-implemented check_host() function (Section 4) > > > > > evaluated > > > > > with the correct parameters.' > > > > > > > > > > This RFC 2119 requirement states the obvious. It basically says > > > > > that > > > > > there is a requirement in draft-ietf-spfbis-4408bis-14 to use a > > > > > correct implementation of draft-ietf-spfbis-4408bis-14. > > > > > > > >This was changed already due to other comments. I think it makes sense > > > >now. Please check when -15 is published. > > > > > > The comment I read on the mailing list is: > > > "I agree, that sentence can probably go." > > > > > > The other comment was from Alessandro. Does your comment mean that > > > the sentence will be removed or does it mean that text is being > > > proposed? > > > >It means it was changed based on other comments. Please look at -15 and > >see if you still think it's a problem. > > I went through the mailing list archive and I only found two comments > about this issue. I'll suggest the following text for the fourth > paragraph of Section 2.4: > > A SPF verifier performs an SPF check using the check_host() function > (Section 4). The SPF check it has to be performed as specified so > that the correct semantics are preserved between publisher and receiver. > > I would rewrite the next sentence as: > > To make the SPF check, the SPF verifier MUST evaluate the check_host() > function with the arguments set as follows: > > That sentence could be moved to the previous paragraph. You then get > the arguments (for the function) together with the check_host() function. That currently point to 4.1 to remove the duplication that was complained about in other comments. I don't think we should put it back. To make the test, the mail receiver MUST evaluate the check_host() function with the arguments described in Section 4.1. > > > I mentioned in a previous comment that " definitions (not > > > sure whether it is a definition) are mentioned in two places. I > > > suggest fixing that and then getting back to the above". > > > >I don't understand what you think is wrong. Repeating the comment > >won't help. > >I did read it. I don't understand it. > > The following is from Section 2.4: > > ' - the domain portion of the "MAIL FROM" or "HELO" identity.' > > and this is from Section 4.1: > > ' - the domain that provides the sought-after authorization > information; initially, the domain portion of the "MAIL > FROM" or "HELO" identity.' > > I suggest choosing one of the above text for "" and using it > in both sections. I got this clarified in the dialog with msk and it's all in 4.1 now. > >So you think it's not something that should be avoided? > > It's not that I don't think that the problem should not be > avoided. I read the SPFBIS charter and I didn't find any text about > addressing every mail-related problem. That is why I suggested > removing the last paragraph of Section 2.5: > > "Generating non-delivery notifications to forged identities that have > failed the authorization check is a source of backscatter and SHOULD > be avoided. Section 2 of [RFC3834] describes backscatter and the > problems it causes." This is very close to what msk and I worked out. Please see the text I posted in the subthread with him and see if it works for you. > >I split the difference and put in: > > > >The SPF record is expressed as a single string of text encoded in a DNS > >TXT record. > > Ok (subject to Andrew's comments). > > >I'm failing to understand how to clarify that use the minimum means use as > >little as you can. It's basically just explaining the dictionary to the > >reader, so I think I don't understand what you think needs changing. > > Fro context this is about the first paragraph of Section 3: > > 'ADMDs publishing SPF records SHOULD try to keep the number of > "include" mechanisms and chained "redirect" modifiers to a minimum. > ADMDs SHOULD also try to minimize the amount of other DNS information > needed to evaluate a record. Section 4.6.4 and Section 10.1.1 > provide some suggestions on how to achieve this.' > > > I'll give the rewrite a try: > > ADMDs publishing SPF records ought to keep the amount of DNS > information needed to evaluate a record to a minimum. > Section 4.6.4 provides some suggestions about "include" > mechanisms and chained "redirect" modifiers. OK. How about this: ADMDs publishing SPF records ought to keep the amount of DNS information needed to evaluate a record to a minimum. and provide some suggestions about "include" mechanisms and chained "redirect" modifiers. > >If it makes sense to use the redirect then that's the minimum. If we truly > >wanted the absolute minimum physically possible, we'd only have ip4, ip4, > >and maybe include mechanisms. I don't think there's a conflict. > > I tried to address this above (see suggested text). > > > > > > In Section 3.1: > > > > > 'SPF records MUST be published as a DNS TXT (type 16) > > > > Resource Record > > > > > > > (RR) [RFC1035] only.' > > > > > > > > > > I would ask why "MUST be published ... only". By the way, Section 3 > > > > > has a reference to Section 4 for record format instead of Section > > > > > 3.1. Is that correct? > > > > > > > >The only is to make it clear that the Type SPF records that were > > > >defined in RFC > > > >4408 are no longer part of the protocol. It is correct. The ABNF for > > > >the > > > >record format is in section 4. > > > > > > There were two comments: > > > "The reference is indeed incorrect." > > > > > > and: > > > 'Should we say "is described along with its interpretation in Section > > > > > > 4.5"? How about changing the title of Section 4.5 to "Record > > > Format"?' > > > >Changing the title to Record Format would be wrong because it's not just > >the format. I changed it to "The record format and the process for > >selecting records is described in ..." > > The issue was that the reference was incorrect. Here is the text > from Section 3: > > 'The SPF record is a single string of text. The record format is > described below in Section 4.' > > The title of Section 4 is "The check_host() Function". It's not incorrect. That is, in fact, where it's described. > >OK. I changed it to "is equivalent to:" > > Thanks. > > >OK. I changed it to produce results. > > Ok (subject to reading the sentence) > > >They are talking about different things relative to domains, so given the > >organization, I don't see an easy way to do that. I'm open to suggestions. > > I commented on the in Section 4.1. I'll repeat what I > mentioned for Section 2.4: > > The following is from Section 2.4: > > ' - the domain portion of the "MAIL FROM" or "HELO" identity.' > > and this is from Section 4.1: > > ' - the domain that provides the sought-after authorization > information; initially, the domain portion of the "MAIL > FROM" or "HELO" identity.' > > I suggest choosing one of the above text for "" and using it > in both sections. This is fixed. > >OK. I took email out. > > Ok (subject to reading the sentence). > > >Sorry, still confused. "I read the first paragraph of Section 4.4 > >as meaning > >that the DNS query is for Type TXT only." That's correct, so I think you > >do understand the sentence. > > I'll defer to Andrew on this. > > > > > > 'Alternatively, for a server failure (RCODE 2) result, > > > > > check_host() > > > > > > > > > > MAY track failures and treat multiple failures within 24 hours > > > > > for > > > > > the same domain as "permerror".' > > > > > > > > > > This text is not in RFC 4408. I found a note in Issue #1 [5] and in > > > > > a message [6]. > > > > > > > >Yes. This is a change to address an operational issue found during SPF > > > >deployment. > > > > > > Stuart mentioned that: "This also solves the TIMEOUT for type 99 > > > problem. Reporting a PermError for a broken name server would be very > > > appropriate (and switching to checking TXT first while said failure > > > is cached would also be permissible)". > > > > > > John commented that: "Not that I'm aware of. That looks to me like > > > an optimization to do in the DNS cache, not in the client". > > > > > > In a previous comment I mentioned that: "Are there any > > > implementations that do this? If so, that's the justification; it's > > > practical experience. If not, we should consider dropping it". > > > >There was an issue. We discussed possible solutions (my initial hope was > >to make all SERVFAIL responses permerror) and this was the best solution > >we came up with. Because we want consistent results across > >implementations it's not just a local cache optimization. I think we > >should leave it since I don't want to redo the entire process of solving > >the issue again. > > I asked whether there were any implementations that do the following: > > 'Alternatively, for a server failure (RCODE 2) result, check_host() > MAY track failures and treat multiple failures within 24 hours for > the same domain as "permerror".' > > Stuart Gathman is listed as the author of pySPF. He mentioned that: > '"This also solves the TIMEOUT for type 99 problem. Reporting a > PermError for a broken name server would be very appropriate (and > switching to checking TXT first while said failure is cached would > also be permissible)"'. > > As an individual I prefer not to do the entire process again. Given > that this is tied to another controversial discussion I have to list > the issue as unresolved. How so? It's only unresolved because you decided to second guess what we already agreed on. I don't think WGLC is a free shot at revisiting all the work we've done. There's a real problem. This is the best solution anyone came up with and so absent some alternative approach, there's nothing to resolve. > >OK, but you didn't answer the question. Would the text I proposed clarify > >things for you? I like it better than the comment you brought up because I > >think it's clearer, so I'd prefer to use it if you think it's OK. > > I am ok if you prefer to use the text you proposed. OK. Done. > > > > > In Section 4.6.4: > > > > > "SPF implementations MUST limit the total number of mechanisms > > > > > and > > > > > > > > > > modifiers ("terms") that cause any DNS query to at most 10 > > > > > during > > > > > SPF > > > > > evaluation." > > > > > > > > > > This was discussed on the mailing list [7]. > > > > > > > > > > "If this number is exceeded during a check, a permerror MUST be > > > > > > > > > > returned." > > > > > > > > > > I read this as if an implementation-specific limit is reached a > > > > > permerror is returned. There are two RFC 2119 MUST in the > > > > > above. That can be reduced to one MUST. > > > > > > > >Is there a problem with it the way it is? > > > > > > Here is my previous comment: > > > > > > For context we are at Section 4.6.4. I'll quote some text from it: > > > "If this number is exceeded during a check, a permerror MUST be > > > > returned." > > > > > 'If this limit is exceeded, the "mx" mechanism MUST produce a > > > > > > "permerror" result.' > > > > > > 'If this limit is exceeded, all records other than the first 10 > > > > > > MUST be ignored.' > > > > > > I prefer not to discuss about the last one (see quoted text) again. > > > In terms of coding it is easier if I am told to return a "permerror" > > > results when DNS limit X is exceeded. That can be specified with one > > > RFC 2119 MUST. I am taking in consideration the SecDir > > > recommendation and interoperability. Speaking of interoperability > > > > > > the following text: > > > 'SPF implementations MUST limit the total number of mechanisms and > > > > > > modifiers ("terms") that cause any DNS query to at most 10 during > > > SPF > > > evaluation.' > > > > > > does not encourage it because of the "at most". Section 4.6.4 does > > > not make things easier for DNS operations as the reader cannot > > > identify the limits easily due to the exceptions. I am ok with the > > > exceptions. What I am suggesting is not to use two RFC 2119 MUST if > > > it there is a way for it to be done with one RFC 2119 MUST. > > > >They are different limits that you have to code differently, so I think > >combining them would reduce clarity for implementers. > > I suggest that the working group reviews that text. In my opinion > the "at most" can interpreted as setting a number less than 10 and > that can cause an interoperability issue. I agree that at most should be removed. Done. > > > > > I read the first paragraph of Section 4.6.4. I am not sure how the > > > > > absolute requirement will be interpreted by the reader. > > > > > > > >We worked on making it clearer. If you have suggested > > > > improvements, please > > > > > >send them. > > > > > > Could you please provide the proposed text? > > > >No, I don't have any more proposed text. I was saying the WG has already > >worked over trying to clarify this section. I think we've done our best, > >to clearly express something that is complicated. I don't think "do it > >better" is going to result in further improvements, so if you have an idea > >how to improve it, please provide it. > > I'll list Section 4.6.4 as an unresolved issue. Please specify what's unresolved. > >I don't find that any clearer, probably less so than what's in the draft > >now. > Ok. > > >They are about defining some consistent limits/expectations in order to > >avoid both impedance between senders and receivers and the potential > >security implications of not implementing proper limits. > > I'll discuss Section 4.6.4 in a separate message OK. > >There were several suggestions, some of them inconsistent with > >actual practice > >experienced by some WG members with real operating systems. I chose to go > >with the text that supported getting interoperable results regardless of > >OS. > Ok. > > > > > > In Section 5.4: > > > > > 'Note regarding implicit MXs: If the has no > > > > MX records, > > > > > > > check_host() MUST NOT pretend the target is its single MX, and > > > > > MUST > > > > > NOT default to an A or AAAA lookup on the > > > > > directly.' > > > > > > > > > > There are two RFC 2119 MUSTs in the above. This is over-usage of > > > > > RFC > > > > > 2119 key words. This text was in RFC 4408. This is not a > > > > > divergence > > > > > from RFC 5321, it is a contrary to Section 5 of RFC 5321. > > > > > > > >It's not contrary. It's saying that aspect of 5321 is not > > > > relevant to SPF. > > > > > >In any case, changing it would be a substantiative change to the > > > >protocol that > > > >would require all implementations to be updated. > > > > > > There are changes listed in Appendix C. Implementations will have to > > > be updated anyway in my opinion. I'll discuss this matter with the > > > Responsible Area Director. > > > >What is there to discuss? It's NOT a change from 4408? Changing it from > >what's there now would be out of scope for our charter. > > Here is the text from the last paragraph of Section 5.4 of RFC 4408: > > 'Note regarding implicit MXs: If the has no MX records, > check_host() MUST NOT pretend the target is its single MX, and MUST > NOT default to an A lookup on the directly. This > behavior breaks with the legacy "implicit MX" rule. See [RFC2821], > Section 5. If such behavior is desired, the publisher should specify > an "a" directive.' > > And the text from the draft: > > 'Note regarding implicit MXs: If the has no MX records, > check_host() MUST NOT pretend the target is its single MX, and MUST > NOT default to an A or AAAA lookup on the directly. > This behavior diverges from the legacy "implicit MX" rule, (See > [RFC5321], Section 5. If such behavior is desired, the publisher > will have to specify an "a" directive).' > > I compared two sentences: > > 1. This behavior breaks with the legacy "implicit MX" rule. > > 2. This behavior diverges from the legacy "implicit MX" rule > > I consider this as a change. I would like to discuss the matter with > the Responsible Area Director. It's a change from what? SPF has worked this way since 2003. It doesn't "break" anything. It was a deliberate design decision. > > > > > In Section 5.5: > > > > > "This mechanism SHOULD NOT be used." > > > > > > > > > > I suggest providing a reason for this. > > > > > > > >The reason is given in the note at the end of the section. > > > > > > The following text was suggested: > > > "This mechanism SHOULD NOT be used it is not as reliable as other > > > > > > mechanisms in cases of DNS errors, and it places a large burden on the > > > .arpa name servers." > > > >In -14, it already says: > > > Note: This mechanism is slow, it is not as reliable as other > > > mechanisms in cases of DNS errors, and it places a large burden on > > > the .arpa name servers. > > > >What should I change? > > I mentioned the suggested text previously. In the first paragraph of > Section 5.5: > > Existing text: > > > This mechanism SHOULD NOT be used. See below for discussion. > > Suggested text: > > This mechanism SHOULD NOT be used it is not as reliable as other > mechanisms in cases of DNS errors, and it places a large burden on the > .arpa name servers. It already says that. > > > > > "To prevent DoS attacks, more than 10 PTR names > > > > > > > > > > MUST NOT be looked up during the evaluation of a "ptr" mechanism > > > > > (see Section 4.6.4)." > > > > > > > > > > The above restates a previous RFC 2119 MUST. > > > > > > > > > > "If used, proper PTR records MUST be in place for the domain's > > > > > hosts > > > > > > > > > > and the "ptr" mechanism SHOULD be one of the last mechanisms > > > > > checked." > > > > > > > > > > Those RFC 2119 key words are not in RFC 4408. I don't see how this > > > > > RFC 2119 change qualifies as a clarification or explanation. > > > > > > > >For the MUST, it flat out won't work if you don't have those (no > > > >interoperation). For the SHOULD, it's an optimization. We can change > > > >it > > > >if you want. > > > > > > My previous comment was that: "It's a change. I suggest reverting it. > > > Telling people who are using the "ptr" mechanism that they must have > > > PTR records is stating the obvious". > > > >Obvious to you. Not obvious to everyone. > > I suggest reverting the change. Why? It's not a rare error for people not to understand this. Most people for small domains that try to deal with SPF are not DNS experts. > > > > > "It is, however, still in use and part of the SPF protocol, so > > > > > compliant > > > > > check_host() implementations MUST support it." > > > > > > > > > > What is a compliant check_host() implementation? > > > > > > > >One that works in accordance with 4408bis. Please suggest an > > > >alternative > > > >if you don't like that. > > > > > > I am ok with what the working group wants. > > > > > > > > In Section 5.6: > > > > > "ip6-network = " > > > > > > > > > > I suggest that the above reference be verified for correctness. > > > > > > > > > > In Section 5.7: > > > > > 'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all' > > > > > > > > > > I'll flag this for review by DNS folks. > > > > > > > > > > In Section 6: > > > > > 'The modifiers defined in this document ("redirect" and "exp") > > > > > MAY > > > > > > > > > > appear anywhere in the record, but SHOULD appear at the end, > > > > > after > > > > > all mechanisms.' > > > > > > > > > > This text is in RFC 4408. I would label the RFC 2119 usage as > > > > > defective. > > > > > > > >Why? > > > > > > My previous comment was: "The text tells me that it is ok if the > > > modifiers appear anywhere but they should appear at the end after all > > > mechanisms. It would be clearer to say that it should appear after > > > all mechanisms". > > > >That is defective use of 2119 language? I disagree that that would be > >clearer. > > I'll list this as an unresolved issue. What's unresolved? You've yet to explain what's defective. I don't think it's particularly effective to list issues you've not explained as unresolved. By definition that's true, but it's also rather unresolvable. > > > > > In Section 6.2: > > > > > "Since the explanation string is intended for an SMTP response > > > > > and > > > > > > > > > > [RFC5321] Section 2.4 says that responses are in [US-ASCII], the > > > > > explanation string MUST be limited to US-ASCII.' > > > > > > > > > > It would be easier to defer to RFC 5321 instead of setting a RFC > > > > > 2119 > > > > > requirement in this draft. I note that this requirement was not in > > > > > RFC > > > > > 4408. > > > > > > > >It's not a new requirement. If you couldn't find it in 4408, then that > > > >means we've succeeded in making the actual requirement more clear. > > > > > > None of the WG participants have pointed out where the actual > > > requirement (RFC "MUST") is in RFC 4408. If the text was in RFC 4408 > > > it would be possible for a WG participant to point me to it. There > > > was a comment about 'this could be expressed non-normatively (e.g. > > > "needs to be")'. > > > >If it's not ASCII, it won't interoperate (at all). Isn't that exactly > >where 2119 language is supposed to be used? Regardless of how it's worded > >in 4408, putting non-ASCII characters in explanation strings does not and > >has never worked. At most it's making something explicit that was > >implicit before, which is a good clarification I'd think. > > The Responsible Area Director has commented about RFC 2119 > language. I suggest referring to his message for any question about > RFC 2119 language. I also suggest removing the RFC 2119 language. I read it. I think it needs to stay. > > > > > "Software SHOULD make it clear that the explanation string > > > > > > > > > > comes from a third party." > > > > > > > > > > I could not understand what that means in RFC 2119 terms. The draft > > > > > uses RFC 2119 key words by example instead of providing an > > > > > explanation. > > > > > > > >I don't understand the comment. > > > > > > There was a comment from Murray: "we're talking about > > > interoperability between humans here, and not between implementations". > > > >We're talking about avoiding security issues caused by the humans getting > >confused. > > I'll list this as an unresolved issue. > > >Since the values end up in log files and Received-SPF/authentication > >results header fields that are provided to be processed on other systems, > >it is an interoperability issue. Having consistency helps > >interoperability. I'd prefer to leave it. > > I'll list this as an unresolved issue (the text is: This SHOULD be a > fully qualified domain name, but if one does not exist (as when the > checking is done by a MUA) or if policy restrictions dictate > otherwise, the word "unknown" SHOULD be substituted.) > ). msk is taking a stab at text for this, I think. > >Why? How about if we call it "Details" instead of Notes? > > There was a suggestion (from you if I recall correctly in another > message). I suggest using that if the working group agrees. > > > > I read RFC 4408 and I did not find any table similar to the one in > > > Section 10.1.1 of draft-ietf-spfbis-4408bis-14. My understanding of > > > "support for changing text" is that the text is proposed on the > > > working group mailing list and it is added if there is agreement. I > > > didn't find any messages about that in the mailing list > > > archives. What I found was a message disagreeing with a change which > > > was made in the draft which was posted together with an explanation > > > about why there was disagreement. In my opinion there wasn't any > > > support for making that change in the draft. > > > >The text came from Alessandro and was discussed on the > >list. Arthur's comment > >came later. The table is new, but is only a new expression of information > >that was in 4408. It does not create any new requirements. > > I don't see agreement for that table. I can take it out. So far one person objected. If the standard is nothing that anyone objects to goes in, we'll be here for a long time. > >What's wrong with the way it is? I think the current text is accurate. > > I don't see anything in the charter about working on a best practice > document. I suggest choosing "good practice" if the working group > really wants that text. I am at a loss for words. Best practice is correct. > >I went with disposable, since discardable is a specific term of art in > >other email authentication related documents and I don't want to create > >potential for confusion. > > ok. > > > > > > In Section 11.5: > > > > > "An SPF compliant receiver gathers information from the > > > > SMTP commands > > > > > > > it receives and from the published DNS records of the > > > > sending domain > > > > > > > holder" > > > > > > > > > > I suggest explaining the untrusted part. > > > > > > > >That's what the section does. > > > > > > There was a comment: "A second sentence indicating most of that > > > input is unverified is probably in order, with references if possible". > > > >I think the section explains exactly that, so some text would help. > > I'll list issue as unresolved. I made a change today based on a suggestion from msk. I think it's resolved. > >I think to single out one person in this way would be unfair to other > >people that made significant contributions. The original 4408 > >acknowledgements weren't done this way and so I think it's literally > >impossible to properly develop an acknowledgements section that would be > >fairly done. This is not to > >knock down Murray's contribution, which I agree has been significant. > > > >There was a thread about this on the IETF main list in late March. Working > >groups vary significantly. What's in the draft for acknowledgements has > >been there, virtually unchanged since last summer. If you really want a > >reasonable > >list of contributors, we'll need to discuss a new schedule because this > >won't finish in May. > > I'll wait for input from Andrew and the Responsible Area Director. > > > > Ok. As a note for the working group, I could not find the draft. > > > >First Google hit for draft-fecyk-dsprotocol is: > > > >http://tools.ietf.org/html/draft-fecyk-dsprotocol-04 > > Thanks. > > > > > > Where can I find "Domain-Authorized SMTP Mail"? > > > > > > > >I don't have a copy of this. > > > > > > I suggest dropping the reference. > > > >SPF did not spring from nothing. It gathered a number of concepts, added a > >few things, and managed to be successful. I think it would be more > >appropriate to leave it as it shows part of the trace back to the origin of > >the protocol. > > I suggest adding text about that if it is important. I suggest > removing the reference as nobody has been able to provide the > document being referenced. > > > > > > In Appendix C: > > > > > > > > > > In Section E.1: > > > > > 'This would cause a lookup on an DNS white list (DNSWL) and cause > > > > > a > > > > > > > > > > result of "fail" only for email not either coming from the > > > > > domain's mx host(s) (SPF pass) or white listed sources (SPF > > > > > neutral).' > > > > > > > > > > I didn't find any discussion about this on the SPFBIS mailing > > > > > list. is there an explanation for this change between RFC > > > > 4408 and this > > > > > > > draft? > > > > > > > >It was pointed out that this is a white list, not a black list. > > > > > > I suggest dropping this change as it was not discussed within the > > > working group. > > > >Yes. It was. > > As I didn't find that discussion I can only conclude that it has not > been discussed within the working group. I suggest dropping the change. As msk pointed out, it was mostly affected by the reorganization. > > > > > In Appendix I: > > > > > > > > > > Appendix I is about "Protocol Status". This draft is intended as a > > > > > Proposed Standard. From an IETF perspective that is what it will > > > > > be. Describing it as something different can be misleading. > > > > > > > > > > "[RFC4408] was designed to clearly document the protocol defined > > > > > by > > > > > > > > > > earlier draft specifications of SPF as used in existing > > > > > implementations. This updated specification is intended to > > > > > clarify > > > > > identified ambiguities in [RFC4408], resolve techincal issues > > > > > identified in post-RFC 4408 deplyment experience, and document > > > > > widely > > > > > deployed extensions to SPF that have been developed since > > > > > [RFC4408] > > > > > was published." > > > > > > > > > > Extensions to the SPF protocol are clearly mentioned in the charter > > > > > as being out of scope. The "document widely deployed extensions" is > > > > > problematic. > > > > > > > >The charter specifically allows for "addition of any enhancements > > > >that have already gained widespread support". > > > > > > I read the discussion about the charter again. It is my > > > understanding that extensions to the SPF protocol is > > > out-of-scope. The working group did not add a work item during the > > > chartering discussion as it was considered as an extension to the > > > protocol. > > > >It was also not widely deployed. Should I take authentication-results out > >of the draft then? > > I did not mention "authentication-results" in my comment. My comment > was about Appendix I. In my opinion "extension" is out-of-scope. If extensions are out of scope, then we need to remove the discussion about a- r. I understand you didn't mention it, but if I follow your suggestion, that's a logical conclusion. > > > > > "This document updates and replaces RFC 4408 that was part > > > > of a group > > > > > > > of simultaneously published Experimental RFCs (RFC 4405, RFC > > > > > 4406, > > > > > RFC 4407, and RFC 4408) in 2006. At that time the IESG > > > > > requested > > > > > the > > > > > community observe the success or failure of the two approaches > > > > > documented in these RFCs during the two years following > > > > publication, > > > > > > > in order that a community consensus could be reached in > > > > the future." > > > > > > > Why is this needed? The SPFBIS WG produced RFC 6686 to resolve the > > > > > experiment. > > > > > > > >Since this is what obsoletes 4408, not everyone will read 6686. > > > > > > There is an informative reference to RFC 6686. I don't see why the > > > text mentioned above is needed. > > > >I think the section is incomplete without it. > > The reference mentions "Resolution of the Sender Policy Framework > (SPF) and Sender ID Experiments". I suggest removing the text. I think it should stay as is, but I guess I'm the only one. Scott K P.S. I sent the XML file to msk for some edits. Once I get it back, I'll merge the changes I mentioned here with that. From spf2@kitterman.com Fri May 17 13:55:08 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C5821F968B for ; Fri, 17 May 2013 13:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.734 X-Spam-Level: X-Spam-Status: No, score=-2.734 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Su7o7lCkCvZ for ; Fri, 17 May 2013 13:54:49 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D4D4021F9512 for ; Fri, 17 May 2013 13:54:49 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6440A20E40FE; Fri, 17 May 2013 16:54:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368824089; bh=gywc9im7HrpkVDMKB6qJEbdirrjwHdDopxGxuPzWBUo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=X3eMkpgs0XmhK1FSqsDNHsQGbXuoFv/mU9IJ4avIUOiOxqZhLAB3rqcK11BAdoSk6 9COork25fQHw1YX1wVSYlrRBW/oSQT7uKNbYSMR16Flz9S3raZxQKPFJOUO7oU71t8 2ZUOqVFxWxI/YSSPQEeq9gLgiqJgUzVzo62ghriY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 46EF620E40F6; Fri, 17 May 2013 16:54:48 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 16:54:48 -0400 Message-ID: <2243311.UY3Zvck4Gp@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130517204757.64157.qmail@joyce.lan> References: <20130517204757.64157.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 20:55:08 -0000 On Friday, May 17, 2013 08:47:57 PM John Levine wrote: > >> Right, so "Don't use SPF to evaluate things other than MAIL FROM and HELO > >> unless both the sender and receiver have agreed out-of-band that doing so > >> is appropriate for that mail stream." That's the intended sentiment? > > > >Except for the out of band part. It could be a new in-band modifier that > >gets defined in the future. > > Anything defined in the future would update the spec, so we don't have > to worry about it. If (as I understand it) the only current way to agree > to use SPF on other stuff is out of band, just say so. The spec already accommodates handling unknown modifiers, so it doesn't need to updated. There's a registry. > >> > I think it's far better than leaving eventually permanent temperrors in > >> > the > >> > sending mail queue for the queue life. If someone has a better way to > >> > deal > >> > with it, then please suggest it. I don't particularly like the > >> > solution, > >> > > >>> > I just think it's better than anything else we've got. > >> > >> +1. It has to have consensus though, so what do others think? > > > >It seemed like people were OK with it when I put it in. > > Oops, I missed this. My position is that the queue lifetime is the > length it is for a reason, and it's a mistake to shortcircuit that. > > Stuff will stay in the outbound queue for the full lifetime if there > are DNS temperror problems with the MX lookup, or the A records the MX > points to. Why should SPF temperrors be different? Because they aren't temporary. From johnl@iecc.com Fri May 17 15:58:32 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F1221F8618 for ; Fri, 17 May 2013 15:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.706 X-Spam-Level: X-Spam-Status: No, score=-110.706 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fphhZZww8cZL for ; Fri, 17 May 2013 15:58:28 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDEF21F8521 for ; Fri, 17 May 2013 15:58:28 -0700 (PDT) Received: (qmail 64604 invoked from network); 17 May 2013 22:58:27 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 May 2013 22:58:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5196b613.xn--btvx9d.k1305; i=johnl@user.iecc.com; bh=2ONbyYDD8LrNJ4URYJmPFJGKgssfOiaogm0fdSE9pA0=; b=h2ke2IGhWdgBLPYmrEywe7g1vVSgsRjyW7d7A9syBF27OtmdHbLRIHEsUb+DdHXrALWyBJsrUpUpWb4fiwrkHwOQYh6P/O252j/qR/Q1ETJblYLaDAsMEtnmWzd5vNCepz75Fg+Vfv1MNUlEJLj9CfUi7myrYtD7IVZZ0GppRG8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5196b613.xn--btvx9d.k1305; olt=johnl@user.iecc.com; bh=2ONbyYDD8LrNJ4URYJmPFJGKgssfOiaogm0fdSE9pA0=; b=CWIIyhj5YBxSg1Qa7dbLddlsRIfEDmEm8MUQYUpdBYA74dDeosO7CZRNtELuqUhNFGkhMnkIrj23bWApNzlY1UHB2jxz3HcZ3LV+IGlrfxqQHD7Yb2O5HtAfUnI6jZQGBuyvWIrmuRc2l/bJMShsgtXAXnXq81keA5INX9Gd0Sc= Date: 17 May 2013 22:58:05 -0000 Message-ID: <20130517225805.64539.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <2243311.UY3Zvck4Gp@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: spf2@kitterman.com Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 22:58:32 -0000 >> >Except for the out of band part. It could be a new in-band modifier that >> >gets defined in the future. >> >> Anything defined in the future would update the spec, so we don't have >> to worry about it. If (as I understand it) the only current way to agree >> to use SPF on other stuff is out of band, just say so. > >The spec already accommodates handling unknown modifiers, so it doesn't need to >updated. There's a registry. But the registry is specification required. If there's a new spec, it will specify what to do with the new modifier. I don't think this is worth a huge argument, but I don't see the point in documenting things that don't exist when we know that they will be documented somewhere else if and when they do. >> Stuff will stay in the outbound queue for the full lifetime if there >> are DNS temperror problems with the MX lookup, or the A records the MX >> points to. Why should SPF temperrors be different? > >Because they aren't temporary. Huh? I went through -14 and all the temperrors are either DNS failures or timeouts. How is that different from failures or timeouts looking up an MX? I realize it happens on the server rather than the client, but so what? R's, John From spf2@kitterman.com Fri May 17 16:05:55 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA44721F968E for ; Fri, 17 May 2013 16:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.728 X-Spam-Level: X-Spam-Status: No, score=-2.728 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrZzBvczOinP for ; Fri, 17 May 2013 16:05:50 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 774E621F968D for ; Fri, 17 May 2013 16:05:50 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E619820E40FE; Fri, 17 May 2013 19:05:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368831949; bh=PDpJSLYq3ewKOXPJPJkwWbyoBbtd5tTGtqo9QfzoZow=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ECUM83t0TC0ba7rx4qtJjhVayMqHs9alJdo/Iw9iqR3H2OPKM6DUe2Hsea4mJvzQ2 954IPHK5llCeL0SRnHdr6xqbFDaQF4ZZ7h8N41FY1PcYWNJ7XrM8luau69hYVXIX9P r8zolsnQDfe0R+i+KT0hH12La9AJfGT1KWcQR+io= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id CC5E620E40F6; Fri, 17 May 2013 19:05:49 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 19:05:49 -0400 Message-ID: <2107801.vGVXe1y3CL@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130517225805.64539.qmail@joyce.lan> References: <20130517225805.64539.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 23:05:55 -0000 On Friday, May 17, 2013 10:58:05 PM John Levine wrote: > >> >Except for the out of band part. It could be a new in-band modifier > >> >that > >> >gets defined in the future. > >> > >> Anything defined in the future would update the spec, so we don't have > >> to worry about it. If (as I understand it) the only current way to agree > >> to use SPF on other stuff is out of band, just say so. > > > >The spec already accommodates handling unknown modifiers, so it doesn't > >need to updated. There's a registry. > > But the registry is specification required. If there's a new spec, it > will specify what to do with the new modifier. I don't think this is > worth a huge argument, but I don't see the point in documenting things > that don't exist when we know that they will be documented somewhere > else if and when they do. True, but I think the statement that such understanding requires an out of band/private agreement is not correct. > >> Stuff will stay in the outbound queue for the full lifetime if there > >> are DNS temperror problems with the MX lookup, or the A records the MX > >> points to. Why should SPF temperrors be different? > > > >Because they aren't temporary. > > Huh? I went through -14 and all the temperrors are either DNS > failures or timeouts. How is that different from failures or timeouts > looking up an MX? I realize it happens on the server rather than the > client, but so what? SERVFAIL is supposed to be something temporary, but in my experience it often is not. That was the root of the original discussion. I wanted to call SERVFAIL a permanent error, but got shown that was not correct. SERVFAIL is often a "permanent" "temporary" error. Scott K From sm@elandsys.com Fri May 17 16:24:47 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCCE21F960E for ; Fri, 17 May 2013 16:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z443TWi27fWv for ; Fri, 17 May 2013 16:24:46 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC1321F960C for ; Fri, 17 May 2013 16:24:45 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.153.229]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4HNOTea018585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 May 2013 16:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1368833083; bh=ispLd+udLoRaecM1nQ9g0y9VKEIx7r9ZoPWOLHx10yI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2IOvoOdeQvu9MlsBPxIt8Vzgkykku2jsRCp4gAbdofVKX5r51S6piyM6c2ihO4BxF nUag6Iypdp9dHESKP66zckvE7y6FrbRnBaMBumD3z7mJoJg3QhldXV4T0At15wJvwr DUf7V+vH/wRW710woAfDvTaCtP47ylQwxpewjtkc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1368833083; i=@elandsys.com; bh=ispLd+udLoRaecM1nQ9g0y9VKEIx7r9ZoPWOLHx10yI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vtg2C204M0QF0j796VvAs31cjO15R2sV5xPUgmX3rHjn98bWsieQDbTH9CdDwJtbF OK+n9/IXdpqjyyDosuXZf8zGqH6jgSgqckpnxKPBYx6mHkB6IzeDMci337mpH55r+j vzNxL1uk53JVCk+S027JpkUQTznGQJqMphYAagUw= Message-Id: <6.2.5.6.2.20130517144328.0d5dade8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 17 May 2013 16:24:15 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <1808846.3L9zQIcVOx@scott-latitude-e6320> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <1972467.x8au6JTDZS@scott-latitude-e6320> <6.2.5.6.2.20130517084156.0c3e9128@resistor.net> <1808846.3L9zQIcVOx@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 23:24:47 -0000 Hi Scott, At 13:51 17-05-2013, Scott Kitterman wrote: >Based on the follow-up with msk, the draft now reads: > > Without explicit approval of the publishing ADMD, checking other > identities against SPF version 1 records is NOT RECOMMENDED because > there are cases that are known to give incorrect results. For > example, almost all mailing lists rewrite the "MAIL FROM" identity > (see Section 10.3), but some do not change any other identities in > the message. Documents that define other identities will have to > define the method for explicit approval. > >This is very close to what you suggest. Do you think this is OK? The issue was the "explicit approval". I'll leave it to the working group to see whether it is ok with the text. > > I went through the mailing list archive and I only found two comments > > about this issue. I'll suggest the following text for the fourth > > paragraph of Section 2.4: > > > > A SPF verifier performs an SPF check using the check_host() function > > (Section 4). The SPF check it has to be performed as specified so > > that the correct semantics are preserved between publisher and receiver. > > > > I would rewrite the next sentence as: > > > > To make the SPF check, the SPF verifier MUST evaluate the check_host() > > function with the arguments set as follows: > > > > That sentence could be moved to the previous paragraph. You then get > > the arguments (for the function) together with the check_host() function. > >That currently point to 4.1 to remove the duplication that was complained >about in other comments. I don't think we should put it back. > > To make the test, the mail receiver MUST evaluate the check_host() > function with the arguments described in Section 4.1. If the working group is ok with this I am ok with it. >This is very close to what msk and I worked out. Please see the >text I posted >in the subthread with him and see if it works for you. I'll leave it to the working group to review and see whether it works for WG participants. >OK. How about this: > > ADMDs publishing SPF records ought to keep the amount of DNS > information needed to evaluate a record to a minimum. target="eval-limits"/> and > provide some suggestions about "include" mechanisms and chained > "redirect" modifiers. That's ok if the working group is ok with it. > > The issue was that the reference was incorrect. Here is the text > > from Section 3: > > > > 'The SPF record is a single string of text. The record format is > > described below in Section 4.' > > > > The title of Section 4 is "The check_host() Function". > >It's not incorrect. That is, in fact, where it's described. I'll leave it to the working group. > > I asked whether there were any implementations that do the following: > > > > 'Alternatively, for a server failure (RCODE 2) result, check_host() > > MAY track failures and treat multiple failures within 24 hours for > > the same domain as "permerror".' > > > > Stuart Gathman is listed as the author of pySPF. He mentioned that: > > '"This also solves the TIMEOUT for type 99 problem. Reporting a > > PermError for a broken name server would be very appropriate (and > > switching to checking TXT first while said failure is cached would > > also be permissible)"'. > > > > As an individual I prefer not to do the entire process again. Given > > that this is tied to another controversial discussion I have to list > > the issue as unresolved. > >How so? It's only unresolved because you decided to second guess what we >already agreed on. I don't think WGLC is a free shot at revisiting all the >work we've done. There's a real problem. This is the best solution anyone >came up with and so absent some alternative approach, there's nothing to >resolve. I went through the mailing list archives. The issue that was raised was "multiple DNS errors over a 24 hour period now can be called a permerror". I saw a discussion of "SERVFAIL" in the mailing list archives. If the working group does not raise this as an issue it's not an issue for me. > > I'll list Section 4.6.4 as an unresolved issue. > >Please specify what's unresolved. I'll take this in a separate message. >It's a change from what? SPF has worked this way since 2003. It doesn't >"break" anything. It was a deliberate design decision. I'll say ok if the working group does not raise this as an issue. >It already says that. Ok. >Why? It's not a rare error for people not to understand this. Most people >for small domains that try to deal with SPF are not DNS experts. That's not what I see as agreement based on I read from the mailing list archives. >What's unresolved? You've yet to explain what's defective. I don't think >it's particularly effective to list issues you've not explained as >unresolved. >By definition that's true, but it's also rather unresolvable. I am ok with what the working group wants. >I read it. I think it needs to stay. > > > > > > > "Software SHOULD make it clear that the explanation string > > > > > > > > > > > > comes from a third party." > > > > > > > > > > > > I could not understand what that means in RFC 2119 > terms. The draft > > > > > > uses RFC 2119 key words by example instead of providing an > > > > > > explanation. > > > > > > > > > >I don't understand the comment. > > > > > > > > There was a comment from Murray: "we're talking about > > > > interoperability between humans here, and not between implementations". > > > > > >We're talking about avoiding security issues caused by the humans getting > > >confused. > > > > I'll list this as an unresolved issue. I didn't see agreement for this after reading the mailing list archives. >msk is taking a stab at text for this, I think. Ok. >I can take it out. So far one person objected. If the standard is nothing >that anyone objects to goes in, we'll be here for a long time. I suggest taking it out. My reading of the mailing list archives is that there wasn't agreement. > > >What's wrong with the way it is? I think the current text is accurate. > > > > I don't see anything in the charter about working on a best practice > > document. I suggest choosing "good practice" if the working group > > really wants that text. > >I am at a loss for words. Best practice is correct. I mentioned that it is outside the scope of the charter. >I made a change today based on a suggestion from msk. I think it's resolved. Ok. > > > > > > In Appendix C: > > > > > > > > > > > > In Section E.1: > > > > > > 'This would cause a lookup on an DNS white list > (DNSWL) and cause > > > > > > a > > > > > > > > > > > > result of "fail" only for email not either coming from the > > > > > > domain's mx host(s) (SPF pass) or white listed sources (SPF > > > > > > neutral).' > > > > > > > > > > > > I didn't find any discussion about this on the SPFBIS mailing > > > > > > list. is there an explanation for this change between RFC > > > > > > 4408 and this > > > > > > > > > draft? > > > > > > > > > >It was pointed out that this is a white list, not a black list. > > > > > > > > I suggest dropping this change as it was not discussed within the > > > > working group. > > > > > >Yes. It was. > > > > As I didn't find that discussion I can only conclude that it has not > > been discussed within the working group. I suggest dropping the change. > >As msk pointed out, it was mostly affected by the reorganization. I didn't see agreement for this change. > > > > >The charter specifically allows for "addition of any enhancements > > > > >that have already gained widespread support". > > > > > > > > I read the discussion about the charter again. It is my > > > > understanding that extensions to the SPF protocol is > > > > out-of-scope. The working group did not add a work item during the > > > > chartering discussion as it was considered as an extension to the > > > > protocol. > > > > > >It was also not widely deployed. Should I take authentication-results out > > >of the draft then? > > > > I did not mention "authentication-results" in my comment. My comment > > was about Appendix I. In my opinion "extension" is out-of-scope. > >If extensions are out of scope, then we need to remove the discussion about a- >r. I understand you didn't mention it, but if I follow your suggestion, >that's a logical conclusion. Please see my previous comment about what is out of scope. >P.S. I sent the XML file to msk for some edits. Once I get it back, >I'll merge >the changes I mentioned here with that. Ok. As a note to the working group, the "Updates" I mentioned previously is not needed. I am also ok with the IDN text as it was reviewed by the working group. Regards, S. Moonesamy From spf2@kitterman.com Fri May 17 16:41:47 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4826321F8FED for ; Fri, 17 May 2013 16:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5o+BeaWyr1H for ; Fri, 17 May 2013 16:41:42 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0840E21F8FC4 for ; Fri, 17 May 2013 16:41:41 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E61EC20E40FE; Fri, 17 May 2013 19:41:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368834100; bh=GQtPS3VVZuhmldQxivWC4qhvCcQWtSG+vYoiAezrydQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=HWxn53xdyMimEORFuDD5V+6t92YzsWk2aDU54Pgld0iZGFcOl0Hg7XRAT4B0kUrLZ i3ML1aMX78SITLu+plVRZfKtabehK2D8t371V9Zf+tQfzy2irMEOPoZwSXwAmiZCYh YBTE0Q3yEmYxp97e7MKBKKFX7sI2ZuN4pIXzxSXc= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C807020E40F6; Fri, 17 May 2013 19:41:40 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 17 May 2013 19:41:39 -0400 Message-ID: <4906675.SizYbEoohs@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130517144328.0d5dade8@resistor.net> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <1808846.3L9zQIcVOx@scott-latitude-e6320> <6.2.5.6.2.20130517144328.0d5dade8@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 23:41:47 -0000 On Friday, May 17, 2013 04:24:15 PM S Moonesamy wrote: > Hi Scott, > > At 13:51 17-05-2013, Scott Kitterman wrote: > >Based on the follow-up with msk, the draft now reads: > > Without explicit approval of the publishing ADMD, checking other > > identities against SPF version 1 records is NOT RECOMMENDED because > > there are cases that are known to give incorrect results. For > > example, almost all mailing lists rewrite the "MAIL FROM" identity > > (see Section 10.3), but some do not change any other identities in > > the message. Documents that define other identities will have to > > define the method for explicit approval. > > > >This is very close to what you suggest. Do you think this is OK? > > The issue was the "explicit approval". I'll leave it to the working > group to see whether it is ok with the text. > > > > I went through the mailing list archive and I only found two comments > > > about this issue. I'll suggest the following text for the fourth > > > > > > paragraph of Section 2.4: > > > A SPF verifier performs an SPF check using the check_host() function > > > (Section 4). The SPF check it has to be performed as specified so > > > that the correct semantics are preserved between publisher and > > > receiver. > > > > > > I would rewrite the next sentence as: > > > To make the SPF check, the SPF verifier MUST evaluate the > > > check_host() > > > > > > function with the arguments set as follows: > > > That sentence could be moved to the previous paragraph. You then get > > > the arguments (for the function) together with the check_host() > > > function. > > > >That currently point to 4.1 to remove the duplication that was complained > >about in other comments. I don't think we should put it back. > > > > To make the test, the mail receiver MUST evaluate the check_host() > > function with the arguments described in Section 4.1. > > If the working group is ok with this I am ok with it. > > >This is very close to what msk and I worked out. Please see the > >text I posted > >in the subthread with him and see if it works for you. > > I'll leave it to the working group to review and see whether it works > for WG participants. > > >OK. How about this: > > ADMDs publishing SPF records ought to keep the amount of DNS > > information needed to evaluate a record to a minimum. > target="eval-limits"/> and > > provide some suggestions about "include" mechanisms and chained > > "redirect" modifiers. > > That's ok if the working group is ok with it. > > > > The issue was that the reference was incorrect. Here is the text > > > > > > from Section 3: > > > 'The SPF record is a single string of text. The record format is > > > > > > described below in Section 4.' > > > > > > The title of Section 4 is "The check_host() Function". > > > >It's not incorrect. That is, in fact, where it's described. > > I'll leave it to the working group. > > > > I asked whether there were any implementations that do the following: > > > 'Alternatively, for a server failure (RCODE 2) result, check_host() > > > > > > MAY track failures and treat multiple failures within 24 hours for > > > the same domain as "permerror".' > > > > > > Stuart Gathman is listed as the author of pySPF. He mentioned that: > > > '"This also solves the TIMEOUT for type 99 problem. Reporting a > > > PermError for a broken name server would be very appropriate (and > > > switching to checking TXT first while said failure is cached would > > > also be permissible)"'. > > > > > > As an individual I prefer not to do the entire process again. Given > > > that this is tied to another controversial discussion I have to list > > > the issue as unresolved. > > > >How so? It's only unresolved because you decided to second guess what we > >already agreed on. I don't think WGLC is a free shot at revisiting all the > >work we've done. There's a real problem. This is the best solution anyone > >came up with and so absent some alternative approach, there's nothing to > >resolve. > > I went through the mailing list archives. The issue that was raised > was "multiple DNS errors over a 24 hour period now can be called a > permerror". I saw a discussion of "SERVFAIL" in the mailing list > archives. If the working group does not raise this as an issue it's > not an issue for me. Sigh. I'll remove it as you aren't the only one who doesn't like this now. > > > I'll list Section 4.6.4 as an unresolved issue. > > > >Please specify what's unresolved. > > I'll take this in a separate message. > > >It's a change from what? SPF has worked this way since 2003. It doesn't > >"break" anything. It was a deliberate design decision. > > I'll say ok if the working group does not raise this as an issue. > > >It already says that. > > Ok. > > >Why? It's not a rare error for people not to understand this. Most people > >for small domains that try to deal with SPF are not DNS experts. > > That's not what I see as agreement based on I read from the mailing > list archives. I don't recall anyone saying that was incorrect. > >What's unresolved? You've yet to explain what's defective. I don't think > >it's particularly effective to list issues you've not explained as > >unresolved. > >By definition that's true, but it's also rather unresolvable. > > I am ok with what the working group wants. > > >I read it. I think it needs to stay. > > > > > > > > > "Software SHOULD make it clear that the explanation string > > > > > > > > > > > > > > comes from a third party." > > > > > > > > > > > > > > I could not understand what that means in RFC 2119 > > > > terms. The draft > > > > > > > > > uses RFC 2119 key words by example instead of providing an > > > > > > > explanation. > > > > > > > > > > > >I don't understand the comment. > > > > > > > > > > There was a comment from Murray: "we're talking about > > > > > interoperability between humans here, and not between > > > > > implementations". > > > > > > > >We're talking about avoiding security issues caused by the humans > > > >getting > > > >confused. > > > > > > I'll list this as an unresolved issue. > > I didn't see agreement for this after reading the mailing list archives. I don't see a strong push for a change either and it's in 4408. > >msk is taking a stab at text for this, I think. > > Ok. > > >I can take it out. So far one person objected. If the standard is nothing > >that anyone objects to goes in, we'll be here for a long time. > > I suggest taking it out. My reading of the mailing list archives is > that there wasn't agreement. It's out. > > > >What's wrong with the way it is? I think the current text is accurate. > > > > > > I don't see anything in the charter about working on a best practice > > > document. I suggest choosing "good practice" if the working group > > > really wants that text. > > > >I am at a loss for words. Best practice is correct. > > I mentioned that it is outside the scope of the charter. The document is full of this kind of advice. When we went through the reorganization discussion, we also we through want was in and what was out. If you want to revisit the scope of the document, it's probably an August deliverable at the earliest. > >I made a change today based on a suggestion from msk. I think it's > >resolved. > Ok. > > > > > > > > In Appendix C: > > > > > > > > > > > > > > In Section E.1: > > > > > > > 'This would cause a lookup on an DNS white list > > > > (DNSWL) and cause > > > > > > > > > a > > > > > > > > > > > > > > result of "fail" only for email not either coming from the > > > > > > > domain's mx host(s) (SPF pass) or white listed sources (SPF > > > > > > > neutral).' > > > > > > > > > > > > > > I didn't find any discussion about this on the SPFBIS mailing > > > > > > > list. is there an explanation for this change between RFC > > > > > > > > 4408 and this > > > > > > > > > > > draft? > > > > > > > > > > > >It was pointed out that this is a white list, not a black list. > > > > > > > > > > I suggest dropping this change as it was not discussed within the > > > > > working group. > > > > > > > >Yes. It was. > > > > > > As I didn't find that discussion I can only conclude that it has not > > > been discussed within the working group. I suggest dropping the change. > > > >As msk pointed out, it was mostly affected by the reorganization. > > I didn't see agreement for this change. > > > > > > >The charter specifically allows for "addition of any enhancements > > > > > >that have already gained widespread support". > > > > > > > > > > I read the discussion about the charter again. It is my > > > > > understanding that extensions to the SPF protocol is > > > > > out-of-scope. The working group did not add a work item during the > > > > > chartering discussion as it was considered as an extension to the > > > > > protocol. > > > > > > > >It was also not widely deployed. Should I take authentication-results > > > >out > > > >of the draft then? > > > > > > I did not mention "authentication-results" in my comment. My comment > > > was about Appendix I. In my opinion "extension" is out-of-scope. > > > >If extensions are out of scope, then we need to remove the discussion about > >a- r. I understand you didn't mention it, but if I follow your > >suggestion, that's a logical conclusion. > > Please see my previous comment about what is out of scope. Yes. I read it. I think you are wrong, but if you are right, there's a lot of stuff that needs to come out and we'll need a new schedule. Scott K From johnl@iecc.com Fri May 17 16:59:25 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5B121F9615 for ; Fri, 17 May 2013 16:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.804 X-Spam-Level: X-Spam-Status: No, score=-110.804 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhaOMR3Q7TJH for ; Fri, 17 May 2013 16:59:21 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 14CA121F95F6 for ; Fri, 17 May 2013 16:59:20 -0700 (PDT) Received: (qmail 76219 invoked from network); 17 May 2013 23:59:18 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 May 2013 23:59:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5196c455.xn--9vv.k1305; i=johnl@user.iecc.com; bh=I+VwlXlKxqF0yRBWBzzpkxgibvmqkWSGpYe9BFEbALc=; b=bHC5aSEfv4t2SfdzfSXIr8pLP0B43jl4nfkOhPLLuecuNZXViBiTeyeyYgN13E+4VJ/0vvA5VVbxZasJuxmddgXdOIOQvJcHCLe0dS0H+BYFsja5buUgmj+M/2s6G6HAWmlZ/G9W+xocfSgJcalCYhO1gRtih1uUHwyXgbSHHFw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5196c455.xn--9vv.k1305; olt=johnl@user.iecc.com; bh=I+VwlXlKxqF0yRBWBzzpkxgibvmqkWSGpYe9BFEbALc=; b=Vf+E7WuXxmFgmffS2XsJzzGUYE7MZVNyizXCDFWV5Bt22jA+DpmuyainzC/J+8yAfCpX3WoVA4cygiLi/9Hv+i7ifxXw88enYyx9Hwj4RPMA5InLSa/FjGReYU0BYRpfSCP0uhYlA39CaYIsIJWcFI0UOeHTGoRlUDimYQiFBAw= Date: 17 May 2013 23:58:55 -0000 Message-ID: <20130517235855.64729.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <2107801.vGVXe1y3CL@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: spf2@kitterman.com Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 23:59:25 -0000 >True, but I think the statement that such understanding requires an out of >band/private agreement is not correct. We could have another round, but the language you and Murray came up with looks fine to me. >> Huh? I went through -14 and all the temperrors are either DNS >> failures or timeouts. How is that different from failures or timeouts >> looking up an MX? I realize it happens on the server rather than the >> client, but so what? > >SERVFAIL is supposed to be something temporary, but in my experience it often >is not. That was the root of the original discussion. I wanted to call >SERVFAIL a permanent error, but got shown that was not correct. SERVFAIL is >often a "permanent" "temporary" error. Well, sure, and it can be equally permanent if you get it when doing an MX or A/AAAA lookup on the client side, leading to repeated requeues until the message times out (RFC 5321 sec 5.1.) I still don't see what merits different treatment. From sm@elandsys.com Fri May 17 17:20:51 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697BC21F9691 for ; Fri, 17 May 2013 17:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leDp+eRcmmPy for ; Fri, 17 May 2013 17:20:50 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D3E21F9423 for ; Fri, 17 May 2013 17:20:49 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.153.229]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4I0KZ4o011747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 May 2013 17:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1368836447; bh=vrb3dc/K1YzOcYhXx/ppRGSdNeZub1/rfX6uAurfT+U=; h=Date:To:From:Subject:In-Reply-To:References; b=0frGZwDs5qcwsN6hU54DLbnv4vssOoXSs126ACz5+mh8hRXr5RnogQV9RuxVUrydQ MYxGpX7BPo7X7lRigF+SHEIQCqbTdV/0IVGYGAjX54D5HzBvkXypsS5zGtIPxTFCOx NymRTAsKYyo9BDOko1Ebe+16jmBUwcHr+77DHFq4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1368836447; i=@elandsys.com; bh=vrb3dc/K1YzOcYhXx/ppRGSdNeZub1/rfX6uAurfT+U=; h=Date:To:From:Subject:In-Reply-To:References; b=EUhy4/3iZKHWX1q77ibsjJvPMwsH8K33Cccx8YXBMLeyMgsjfPz+eJXeHXtmqFgMk vssJQ57/LlHxTIyx6OTdm6UFkjWCWTppqFp8WPY99VclRGUEGAeNnipNAWXh5DPjjf hZZI3T4Ecyhs7s+0OkRACjWjvxXZBP7KrCWiD0QA= Message-Id: <6.2.5.6.2.20130517162915.0adc1b98@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 17 May 2013 16:49:06 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1808846.3L9zQIcVOx@scott-latitude-e6320> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <1972467.x8au6JTDZS@scott-latitude-e6320> <6.2.5.6.2.20130517084156.0c3e9128@resistor.net> <1808846.3L9zQIcVOx@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 - Section 4.6.4 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 00:20:51 -0000 Hello, I am listing some text from Section 4.6.4 of the draft only. I'll borrow a few works from Andrew: 'IMO, the purpose of a 2119 SHOULD is not "eat your broccoli; it's good for you." A good rule of thumb is, if you have a SHOULD, you ought to be able to say why it's not MUST (i.e. under what conditions it would be ok not to do the thing you SHOULD do). Since the IETF is about interoperability, this harm should be an interoperability issue.' The text being discussed was: 'MTAs or other processors SHOULD impose a limit on the maximum amount of elapsed time to evaluate check_host(). Such a limit SHOULD allow at least 20 seconds. If such a limit is exceeded, the result of authorization SHOULD be "temperror".' Please comment if you are not ok with the above. Regards, S. Moonesamy From sm@elandsys.com Fri May 17 17:20:52 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450A421F9691 for ; Fri, 17 May 2013 17:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhDEcHIz9HOe for ; Fri, 17 May 2013 17:20:51 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A1B21F9423 for ; Fri, 17 May 2013 17:20:51 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.153.229]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4I0KZ4q011747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 May 2013 17:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1368836450; bh=A5MFG+fpGSgPRHaR54HqMe9m/lJWy0hxTVSqtJXRnX4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PLjzZB3xmuaNxQm9e5WEhPE6lQw4NC9tCHv7aj3cXX/k4pZfTHDYkpTG1ZNRIRdl4 YTgC4lmSmewft2Liiz1HB1w/rg/NdLs744TM7IXWOG/5Oten+3/DJxBGDNHKo0Xj5n olECui66BSUGOQ8re9tOKTQS87XtYlpkT0BJh5U4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1368836450; i=@elandsys.com; bh=A5MFG+fpGSgPRHaR54HqMe9m/lJWy0hxTVSqtJXRnX4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=iequDvxdJLObG1sUHui45eqxsRSX97s2Dp1G/twwdN36qfCOyJJwu3BJ0To5lvaEd IdduQQfXZ0a3wHreQpoKhnmJRpPu+Jw7CWpi/WP5ZlMiOih7yzQVb2OFU03/dxF9th jiiFwVDEMpwjoisBDlGblZKs8zpBdCTtz8cjmmR8= Message-Id: <6.2.5.6.2.20130517165218.0c3e7268@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 17 May 2013 17:20:23 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <4906675.SizYbEoohs@scott-latitude-e6320> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <1808846.3L9zQIcVOx@scott-latitude-e6320> <6.2.5.6.2.20130517144328.0d5dade8@resistor.net> <4906675.SizYbEoohs@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 00:20:52 -0000 Hi Scott, At 16:41 17-05-2013, Scott Kitterman wrote: > > >Why? It's not a rare error for people not to understand > this. Most people > > >for small domains that try to deal with SPF are not DNS experts. > > > > That's not what I see as agreement based on I read from the mailing > > list archives. > >I don't recall anyone saying that was incorrect. I could not find any discussion of the current text being proposed and discussed in the mailing list archives. >I don't see a strong push for a change either and it's in 4408. I don't see a strong push either. > > > > >What's wrong with the way it is? I think the current text > is accurate. > > > > > > > > I don't see anything in the charter about working on a best practice > > > > document. I suggest choosing "good practice" if the working group > > > > really wants that text. > > > > > >I am at a loss for words. Best practice is correct. > > > > I mentioned that it is outside the scope of the charter. > >The document is full of this kind of advice. When we went through the >reorganization discussion, we also we through want was in and what was out. >If you want to revisit the scope of the document, it's probably an August >deliverable at the earliest. I am looking at what text has been discussed on the mailing list and what gained agreement. Regards, S. Moonesamy From spf2@kitterman.com Fri May 17 17:24:18 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3B121F9476 for ; Fri, 17 May 2013 17:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogq-uQzH705B for ; Fri, 17 May 2013 17:24:13 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id BAAB921F9424 for ; Fri, 17 May 2013 17:24:13 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 8B927D0407E; Fri, 17 May 2013 19:24:07 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368836653; bh=AaCNsolkH45kbbhHPF4NAlSLWfnAjzN7b5FRT9yxpHQ=; h=In-Reply-To:References:Subject:From:Date:To:From; b=K+urNvDeMk3ZwNRi8UdieefO+cgNWaAKD4Zwfg/PuSy3YujrXPur5xfCVRJPtBi2B Ep9X6q9+MuP7KEIUlUgvHw/a2dGIS+OFpcpTqMa7ijEDpbpUyaFns3M73NFO2kAuUW JFibpnyDsiVAJq9bbdeL9Q+IzUQi8om3Qu6xZNKI= Received: from [IPV6:2600:1003:b02d:1ff8:116b:23a:75ff:16d5] (unknown [IPv6:2600:1003:b02d:1ff8:116b:23a:75ff:16d5]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 310B1D04049; Fri, 17 May 2013 19:24:06 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <20130517235855.64729.qmail@joyce.lan> References: <20130517235855.64729.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 17 May 2013 20:24:04 -0400 To: spfbis@ietf.org Message-ID: <90695273-a996-4e8f-ace9-b6deb1dfd8d7@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 00:24:18 -0000 John Levine wrote: >>True, but I think the statement that such understanding requires an >out of >>band/private agreement is not correct. > >We could have another round, but the language you and Murray came up >with looks fine to me. > >>> Huh? I went through -14 and all the temperrors are either DNS >>> failures or timeouts. How is that different from failures or >timeouts >>> looking up an MX? I realize it happens on the server rather than >the >>> client, but so what? >> >>SERVFAIL is supposed to be something temporary, but in my experience >it often >>is not. That was the root of the original discussion. I wanted to >call >>SERVFAIL a permanent error, but got shown that was not correct. >SERVFAIL is >>often a "permanent" "temporary" error. > >Well, sure, and it can be equally permanent if you get it when doing >an MX or A/AAAA lookup on the client side, leading to repeated >requeues until the message times out (RFC 5321 sec 5.1.) I still >don't see what merits different treatment. It's pretty clear I'm in the rough on this, so I've removed it. Scott K From spf2@kitterman.com Fri May 17 17:26:25 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D3921F961B for ; Fri, 17 May 2013 17:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fELAr6oMowQe for ; Fri, 17 May 2013 17:26:21 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id E91C721F9487 for ; Fri, 17 May 2013 17:26:20 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id AEA69D04094; Fri, 17 May 2013 19:26:16 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368836776; bh=BxSpvQB5U3jpoqdri+QQtr3ws19942DkriYTSREU8g0=; h=In-Reply-To:References:Subject:From:Date:To:From; b=ODITNUO/QMJfWb2vy9kjXjWiGI9b/TlPyD3IPJHB4uCynDLKd12IeuJWk5H8kqJUy 9Ntjz2w8l0IkKWzPjxzSEX5VwZ17EWL1F8WhfBFdWTFejFX2tFblFKJTkQKGz29ZjC BTBqEfqQns8UJ1Hh5MiCNXJdlnYPK/OGBFLzIILs= Received: from [IPV6:2600:1003:b02d:1ff8:116b:23a:75ff:16d5] (unknown [IPv6:2600:1003:b02d:1ff8:116b:23a:75ff:16d5]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 52238D04092; Fri, 17 May 2013 19:26:16 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20130517165218.0c3e7268@resistor.net> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <1808846.3L9zQIcVOx@scott-latitude-e6320> <6.2.5.6.2.20130517144328.0d5dade8@resistor.net> <4906675.SizYbEoohs@scott-latitude-e6320> <6.2.5.6.2.20130517165218.0c3e7268@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 17 May 2013 20:26:13 -0400 To: spfbis@ietf.org Message-ID: <6d171169-a73a-4352-b204-cac6b180f790@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 00:26:25 -0000 S Moonesamy wrote: >Hi Scott, >At 16:41 17-05-2013, Scott Kitterman wrote: >> > >Why? It's not a rare error for people not to understand >> this. Most people >> > >for small domains that try to deal with SPF are not DNS experts. >> > >> > That's not what I see as agreement based on I read from the mailing >> > list archives. >> >>I don't recall anyone saying that was incorrect. > >I could not find any discussion of the current text being proposed >and discussed in the mailing list archives. > >>I don't see a strong push for a change either and it's in 4408. > >I don't see a strong push either. > >> > > > >What's wrong with the way it is? I think the current text >> is accurate. >> > > > >> > > > I don't see anything in the charter about working on a best >practice >> > > > document. I suggest choosing "good practice" if the working >group >> > > > really wants that text. >> > > >> > >I am at a loss for words. Best practice is correct. >> > >> > I mentioned that it is outside the scope of the charter. >> >>The document is full of this kind of advice. When we went through the >>reorganization discussion, we also we through want was in and what was >out. >>If you want to revisit the scope of the document, it's probably an >August >>deliverable at the earliest. > >I am looking at what text has been discussed on the mailing list and >what gained agreement. If it's out of scope, why does that matter? Scott K From sm@elandsys.com Fri May 17 17:44:04 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C94421F9180 for ; Fri, 17 May 2013 17:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HiimXBOhjHd for ; Fri, 17 May 2013 17:44:03 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6028D21F915C for ; Fri, 17 May 2013 17:44:03 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.153.229]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4I0hnFp028693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 May 2013 17:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1368837841; bh=pKkjfYV97X6BsMLeOpzLGsY2CEX9TFWnKT4OfU1UZHQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JM1rSwxpUxP/mW5QmTzXBNbZ68JHgJNddaJdROuORo890/hHvzp01qAOBjJSM+L1Z HWz0RTmn93YaaexMwi8TKO2EQddjsnTlSgxNJcsjaOoDGXWJeLtb0rRs3YHBhd0Out cCsHU/aw3d5X0ImYFPy242S5ABItU9eajXw5kD4w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1368837841; i=@elandsys.com; bh=pKkjfYV97X6BsMLeOpzLGsY2CEX9TFWnKT4OfU1UZHQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=aZAiPsTUFDKm0CrHN8iKEq8PC2MYOSFEA7uIKp+GhsKdmcQx/uYtLX4ccpPH/JIG4 6PEkC/20ZXLHm1jg+2bCoDvWA+DhvmIge/5cc2kyD3FpZdaSBgA1pMKEXNkVYIOzBK kG7cE+SeUXRcSAaQRe4vZQI6u0lMnqFarfZTWpDE= Message-Id: <6.2.5.6.2.20130517173349.0cc2ef28@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 17 May 2013 17:43:37 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <6d171169-a73a-4352-b204-cac6b180f790@email.android.com> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <1808846.3L9zQIcVOx@scott-latitude-e6320> <6.2.5.6.2.20130517144328.0d5dade8@resistor.net> <4906675.SizYbEoohs@scott-latitude-e6320> <6.2.5.6.2.20130517165218.0c3e7268@resistor.net> <6d171169-a73a-4352-b204-cac6b180f790@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 00:44:04 -0000 Hi Scott, At 17:26 17-05-2013, Scott Kitterman wrote: >If it's out of scope, why does that matter? My comment was: "I am looking at what text has been discussed on the mailing list and what gained agreement." A working group participant can raise any objection if a text change was made and that text change is outside the scope of the SPFBIS charter . I read the messages posted to the SPFBIS mailing list before or during the WGLC and I did not find any objection which has not been addressed by the SPFBIS WG Chairs. Regards, S. Moonesamy From spf2@kitterman.com Fri May 17 18:22:39 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E3821F8E93 for ; Fri, 17 May 2013 18:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.716 X-Spam-Level: X-Spam-Status: No, score=-2.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf4Gjc51Uwzr for ; Fri, 17 May 2013 18:22:38 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1C27621F8556 for ; Fri, 17 May 2013 18:22:37 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 473BAD0407E; Fri, 17 May 2013 20:22:37 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368840157; bh=fxFPONazJWQzFjBp9xnef5c0F2F2PZ3CyMh4hSaXhCI=; h=In-Reply-To:References:Subject:From:Date:To:From; b=Q35TykrNN/+JGRHFdh1dRq6210PJM6f2l+mvPynl6rDNd+2wil8JmAMS96PVwGoEw iTPb09LlvOYRAyREHfMlkpFTpP+dgzhykoZIqKFVFRjGR6zjRXAbSvNmdm3lpRPPbE j31YdNG4GoumGI5ScaOsRvkPojG09sbHNuT3fvXw= Received: from [192.168.111.2] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 76938D04067; Fri, 17 May 2013 20:22:33 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20130517173349.0cc2ef28@resistor.net> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <1808846.3L9zQIcVOx@scott-latitude-e6320> <6.2.5.6.2.20130517144328.0d5dade8@resistor.net> <4906675.SizYbEoohs@scott-latitude-e6320> <6.2.5.6.2.20130517165218.0c3e7268@resistor.net> <6d171169-a73a-4352-b204-cac6b180f790@email.android.com> <6.2.5.6.2.20130517173349.0cc2ef28@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 17 May 2013 21:22:16 -0400 To: spfbis@ietf.org Message-ID: <3f4163fb-262a-4367-8437-613cae055605@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 01:22:39 -0000 S Moonesamy wrote: >Hi Scott, >At 17:26 17-05-2013, Scott Kitterman wrote: >>If it's out of scope, why does that matter? > >My comment was: > > "I am looking at what text has been discussed on the mailing list and > what gained agreement." > >A working group participant can raise any objection if a text change >was made and that text change is outside the scope of the SPFBIS >charter . I read the messages posted to the SPFBIS mailing list >before or during the WGLC and I did not find any objection which has >not been addressed by the SPFBIS WG Chairs. FYI, I went back and looked. It was added in rev 05. My point is that if this is out of scope, then a substantial fraction of the document is out of scope. We've had many discussions about what is in and what is out. Coming at this point in the process, I find a shift in your view about scope very troubling. If describing a established operational practices is out of scope, then it has to be generally out of scope and we have to re-write the document. You can't bend the charter in one direction to get rid of some of it and in the other to keep the rest. The group my decide it's prudent not to put this in or to reword it, but you can't selectively adjust the scope of the charter. I don't recommend this path. Scott K From sm@elandsys.com Sat May 18 01:50:26 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3836521F962C for ; Sat, 18 May 2013 01:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zDYwIeQQlxn for ; Sat, 18 May 2013 01:50:25 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7704221F962B for ; Sat, 18 May 2013 01:50:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.153.229]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4I8oAn3020711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 18 May 2013 01:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1368867022; bh=GlXRoNcCYqqZI84AHdBK9QC2bEt77TlfAOTjM5SE03c=; h=Date:To:From:Subject:In-Reply-To:References; b=CuetvC8lDtc5UEgMF0q5qUxu4DbSvdEPkVvMSQQN+zhEuJU0RWRXkHsy6gr0Yw9zS 8oX3LoD3y3hoVb+hawwtBMruJ60x4yc/TbuEpc63JU6JGfcJJGWRN4MSaRHVySCCPp IykKDRbKZZW7Jc9DogvFAirEgJio2YbJWqQK9Ll8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1368867022; i=@elandsys.com; bh=GlXRoNcCYqqZI84AHdBK9QC2bEt77TlfAOTjM5SE03c=; h=Date:To:From:Subject:In-Reply-To:References; b=jZHjzAuoV7ssAHzJIDFrrp79c0lCpu2YKEKaoBHq9x0+O3QFwqYl93Pc8+wh3FsAb cioD1xscyXVNCmrZk8OEAietMnBbbwF2FOKUyR33cNvEz21I/hpqfUNcyup1XFJ5Tu KkXz3aFRuAUYPrEYashxRgmmhIHP1yAk5v/OoHtc= Message-Id: <6.2.5.6.2.20130517233552.0b58c1d8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 18 May 2013 01:46:46 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <3f4163fb-262a-4367-8437-613cae055605@email.android.com> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <1808846.3L9zQIcVOx@scott-latitude-e6320> <6.2.5.6.2.20130517144328.0d5dade8@resistor.net> <4906675.SizYbEoohs@scott-latitude-e6320> <6.2.5.6.2.20130517165218.0c3e7268@resistor.net> <6d171169-a73a-4352-b204-cac6b180f790@email.android.com> <6.2.5.6.2.20130517173349.0cc2ef28@resistor.net> <3f4163fb-262a-4367-8437-613cae055605@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Scope (was: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 08:50:26 -0000 Hello, I read the SPFBIS mailing list archive again to see whether the question of scope was not addressed correctly. There was a discussion about "what unused means". John Levine, Scott Kitterman, Dave Crocker, Alessandro Vesely, and Hector Santos commented about that. A message about the scope of the charter was posted to the SPFBIS mailing list by the WG Chairs after that. Douglas Otis posted comments about "Leaving DNS look-up handling undefined or suggesting A-labels should be retained in the in the return path is not acceptable". There were comments from John Levine, Scott Kitterman, Dave Crocker, Murray S. Kucherawy, Alessandro Vesely, Commerco WebMaster and John Leslie about that. There was a comment from Scott Kitterman about "localpart macros are rare enough that no one need any sleep over them not supporting the full range of UTF-8, but they are in use so it's out of scope to ditch them". Murray S. Kucherawy, Dave Crocker, John Leslie, Alessandro Vesely, Kurt Andersen and Scott Kitterman participated in the discussion about the issue. There was a message from Douglas Otis about "support for retaining Received-SPF Header Field". There was also a message from Murray S. Kucherawy about adding support for "Authentication-Results: header". There was a message from Hector Santos about "remove A-R from 4408bis". Scott Kitterman, Hector Santos, John Levine, Arthur Thisell and Wayne Doust participated in the discussion. There was a message from Hector Santos about "Genesis of 30 days delays" as the text appeared in draft-ietf-spfbis-4408bis-10. Scott Kitterman, Murray S. Kucherawy and John Levine participated in the discussion. I mentioned that there was an short discussion between Scott Kitterman and Murray S. Kucherawy about the "30 days" period previously. In my opinion these changes or non-changes were proposed on the SPFBIS mailing list and they were discussed on the SPFBIS mailing list. What I have to show during the evaluation of the document is where the decision for a change or non-change was made and the discussions leading to the decision. If there is an issue about scope, for example "extensions to SPF" I can point out that the matter was brought to the attention of the working group last year: "This updated specification is intended to clarify identified ambiguities in [RFC4408], resolve techincal issues identified in post-RFC 4408 deplyment experience, and document widely deployed extensions to SPF that have been developed since [RFC4408] was published." and it was pointed out that extensions to SPF does not seem in line with what is in the SPFBIS charter. If I am asked about Section 9 of the draft during the evaluation I can point to the messages discussing about scope and the decision about the change. Regards, S. Moonesamy From ajs@anvilwalrusden.com Sat May 18 02:25:41 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBC521F915C for ; Sat, 18 May 2013 02:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2mlqm8nQ735 for ; Sat, 18 May 2013 02:25:34 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8E321F937B for ; Sat, 18 May 2013 02:25:33 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 43B278A031 for ; Sat, 18 May 2013 09:25:32 +0000 (UTC) Date: Sat, 18 May 2013 05:25:29 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130518092529.GC16458@mx1.yitter.info> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <2724237.eQuNQK5KLA@scott-latitude-e6320> <6.2.5.6.2.20130516154521.06ceef08@resistor.net> <1972467.x8au6JTDZS@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] MUST vs "necessary" (Re: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 09:25:41 -0000 On Fri, May 17, 2013 at 01:35:21AM -0700, Murray S. Kucherawy wrote: > > Andrew's message drew the distinction between saying "necessary" and > "MUST". There must be a nuance in there that I'm missing, because they're > essentially synonymous to me; in fact, "-all" is the only way to achieve > the stated goal for either party to the communication, so "MUST" seems > proper to me, though either solution is also fine. Andrew, would you care > to elaborate? In RFC 2119 we have this: "MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification." But the passage in question is not saying "you have to do this". It's saying instead that, because of the way the protocol works, the only way to achieve some end is to use a particular facility. In other words, this is really informational guidance on how to use the protocol, given the way it works. The original reason I was making the distinction, please remember, was that the draft at the time was making a change from RECOMMENDED to MUST, but it was doing so conditionally, thereby using the RFC 2119 keywords more correctly (the 4408 use of RECOMMENDED in this case was really more "we think this is a good idea"). In the context of the new text, it seemed to me we didn't need a 2119 keyword at all, because what was being described is a consequence of the way the protocol operates, and not a requirement on conforming implementations. I don't feel super strongly about this. I acknowledge SM's point, however, that this change appears to be a substantive change in the use of a 2119 keyword from 4408 to the new document, and there's a potential question as to whether that is appropriate under our charter. I think this argument could go either way, which is why I suggested the formulation without the keyword. I'm not married to this approach, however, and I think it will be possible to argue that the change in this case is ok under our charter. It's just a potential snag when we go to IETF LC. (Of course, compared to the war we'll have over the TXT record, I suppose this'll be in the noise.) I hope that clears things up. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Sat May 18 02:55:21 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE0021F9195 for ; Sat, 18 May 2013 02:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZLeQFnmKr6e for ; Sat, 18 May 2013 02:55:14 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB0A21F912C for ; Sat, 18 May 2013 02:55:13 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 828778A031 for ; Sat, 18 May 2013 09:55:13 +0000 (UTC) Date: Sat, 18 May 2013 05:55:11 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130518095510.GF16458@mx1.yitter.info> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <2724237.eQuNQK5KLA@scott-latitude-e6320> <6.2.5.6.2.20130516154521.06ceef08@resistor.net> <1972467.x8au6JTDZS@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1972467.x8au6JTDZS@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 09:55:21 -0000 On Fri, May 17, 2013 at 02:37:39AM -0400, Scott Kitterman wrote: > On Thursday, May 16, 2013 06:36:14 PM S Moonesamy wrote: > > >How could one retrieve anything other than DNS TXT records from the > > >DNS? That > > >seems redundant since it says "retrieved from the DNS". > > > > I left this DNS angle for Andrew to comment. > > OK. I don't think it matters. > > "The SPF record is a variable length string of octets encoded in > > a DSN TXT record." > > I split the difference and put in: > > The SPF record is expressed as a single string of text encoded in a DNS TXT > record. Here, however, I think there might be a problem. First, I think the sentence probably should say "The SPF record is expressed as a single string of text encoded in the RDATA of a DNS TXT record." That's strictly speaking where you find it. But on reflection, there remains the question of whether you're allowed to split across TXT records. This came up on another list, and it's a good point. If we have consensus that you _can't_, then we should say so: "The SPF record is expressed as a single string of text found in the RDATA of a single DNS TXT resource record." Or something like that. If it _is_ possible to split the policy statement across multiple TXT records, we need to explain how. (I think it's impossible to do reliably, FWIW.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Sat May 18 07:55:44 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400E021F913E for ; Sat, 18 May 2013 07:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.712 X-Spam-Level: X-Spam-Status: No, score=-2.712 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id em8Qw2mlj+mN for ; Sat, 18 May 2013 07:55:39 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A0B4321F9133 for ; Sat, 18 May 2013 07:55:38 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 940EB20E40FC; Sat, 18 May 2013 10:55:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368888937; bh=qgQhXykF+3DDZ9wrz4MjRuCkra3tpaS//UxJ2HPisPE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Ha2vRmSB1TIIvylyrN+gQBi9AWhgOTaCZYS8H5gpoi0d5R6I7GRYDFn13FrGOWQn3 ux4lijCxm5bW0Oos3HtxBZb+sHL9JV8RdCttDw2/2HuGpRqc3pbMbW/pnO7BAI9XeR 6cqXqnBaPMKZf2UUdsEZSq49zQLTXtDQamiqjt9U= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 797FF20E401D; Sat, 18 May 2013 10:55:37 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 May 2013 10:55:36 -0400 Message-ID: <8314278.tCmO8Z4mIG@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130518095510.GF16458@mx1.yitter.info> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <1972467.x8au6JTDZS@scott-latitude-e6320> <20130518095510.GF16458@mx1.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 14:55:44 -0000 On Saturday, May 18, 2013 05:55:11 AM Andrew Sullivan wrote: > On Fri, May 17, 2013 at 02:37:39AM -0400, Scott Kitterman wrote: > > On Thursday, May 16, 2013 06:36:14 PM S Moonesamy wrote: > > > >How could one retrieve anything other than DNS TXT records from the > > > >DNS? That > > > >seems redundant since it says "retrieved from the DNS". > > > > > > I left this DNS angle for Andrew to comment. > > > > OK. > > I don't think it matters. > > > > "The SPF record is a variable length string of octets encoded in > > > > > > a DSN TXT record." > > > > I split the difference and put in: > > > > The SPF record is expressed as a single string of text encoded in a DNS > > TXT record. > > Here, however, I think there might be a problem. > > First, I think the sentence probably should say "The SPF record is > expressed as a single string of text encoded in the RDATA of a DNS TXT > record." That's strictly speaking where you find it. > > But on reflection, there remains the question of whether you're > allowed to split across TXT records. This came up on another list, > and it's a good point. If we have consensus that you _can't_, then we > should say so: "The SPF record is expressed as a single string of text > found in the RDATA of a single DNS TXT resource record." Or something > like that. If it _is_ possible to split the policy statement across > multiple TXT records, we need to explain how. (I think it's > impossible to do reliably, FWIW.) Thanks. The practice to date has been that it can be multiple strings in a single record. I've to copy/pasted your second suggestion. Scott K From superuser@gmail.com Sat May 18 10:22:09 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AAC21F8FEC for ; Sat, 18 May 2013 10:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgSF4ux0eUfD for ; Sat, 18 May 2013 10:22:08 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 50E9221F8FE9 for ; Sat, 18 May 2013 10:22:08 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id j13so3926527wgh.4 for ; Sat, 18 May 2013 10:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BToir6YlQ7biuvkhcamyg586th6qocJDCtHltBQGkXk=; b=rHdvjO2Wo/doarRcYqZRid5sgWZekJOTer8c6JEpqey0jxy0mpLz1JtjFNtZGK8gG7 cFupBn9xmYgs0f+jBPPulJs0menWSpnAVf/SdyLn3r1xjaI8jp+P0hoQNwkHqSmOER/K 37m2BDrYbPqHU78PkSevC4RyQyXz/zyLBiR/A2SJ/QTuY2lu12YDoa9M8mpdG6gQn1Xn 2we7hZS1ketVbDm8W8Gc7x01d7urj1ER+qfCqU9SRccOV32GLiOz+v7xD5a3SZOHckMX 5EwXcDzZ5TPqa8zYmgCjXkA0OwwJBTe8E++0dRfRA+Ch+xHs2jTIV0fH2GdJ2HC/zaHW sF3Q== MIME-Version: 1.0 X-Received: by 10.195.12.135 with SMTP id eq7mr6461352wjd.17.1368897727486; Sat, 18 May 2013 10:22:07 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Sat, 18 May 2013 10:22:07 -0700 (PDT) In-Reply-To: <8314278.tCmO8Z4mIG@scott-latitude-e6320> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <1972467.x8au6JTDZS@scott-latitude-e6320> <20130518095510.GF16458@mx1.yitter.info> <8314278.tCmO8Z4mIG@scott-latitude-e6320> Date: Sat, 18 May 2013 10:22:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7bb04b24c7e2ea04dd0156e0 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 17:22:09 -0000 --047d7bb04b24c7e2ea04dd0156e0 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 18, 2013 at 7:55 AM, Scott Kitterman wrote: > > But on reflection, there remains the question of whether you're > > allowed to split across TXT records. This came up on another list, > > and it's a good point. If we have consensus that you _can't_, then we > > should say so: "The SPF record is expressed as a single string of text > > found in the RDATA of a single DNS TXT resource record." Or something > > like that. If it _is_ possible to split the policy statement across > > multiple TXT records, we need to explain how. (I think it's > > impossible to do reliably, FWIW.) > > The predecessor to Sender ID was Caller ID, and it stored the policy in XML which most of the time didn't fit in a single TXT RR, so they came up with a labeling scheme to indicate the order in which multiple TXT RRs were to be reassembled. It seemed to be reliable. Totally unnecessary here though. -MSK --047d7bb04b24c7e2ea04dd0156e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, May 18, 2013 at 7:55 AM, Scott Kitterman <spf2@k= itterman.com> wrote:
>= But on reflection, there remains the question of whether you're
> allowed to split across TXT records. =A0This came up on another list,<= br> > and it's a good point. =A0If we have consensus that you _can't= _, then we
> should say so: "The SPF record is expressed as a single string of= text
> found in the RDATA of a single DNS TXT resource record." =A0Or so= mething
> like that. =A0If it _is_ possible to split the policy statement across=
> multiple TXT records, we need to explain how. =A0(I think it's
> impossible to do reliably, FWIW.)


The predecessor to Sender ID wa= s Caller ID, and it stored the policy in XML which most of the time didn= 9;t fit in a single TXT RR, so they came up with a labeling scheme to indic= ate the order in which multiple TXT RRs were to be reassembled.=A0 It seeme= d to be reliable.=A0 Totally unnecessary here though.

-MSK
--047d7bb04b24c7e2ea04dd0156e0-- From sm@elandsys.com Sat May 18 10:46:43 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8294D21F901A for ; Sat, 18 May 2013 10:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-otVQ3YmLDE for ; Sat, 18 May 2013 10:46:42 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E30E721F8B65 for ; Sat, 18 May 2013 10:46:42 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.145.160]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4IHkRHq006962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 May 2013 10:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1368899200; bh=yiiICAEEn6qZnbvxkoW7oHVpEurZ1H4gVcdHEw/niSI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=t39TjI4RCjRm/QyiadKEsJyOJXaYpqCoalwadK576KpicpwAh+LdR71pyX3mpaoOD TSg3kUYbhFj/Uc9nVwWOiHhiSbMVnpjAUcCulaTLlHqC7LyTQaPO6LJBz+Qwal6tsB wmwo0MgwYcLqErUgxsRd1oH7tC6mGtfaYqbMhS5s= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1368899200; i=@elandsys.com; bh=yiiICAEEn6qZnbvxkoW7oHVpEurZ1H4gVcdHEw/niSI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rinLBgfa3eO4efYIId82AG4t2sslr/E9V6+sak4fXVqW3uMIDfhvcAduv1Pehdz3R gI8U5Ebi0wXP0DWlZOC0LVtqnEkNcYTlzJgxb4EuEyBvGhuFdVih2p7ie5H7DmBtyV oOLlrMqzyiN4jwIFUTjiZZDI0nSnUVdeSmJePs/A= Message-Id: <6.2.5.6.2.20130518101418.0bbf6848@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 18 May 2013 10:35:03 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <4504827.dqlBOFqUut@scott-latitude-e6320> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <6.2.5.6.2.20130513213220.0b8c3c10@elandnews.com> <4504827.dqlBOFqUut@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Addressing reviews (was: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 17:46:43 -0000 Hi Scott, The Gen-ART review of draft-ietf-spfbis-4408bis-14 was posted on April 29 ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03647.html ). There weren't any comments about that review. The Applications Area directorate review was posted on April 29 ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03633.html ). There was a comment from Hector Santos ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03653.html ). The Security Directorate review of draft-ietf-spfbis-4408bis-14 was posted on April 30 ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03679.html ). There was a comment from you ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03723.html ) and from John Levine ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03726.html ). Can you provide an estimate date of when the reviews mentioned above will be addressed? Regards, S. Moonesamy From spf2@kitterman.com Sat May 18 11:07:33 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E95521F8F4A for ; Sat, 18 May 2013 11:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Btj581KUswXW for ; Sat, 18 May 2013 11:07:28 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4E61321F8F43 for ; Sat, 18 May 2013 11:07:28 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B34F520E40FC; Sat, 18 May 2013 14:07:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368900447; bh=Y3OnlqittG3qlP3JwRFGM0V6pRlpxWhQw0zRXHLtPVo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kKyulHqIxxxRC2hgApGBiKLhgdOUP5P5fjJqoRY8ypr3CjzVbogSRI4skp11jkIqh ASKetHx/c3qrLsydktovUe5l8et32uNGcAEQqXu4d/ecCS7hUemAy7FeY13TaflYcy 15OixeiZG+UoUn9F3+OX820dqGl/bE8wFyGMPvp4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 98EBB20E401D; Sat, 18 May 2013 14:07:27 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 May 2013 14:07:26 -0400 Message-ID: <5087983.gq5KGjyuFv@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130518092529.GC16458@mx1.yitter.info> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <20130518092529.GC16458@mx1.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] MUST vs "necessary" (Re: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 18:07:33 -0000 On Saturday, May 18, 2013 05:25:29 AM Andrew Sullivan wrote: > On Fri, May 17, 2013 at 01:35:21AM -0700, Murray S. Kucherawy wrote: > > Andrew's message drew the distinction between saying "necessary" and > > "MUST". There must be a nuance in there that I'm missing, because they're > > essentially synonymous to me; in fact, "-all" is the only way to achieve > > the stated goal for either party to the communication, so "MUST" seems > > proper to me, though either solution is also fine. Andrew, would you care > > to elaborate? > > In RFC 2119 we have this: "MUST This word, or the terms "REQUIRED" or > "SHALL", mean that the definition is an absolute requirement of the > specification." But the passage in question is not saying "you have > to do this". It's saying instead that, because of the way the > protocol works, the only way to achieve some end is to use a > particular facility. In other words, this is really informational > guidance on how to use the protocol, given the way it works. > > The original reason I was making the distinction, please remember, was > that the draft at the time was making a change from RECOMMENDED to > MUST, but it was doing so conditionally, thereby using the RFC 2119 > keywords more correctly (the 4408 use of RECOMMENDED in this case was > really more "we think this is a good idea"). In the context of the > new text, it seemed to me we didn't need a 2119 keyword at all, > because what was being described is a consequence of the way the > protocol operates, and not a requirement on conforming > implementations. > > I don't feel super strongly about this. I acknowledge SM's point, > however, that this change appears to be a substantive change in the > use of a 2119 keyword from 4408 to the new document, and there's a > potential question as to whether that is appropriate under our > charter. I think this argument could go either way, which is why I > suggested the formulation without the keyword. I'm not married to > this approach, however, and I think it will be possible to argue that > the change in this case is ok under our charter. It's just a > potential snag when we go to IETF LC. (Of course, compared to the war > we'll have over the TXT record, I suppose this'll be in the noise.) > > I hope that clears things up. Here's what I have now: SPF results can be used to make both positive (source is authorized) and negative (source is not authorized) determinations. If ADMDs choose to publish SPF records and want to support receivers making negative authorization determinations, it is necessary for them to publish records that end in "-all", or redirect to other records that do, otherwise, no definitive determination of authorization can be made. Potential issues and mitigations associated with negative determinations are discussed in . I think that addresses the question. It makes the point without and 2119 mustard, so if everyone is happy with it, I'm OK with it too. Scott K From spf2@kitterman.com Sat May 18 11:19:14 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F2D21F8D84 for ; Sat, 18 May 2013 11:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.703 X-Spam-Level: X-Spam-Status: No, score=-2.703 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOFI-D8eP2Z6 for ; Sat, 18 May 2013 11:19:09 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A900121F8F27 for ; Sat, 18 May 2013 11:18:57 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 691BA20E40FC; Sat, 18 May 2013 14:18:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368901137; bh=PNo3VKI11DuCAGH06wjq+fSlZZmW7nv4eKWJkglSaas=; h=From:To:Subject:Date:In-Reply-To:References:From; b=heXqYt/18c9G/zrGnuVQSwqRBNhzNMNEgq/WfXnAnJvT4tJ3Cc7ycb2T6N/6h1V3G fEs3t2NMQtRqP8YJuK3c0ekm3F4wQzVRr8i1mlTAtkUCfVST/sUFn4KAOp4kxaldef mbVgsz6NNsaHqO2+E48tQspuksfhbnI/aklrfjtk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 46BC920E401D; Sat, 18 May 2013 14:18:56 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 18 May 2013 14:18:56 -0400 Message-ID: <1970765.m0P0b2ejkL@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130518101418.0bbf6848@elandnews.com> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <4504827.dqlBOFqUut@scott-latitude-e6320> <6.2.5.6.2.20130518101418.0bbf6848@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Addressing reviews (was: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 18:19:14 -0000 On Saturday, May 18, 2013 10:35:03 AM S Moonesamy wrote: > Hi Scott, > > The Gen-ART review of draft-ietf-spfbis-4408bis-14 was posted on > April 29 ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg03647.html > ). There weren't any comments about that review. I inadvertently marked that one read, so I missed it. > The Applications Area directorate review was posted on April 29 ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg03633.html Same with that one. > ). There was a comment from Hector Santos ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg03653.html ). This message repeats discussions that we've already had and the chairs declared closed. I don't think a response is needed or appropriate. > The Security Directorate review of draft-ietf-spfbis-4408bis-14 was > posted on April 30 ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg03679.html > ). There was a comment from you ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg03723.html ) > and from John Levine ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg03726.html ). Based on that, I think that no changes in the document are needed. > Can you provide an estimate date of when the reviews mentioned above > will be addressed? I'm currently waiting for msk to send me some XML edits based on other comments. Since the two outstanding reviews will probably lead to a number of small changes throughout the draft, I'm planning on waiting until I get msk's XML back and can merge in his changes. Possibly today. As long as I get the XML update back from msk this weekend, I should be able to finish up the other two reviews on Monday. Scott K From hsantos@isdg.net Sat May 18 12:08:27 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598AE21F84CD for ; Sat, 18 May 2013 12:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.735 X-Spam-Level: X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8HTo89ULK1c for ; Sat, 18 May 2013 12:08:23 -0700 (PDT) Received: from mail.santronics.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C25AA21F8459 for ; Sat, 18 May 2013 12:08:22 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4769; t=1368904096; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=SxzUZ/7 xLQDzrzeZPymy04A8Csw=; b=HRB/r3zK35aucPDVOSIyJkfIcjynUbTdUkPjAna d6rS1Fo2BLMF0pmmqvQrRuUgqW3uyw3llNQtalq3jvgyq2smEytIcdQDtNQRK0pT Fsfb91YAkGkEo5P5+oyRW/4m/QRN4b/qTiXEfEwlN7A02BtxpyjRgicdNI+RYUDv 6i5A= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 18 May 2013 15:08:16 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3402795834.11065.3112; Sat, 18 May 2013 15:08:16 -0400 Message-ID: <5197D132.7030901@isdg.net> Date: Sat, 18 May 2013 15:06:26 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Scott Kitterman References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <20130518092529.GC16458@mx1.yitter.info> <5087983.gq5KGjyuFv@scott-latitude-e6320> In-Reply-To: <5087983.gq5KGjyuFv@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] MUST vs "necessary" (Re: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 19:08:27 -0000 I prefer the original MUST, there is a "legal" aspect to it, including "malpractice" for not doing something expected of you, or in legal terms "what the (SPF) expert in practice is expected do." If you (publisher) don't want harsh treatment, then it is just as equal to say "MUST NOT" use -ALL in the same way that you MUST use -ALL as it is the only way that would allow for a "legal" means to reject your mail. We keep weakening the concept of -ALL and I hope we can stop doing things that will get criticism. I'm sure the key cogs can "talk" they way out of it, but SPF is the only protocol that allows for strong indemnification with a -ALL policy. The rest is all junk in my book. Its the same idea Mr. Levine had regarding SSP when he broke it up into ADSP and basically just offer one policy - discard. The difference is that SPF caught on with a tremendous amount of high value domains (those that want and operate in strong exclusive network environments). They are not your ESPs, public service bureaus. The Mailing List, and even then the IETF.ORG has a -ALL policy. They are by far private corporate domains. Please respect the desire to use -ALL with strong expectations for SPF compliant receivers to either reject or separate SPF failed mail. Either way, its not their mail and they don't want you (prefer) to push it to users. It is now the Receiver responsibility if he ignores the -ALL policy. Thank you -- HLS On 5/18/2013 2:07 PM, Scott Kitterman wrote: > On Saturday, May 18, 2013 05:25:29 AM Andrew Sullivan wrote: >> On Fri, May 17, 2013 at 01:35:21AM -0700, Murray S. Kucherawy wrote: >>> Andrew's message drew the distinction between saying "necessary" and >>> "MUST". There must be a nuance in there that I'm missing, because they're >>> essentially synonymous to me; in fact, "-all" is the only way to achieve >>> the stated goal for either party to the communication, so "MUST" seems >>> proper to me, though either solution is also fine. Andrew, would you care >>> to elaborate? >> >> In RFC 2119 we have this: "MUST This word, or the terms "REQUIRED" or >> "SHALL", mean that the definition is an absolute requirement of the >> specification." But the passage in question is not saying "you have >> to do this". It's saying instead that, because of the way the >> protocol works, the only way to achieve some end is to use a >> particular facility. In other words, this is really informational >> guidance on how to use the protocol, given the way it works. >> >> The original reason I was making the distinction, please remember, was >> that the draft at the time was making a change from RECOMMENDED to >> MUST, but it was doing so conditionally, thereby using the RFC 2119 >> keywords more correctly (the 4408 use of RECOMMENDED in this case was >> really more "we think this is a good idea"). In the context of the >> new text, it seemed to me we didn't need a 2119 keyword at all, >> because what was being described is a consequence of the way the >> protocol operates, and not a requirement on conforming >> implementations. >> >> I don't feel super strongly about this. I acknowledge SM's point, >> however, that this change appears to be a substantive change in the >> use of a 2119 keyword from 4408 to the new document, and there's a >> potential question as to whether that is appropriate under our >> charter. I think this argument could go either way, which is why I >> suggested the formulation without the keyword. I'm not married to >> this approach, however, and I think it will be possible to argue that >> the change in this case is ok under our charter. It's just a >> potential snag when we go to IETF LC. (Of course, compared to the war >> we'll have over the TXT record, I suppose this'll be in the noise.) >> >> I hope that clears things up. > > Here's what I have now: > > SPF results can be used to make both positive (source is authorized) > and negative (source is not authorized) determinations. If ADMDs > choose to publish SPF records and want to support receivers making > negative authorization determinations, it is necessary for them to > publish records that end in "-all", or redirect to other records > that do, otherwise, no definitive determination of authorization can > be made. Potential issues and mitigations associated with negative > determinations are discussed in . > > I think that addresses the question. It makes the point without and 2119 > mustard, so if everyone is happy with it, I'm OK with it too. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From WebMaster@Commerco.Net Sat May 18 14:06:57 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCA021F8B64 for ; Sat, 18 May 2013 14:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pd1NG3+IDW-m for ; Sat, 18 May 2013 14:06:53 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id D6BF621F8B65 for ; Sat, 18 May 2013 14:06:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=HF//Hx0umGGJezqi3iBdClhefriHO079e8gq+aAb1BZ99VnmZ+6u/DUJSW7pmyBXxccFE57uwVTeZG5cB8KOw2d/BGNWTZ48L/aExMJnMPPR0hqWSkFqPXB82yy9rtiu5hck4vO80piY1GvQwdbxKlD517XEtgfXNncCtQnd/Ns= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.6) with ESMTP (EHLO [10.240.241.49]); Sat, 18 May 2013 21:06:50 +0000 Message-ID: <5197ED63.7060800@Commerco.Net> Date: Sat, 18 May 2013 15:06:43 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <20130518092529.GC16458@mx1.yitter.info> <5087983.gq5KGjyuFv@scott-latitude-e6320> <5197D132.7030901@isdg.net> In-Reply-To: <5197D132.7030901@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Cc: Hector Santos , Scott Kitterman , Andrew Sullivan Subject: Re: [spfbis] MUST vs "necessary" (Re: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 21:06:57 -0000 On 5/18/2013 1:06 PM, Hector Santos wrote: > I prefer the original MUST, there is a "legal" aspect to it, including > "malpractice" for not doing something expected of you, or in legal terms > "what the (SPF) expert in practice is expected do." > > If you (publisher) don't want harsh treatment, then it is just as equal > to say "MUST NOT" use -ALL in the same way that you MUST use -ALL as it > is the only way that would allow for a "legal" means to reject your mail. > > We keep weakening the concept of -ALL and I hope we can stop doing > things that will get criticism. I'm sure the key cogs can "talk" they > way out of it, but SPF is the only protocol that allows for strong > indemnification with a -ALL policy. The rest is all junk in my book. > Its the same idea Mr. Levine had regarding SSP when he broke it up > into ADSP and basically just offer one policy - discard. The > difference is that SPF caught on with a tremendous amount of high value > domains (those that want and operate in strong exclusive network > environments). They are not your ESPs, public service bureaus. The > Mailing List, and even then the IETF.ORG has a -ALL policy. They are by > far private corporate domains. Please respect the desire to use -ALL > with strong expectations for SPF compliant receivers to either reject or > separate SPF failed mail. Either way, its not their mail and they don't > want you (prefer) to push it to users. It is now the Receiver > responsibility if he ignores the -ALL policy. > > Thank you > > -- > HLS > +1 As I recall, the original spirit and intent of SPF was its being introduced as a simple vehicle to allow domain holders (now ADMDs) or publishers an easy way to announce to the known universe that email was being sent out from MTAs which were not under their control and were not authorized to send email using their domain names, as it damaged the reputation of their brands. It attempted to do this without breaking most existing SMTP implementations and environments, which were all SPF unaware at that time. Much of the impetus for SPF came from a growing practice in the late 1990s, originally tagged a "Joe Job" because one of an early well publicized example which happened to the individual who held Joes.com at the time. In essence, spammers were using the domain names of innocent domain holders, which would effectively ruin their domain's reputation. SPF was a pretty darn good solution to address that problem. SPF was and is not perfect, but it worked then and still works for many out there. The sacrosanct nature of the -All syntax in the minds of publishers is vitally important where it is published as "v=spf1 -all", as that specific syntax example offers a very clear announcement by the domain holder, that under no circumstances should their domain ever send out email. Ultimately, I believe that domain holders publishing this syntax would expect that unless the receiving MTA is SPF unaware (and after going on 10 years of SPF published domains, it would be interesting to know how large that number actually is), the email MUST never arrive at the addressed user's mail box... ever (not as junk, not as flagged). As SPF publishers, we can certainly not restrict local usage of data from the transaction, which can and will be used to the receivers' heart's desires for their analytic purposes, but if a receiver really does implement SPF, that message MUST never be delivered to the end user or it defeats the entire original goal of SPF preserving a domain name's reputation. An equally binary decision should be to never deliver messages to the end user when the sending MTA IP does not match an explicit set of machines that the publisher represents as being the only IPs from which the domain should be sending email. In these specific cases (and there are arguably quite a few more), anything less is just not a valid SPF implementation in the mind of this publisher... and I suspect the wide majority of those who chose to publish their SPF records to begin with. For those environments needing a better answer that SPF1 supplies, it probably won't come from this SPFbis, but rather some future SPF V3 where folks could have the luxury to define what they need after years of SPF1 experience, for example, a new ALL syntax (e.g., +ALL) which might meet the needs of some larger or unusual email environments. It would have to be a future version because that kind of addition would be beyond the scope and definition of the charter. And, rather remarkably, thanks to this SPFbis, there is even a fairly unused DNS RR called SPF in place which can even be immediately adopted and tasked for SPF V3! The future is very exciting! ;-) Alan M. > > On 5/18/2013 2:07 PM, Scott Kitterman wrote: >> On Saturday, May 18, 2013 05:25:29 AM Andrew Sullivan wrote: >>> On Fri, May 17, 2013 at 01:35:21AM -0700, Murray S. Kucherawy wrote: >>>> Andrew's message drew the distinction between saying "necessary" and >>>> "MUST". There must be a nuance in there that I'm missing, because >>>> they're >>>> essentially synonymous to me; in fact, "-all" is the only way to >>>> achieve >>>> the stated goal for either party to the communication, so "MUST" seems >>>> proper to me, though either solution is also fine. Andrew, would >>>> you care >>>> to elaborate? >>> >>> In RFC 2119 we have this: "MUST This word, or the terms "REQUIRED" or >>> "SHALL", mean that the definition is an absolute requirement of the >>> specification." But the passage in question is not saying "you have >>> to do this". It's saying instead that, because of the way the >>> protocol works, the only way to achieve some end is to use a >>> particular facility. In other words, this is really informational >>> guidance on how to use the protocol, given the way it works. >>> >>> The original reason I was making the distinction, please remember, was >>> that the draft at the time was making a change from RECOMMENDED to >>> MUST, but it was doing so conditionally, thereby using the RFC 2119 >>> keywords more correctly (the 4408 use of RECOMMENDED in this case was >>> really more "we think this is a good idea"). In the context of the >>> new text, it seemed to me we didn't need a 2119 keyword at all, >>> because what was being described is a consequence of the way the >>> protocol operates, and not a requirement on conforming >>> implementations. >>> >>> I don't feel super strongly about this. I acknowledge SM's point, >>> however, that this change appears to be a substantive change in the >>> use of a 2119 keyword from 4408 to the new document, and there's a >>> potential question as to whether that is appropriate under our >>> charter. I think this argument could go either way, which is why I >>> suggested the formulation without the keyword. I'm not married to >>> this approach, however, and I think it will be possible to argue that >>> the change in this case is ok under our charter. It's just a >>> potential snag when we go to IETF LC. (Of course, compared to the war >>> we'll have over the TXT record, I suppose this'll be in the noise.) >>> >>> I hope that clears things up. >> >> Here's what I have now: >> >> SPF results can be used to make both positive (source is >> authorized) >> and negative (source is not authorized) determinations. If >> ADMDs >> choose to publish SPF records and want to support receivers >> making >> negative authorization determinations, it is necessary for >> them to >> publish records that end in "-all", or redirect to other >> records >> that do, otherwise, no definitive determination of >> authorization can >> be made. Potential issues and mitigations associated with >> negative >> determinations are discussed in . >> >> I think that addresses the question. It makes the point without and 2119 >> mustard, so if everyone is happy with it, I'm OK with it too. >> >> Scott K >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis >> >> > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From sm@elandsys.com Sat May 18 15:28:54 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2321521F8B65 for ; Sat, 18 May 2013 15:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCmupYn-h0CZ for ; Sat, 18 May 2013 15:28:53 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F3221F8B64 for ; Sat, 18 May 2013 15:28:53 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.145.160]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4IMSbqf010367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 May 2013 15:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1368916129; bh=+YuvP3b2esa0Z1Sz/Zllj84ObpuCXHF10CuUGhF+t4I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YlgbqLvl2lvzcAu6hw+RfUs805Zof1r5WAPZp+EWxru8YZDCApDZ2lX7HmqAGQccb hR3M5jS5R2jv56Mm8MyfsHQV2OPfHVE8vh34J98zG6en5LPMUXx2rFIt8KzZ9crJXx zcZy0Nvjy8zvWDOGvh6wp3ZKTRd8xm7d/5EJvPAs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1368916129; i=@elandsys.com; bh=+YuvP3b2esa0Z1Sz/Zllj84ObpuCXHF10CuUGhF+t4I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vu7fhsCalHHTrMTfG86CIFm+1y1acvFNlwOGB4zRSeeQW6hKGWVhlUA4VQ95Xg4h2 SbWxaghVKlfYYGoZU1y/FOgL4XvdjAXKN3vVGN7+7asl71+o76evj4dLyUMERoI1gb IZfsPRuqKM73oKC4s1XpfzMEvk9IiJFAAu3UoYBQ= Message-Id: <6.2.5.6.2.20130518152104.0c95aa40@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 18 May 2013 15:25:50 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <1970765.m0P0b2ejkL@scott-latitude-e6320> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <4504827.dqlBOFqUut@scott-latitude-e6320> <6.2.5.6.2.20130518101418.0bbf6848@elandnews.com> <1970765.m0P0b2ejkL@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Addressing reviews (was: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 22:28:54 -0000 Hi Scott, At 11:18 18-05-2013, Scott Kitterman wrote: > > The Gen-ART review of draft-ietf-spfbis-4408bis-14 was posted on > > April 29 ( > > http://www.ietf.org/mail-archive/web/spfbis/current/msg03647.html > > ). There weren't any comments about that review. > >I inadvertently marked that one read, so I missed it. > > > The Applications Area directorate review was posted on April 29 ( > > http://www.ietf.org/mail-archive/web/spfbis/current/msg03633.html > >Same with that one. > > > ). There was a comment from Hector Santos ( > > http://www.ietf.org/mail-archive/web/spfbis/current/msg03653.html ). > >This message repeats discussions that we've already had and the chairs >declared closed. I don't think a response is needed or appropriate. > > > The Security Directorate review of draft-ietf-spfbis-4408bis-14 was > > posted on April 30 ( > > http://www.ietf.org/mail-archive/web/spfbis/current/msg03679.html > > ). There was a comment from you ( > > http://www.ietf.org/mail-archive/web/spfbis/current/msg03723.html ) > > and from John Levine ( > > http://www.ietf.org/mail-archive/web/spfbis/current/msg03726.html ). > >Based on that, I think that no changes in the document are needed. > > > Can you provide an estimate date of when the reviews mentioned above > > will be addressed? > >I'm currently waiting for msk to send me some XML edits based on other >comments. Since the two outstanding reviews will probably lead to a >number of >small changes throughout the draft, I'm planning on waiting until I get msk's >XML back and can merge in his changes. > >Possibly today. As long as I get the XML update back from msk this >weekend, I >should be able to finish up the other two reviews on Monday. Thanks. I'll forward the responses to the directorate/review team reviews once they are ready. Regards, S. Moonesamy From ajs@anvilwalrusden.com Sat May 18 18:19:26 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E357B21F8BBC for ; Sat, 18 May 2013 18:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bm8x369XpFh for ; Sat, 18 May 2013 18:19:12 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 59B4F21F8B98 for ; Sat, 18 May 2013 18:19:12 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id E8FEE8A031 for ; Sun, 19 May 2013 01:19:10 +0000 (UTC) Date: Sat, 18 May 2013 21:19:09 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130519011909.GG26709@mx1.yitter.info> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <20130518092529.GC16458@mx1.yitter.info> <5087983.gq5KGjyuFv@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5087983.gq5KGjyuFv@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] MUST vs "necessary" (Re: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 01:19:27 -0000 On Sat, May 18, 2013 at 02:07:26PM -0400, Scott Kitterman wrote: > Here's what I have now: [elided] I'm completely comfortable with that. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Sat May 18 18:27:05 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042F921F8BC5 for ; Sat, 18 May 2013 18:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4oxCivj52QZ for ; Sat, 18 May 2013 18:26:59 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 3905A21F8BBC for ; Sat, 18 May 2013 18:26:59 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 883E38A031 for ; Sun, 19 May 2013 01:26:58 +0000 (UTC) Date: Sat, 18 May 2013 21:27:00 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130519012700.GH26709@mx1.yitter.info> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <20130518092529.GC16458@mx1.yitter.info> <5087983.gq5KGjyuFv@scott-latitude-e6320> <5197D132.7030901@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5197D132.7030901@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] MUST vs "necessary" (Re: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 01:27:05 -0000 No hat, not even a straw one (it's Victoria Day weekend here). On Sat, May 18, 2013 at 03:06:26PM -0400, Hector Santos wrote: > I prefer the original MUST, there is a "legal" aspect to it, No, there just isn't such an aspect, scare quotes or no. We are not legislators of the Internet. We are people who recommend things that people can do in order to maximise interoperability. The passage in question is talking about what happens under various conditions, _and not_ what you have to do in order that the protocol works. There's a subtle but very important difference between, "If you don't do this, the protocol doesn't work," and, "If you want to achieve $X, then you need to do $Y." MUST in the 2119 sense means the former of those two, and that's why I think in this case it's ok to change the text as Scott has suggested. In particular, > If you (publisher) don't want harsh treatment, then it is just as > equal to say "MUST NOT" _this_ is simply not a 2119 meaning of MUST, in my opinion. > We keep weakening the concept of -ALL and I hope we can stop doing > things that will get criticism. I'm sure the key cogs can "talk" > they way out of it, but SPF is the only protocol that allows for > strong indemnification with a -ALL policy. There is no weakening here. The text is plain. It's just not prescriptive, as is appropriate in a protocol document. If you wish to write a best practices document for operators, that would be a more appropriate place to put your concerns here. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From superuser@gmail.com Sat May 18 18:38:13 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC17A21F87C5 for ; Sat, 18 May 2013 18:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DT0J70xcn1o for ; Sat, 18 May 2013 18:38:13 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 466F521F871C for ; Sat, 18 May 2013 18:38:13 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id p57so2870609wes.32 for ; Sat, 18 May 2013 18:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sbyyPPGAW6fKpMRo29GetQWvRVYebNC3wyp7xPJ4Y2Y=; b=ZbzAsmgBUQDNfD6Kz+AAjrERrhT76bfRcHJdFadscfKY+hZ+YyjFiaVKr8IxAq939b W8c4RCSi/aUfvNb1r0VTANFOVGudzkTwKXumZK2Ls6ivjAC4tRJZa6lyM3hUmakXIbNm By7Kxc0aSrXUmfNVgaL/tv8iluzerVDqLEet5p8C9PnfFCJtgIo6A2zPrO3GSFu2Qxhg PlXL46d0VCeGK67LjpcLbnNoVDM+uvH0uPVwsDgt1wMKAO/H5TasScOyMnDsci4nghe2 VyTXGOWQXiMNA7XUDhiTKJY2ZooJGibJPgw21P5rqfuiIEajfXD3NPdDN1pHEDKGtWX7 VW4Q== MIME-Version: 1.0 X-Received: by 10.180.37.133 with SMTP id y5mr4125876wij.20.1368927492417; Sat, 18 May 2013 18:38:12 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Sat, 18 May 2013 18:38:12 -0700 (PDT) In-Reply-To: <20130519011909.GG26709@mx1.yitter.info> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <20130518092529.GC16458@mx1.yitter.info> <5087983.gq5KGjyuFv@scott-latitude-e6320> <20130519011909.GG26709@mx1.yitter.info> Date: Sat, 18 May 2013 18:38:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=e89a8f50335ae8b0d404dd0844d5 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] MUST vs "necessary" (Re: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 01:38:14 -0000 --e89a8f50335ae8b0d404dd0844d5 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 18, 2013 at 6:19 PM, Andrew Sullivan wrote: > On Sat, May 18, 2013 at 02:07:26PM -0400, Scott Kitterman wrote: > > Here's what I have now: > > [elided] > > I'm completely comfortable with that. > +1. -MSK --e89a8f50335ae8b0d404dd0844d5 Content-Type: text/html; charset=ISO-8859-1
On Sat, May 18, 2013 at 6:19 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Sat, May 18, 2013 at 02:07:26PM -0400, Scott Kitterman wrote:
> Here's what I have now:

[elided]

I'm completely comfortable with that.

+1.

-MSK
--e89a8f50335ae8b0d404dd0844d5-- From superuser@gmail.com Sat May 18 18:49:49 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3B521F8CF4 for ; Sat, 18 May 2013 18:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAlTMRj4OkTu for ; Sat, 18 May 2013 18:49:49 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 01D6221F87E0 for ; Sat, 18 May 2013 18:49:48 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hq7so1210920wib.16 for ; Sat, 18 May 2013 18:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8DK/bZ/WPVinqSmxjXborll0YFw6ghF8BvIVk4e+ySo=; b=yXSehflyhpXjgUG42BJIAOwjGsOX9gC01nCQHe9uY322BrkTFQsUXmsorNpI3a7U9q 0thfI/n7AoMhwYC+6yLbQqhBhPZnfN+sXVfYB1s4KKu7C06NLCsdu33TZtXhBaPsELjk qVSH4336yOUmGTAULzgU2hW/1gxPPzUOpUYwZxTXD1u+Oc/fbzkNlNmUVFLFqgiud8c0 T0X4jaUVv9s2jKAi2xtw7mTu70x9Il92lu7K9C+cBSXYZ97prRqS9reUTGrrIG9zt1La ksNTC07/O0GFsex8jnNOGiUKWkhZV1HADus848tvJZEX4cZew9s5XY6PGRXjPgP3fgjl +s+A== MIME-Version: 1.0 X-Received: by 10.180.37.133 with SMTP id y5mr4147696wij.20.1368928188163; Sat, 18 May 2013 18:49:48 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Sat, 18 May 2013 18:49:47 -0700 (PDT) In-Reply-To: <5197ED63.7060800@Commerco.Net> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <20130518092529.GC16458@mx1.yitter.info> <5087983.gq5KGjyuFv@scott-latitude-e6320> <5197D132.7030901@isdg.net> <5197ED63.7060800@Commerco.Net> Date: Sat, 18 May 2013 18:49:47 -0700 Message-ID: From: "Murray S. Kucherawy" To: Commerco WebMaster Content-Type: multipart/alternative; boundary=e89a8f50335a60ee8104dd086e58 Cc: "spfbis@ietf.org" , Hector Santos , Scott Kitterman , Andrew Sullivan Subject: Re: [spfbis] MUST vs "necessary" (Re: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 01:49:49 -0000 --e89a8f50335a60ee8104dd086e58 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 18, 2013 at 2:06 PM, Commerco WebMaster wrote: > [...] > > In these specific cases (and there are arguably quite a few more), > anything less is just not a valid SPF implementation in the mind of this > publisher... and I suspect the wide majority of those who chose to publish > their SPF records to begin with. > > Hi Alan, I'm not clear on how the language change under discussion here takes any of that away. It is still the case that, under the stated conditions, SPF returns a "fail" and the receiver is then free to act on that as it sees fit. "MUST" has special meaning to us in the IETF. As I understand it, "MUST use '-all'" essentially means the protocol will break if you don't do that. In reality, the protocol works just fine if you don't do that; you just aren't going to get the result you want. The new text correctly reflects this subtle difference. There is no watering down of anything here; it's just a correction in the way we use a few special words when writing RFCs. Personally, I think the claim that any part of this or any other protocol has "legal" implications is specious unless it's backed up by legislation or legal precedent, which isn't the case here. -MSK --e89a8f50335a60ee8104dd086e58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, May 18, 2013 at 2:06 PM, Commerco WebMaster <WebMaster@commerco.net> wrote:
[...]

In these specific cases (and there are arguably quite a few more), anything= less is just not a valid SPF implementation in the mind of this publisher.= .. and I suspect the wide majority of those who chose to publish their SPF = records to begin with.


Hi Alan,

I'm not clear on h= ow the language change under discussion here takes any of that away.=A0 It = is still the case that, under the stated conditions, SPF returns a "fa= il" and the receiver is then free to act on that as it sees fit.

"MUST" has special meaning to us in the IETF.=A0 A= s I understand it, "MUST use '-all'" essentially means th= e protocol will break if you don't do that.=A0 In reality, the protocol= works just fine if you don't do that; you just aren't going to get= the result you want.=A0 The new text correctly reflects this subtle differ= ence.

There is no watering down of anything here; it's just a = correction in the way we use a few special words when writing RFCs.

=
Personally, I think the claim that any part of this or any other= protocol has "legal" implications is specious unless it's ba= cked up by legislation or legal precedent, which isn't the case here.

-MSK
--e89a8f50335a60ee8104dd086e58-- From superuser@gmail.com Sat May 18 18:50:52 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CB721F8415 for ; Sat, 18 May 2013 18:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwfFqypzoDjJ for ; Sat, 18 May 2013 18:50:51 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 755E221F83EF for ; Sat, 18 May 2013 18:50:51 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id p57so2849313wes.4 for ; Sat, 18 May 2013 18:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lQ5UPQ6/0RsbBAdoulMTt34Da0gafBXRh9OBrMYNTkE=; b=Iv7C+HYsSaNcSpfQTjKqp5kkQXPRjV+pXw7hyQsbbAn928uCgTDlVvTvJiKTmrkt4H KM89zOePYTwURAKbL9zE6cCKg8+c1kbzA6LMP+4CmsOMUjt8azurFKsiOYtB1Z1gXF90 GYJQSCC9s4TW4BYeGYWVGumURknQRwtpk19bAFXZKuGpHBGhr0MDvss6wln6LhqpcsK+ 0EAI5eFwUA0pO9N35Ho7nJIH04N5Rcyl3FMuWSwqb3JEBs1GGJZSutRtchqkbMjaGVxW UQR9w2bh+uu19BYpjDaS6WHxgv2DEmMPf0UfWXX59RhHcqm35n2LVWSvBCo0ZJYItJ/Y 0lNQ== MIME-Version: 1.0 X-Received: by 10.180.79.69 with SMTP id h5mr4163224wix.14.1368928250696; Sat, 18 May 2013 18:50:50 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Sat, 18 May 2013 18:50:50 -0700 (PDT) In-Reply-To: <1970765.m0P0b2ejkL@scott-latitude-e6320> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <4504827.dqlBOFqUut@scott-latitude-e6320> <6.2.5.6.2.20130518101418.0bbf6848@elandnews.com> <1970765.m0P0b2ejkL@scott-latitude-e6320> Date: Sat, 18 May 2013 18:50:50 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d043c062e1b1a4e04dd08720b Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Addressing reviews (was: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 01:50:52 -0000 --f46d043c062e1b1a4e04dd08720b Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 18, 2013 at 11:18 AM, Scott Kitterman wrote: > I'm currently waiting for msk to send me some XML edits based on other > comments. Since the two outstanding reviews will probably lead to a > number of > small changes throughout the draft, I'm planning on waiting until I get > msk's > XML back and can merge in his changes. > > Possibly today. As long as I get the XML update back from msk this > weekend, I > should be able to finish up the other two reviews on Monday. > > I do have it, and I plan to attack it this evening. -MSK --f46d043c062e1b1a4e04dd08720b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, May 18, 2013 at 11:18 AM, Scott Kitterman <spf2@= kitterman.com> wrote:
I'm currently waiting for msk to send me= some XML edits based on other
comments. =A0Since the two outstanding reviews will probably lead to a numb= er of
small changes throughout the draft, I'm planning on waiting until I get= msk's
XML back and can merge in his changes.

Possibly today. =A0As long as I get the XML update back from msk this weeke= nd, I
should be able to finish up the other two reviews on Monday.


I do have it, and I plan to attack it = this evening.

-MSK

--f46d043c062e1b1a4e04dd08720b-- From johnl@iecc.com Sat May 18 21:44:43 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4197D21F8AD5 for ; Sat, 18 May 2013 21:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.87 X-Spam-Level: X-Spam-Status: No, score=-110.87 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ardehObD7lAM for ; Sat, 18 May 2013 21:44:39 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5250621F8AA8 for ; Sat, 18 May 2013 21:44:36 -0700 (PDT) Received: (qmail 54554 invoked from network); 19 May 2013 04:44:35 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 May 2013 04:44:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=519858b3.xn--btvx9d.k1305; i=johnl@user.iecc.com; bh=f+CTeC/BwlWeLyM9Fonc8ZRnpg0nCdZJzpKDF0VS18Q=; b=Wt3bK7AYsjTsY4sg+K1bqJRjxyqstoXm0GSz4OZ2JftveX0dpm2OZACXtTNqBxrem8EYqnCPzIjhl2Z+WRLjdQlRvZIbNc0LT+RB9DsZIATJag66bJ7Eut8eU78lvifqO4mROfUXmCjTWkMKxHqjxFPhtWtxOLmewXXAysZjYkA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=519858b3.xn--btvx9d.k1305; olt=johnl@user.iecc.com; bh=f+CTeC/BwlWeLyM9Fonc8ZRnpg0nCdZJzpKDF0VS18Q=; b=Sk+3X/Kc/9bAgKqg7yg1eDr7vWQo25rfkwUt1crg2nNQsqM6PHwrLlqB7NouXviIA/ugfZwuMloC2+azwzU6ELjpVaeHjuIhFGONvUkwFYNHWQZhBukAvKhbAIhmYaWNAbGZ8LprPdEOHNm44zizA3n99O8X6sdtTccDZmkLNhw= Date: 19 May 2013 04:44:13 -0000 Message-ID: <20130519044413.75809.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <20130518095510.GF16458@mx1.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: ajs@anvilwalrusden.com Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 04:44:43 -0000 >But on reflection, there remains the question of whether you're >allowed to split across TXT records. This came up on another list, >and it's a good point. This part of RFC 4408 seems pretty clear to me, and the language is unchanged in 4408bis other than the section number: 3.1.2. Multiple DNS Records A domain name MUST NOT have multiple records that would cause an authorization check to select more than one record. See Section 4.5 for the selection rules. Since RRSETs are unordered, there'd be no way to tell in what order the RRs of a split record were supposed to be assembled, or even which RRs were supposed to be part of the SPF record and which weren't. Since there is no length limit on a TXT record short of the 64K limit on an RRSET, and multiple single-string records take up more space than one multi-string record, there's no operational reason to split. For anyone with a reasonable understanding of SPF and the DNS, I'd think it would be obvious that splitting across multiple TXT records wouldn't work. When I read the message I think you're referring to, the person seemed not to understand the difference between a TXT record with multiple strings and multiple TXT records. Given his background that was kind of surprising, but that's sure what it looked like. Scott knows better than I do, but I am not aware of anyone who's actually tried to implement SPF being confused about this. From WebMaster@Commerco.Net Sat May 18 22:25:42 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A80721F8A0B for ; Sat, 18 May 2013 22:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOyBAtBUb8+b for ; Sat, 18 May 2013 22:25:37 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4743421F8A00 for ; Sat, 18 May 2013 22:25:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=O0a4WZcblVvgL93MQtdeabNtIUWh/XMJR8G4GqiELEHT4tgldasrHcKSYV7QDk5PcUGz1lrFEgboioFmBXBS9P6jgxGlViRnIQ0a0fPoudgRlIQ56xTcq2obcjAjHnd7hlDAC4GdNwByCQITu/xxiKmij6gs90Tl+6x86tkthvU= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.6) with ESMTP (EHLO [10.240.241.49]); Sun, 19 May 2013 05:25:32 +0000 Message-ID: <51986245.7090803@Commerco.Net> Date: Sat, 18 May 2013 23:25:25 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <20130518092529.GC16458@mx1.yitter.info> <5087983.gq5KGjyuFv@scott-latitude-e6320> <5197D132.7030901@isdg.net> <5197ED63.7060800@Commerco.Net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Cc: "spfbis@ietf.org" , Hector Santos , Scott Kitterman , Andrew Sullivan Subject: Re: [spfbis] MUST vs "necessary" (Re: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 05:25:42 -0000 Hi Murray, I'm not trying to be disagreeable. I'm simply trying to memorialize some of the thinking that took place in the earlier days of SPF as regards what publishers were told and why SPF really took off early as a domain name reputation tool for publishers in response to Hector's comment. On 5/18/2013 7:49 PM, Murray S. Kucherawy wrote: > On Sat, May 18, 2013 at 2:06 PM, Commerco WebMaster > > wrote: > > [...] > > In these specific cases (and there are arguably quite a few more), > anything less is just not a valid SPF implementation in the mind of > this publisher... and I suspect the wide majority of those who chose > to publish their SPF records to begin with. > > > Hi Alan, > > I'm not clear on how the language change under discussion here takes any > of that away. It is still the case that, under the stated conditions, > SPF returns a "fail" and the receiver is then free to act on that as it > sees fit. Perhaps, as a publisher, I was being oversensitive to Hector's remarks, which did ring a cord. > > "MUST" has special meaning to us in the IETF. As I understand it, "MUST > use '-all'" essentially means the protocol will break if you don't do > that. In reality, the protocol works just fine if you don't do that; > you just aren't going to get the result you want. The new text > correctly reflects this subtle difference. I think that MUST has a special meaning to anyone defining or implementing a specification, as in you MUST do this or things go badly (as in break). SPF was originally tasked and designed not to break SMTP, which would have been a show stopper for any publisher looking at implementing it. Thus, pretty much anything done with SPF must be flexible enough that it would not disturb the operation of a pure SMTP MTA. I don't think many would argue that the way in which options for "all" was created in SPF1 has proven too limited in cases for some larger mail services and other limited cases I won't rehash here. I get that too. My ultimate point is the best fix for those issues may well be better served in a future SPF version, because the better fix for this "-all" bone of contention may be to add additional "all" syntax to SPF1 addressing some of its current limitations and shortcomings, which I understand is beyond the scope of the SPFbis. > > There is no watering down of anything here; it's just a correction in > the way we use a few special words when writing RFCs. > Very well then. > Personally, I think the claim that any part of this or any other > protocol has "legal" implications is specious unless it's backed up by > legislation or legal precedent, which isn't the case here. > > -MSK > I also agree that there is certainly no actual "legal" implication in using the word MUST in a specification. I'm not sure Hector was thinking legal as in pertaining to the legal system, thus his quotation marks around "legal". I suspect that it was more like something in programming where words of art like "illegal bounds violation" or "legal operation" are used to describe bad or good events which happen in our world of computing and networking. At least that is the way I took his statements. "legal" arguably was an unfortunate choice by Hector, but I think the spirit of what I inferred as his intent may reflect concerns of some of the publishers about the process and the end result. All that said, as long as publishers' domain reputations are protected and publishers don't end up getting inappropriate accusative phone calls from angry users about how a publisher spammed them (when the domain being accused of such events has a long term policy claim via an SPF TXT record not to send email at all), because the user's MTA should not have delivered the email to the user in the first place, then all is well. And again, I understand that could happen easily with an MTA that is SPF unaware, but with an SPF aware implementation, that really should never be allowed to occur. Alan M. From johnl@iecc.com Sat May 18 22:57:27 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8414521F899E for ; Sat, 18 May 2013 22:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.952 X-Spam-Level: X-Spam-Status: No, score=-110.952 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVlzEzGVTH3u for ; Sat, 18 May 2013 22:57:23 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4CADC21F8A4E for ; Sat, 18 May 2013 22:57:23 -0700 (PDT) Received: (qmail 64156 invoked from network); 19 May 2013 05:57:22 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 May 2013 05:57:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=519869c2.xn--30v786c.k1305; i=johnl@user.iecc.com; bh=0oPteQw9JeXGO+wnggffQHwtuTH9EXTJWorSCCivSdg=; b=TOrE56rWvFES1vY1Eny31+F7bWlBd2Q1UZ5BQus+CzowmNLW0bX5B4Q6NKVIw66qHtJnBf3uEVBpzmdxeyhYOwb4FztkTxiH+DfhTLwLhuQ1k2pfn5q93gy++3boytq/y/e/Lr5vHOeA6aixFB6TGM0JIN8mbG09Lqntk0FE6Ck= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=519869c2.xn--30v786c.k1305; olt=johnl@user.iecc.com; bh=0oPteQw9JeXGO+wnggffQHwtuTH9EXTJWorSCCivSdg=; b=cRUNxeqojk9phELN4FFFiOjUA883SFD+6cJmeXRX73+B+fE+5NH6jibBHTRykVTIjo3l0IKYUq3fv0WKWcJsGOIvUJ3ESJBP1oTm5Zc4yTqyKpiuCPEwSAUQ4keOdpHDm+ssFxSD4ckc4Gi1OM6bXCiCPRIq3r8WPKO1YCPZQxs= Date: 19 May 2013 05:57:00 -0000 Message-ID: <20130519055700.76224.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: superuser@gmail.com Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 05:57:27 -0000 >The predecessor to Sender ID was Caller ID, and it stored the policy in XML >which most of the time didn't fit in a single TXT RR, so they came up with >a labeling scheme to indicate the order in which multiple TXT RRs were to >be reassembled. It seemed to be reliable. Totally unnecessary here though. Well, kind of. They put a 2K limit on the length of each TXT record, allegedly because longer records broke BIND. (This was in 2004, maybe they did.) The records were under a distinguished name _ep.whatever and if there was more than one, each started with a two-octet sequence number. I think we can fairly characterize it as a crock. Disregarding for a moment the fundamental ill-advisedness of storing big blobs of XML in the DNS, if you actually wanted to do that, the DNS standards have always been quite clear that you can have very long TXT records, and that a server and client fall back to TCP to exchange them if they're too big for a UDP packet. But anyway, SPF has always been one record. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From hsantos@isdg.net Sun May 19 04:29:12 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5437621F855A for ; Sun, 19 May 2013 04:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.706 X-Spam-Level: X-Spam-Status: No, score=-101.706 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjUG55y05iYa for ; Sun, 19 May 2013 04:29:07 -0700 (PDT) Received: from mail.catinthebox.net (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7E91921F8B04 for ; Sun, 19 May 2013 04:29:04 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2640; t=1368962941; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=LNUVNoY wKz0ogO0lpGzlI4sAocI=; b=WtPM8MV6d5O638BZj+7ED8LxjHbNdUNlZYixRqg xC3NMGMMW+NSPWr/g+gJbUVF+m6YtfPQQPKsdsz2fR4j4IMs4z1MMG8cOMwndMPt AS3aFc6vkP+Q1tl9MiQMwle36mKDp3z1bR4a5nN0t0D9Xn12+sG4d6JJFvoM87qC /09E= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 19 May 2013 07:29:01 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3461640097.12499.1688; Sun, 19 May 2013 07:29:01 -0400 Message-ID: <5198B70E.6060201@isdg.net> Date: Sun, 19 May 2013 07:27:10 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <20130518092529.GC16458@mx1.yitter.info> <5087983.gq5KGjyuFv@scott-latitude-e6320> <5197D132.7030901@isdg.net> <20130519012700.GH26709@mx1.yitter.info> In-Reply-To: <20130519012700.GH26709@mx1.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] MUST vs "necessary" (Re: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 11:29:12 -0000 Andrew, its really not hard. The term is used in reference to what any considerate and competent product manager would or better said, expected to consider - product liability issues, and this certainly will fall under it. Run it by your chief council. Its called neglect if you don't want to follow want is considered technically the expected of what will be "Internet Standard" practice. Of course, nothing really matters if there is no harm, but push come to shove, it is certainly useful legal material if such a quote, harm, unquote, case ever comes up. A protocol change (and that is what it is) of MUST to necessary, is not the same thing. It weakens the protocol requirement to use -ALL as it was intended to be use if a publisher wishes a strong treatment to reject/separate by the receiver. The BIS document went into (over) verbose length to stipulate this design requirement especially as a security concern - albeit weakly stated. Thank you -- HLS On 5/18/2013 9:27 PM, Andrew Sullivan wrote: > No hat, not even a straw one (it's Victoria Day weekend here). > > On Sat, May 18, 2013 at 03:06:26PM -0400, Hector Santos wrote: >> I prefer the original MUST, there is a "legal" aspect to it, > > No, there just isn't such an aspect, scare quotes or no. We are not > legislators of the Internet. We are people who recommend things that > people can do in order to maximise interoperability. The passage in > question is talking about what happens under various conditions, _and > not_ what you have to do in order that the protocol works. There's a > subtle but very important difference between, "If you don't do this, > the protocol doesn't work," and, "If you want to achieve $X, then you > need to do $Y." > > MUST in the 2119 sense means the former of those two, and that's why I > think in this case it's ok to change the text as Scott has suggested. > In particular, > >> If you (publisher) don't want harsh treatment, then it is just as >> equal to say "MUST NOT" > > _this_ is simply not a 2119 meaning of MUST, in my opinion. > >> We keep weakening the concept of -ALL and I hope we can stop doing >> things that will get criticism. I'm sure the key cogs can "talk" >> they way out of it, but SPF is the only protocol that allows for >> strong indemnification with a -ALL policy. > > There is no weakening here. The text is plain. It's just not > prescriptive, as is appropriate in a protocol document. If you wish > to write a best practices document for operators, that would be a more > appropriate place to put your concerns here. > > Best, > > A > From hsantos@isdg.net Sun May 19 06:22:50 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F8421F8756 for ; Sun, 19 May 2013 06:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.153 X-Spam-Level: X-Spam-Status: No, score=-102.153 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggaO280oIC92 for ; Sun, 19 May 2013 06:22:45 -0700 (PDT) Received: from mail.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 838D621F8721 for ; Sun, 19 May 2013 06:22:44 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3912; t=1368969762; h=Received:Received: Message-ID:Date:From:To:Subject:Organization:List-ID; bh=adgyLCD Wfd9tneYXknLtNlFJ3Do=; b=mBWjGR/o/jagyIkquk6irWpCtYY1txjbEkgC9E3 vdWT2us6N7qaVoriPf/iJEt0UUjzQwgcxmz3vxV4ihxGycygRsHTHIYztUChYxO7 L4mWmgXiLgDWtQX6XWHO1nQs49pnciXjrnc2FQJw8Uy0W3eic4QD8DpKKzlx2P6k QdNA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 19 May 2013 09:22:42 -0400 Received: from [208.247.131.8] ([208.247.131.8]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3468461366.12499.5508; Sun, 19 May 2013 09:22:42 -0400 Message-ID: <5198D1B3.7080001@isdg.net> Date: Sun, 19 May 2013 09:20:51 -0400 From: Hector Santos User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <20130518092529.GC16458@mx1.yitter.info> <5087983.gq5KGjyuFv@scott-latitude-e6320> <5197D132.7030901@isdg.net> <5197ED63.7060800@Commerco.Net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , Commerco WebMaster , Scott Kitterman , Andrew Sullivan Subject: Re: [spfbis] MUST vs "necessary" (Re: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 13:22:50 -0000 On 5/18/2013 9:49 PM, Murray S. Kucherawy wrote: > Hi Alan, > > I'm not clear on how the language change under discussion here takes any of > that away. It is still the case that, under the stated conditions, SPF > returns a "fail" and the receiver is then free to act on that as it sees > fit. > > "MUST" has special meaning to us in the IETF. As I understand it, "MUST > use '-all'" essentially means the protocol will break if you don't do > that. Yes, that is exactly what it means. From both ends, if a publisher wants immediate treatment by the receiver for highly detectable spoofed transactions, then he MUST use -ALL, otherwise, historically, mailer designers (of all networks), will not use immediate transport level reject, block, quarantine, or do whatever to the message that does not, "out of the box" requires the operator intervention, i.e. a heuristic or rule or trust concept. The trust is *with* the protocol. In other words, the SMTP package takes control. Only -ALL can do this. Consider it the "Built-in" special handling, that does not require any other protocol. Keep in mind that mail receivers (MDAs, not users) also have a big stake in this. It lowers the processing abuse taken on by the receiver for all the spoofing going on. The entire network feels it, had felt it in 2003 which highlighted the urgency, i.e. MARID. So receivers are also telling publishers you MUST use -ALL if you want the receivers to immediately classified the message for negative, rejectable, no need to report, built-in SPF support operations. I would also like to politely suggest, that you (Murray) is 100% perfectly correct in having the design philosophy and synergism to couple concepts such as DMARC as the means to expose "handling" ideas. Its the same idea proposed in 2006 with the DSAP (DKIM Signature Authorization Protocol) [1] where it included handling and reporting features as well. So on the one hand, we can refer to additional handling protocols or we can keep that ended for all the SPF policies except for, as long term SPF advocates stated, the one special case -ALL policy which gives publishers and receivers that power to filter at the SMTP transaction level. Of course, we can make it optional, and that could be the *new* thing in all honesty, for implementers. A common translation we would program for operators: [X] Reject SPF -ALL failed message [X] Move to User's SPAM box Of course, I understand where there may be operation, like an ESP, where it is done only with a separation by default and with no option to reject. So one side rejects with no option to separate, and another aside separates with no option to reject except to allow the user to trash his spam box. Finally, consider that not every mail system needs or even offers a SPAM BOX separation, especially true with the early mail systems. So called "Spam/Junk" folders came much later in the game. I understand your POV, like many of my sysop customers have, that SPAM BOXES and online views of such concepts is a good feature to have in mail products. But from a protocol standpoint, this "folder view" design can not be enforced. > There is no watering down of anything here; it's just a correction in the > way we use a few special words when writing RFCs. It adds confusion for the -ALL SPF "built-in" special handling case. > Personally, I think the claim that any part of this or any other protocol > has "legal" implications is specious unless it's backed up by legislation > or legal precedent, which isn't the case here. Its a product design methodology, that does include social engineering concepts (not of the Facebook "social" kind), but infrastructure per se. Thank you -- HLS [1] DKIM Signature Authorization Protocol (DSAP) http://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-16 From GK@ninebynine.org Sun May 19 05:20:12 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A0821F89E2; Sun, 19 May 2013 05:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJWcRvfJ+E1b; Sun, 19 May 2013 05:20:06 -0700 (PDT) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD8221F8617; Sun, 19 May 2013 05:20:06 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Ue2ao-0004Ap-gq; Sun, 19 May 2013 13:20:02 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Ue2an-0004rr-9J; Sun, 19 May 2013 13:20:02 +0100 Message-ID: <5198C178.9060908@ninebynine.org> Date: Sun, 19 May 2013 13:11:36 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20130423150556.0c2c07e8@elandnews.com> In-Reply-To: <6.2.5.6.2.20130423150556.0c2c07e8@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 X-Mailman-Approved-At: Sun, 19 May 2013 07:08:00 -0700 Cc: spfbis@ietf.org, ietf-message-headers@ietf.org Subject: Re: [spfbis] Received-SPF header X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 12:20:13 -0000 Hi, Apologies for my slow response - I've been partially off-net for a few weeks. On casual inspection, the registration template and related description look OK to me. As a minor personal nit, and in no way a blocker, it might be nice to cross reference the section number in which the header field is described from the registration template (the document being quite long). #g -- On 23/04/2013 23:13, S Moonesamy wrote: > Hi Graham, > > As a FYI, draft-ietf-spfbis-4408bis intends to register the "Received-SPF:" > header field in the Permanent Message Header Field Registry. > > Regards, > S. Moonesamy (as document shepherd) > From SRS0=2Ci6g=PF==stuart@gathman.org Sun May 19 20:20:04 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6155921F8F27 for ; Sun, 19 May 2013 20:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLmn95DnvxyK for ; Sun, 19 May 2013 20:20:02 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0FC21F855F for ; Sun, 19 May 2013 20:20:01 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1369020028; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=4EB3XI6HWVyscUNtraaXsWw5GSQ/PfA+yXAD+gIKtxI=; b=UvVpZ7KZer1So8epXtSiTRh+cmmIZ61AN9Iic3iilintEmC7nsRDVNhFXHne+0eC4FU8Tj El6sM4KyBkrnj9NGO8KCDSn8oRCva6LRdF8BL8Nbch81m3iVFUb5cna8RaOaqYBJZOFaNVru wJY6If+ywugAMiLPqSwtJGd7TvzC8= Received: from melissa.gathman.org (ip72-205-26-231.dc.dc.cox.net [72.205.26.231]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r4K3KSD4013875 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 19 May 2013 23:20:28 -0400 Message-ID: <51999660.6070105@gathman.org> Date: Sun, 19 May 2013 23:20:00 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <20130424180512.GN16817@mx1.yitter.info> <1431349.C0e3qG0mtd@scott-latitude-e6320> <517ABBDA.2060201@dcrocker.net> In-Reply-To: <517ABBDA.2060201@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 03:21:31 -0000 New observation: claims that spf libraries didn't support SPF RR are likely correct. Long ago, Nostradamus foresaw that on 04/26/2013 01:39 PM, Dave Crocker would write: > > Even then, retention is a bad idea. There is no current basis for > seeing any likelihood of utility for the RR. None. After seeing a complaint that spf libraries didn't support SPF RR, and protesting that pyspf did, I went and checked, and lo and behold, SPF RRs were disabled in pyspf at some point - and I hadn't noticed. I turned them back on, and discovered that we were missing important SPF policies for business partners due to not checking SPF RRs! I have not yet run into any of the braindead servers (that timeout on unknown RRs) that caused the initial difficulties with using the SPF RR. Interestingly, I find that all the (rare) SPF RRs in the field I've encountered so far publish *only* SPF RR. Probably a wise strategy. The "publish both" recommendation in rfc4408 is problematic. From ajs@anvilwalrusden.com Sun May 19 20:53:38 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC5221F84DF for ; Sun, 19 May 2013 20:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8es7uTVIyCX for ; Sun, 19 May 2013 20:53:32 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 958B421F84D4 for ; Sun, 19 May 2013 20:53:32 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 9EA918A031 for ; Mon, 20 May 2013 03:53:31 +0000 (UTC) Date: Sun, 19 May 2013 23:53:30 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130520035329.GG33927@mx1.yitter.info> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <20130424180512.GN16817@mx1.yitter.info> <1431349.C0e3qG0mtd@scott-latitude-e6320> <517ABBDA.2060201@dcrocker.net> <51999660.6070105@gathman.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51999660.6070105@gathman.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 03:53:39 -0000 Chair hat: this is a real question to the WG. On Sun, May 19, 2013 at 11:20:00PM -0400, Stuart Gathman wrote: > Interestingly, I find that all the (rare) SPF RRs in the field I've > encountered so far publish *only* SPF RR. Probably a wise strategy. > The "publish both" recommendation in rfc4408 is problematic. Given our charter, what conclusion for our work product do you think should produce? A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Sun May 19 21:54:33 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A8421F8FE9 for ; Sun, 19 May 2013 21:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EZrOCQ5tz72 for ; Sun, 19 May 2013 21:54:33 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 02C0821F852A for ; Sun, 19 May 2013 21:54:33 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id E35E6C9427; Mon, 20 May 2013 04:54:22 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1369025672; bh=JfKhfRz9qx+I1RHN4g8hYgCYPlNIcH1oTWPor7dAbQ0=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=PGbXl8ikjpxmIQ9nk5Fn5cwfCNYfDouJrfd3tuECfG83m6wAvp867qiMB/AoTZzoT XWdgZ4Axg8SyejUbZMvI9Ti9/FpPsoVvYMPYDqJec+1vqJeODwDfJX+BfBhV6eB8ut L59riYNsOOwSdpVSTSgSNF/fu7eFBTpx2JfO/W1U= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Mon, 20 May 2013 04:54:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 7CB9E216C43; Mon, 20 May 2013 04:54:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id F02AB3487172; Mon, 20 May 2013 14:54:18 +1000 (EST) To: Andrew Sullivan From: Mark Andrews References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <20130424180512.GN16817@mx1.yitter.info> <1431349.C0e3qG0mtd@scott-latitude-e6320> <517ABBDA.2060201@dcrocker.net> <51999660.6070105@gathman.org> <20130520035329.GG33927@mx1.yitter.info> In-reply-to: Your message of "Sun, 19 May 2013 23:53:30 -0400." <20130520035329.GG33927@mx1.yitter.info> Date: Mon, 20 May 2013 14:54:18 +1000 Message-Id: <20130520045418.F02AB3487172@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: spfbis@ietf.org Subject: Re: [spfbis] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 04:54:33 -0000 In message <20130520035329.GG33927@mx1.yitter.info>, Andrew Sullivan writes: > Chair hat: this is a real question to the WG. > > On Sun, May 19, 2013 at 11:20:00PM -0400, Stuart Gathman wrote: > > > Interestingly, I find that all the (rare) SPF RRs in the field I've > > encountered so far publish *only* SPF RR. Probably a wise strategy. > > The "publish both" recommendation in rfc4408 is problematic. > > Given our charter, what conclusion for our work product do you think > should produce? Well given removal of features that are in use is prohibited and that SPF records are both looked up (libspf2) and published (8% of domains that publish SPF record publish a type 99 SPF record) and there are not significantly different failure rates. I respectfully suggest that we require that type 99 records be looked up first and that type TXT records be looked up on SERVFAIL or a NODATA response. Note type 99 use has doubled since the RFC 6686 surveys were done. Mark % grep status: domainlist.{spf,txt,mx,a,aaaa} | awk '{print $1, $6}' | sed 's/:;;//' | sort | uniq -c 22287 domainlist.a NOERROR, 2765 domainlist.a NXDOMAIN, 524 domainlist.a SERVFAIL, 22149 domainlist.aaaa NOERROR, 2766 domainlist.aaaa NXDOMAIN, 661 domainlist.aaaa SERVFAIL, 22240 domainlist.mx NOERROR, 2768 domainlist.mx NXDOMAIN, 568 domainlist.mx SERVFAIL, 22068 domainlist.spf NOERROR, 2774 domainlist.spf NXDOMAIN, 737 domainlist.spf SERVFAIL, 22157 domainlist.txt NOERROR, 2777 domainlist.txt NXDOMAIN, 645 domainlist.txt SERVFAIL, % grep v=spf1 domainlist.spf | wc 730 6923 74024 % grep v=spf1 domainlist.txt | wc 9289 91287 984437 % grep v=spf1 domainlist.txt | awk '{print $1}' > txt.list % grep v=spf1 domainlist.spf | awk '{print $1}' > spf.list % comm -23 txt.list spf.list | wc 9256 9256 132941 % comm -13 txt.list spf.list | wc 697 697 9832 % comm -12 txt.list spf.list | wc 33 33 439 % > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From spf2@kitterman.com Sun May 19 22:12:00 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E3F21F8FF2 for ; Sun, 19 May 2013 22:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvADqvqPrQ7w for ; Sun, 19 May 2013 22:11:47 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D575F21F8FDD for ; Sun, 19 May 2013 22:11:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E61E520E40D2; Mon, 20 May 2013 01:11:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369026703; bh=7wYnPhpUmmRP/RXTlLP/UeWn8U9XZ9aAqhrX+i/QWVE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=CeFtE/+xPYt0clnhtph0VHfaVAbydYg+1UAcZHek7BastkZ7Rmxp0sUz4nONmqA4x Fo0ac6GGO46veLqFyYYV4RjnmvRLhHzjH+9xPgAMYZysUY+2+eliBfQbatBU1C++P5 Y+yAP/x99piqAAqevBSpuJ6QJQC4iOrJGeFd3gpM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C8FA820E40CF; Mon, 20 May 2013 01:11:43 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 May 2013 01:11:40 -0400 Message-ID: <2568528.KYijAM7kNx@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <51999660.6070105@gathman.org> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <517ABBDA.2060201@dcrocker.net> <51999660.6070105@gathman.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 05:12:00 -0000 On Sunday, May 19, 2013 11:20:00 PM Stuart Gathman wrote: > New observation: claims that spf libraries didn't support SPF RR are > likely correct. > > Long ago, Nostradamus foresaw that on 04/26/2013 01:39 PM, Dave Crocker > > would write: > > Even then, retention is a bad idea. There is no current basis for > > seeing any likelihood of utility for the RR. None. > > After seeing a complaint that spf libraries didn't support SPF RR, and > protesting that pyspf did, I went and checked, and lo and behold, SPF > RRs were disabled in pyspf at some point - and I hadn't noticed. I > turned them back on, and discovered that we were missing important SPF > policies for business partners due to not checking SPF RRs! I have not > yet run into any of the braindead servers (that timeout on unknown RRs) > that caused the initial difficulties with using the SPF RR. > > Interestingly, I find that all the (rare) SPF RRs in the field I've > encountered so far publish *only* SPF RR. Probably a wise strategy. > The "publish both" recommendation in rfc4408 is problematic. It was turned off because I turned it off after it caused problems (Stuart and I are co-maintainers of pyspf). This was several years ago, so either I misremember discussing the change with him when I did it or he's forgotten the discussion. Until it's reliable enough to use, it shouldn't be used and, of course, no one will care if it's reliable if it's not used. All of which is irrelevant to the rationale for removing it. Scott K From spf2@kitterman.com Sun May 19 22:13:38 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B68121F8700 for ; Sun, 19 May 2013 22:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbOUhQOqhags for ; Sun, 19 May 2013 22:13:33 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EF65821F8503 for ; Sun, 19 May 2013 22:13:32 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A79A420E40D2; Mon, 20 May 2013 01:13:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369026810; bh=B4IattbmVDyDxmkDRreggbvJ1iYePTVu15qMDyI1MVU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=j3s8emsOpBzzyGsXaBloTrau2AMhadDlsOX24iUP+sMhcTxoqCkAQFiZvYPb+s1iV s4h5Ro5hKP1vamczUbKEPdRE+t0/baLlY4DUiKNrxpnADI2LEjIAqQ5F7kDw2ZVLbp P+yINyLFpbXJVFCk5w8WFoH5ZZPrFh9TDW4XCo6M= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 8B01C20E40CF; Mon, 20 May 2013 01:13:30 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 May 2013 01:13:29 -0400 Message-ID: <12569478.XPmz56gEZG@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130520045418.F02AB3487172@drugs.dv.isc.org> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <20130520035329.GG33927@mx1.yitter.info> <20130520045418.F02AB3487172@drugs.dv.isc.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 05:13:38 -0000 On Monday, May 20, 2013 02:54:18 PM Mark Andrews wrote: > In message <20130520035329.GG33927@mx1.yitter.info>, Andrew Sullivan writes: > > Chair hat: this is a real question to the WG. > > > > On Sun, May 19, 2013 at 11:20:00PM -0400, Stuart Gathman wrote: > > > Interestingly, I find that all the (rare) SPF RRs in the field I've > > > encountered so far publish *only* SPF RR. Probably a wise strategy. > > > The "publish both" recommendation in rfc4408 is problematic. > > > > Given our charter, what conclusion for our work product do you think > > should produce? > > Well given removal of features that are in use is prohibited and > that SPF records are both looked up (libspf2) and published (8% of > domains that publish SPF record publish a type 99 SPF record) and > there are not significantly different failure rates. I respectfully > suggest that we require that type 99 records be looked up first and > that type TXT records be looked up on SERVFAIL or a NODATA response. That would be a ridiculous design. Scott K From superuser@gmail.com Mon May 20 00:49:05 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D0A21F8521; Mon, 20 May 2013 00:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtDf+ZAGASyT; Mon, 20 May 2013 00:49:03 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id D358821F8539; Mon, 20 May 2013 00:49:00 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so147608wgg.28 for ; Mon, 20 May 2013 00:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=K1CmhgR3+bvA9Xh/jX/rjRpsv+IkUEroBD+5PtQo/LM=; b=ecwP5Z12luTuTbnkFVcO+PA8EjxpLs7v+lmBb0IEpYk/Du0pEXZxj5coBKgrY89aG3 mOy0m0+/5dvTvSfnkAmDqUUDrxRK2gvKycAXD+yGaus2QEtRxRBw2M3UQ28noixq6jZV AE2ZIpivaV9XM3jfL+FRkCYnjioGIY3liBhXmNzp3T+8/lEJA9esBOabu4yoH4ySMLz5 lqoDhIFQZMxy3p/JG/UVZT+N60vtQTT3nuWlUnEtjVkUhyv9HfXnmcYNt9IKy03CjEzZ vir68mpdFnjprzbotCzqZDUGrqj8CzN6VsBNVP/UzYHFTU1u4fOS5uBAJLmdHZw381FG GrYg== MIME-Version: 1.0 X-Received: by 10.180.210.242 with SMTP id mx18mr11069821wic.14.1369036139666; Mon, 20 May 2013 00:48:59 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Mon, 20 May 2013 00:48:59 -0700 (PDT) In-Reply-To: <9E5D5870D2E1345B7ABA6971@cyrus.local> References: <9E5D5870D2E1345B7ABA6971@cyrus.local> Date: Mon, 20 May 2013 00:48:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Cyrus Daboo , "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=001a11c262e8ca24bb04dd21909d Cc: The IESG , IETF Apps Discuss Subject: Re: [spfbis] [apps-discuss] APPSDIR review of draft-ietf-spfbis-4408bis-14.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 07:49:05 -0000 --001a11c262e8ca24bb04dd21909d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 29, 2013 at 6:50 AM, Cyrus Daboo wrote: > Nits: > Section 2.6 and Section 8 appear to duplicate a lot of similar > information. Please consider trimming down Section 2.6 and have it refer to > Section 8 for full details. > > > Hi Cyrus, There is a little duplication in there that I'm attempting to help the editor to reduce to a minimum. It's intentional, however, because the WG concluded it was necessary to separate the list of possible SPF results from any kind of normative statements (or even inference) about what an operator should do with one of those results. Thus, 2.6 lists protocol elements, and 8 is basically some operational discussion. I may also say the above in a more condensed form just so it's clear why the apparent duplication exists. Thanks for the review, -MSK --001a11c262e8ca24bb04dd21909d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 29, 2013 at 6:50 AM, Cyrus Daboo <cyrus@daboo.= name> wrote:
Nits:
=A0 =A0 =A0 =A0 Section 2.6 and Section 8 appear to duplicate a lot of simi= lar information. Please consider trimming down Section 2.6 and have it refe= r to Section 8 for full details.



Hi Cyrus,

There is a = little duplication in there that I'm attempting to help the editor to r= educe to a minimum.=A0 It's intentional, however, because the WG conclu= ded it was necessary to separate the list of possible SPF results from any = kind of normative statements (or even inference) about what an operator sho= uld do with one of those results.=A0 Thus, 2.6 lists protocol elements, and= 8 is basically some operational discussion.

I may also say the above in a more con= densed form just so it's clear why the apparent duplication exists.
=
Thanks for the review,

-MSK
--001a11c262e8ca24bb04dd21909d-- From WebMaster@Commerco.Net Mon May 20 02:07:03 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5FF21F871D for ; Mon, 20 May 2013 02:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GFlFrSm22te for ; Mon, 20 May 2013 02:06:54 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id B84E821F84A6 for ; Mon, 20 May 2013 02:03:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=sbqzcSwDkCZ9xgQEBsoS56h071RgA3BVMXsOrwFXmPWtMPNeAPuDlUspb2O6YHaPBaRmynzG1bZAicamX8YgiQb5z+9HI+bEgNesaKfIFjXYDHtKby/MK+mIAmQ2geLV57TJkH+Ckoq94KHcf3FJMfecXJ2LHZiQaIG2/DV5TDE= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.6) with ESMTP (EHLO [10.240.241.49]); Mon, 20 May 2013 08:52:52 +0000 Message-ID: <5199E45D.8080109@Commerco.Net> Date: Mon, 20 May 2013 02:52:45 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Andrew Sullivan References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <20130424180512.GN16817@mx1.yitter.info> <1431349.C0e3qG0mtd@scott-latitude-e6320> <517ABBDA.2060201@dcrocker.net> <51999660.6070105@gathman.org> <20130520035329.GG33927@mx1.yitter.info> In-Reply-To: <20130520035329.GG33927@mx1.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Cc: spfbis@ietf.org Subject: Re: [spfbis] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 09:07:03 -0000 On 5/19/2013 9:53 PM, Andrew Sullivan wrote: > Chair hat: this is a real question to the WG. > > On Sun, May 19, 2013 at 11:20:00PM -0400, Stuart Gathman wrote: > >> Interestingly, I find that all the (rare) SPF RRs in the field I've >> encountered so far publish *only* SPF RR. Probably a wise strategy. >> The "publish both" recommendation in rfc4408 is problematic. > > Given our charter, what conclusion for our work product do you think > should produce? > > A > Andrew, As I recall, the charter may not allow additional features to SPF1 syntax, so this may not even be an answer. Even so... It would be great to add something into the SPF TXT record to serve as an SPF type 99 preference indicator, that simply redirects the DNS requester to the type 99 SPF RR, much in the way that a redirect can take place to point to a different TXT record via the "redirect" syntax in SPF1 today. To that end I propose type99:[0|1] for both TXT and SPF (99) RRs. For example: TXT "v=spf1 type99:1 ip4:192.168.123.123 ip4:10.10.123.123 -all" could mean for existing libraries that this domain only sends email via the two IP4 addresses presented (as it always would have), but if you happen to support type99 syntax, the domain is also published using the SPF RR, so chose that for now and don't bother doing TXT request in future SPF requests for this domain that may be required for this SPF transaction, as since now you know we publish in both, you can limit your requests to SPF 99 to stop doing double work from your side and double taxing our DNS servers (and heck, you might even go so far as to cache that knowledge for the TTL supplied in the response). This would mean that a publisher MUST then have an identical spf1 record like this: SPF "v=spf1 type99:1 ip4:192.168.123.123 ip4:10.10.123.123 -all" Alternately: TXT "v=spf1 type99:0 ip4:192.168.123.123 ip4:10.10.123.123 -all" could mean we are aware of type 99, but for whatever reasons (e.g., our DNS or device does not support 99), we are only publishing a TXT record for SPF, so you must not even use type99. Perhaps one could also allow the type99:[0|1] syntax in the SPF type 99 record, to serve as a contextual switch back mechanism when redirecting over to a domain known to only publish type TXT to avoid causing any harm (unintended or otherwise). Again, I'm pretty sure the above goes beyond charter, but it might present an easy way to help libs going forward understand that the preferred method of handing SPF for a given domain is via SPF type 99 records without breaking the original TXT only SPF environments for records existing in the time preceding MARID and the approval and introduction of Type99 SPF RRs at or about that time. Since TXT was the original RR spec for SPF1, it is reasonable to keep the TXT as the first DNS lookup choice for SPF1, but if a domain's dns host/zone file indicates its preference for SPF type 99, perhaps the above might allow for using the SPF type 99 and start the process of coaching people to implement type 99 RR records for any future SPF versions, where it becomes the primary RR. Since it was the work product of this group that uncovered the technical problem with having the SPF type 99 RR published coterminous with the TXT RR and consequentially suggesting use of SPF type 99 be depreciated, perhaps it might not be beyond the bounds of reason to push the limits of the charter by instead supplying a fix in the SPFbis to address the technical problem with a possible solution rather than simply depreciating. Best, Alan M. From johnl@iecc.com Mon May 20 05:01:03 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88C421F9206 for ; Mon, 20 May 2013 05:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.98 X-Spam-Level: X-Spam-Status: No, score=-110.98 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZ8vaojFeXha for ; Mon, 20 May 2013 05:00:59 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id F26B921F9121 for ; Mon, 20 May 2013 05:00:58 -0700 (PDT) Received: (qmail 96485 invoked from network); 20 May 2013 12:00:56 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 May 2013 12:00:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=519a1078.xn--30v786c.k1305; i=johnl@user.iecc.com; bh=bNISdj0TQMCsFBrPIBlD+pJayhSxXMimY2GXt1Q8jFA=; b=R2evViBeqNCGOib+K0fgKdy3LDbVX9Xhf3vl5sTTV0bV7ghO5pe8IfYjC4NWylSwU+PXyzsbPVFShoCOvbaSJI8TfCQIU+IlSfC3//sO5dwn/J67AiNQqBYH7uSAA/KDQNHC9wtXXy24DElJElyHTgw9NstxXIf8wLF5dD9Pkkc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=519a1078.xn--30v786c.k1305; olt=johnl@user.iecc.com; bh=bNISdj0TQMCsFBrPIBlD+pJayhSxXMimY2GXt1Q8jFA=; b=DL8w03mayx+2oJALZ4eJo6qmsvKJ4bZy+FcXIUC+bhyNwex66G3rBdLLyRnxBsdEGO+qSE8nANo3wkPMr7TDxoE4QMwUsPeA3ZK5JjxTeu3AmUa9AhUUxKbpNXOIYpcumed9jceBpy46ecC9IGXANsm5cnYOVfvyR5hPIuiJzNs= Date: 20 May 2013 12:00:33 -0000 Message-ID: <20130520120033.95642.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <5199E45D.8080109@Commerco.Net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: WebMaster@Commerco.Net Subject: Re: [spfbis] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 12:01:03 -0000 >It would be great to add something into the SPF TXT record to serve as >an SPF type 99 preference indicator, that simply redirects the DNS >requester to the type 99 SPF RR By the time it saw the flag, an SPF checker would already have fetched the TXT record, which would presumably be in the local DNS cache for subsequent lookups. Other than gratuitously increased DNS traffic, and decreased reliability when the type 99 lookup fails or the SPF record isn't consistent with the TXT record, what would this accomplish? R's, John From schlitt@theworld.com Mon May 20 08:48:08 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5AB21F93C4 for ; Mon, 20 May 2013 08:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-Q0P4hEdeE5 for ; Mon, 20 May 2013 08:48:03 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id BA3F021F92E3 for ; Mon, 20 May 2013 08:48:03 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4KFlgvp018710; Mon, 20 May 2013 11:47:44 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4KFlgJW5139176; Mon, 20 May 2013 11:47:42 -0400 (EDT) Received: from localhost (schlitt@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) with ESMTP id r4KFlbl55131068; Mon, 20 May 2013 11:47:37 -0400 (EDT) X-Authentication-Warning: shell01.TheWorld.com: schlitt owned process doing -bs Date: Mon, 20 May 2013 11:47:37 -0400 From: Dan Schlitt To: Mark Andrews In-Reply-To: <20130520045418.F02AB3487172@drugs.dv.isc.org> Message-ID: References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <20130424180512.GN16817@mx1.yitter.info> <1431349.C0e3qG0mtd@scott-latitude-e6320> <517ABBDA.2060201@dcrocker.net> <51999660.6070105@gathman.org> <20130520035329.GG33927@mx1.yitter.info> <20130520045418.F02AB3487172@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: spfbis@ietf.org, Andrew Sullivan Subject: Re: [spfbis] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 15:48:08 -0000 +1 -- Dan Schlitt schlitt@world.std.com On Mon, 20 May 2013, Mark Andrews wrote: > > In message <20130520035329.GG33927@mx1.yitter.info>, Andrew Sullivan writes: >> Chair hat: this is a real question to the WG. >> >> On Sun, May 19, 2013 at 11:20:00PM -0400, Stuart Gathman wrote: >> >>> Interestingly, I find that all the (rare) SPF RRs in the field I've >>> encountered so far publish *only* SPF RR. Probably a wise strategy. >>> The "publish both" recommendation in rfc4408 is problematic. >> >> Given our charter, what conclusion for our work product do you think >> should produce? > > Well given removal of features that are in use is prohibited and > that SPF records are both looked up (libspf2) and published (8% of > domains that publish SPF record publish a type 99 SPF record) and > there are not significantly different failure rates. I respectfully > suggest that we require that type 99 records be looked up first and > that type TXT records be looked up on SERVFAIL or a NODATA response. > > Note type 99 use has doubled since the RFC 6686 surveys were done. > > Mark > > % grep status: domainlist.{spf,txt,mx,a,aaaa} | awk '{print $1, $6}' | sed 's/:;;//' | sort | uniq -c > 22287 domainlist.a NOERROR, > 2765 domainlist.a NXDOMAIN, > 524 domainlist.a SERVFAIL, > 22149 domainlist.aaaa NOERROR, > 2766 domainlist.aaaa NXDOMAIN, > 661 domainlist.aaaa SERVFAIL, > 22240 domainlist.mx NOERROR, > 2768 domainlist.mx NXDOMAIN, > 568 domainlist.mx SERVFAIL, > 22068 domainlist.spf NOERROR, > 2774 domainlist.spf NXDOMAIN, > 737 domainlist.spf SERVFAIL, > 22157 domainlist.txt NOERROR, > 2777 domainlist.txt NXDOMAIN, > 645 domainlist.txt SERVFAIL, > % grep v=spf1 domainlist.spf | wc > 730 6923 74024 > % grep v=spf1 domainlist.txt | wc > 9289 91287 984437 > % grep v=spf1 domainlist.txt | awk '{print $1}' > txt.list > % grep v=spf1 domainlist.spf | awk '{print $1}' > spf.list > % comm -23 txt.list spf.list | wc > 9256 9256 132941 > % comm -13 txt.list spf.list | wc > 697 697 9832 > % comm -12 txt.list spf.list | wc > 33 33 439 > % > > >> A >> >> -- >> Andrew Sullivan >> ajs@anvilwalrusden.com >> _______________________________________________ >> spfbis mailing list >> spfbis@ietf.org >> https://www.ietf.org/mailman/listinfo/spfbis > From ogud@ogud.com Mon May 20 10:01:10 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C5321F935E for ; Mon, 20 May 2013 10:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHO-RTbLYJPA for ; Mon, 20 May 2013 10:01:05 -0700 (PDT) Received: from smtp82.ord1c.emailsrvr.com (smtp82.ord1c.emailsrvr.com [108.166.43.82]) by ietfa.amsl.com (Postfix) with ESMTP id 9319F21F96D1 for ; Mon, 20 May 2013 10:01:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 1786E500A9; Mon, 20 May 2013 13:01:04 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id EEFF2500B8; Mon, 20 May 2013 13:01:02 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Olafur Gudmundsson In-Reply-To: <12569478.XPmz56gEZG@scott-latitude-e6320> Date: Mon, 20 May 2013 13:01:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <237F033C-4A72-41E4-8BE8-6837600A0E7E@ogud.com> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <20130520035329.GG33927@mx1.yitter.info> <20130520045418.F02AB3487172@drugs.dv.isc.org> <12569478.XPmz56gEZG@scott-latitude-e6320> To: Scott Kitterman X-Mailer: Apple Mail (2.1503) Cc: spfbis@ietf.org Subject: Re: [spfbis] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 17:01:10 -0000 On May 20, 2013, at 1:13 AM, Scott Kitterman wrote: > On Monday, May 20, 2013 02:54:18 PM Mark Andrews wrote: >> In message <20130520035329.GG33927@mx1.yitter.info>, Andrew Sullivan = writes: >>> Chair hat: this is a real question to the WG. >>>=20 >>> On Sun, May 19, 2013 at 11:20:00PM -0400, Stuart Gathman wrote: >>>> Interestingly, I find that all the (rare) SPF RRs in the field I've >>>> encountered so far publish *only* SPF RR. Probably a wise = strategy. >>>> The "publish both" recommendation in rfc4408 is problematic. >>>=20 >>> Given our charter, what conclusion for our work product do you think >>> should produce? >>=20 >> Well given removal of features that are in use is prohibited and >> that SPF records are both looked up (libspf2) and published (8% of >> domains that publish SPF record publish a type 99 SPF record) and >> there are not significantly different failure rates. I respectfully >> suggest that we require that type 99 records be looked up first and >> that type TXT records be looked up on SERVFAIL or a NODATA response. >=20 > That would be a ridiculous design. Why ?=20 This is the right way to build fallback in DNS given the installed base, = ask for one type and if it is not available=20 try the fallback.=20 If your client can do queries in parallel then you can do both and use = one of the ones that returns an positive answer, but in that case there is a race condition if both return and the two types differ, that = can be addressed by preferred type rule.=20 Mark's suggestion is SPF is the preferred type, and TXT is compatibility = type in sequence.=20 You may disagree with that order =85.=20 =20 Olafur From johnl@iecc.com Mon May 20 10:08:59 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD6221F93C8 for ; Mon, 20 May 2013 10:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.002 X-Spam-Level: X-Spam-Status: No, score=-111.002 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AN0QHO-dRB59 for ; Mon, 20 May 2013 10:08:55 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 764D321F935E for ; Mon, 20 May 2013 10:08:55 -0700 (PDT) Received: (qmail 15493 invoked from network); 20 May 2013 17:08:54 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 May 2013 17:08:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=519a58a6.xn--30v786c.k1305; i=johnl@user.iecc.com; bh=Wc+EHUq+LtImjF244sLgVF34KsMpXE0Q5nMD73z3i8c=; b=ZER0ll5PGp9XEuM0BrlaIJUgOBI3C6pHe8aQ5NXkLOtXgMJRjegZ+NXzhQn/9wn3h2vQEVDlQB/EePKyiryYC1Bu/fXk6XwLJXxizsXBzocWr0fngb0ySksIy2hCreofvfuAPTeXda5UTYd5rTZA9ONiQnp7t05jTpKrw9XwxlI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=519a58a6.xn--30v786c.k1305; olt=johnl@user.iecc.com; bh=Wc+EHUq+LtImjF244sLgVF34KsMpXE0Q5nMD73z3i8c=; b=QMkbAD4+glRmN1nkfX/zZIWonN0Uhfuj2evwe0VB8Ucqr5bJ8H5j2BWSCz7DpMNNqniUn7dp9ms7SdtR7sY5ECiyjeh6qxxLa/u1FXmcXmXRnvD3tvpI/HhSxteR8hiQolPtCggEDwXk4HDifLjTig9gdHxeh4pxTs14hQ17PZU= Date: 20 May 2013 17:08:32 -0000 Message-ID: <20130520170832.69210.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <237F033C-4A72-41E4-8BE8-6837600A0E7E@ogud.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: ogud@ogud.com Subject: Re: [spfbis] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 17:09:00 -0000 >Mark's suggestion is SPF is the preferred type, and TXT is compatibility type in sequence. >You may disagree with that order …. The issue of sequential lookups was debated at great length on this list. Could you explain why you disagree with the reasoning that led to our conclusion? From ogud@ogud.com Mon May 20 10:23:25 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9CC21F96DB for ; Mon, 20 May 2013 10:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7bdWNEG0MK7 for ; Mon, 20 May 2013 10:23:20 -0700 (PDT) Received: from smtp90.ord1c.emailsrvr.com (smtp90.ord1c.emailsrvr.com [108.166.43.90]) by ietfa.amsl.com (Postfix) with ESMTP id 8A89621F96C4 for ; Mon, 20 May 2013 10:23:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 19B2C140080; Mon, 20 May 2013 13:23:16 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id B62FB1400E6; Mon, 20 May 2013 13:23:15 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Olafur Gudmundsson In-Reply-To: <20130520170832.69210.qmail@joyce.lan> Date: Mon, 20 May 2013 13:23:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5D6A979B-9C6B-4D46-BA7C-81EE7D3A55BA@ogud.com> References: <20130520170832.69210.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1503) Cc: spfbis@ietf.org Subject: Re: [spfbis] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 17:23:26 -0000 On May 20, 2013, at 1:08 PM, "John Levine" wrote: >> Mark's suggestion is SPF is the preferred type, and TXT is = compatibility type in sequence.=20 >> You may disagree with that order =EF=BF=BD.=20 >=20 > The issue of sequential lookups was debated at great length on this > list. Could you explain why you disagree with the reasoning that led > to our conclusion? Thanks your selective copying the main reason I was forced to reply is = lost: Scott Kitterman said about Mark's proposal:=20 "That would be a ridiculous design." I was trying to point out that Mark's proposal is sound and the only = point of contention is the possible order of=20 queries, without saying anything about what my position is.=20 I do not have a bone in this fight other than the FUD that some people = spew out about DNS and DNS software.=20 In the prior message that I read on this thread Scott said the following " It was turned off because I turned it off after it caused problems = (Stuart and I=20 are co-maintainers of pyspf). This was several years ago, so either I=20= misremember discussing the change with him when I did it or he's = forgotten the=20 discussion. Until it's reliable enough to use, it shouldn't be used and, of course, = no one=20 will care if it's reliable if it's not used. All of which is irrelevant to the rationale for removing it. " Which can be taken to mean he is partially responsible for the = difficulties that some people have in getting SPF records=20 from the DNS when present, thus has skewed the measurements used to = justify the removal SPF type.=20 Olafur From spf2@kitterman.com Mon May 20 10:39:39 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B77621F8ADF for ; Mon, 20 May 2013 10:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6ZGQ6IroL0t for ; Mon, 20 May 2013 10:39:32 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CDBC421F898B for ; Mon, 20 May 2013 10:39:31 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 44F8420E40D6; Mon, 20 May 2013 13:39:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369071571; bh=as95Ae5iiotx6GTyoX7Cl98y7E3xnsd7eM0d38Ab/MA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JeNYt/XZccOAeoDGT4qaGKqMYAkVWN7cNh/bapXNzhHG800PMZJAgDOL5yH6tyhgK /r1P5TNTR3U9daQYfNFbWJCndIBVtaKf/cMCgRh1VxsWWJy9MykH4r2eP4gqCgBPMw Q0OFARRDitPutm0l36SfhYz3qNKw7Zr5TQcLNJeg= Received: from scott-latitude-e6320.localnet (121.sub-70-192-199.myvzw.com [70.192.199.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1B74F20E40D4; Mon, 20 May 2013 13:39:30 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 May 2013 13:39:29 -0400 Message-ID: <2559081.7IgQ8Mc0EM@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <237F033C-4A72-41E4-8BE8-6837600A0E7E@ogud.com> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <12569478.XPmz56gEZG@scott-latitude-e6320> <237F033C-4A72-41E4-8BE8-6837600A0E7E@ogud.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 17:39:39 -0000 On Monday, May 20, 2013 01:01:06 PM Olafur Gudmundsson wrote: > On May 20, 2013, at 1:13 AM, Scott Kitterman wro= te: > > On Monday, May 20, 2013 02:54:18 PM Mark Andrews wrote: > >> In message <20130520035329.GG33927@mx1.yitter.info>, Andrew Sulliv= an=20 writes: > >>> Chair hat: this is a real question to the WG. > >>>=20 > >>> On Sun, May 19, 2013 at 11:20:00PM -0400, Stuart Gathman wrote: > >>>> Interestingly, I find that all the (rare) SPF RRs in the field I= 've > >>>> encountered so far publish *only* SPF RR. Probably a wise strat= egy. > >>>> The "publish both" recommendation in rfc4408 is problematic. > >>>=20 > >>> Given our charter, what conclusion for our work product do you th= ink > >>> should produce? > >>=20 > >> Well given removal of features that are in use is prohibited and > >> that SPF records are both looked up (libspf2) and published (8% of= > >> domains that publish SPF record publish a type 99 SPF record) and > >> there are not significantly different failure rates. I respectful= ly > >> suggest that we require that type 99 records be looked up first an= d > >> that type TXT records be looked up on SERVFAIL or a NODATA respons= e. > >=20 > > That would be a ridiculous design. >=20 > Why ? > This is the right way to build fallback in DNS given the installed ba= se, ask > for one type and if it is not available try the fallback. > If your client can do queries in parallel then you can do both and us= e one > of the ones that returns an positive answer, but in that case there i= s a > race condition if both return and the two types differ, that can be > addressed by preferred type rule. Mark's suggestion is SPF is the pre= ferred > type, and TXT is compatibility type in sequence. You may disagree wit= h that > order =E2=80=A6. There's no value proposition for receivers. We've been through all thi= s in=20 the working group before, but I'll give at least a summary ... In RFC 4408 there is an interoperability defect. Senders can publish T= XT or=20 SPF types and meet the requirements in 4408. Receivers can publish TXT= or SPF=20 and similarly meet the requirements of 4408. We concluded that to be=20= interoperable there had to be a common format that senders MUST publish= and=20 receivers MUST check, otherwise they could end up completely failing to= =20 communicate. We considered to which type to make the MUST format and concluded that = given=20 the overwhelming deployed based for TXT only versus SPF only (publisher= s that=20 publish both SPF and TXT can be ignored for this analysis), making TXT = the=20 mandatory format was the only thing that made sense. Given that, checking type TXT first is the only sensible approach. The= n you=20 have to consider the value proposition of a follow-on type SPF check. = Once=20 the TXT lookup is complete, you have ~98% of the SPF records you are go= ing to=20 get. Offsetting the value of trying to get those few additional record= s are=20 not only the costs of doing the queries (virtually none of which will r= eturn=20 useful information), but also the delays caused by DNS servers that tim= eout=20 for TYpe SPF (but not TXT) that can slow down busy mail streams. As a receiver, I don't see the value in getting those last few records = that's=20 worth not only the added resources, but the additional complexity in co= de. I=20 get the protocol purity argument, but in the real world, I don't think = people=20 care. Scott K From dhc@dcrocker.net Mon May 20 10:49:58 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D68B21F8E9A for ; Mon, 20 May 2013 10:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA94VuRTDBrJ for ; Mon, 20 May 2013 10:49:53 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7B13B21F8F0C for ; Mon, 20 May 2013 10:49:52 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r4KHnmqd020613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 May 2013 10:49:52 -0700 Message-ID: <519A623A.2070905@dcrocker.net> Date: Mon, 20 May 2013 10:49:46 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Olafur Gudmundsson References: <20130520170832.69210.qmail@joyce.lan> <5D6A979B-9C6B-4D46-BA7C-81EE7D3A55BA@ogud.com> In-Reply-To: <5D6A979B-9C6B-4D46-BA7C-81EE7D3A55BA@ogud.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 20 May 2013 10:49:52 -0700 (PDT) Cc: spfbis@ietf.org, John Levine Subject: Re: [spfbis] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 17:49:58 -0000 On 5/20/2013 10:23 AM, Olafur Gudmundsson wrote: > Which can be taken to mean he is partially responsible for the difficulties that some people have in getting SPF records > from the DNS when present, thus has skewed the measurements used to justify the removal SPF type. This is the essential problem with trying to re-argue a topic that was already discussed extensively and exhaustively and was fully resolved very, very long ago: it imposes the burden on defenders of the decision to be just as thorough as they/we were long ago. Forgive me if I think that that is placing the cost on the wrong people. It also causes challengers to think that they are being reasonable in re-raising an old topic and claiming that it was a bad decision. So here's what it normally considered reasonable in the IETF: Working Group Guidelines and Procedures RFC 2418: It is occasionally appropriate to revisit a topic, to re-evaluate alternatives or to improve the group's understanding of a relevant decision. However, unnecessary repeated discussions on issues can be avoided if the Chair makes sure that the main arguments in the discussion (and the outcome) are summarized and archived after a discussion has come to conclusion. We've got a lengthy archive on this topic. This particular item was not an easy or quick decision. The odds that there's some key point that was missed are quite small. So what I'd appreciate is for folks who want to challenge or criticize an existing working group decision to do their f'ing homework with the archive and point to specific errors in the sequence or its content. Please do not put a burden on the working group until that homework has been done. But of course, that's just my personal preference. No doubt, I'm the one being unreasonable. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Mon May 20 10:50:53 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC3121F9121 for ; Mon, 20 May 2013 10:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ru0FAwuSZdo for ; Mon, 20 May 2013 10:50:44 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D711E21F8F12 for ; Mon, 20 May 2013 10:50:43 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 51ACA20E40D6; Mon, 20 May 2013 13:50:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369072243; bh=WPZew0Z9+7ZWC9r46NGRXIf9g43VzKy75fTSWw7SHLw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SPbB7sXpRWTBeA2LQyxmSla+ldfWeLMy1juCRhj+Zv1msXbQ3X2UF8v6jAChqr64S 7gBVX5H9V4fmDbUSb8bfAio1VL4uF33W5TIQdOEUYTMnGzBkGhixIU4Yh9CpAMxyz7 uK0IjmmVVAKqIgxMcfaCBDTZQURyA1qiATQjdMUE= Received: from scott-latitude-e6320.localnet (121.sub-70-192-199.myvzw.com [70.192.199.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2719720E40D4; Mon, 20 May 2013 13:50:42 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 20 May 2013 13:50:41 -0400 Message-ID: <1405188.pQhzXLDkZk@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <5D6A979B-9C6B-4D46-BA7C-81EE7D3A55BA@ogud.com> References: <20130520170832.69210.qmail@joyce.lan> <5D6A979B-9C6B-4D46-BA7C-81EE7D3A55BA@ogud.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 17:50:55 -0000 On Monday, May 20, 2013 01:23:19 PM Olafur Gudmundsson wrote: > On May 20, 2013, at 1:08 PM, "John Levine" wrote: > >> Mark's suggestion is SPF is the preferred type, and TXT is compati= bility > >> type in sequence. You may disagree with that order =EF=BF=BD. > >=20 > > The issue of sequential lookups was debated at great length on this= > > list. Could you explain why you disagree with the reasoning that l= ed > > to our conclusion? >=20 > Thanks your selective copying the main reason I was forced to reply i= s lost: > Scott Kitterman said about Mark's proposal: > "That would be a ridiculous design." >=20 > I was trying to point out that Mark's proposal is sound and the only = point > of contention is the possible order of queries, without saying anythi= ng > about what my position is. >=20 > I do not have a bone in this fight other than the FUD that some peopl= e spew > out about DNS and DNS software. >=20 > In the prior message that I read on this thread Scott said the follow= ing > " > It was turned off because I turned it off after it caused problems (S= tuart > and I are co-maintainers of pyspf). This was several years ago, so e= ither > I misremember discussing the change with him when I did it or he's > forgotten the discussion. >=20 > Until it's reliable enough to use, it shouldn't be used and, of cours= e, no > one will care if it's reliable if it's not used. >=20 > All of which is irrelevant to the rationale for removing it. > " >=20 > Which can be taken to mean he is partially responsible for the diffic= ulties > that some people have in getting SPF records from the DNS when presen= t, > thus has skewed the measurements used to justify the removal SPF type= . I turned it off because it wasn't reliable. It's still not reliable. = As a=20 software developer I've got no obligation to deliver inferior performan= ce to=20 users because someone has a theory it might some day be useful. Scott K From dotzero@gmail.com Mon May 20 11:02:18 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8C021F95EE for ; Mon, 20 May 2013 11:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT17yIlikf65 for ; Mon, 20 May 2013 11:02:18 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id C33D621F95E4 for ; Mon, 20 May 2013 11:02:17 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id lx15so4762797lab.10 for ; Mon, 20 May 2013 11:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OmZJrYkB2z1qZwCRiJGL47qRIR5+uFizp3M4shYkDNw=; b=Cqtw3WvnwQIJgm2yxvY2c/UKFAc+89hR10yo++XvtF9WaGKXuUzZu2Yb+j5dUMnjMm GX5X7nE3fC82ZRBlnvTKupsSJmBmZME96SAHFkUM0seX+SRjwLlkmu/zfInk45dtW5M/ cH+gMYr0qkf/CbaU4RqH1ZwUKOas79VP+A7eiAA3986GGNW0RMsLL37quTWZRZLrklW1 jLA/ZWJb+DPcryGNnUuizvx9F5dsJHPmR4zknrvFrah/GyF/2QHOrrOXRM7CUJ1YLJ1v XzeTf2+NM40K7uYytNjbx0QOsNxtJyQ7ht4Lx81EYUFSxj7R2UTdqo/40ezt4Yn2kbAk Konw== MIME-Version: 1.0 X-Received: by 10.112.184.226 with SMTP id ex2mr13147760lbc.33.1369072936087; Mon, 20 May 2013 11:02:16 -0700 (PDT) Received: by 10.112.138.8 with HTTP; Mon, 20 May 2013 11:02:16 -0700 (PDT) In-Reply-To: <519A623A.2070905@dcrocker.net> References: <20130520170832.69210.qmail@joyce.lan> <5D6A979B-9C6B-4D46-BA7C-81EE7D3A55BA@ogud.com> <519A623A.2070905@dcrocker.net> Date: Mon, 20 May 2013 14:02:16 -0400 Message-ID: From: Dotzero To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, John Levine , Olafur Gudmundsson Subject: Re: [spfbis] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 18:02:18 -0000 On Mon, May 20, 2013 at 1:49 PM, Dave Crocker wrote: > On 5/20/2013 10:23 AM, Olafur Gudmundsson wrote: >> >> Which can be taken to mean he is partially responsible for the >> difficulties that some people have in getting SPF records >> from the DNS when present, thus has skewed the measurements used to >> justify the removal SPF type. > > > > This is the essential problem with trying to re-argue a topic that was > already discussed extensively and exhaustively and was fully resolved very, > very long ago: it imposes the burden on defenders of the decision to be > just as thorough as they/we were long ago. Forgive me if I think that that > is placing the cost on the wrong people. > > It also causes challengers to think that they are being reasonable in > re-raising an old topic and claiming that it was a bad decision. > > So here's what it normally considered reasonable in the IETF: > > Working Group Guidelines and Procedures > RFC 2418: > > It is occasionally appropriate to revisit a topic, to re-evaluate > alternatives or to improve the group's understanding of a relevant > decision. However, unnecessary repeated discussions on issues can be > avoided if the Chair makes sure that the main arguments in the > discussion (and the outcome) are summarized and archived after a > discussion has come to conclusion. > > We've got a lengthy archive on this topic. This particular item was not an > easy or quick decision. The odds that there's some key point that was > missed are quite small. > > So what I'd appreciate is for folks who want to challenge or criticize an > existing working group decision to do their f'ing homework with the archive > and point to specific errors in the sequence or its content. > > Please do not put a burden on the working group until that homework has been > done. > > But of course, that's just my personal preference. No doubt, I'm the one > being unreasonable. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > While there are times I have found Dave to be unreasonable, this is not one of those times. As he points out, this has been discussed extensively and exhaustuvely. Unless there is something truly new being brought to the table or a glaring error in the previous discussions is pointed out (other than "I don't like the prior decision of the group" then I personally think additional rehashing of the same discussions does not advance the WG in a meaningful manner. We made a design error in RFC4408. I was ambivalent about potential resolution when this first came up as a discussion. I was ultimately swayed that dropping type-99 makes the best sense from a practical standpoint given where things stand today. Like Dave, I appreciate the desire for a "pure" solution but I truly believe that from a practical and operational perspective, the approach the WG came up with makes the most sense. Mike Mike From sm@elandsys.com Mon May 20 11:26:38 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E1E21F960B for ; Mon, 20 May 2013 11:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tf19OA6Z2EPG for ; Mon, 20 May 2013 11:26:38 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D3321F8FBE for ; Mon, 20 May 2013 11:26:37 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.130.208]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4KIQOSj000728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 May 2013 11:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1369074396; bh=9JvvrSiHalo7isLRo2QCLhXNtxaPpIYhjAxKHa1YRDE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=C3IMQcjpFES2giCi9I/fH5hqJpifaBWWFokdIbS0wVf8SLzq5RfjoEDu3du0zM8nb LbpRcBnDrnghlwDJnAnOzSAES8NH4KYLDrejn6INVciw5Q1nJEMp9ewvuwihpKRwyW OIBJ4PrLUrLcI/haDxZA1JKdNiKABRAL3f56Hsg8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1369074396; i=@elandsys.com; bh=9JvvrSiHalo7isLRo2QCLhXNtxaPpIYhjAxKHa1YRDE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=KmNQALcmBqTXq9OaDWegf5b5E0RhID7JNUOu3nLBK48tgSMET+fLPjGAkb7aO7fMi YQkTXtgnufcZR38CsC56/ANdmcHc4sS4B04pk+DAItrhvQQepkRT/8Ed0Hmt99mB4z Oik2+X2Y5GCavPAHo3r3byta6W2Sy3PwLPOa5DX0= Message-Id: <6.2.5.6.2.20130520112038.0bbdb130@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 May 2013 11:24:40 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20130430185911.GI3583@mx1.yitter.info> References: <20130430185911.GI3583@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Messages on obsoleting SPF RRTYPE, merits of TXT, etc. X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 18:26:39 -0000 At 11:59 30-04-2013, Andrew Sullivan wrote: >There has been an enormous number of messages lately discussing the >planned deprecation of the SPF RRTYPE and whether TXT is an >appropriate thing to use and if it is whether the SPF use of it is ok. > >Many people have posted many messages on these related topics, and the >chairs (in their moderator role) believe that all the arguments that >are likely to be made already have been. > >If you are tempted to say more, we ask that you identify the specific >point that you think has not been addressed and talk only about >that. Other arguments have been made clearly, we believe, and do not >need additional repetition. > >Best regards, > >Andrew (for the chairs) The above moderator note was sent to the mailing list on April 30. I would like to remind SPFBIS WG participants about it. Regards, S. Moonesamy (as SPFBIS WG co-chair) From marka@isc.org Mon May 20 15:03:16 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DDE21F96D0 for ; Mon, 20 May 2013 15:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nn9oUBv1Ny5s for ; Mon, 20 May 2013 15:03:14 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 15B3921F96CF for ; Mon, 20 May 2013 15:03:14 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id B0D455F98E4; Mon, 20 May 2013 22:03:01 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1369087393; bh=ZevkoIEYY5L/IPoGs05ISRLS9ln5XQWYjJlZkW5vpw8=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=nEnNsD6Bcmz1jF3j+87leNPZyCvfLb50zPG7ylaOXEPF6CRZKgeIQeth6LPp2fenc cttHkWz08bz1QU41yFYbDId68NplJKR4hp98Qqb/pmbBXPWYYhjnA4pnWmlud7FXxw PmkqxVMgewqdni5NyfuWQpEGvXYlO2zb3Wyrev88= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 9703D216C43; Mon, 20 May 2013 22:02:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id E478D348B805; Tue, 21 May 2013 08:02:52 +1000 (EST) To: Olafur Gudmundsson From: Mark Andrews References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <20130520035329.GG33927@mx1.yitter.info> <20130520045418.F02AB3487172@drugs.dv.isc.org> <12569478.XPmz56gEZG@scott-latitude-e6320> <237F033C-4A72-41E4-8BE8-6837600A0E7E@ogud.com> In-reply-to: Your message of "Mon, 20 May 2013 13:01:06 -0400." <237F033C-4A72-41E4-8BE8-6837600A0E7E@ogud.com> Date: Tue, 21 May 2013 08:02:52 +1000 Message-Id: <20130520220252.E478D348B805@drugs.dv.isc.org> Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 22:03:16 -0000 In message <237F033C-4A72-41E4-8BE8-6837600A0E7E@ogud.com>, Olafur Gudmundsson writes: Input error > > On May 20, 2013, at 1:13 AM, Scott Kitterman wrote: > > > On Monday, May 20, 2013 02:54:18 PM Mark Andrews wrote: > >> In message <20130520035329.GG33927@mx1.yitter.info>, Andrew Sullivan > writes: > >>> Chair hat: this is a real question to the WG. > >>> > >>> On Sun, May 19, 2013 at 11:20:00PM -0400, Stuart Gathman wrote: > >>>> Interestingly, I find that all the (rare) SPF RRs in the field I've > >>>> encountered so far publish *only* SPF RR. Probably a wise strategy. > >>>> The "publish both" recommendation in rfc4408 is problematic. > >>> > >>> Given our charter, what conclusion for our work product do you think > >>> should produce? > >> > >> Well given removal of features that are in use is prohibited and > >> that SPF records are both looked up (libspf2) and published (8% of > >> domains that publish SPF record publish a type 99 SPF record) and > >> there are not significantly different failure rates. I respectfully > >> suggest that we require that type 99 records be looked up first and > >> that type TXT records be looked up on SERVFAIL or a NODATA response. > > > > That would be a ridiculous design. > > > Why ? > This is the right way to build fallback in DNS given the installed base, > ask for one type and if it is not available > try the fallback. > If your client can do queries in parallel then you can do both and use > one of the ones that returns an positive answer, but in that case > there is a race condition if both return and the two types differ, that > can be addressed by preferred type rule. If two type are returned and they are different you are in transition. You pick one. It does not matter which because there is no way to tell which is the newest. If you want a explict order then ignore the TXT record. SPF records don't hace a sequence number and TTL doesn't help. This is no different to querying two or more recusive servers for TXT records after the zone has been updated and getting different results. You cannot tell which of the results is current. Note nameserver vendors are free to add code to keep SPF and TXT records in sync already. The simplest would be to document that if both SPF and TXT types are present and differ then the TXT record will be updated to match the SPF record. Alternatively they could add a "xorig=" and the code would use its presence to select which record is the orginal and which is the copy. Both ideas are permisible by RFC 4408. It took me a couple of minutes to add such code to dnssec-signzone the other day to do "xorig=". Adding it to the update and the post zone loading codes in named would not take much longer. Having a RFC that said it MAY/SHOULD be done would make it easier for anyone where the web front end still only supports TXT records. > Mark's suggestion is SPF is the preferred type, and TXT is compatibility > type in sequence. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Mon May 20 15:23:20 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6310921F9699 for ; Mon, 20 May 2013 15:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5uFNhnJhA+C for ; Mon, 20 May 2013 15:23:19 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 41A2D21F9675 for ; Mon, 20 May 2013 15:23:16 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 1DCA1C947D; Mon, 20 May 2013 22:23:07 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1369088595; bh=nV64uytH+tgQpP3dgnj+hcUZs9XakAb8Z41q7hfNBxQ=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=lxJOQrOsL0YO6987kWDRFNEcvqNr6OhyzaPNPYfGXXn0MvAVdhhcZRMH/c782x3bG IRYCO9CenYskGLYXqsRbMn41NXtc7G6znMmsQlG4D73/SsPXkIttT1tN6O7ftCkVp/ 6mKEkiwGejJkiEIZ6TviaLij1kyfnMo9Wc3hUuF8= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Mon, 20 May 2013 22:23:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 734F9216C43; Mon, 20 May 2013 22:23:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 99186348CB59; Tue, 21 May 2013 08:23:03 +1000 (EST) To: Scott Kitterman From: Mark Andrews References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <12569478.XPmz56gEZG@scott-latitude-e6320> <237F033C-4A72-41E4-8BE8-6837600A0E7E@ogud.com> <2559081.7IgQ8Mc0EM@scott-latitude-e6320> In-reply-to: Your message of "Mon, 20 May 2013 13:39:29 -0400." <2559081.7IgQ8Mc0EM@scott-latitude-e6320> Date: Tue, 21 May 2013 08:23:03 +1000 Message-Id: <20130520222303.99186348CB59@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: spfbis@ietf.org Subject: Re: [spfbis] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 22:23:20 -0000 In message <2559081.7IgQ8Mc0EM@scott-latitude-e6320>, Scott Kitterman writes: > On Monday, May 20, 2013 01:01:06 PM Olafur Gudmundsson wrote: > > On May 20, 2013, at 1:13 AM, Scott Kitterman wrote: > > > On Monday, May 20, 2013 02:54:18 PM Mark Andrews wrote: > > >> In message <20130520035329.GG33927@mx1.yitter.info>, Andrew Sullivan > writes: > > >>> Chair hat: this is a real question to the WG. > > >>> > > >>> On Sun, May 19, 2013 at 11:20:00PM -0400, Stuart Gathman wrote: > > >>>> Interestingly, I find that all the (rare) SPF RRs in the field I've > > >>>> encountered so far publish *only* SPF RR. Probably a wise > strategy. > > >>>> The "publish both" recommendation in rfc4408 is problematic. > > >>> > > >>> Given our charter, what conclusion for our work product do you think > > >>> should produce? > > >> > > >> Well given removal of features that are in use is prohibited and > > >> that SPF records are both looked up (libspf2) and published (8% of > > >> domains that publish SPF record publish a type 99 SPF record) and > > >> there are not significantly different failure rates. I respectfully > > >> suggest that we require that type 99 records be looked up first and > > >> that type TXT records be looked up on SERVFAIL or a NODATA response. > > > > > > That would be a ridiculous design. > > > > Why ? > > This is the right way to build fallback in DNS given the installed > base, ask > > for one type and if it is not available try the fallback. > > If your client can do queries in parallel then you can do both and use > one > > of the ones that returns an positive answer, but in that case there is a > > race condition if both return and the two types differ, that can be > > addressed by preferred type rule. Mark's suggestion is SPF is the > preferred > > type, and TXT is compatibility type in sequence. You may disagree with > that > > order . > > There's no value proposition for receivers. We've been through all this > in the working group before, but I'll give at least a summary ... > > In RFC 4408 there is an interoperability defect. Senders can publish TXT > or SPF types and meet the requirements in 4408. Receivers can publish > TXT or SPF and similarly meet the requirements of 4408. We concluded > that to be interoperable there had to be a common format that senders > MUST publish and receivers MUST check, otherwise they could end up > completely failing to communicate. And the SHOULD publish both records could be encoded into nameservers but unless you ask they are unlikely to do it. Note I do not believe this is a real defect. The final state should be SPF queries and records only which RFC 4408 permitted the same as it permitted TXT queries and records only to make the pre RFC 4408 situation compatible with RFC 4408. > We considered to which type to make the MUST format and concluded that > given the overwhelming deployed based for TXT only versus SPF only > (publishers that publish both SPF and TXT can be ignored for this > analysis), making TXT the mandatory format was the only thing that made > sense. And the number SPF record has gone from 4% to 8% in the last two years and will only continue to increase. > Given that, checking type TXT first is the only sensible approach. No it isn't the only sensible approach. There wouldn't be this arguement if it was. > Then > you have to consider the value proposition of a follow-on type SPF check. > Once the TXT lookup is complete, you have ~98% of the SPF records you > are going to get. Offsetting the value of trying to get those few > additional records are not only the costs of doing the queries (virtually > none of which will return useful information), but also the delays caused > by DNS servers that timeout for TYpe SPF (but not TXT) that can slow down > busy mail streams. > > As a receiver, I don't see the value in getting those last few records > that's worth not only the added resources, but the additional complexity > in code. I get the protocol purity argument, but in the real world, I > don't think people care. If you look as SPF in isolation you come to that conculsion if you look with a broader perspective you come to different conclusions. > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ajs@anvilwalrusden.com Mon May 20 16:02:55 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F73A21F9674 for ; Mon, 20 May 2013 16:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BC0Ha6RWxmR9 for ; Mon, 20 May 2013 16:02:49 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9579021F9662 for ; Mon, 20 May 2013 16:02:49 -0700 (PDT) Received: from mx1.yitter.info (unknown [38.126.117.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 837D88A035 for ; Mon, 20 May 2013 23:02:48 +0000 (UTC) Date: Mon, 20 May 2013 19:02:51 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130520230250.GB17439@mx1.yitter.info> References: <6.2.5.6.2.20130423150008.0c2c0558@elandnews.com> <12569478.XPmz56gEZG@scott-latitude-e6320> <237F033C-4A72-41E4-8BE8-6837600A0E7E@ogud.com> <2559081.7IgQ8Mc0EM@scott-latitude-e6320> <20130520222303.99186348CB59@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130520222303.99186348CB59@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Obsoleting SPF RRTYPE X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 23:02:55 -0000 Chair hat on. On Tue, May 21, 2013 at 08:23:03AM +1000, Mark Andrews wrote: > > If you look as SPF in isolation you come to that conculsion if you > look with a broader perspective you come to different conclusions. As Dave Crocker pointed out elsewhere in this thread, there was already a considerable number of electrons spilled on this topic. The above claim, however, appears to be hinting at a new argument. Unfortunately, instead of actually making the argument, it merely hints that there is one. If this is the one about polluting TXT space, I think you will find that argument _was_ considered in the previous discussions. I urge those with a temptation to weigh in on this topic to please review the history of the topic in the WG before saying more. If that's _not_ the argument, then what is the argument, please? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Mon May 20 21:46:03 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C0C21F975D for ; Mon, 20 May 2013 21:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IuSd4mS2V8S for ; Mon, 20 May 2013 21:45:59 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAD321F869F for ; Mon, 20 May 2013 21:45:58 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 180E420E40D6; Tue, 21 May 2013 00:45:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369111558; bh=SsgLgP/ZnMx3ZE0uS4dkHaKpq4FbmSWaO4Sw/5XE2nY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WvdeMd0/Jx+QGI45uNrg3+7U3C0yLo1Z9RuDRmw82geVFrXYSSKfdNFb76Aa4FmV3 kJ6aLiOVe7wpvFcWoZa4aO9LYScoDYymEnZINL9Kd6jbE3987HFc8uu2OcakivKZA6 Eqv7nGqlvyqct5qiTwVSm4WL5yf9eatiBBtnAO9c= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id EEF0120E40D4; Tue, 21 May 2013 00:45:57 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 21 May 2013 00:45:56 -0400 Message-ID: <3128599.YnUERkyy2J@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130429100907.0d0cab88@elandnews.com> References: <6.2.5.6.2.20130429100907.0d0cab88@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Gen-ART Last Call review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 04:46:03 -0000 On Monday, April 29, 2013 10:14:28 AM S Moonesamy wrote: > Hi Meral, > > Thanks for the review. I am forwarding it to the SPFBIS mailing list > for discussion. I'll email you in a few days to address your comments. > > Regards, > S. Moonesamy (as document shepherd) > > At 08:53 29-04-2013, Meral Shirazipour wrote: > >I am the assigned Gen-ART reviewer for this draft. For background on > >Gen-ART, please see the FAQ at > >http://wiki.tools. > >ietf.org/area/gen/trac/wiki/GenArtfaq . > > > >Please resolve these comments along with any other Last Call > >comments you may receive. > > > >Document: draft-ietf-spfbis-4408bis-14 > >Reviewer: Meral Shirazipour > >Review Date: 2013-04-29 > >IETF LC End Date: 2013-04-30 > >IESG Telechat date: NA > > > > > > > >Summary: > >This draft is almost ready to be published as Informational RFC but > >I do have some comments. > > > > > >Nits/editorial comments: > >-[Page 6] Section "1.1.2. Imported Definitions" > >Please consider expanding acronyms and giving the section of the RFC > >where each term is defined. > >(Also throughout the document it would greatly help the readability > >if acronyms are expanded when first used.) Done to the extent I found issues. ABNF was expaned in 4.6.1 and I moved the expansion up to 1.1.2. If anyone notices any missing, please point them out. > > > >-[Page 8] Section 2.2. Line 1: > >""MAIL FROM" -> extra \" Fixed. > >-[Page 13], Section 3.3. , first line: "sections 3.3.14 and 3.3". > >If both subsection and subsubsection are to be mentioned, please > >consider: "sections 3.3 and 3.3.14" Fixed. > >-[Page 16], Section 4.3, paragraph 1, last sentence: extra text/typo > >to be removed: "on 2.3 of [RFC5890]." Fixed. > >-[Page 16], Section 4.4, paragraph 3,"[RFC2308] suggests on an" > >--remove "on"--> "[RFC2308] suggests an" Text removed due to other comments. > >-[Page 21], Section 5.1, line 1, > >"This section defines two types of mechanisms." --for clarity--> > >"This section defines two types of mechanisms: basic and designated > >sender." I now have: > This section defines two types of mechanisms: basic language framework > mechanisms and designated sender mechanisms. > >-[Page 21], second paragraph before last, " both "AAAA" and "A" > >secords "--typo--> "records" Fixed. > >-[Page 22], Section 5.2, point 3, please review "include: > >mechanism" and "\"fail ". > >Suggestion: instead of "gives a pass" or "gives a fail" is it better > >to say "signifies" or "represents" as pass/fail? I went with "produces". > >-[Page 22], second paragraph before last, > >"Only the evaluated result of the referenced SPF record is used, > >rather than acting as if the referenced SPF > >record was literally included in the first." > >The part after the comma in this sentence is hard to understand. > >Please review if possible. I agree it's convoluted (it's also unchanged from RFC 4408). Here's what I came up with. Is this better? > Only the evaluated result of the referenced SPF record is used, rather than > literally including the mechanisms of the referenced record in the first. > >-[Page 24], Section 5.4, > >"the evaluation terminated"--missing is-->"the evaluation is terminated" > >"has no MX records"--no s-->"has no MX record" Fixed. > >-[Page 26], first paragraph, > >"and more reliable alternatives used instead"---->"and more reliable > >alternatives should be used instead" Fixed. > >"still in use and part of"---->"still in use as part of" Fixed. > >-[Page 29], paragraph 3, > >"is generally be"---->"will generally be" Fixed. > >-[Page 30], paragraph 1, > >"such as shown in Section 2.6.4",- is this pointing to the correct section? No. The text got moved when the WG reorganized the document, but the reference wasn't updated. I've fixed it now. > >-[Page 30], last sentence > >"Note: During recursion into an "include" mechanism, an exp= modifier > > > > from the MUST NOT be used. In contrast, when executing > > a "redirect" modifier, an exp= modifier from the original domain MUST > > NOT be used. > > > >" > >Is it possible to add 1-2 sentence to explain why?(what is the > >expected consequence if this is not respected) Here's what I added: > This is because "include" is meant to cross administrative boundaries and > the explanation provided should be the one from the receiving ADMD, while > "redirect" is meant to operate as a tool to consolidate policy records > within an ADMD an so the redirected explanation is the one that ought to > have priority. > >-[Page 32], line 3, > >"p = the validated domain name of (do not use)" > >Is it possible to add a reference to section 5.5 which explains why? > >Suggested: "(do not use, see Section 5.5)" In the details about the macros below, it says "This macro SHOULD NOT be used (see Section 5.5 for the discussion)." I think this is sufficient. > >-[Page 33], third paragraph before last > >"was provide more than once"---->"was provided more than once" Fixed > >-[Page 34], last "Note": > >"....for as long as the shortest Time To Live (TTL) of all the DNS > >records involved." > >Please review this sentence ending. It is not clear. > >Suggestion: "as long as the DNS record involved with the shortest > >TTL has not expired" ? Done. Thaks. > >-[Page 36], sentence 2, "Terse definitions"--typo-->"The definitions" Fixed. > >-[Page 36], paragraph 2,"be explicity"--typo-->"be explicitly" Fixed. > >-[Page 36], Section 8.1,"checked idenity"--typo-->"checked identity" Fixed. > >-[Page 37], Section 8.4, "the 5.7.1 enhanced status code", with > >reference to RFC3463. > >For better clarity please consider adding reference to Section 3.8 > >of the RFC3463. Added. > >-[Page 38], Section 8.6, > >For better clarity please consider referring to Section 3.5 of RFC3463 Added. > >-[Page 38], Section 8.8, > >For better clarity please consider referring to Section 3.6 of RFC3463 Added. > >-[Page 39], Section 9 Title, "Recording The Result"---->"the" Done. > >-[Page 44], Line 2, "carefully weight"---->"carefully weigh" Fixed. > >-[Page 44], Section 10.1.2, ""ip4" and "ip6" over "a" or "a" or "mx"." > >The last part should suggest "mx' over "a" or the reverse? It should suggest "a" over "mx" and if I change the last or to over, it does. > >-[Page 46], Section 10.3 "User actor.[RFC5598]."---->"User actor > >[RFC5598]." Fixed. > >-[Page 47], before last sentence, missing closing > >parenthesis:"(defined in Section 4.6.4." Fixed. > >-[Page 49], Section 11.5.3, "It is necesary"--typo-->"It is necessary" Fixed. > >-[Page 62], line 2, "to implmentation"--typo-->"to implementation" Fixed. > >-[Page 62], second bullet before last, "Section 10 and Appendices D > >- H below.", is this part of the sentence refering to anything, below? It's referring to the new information in section 10 and appendicies D - H. > >-[Page 65], Section E.3, "Receving ADMDs"--typo-->"Receiving ADMDs" Fixed. > >-[Page 66], last line, "mitiate"--typo-->"mitigate" Fixed. > >-[Page 68], one line before last, "reliabilility"--typo-->"reliability" Fixed > >-[Page 70], paragraphe 2, > >"techincal"--typo-->"technical" > >"deplyment"--typo-->"deployment" Fixed. > >-[Page 72], line 7, "obslete"--typo-->"obsolete" Fixed. > >-[Page 72], 2 line before last, "text and figures from Alessandro > >Vesely", is it only to section 9.1, or 10.1.1. as well? It was 10.1.1, but the figure's been removed due to other comments, so I'll adjust. > >-[Page 73], "Added new section 9 discussion on treatment of > >bounces", is it section 9 or section 10.1.3? 10.1.3. > >-[Page 73], 1 line before last, "potental"--typo-->"potential" Fixed. > >-Appendix J., please review the 'section references' pointing to > >various changes. Did this. > > > > > >-Throughout the draft, DNS "look up"---->"lookup" Fixed. > >-Throughout the draft, DNS RCODEs are mentioned without any > >reference to RFC1035 (or RFC6195) I added a reference to 1035 in 4.3, which is the first place RCODEs are mentioned. > >-Throughout the draft, many cross references break the follow. I > >suggested revisiting some of them and adding a small text after each > >reference which introduces that section. > >Example :[Page 17], Section 4.6.2 "the result is specified in > >Section 4.7", suggested-->"the result is specified in Section 4.7 > >where Default results are discussed" This particular one has been changed based on other comments. > >-"Section 2.6 Results of Evaluation" lists the possible outputs of > >check_host(). > >Then "Section 8. Result Handling" continues the description with > >handling guidance. > >To avoid breaking the flow, please consider moving the descriptive > >content of Section 2.6 into Section 8. (unless there is another > >reason to keep them far apart). As Murray replied already, they are separated for a reason that has the rough consensus of the group (as far as I can tell). We've made some adjustments that should help. Thanks for the detailed review. Scott K From spf2@kitterman.com Mon May 20 21:48:49 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1114D21F975D for ; Mon, 20 May 2013 21:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVUfUukzI-pE for ; Mon, 20 May 2013 21:48:44 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9086621F975B for ; Mon, 20 May 2013 21:48:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 24BB120E40D6; Tue, 21 May 2013 00:48:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369111724; bh=hiCysLqM1yMHWvytQyqtnvw5a5huRWmRM0dI4gzR/44=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EOOrmy4Fvn3hYcBDxitpOo4qSouPOq10d+j6BNx28cILyp5T9/tSmOz4/G/MycM+F jdRk0aK6mY1UYpXkFMXm0rU1JIaDtQSHGUqLuvzTyOaP0ilq+OiHcdXxRQm/BXqleM 4rl9V2bK+VVZ5Oq9qZBduj1sfEGO5XDivo2HsYcA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0E23D20E40D4; Tue, 21 May 2013 00:48:43 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 21 May 2013 00:48:43 -0400 Message-ID: <1899050.5TqR9ouOXZ@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130518101418.0bbf6848@elandnews.com> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <4504827.dqlBOFqUut@scott-latitude-e6320> <6.2.5.6.2.20130518101418.0bbf6848@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Addressing reviews (was: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 04:48:49 -0000 On Saturday, May 18, 2013 10:35:03 AM S Moonesamy wrote: > The Gen-ART review of draft-ietf-spfbis-4408bis-14 was posted on > April 29 ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg03647.html > ). There weren't any comments about that review. Commented (should hit the list before this does). > The Applications Area directorate review was posted on April 29 ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg03633.html It's almost 1AM here and I'm out of steam for the night. I'll try to get to this one tomorrow. Scott K From sm@elandsys.com Tue May 21 00:01:44 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFF321F9726; Tue, 21 May 2013 00:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.08 X-Spam-Level: X-Spam-Status: No, score=-102.08 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hw7RqIcVte8Q; Tue, 21 May 2013 00:01:37 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6C121F8F4D; Tue, 21 May 2013 00:01:36 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.130.208]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4L71EZn005430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 May 2013 00:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1369119689; bh=v6lzwXL16qlPeR/irguWOJK2GNwsiITn3FazhfOMoLU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=gLPK0bJ8KT1S275THmrSx/Mlh/b3pVv9hsYHPi2+bdlGXmQaXN8mIY6fcOYc2g6A5 zyIeDXHicBextPTM/SDcelzlvt3gRxS1dZbR+Ut9y3Yggd24MHTg+nGfaPvCu7u1Ja Buqe6++h7nIYj526pp0UlYes5yUoA5wtJcW0oHeI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1369119689; i=@elandsys.com; bh=v6lzwXL16qlPeR/irguWOJK2GNwsiITn3FazhfOMoLU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FkArel5107qGm53VQdcZKVQTex4SLgtVouFhKW1j7EB5tVCwJW2yVplyGS+J//abw Kdo/z5xeSmkmPG6HH2KD2UrQBX5Lyv/iqN6wib7eRRAc1PDNcOxJCc9DqURpcH/7XC rkVQZOwkKoC6pDG6WctWrxyHns7WRfxI0Od9xEac= Message-Id: <6.2.5.6.2.20130520225117.0cbd8c08@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 May 2013 22:55:48 -0700 To: Meral Shirazipour From: S Moonesamy In-Reply-To: <3128599.YnUERkyy2J@scott-latitude-e6320> References: <6.2.5.6.2.20130429100907.0d0cab88@elandnews.com> <3128599.YnUERkyy2J@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, gen-art@ietf.org, Scott Kitterman Subject: Re: [spfbis] Gen-ART Last Call review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 07:01:44 -0000 Hi Meral, Thanks for the detailed review. I am forwarding the response. Please let me know if the Gen-ART review has not been addressed. Regards, S. Moonesamy (as document shepherd) > > At 08:53 29-04-2013, Meral Shirazipour wrote: > > >I am the assigned Gen-ART reviewer for this draft. For background on > > >Gen-ART, please see the FAQ at > > >http://w > iki.tools. > > >ietf.org/area/gen/trac/wiki/GenArtfaq . > > > > > >Please resolve these comments along with any other Last Call > > >comments you may receive. > > > > > >Document: draft-ietf-spfbis-4408bis-14 > > >Reviewer: Meral Shirazipour > > >Review Date: 2013-04-29 > > >IETF LC End Date: 2013-04-30 > > >IESG Telechat date: NA > > > > > > > > > > > >Summary: > > >This draft is almost ready to be published as Informational RFC but > > >I do have some comments. > > > > > > > > >Nits/editorial comments: > > >-[Page 6] Section "1.1.2. Imported Definitions" > > >Please consider expanding acronyms and giving the section of the RFC > > >where each term is defined. > > >(Also throughout the document it would greatly help the readability > > >if acronyms are expanded when first used.) > >Done to the extent I found issues. ABNF was expaned in 4.6.1 and I moved the >expansion up to 1.1.2. If anyone notices any missing, please point them out. > > > > > > >-[Page 8] Section 2.2. Line 1: > > >""MAIL FROM" -> extra \" > >Fixed. > > > >-[Page 13], Section 3.3. , first line: "sections 3.3.14 and 3.3". > > >If both subsection and subsubsection are to be mentioned, please > > >consider: "sections 3.3 and 3.3.14" > >Fixed. > > > >-[Page 16], Section 4.3, paragraph 1, last sentence: extra text/typo > > >to be removed: "on 2.3 of [RFC5890]." > >Fixed. > > > >-[Page 16], Section 4.4, paragraph 3,"[RFC2308] suggests on an" > > >--remove "on"--> "[RFC2308] suggests an" > >Text removed due to other comments. > > > >-[Page 21], Section 5.1, line 1, > > >"This section defines two types of mechanisms." --for clarity--> > > >"This section defines two types of mechanisms: basic and designated > > >sender." > >I now have: > > This section defines two types of mechanisms: basic language framework > > mechanisms and designated sender mechanisms. > > > >-[Page 21], second paragraph before last, " both "AAAA" and "A" > > >secords "--typo--> "records" > >Fixed. > > > >-[Page 22], Section 5.2, point 3, please review "include: > > >mechanism" and "\"fail ". > > >Suggestion: instead of "gives a pass" or "gives a fail" is it better > > >to say "signifies" or "represents" as pass/fail? > >I went with "produces". > > > >-[Page 22], second paragraph before last, > > >"Only the evaluated result of the referenced SPF record is used, > > >rather than acting as if the referenced SPF > > >record was literally included in the first." > > >The part after the comma in this sentence is hard to understand. > > >Please review if possible. > >I agree it's convoluted (it's also unchanged from RFC 4408). Here's what I >came up with. Is this better? > > > Only the evaluated result of the referenced SPF record is used, rather than > > literally including the mechanisms of the referenced record in the first. > > > >-[Page 24], Section 5.4, > > >"the evaluation terminated"--missing is-->"the evaluation is terminated" > > >"has no MX records"--no s-->"has no MX record" > >Fixed. > > > >-[Page 26], first paragraph, > > >"and more reliable alternatives used instead"---->"and more reliable > > >alternatives should be used instead" > >Fixed. > > > >"still in use and part of"---->"still in use as part of" > >Fixed. > > > >-[Page 29], paragraph 3, > > >"is generally be"---->"will generally be" > >Fixed. > > > >-[Page 30], paragraph 1, > > >"such as shown in Section 2.6.4",- is this pointing to the > correct section? > >No. The text got moved when the WG reorganized the document, but the >reference wasn't updated. I've fixed it now. > > > >-[Page 30], last sentence > > >"Note: During recursion into an "include" mechanism, an exp= modifier > > > > > > from the MUST NOT be used. In contrast, when executing > > > a "redirect" modifier, an exp= modifier from the original domain MUST > > > NOT be used. > > > > > >" > > >Is it possible to add 1-2 sentence to explain why?(what is the > > >expected consequence if this is not respected) > >Here's what I added: > > > This is because "include" is meant to cross administrative boundaries and > > the explanation provided should be the one from the receiving ADMD, while > > "redirect" is meant to operate as a tool to consolidate policy records > > within an ADMD an so the redirected explanation is the one that ought to > > have priority. > > > >-[Page 32], line 3, > > >"p = the validated domain name of (do not use)" > > >Is it possible to add a reference to section 5.5 which explains why? > > >Suggested: "(do not use, see Section 5.5)" > >In the details about the macros below, it says "This macro SHOULD NOT be used >(see Section 5.5 for the discussion)." I think this is sufficient. > > > >-[Page 33], third paragraph before last > > >"was provide more than once"---->"was provided more than once" > >Fixed > > > >-[Page 34], last "Note": > > >"....for as long as the shortest Time To Live (TTL) of all the DNS > > >records involved." > > >Please review this sentence ending. It is not clear. > > >Suggestion: "as long as the DNS record involved with the shortest > > >TTL has not expired" ? > >Done. Thaks. > > > >-[Page 36], sentence 2, "Terse definitions"--typo-->"The definitions" > >Fixed. > > > >-[Page 36], paragraph 2,"be explicity"--typo-->"be explicitly" > >Fixed. > > > >-[Page 36], Section 8.1,"checked idenity"--typo-->"checked identity" > >Fixed. > > > >-[Page 37], Section 8.4, "the 5.7.1 enhanced status code", with > > >reference to RFC3463. > > >For better clarity please consider adding reference to Section 3.8 > > >of the RFC3463. > >Added. > > > >-[Page 38], Section 8.6, > > >For better clarity please consider referring to Section 3.5 of RFC3463 > >Added. > > > >-[Page 38], Section 8.8, > > >For better clarity please consider referring to Section 3.6 of RFC3463 > >Added. > > > >-[Page 39], Section 9 Title, "Recording The Result"---->"the" > >Done. > > > >-[Page 44], Line 2, "carefully weight"---->"carefully weigh" > >Fixed. > > > >-[Page 44], Section 10.1.2, ""ip4" and "ip6" over "a" or "a" or "mx"." > > >The last part should suggest "mx' over "a" or the reverse? > >It should suggest "a" over "mx" and if I change the last or to over, it does. > > > >-[Page 46], Section 10.3 "User actor.[RFC5598]."---->"User actor > > >[RFC5598]." > >Fixed. > > > >-[Page 47], before last sentence, missing closing > > >parenthesis:"(defined in Section 4.6.4." > >Fixed. > > > >-[Page 49], Section 11.5.3, "It is necesary"--typo-->"It is necessary" > >Fixed. > > > >-[Page 62], line 2, "to implmentation"--typo-->"to implementation" > >Fixed. > > > >-[Page 62], second bullet before last, "Section 10 and Appendices D > > >- H below.", is this part of the sentence refering to anything, below? > >It's referring to the new information in section 10 and appendicies D - H. > > > >-[Page 65], Section E.3, "Receving ADMDs"--typo-->"Receiving ADMDs" > >Fixed. > > > >-[Page 66], last line, "mitiate"--typo-->"mitigate" > >Fixed. > > > >-[Page 68], one line before last, "reliabilility"--typo-->"reliability" > >Fixed > > > >-[Page 70], paragraphe 2, > > >"techincal"--typo-->"technical" > > >"deplyment"--typo-->"deployment" > >Fixed. > > > >-[Page 72], line 7, "obslete"--typo-->"obsolete" > >Fixed. > > > >-[Page 72], 2 line before last, "text and figures from Alessandro > > >Vesely", is it only to section 9.1, or 10.1.1. as well? > >It was 10.1.1, but the figure's been removed due to other comments, so I'll >adjust. > > > >-[Page 73], "Added new section 9 discussion on treatment of > > >bounces", is it section 9 or section 10.1.3? > >10.1.3. > > > >-[Page 73], 1 line before last, "potental"--typo-->"potential" > >Fixed. > > > >-Appendix J., please review the 'section references' pointing to > > >various changes. > >Did this. > > > > > > > > >-Throughout the draft, DNS "look up"---->"lookup" > >Fixed. > > > >-Throughout the draft, DNS RCODEs are mentioned without any > > >reference to RFC1035 (or RFC6195) > >I added a reference to 1035 in 4.3, which is the first place RCODEs are >mentioned. > > > >-Throughout the draft, many cross references break the follow. I > > >suggested revisiting some of them and adding a small text after each > > >reference which introduces that section. > > >Example :[Page 17], Section 4.6.2 "the result is specified in > > >Section 4.7", suggested-->"the result is specified in Section 4.7 > > >where Default results are discussed" > >This particular one has been changed based on other comments. > > > >-"Section 2.6 Results of Evaluation" lists the possible outputs of > > >check_host(). > > >Then "Section 8. Result Handling" continues the description with > > >handling guidance. > > >To avoid breaking the flow, please consider moving the descriptive > > >content of Section 2.6 into Section 8. (unless there is another > > >reason to keep them far apart). > >As Murray replied already, they are separated for a reason that has the rough >consensus of the group (as far as I can tell). We've made some adjustments >that should help. > >Thanks for the detailed review. > >Scott K >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From meral.shirazipour@ericsson.com Tue May 21 12:35:46 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B24C11E80FD; Tue, 21 May 2013 12:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+acckUVmx3l; Tue, 21 May 2013 12:35:40 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9393B11E80F8; Tue, 21 May 2013 12:35:40 -0700 (PDT) X-AuditID: c6180641-b7f7b6d000001a44-b1-519bcc8b99b8 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B7.AC.06724.B8CCB915; Tue, 21 May 2013 21:35:40 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Tue, 21 May 2013 15:35:39 -0400 From: Meral Shirazipour To: S Moonesamy Thread-Topic: [spfbis] Gen-ART Last Call review of draft-ietf-spfbis-4408bis-14 Thread-Index: AQHOVfEK79wlaS2kkkGJbtF4DEEAdZkQCMTw Date: Tue, 21 May 2013 19:35:38 +0000 Message-ID: References: <6.2.5.6.2.20130429100907.0d0cab88@elandnews.com> <3128599.YnUERkyy2J@scott-latitude-e6320> <6.2.5.6.2.20130520225117.0cbd8c08@resistor.net> In-Reply-To: <6.2.5.6.2.20130520225117.0cbd8c08@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyuXSPn27PmdmBBkf+sVlcffWZxeJV/01W i8cr7rBaPJ25n92BxePem49MHkuW/GTy+L5qF3sAcxSXTUpqTmZZapG+XQJXxspPU9gLbgVW 9K2bxtTA2ODYxcjBISFgItF/kbOLkRPIFJO4cG89WxcjF4eQwFFGiVkHH7JAOMsZJZY9WcIE UsUmYCGx/fdzVpBmEQE1iX0z00HCzAJlEtuvXWAGsYUFAiW6Dl1jBbFFBIIk/u1cAmUbSaw7 9oQdxGYRUJVYeGkyG8gYXgFvicmzDCBW3WOUuL/wAVg9p4CtxMF1M9hAbEag476fWsMEsUtc 4taT+UwQRwtILNlznhnCFpV4+fgfK4StLLHkyX4WiHodiQW7P7FB2NoSyxa+BqvnFRCUODnz CcsERrFZSMbOQtIyC0nLLCQtCxhZVjFylBanluWmGxluYgRG0DEJNscdjAs+WR5ilOZgURLn 7daeGigkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMWG/wPSOBTvWP7woYtbAliJoe/5q287a FvXOxtLLgq38wicVvzJqSX3cfnLjd5YbpguvvFR1vOVXrZprHvsixOKRoFVMj8+OI1KhQd5W 5RHLJ/+4JyE0/2miw/345M1FwanZZ4M5jnc8n/XUntNDa4vYw13vDU/vfFR8OP6ayNblbEs5 eBceUmIpzkg01GIuKk4EAC5mL5JuAgAA X-Mailman-Approved-At: Tue, 21 May 2013 12:53:38 -0700 Cc: "spfbis@ietf.org" , "gen-art@ietf.org" , Scott Kitterman Subject: Re: [spfbis] Gen-ART Last Call review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 19:35:46 -0000 Hi, Yes, thank you Best Regards, Meral -----Original Message----- From: S Moonesamy [mailto:sm+ietf@elandsys.com]=20 Sent: Monday, May 20, 2013 22:56 To: Meral Shirazipour Cc: Scott Kitterman; gen-art@ietf.org; spfbis@ietf.org Subject: Re: [spfbis] Gen-ART Last Call review of draft-ietf-spfbis-4408bis= -14 Importance: High Hi Meral, Thanks for the detailed review. I am forwarding the response. Please let = me know if the Gen-ART review has not been addressed. Regards, S. Moonesamy (as document shepherd) > > At 08:53 29-04-2013, Meral Shirazipour wrote: > > >I am the assigned Gen-ART reviewer for this draft. For background=20 > > >on Gen-ART, please see the FAQ at=20 > > >http://w > iki.tools. > > >ietf.org/area/gen/trac/wiki/GenArtfaq . > > > > > >Please resolve these comments along with any other Last Call=20 > > >comments you may receive. > > > > > >Document: draft-ietf-spfbis-4408bis-14 > > >Reviewer: Meral Shirazipour > > >Review Date: 2013-04-29 > > >IETF LC End Date: 2013-04-30 > > >IESG Telechat date: NA > > > > > > > > > > > >Summary: > > >This draft is almost ready to be published as Informational RFC but=20 > > >I do have some comments. > > > > > > > > >Nits/editorial comments: > > >-[Page 6] Section "1.1.2. Imported Definitions" > > >Please consider expanding acronyms and giving the section of the=20 > > >RFC where each term is defined. > > >(Also throughout the document it would greatly help the readability=20 > > >if acronyms are expanded when first used.) > >Done to the extent I found issues. ABNF was expaned in 4.6.1 and I=20 >moved the expansion up to 1.1.2. If anyone notices any missing, please po= int them out. > > > > > > >-[Page 8] Section 2.2. Line 1: > > >""MAIL FROM" -> extra \" > >Fixed. > > > >-[Page 13], Section 3.3. , first line: "sections 3.3.14 and 3.3". > > >If both subsection and subsubsection are to be mentioned, please > > >consider: "sections 3.3 and 3.3.14" > >Fixed. > > > >-[Page 16], Section 4.3, paragraph 1, last sentence: extra=20 > > >text/typo to be removed: "on 2.3 of [RFC5890]." > >Fixed. > > > >-[Page 16], Section 4.4, paragraph 3,"[RFC2308] suggests on an" > > >--remove "on"--> "[RFC2308] suggests an" > >Text removed due to other comments. > > > >-[Page 21], Section 5.1, line 1, > > >"This section defines two types of mechanisms." --for clarity-->=20 > > >"This section defines two types of mechanisms: basic and designated=20 > > >sender." > >I now have: > > This section defines two types of mechanisms: basic language framewo= rk > > mechanisms and designated sender mechanisms. > > > >-[Page 21], second paragraph before last, " both "AAAA" and "A" > > >secords "--typo--> "records" > >Fixed. > > > >-[Page 22], Section 5.2, point 3, please review "include: > > >mechanism" and "\"fail ". > > >Suggestion: instead of "gives a pass" or "gives a fail" is it=20 > > >better to say "signifies" or "represents" as pass/fail? > >I went with "produces". > > > >-[Page 22], second paragraph before last, "Only the evaluated=20 > > >result of the referenced SPF record is used, rather than acting as=20 > > >if the referenced SPF record was literally included in the first." > > >The part after the comma in this sentence is hard to understand. > > >Please review if possible. > >I agree it's convoluted (it's also unchanged from RFC 4408). Here's=20 >what I came up with. Is this better? > > > Only the evaluated result of the referenced SPF record is used,=20 > > rather than literally including the mechanisms of the referenced record= in the first. > > > >-[Page 24], Section 5.4, > > >"the evaluation terminated"--missing is-->"the evaluation is terminate= d" > > >"has no MX records"--no s-->"has no MX record" > >Fixed. > > > >-[Page 26], first paragraph, > > >"and more reliable alternatives used instead"---->"and more=20 > > >reliable alternatives should be used instead" > >Fixed. > > > >"still in use and part of"---->"still in use as part of" > >Fixed. > > > >-[Page 29], paragraph 3, > > >"is generally be"---->"will generally be" > >Fixed. > > > >-[Page 30], paragraph 1, > > >"such as shown in Section 2.6.4",- is this pointing to the > correct section? > >No. The text got moved when the WG reorganized the document, but the=20 >reference wasn't updated. I've fixed it now. > > > >-[Page 30], last sentence > > >"Note: During recursion into an "include" mechanism, an exp=3D=20 > > >modifier > > > > > > from the MUST NOT be used. In contrast, when execut= ing > > > a "redirect" modifier, an exp=3D modifier from the original domain= MUST > > > NOT be used. > > > > > >" > > >Is it possible to add 1-2 sentence to explain why?(what is the=20 > > >expected consequence if this is not respected) > >Here's what I added: > > > This is because "include" is meant to cross administrative=20 > > boundaries and the explanation provided should be the one from the=20 > > receiving ADMD, while "redirect" is meant to operate as a tool to=20 > > consolidate policy records within an ADMD an so the redirected=20 > > explanation is the one that ought to have priority. > > > >-[Page 32], line 3, > > >"p =3D the validated domain name of (do not use)" > > >Is it possible to add a reference to section 5.5 which explains why? > > >Suggested: "(do not use, see Section 5.5)" > >In the details about the macros below, it says "This macro SHOULD NOT=20 >be used (see Section 5.5 for the discussion)." I think this is sufficient= . > > > >-[Page 33], third paragraph before last "was provide more than=20 > > >once"---->"was provided more than once" > >Fixed > > > >-[Page 34], last "Note": > > >"....for as long as the shortest Time To Live (TTL) of all the DNS=20 > > >records involved." > > >Please review this sentence ending. It is not clear. > > >Suggestion: "as long as the DNS record involved with the shortest=20 > > >TTL has not expired" ? > >Done. Thaks. > > > >-[Page 36], sentence 2, "Terse definitions"--typo-->"The definitions" > >Fixed. > > > >-[Page 36], paragraph 2,"be explicity"--typo-->"be explicitly" > >Fixed. > > > >-[Page 36], Section 8.1,"checked idenity"--typo-->"checked identity" > >Fixed. > > > >-[Page 37], Section 8.4, "the 5.7.1 enhanced status code", with=20 > > >reference to RFC3463. > > >For better clarity please consider adding reference to Section 3.8=20 > > >of the RFC3463. > >Added. > > > >-[Page 38], Section 8.6, > > >For better clarity please consider referring to Section 3.5 of=20 > > >RFC3463 > >Added. > > > >-[Page 38], Section 8.8, > > >For better clarity please consider referring to Section 3.6 of=20 > > >RFC3463 > >Added. > > > >-[Page 39], Section 9 Title, "Recording The Result"---->"the" > >Done. > > > >-[Page 44], Line 2, "carefully weight"---->"carefully weigh" > >Fixed. > > > >-[Page 44], Section 10.1.2, ""ip4" and "ip6" over "a" or "a" or "mx"." > > >The last part should suggest "mx' over "a" or the reverse? > >It should suggest "a" over "mx" and if I change the last or to over, it do= es. > > > >-[Page 46], Section 10.3 "User actor.[RFC5598]."---->"User actor=20 > > >[RFC5598]." > >Fixed. > > > >-[Page 47], before last sentence, missing closing=20 > > >parenthesis:"(defined in Section 4.6.4." > >Fixed. > > > >-[Page 49], Section 11.5.3, "It is necesary"--typo-->"It is necessary" > >Fixed. > > > >-[Page 62], line 2, "to implmentation"--typo-->"to implementation" > >Fixed. > > > >-[Page 62], second bullet before last, "Section 10 and Appendices D > > >- H below.", is this part of the sentence refering to anything, below? > >It's referring to the new information in section 10 and appendicies D - H. > > > >-[Page 65], Section E.3, "Receving ADMDs"--typo-->"Receiving ADMDs" > >Fixed. > > > >-[Page 66], last line, "mitiate"--typo-->"mitigate" > >Fixed. > > > >-[Page 68], one line before last, "reliabilility"--typo-->"reliability= " > >Fixed > > > >-[Page 70], paragraphe 2, > > >"techincal"--typo-->"technical" > > >"deplyment"--typo-->"deployment" > >Fixed. > > > >-[Page 72], line 7, "obslete"--typo-->"obsolete" > >Fixed. > > > >-[Page 72], 2 line before last, "text and figures from Alessandro=20 > > >Vesely", is it only to section 9.1, or 10.1.1. as well? > >It was 10.1.1, but the figure's been removed due to other comments, so=20 >I'll adjust. > > > >-[Page 73], "Added new section 9 discussion on treatment of=20 > > >bounces", is it section 9 or section 10.1.3? > >10.1.3. > > > >-[Page 73], 1 line before last, "potental"--typo-->"potential" > >Fixed. > > > >-Appendix J., please review the 'section references' pointing to=20 > > >various changes. > >Did this. > > > > > > > > >-Throughout the draft, DNS "look up"---->"lookup" > >Fixed. > > > >-Throughout the draft, DNS RCODEs are mentioned without any=20 > > >reference to RFC1035 (or RFC6195) > >I added a reference to 1035 in 4.3, which is the first place RCODEs are=20 >mentioned. > > > >-Throughout the draft, many cross references break the follow. I=20 > > >suggested revisiting some of them and adding a small text after=20 > > >each reference which introduces that section. > > >Example :[Page 17], Section 4.6.2 "the result is specified in=20 > > >Section 4.7", suggested-->"the result is specified in Section 4.7=20 > > >where Default results are discussed" > >This particular one has been changed based on other comments. > > > >-"Section 2.6 Results of Evaluation" lists the possible outputs of=20 > > >check_host(). > > >Then "Section 8. Result Handling" continues the description with=20 > > >handling guidance. > > >To avoid breaking the flow, please consider moving the descriptive=20 > > >content of Section 2.6 into Section 8. (unless there is another=20 > > >reason to keep them far apart). > >As Murray replied already, they are separated for a reason that has the=20 >rough consensus of the group (as far as I can tell). We've made some=20 >adjustments that should help. > >Thanks for the detailed review. > >Scott K >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From vesely@tana.it Thu May 23 04:27:23 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2DC21F9673 for ; Thu, 23 May 2013 04:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Me92t6Im0YGn for ; Thu, 23 May 2013 04:27:18 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5511221F9670 for ; Thu, 23 May 2013 04:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1369308437; bh=I7PZJTGA7+5IoiqRDx++gLV8vI0iL41WuA69ne94+qM=; l=1925; h=Date:From:To:References:In-Reply-To; b=IwBOGfmyh3FR3n5cT85/alKfcfRfZfG9i7dD9xKND0x2BPSpJ1GFpc28KUGpZgofu ERfRfDzNrjstQRqy1HbeNVkgNqIgtsEtCcSkiFScmU6tqTkuRjwfpUC9lGN7F28xm1 ZnkmO2NsWiIqdHskfbYk5ZlhE6xWlslXdm9X+/hM= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.156] (pcale.tana [172.25.197.156]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Thu, 23 May 2013 13:27:17 +0200 id 00000000005DC02B.00000000519DFD15.00001F06 Message-ID: <519DFD15.7060109@tana.it> Date: Thu, 23 May 2013 13:27:17 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <2434269.5GrKsYB81B@scott-latitude-e6320> <2042974.EAbD7S3bRR@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 11:27:23 -0000 On Fri 17/May/2013 20:52:13 +0200 Murray S. Kucherawy wrote: > On Fri, May 17, 2013 at 11:41 AM, Scott Kitterman wrote: > >>>> From my point of view, we have a new proposed solution that >>>> the WG developed to a long standing issue. It seems a bit >>>> odd to then demand that it can only be part of the output of >>>> the WG if someone else implemented it. >>> >>> I'm not making that demand, but I do think it bolsters our >>> position if it's seen real world action. I don't have any >>> objection to including it. We just need to be prepared to push >>> on it if the WG agrees that it's what we want to say and it's >>> met with resistance. >> >> I think it's far better than leaving eventually permanent >> temperrors in the sending mail queue for the queue life. If >> someone has a better way to deal with it, then please suggest it. >> I don't particularly like the solution, I just think it's better >> than anything else we've got. > > +1. It has to have consensus though, so what do others think? I agree on the principle: Admins who wish to protect their domain names with SPF must be so clever as to serve their records timely. On Sat 18/May/2013 01:58:55 +0200 John Levine wrote: > > Well, sure, and it can be equally permanent if you get it when > doing an MX or A/AAAA lookup on the client side, leading to > repeated requeues until the message times out (RFC 5321 sec 5.1.) I > still don't see what merits different treatment. The difference is that the client side has a queue timeout, which the server misses in this case. The client may have a different strategy for these malfunctions, but there's no way to inform it. So, the server had better not reply 4xx for 5 days if it can determine the failure is not going to go away. If we agree it is a server policy issue, can it be addressed in a section on *Policy For SPF Temperror*, then? From sm@elandsys.com Thu May 23 09:25:06 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFF521F95FD for ; Thu, 23 May 2013 09:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUt2KVYVsmYX for ; Thu, 23 May 2013 09:25:03 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC68121F95FB for ; Thu, 23 May 2013 09:25:03 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.5]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4NGOmGi006356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 09:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1369326300; bh=j59C8NQZcoZwSkMe+hHb1BGOlzkC337jUzU/QTIOGz4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Gl/jJElCQrJA6FYoXwwvJXYhTMtrpjK3ucIs1+hXuW5Chbmv3VxvJvGXNQrkUbr2q eNB7uwJIg76mIueDayqDCYvM7RE+3TxJkPl98AttgiBcLdqQ8eS6zfZ/6bFitpNc7s CNAgSjkJUBa24671ivgAbAB7D/xY0wvfnj98aBCk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1369326300; i=@elandsys.com; bh=j59C8NQZcoZwSkMe+hHb1BGOlzkC337jUzU/QTIOGz4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JnCPf4opcM4vbL14Jx7xYmxJJEvgHdjtSTRHdgSjIJfJsOiFCPI8JWmi/swb8pzim Z0k44otPTNRyyzNfQzkEkTQCh9fXOV+BEexAwj1ocWC+r1GaCSqbsZxjjLh/uVvfDy 8+6SFAnJkb14BmUl5DC+nfQnwshg7EkFnE8wy6GY= Message-Id: <6.2.5.6.2.20130523082001.0dc51fe0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 May 2013 08:24:28 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <1899050.5TqR9ouOXZ@scott-latitude-e6320> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <4504827.dqlBOFqUut@scott-latitude-e6320> <6.2.5.6.2.20130518101418.0bbf6848@elandnews.com> <1899050.5TqR9ouOXZ@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Addressing reviews (was: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 16:25:06 -0000 Hi Scott, At 21:48 20-05-2013, Scott Kitterman wrote: >Commented (should hit the list before this does). Thanks, the Gen-ART review has been addressed ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03801.html ). >It's almost 1AM here and I'm out of steam for the night. I'll try to get to >this one tomorrow. Could you please provide an estimate date of when the Applications Area directorate and Security Directorate reviews will be addressed? Thanks, S. Moonesamy (as document shepherd) From spf2@kitterman.com Thu May 23 09:44:19 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082C421F9779 for ; Thu, 23 May 2013 09:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iy4Av7USkrB for ; Thu, 23 May 2013 09:44:03 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 371AF21F9397 for ; Thu, 23 May 2013 09:30:10 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 51AD220E40F7; Thu, 23 May 2013 12:30:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369326609; bh=URFDro5JVOmY3LVNrWRzMvfKGl9YxPzWsjsekOM3Gjc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=XOaY9cv2hnjd2IChzwnYnsiBLaVkW1jJSWiDGj9nA9J5VQo2HxF+Rw36CrbOsr7F9 WySTbXsSfI7WhGXwupGXV+/NgnY1BoQg6/ji0QscOz4clUjyjYQMdGCEmhKvrYJXLG vTBQ3ya/j928VZpwCZoSKrHkRxO10y/dpSNMBGTc= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3B4F720E4090; Thu, 23 May 2013 12:30:08 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 23 May 2013 12:30:06 -0400 Message-ID: <2524008.lj3isPCILN@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130523082001.0dc51fe0@resistor.net> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <1899050.5TqR9ouOXZ@scott-latitude-e6320> <6.2.5.6.2.20130523082001.0dc51fe0@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Addressing reviews (was: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 16:44:19 -0000 On Thursday, May 23, 2013 08:24:28 AM S Moonesamy wrote: > Hi Scott, > > At 21:48 20-05-2013, Scott Kitterman wrote: > >Commented (should hit the list before this does). > > Thanks, the Gen-ART review has been addressed ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg03801.html ). > > >It's almost 1AM here and I'm out of steam for the night. I'll try to get > >to this one tomorrow. > > Could you please provide an estimate date of when the Applications > Area directorate and Security Directorate reviews will be addressed? As we discussed previously, I think the discussion we've already had is sufficient response to the security review. I'm working on the applications area review today. Scott K From sm@elandsys.com Thu May 23 10:09:34 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0AC21F96D1; Thu, 23 May 2013 10:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eazeMl0Xvrk; Thu, 23 May 2013 10:09:24 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2304821F97AF; Thu, 23 May 2013 10:01:28 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.5]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4NH19tF023443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 10:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1369328483; bh=f2P5Im/Ou+JfF1Hocd/xVp2gEMi6IPhKKMZPn6qwNkY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QR/oNg8JfemcF/p+vLlpx4TS6MW89/guk7N/S97KnG2lU4rTUk8mx7nCbJn+dJneg prEoJm8g+N8NNs0ixKku5exwxyJODNOWICfoeWFzjseLnq2wfpJgf0eQMP/NRPi9WK 1UPYUpVnQMjrE94UgomphQ5e/v2T+0OMLOyfnei0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1369328483; i=@elandsys.com; bh=f2P5Im/Ou+JfF1Hocd/xVp2gEMi6IPhKKMZPn6qwNkY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=08CX6TUD0z2qwkfaYc70KJYz6AQzCkLkq+kXegVrxZuT15aS6cDuTDwnwCTaPfWzn deMJgFmh9V0fTpdCvz2pxMjFSiuDObUJPXi5ofUPZf8aQcduFOoNttQH3473V9ucUj Mp5I+uLAlfV8UIV1cpr2qI4frS/ekG7LqOk1qgCU= Message-Id: <6.2.5.6.2.20130523095247.0dc5a520@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 May 2013 10:01:02 -0700 To: Phillip Hallam-Baker From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [spfbis] draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 17:09:34 -0000 Hi Phillip, At 09:58 26-04-2013, Phillip Hallam-Baker wrote: >The document is clear and describes the SPF mechanism effectively. >The only quibble that I could find is that repeated mentions are >made of limiting the number of 'DNS queries' without specifying >whether these are individual queries or recursive. The count will >come out rather differently if looking up TXT/x.example.com counts >as one lookup or three. I think it is reasonably clear that this is >one but could not find an explicit statement to that effect. > >On the security side, the document addresses all the mail issues >that I can remember at this point and rather more besides. > >I think we have reached the point of diminishing returns. > >The document provides a clear enough warning to people configuring >SPF records as to the consequences of getting it wrong which is the >main concern. The filtering services will know their business well >enough to minimize false positives. > >Hopefully the email infrastructure will evolve over time towards >concentrating on the more policy friendly approaches and it will be >possible to simplify the mechanism at a future date. There are two comments about the security directorate review of draft-ietf-spfbis-4408bis-14 at http://www.ietf.org/mail-archive/web/spfbis/current/msg03723.html and http://www.ietf.org/mail-archive/web/spfbis/current/msg03726.html The SPFBIS WG does not plan to make any change to draft-ietf-spfbis-4408bis. Please let me know if you consider that the security directorate review has not been addressed. Regards, S. Moonesamy (as document shepherd) From doug.mtview@gmail.com Thu May 23 12:29:11 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD0E21F90AC; Thu, 23 May 2013 12:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMCSC+6uBqDz; Thu, 23 May 2013 12:28:57 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4DD21F96C7; Thu, 23 May 2013 11:58:20 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id v14so2005229pde.32 for ; Thu, 23 May 2013 11:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=tFHq9RbIQfrmwJ6DJiQlDKjQC99NSvu8+vlNYB1zdpg=; b=ckf1jYLsn0EcIjv/BkhPdAjeeWquay0NaGX/asA2IRZHV5cD4e7XfeFZPGmt3zPw5d iJ/GxuzmYrnTW1Djl9RnwkG2xCNeqHk7+vjJY4K+RsNK9vUBFYKz0mC9NI8r6Uk8Gg4k bl1AJair+kQapDdetVNZBJcZ5rTt4IjlB4VWpmrc4vJrKmR1tvAmT9E7xm5UOQx0pd8S 0Y/JL8ZIEsSORQYH8+XIIsFN29qSOIbk1cfe0aixEjsdhWTUCoxYMsF16yNMw1o4sRws YNmcVAykgWrw+33uLFsj2Rd1nECnVlMTw/rYXcNa91mKJZwGgO9Ayt1fbpvim1gy+JE9 oxhA== X-Received: by 10.68.164.226 with SMTP id yt2mr14310305pbb.203.1369335500037; Thu, 23 May 2013 11:58:20 -0700 (PDT) Received: from [192.168.1.194] (c-24-4-157-244.hsd1.ca.comcast.net. [24.4.157.244]) by mx.google.com with ESMTPSA id if5sm12729646pbb.31.2013.05.23.11.58.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 May 2013 11:58:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Douglas Otis In-Reply-To: <6.2.5.6.2.20130523095247.0dc5a520@elandnews.com> Date: Thu, 23 May 2013 11:58:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7E10E46C-D524-41F2-9546-09DC7E3426A1@gmail.com> References: <6.2.5.6.2.20130523095247.0dc5a520@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1503) Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, Phillip Hallam-Baker , iesg@ietf.org, secdir@ietf.org Subject: Re: [spfbis] draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 19:29:11 -0000 On May 23, 2013, at 10:01 AM, S Moonesamy wrote: > Hi Phillip, > At 09:58 26-04-2013, Phillip Hallam-Baker wrote: >> The document is clear and describes the SPF mechanism effectively. = The only quibble that I could find is that repeated mentions are made of = limiting the number of 'DNS queries' without specifying whether these = are individual queries or recursive. The count will come out rather = differently if looking up TXT/x.example.com counts as one lookup or = three. I think it is reasonably clear that this is one but could not = find an explicit statement to that effect. >>=20 >> On the security side, the document addresses all the mail issues that = I can remember at this point and rather more besides. >>=20 >> I think we have reached the point of diminishing returns. >>=20 >> The document provides a clear enough warning to people configuring = SPF records as to the consequences of getting it wrong which is the main = concern. The filtering services will know their business well enough to = minimize false positives. >>=20 >> Hopefully the email infrastructure will evolve over time towards = concentrating on the more policy friendly approaches and it will be = possible to simplify the mechanism at a future date. >=20 > There are two comments about the security directorate review of = draft-ietf-spfbis-4408bis-14 at = http://www.ietf.org/mail-archive/web/spfbis/current/msg03723.html and = http://www.ietf.org/mail-archive/web/spfbis/current/msg03726.html >=20 > The SPFBIS WG does not plan to make any change to = draft-ietf-spfbis-4408bis. Please let me know if you consider that the = security directorate review has not been addressed. Dear SM and Scott, Greater clarity would have been achieved by separating transactions = involving the SPF checkhost process (spfch-transactions) which may then = generate some number of recursive dns server transactions = (rdns-transactions). A transaction made at the spfch level will result in some number of = transactions at the rdns level, which could then be described as = representing some number of separate DNS queries. Confusion has been caused by conflating checkhost and recursive DNS = transactions with that of non-recursive DNS which may involve dozens of = unique queries to resolve any particular resource. This is bad and is a = continuing source of confusion. A practical means to simplify SPF's impact on a receiver's DNS is to = first ignore SPF records containing macro expressions. This happens and = this may explain the nearly 100% lack of macro use. They then limit the = number of SPF resource records and MX mechanisms and ignore the PTR = mechanism. Appreciate what receivers consider a reasonable demand on = their resources that offers cache-able results. Regards, Douglas Otis From sm@elandsys.com Thu May 23 12:54:29 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5670B21F8F6D; Thu, 23 May 2013 12:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.407 X-Spam-Level: X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNb1mVWB4vTD; Thu, 23 May 2013 12:54:00 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 120D521F97EE; Thu, 23 May 2013 12:15:50 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.5]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4NJFTlB011947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 12:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1369336543; bh=A4gR+4J5IGaopWkzi5DjRnhEq3Rjks54l68so2KH6u4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=MzS0e1ZjgN2XYKChaLLkx/BCc8gfIo0T62Iq2UZlK5go0d3++TTUKFxiH528wA/bE SvX9axZyn1PX3BJ6VrzamOs7s7S+cnyaZNxHSiBs9VhTi4AAKYH0LU94cvrROSC3TS 8v3n8whQZCJMAApTBQUhpjQhRw+jFwTQUBydiV4c= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1369336543; i=@elandsys.com; bh=A4gR+4J5IGaopWkzi5DjRnhEq3Rjks54l68so2KH6u4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pWIoThYLaq3G+Lmepcd3BXyGwcw+lmCmpFbnsZqrhHhmwT2NVAxfUV9YzTWWypeo/ pvbh2nl8RTob1muF9O2mDbvTtCB/gIs2AUBvJCaSca7DQALvrfVjckJMTqfH1WCkVr pyHQ4GDaanSmVwQOCIJnCXFXoYRrHJZXz7iRyfvI= Message-Id: <6.2.5.6.2.20130523120130.0de4f6e0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 May 2013 12:14:32 -0700 To: Douglas Otis From: S Moonesamy In-Reply-To: <7E10E46C-D524-41F2-9546-09DC7E3426A1@gmail.com> References: <6.2.5.6.2.20130523095247.0dc5a520@elandnews.com> <7E10E46C-D524-41F2-9546-09DC7E3426A1@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, Phillip Hallam-Baker , iesg@ietf.org, secdir@ietf.org Subject: Re: [spfbis] draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 19:54:31 -0000 Hi Doug, At 11:58 23-05-2013, Douglas Otis wrote: >Greater clarity would have been achieved by separating transactions >involving the SPF checkhost process (spfch-transactions) which may >then generate some number of recursive dns server transactions >(rdns-transactions). > >A transaction made at the spfch level will result in some number of >transactions at the rdns level, which could then be described as >representing some number of separate DNS queries. > >Confusion has been caused by conflating checkhost and recursive DNS >transactions with that of non-recursive DNS which may involve dozens >of unique queries to resolve any particular resource. This is bad >and is a continuing source of confusion. What I noted among other things in the review was "the only quibble" and "it is reasonably clear". >A practical means to simplify SPF's impact on a receiver's DNS is to >first ignore SPF records containing macro expressions. This happens >and this may explain the nearly 100% lack of macro use. They then >limit the number of SPF resource records and MX mechanisms and >ignore the PTR mechanism. Appreciate what receivers consider a >reasonable demand on their resources that offers cache-able results. I don't see any relation between the security directorate review ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03679.html ) to the above (quoted paragraph). If the security directorate reviewer is of the opinion that it is related to his review I will ask the SPFBIS to comment about the matter. Regards, S. Moonesamy (as document shepherd) From spf2@kitterman.com Thu May 23 14:04:27 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B823821F972A for ; Thu, 23 May 2013 14:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.683 X-Spam-Level: X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtepnBG8iFet for ; Thu, 23 May 2013 14:04:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 929A021F96C0 for ; Thu, 23 May 2013 13:22:27 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CBB5A20E40F7; Thu, 23 May 2013 16:22:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369340545; bh=DmxJZz64/2y3cWnr31dnxMiGIHCsFqx4WtAljp5YJyk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZhhbxXgfqiFFpWcyVtWmmGxNx60Fc1hmbHzU8pM5KSMKWlxLxqSJeQQ5mhFvS44+b VlkmpdgZHnqabna2nVnHBwq/Fx1IsSdx3zJAOfnVG7q4JGnkj0DmZ87tIeUcn7pv2r fkv+UFGOtu5/Lpt0dJjCySimvKw4KMiV0YBc9Y04= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id ACBDB20E4090; Thu, 23 May 2013 16:22:25 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 23 May 2013 16:22:24 -0400 Message-ID: <1778285.8glKQALeLt@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130429065657.0d392368@elandnews.com> References: <6.2.5.6.2.20130429065657.0d392368@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] APPSDIR review of draft-ietf-spfbis-4408bis-14.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:04:27 -0000 On Monday, April 29, 2013 07:05:57 AM S Moonesamy wrote: > Hi Cyrus, >=20 > Thanks for the review. I am forwarding it to the > SPFBIS mailing list for the working group to > discuss. I'll follow-up on apps-discuss@ after that. >=20 > Regards, > S. Moonesamy (as document shepherd) >=20 > >I have been selected as the Applications Area > >Directorate reviewer for this draft (for > >background on appsdir, please see > >=E2=80=8Bhttp://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsA= reaDirectorat > >e ). > > > >Please resolve these comments along with any > >other Last Call comments you may receive. Please > >wait for direction from your document shepherd > >or AD before posting a new version of the draft. > > > >Document: draft-ietf-spfbis-4408bis-14.txt > >Title: Sender Policy Framework (SPF) for > >Authorizing Use of Domains in Email, Version 1 > >Reviewer: Cyrus Daboo > >Review Date: 2013-04-29 > > > >Summary: This draft is almost ready for > >publication as an RFC, subject to some minor issues that should be > >resolved. > > > >Overview: This document is an update to RFC4408 > >that seeks to upgrade the specification from > >experimental status, clarifying a number of > >issues in the original specification, providing > >in depth detail of actual deployment experience, > >and documenting various extensions now in common > >use. The new draft achieves these aims and > >provides a good reference for implementors. > > > >Major Issues: None > > > >Minor Issues: > > Section 4.6.1 ABNF terms "A / MX / PTR > > / IP4 / IP6" are upper case but terminal terms > > are lower case in Section 5 (but uppercase in > > Appendix A). Looks like these need fixing in Section 5. I think we should lower case them all and I've done that for the next r= evision=20 in both 4.6.1 and Appendix A. It makes things more consistent overall.= > > Section 6.2 Paragraph 6 There is a > >=20 > > reference to Section 2.6.4 but that section > > does not contain anything relevant. Either > > remove the reference or point to a relevant section. Corrected to point to 8.4. This was a casualty of a reorganizing the=20= document. > > Section 7.1 Paragraph 2 States "subject > >=20 > > to LDH rule" - that needs a reference to > > RFC3696 Section 2 (reference was in RFC 4408). Is this not sufficient: The "toplabel" construction is subject to the LDH rule plus additional top-level domain (TLD) restrictions. See Section 2 of [RFC3696] for background. > >Section 11.3 Why no mention of DNSSEC as a way > >to alleviate this issue? Has anyone been using > >DNSSEC with SPF? If not, why not? I think this is covered by the reference to RFC 3833, but if someone ha= s a=20 suggestion for more explicit text, please provide it. > >Nits: > > Section 2.4 (argument list) and Section > >=20 > > 4.1 appear to duplicate similar information - > > consider removing the list of args in Section 2.4 and add a referen= ce to > > $4.1.>=20 Done. > > Section 2.5 Paragraph 2 First part of > >=20 > > sentence hard to read - break it up with commas. I agree with the comment, but I'm not sure where to put them without ch= anging=20 the meaning. > > Section 2.6 and Section 8 appear to > >=20 > > duplicate a lot of similar information. Please > > consider trimming down Section 2.6 and have it > > refer to Section 8 for full details. Done. > > Section 3.5 Paragraph 1 Has the word > >=20 > > "discouraged". Shouldn't this use a 2119 term, e.g.: "NOT RECOMMEND= ED"? Probably, but it is discouraged in RFC 4408 and we're trying to be care= ful=20 about introducing new 2119 requirements. > > Section 6.1 Paragraph 1 Remove second > > sentence - pretty much the same as the first one. Done. > > Section 6.2 Paragraph 4 Put exp in double-quotes. Done. =20 > > Section 10 Paragraph 1 SHOULD - in this > > context it is not really appropriate to use a 2119 term. Please rep= hrase. Changed. > > Various places: permerror is sometimes > > used without double-quotes around it - I think > > all uses should have double-quotes. Changed. Scott K From spf2@kitterman.com Thu May 23 14:08:28 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F33421F972D for ; Thu, 23 May 2013 14:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.681 X-Spam-Level: X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFRkgYDAzR6A for ; Thu, 23 May 2013 14:08:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF4221F97C4 for ; Thu, 23 May 2013 13:23:53 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2E5D820E40F7; Thu, 23 May 2013 16:23:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369340633; bh=ojQgBb0JANEHhPmCrwFQleYTxI+UICx2/Z7HT7AznsU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=BPqOPwwWNsgS+sQzLGwpuil8A4yAgxE4TSvHVpfBl4J1xAF3nlXSRDqrUvTXSs3va GqL0iLFLvoz3p2ecs7DrErFlrzcbWyanxyUdY5fGEsbIteEyCpI3wwNGHRvzuYu4Mf 2QgwM0zA+Y8Z34t/1QyxmDs26632e0hDVREACWbE= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 17CF020E4090; Thu, 23 May 2013 16:23:53 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 23 May 2013 16:23:52 -0400 Message-ID: <3764152.r4JtREsgbi@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130518101418.0bbf6848@elandnews.com> References: <6.2.5.6.2.20130423063319.0d04e118@elandnews.com> <4504827.dqlBOFqUut@scott-latitude-e6320> <6.2.5.6.2.20130518101418.0bbf6848@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Addressing reviews (was: Document shepherd review of draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:08:28 -0000 On Saturday, May 18, 2013 10:35:03 AM S Moonesamy wrote: > Hi Scott, > > The Gen-ART review of draft-ietf-spfbis-4408bis-14 was posted on > April 29 ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg03647.html > ). There weren't any comments about that review. > > The Applications Area directorate review was posted on April 29 ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg03633.html > ). There was a comment from Hector Santos ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg03653.html ). > > The Security Directorate review of draft-ietf-spfbis-4408bis-14 was > posted on April 30 ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg03679.html > ). There was a comment from you ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg03723.html ) > and from John Levine ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg03726.html ). > > Can you provide an estimate date of when the reviews mentioned above > will be addressed? I believe these are all addressed now. I don't have any other reviews pending, so I'll publish -15 later today if no one else speaks up. Scott K From sm@elandsys.com Thu May 23 15:14:06 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6242221F983A; Thu, 23 May 2013 15:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxkYBpRtD8s6; Thu, 23 May 2013 15:13:55 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3363C21F983F; Thu, 23 May 2013 14:29:26 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.5]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4NLT3sq023426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 14:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1369344557; bh=As6zUMYor+zZ+QsTkoyPdRn0q9Mxwl/6xDreWazDfxs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1lpVVjwEEkAuyz9dQqe0/bGGLykFYMdtfLCQO6MinKJ9HifKgjjTSqnYHBbwAYxhI IbLhSnELESL1RKe2Ls2/43Yq7OEWsGpMOUO/zfOpWvu39eiO7PaxX2nqyOv2Gqk5Ft WPlEOegQotWcd0QM9xWVYzmutg502dL/4ZF4n4qc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1369344557; i=@elandsys.com; bh=As6zUMYor+zZ+QsTkoyPdRn0q9Mxwl/6xDreWazDfxs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ilUG9Cee+Flp6pMGrsWke0E/U909+4+H+95eR5g9UA/weQND+S7h1oZWLV99qFa2x KhXsCcj71AsG70Hg4RvzKQ6494v9KnDAwIy4r1kNhNRuvgclrZYXLUa5UI8GPV7Aj9 5tuaNLfWIz41mZn6//T3NIEUzMY5ZkAKJIDDp7bk= Message-Id: <6.2.5.6.2.20130523142426.0daf25c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 May 2013 14:28:31 -0700 To: Cyrus Daboo From: S Moonesamy In-Reply-To: <1778285.8glKQALeLt@scott-latitude-e6320> References: <6.2.5.6.2.20130429065657.0d392368@elandnews.com> <1778285.8glKQALeLt@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [spfbis] APPSDIR review of draft-ietf-spfbis-4408bis-14.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:14:06 -0000 Hi Cyrus, At 13:22 23-05-2013, Scott Kitterman wrote: >On Monday, April 29, 2013 07:05:57 AM S Moonesamy wrote: > > >Document: draft-ietf-spfbis-4408bis-14.txt > > >Title: Sender Policy Framework (SPF) for > > >Authorizing Use of Domains in Email, Version 1 > > >Reviewer: Cyrus Daboo > > >Review Date: 2013-04-29 > > > > > >Summary: This draft is almost ready for > > >publication as an RFC, subject to some minor issues that should be > > >resolved. > > > > > >Overview: This document is an update to RFC4408 > > >that seeks to upgrade the specification from > > >experimental status, clarifying a number of > > >issues in the original specification, providing > > >in depth detail of actual deployment experience, > > >and documenting various extensions now in common > > >use. The new draft achieves these aims and > > >provides a good reference for implementors. > > > > > >Major Issues: None > > > > > >Minor Issues: > > > Section 4.6.1 ABNF terms "A / MX / PTR > > > / IP4 / IP6" are upper case but terminal terms > > > are lower case in Section 5 (but uppercase in > > > Appendix A). Looks like these need fixing in Section 5. > >I think we should lower case them all and I've done that for the >next revision >in both 4.6.1 and Appendix A. It makes things more consistent overall. > > > > Section 6.2 Paragraph 6 There is a > > > > > > reference to Section 2.6.4 but that section > > > does not contain anything relevant. Either > > > remove the reference or point to a relevant section. > >Corrected to point to 8.4. This was a casualty of a reorganizing the >document. > > > > Section 7.1 Paragraph 2 States "subject > > > > > > to LDH rule" - that needs a reference to > > > RFC3696 Section 2 (reference was in RFC 4408). > >Is this not sufficient: > > The "toplabel" construction is subject to the LDH rule plus > additional top-level domain (TLD) restrictions. See Section 2 of > [RFC3696] for background. > > > >Section 11.3 Why no mention of DNSSEC as a way > > >to alleviate this issue? Has anyone been using > > >DNSSEC with SPF? If not, why not? > >I think this is covered by the reference to RFC 3833, but if someone has a >suggestion for more explicit text, please provide it. > > > >Nits: > > > Section 2.4 (argument list) and Section > > > > > > 4.1 appear to duplicate similar information - > > > consider removing the list of args in Section 2.4 and add a reference to > > > $4.1.> > >Done. > > > > Section 2.5 Paragraph 2 First part of > > > > > > sentence hard to read - break it up with commas. > >I agree with the comment, but I'm not sure where to put them without changing >the meaning. > > > > Section 2.6 and Section 8 appear to > > > > > > duplicate a lot of similar information. Please > > > consider trimming down Section 2.6 and have it > > > refer to Section 8 for full details. > >Done. > > > > Section 3.5 Paragraph 1 Has the word > > > > > > "discouraged". Shouldn't this use a 2119 term, e.g.: "NOT RECOMMENDED"? > >Probably, but it is discouraged in RFC 4408 and we're trying to be careful >about introducing new 2119 requirements. > > > > Section 6.1 Paragraph 1 Remove second > > > sentence - pretty much the same as the first one. > >Done. > > > > Section 6.2 Paragraph 4 Put exp in double-quotes. > >Done. > > > > Section 10 Paragraph 1 SHOULD - in this > > > context it is not really appropriate to use a 2119 term. Please rephrase. > >Changed. > > > > Various places: permerror is sometimes > > > used without double-quotes around it - I think > > > all uses should have double-quotes. > >Changed. Do the above comments address your AppsDir review ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09353.html )? Thanks, S. Moonesamy (as document shepherd) From internet-drafts@ietf.org Thu May 23 15:45:50 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FF621F855F; Thu, 23 May 2013 15:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNy0PYIrI4jw; Thu, 23 May 2013 15:45:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3813C21F8F62; Thu, 23 May 2013 15:42:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130523224256.15462.55198.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 15:42:56 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-15.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:45:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SPF Update Working Group of the IETF. Title : Sender Policy Framework (SPF) for Authorizing Use of Dom= ains in Email, Version 1 Author(s) : Scott Kitterman Filename : draft-ietf-spfbis-4408bis-15.txt Pages : 75 Date : 2013-05-23 Abstract: Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby a ADMDs (ADministrative Management Domains) can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization. This document obsoletes RFC4408. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From spf2@kitterman.com Thu May 23 15:47:55 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DE321F8C98 for ; Thu, 23 May 2013 15:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.678 X-Spam-Level: X-Spam-Status: No, score=-2.678 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU+YyNpm3T72 for ; Thu, 23 May 2013 15:47:46 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7776721F9721 for ; Thu, 23 May 2013 15:47:25 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9DD7320E40F7; Thu, 23 May 2013 18:47:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369349244; bh=5Q0yZ//VnSod0f94uImI5yzy4DIOldQ0ekE92mV0sKU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZYHmTsciAYJ0CrwY66uoQwjkmltK7iaPAIcNudQw1iinuYw4wN5UFF/ce7YdER5+m /ORPsOYHbe8BJbYg923NTMZjoEFjsDUAeHl1bA/KKyc3ZLUjeDnZaiM+1I/Mv5Unjb YA0auYPiK28TQlfUtytLWRX+mjAQNQIMYVW3Of4M= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 85E4D20E4090; Thu, 23 May 2013 18:47:24 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 23 May 2013 18:47:23 -0400 Message-ID: <4254865.V2u2IjG0lH@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130523224256.15462.62780.idtracker@ietfa.amsl.com> References: <20130523224256.15462.62780.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New Version Notification for draft-ietf-spfbis-4408bis-15.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:47:55 -0000 On Thursday, May 23, 2013 03:42:56 PM you wrote: > A new version of I-D, draft-ietf-spfbis-4408bis-15.txt > has been successfully submitted by Scott Kitterman and posted to the > IETF repository. > > Filename: draft-ietf-spfbis-4408bis > Revision: 15 > Title: Sender Policy Framework (SPF) for Authorizing Use of Domains in > Email, Version 1 Creation date: 2013-05-23 > Group: spfbis > Number of pages: 75 > URL: > http://www.ietf.org/internet-drafts/draft-ietf-spfbis-4408bis-15.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis > Htmlized: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-15 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ietf-spfbis-4408bis-15 This draft consists of changes due to last call comments. Scott K From doug.mtview@gmail.com Fri May 24 14:58:51 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D40211E8135; Fri, 24 May 2013 14:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wO31-p-VRbmZ; Fri, 24 May 2013 14:58:49 -0700 (PDT) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id DF52111E8129; Fri, 24 May 2013 14:58:48 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id w16so3444618vbb.37 for ; Fri, 24 May 2013 14:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3ZEWRgm+QVx2MsfeAOqSpzIxGr+1z0MsN3NaUd0obfA=; b=OKCvvhdjFdlhspwaybk+nabfUMjruiOLs9ZrChrE8lmZxB6F7hFD93hQPoStaYLD/P KFhNxEqvwSy8bJ9MOffTqnKud38OxWAREt/4X9Fb1NOrAChwxXsZvxIvslz1Ae+oCztt zbtavbXWQw76JGNidZSHe3pZLohO1I2fQ67AxKF67vhIIyGwKZEAPpciLlLFAuERzCnU 5uLzPz8qSItpFpOFndDy35x3C9z82ZVxX+C4p/KzN/0n3QIrFtW6ed71sWsYUWTbft8V 7q/5WQZA3BjbHf5UvJzO+z9qzcjldci57VLd3wMGWVKrNo98iQr+kZyo28UNgZy4HkG4 763g== X-Received: by 10.52.38.161 with SMTP id h1mr8396588vdk.30.1369432728283; Fri, 24 May 2013 14:58:48 -0700 (PDT) Received: from [192.168.0.99] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id s14sm10495374vdg.6.2013.05.24.14.58.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 14:58:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Douglas Otis In-Reply-To: <6.2.5.6.2.20130523120130.0de4f6e0@elandnews.com> Date: Fri, 24 May 2013 14:58:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20130523095247.0dc5a520@elandnews.com> <7E10E46C-D524-41F2-9546-09DC7E3426A1@gmail.com> <6.2.5.6.2.20130523120130.0de4f6e0@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1503) Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, Phillip Hallam-Baker , iesg@ietf.org, secdir@ietf.org Subject: Re: [spfbis] draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 21:58:51 -0000 On May 23, 2013, at 12:14 PM, S Moonesamy wrote: > Hi Doug, > At 11:58 23-05-2013, Douglas Otis wrote: >> Greater clarity would have been achieved by separating transactions = involving the SPF checkhost process (spfch-transactions) which may then = generate some number of recursive dns server transactions = (rdns-transactions). >>=20 >> A transaction made at the spfch level will result in some number of = transactions at the rdns level, which could then be described as = representing some number of separate DNS queries. >>=20 >> Confusion has been caused by conflating checkhost and recursive DNS = transactions with that of non-recursive DNS which may involve dozens of = unique queries to resolve any particular resource. This is bad and is a = continuing source of confusion. >=20 > What I noted among other things in the review was "the only quibble" = and "it is reasonably clear". >=20 >> A practical means to simplify SPF's impact on a receiver's DNS is to = first ignore SPF records containing macro expressions. This happens and = this may explain the nearly 100% lack of macro use. They then limit the = number of SPF resource records and MX mechanisms and ignore the PTR = mechanism. Appreciate what receivers consider a reasonable demand on = their resources that offers cache-able results. >=20 > I don't see any relation between the security directorate review ( = http://www.ietf.org/mail-archive/web/spfbis/current/msg03679.html ) to = the above (quoted paragraph). If the security directorate reviewer is = of the opinion that it is related to his review I will ask the SPFBIS to = comment about the matter. Dear SM, SPFbis terminology conflates similar terms used in both recursive DNS = and the pseudo check_host service indirectly defined in the SPFbis = document. In addition, there appears to be a significant departure in = processing of the EHLO domain in lieu of the RFC5321.MAILFROM. SPFbis = section 2.1states "If a conclusive determination about the message can = be made based on a check of HELO, then the use of DNS resources to = process the typically more complex MAIL FROM can be avoided."=20 This approach is at odds with a process proposed by = draft-kucherawy-dmarc-base, section 4.3 "For example, [DKIM] = authenticates the domain that affixed a signature to the message, while = [SPF] authenticates either the domain that appears in then = RFC5321.Mail=46rom portion of [SMTP] or the RFC5321.EHLO/HELO domain if = the RFC5321.Mail=46rom is null (in the case of Delivery Status = Notifications). Draft-kucherawy-dmarc-base already requires reprocessing message header = stacks to exclude ONLY repeated =46rom header fields. It also suggests = EHLO will be ignored and the RFC5321.Mail=46rom will still need to be = processed. This potentially doubles the load on DNS and offers poor = protocol layering. If directed toward synthetic domains used to replace = web cookies, the application of the new DNS Response Rate Limiting may = prove problematic, in addition to an attack easily occurring from a = myriad clients easily beyond prefix limits used to associate responses. = Although related to offering security, it seems highly improbable SPF = can safely make use of DNSsec.=20 It should also be noted that RFC6531 introduces character sets not = handled by SPFbis since this also includes local-part components which = may invoke handling errors since this introduces data not converted by = RFC5890. It should also be noted that use of macros still allows = left-hand labels to take the place of randomized local-parts to leverage = cached records while inducing different queries. The only way SPFbis can be made reasonably safe would be to disable = implementation of the macro functions by the receiver. Since these = macros are rarely used, this change would not impact the exchange of = email. Even now, senders making use of macros will see a greater = impact with their SPF records being ignored as things currently stand. Regards, Douglas Otis From sm@elandsys.com Sat May 25 03:08:22 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B537521F9092 for ; Sat, 25 May 2013 03:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZflZFGmaBu0 for ; Sat, 25 May 2013 03:08:22 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0658721F901A for ; Sat, 25 May 2013 03:08:22 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.207]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4PA86bV005839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 May 2013 03:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1369476498; bh=8y7y48Hlm9YO+FqEUPU2VxWd4fNXVArvbiLcB4JIknE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QYDfgHLuQnAM3weB5mWf6R6thBjmCRsDbb9XsY9Q3MU1G+bBnqe6G6Jgn+CPZsXEW O3muO2St/i8Of42Tatp4nr6OkRTP+bcwczMFmq+HLJskiK3pRGiwLW4deQ1+/V/jhG u2brAtxrB9ZXgHE700RErDFwkdr2jXQPx0brru60= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1369476498; i=@elandsys.com; bh=8y7y48Hlm9YO+FqEUPU2VxWd4fNXVArvbiLcB4JIknE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NyP7XFPibxqdIs7twmxGvvwUoAXYhuRmVo2RzksmMJwjiNEpG4ercf/cCo9rh3nVr OKBZEPvt/rwkFf/kurQbJYeHvLN22BcquI23smNXkYEKs4T4qgnQjTISmnqKYlnvIb W1TU9IrEdElQn5uxc3Ghqn2NBpaDjnmWEDIM15Rk= Message-Id: <6.2.5.6.2.20130525023930.0cbd2790@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 25 May 2013 02:52:01 -0700 To: Douglas Otis From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130523095247.0dc5a520@elandnews.com> <7E10E46C-D524-41F2-9546-09DC7E3426A1@gmail.com> <6.2.5.6.2.20130523120130.0de4f6e0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org Subject: Re: [spfbis] draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 10:08:22 -0000 Hi Doug, At 14:58 24-05-2013, Douglas Otis wrote: >This approach is at odds with a process proposed by >draft-kucherawy-dmarc-base, section 4.3 "For example, [DKIM] >authenticates the domain that affixed a signature to the message, >while [SPF] authenticates either the domain that appears in then >RFC5321.MailFrom portion of [SMTP] or the RFC5321.EHLO/HELO domain >if the RFC5321.MailFrom is null (in the case of Delivery Status Notifications). > >Draft-kucherawy-dmarc-base already requires reprocessing message >header stacks to exclude ONLY repeated From header fields. It also >suggests EHLO will be ignored and the RFC5321.MailFrom will still >need to be processed. This potentially doubles the load on DNS and >offers poor protocol layering. If directed toward synthetic domains >used to replace web cookies, the application of the new DNS Response >Rate Limiting may prove problematic, in addition to an attack easily >occurring from a myriad clients easily beyond prefix limits used to >associate responses. Although related to offering security, it >seems highly improbable SPF can safely make use of DNSsec. The above comment is about draft-kucherawy-dmarc-base. The SPFBIS WG is not working on draft-kucherawy-dmarc-base. I have not been asked to take that draft into consideration for the work being done in the SPFBIS WG. Regards, S. Moonesamy (as document shepherd) From cyrus@daboo.name Tue May 28 07:40:13 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B405121F9759; Tue, 28 May 2013 07:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mk6SAlWNMEQL; Tue, 28 May 2013 07:40:09 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id F32C421F97A5; Tue, 28 May 2013 07:40:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 989124443336; Tue, 28 May 2013 10:40:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJBZUcuBhF3j; Tue, 28 May 2013 10:40:07 -0400 (EDT) Received: from [10.0.1.11] (unknown [17.45.162.251]) by daboo.name (Postfix) with ESMTPSA id 674CC444332B; Tue, 28 May 2013 10:40:06 -0400 (EDT) Date: Tue, 28 May 2013 10:40:07 -0400 From: Cyrus Daboo To: S Moonesamy Message-ID: <2B58ED5599DDF1DD894E64BA@cyrus.local> In-Reply-To: <6.2.5.6.2.20130523142426.0daf25c8@resistor.net> References: <6.2.5.6.2.20130429065657.0d392368@elandnews.com> <1778285.8glKQALeLt@scott-latitude-e6320> <6.2.5.6.2.20130523142426.0daf25c8@resistor.net> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=273 X-Mailman-Approved-At: Tue, 28 May 2013 09:45:40 -0700 Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [spfbis] APPSDIR review of draft-ietf-spfbis-4408bis-14.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 14:40:13 -0000 Hi S, --On May 23, 2013 2:28:31 PM -0700 S Moonesamy wrote: > Do the above comments address your AppsDir review ( > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09353.html )? Yes, I am OK with the changes adopted. -- Cyrus Daboo From sm@elandsys.com Tue May 28 13:16:56 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7168121F8FB3 for ; Tue, 28 May 2013 13:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS+Ji3gO+rjf for ; Tue, 28 May 2013 13:16:55 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D40DD21F8F32 for ; Tue, 28 May 2013 13:16:55 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.129.170]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4SKGZHQ028583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 May 2013 13:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1369772207; bh=PlqHY8JRfD9ArP2J2h4dtnmBynA5q+4jxgZGXSh/ah4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qrSy5uENtZ9KrMbUFFSB8j1EAmUyK/JH1CMyJitxuooVNab46WsaNP1RvbAu4C+UO 0jP4YIOAOZrktJGwPTn0LhyJFgbQmPv/ROaByNHy4PVt/ncFem1nc7LFJCw9Rdnmql Z4WpcW6Iz+yxVn5xOjNrFaDGIo2yNA8QT2s99qVA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1369772207; i=@elandsys.com; bh=PlqHY8JRfD9ArP2J2h4dtnmBynA5q+4jxgZGXSh/ah4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hg9RylV+iTk4CeF/tVXEQbPc2LX53Q3FFioMxTK0ftUg7QJpd6wdtBmpnogbrSIPY UAZl9/l5fovMZ1QDkzb8GXY9PbcdQM6NpAO1oIzLGzGpNetpiyDOwtZK6bQPuzpSqM xHtgUqfcpz1E+onW+UPoyCVCKXnTC+soGdMNmEkQ= Message-Id: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 28 May 2013 13:16:06 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Douglas Otis Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 20:16:56 -0000 Hello, Douglas Otis submitted draft-otis-spfbis-macros-nixed-00 [1] as WGLC comments about draft-ietf-spfbis-4408bis-14. Could the SPFBIS WG please read the draft-otis-spfbis-macros-nixed-00 and comment about it? Regards, S. Moonesamy (as SPFBIS WG co-chair) 1. http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-00 From superuser@gmail.com Tue May 28 14:16:02 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAAA21F87C5 for ; Tue, 28 May 2013 14:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAKQNt-JNNw2 for ; Tue, 28 May 2013 14:16:01 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 460BA21F87BB for ; Tue, 28 May 2013 14:16:01 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hj6so2918743wib.11 for ; Tue, 28 May 2013 14:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UGvsyitpgAFfyOiQvdrhQN42DoB0BzzoMg+mXMacal0=; b=vqUrQoBRN7MTAzMOmV+anAY9T1Nik/XmUw4SJ11fFHDQ8JwOKpIG9dZEQS8xprFLFz yFZ+XbRYDv1ZcS4eaNqIE9GL8bB42KagYW93+mBsLXScM2ILWm7aORrp79avgRQ7kQrv qRNI5lI8ynJYbScvzKd7ddW+H+W12cP52k1HOHFZzSbal2EHMoGCZbE+IOF4WUD9jEDz v2f0svotQvwQzJmLRY+f7cXg5INzUpnEsDfNK5Q0fV5Kg03UXyaYzSZDeLapzf5zGvIy SgHBcIzGxGpnexObyjfCwdyKzgrOAr1hniswlzbQ45sCCp38XEuadZx7wjJeSFv4uEmP hPUQ== MIME-Version: 1.0 X-Received: by 10.180.105.161 with SMTP id gn1mr13773807wib.5.1369775759914; Tue, 28 May 2013 14:15:59 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Tue, 28 May 2013 14:15:59 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> Date: Tue, 28 May 2013 14:15:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=f46d041826fc9780f704ddcdc523 Cc: "spfbis@ietf.org" , Douglas Otis Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 21:16:02 -0000 --f46d041826fc9780f704ddcdc523 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 28, 2013 at 1:16 PM, S Moonesamy wrote: > Douglas Otis submitted draft-otis-spfbis-macros-nixed-00 [1] as WGLC > comments about draft-ietf-spfbis-4408bis-14. Could the SPFBIS WG please > read the draft-otis-spfbis-macros-nixed-00 and comment about it? > > I have reviewed the draft, as requested. My responses: Nixing macros based on non-use has already been debated at length, to the point of a low-level appeal, and it's been decided that they're staying. There's no action for the WG here based on that argument. Beyond that, I disagree that macros "diminish" SPF's utility in any way; their mere presence in the protocol doesn't render it less useful, as one may simply not use them and still get useful results. I would argue that DMARC, which makes use of SPF in a specific way, should not influence SPF itself at this point as DMARC has no particular status with the IETF yet. The dropping of type 99 RRTYPE support was made for more reasons than just "sparse use", so I don't find that part of Doug's arguments compelling. I think we reached consensus on that debate long ago, and it's been beaten to death recently once again on the main IETF list. The local-part macro attack has been discussed to death. There's no new information presented here that I can see. Saying RFC6686 "failed to provide a breakdown on macro use" is to imply that it should have. Analysis of macro use was not part of the goal set of that document, so it's strange to identify this as a failure. However, I still have those data available should there be some demonstrated purpose for mining the data further. Or, Doug can do his own survey and see what he finds. The document mentions use of macros given the advent of EAI, but I believe the current spfbis document already deals with this in the same way DKIM did. Someone more expert in EAI than I am might want to confirm we've done our due diligence there. Overall, I don't think this draft introduces any new material such that the WG needs to revisit anything since WGLC closed. -MSK --f46d041826fc9780f704ddcdc523 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 28, 2013 at 1:16 PM, S Moonesamy <sm+ietf@= elandsys.com> wrote:
Douglas Otis submitted dr= aft-otis-spfbis-macros-nixed-00 [1] as WGLC comments about draft-ietf-spfbi= s-4408bis-14. =A0Could the SPFBIS WG please read the draft-otis-spfbis-macr= os-nixed-00 and comment about it?


I have reviewed the draft, as requested.=A0 My respons= es:

Nixing macros based on non-use has already been debated at lengt= h, to the point of a low-level appeal, and it's been decided that they&= #39;re staying.=A0 There's no action for the WG here based on that argu= ment.

Beyond that, I disagree that macros &q= uot;diminish" SPF's utility in any way; their mere presence in the= protocol doesn't render it less useful, as one may simply not use them= and still get useful results.

I would argue that DMARC, which makes = use of SPF in a specific way, should not influence SPF itself at this point= as DMARC has no particular status with the IETF yet.

The dropping of type 99 RRTYPE support was made for more reasons than just = "sparse use", so I don't find that part of Doug's argumen= ts compelling.=A0 I think we reached consensus on that debate long ago, and= it's been beaten to death recently once again on the main IETF list.
The local-part macro attack has been d= iscussed to death.=A0 There's no new information presented here that I = can see.

Saying RFC6686 "faile= d to provide a breakdown on macro use" is to imply that it should have= .=A0 Analysis of macro use was not part of the goal set of that document, s= o it's strange to identify this as a failure.=A0 However, I still have = those data available should there be some demonstrated purpose for mining t= he data further.=A0 Or, Doug can do his own survey and see what he finds.
The document mentions use of macros gi= ven the advent of EAI, but I believe the current spfbis document already de= als with this in the same way DKIM did.=A0 Someone more expert in EAI than = I am might want to confirm we've done our due diligence there.

Overall, I don't think this draft = introduces any new material such that the WG needs to revisit anything sinc= e WGLC closed.

-MSK
--f46d041826fc9780f704ddcdc523-- From doug.mtview@gmail.com Tue May 28 18:38:47 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0278B21F8EFC for ; Tue, 28 May 2013 18:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfJ3M5Tbqy2f for ; Tue, 28 May 2013 18:38:42 -0700 (PDT) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 2E04D21F8ED8 for ; Tue, 28 May 2013 18:38:42 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz11so5900390pad.2 for ; Tue, 28 May 2013 18:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version :x-mailer; bh=HkqnpwO8Vms4rMII9Uid98H6/hr1cFEv4juXAHzC+/k=; b=FWF1z3b+Xm96TLHKEwv45P07LU9SnsuLi4f7Wtvo1DlJSmAidyN3l+c0kBx+1opNj3 pON3GjswL0nX/HACKUeFztKqB7cveE/XjNfkRQ7d0m84IJBbBRFJYsJz/IAACDgstJkp tbxHYWnA3oaY6EdWjGQOdvnwFKpKhK7dOyTrbG41WCSzRy732RiA/ak+ErF5vhK6li1u S5KiluT5lN9KEYvrtb+nkAawzU4lic/XfHSt3v2TPzZFNB0j1gHhXdnn36x6l/8ANAW5 CFk9SyBY1laG1fNTcBiLAG9J7FZ+1Nt2M6xi01zXO4Ya6Dj4nzj5jxy9njVg8uBp6/w3 FykA== X-Received: by 10.68.226.39 with SMTP id rp7mr472062pbc.97.1369791521813; Tue, 28 May 2013 18:38:41 -0700 (PDT) Received: from [192.168.1.194] (c-24-4-157-244.hsd1.ca.comcast.net. [24.4.157.244]) by mx.google.com with ESMTPSA id pb5sm34621686pbc.29.2013.05.28.18.38.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 May 2013 18:38:40 -0700 (PDT) From: Douglas Otis Content-Type: multipart/alternative; boundary="Apple-Mail=_59ED8F4B-2D39-4F42-8618-1A0177C6BF59" Date: Tue, 28 May 2013 18:38:57 -0700 Message-Id: To: "spfbis@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Cc: Andrew Sullivan , S Moonesamy Subject: [spfbis] draft-otis-spfbis-macros-nixed-01 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 01:38:47 -0000 --Apple-Mail=_59ED8F4B-2D39-4F42-8618-1A0177C6BF59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear SPFbis WG, The I-D mentioned by SM has been updated. Sorry for the delay, but it = was hoped more information could be included than time allowed. http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-01 Review the diff section to determine the changes. Regards, Douglas Otis --Apple-Mail=_59ED8F4B-2D39-4F42-8618-1A0177C6BF59 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Dear SPFbis WG,

The I-D mentioned by SM has been updated.  Sorry for the delay, but it was hoped more information could be included than time allowed.


Review the diff section to determine the changes.

Regards,
Douglas Otis


--Apple-Mail=_59ED8F4B-2D39-4F42-8618-1A0177C6BF59-- From dhc@dcrocker.net Tue May 28 18:43:42 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A4321F8EEC for ; Tue, 28 May 2013 18:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFPSz9r4nGgE for ; Tue, 28 May 2013 18:43:36 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C04C421F8ED8 for ; Tue, 28 May 2013 18:43:36 -0700 (PDT) Received: from [192.168.1.7] (chello080108132236.14.wu-wien.teleweb.at [80.108.132.236] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r4T1hFsc026184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 May 2013 18:43:21 -0700 Message-ID: <51A55D2F.3010202@dcrocker.net> Date: Wed, 29 May 2013 03:43:11 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 28 May 2013 18:43:23 -0700 (PDT) Cc: "spfbis@ietf.org" , S Moonesamy , Douglas Otis Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 01:43:42 -0000 On 5/28/2013 11:15 PM, Murray S. Kucherawy wrote: > > Overall, I don't think this draft introduces any new material such that > the WG needs to revisit anything since WGLC closed. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Tue May 28 19:53:15 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF26621E8082 for ; Tue, 28 May 2013 19:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmFPYNAENI2m for ; Tue, 28 May 2013 19:53:00 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B53D721F8B27 for ; Tue, 28 May 2013 19:53:00 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8D53420E40D6; Tue, 28 May 2013 22:52:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369795975; bh=0qhcD+giA+6bwyLpa3M0EyOocMHCocfTLe/Fy3GrB0I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=n1dvCoGsGtpkMfe90Epl3LBOsxCa5TYMaKpyCV0a7JZVigG+6a8pXjrU9Vozgd6Vg 1wlhyHUusFsM9vbR6NZMKI/6q6gvqUgkEiPU8M2oJWdxk3rMUOI52wlczzjGD5G3gq Umixlit7S05xER894IZYrBCGqI8V7hzQMxaoHJ/U= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6F91C20E40CF; Tue, 28 May 2013 22:52:55 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 28 May 2013 22:52:53 -0400 Message-ID: <21746052.2ftQxjEWaI@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-22-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <51A55D2F.3010202@dcrocker.net> References: <51A55D2F.3010202@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 02:53:16 -0000 On Wednesday, May 29, 2013 03:43:11 AM Dave Crocker wrote: > On 5/28/2013 11:15 PM, Murray S. Kucherawy wrote: > > Overall, I don't think this draft introduces any new material such that > > the WG needs to revisit anything since WGLC closed. > > +1 > I've reviewed the document and the revision and I concur. Scott K From doug.mtview@gmail.com Tue May 28 21:46:36 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C430621F85C0 for ; Tue, 28 May 2013 21:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T22UKjwJG2D8 for ; Tue, 28 May 2013 21:46:25 -0700 (PDT) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id D929821F85B8 for ; Tue, 28 May 2013 21:46:25 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb11so7405473pad.9 for ; Tue, 28 May 2013 21:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=EGqqTc0xr7Uw5/jIqIPM/BElkEm/7ZcUG7rSF9vH31k=; b=0qLkXc4C2yGUYyveKLiSeqrYGDCC6t8bjBt0/lhcD2PaU1jU83g5IoFauAVn3wJagM CGYgDvsRxHWU9G8SwTudlzqefeZsYimiUPYgI4A/vs1f2mD8sB7jkH1OPXaisl08uOrg /qQueOan7iIrkA7ienFE/d9X0dNM7eolH0jUqyA2WznouLu+0qUQQ8LgpH/e76hnNhfS GQ7ZoMpvivr4gcCegK1w/aUeKXD+xOPOdsFK6En6BKWw1vSml2SmSp9T6pMd/kIcoTcV nZi2x1eN4eXFE3c7dPgxq9T3zg+WH7lxitPUKlYWHVZF0HWtKdLXk1r0F+vY+aFQkQd6 pzbw== X-Received: by 10.68.164.33 with SMTP id yn1mr1090708pbb.71.1369802785625; Tue, 28 May 2013 21:46:25 -0700 (PDT) Received: from ?IPv6:2601:9:4d80:49:28f6:b4b6:27fe:79d6? ([2601:9:4d80:49:28f6:b4b6:27fe:79d6]) by mx.google.com with ESMTPSA id kv2sm35684434pbc.28.2013.05.28.21.46.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 May 2013 21:46:24 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_AC20CE27-2C69-4B2F-8B3D-8435CAC4DC9D" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Douglas Otis In-Reply-To: Date: Tue, 28 May 2013 21:46:21 -0700 Message-Id: References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1503) Cc: "spfbis@ietf.org" , S Moonesamy Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 04:46:36 -0000 --Apple-Mail=_AC20CE27-2C69-4B2F-8B3D-8435CAC4DC9D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On May 28, 2013, at 2:15 PM, Murray S. Kucherawy = wrote: > On Tue, May 28, 2013 at 1:16 PM, S Moonesamy = wrote: > Douglas Otis submitted draft-otis-spfbis-macros-nixed-00 [1] as WGLC = comments about draft-ietf-spfbis-4408bis-14. Could the SPFBIS WG please = read the draft-otis-spfbis-macros-nixed-00 and comment about it? >=20 >=20 > I have reviewed the draft, as requested. My responses: >=20 > Nixing macros based on non-use has already been debated at length, to = the point of a low-level appeal, and it's been decided that they're = staying. There's no action for the WG here based on that argument. Dear Murray, A pertinent point regarding the decision that receivers must process = macros is whether it represents a reasonable demand. SPF records = containing macros can not cache results and will always necessitate = reprocessing. If macro processing is skipped, any expectation of = preserving interchange is lost. In other words, it is broken by design = by asking too much from receivers. =20 > Beyond that, I disagree that macros "diminish" SPF's utility in any = way; their mere presence in the protocol doesn't render it less useful, = as one may simply not use them and still get useful results. When the main purported use is to determine a domain's outbound IP = addresses, macros preclude this prevalent use offering the greatest = utility, bar none. > I would argue that DMARC, which makes use of SPF in a specific way, = should not influence SPF itself at this point as DMARC has no particular = status with the IETF yet. DMARC does not differ in how many hoped to make use of SPF. Desired use = is very much at odds with stated SPF processing which is likely to = require subsequent reprocessing, with increased burdens and layer = violations. =20 > The dropping of type 99 RRTYPE support was made for more reasons than = just "sparse use", so I don't find that part of Doug's arguments = compelling. I think we reached consensus on that debate long ago, and = it's been beaten to death recently once again on the main IETF list. Mark Andrews made good points about increasing use of SPF 99 not shown = in your survey. The general goal should be to ensure unknown RR types = are accommodated. Unfortunately, some vendors still don't. > The local-part macro attack has been discussed to death. There's no = new information presented here that I can see. >=20 > Saying RFC6686 "failed to provide a breakdown on macro use" is to = imply that it should have. Analysis of macro use was not part of the = goal set of that document, so it's strange to identify this as a = failure. However, I still have those data available should there be = some demonstrated purpose for mining the data further. Or, Doug can do = his own survey and see what he finds. IMHO, it was wrong (a failing) to limit a review of SPF to answer only = whether the PRA mode was being used. This review should have also = focused on both macro publication and macro processing. Whether it is = local-part macro or any other macro, cached results are not useful and = much of the SPF utility for defining a domain's outbound address space = is lost. Since there is only 0.053% of domains using macros, it becomes = an easy trade-off some providers make. They even have stated ignoring = SPF records containing macros do not result in complaints. > The document mentions use of macros given the advent of EAI, but I = believe the current spfbis document already deals with this in the same = way DKIM did. Someone more expert in EAI than I am might want to = confirm we've done our due diligence there. It can no longer be assumed domains will be encoded as A-labels. In = addition, it can not be assumed the local-part will be ASCII. Such = changes can place spf libraries at risk. In a quick review, it seems = some unused features in the libraries might permit induced buffer = overruns. Adding in additional conversion libraries introduces more = risk which might compromise SMTP servers. Nothing justifies these types = of risks to support something that is practically unused. =20 > Overall, I don't think this draft introduces any new material such = that the WG needs to revisit anything since WGLC closed. The macros nixed draft was just updated to better clarify these = concerns. http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-01 Regards, Douglas Otis --Apple-Mail=_AC20CE27-2C69-4B2F-8B3D-8435CAC4DC9D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 superuser@gmail.com> = wrote:

On Tue, May 28, 2013 at 1:16 PM, S = Moonesamy <sm+ietf@elandsys.com> wrote:
Beyond = that, I disagree that macros "diminish" SPF's utility in any way; their = mere presence in the protocol doesn't render it less useful, as one may = simply not use them and still get useful = results.

When the = main purported use is to determine a domain's outbound IP addresses, = macros preclude this prevalent use offering the greatest utility, bar = none.

I would argue that = DMARC, which makes use of SPF in a specific way, should not influence = SPF itself at this point as DMARC has no particular status with the IETF = yet.

DMARC does = not differ in how many hoped to make use of SPF.  Desired use is = very much at odds with stated SPF processing which is likely to require = subsequent reprocessing, with increased burdens and layer violations. =   

The dropping of type 99 RRTYPE support was made for more reasons than = just "sparse use", so I don't find that part of Doug's arguments = compelling.  I think we reached consensus on that debate long ago, = and it's been beaten to death recently once again on the main IETF = list.

Mark Andrews = made good points about increasing use of SPF 99 not shown in your = survey.  The general goal should be to ensure unknown RR types are = accommodated.  Unfortunately, some vendors still = don't.

The local-part macro = attack has been discussed to death.  There's no new information = presented here that I can see.

Saying RFC6686 "failed to provide a breakdown on = macro use" is to imply that it should have.  Analysis of macro use = was not part of the goal set of that document, so it's strange to = identify this as a failure.  However, I still have those data = available should there be some demonstrated purpose for mining the data = further.  Or, Doug can do his own survey and see what he = finds.

IMHO, it = was wrong (a failing) to limit a review of SPF to answer only whether = the PRA mode was being used.  This review should have also focused = on both macro publication and macro processing.  Whether it is = local-part macro or any other macro, cached results are not useful and = much of the SPF utility for defining a domain's outbound address space = is lost.  Since there is only 0.053% of domains using macros, it = becomes an easy trade-off some providers make.  They even have = stated ignoring SPF records containing macros do not result in = complaints.

The = document mentions use of macros given the advent of EAI, but I believe = the current spfbis document already deals with this in the same way DKIM = did.  Someone more expert in EAI than I am might want to confirm = we've done our due diligence = there.

It can no = longer be assumed domains will be encoded as A-labels. In addition, it = can not be assumed the local-part will be ASCII.  Such changes can = place spf libraries at risk.  In a quick review, it seems some = unused features in the libraries might permit induced buffer overruns. =  Adding in additional conversion libraries introduces more risk = which might compromise SMTP servers.  Nothing justifies these types = of risks to support something that is practically unused. =  

Overall, I don't think = this draft introduces any new material such that the WG needs to revisit = anything since WGLC = closed.

The macros = nixed draft was just updated to better clarify these = concerns.

Regards,
Douglas = Otis


= --Apple-Mail=_AC20CE27-2C69-4B2F-8B3D-8435CAC4DC9D-- From superuser@gmail.com Tue May 28 23:53:05 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB7A21F9048 for ; Tue, 28 May 2013 23:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTyZueLZ1cMI for ; Tue, 28 May 2013 23:52:57 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC1A21F8E76 for ; Tue, 28 May 2013 23:52:55 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id c10so3227236wiw.13 for ; Tue, 28 May 2013 23:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GbnR3Ed3Zvf7sPoXnFlxxE5Q/sYYNSNR2yJGUoCGw3Q=; b=LDL8GdOgLTvCItXBscC/whgUAK+aDVSWXptcdbGPjPkGkxrkKPkqAeVTo7DQvssO3K IkdAz0o417dpU6Ib3aD4WqYx94x/RWdksbII+0VJILpEtx48pjuPjZcsq+ceh8S2t6wh Ayev+BBdHb15PeIAmQTINp92RdRvDHME6NCTD0M28gZDHANnuwbuuYLNkhj4hPwsp0no iZKFkAhNXFWZPUa49x2IDM8/z81LmlaZUCDZ0gG/6T7p3j90VX7nqnK/03E3tGeqPxz5 P1sXh5Zh8DmW2pFE9hZLLiftrj7Xzs75aJLLV0ViN7TkIHpgX37CepMohthZkTBJ1k1L wHvA== MIME-Version: 1.0 X-Received: by 10.180.206.180 with SMTP id lp20mr14745617wic.41.1369810374521; Tue, 28 May 2013 23:52:54 -0700 (PDT) Received: by 10.180.74.203 with HTTP; Tue, 28 May 2013 23:52:54 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> Date: Tue, 28 May 2013 23:52:54 -0700 Message-ID: From: "Murray S. Kucherawy" To: Douglas Otis Content-Type: multipart/alternative; boundary=001a11c380b0c8792904ddd5d43c Cc: "spfbis@ietf.org" , S Moonesamy Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 06:53:06 -0000 --001a11c380b0c8792904ddd5d43c Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 28, 2013 at 9:46 PM, Douglas Otis wrote: > The macros nixed draft was just updated to better clarify these concerns. > > http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-01 > > For the record, I've reviewed the revision and your reply, and I have nothing to add. -MSK --001a11c380b0c8792904ddd5d43c Content-Type: text/html; charset=ISO-8859-1
On Tue, May 28, 2013 at 9:46 PM, Douglas Otis <doug.mtview@gmail.com> wrote:
The macros nixed draft was just updated to better clarify these concerns.

For the record, I've reviewed the revision and your reply, and I have nothing to add.

-MSK
--001a11c380b0c8792904ddd5d43c-- From dhc@dcrocker.net Wed May 29 07:29:25 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C316D21F9008 for ; Wed, 29 May 2013 07:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMuxOYYxURXV for ; Wed, 29 May 2013 07:29:20 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id BB79121F9012 for ; Wed, 29 May 2013 07:29:20 -0700 (PDT) Received: from [192.168.1.7] (chello080108132236.14.wu-wien.teleweb.at [80.108.132.236] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r4TET0Xx005777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 May 2013 07:29:05 -0700 Message-ID: <51A610A6.6010806@dcrocker.net> Date: Wed, 29 May 2013 16:28:54 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "spfbis@ietf.org" References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 29 May 2013 07:29:05 -0700 (PDT) Cc: S Moonesamy Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 14:29:25 -0000 On 5/29/2013 8:52 AM, Murray S. Kucherawy wrote: > > For the record, I've reviewed the revision and your reply, and I have > nothing to add. This topic is not merely dead and buried. It's fully decomposed. There's nothing left but dirt. We should let it rest, less we have some agricultural aspirations. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From john@jlc.net Wed May 29 07:36:43 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B7D21F8B16 for ; Wed, 29 May 2013 07:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Onbyo1GZke1e for ; Wed, 29 May 2013 07:36:38 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 50F1321F8B07 for ; Wed, 29 May 2013 07:36:36 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id C8DE433C26; Wed, 29 May 2013 10:36:35 -0400 (EDT) Date: Wed, 29 May 2013 10:36:35 -0400 From: John Leslie To: Douglas Otis Message-ID: <20130529143635.GZ23227@verdi> References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: "spfbis@ietf.org" , "Murray S. Kucherawy" , S Moonesamy Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 14:36:43 -0000 NB: I tend to take Doug seriously, and feel he deserves more that "We ignored him before: it's safe to ignore him again." Douglas Otis wrote: > On May 28, 2013, at 2:15 PM, Murray S. Kucherawy wrote: > >> Nixing macros based on non-use has already been debated at length, >> to the point of a low-level appeal, and it's been decided that >> they're staying. There's no action for the WG here based on that >> argument. I am not willing to advocate their removal, but I think they deserve to move a goodly way on the path to deprecation. They are indeed used (rarely), and are useful for some purposes not particularly central to SPF. Forbidding their use in this SPFbis would be going too far IMHO. Nonetheless, they remain a path to magnification of DoS. IMHO, folks _will_ turn off SPF macro expansion when it becomes a common tactic for DoS. (It's particularly nasty in that the initial request is free: a simple TXT record in DNS for some quite unrelated domain can set off at least ten seemingly-random DNS queries.) I quite agree it hasn't happened yet, and it doesn't seem likely to happen in the next year or two. Nonetheless, it's there for the taking, and it could become popular on rather short notice. > A pertinent point regarding the decision that receivers must process > macros is whether it represents a reasonable demand. "MUST process" strikes me as less than reasonable. The benefit to the receiver which processes them is minuscule. The benefit to the domain which publishes them can mostly be accomplished in a cheaper way, and for the bulk of the other cases statistical sampling would accomplish essentially as much: processing them for one case out of a hundred would serve _very_ nicely. > SPF records containing macros can not cache results and will always > necessitate reprocessing. (I don't understand Doug's point here either.) > If macro processing is skipped, any expectation of preserving > interchange is lost. In other words, it is broken by design by > asking too much from receivers. I do agree it asks too much of receivers. >> Beyond that, I disagree that macros "diminish" SPF's utility in >> any way; their mere presence in the protocol doesn't render it >> less useful, as one may simply not use them and still get useful >> results. Which is observed in the wild... > When the main purported use is to determine a domain's outbound > IP addresses, macros preclude this prevalent use offering the > greatest utility, bar none. (I don't understand that sentence either.) >> I would argue that DMARC, which makes use of SPF in a specific way, >> should not influence SPF itself at this point as DMARC has no >> particular status with the IETF yet. DMARC is heading toward an IETF status, though it seems premature to react to it at this time. > DMARC does not differ in how many hoped to make use of SPF. > Desired use is very much at odds with stated SPF processing which > is likely to require subsequent reprocessing, with increased burdens > and layer violations. > >> The dropping of type 99 RRTYPE support was made for more reasons >> than just "sparse use"... I'll not take that bait! >> The local-part macro attack has been discussed to death. Well, to exhaustion anyway... >> There's no new information presented here that I can see. I must admit I saw nothing to change my mind on that; but before Doug's recent posts I already strongly believed that SPF macros deserve a path towards deprecation. >> Saying RFC6686 "failed to provide a breakdown on macro use" is to >> imply that it should have... I have no opinion on that. > IMHO, it was wrong (a failing) to limit a review of SPF to answer only > whether the PRA mode was being used... No opinion on that either... >> The document mentions use of macros given the advent of EAI, but I >> believe the current spfbis document already deals with this in the >> same way DKIM did... EAI is a minefield for DNS -- but is no worse for SPF. > It can no longer be assumed domains will be encoded as A-labels... Alas, true; but again no worse for SPF than most other uses. -- John Leslie From SRS0=LyOEw=PO==stuart@gathman.org Wed May 29 07:41:01 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC7E21F8AD8 for ; Wed, 29 May 2013 07:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITrrbKeOnEkV for ; Wed, 29 May 2013 07:41:00 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id 266B021F8556 for ; Wed, 29 May 2013 07:41:00 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1369838491; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=Qk5XLzmtrYT9hkI6WEO4llF+PW45G+hrcpNeb8u7Xxw=; b=fjqC1Oyay7EGZZrPCe61WWO1/FqwjSo/++2TPUNvdaY6HNKhbLSJCa/FUVGb3oF0NcuQWL TyTKLelqLiOc49pDXO9/ULtUnvbu3gck/s62Ig5aKWoNfu2hXFYn3Tmo1QNbKyDy0IENW0A8 acfIAr57IrWRbXyyrdqiVH69xD8RQ= Received: from melissa.gathman.org (ip72-205-26-231.dc.dc.cox.net [72.205.26.231]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r4TEfUbN013078 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 29 May 2013 10:41:31 -0400 Message-ID: <51A6137A.7000203@gathman.org> Date: Wed, 29 May 2013 10:40:58 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <20130523224256.15462.62780.idtracker@ietfa.amsl.com> <4254865.V2u2IjG0lH@scott-latitude-e6320> In-Reply-To: <4254865.V2u2IjG0lH@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] New Version Notification for draft-ietf-spfbis-4408bis-15.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 14:41:27 -0000 Long ago, Nostradamus foresaw that on 05/23/2013 06:47 PM, Scott Kitterman would write: > On Thursday, May 23, 2013 03:42:56 PM you wrote: >> A new version of I-D, draft-ietf-spfbis-4408bis-15.txt >> has been successfully submitted by Scott Kitterman and posted to the >> IETF repository. >> >> Note that requirements for the domain presented in the EHLO or HELO Embarrassing grammar mistake in 2.1.2 command are not always clear to the sending party, and SPF verifiers have to be prepared for >>>>> is <<<<< identity to be an IP address literal (see [RFC5321] section 4.1.3), or simply be malformed. From dhc@dcrocker.net Wed May 29 07:43:07 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAA621F8FB6 for ; Wed, 29 May 2013 07:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3siyq-h9QMOL for ; Wed, 29 May 2013 07:43:00 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5B121F8D00 for ; Wed, 29 May 2013 07:43:00 -0700 (PDT) Received: from [192.168.1.7] (chello080108132236.14.wu-wien.teleweb.at [80.108.132.236] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r4TEgeA1006015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 May 2013 07:42:46 -0700 Message-ID: <51A613DB.6000608@dcrocker.net> Date: Wed, 29 May 2013 16:42:35 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Leslie References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> <20130529143635.GZ23227@verdi> In-Reply-To: <20130529143635.GZ23227@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 29 May 2013 07:42:47 -0700 (PDT) Cc: "spfbis@ietf.org" , "Murray S. Kucherawy" , S Moonesamy Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 14:43:08 -0000 On 5/29/2013 4:36 PM, John Leslie wrote: > I am not willing to advocate their removal, but I think they deserve > to move a goodly way on the path to deprecation. John, I think you've missed the rather basic IETF process point that has been explained at least twice in the latest round. That is, we've already fully and painfully dealt with this topic. It's not an open issue. Therefore discussing it it wasting yours and our time. Even our chairs have been motivated to note this fact explicitly. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Wed May 29 09:23:03 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDD621F95E1 for ; Wed, 29 May 2013 09:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GktBaj4g0cTZ for ; Wed, 29 May 2013 09:23:01 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 779A621F922A for ; Wed, 29 May 2013 09:22:59 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id w62so6497432wes.31 for ; Wed, 29 May 2013 09:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GGaM39c+6RECC9cI2mtECFShyjd/5WdeB/j+fnbN9Eg=; b=gIAEwYvmGy7M5qEM8ZRgU1V0YagufAvGtZ9G1HQELRXxvzxjs6JiQTUaYrYZ0QLZOK +5NGLxX9bvbwqNgZWxXML6yFLDbtjHr2L92vDczB9aKvmEruua1LieIbSyK6GkE53J0w cEEdSp1cCZp/e9L0jFh+p2497vpXoFQVmg8+3ZQrUzedcSL997ApL/2xGgl38hBqLgXt L/0OG4Oj9Tvq8NaAEjUc/W9eZXuRjcx+2SXbMrPdpCxISD2uDjC91irSE704jNzoDAdn kEE0e02/xJkZ7UnCGeMfp+YI67y9HZmqH5u52+9CN9XtDmTOi6VddCI+JmXCQakn9OX+ SNvA== MIME-Version: 1.0 X-Received: by 10.194.158.194 with SMTP id ww2mr2045357wjb.3.1369844578466; Wed, 29 May 2013 09:22:58 -0700 (PDT) Received: by 10.180.74.203 with HTTP; Wed, 29 May 2013 09:22:58 -0700 (PDT) In-Reply-To: <20130529143635.GZ23227@verdi> References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> <20130529143635.GZ23227@verdi> Date: Wed, 29 May 2013 09:22:58 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Leslie Content-Type: multipart/alternative; boundary=089e013c64de7f41e804ddddcb2b Cc: "spfbis@ietf.org" , Douglas Otis , S Moonesamy Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 16:23:03 -0000 --089e013c64de7f41e804ddddcb2b Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 29, 2013 at 7:36 AM, John Leslie wrote: > NB: I tend to take Doug seriously, and feel he deserves more that "We > ignored him before: it's safe to ignore him again." > I'm at a loss to understand how replying to his draft with a review of it constitutes ignoring him. Douglas Otis wrote: > > On May 28, 2013, at 2:15 PM, Murray S. Kucherawy > wrote: > > > >> Nixing macros based on non-use has already been debated at length, > >> to the point of a low-level appeal, and it's been decided that > >> they're staying. There's no action for the WG here based on that > >> argument. > > I am not willing to advocate their removal, but I think they deserve > to move a goodly way on the path to deprecation. > Could you please explain what procedural path you propose we follow to do so? You were, I believe, paying attention when their removal or even deprecation was proposed, argued, ruled out-of-charter, appealed, and put down. I would think at that point that the topic was de facto no longer valid for this WG. So, short of appealing the charter itself (which I would argue is far, far past the point of being a reasonable course of action), we would only be re-covering a well beaten path destined for the same result. > > Nonetheless, they remain a path to magnification of DoS. IMHO, folks > _will_ turn off SPF macro expansion when it becomes a common tactic for > DoS. (It's particularly nasty in that the initial request is free: a > simple TXT record in DNS for some quite unrelated domain can set off > at least ten seemingly-random DNS queries.) > > I quite agree it hasn't happened yet, and it doesn't seem likely to > happen in the next year or two. Nonetheless, it's there for the taking, > and it could become popular on rather short notice. > At best, you could propose text to add to the bis draft that discusses this (if it's not already) and see if it can get working group consensus to stay in. It would've been nice to do this prior to WGLC or its completion, of course, and it's up to the co-charis to decide whether to admit it all at this point. However, I suggest that rendering this entire portion of the protocol "optional" will monkey with interoperability, so I would argue against such a change. -MSK --089e013c64de7f41e804ddddcb2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 29, 2013 at 7:36 AM, John Leslie <john@jlc.net= > wrote:
NB: I tend to take Doug seriously, and feel he deserves more that "We<= br> ignored him before: it's safe to ignore him again."

I'm at a loss to understand how replying to his draft = with a review of it constitutes ignoring him.

Douglas Otis <doug.mtview@gmail= .com> wrote:
> On May 28, 2013, at 2:15 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
>
>> Nixing macros based on non-use has already= been debated at length,
>> to the point of a low-level appeal, and it's been decided that=
>> they're staying. =A0There's no action for the WG here base= d on that
>> argument.

=A0 =A0I am not willing to advocate their removal, but I think they d= eserve
to move a goodly way on the path to deprecation.

<= /div>
Could you please explain what procedural path you propose we foll= ow to do so?=A0 You were, I believe, paying attention when their removal or= even deprecation was proposed, argued, ruled out-of-charter, appealed, and= put down.=A0 I would think at that point that the topic was de facto no lo= nger valid for this WG.=A0 So, short of appealing the charter itself (which= I would argue is far, far past the point of being a reasonable course of a= ction), we would only be re-covering a well beaten path destined for the sa= me result.
=A0

=A0 =A0Nonetheless, they remain a path to magnification of DoS. IMHO, folks=
_will_ turn off SPF macro expansion when it becomes a common tactic for
DoS. (It's particularly nasty in that the initial request is free: a simple TXT record in DNS for some quite unrelated domain can set off
at least ten seemingly-random DNS queries.)

=A0 =A0I quite agree it hasn't happened yet, and it doesn't seem li= kely to
happen in the next year or two. Nonetheless, it's there for the taking,=
and it could become popular on rather short notice.
At best, you could propose text to add to the bis draft that d= iscusses this (if it's not already) and see if it can get working group= consensus to stay in.=A0 It would've been nice to do this prior to WGL= C or its completion, of course, and it's up to the co-charis to decide = whether to admit it all at this point.

However, I suggest that rendering this entire portion of the protocol &= quot;optional" will monkey with interoperability, so I would argue aga= inst such a change.

-MSK
--089e013c64de7f41e804ddddcb2b-- From doug.mtview@gmail.com Wed May 29 12:58:29 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE3E21F8F27 for ; Wed, 29 May 2013 12:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GF1FHQBuKoOk for ; Wed, 29 May 2013 12:58:28 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CE35A21F909A for ; Wed, 29 May 2013 12:58:21 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so9657498pbb.33 for ; Wed, 29 May 2013 12:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=gxNGF7WENo1NeUPaU3cGl+0CT9l+aS6FfIXtOzANMTM=; b=Je8/h8YE5LKU4tGL0DVOw8zoX/iLbQ1wDIb9SJnkwst3T+mmPl4gg5rSy4TvfdV3oE U0xmcFcUMLJZwkUSQgKfnAPsg1WDu45e+9sZ+hUffZAi8yCdc2GOX0qv0tA9KoOCxV6a ngrtWeg9kzXRcVzDvGYZ+ebZeRpxLL+GN9p7e0+2nspkvsECFmWoGdgUhwhiXqvCey1v auDMu/V1wndAdiGxbAlfxNlGFcAmmJU+2gIF/T3SsaDSPlx1H6Fy9vUvDVEyY8LFYVNc xXPWjIzA8i1vZFuuSoNp+AULDmXBUm5BfpecShM1wc1cpo38U2lKBnz7Sdu4R8jAdX4u Hudg== X-Received: by 10.66.13.169 with SMTP id i9mr4868494pac.212.1369857501478; Wed, 29 May 2013 12:58:21 -0700 (PDT) Received: from [192.168.0.99] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id nt6sm10029876pbb.4.2013.05.29.12.58.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 May 2013 12:58:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Douglas Otis In-Reply-To: <20130529143635.GZ23227@verdi> Date: Wed, 29 May 2013 12:58:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> <20130529143635.GZ23227@verdi> To: John Leslie X-Mailer: Apple Mail (2.1503) Cc: "spfbis@ietf.org" , "Murray S. Kucherawy" , S Moonesamy Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 19:58:29 -0000 On May 29, 2013, at 7:36 AM, John Leslie wrote: > NB: I tend to take Doug seriously, and feel he deserves more that "We > ignored him before: it's safe to ignore him again." >=20 > Douglas Otis wrote: >> On May 28, 2013, at 2:15 PM, Murray S. Kucherawy = wrote: >>=20 >>> Nixing macros based on non-use has already been debated at length, >>> to the point of a low-level appeal, and it's been decided that >>> they're staying. There's no action for the WG here based on that >>> argument. >=20 > I am not willing to advocate their removal, but I think they deserve > to move a goodly way on the path to deprecation. >=20 > They are indeed used (rarely), and are useful for some purposes not > particularly central to SPF. Forbidding their use in this SPFbis would > be going too far IMHO. Dear John, The WG had little problem deprecating SPF Resource Records, which = actually enjoyed greater and growing use. Clearly, this WG is not = vested in preserving DNS. However, efforts expended in creating a DNS based macro language and = associated compilers makes it difficult for those vested in SPF macros = to admit failure. Such reluctance is understandable. Several of the = macro mechanisms have been given a "do not use" designation. = Unfortunately, such advice does not go far enough since it offers = receivers no protection who are then expected to compile and resolve = scripts from unknown sources. Since macros are actually more likely to = interfere with acceptance, their use has become negligible where even = publishing macros will not ensure interchange. > Nonetheless, they remain a path to magnification of DoS. IMHO, folks > _will_ turn off SPF macro expansion when it becomes a common tactic = for > DoS. (It's particularly nasty in that the initial request is free: a > simple TXT record in DNS for some quite unrelated domain can set off > at least ten seemingly-random DNS queries.) Correction: SPF can set off 100 seemingly random DNS queries. DoS may = seem a minor concern compared to protecting server's resources from = non-cachable DNS related overhead. As such, some folks have already = turned-off SPF macros. The DoS issue may become more apparent when = DNSsec is deployed to support DANE enabled StartTLS for SMTP while = coping with IPv6. =20 SPF does not support RFC6532 internationalized email, nor does = suggesting RFC5890 in the specification properly deal with many possible = security issues. The SPF macro compiler will be dealing with non-ASCII = strings that may occur within local-part parameters never intended to be = DNS compliant, in addition to non-A-Label DNS. It only requires a = single buffer overrun to compromise an SMTP server. It seems negligent = to run SPF scripts outside of a sandbox when making substantial changes = to basic SPF macro compiler inputs. =20 > I quite agree it hasn't happened yet, and it doesn't seem likely to > happen in the next year or two. Nonetheless, it's there for the = taking, > and it could become popular on rather short notice. >=20 >> A pertinent point regarding the decision that receivers must process >> macros is whether it represents a reasonable demand. >=20 > "MUST process" strikes me as less than reasonable. The benefit to > the receiver which processes them is minuscule. The benefit to the > domain which publishes them can mostly be accomplished in a cheaper > way, and for the bulk of the other cases statistical sampling would > accomplish essentially as much: processing them for one case out of > a hundred would serve _very_ nicely. Agreed, and it only requires a few large providers to also reach this = conclusion for macros to then break interchange... >> SPF records containing macros can not cache results and will always >> necessitate reprocessing. >=20 > (I don't understand Doug's point here either.) When inputs into the SPF process include message elements beyond related = domains, re-executing the entire SPF process is the only compliant = method. If the SPF process were limited to just the related domain, = then results could be cached by domain. SPF macros may introduce label = and local-part components that remove possible 1:1 domain/result = relationships. A 1:1 domain/result relationship is restored when SPF = macros are ignored. Ignoring these macros convey many benefits to = receivers and was asserted by AOL at the onset of SPF. >> If macro processing is skipped, any expectation of preserving >> interchange is lost. In other words, it is broken by design by >> asking too much from receivers. >=20 > I do agree it asks too much of receivers. >=20 >>> Beyond that, I disagree that macros "diminish" SPF's utility in >>> any way; their mere presence in the protocol doesn't render it >>> less useful, as one may simply not use them and still get useful >>> results. >=20 > Which is observed in the wild... >> When the main purported use is to determine a domain's outbound >> IP addresses, macros preclude this prevalent use offering the >> greatest utility, bar none. >=20 > (I don't understand that sentence either.) The greatest utility expressed by providers for SPF (which may list MX = or hostname resources or simply offer CIDR notation) is to determine a = domain's outbound address space. Comparing this list against reputation = services quickly ascertains potential problems. When macros are used, ascertaining a domain's outbound address space can = not be determined without also processing SPF macros in conjunction with = message derived elements acting as inputs. Use of macros can easily = destroy this utility by introducing indeterminate unknowns, such as the = IP addresses of the client, or some portion of the local-part. These = elements may depend on indeterminately placed exists() resources. >>> I would argue that DMARC, which makes use of SPF in a specific way, >>> should not influence SPF itself at this point as DMARC has no >>> particular status with the IETF yet. >=20 > DMARC is heading toward an IETF status, though it seems premature > to react to it at this time. A processing priority conflict will require revisiting SPF processing = with different inputs more than once. An inability to cache results = against domains places greater emphasis on a need to immediately = deprecate macros. Now is the time for macro deprecation in all its = aspects. >> DMARC does not differ in how many hoped to make use of SPF. >> Desired use is very much at odds with stated SPF processing which >> is likely to require subsequent reprocessing, with increased burdens >> and layer violations. =20 >>=20 >>> The dropping of type 99 RRTYPE support was made for more reasons >>> than just "sparse use"... >=20 > I'll not take that bait! >=20 >>> The local-part macro attack has been discussed to death. >=20 > Well, to exhaustion anyway... >=20 >>> There's no new information presented here that I can see. >=20 > I must admit I saw nothing to change my mind on that; but before > Doug's recent posts I already strongly believed that SPF macros = deserve > a path towards deprecation. Agreed. The path offered by the WG does not protect receivers or ensure = interchange primarily due to survey oversights, IMHO.=20 >>> Saying RFC6686 "failed to provide a breakdown on macro use" is to >>> imply that it should have... >=20 > I have no opinion on that. Perhaps I should have said omitted any consideration of macro use, = although oddly the same survey concluded that SPF RR types should be = deprecated, without also noting an even greater disparity in macro = publication. >> IMHO, it was wrong (a failing) to limit a review of SPF to answer = only >> whether the PRA mode was being used... >=20 > No opinion on that either... >=20 >>> The document mentions use of macros given the advent of EAI, but I >>> believe the current spfbis document already deals with this in the >>> same way DKIM did... >=20 > EAI is a minefield for DNS -- but is no worse for SPF. How will a new reference to RFC5890 ensure security is retained? How = will SPF macro compilers handle new inputs? =20 >> It can no longer be assumed domains will be encoded as A-labels... >=20 > Alas, true; but again no worse for SPF than most other uses. The impact might be something fairly minor. An encoding that expands = differently in some library sub-component that then allows an SMTP = server to be compromised. How will this play with existing libraries, = and how will this operate in conjunction with new changes? Is it really = safe to assume there will not be any problem? As a side note, the macros-nixed I-D was made available earlier, but SM = wanted to delay its review until after the WG concluded its revision = process. After all, there was every reason to believe the related = concerns would be casually dismissed by the WG. I'll make a few more = changes to address some of the expressed confusion. Any input or criticism either on or off the list is most welcome. Thank = you. Regards, Douglas Otis= From ajs@anvilwalrusden.com Wed May 29 13:21:59 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC9021F9776 for ; Wed, 29 May 2013 13:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S899Rr2TBIwC for ; Wed, 29 May 2013 13:21:53 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBDC21F9763 for ; Wed, 29 May 2013 13:21:51 -0700 (PDT) Received: from mx1.yitter.info (nat-01-mht.dyndns.com [216.146.45.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id F0FCF8A031 for ; Wed, 29 May 2013 20:21:49 +0000 (UTC) Date: Wed, 29 May 2013 16:21:45 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130529202145.GA9506@mx1.yitter.info> References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> <20130529143635.GZ23227@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 20:21:59 -0000 I'm not sure whether I'm wearing any hat here. On Wed, May 29, 2013 at 12:58:17PM -0700, Douglas Otis wrote: > > The WG had little problem deprecating SPF Resource Records, which > actually enjoyed greater and growing use. Clearly, this WG is not > vested in preserving DNS. > > However, efforts expended in creating a DNS based macro language and > associated compilers makes it difficult for those vested in SPF > macros to admit failure. Such reluctance is understandable. This analogy is, in my personal opinion, invidious. The reason the WG decided to deprecate the SPF RRTYPE is because RFC 4408 has an actual interoperability problem in it. You may recall that SM and I originally ruled that deprecation of the SPF RRTYPE was _out_ of scope, on the grounds that it was "used". Our interpretation of "used" was that, if there was any evidence of deployment on the network, then the feature was not unused, and therefore it was beyond the scope of the WG's charter to deprecate the feature. I think the charter is crystal clear about this matter. This decision was appealed to the AD, who agreed with us (though not about the crystal clarity). The only reason we decided that we had to do something with TYPE 99 was simply that there turned out to be an interoperability problem. We had to do something backward-incompatible _no matter what_, so we determined at that point that we should deprecate the least-used RRTYPE. In order to deprecate macros the same way, we would need some argument as to why it would be acceptable to violate our charter in that way. Otherwise, since there are some people using macros, they are still used so we have to maintain them. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From dhc@dcrocker.net Wed May 29 13:25:44 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D7F21F979A for ; Wed, 29 May 2013 13:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBpBHrhAgVq4 for ; Wed, 29 May 2013 13:25:31 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADCA21F97A1 for ; Wed, 29 May 2013 13:25:29 -0700 (PDT) Received: from [173.255.178.203] (203.178.255.173.client.dyn.strong-mf8.as54203.net [173.255.178.203]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r4TKPLb6013996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 May 2013 13:25:27 -0700 Message-ID: <51A6642C.80001@dcrocker.net> Date: Wed, 29 May 2013 22:25:16 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andrew Sullivan References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> <20130529143635.GZ23227@verdi> <20130529202145.GA9506@mx1.yitter.info> In-Reply-To: <20130529202145.GA9506@mx1.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 29 May 2013 13:25:27 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 20:25:45 -0000 On 5/29/2013 10:21 PM, Andrew Sullivan wrote: > This analogy is, in my personal opinion, invidious. the thread is invidious, not just the analogy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Wed May 29 13:56:16 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42EC21F968F for ; Wed, 29 May 2013 13:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDmY59pLNuQw for ; Wed, 29 May 2013 13:55:21 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D20F21F94B1 for ; Wed, 29 May 2013 13:55:19 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.215]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4TKsuPQ003089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 May 2013 13:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1369860908; bh=s/GSYwFG19bDNSk6yxt+iuD2ERowITFBa+s602dN5uI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=H5hYbxE+li97rQD6T9ve0XnLnf/2gBrloIk5iHEJRdC/f/mX/9OucYyM8/4FvPcMV 1PxV37/sfC1NlAOK5mS6AUOl/iLYxorxXDglYIbWImeSN20PLon9/XEUvpl7QGNa/e V0CiibXDlEey87SQXnbwMUU8nx+NwWfD69bCki/w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1369860908; i=@elandsys.com; bh=s/GSYwFG19bDNSk6yxt+iuD2ERowITFBa+s602dN5uI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Qct+e58pE23raV26IABnddnoePgaZOI3xjfSy0dE+KutKq8DK7WSyRAYJsyetG3ta xAGd/QfKIjsWUg+N7qk4JHsoSMG2Hu7O101URAI/nui8iEfyZggSaMo90ss12I2OIs kT1I568lUW/TGsOT/ZvE2boFQPbm0QcRttHCsgdg= Message-Id: <6.2.5.6.2.20130529132031.0e9b6668@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 29 May 2013 13:50:58 -0700 To: Douglas Otis From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> <20130529143635.GZ23227@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 20:56:17 -0000 Hi Doug, At 12:58 29-05-2013, Douglas Otis wrote: >As a side note, the macros-nixed I-D was made available earlier, but >SM wanted to delay its review until after the WG concluded its >revision process. After all, there was every reason to believe the >related concerns would be casually dismissed by the WG. I'll make a >few more changes to address some of the expressed confusion. I'll comment as an individual. A summary of the WGLC for draft-ietf-spfbis-4408bis-14 was posted on April 24. That is the date the WGLC ended. The directorate/review team reviews arrived after that. A reminder about addressing those reviews and the comments received during the WGLC was posted on April 30. A message about draft-otis-spfbis-macros-nixed-00 was posted to the SPFBIS mailing list on May 16. I was tracking the existing comments. There are limits to what I can do. :-) It is up to the SPFBIS working group to carefully consider the comments in draft-otis-spfbis-macros-nixed-01. I don't think that it is a good idea to dismiss any concerns casually. If you believe that the concerns you raised were not addressed correctly, please let me know so that I can bring it to the attention of the Area Director. Regards, S. Moonesamy From marka@isc.org Wed May 29 14:26:21 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B384021F8FB6 for ; Wed, 29 May 2013 14:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3s7K7kTlXn7 for ; Wed, 29 May 2013 14:26:21 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 21A3F21F8F7B for ; Wed, 29 May 2013 14:26:20 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id BC3E2C94BF; Wed, 29 May 2013 21:26:07 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1369862780; bh=Akkd+/lrNpCM4n/Zwn7hFB/vammgjbgTG0UIYByKgz8=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Vl3CiT7QQ8ofFQicuAnOlfxI1MgwNr2vmoTyldJS6jGiThnRCVOWyaThmr7FUdvTk yYttR3pOiCiAG2aQ1N2HPLF/y8eFhZWyE27MW517iZpZgp9LscF+QOf0DmTz5VLyYL 1bWiHcd7cLnbXHykx3tXE+MWTYkR6xIfUMDA5yX4= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 29 May 2013 21:26:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 52863216C47; Wed, 29 May 2013 21:26:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5909734DBABF; Thu, 30 May 2013 07:26:02 +1000 (EST) To: Andrew Sullivan From: Mark Andrews References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> <20130529143635.GZ23227@verdi> <20130529202145.GA9506@mx1.yitter.info> In-reply-to: Your message of "Wed, 29 May 2013 16:21:45 -0400." <20130529202145.GA9506@mx1.yitter.info> Date: Thu, 30 May 2013 07:26:01 +1000 Message-Id: <20130529212602.5909734DBABF@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: spfbis@ietf.org Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 21:26:21 -0000 In message <20130529202145.GA9506@mx1.yitter.info>, Andrew Sullivan writes: > I'm not sure whether I'm wearing any hat here. > > On Wed, May 29, 2013 at 12:58:17PM -0700, Douglas Otis wrote: > > > > The WG had little problem deprecating SPF Resource Records, which > > actually enjoyed greater and growing use. Clearly, this WG is not > > vested in preserving DNS. > > > > However, efforts expended in creating a DNS based macro language and > > associated compilers makes it difficult for those vested in SPF > > macros to admit failure. Such reluctance is understandable. > > This analogy is, in my personal opinion, invidious. > > The reason the WG decided to deprecate the SPF RRTYPE is because RFC > 4408 has an actual interoperability problem in it. You may recall > that SM and I originally ruled that deprecation of the SPF RRTYPE was > _out_ of scope, on the grounds that it was "used". Our interpretation > of "used" was that, if there was any evidence of deployment on the > network, then the feature was not unused, and therefore it was beyond > the scope of the WG's charter to deprecate the feature. I think the > charter is crystal clear about this matter. This decision was > appealed to the AD, who agreed with us (though not about the crystal clarity) > . > > The only reason we decided that we had to do something with TYPE 99 > was simply that there turned out to be an interoperability problem. > We had to do something backward-incompatible _no matter what_, so we > determined at that point that we should deprecate the least-used > RRTYPE. And what has been done does NOT fix the perceived interoperability problem. There are lots of sites *using* type 99 some of which don't publish TXT records despite the SHOULD. The group is expecting those sites to suddenly replace those records with TXT record. There is no plan to get from where we are today back to TXT only. There will forever be confusion about what record to use because there will forever be a record called SPF which you do not use for SPF. Note even we have to use "type 99" to avoid this confusion. > In order to deprecate macros the same way, we would need some argument > as to why it would be acceptable to violate our charter in that way. > Otherwise, since there are some people using macros, they are still > used so we have to maintain them. > > Best, > > A > > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ajs@anvilwalrusden.com Wed May 29 14:42:45 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FB921F9764 for ; Wed, 29 May 2013 14:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjJQsP4bEFKS for ; Wed, 29 May 2013 14:42:39 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 494F021F9763 for ; Wed, 29 May 2013 14:42:37 -0700 (PDT) Received: from mx1.yitter.info (nat-01-mht.dyndns.com [216.146.45.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 7BF038A031 for ; Wed, 29 May 2013 21:42:36 +0000 (UTC) Date: Wed, 29 May 2013 17:42:34 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130529214234.GB9584@mx1.yitter.info> References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> <20130529143635.GZ23227@verdi> <20130529202145.GA9506@mx1.yitter.info> <20130529212602.5909734DBABF@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130529212602.5909734DBABF@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] The RRTYPE topic (was: WGLC: draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 21:42:45 -0000 Moderator hat. Mark, On Thu, May 30, 2013 at 07:26:01AM +1000, Mark Andrews wrote: > > In message <20130529202145.GA9506@mx1.yitter.info>, Andrew Sullivan writes: > > The only reason we decided that we had to do something with TYPE 99 > And what has been done does NOT fix the perceived interoperability If you're going to start a completely irrelevant thread to the thing we are talking about, do you think you might at least change the subject line? The RRTYPE discussion has been closed in this WG; we made a decision some time ago. You have not presented any new arguments, as nearly as I can tell, for revisiting that decision, so I don't think it is reasonable to reopen the discussion. But if you plan to do so, please at least don't drag that red herring through the path of a different, already contentious, discussion. Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Wed May 29 15:08:34 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5D921F93F4 for ; Wed, 29 May 2013 15:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RCQtuo8gOet for ; Wed, 29 May 2013 15:08:33 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A01DD21F93D2 for ; Wed, 29 May 2013 15:08:33 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 6E585C94B7; Wed, 29 May 2013 22:08:24 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1369865313; bh=B5N2XyS8PXO4Fhn5Gm9LH4Eazo2dvOuXtU/uODqzYXk=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=e46SWHc/eF9m0Zw5iGdo1raP9GHQX61tdv9OlDCZQ2Drci65Ojo71091OF3W4+i7D ThM+K0XeliNWTKxt8+r6ZJ/jIMFgXB/6saXr6eXaM6OqLsZXU00C8lxD0DS32Vu62x XaincJaG4DrXMTwfKBXtZOZ1BTMwLQSwvf9XRCyc= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 29 May 2013 22:08:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4d9f:af8e:ad79:c073]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 279AD216C52; Wed, 29 May 2013 22:08:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2326134DBF6E; Thu, 30 May 2013 08:08:22 +1000 (EST) To: Andrew Sullivan From: Mark Andrews References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> <20130529143635.GZ23227@verdi> <20130529202145.GA9506@mx1.yitter.info> <20130529212602.5909734DBABF@drugs.dv.isc.org> <20130529214234.GB9584@mx1.yitter.info> In-reply-to: Your message of "Wed, 29 May 2013 17:42:34 -0400." <20130529214234.GB9584@mx1.yitter.info> Date: Thu, 30 May 2013 08:08:22 +1000 Message-Id: <20130529220822.2326134DBF6E@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: spfbis@ietf.org Subject: Re: [spfbis] The RRTYPE topic (was: WGLC: draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 22:08:34 -0000 In message <20130529214234.GB9584@mx1.yitter.info>, Andrew Sullivan writes: > Moderator hat. > > Mark, > > On Thu, May 30, 2013 at 07:26:01AM +1000, Mark Andrews wrote: > > > > In message <20130529202145.GA9506@mx1.yitter.info>, Andrew Sullivan writes: > > > The only reason we decided that we had to do something with TYPE 99 > > > And what has been done does NOT fix the perceived interoperability > > If you're going to start a completely irrelevant thread to the thing > we are talking about, do you think you might at least change the > subject line? > > The RRTYPE discussion has been closed in this WG; we made a decision > some time ago. You have not presented any new arguments, as nearly as > I can tell, for revisiting that decision, so I don't think it is > reasonable to reopen the discussion. But if you plan to do so, please > at least don't drag that red herring through the path of a different, > already contentious, discussion. The working group has created two new unaddressed issue by going the TXT only. * how to get people who fielded only SPF records to move to TXT records * how to deal with the confusion of a SPF record that isn't to be used for SPF. Neither of those issues are currently addressed. > Thanks, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From superuser@gmail.com Wed May 29 16:56:24 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775D821F8B2B for ; Wed, 29 May 2013 16:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RB6f2DKkH4Yr for ; Wed, 29 May 2013 16:56:24 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id D9A1321F8B04 for ; Wed, 29 May 2013 16:56:23 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id um15so9932366pbc.25 for ; Wed, 29 May 2013 16:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B0+DU+24qR+haMcS5bms2cju0NBRThYr+pTmtBcvJXc=; b=BaUo3CoTqM5o3mJWA52+LIbqyHEEyW7ikJeNIvi4IBGwlO8lq0zQ6n/VvN73RrbAG7 D7zpbq4rLWYyI5ZBOHzyk5Wl8nPXR6sW2YHUqcU6JLzgMf+l1G0mwTpnm+KbHeSz5pxO UhU/7hs6h3a68pQoCrHhUFrDMnT5eWa/sOeGIWB1Bku8hC1IonVuQGlVI5+YKil9dryb Jou07P7269l2uTqlkK+Q9Sf+FMoKiiBH9H2xQt25IimGU6xEiMFzU2W7kN+9beS80oZm 2RD0BOF5C4sRWwYHBVbnfuds/N7oHNpljx/b67HLsOscHOhSvQQxMnE/S7rZ7c4rpVS/ Ws+Q== MIME-Version: 1.0 X-Received: by 10.66.126.11 with SMTP id mu11mr5606228pab.81.1369871783595; Wed, 29 May 2013 16:56:23 -0700 (PDT) Received: by 10.66.234.2 with HTTP; Wed, 29 May 2013 16:56:23 -0700 (PDT) In-Reply-To: <20130529220822.2326134DBF6E@drugs.dv.isc.org> References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> <20130529143635.GZ23227@verdi> <20130529202145.GA9506@mx1.yitter.info> <20130529212602.5909734DBABF@drugs.dv.isc.org> <20130529214234.GB9584@mx1.yitter.info> <20130529220822.2326134DBF6E@drugs.dv.isc.org> Date: Wed, 29 May 2013 16:56:23 -0700 Message-ID: From: "Murray S. Kucherawy" To: Mark Andrews Content-Type: multipart/alternative; boundary=485b395e7de70c954704dde421e1 Cc: "spfbis@ietf.org" , Andrew Sullivan Subject: Re: [spfbis] The RRTYPE topic (was: WGLC: draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 23:56:24 -0000 --485b395e7de70c954704dde421e1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 29, 2013 at 3:08 PM, Mark Andrews wrote: > The working group has created two new unaddressed issue by going the TXT > only. > > * how to get people who fielded only SPF records to move to TXT records > * how to deal with the confusion of a SPF record that isn't to be used > for SPF. > > Neither of those issues are currently addressed. > > To the first point: If we go in the opposite direction and deprecate use of TXT for SPF, the community of people that needs to update is vastly larger. How is that the better solution? I don't understand what you mean by the second thing. -MSK --485b395e7de70c954704dde421e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 29, 2013 at 3:08 PM, Mark Andrews <marka@isc.org<= /a>> wrote:
The working group has created two new unaddressed issue by going the TXT only.

* how to get people who fielded only SPF records to move to TXT records
* how to deal with the confusion of a SPF record that isn't to be used<= br> =A0 for SPF.

Neither of those issues are currently addressed.


To the first point: If we go in the opposite direction and= deprecate use of TXT for SPF, the community of people that needs to update= is vastly larger.=A0 How is that the better solution?

I don't understand what you mean b= y the second thing.

-MSK
<= /div> --485b395e7de70c954704dde421e1-- From marka@isc.org Wed May 29 17:39:34 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032DC21F918F for ; Wed, 29 May 2013 17:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwKOMNQpyPqj for ; Wed, 29 May 2013 17:39:33 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 9254B21F8CEC for ; Wed, 29 May 2013 17:39:25 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 56FA15F98FC; Thu, 30 May 2013 00:39:15 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1369874364; bh=78dY23+icxtBUasDmI5khUV2OuHF6tft++wWVAriH+A=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=Gw1abpfi8f7to+ArUNZ6u2ewyxFNYQwbKn7A4JzYFp+bTgn3qvp1SLA2f/u8F47s9 nNGyjPOEYQRdfdAfT857REfMmDXP7QyadLV6QN8DSE4zo3SAfpzF8fN/41CLMf4qaE 15sW16xyS4dnuCeq+xWmdSFm/BuKjxH0Z6Y4A8jg= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 1FC89216C40; Thu, 30 May 2013 00:39:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6983934DF471; Thu, 30 May 2013 10:39:06 +1000 (EST) To: "Murray S. Kucherawy" From: Mark Andrews References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> <20130529143635.GZ23227@verdi> <20130529202145.GA9506@mx1.yitter.info> <20130529212602.5909734DBABF@drugs.dv.isc.org> <20130529214234.GB9584@mx1.yitter.info> <20130529220822.2326134DBF6E@drugs.dv.isc.org> In-reply-to: Your message of "Wed, 29 May 2013 16:56:23 -0700." Date: Thu, 30 May 2013 10:39:05 +1000 Message-Id: <20130530003906.6983934DF471@drugs.dv.isc.org> Cc: "spfbis@ietf.org" , Andrew Sullivan Subject: Re: [spfbis] The RRTYPE topic (was: WGLC: draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 00:39:34 -0000 In message , "Murray S. Kucherawy" writes: > On Wed, May 29, 2013 at 3:08 PM, Mark Andrews wrote: > > > The working group has created two new unaddressed issue by going the TXT > > only. > > > > * how to get people who fielded only SPF records to move to TXT records > > * how to deal with the confusion of a SPF record that isn't to be used > > for SPF. > > > > Neither of those issues are currently addressed. > > > > > To the first point: If we go in the opposite direction and deprecate use of > TXT for SPF, the community of people that needs to update is vastly > larger. How is that the better solution? I hesitate to answer this because I will be told to shutup again. Firstly no one has asked anyone to deprecate the use of TXT for SPF but if one wanted too one could direct nameserver vendors to log messages, refuse to load the zone or synthesis a SPF record if a SPF/TXT record was found without a SPF/SPF record. Code has shipped in nameservers that logs such a message. It logs a message when the "SHOULD publish both" of RFC 4408 is not being met. As for numbers the survey was taken *very* early in a transition from TXT to SPF. SPF record have doubled as a percentage since the initial survey was taken. SPF is a experimental type in RFC 4408 which definitely has some impact on whether support for parsing SPF record was added to nameservers. > I don't understand what you mean by the second thing. You have a DNS record with a mnemonic of SPF that is not to be used for SPF. What does the instruction "Put a SPF record in the DNS" mean? Will it result in a type 99 record being added? How will such errors be prevented? > -MSK > > --485b395e7de70c954704dde421e1 > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > >
On Wed, May 29, 2013 at 3:08 PM, Mark Andrews "ltr"><marka@isc.org<= > /a>> wrote:
te">
der-left:1px solid rgb(204,204,204);padding-left:1ex"> > The working group has created two new unaddressed issue by going the TXT > > only.
>
> * how to get people who fielded only SPF records to move to TXT records
> * how to deal with the confusion of a SPF record that isn't to be used<= > br> > =A0 for SPF.
>
> Neither of those issues are currently addressed.
>


=3D"gmail_extra">To the first point: If we go in the opposite direction and= > deprecate use of TXT for SPF, the community of people that needs to update= > is vastly larger.=A0 How is that the better solution?
>
I don't understand what you mean b= > y the second thing.

-MSK
<= > /div> > > --485b395e7de70c954704dde421e1-- > > --===============2300023921508032151== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > --===============2300023921508032151==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ajs@anvilwalrusden.com Wed May 29 18:15:46 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A2421F939E for ; Wed, 29 May 2013 18:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXlXoWPxVnZA for ; Wed, 29 May 2013 18:15:40 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id C92FE21F93C4 for ; Wed, 29 May 2013 18:15:40 -0700 (PDT) Received: from mx1.yitter.info (c-50-136-77-224.hsd1.nh.comcast.net [50.136.77.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 2CE318A038 for ; Thu, 30 May 2013 01:15:40 +0000 (UTC) Date: Wed, 29 May 2013 21:15:41 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130530011540.GE43673@mx1.yitter.info> References: <20130529143635.GZ23227@verdi> <20130529202145.GA9506@mx1.yitter.info> <20130529212602.5909734DBABF@drugs.dv.isc.org> <20130529214234.GB9584@mx1.yitter.info> <20130529220822.2326134DBF6E@drugs.dv.isc.org> <20130530003906.6983934DF471@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130530003906.6983934DF471@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] The RRTYPE topic (was: WGLC: draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 01:15:46 -0000 No hat. On Thu, May 30, 2013 at 10:39:05AM +1000, Mark Andrews wrote: > You have a DNS record with a mnemonic of SPF that is not to be used > for SPF. What does the instruction "Put a SPF record in the DNS" > mean? Will it result in a type 99 record being added? How will > such errors be prevented? Wouldn't it be good of name servers to detect someone attempting to serve a deprecated RRTYPE, and warn them of this? A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Wed May 29 18:30:31 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B940321F9193 for ; Wed, 29 May 2013 18:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8LZHSp75kvy for ; Wed, 29 May 2013 18:30:30 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 54F7521F9123 for ; Wed, 29 May 2013 18:30:30 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id B86E65F983B; Thu, 30 May 2013 01:30:21 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1369877429; bh=TGIYAOAU9Q5TERBI9+bdCZtFNy2J8lqWauEQ2nQqAig=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=uz/+rhJKXGkRoAl0eeM4gvKqkOC0be9MGWTRxj8Iz+D2aWNCqh2g/QQZdJ8PELJSE hOD6ceB9iYD2QnsMG59/0TtHQpGZmHYe6pUxBbFa/pmfg8v09WS4jh9jPbVRJ6kCmB fUBkWi7mFeCs/t9vCJVSqqLNDtdsZrnw1RpBAGFw= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id F271F216C40; Thu, 30 May 2013 01:30:19 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2ABE434E2004; Thu, 30 May 2013 11:30:17 +1000 (EST) To: Andrew Sullivan From: Mark Andrews References: <20130529143635.GZ23227@verdi> <20130529202145.GA9506@mx1.yitter.info> <20130529212602.5909734DBABF@drugs.dv.isc.org> <20130529214234.GB9584@mx1.yitter.info> <20130529220822.2326134DBF6E@drugs.dv.isc.org> <20130530003906.6983934DF471@drugs.dv.isc.org> <20130530011540.GE43673@mx1.yitter.info> In-reply-to: Your message of "Wed, 29 May 2013 21:15:41 -0400." <20130530011540.GE43673@mx1.yitter.info> Date: Thu, 30 May 2013 11:30:17 +1000 Message-Id: <20130530013017.2ABE434E2004@drugs.dv.isc.org> Cc: spfbis@ietf.org Subject: Re: [spfbis] The RRTYPE topic (was: WGLC: draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 01:30:31 -0000 In message <20130530011540.GE43673@mx1.yitter.info>, Andrew Sullivan writes: > No hat. > > On Thu, May 30, 2013 at 10:39:05AM +1000, Mark Andrews wrote: > > > You have a DNS record with a mnemonic of SPF that is not to be used > > for SPF. What does the instruction "Put a SPF record in the DNS" > > mean? Will it result in a type 99 record being added? How will > > such errors be prevented? > > Wouldn't it be good of name servers to detect someone attempting to > serve a deprecated RRTYPE, and warn them of this? Yes. Note, I don't see how this is different to warning about a missing SPF record which I'm sure if I go rummage about in the archives I will find as being rejected as a part of the solution to the perceived interoperability problem except you would never want to turn it off. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From spf2@kitterman.com Wed May 29 20:20:11 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77FE11E80A6 for ; Wed, 29 May 2013 20:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyQDAMu3jMfS for ; Wed, 29 May 2013 20:20:05 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A64BB11E80C5 for ; Wed, 29 May 2013 20:19:56 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5D7EE20E40D4; Wed, 29 May 2013 23:19:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369883995; bh=o8msjdPmF0g6RsLlN1+0jdO9dKRsCVGbuSkBr2cljew=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cpHiHj1Dm1+goOMK7Q5q84CmIOSxUgbtSW1cV03hsiUOccd1OzpWKqOplInpTa+AL UdCZqLfV48LDhzQc9x3rWbMX2Fsj2b4Kt5EieUPRO68Ihkjx1Q8TE+w+02oKUD29y1 T6JLrVoFOvq3ulIOkYPZvOBrYXLYGs90SKdoucEQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4316620E40B0; Wed, 29 May 2013 23:19:54 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 29 May 2013 23:19:52 -0400 Message-ID: <1722177.kRMm2DMPxH@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-22-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <51A6137A.7000203@gathman.org> References: <20130523224256.15462.62780.idtracker@ietfa.amsl.com> <4254865.V2u2IjG0lH@scott-latitude-e6320> <51A6137A.7000203@gathman.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New Version Notification for draft-ietf-spfbis-4408bis-15.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 03:20:11 -0000 On Wednesday, May 29, 2013 10:40:58 AM Stuart Gathman wrote: > Long ago, Nostradamus foresaw that on 05/23/2013 06:47 PM, Scott > > Kitterman would write: > > On Thursday, May 23, 2013 03:42:56 PM you wrote: > >> A new version of I-D, draft-ietf-spfbis-4408bis-15.txt > >> has been successfully submitted by Scott Kitterman and posted to the > >> IETF repository. > >> > >> Note that requirements for the domain presented in the EHLO or HELO > > Embarrassing grammar mistake in 2.1.2 > > command are not always clear to the sending party, and SPF verifiers > have to be prepared for >>>>> is <<<<< identity to be an IP address > literal (see > [RFC5321] section 4.1.3), or simply be malformed. Thanks. Fixed locally. Scott K From superuser@gmail.com Wed May 29 22:41:50 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247DF21F92B7 for ; Wed, 29 May 2013 22:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V64eZfUn6w37 for ; Wed, 29 May 2013 22:41:49 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBBE21F8930 for ; Wed, 29 May 2013 22:41:48 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id m46so6872151wev.24 for ; Wed, 29 May 2013 22:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ochEWlKzZZsDTv1gFr9Td7wRpu3OPIlT/2LLr/ko8Mo=; b=KWnCA7rxmnWIAokzjzsygPrbw+iVd+CLthfG03pKdqfjIClEdm8nc21hclTBlLgUNE b68l71gqeI3k6E/LmBPt6bh4Inyf5pzJrg6S2e5Sbdp2gl2nabRCsBIhsXQTZ/Zk9/VR Kcc8hd2JXgXCnq1R6+DGGCUsP3Sv6VqzT5iIrOmvVQ3hxlmyCRl07fAzSbjHo5uZgD/y gZutId6LhI9dw5i15ZCSDwxuei3rApLpqbF8c0bQZygj7nCSYmqyHN5EnovQi1I8DD2V RV+qLoApBDDd/VgzYHx+Sl3WtD1eSAfXwvsgfsT10Oraz0aGbwvTH+IiQ97UQ4YAcXSS +bmg== MIME-Version: 1.0 X-Received: by 10.194.123.69 with SMTP id ly5mr2984985wjb.29.1369892508103; Wed, 29 May 2013 22:41:48 -0700 (PDT) Received: by 10.180.74.203 with HTTP; Wed, 29 May 2013 22:41:48 -0700 (PDT) In-Reply-To: <20130530003906.6983934DF471@drugs.dv.isc.org> References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> <20130529143635.GZ23227@verdi> <20130529202145.GA9506@mx1.yitter.info> <20130529212602.5909734DBABF@drugs.dv.isc.org> <20130529214234.GB9584@mx1.yitter.info> <20130529220822.2326134DBF6E@drugs.dv.isc.org> <20130530003906.6983934DF471@drugs.dv.isc.org> Date: Wed, 29 May 2013 22:41:48 -0700 Message-ID: From: "Murray S. Kucherawy" To: Mark Andrews Content-Type: multipart/alternative; boundary=089e01175f83537a2f04dde8f45f Cc: "spfbis@ietf.org" , Andrew Sullivan Subject: Re: [spfbis] The RRTYPE topic (was: WGLC: draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 05:41:50 -0000 --089e01175f83537a2f04dde8f45f Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 29, 2013 at 5:39 PM, Mark Andrews wrote: > As for numbers the survey was taken *very* early in a transition > from TXT to SPF. SPF record have doubled as a percentage since the > initial survey was taken. > > RFC4408 was published in 2006, and SPF had been in extra-IETF development for a while before that. RFC6686 was published less than a year ago. I don't see how you can characterize that as "early". -MSK --089e01175f83537a2f04dde8f45f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --089e01175f83537a2f04dde8f45f-- From marka@isc.org Wed May 29 23:43:57 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C2721F95EB for ; Wed, 29 May 2013 23:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zohZ2QwWzZg for ; Wed, 29 May 2013 23:43:57 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 27FBB21F9579 for ; Wed, 29 May 2013 23:43:57 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id B3B1EC9428; Thu, 30 May 2013 06:43:50 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1369896236; bh=15wKR7y34T/yPASUlsinHcP99NVmhBABWYAotzcS1ZY=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=aS+J/m5MwFKDroc/QmKIDqtU0CMVH8meM9zo6S/C1rNQm42tIwPTU4V12fUpQsBGw jdDE4gwW0vGsfok1GVaccgcwMyvCahw0NAdstR0VtZsQYzyXzGSYk+0Bnn+bx9Jh9Y vkNhM4+6tYyzu/iCxK+bmQrj6U9SgEZ9hfdJcVbA= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Thu, 30 May 2013 06:43:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 58F99216C40; Thu, 30 May 2013 06:43:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 9F7DE34EC657; Thu, 30 May 2013 16:43:41 +1000 (EST) To: "Murray S. Kucherawy" From: Mark Andrews References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> <20130529143635.GZ23227@verdi> <20130529202145.GA9506@mx1.yitter.info> <20130529212602.5909734DBABF@drugs.dv.isc.org> <20130529214234.GB9584@mx1.yitter.info> <20130529220822.2326134DBF6E@drugs.dv.isc.org> <20130530003906.6983934DF471@drugs.dv.isc.org> In-reply-to: Your message of "Wed, 29 May 2013 22:41:48 -0700." Date: Thu, 30 May 2013 16:43:41 +1000 Message-Id: <20130530064341.9F7DE34EC657@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "spfbis@ietf.org" , Andrew Sullivan Subject: Re: [spfbis] The RRTYPE topic (was: WGLC: draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 06:43:57 -0000 In message , "Murray S. Kucherawy" writes: > > On Wed, May 29, 2013 at 5:39 PM, Mark Andrews wrote: > > > As for numbers the survey was taken *very* early in a transition > > from TXT to SPF. SPF record have doubled as a percentage since the > > initial survey was taken. > > > > > RFC4408 was published in 2006, and SPF had been in extra-IETF development > for a while before that. RFC6686 was published less than a year ago. I > don't see how you can characterize that as "early". In a project that I would expect to take 15+ years years to complete yes it was early. For a project where the SPF propronent took until 2008 to issue new library code that made type 99 lookups. Nameserver vendors incorporated SPF support faster than the SPF propronent. Then it required MTA vendors/package maintainers to use the new code. There wasn't even one hardware replacement cycle allowed for. It takes OS vendors years to integrate new nameserver code into their releases. TXT to SPF transition was never going to be quick. It has/had a timescale similar to A to MX only domain adoption. As far as I could see the transition was roughly where I exected it to be. If the SPF working group had wanted a faster transition they should have set development milestones and requested that nameservers vendors log missing type 99 records etc. Changing things in the DNS takes a lot of time. This is something DNS developers know and accept. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From doug.mtview@gmail.com Thu May 30 09:16:49 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22A221F93A5 for ; Thu, 30 May 2013 09:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyUIx9d+aV21 for ; Thu, 30 May 2013 09:16:49 -0700 (PDT) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E54C721F8FA3 for ; Thu, 30 May 2013 09:16:26 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id f15so541035eak.15 for ; Thu, 30 May 2013 09:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=hUsVTQX9T5qSvFSPGWn7H7UlqPH58zwlU0fOt0hEbgg=; b=ppxd2m6OCI0HhTK+zPaFhq+dWZFAN82CuUILy1eaG3q2HOqNCXvyt9WKi6dB3I8i8n IZ8OeJ8dB608DJqxtG8A7pBmsoKw/TpTND6YDqFxq5JFrnfmXAhipcXdt/BbITgSVc36 zqnc2Ruo3QE4b8iVEuwS28/t1YHZfJvj0S95TOihoH3qX9lNZxcpFPWtO+0EYm4cWrGs Z9wsyo/D0Pm2RW+kSMx+WK8jYXkQ8FaK6Gys7JBS7j4pJHz7uv/NuzkOH68yivma7bdf xRp75Zd7+UGZ5l92LR+xxvjAqPwf8whAl+3ZDnDo+Af/VWqf92ogX+AXVV0IFF7xcTRF Tqsw== X-Received: by 10.14.209.135 with SMTP id s7mr10410647eeo.57.1369930578119; Thu, 30 May 2013 09:16:18 -0700 (PDT) Received: from ?IPv6:2601:9:3180:3e:4005:6271:8a70:55e1? ([2601:9:3180:3e:4005:6271:8a70:55e1]) by mx.google.com with ESMTPSA id a5sm61315266ees.6.2013.05.30.09.16.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 09:16:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Douglas Otis In-Reply-To: <20130529214234.GB9584@mx1.yitter.info> Date: Thu, 30 May 2013 09:16:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3478D7CC-4617-4D80-805F-EBE8A26D2BBF@gmail.com> References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> <20130529143635.GZ23227@verdi> <20130529202145.GA9506@mx1.yitter.info> <20130529212602.5909734DBABF@drugs.dv.isc.org> <20130529214234.GB9584@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1503) Cc: spfbis@ietf.org Subject: Re: [spfbis] The RRTYPE topic (was: WGLC: draft-ietf-spfbis-4408bis-14) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:16:49 -0000 On May 29, 2013, at 2:42 PM, Andrew Sullivan = wrote: > Moderator hat. >=20 > Mark, >=20 > On Thu, May 30, 2013 at 07:26:01AM +1000, Mark Andrews wrote: >>=20 >> In message <20130529202145.GA9506@mx1.yitter.info>, Andrew Sullivan = writes: >>> The only reason we decided that we had to do something with TYPE 99 >=20 >> And what has been done does NOT fix the perceived interoperability >=20 > If you're going to start a completely irrelevant thread to the thing > we are talking about, do you think you might at least change the > subject line? Dear Mr. Sullivan, Reviewing past decisions within a thread labeled WGLC... seems most = appropriate. Regards, Douglas Otis From SRS0=7TApp=PP==stuart@gathman.org Thu May 30 09:55:39 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB2921F8AF7 for ; Thu, 30 May 2013 09:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRU-BJG33jrn for ; Thu, 30 May 2013 09:55:39 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id C74F821F89C3 for ; Thu, 30 May 2013 09:55:38 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (PLAIN sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1369932968; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=aA9eYFcU8xKC/sW9bwoW7HhXg+eB5y76CmcuxL2ZcVk=; b=Ani2opUbwNupf8o7QQWJXjS9xdCN/IgGQp8Pd1mNhT6g+uAsoqdLviAM0FfKQijkRWNr1f l9WCwSnvSf6niwV00AmsMXXe8f8pSU4mFUzle3oYlc1vc1IrK25OflzoqfxjStAfElWjnWzV LqXw4yjZSms7CX0SmAH9Y7DCQ/FVg= Received: from sdg.bmsi.com ([IPv6:2001:470:8:488:ac33:8e64:343:987d]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r4UGtxQ1016995 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 30 May 2013 12:56:08 -0400 Message-ID: <51A7847B.1090303@gathman.org> Date: Thu, 30 May 2013 12:54:58 -0400 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> <20130529143635.GZ23227@verdi> <20130529202145.GA9506@mx1.yitter.info> <20130529212602.5909734DBABF@drugs.dv.isc.org> <20130529214234.GB9584@mx1.yitter.info> <20130529220822.2326134DBF6E@drugs.dv.isc.org> <20130530003906.6983934DF471@drugs.dv.isc.org> <20130530064341.9F7DE34EC657@drugs.dv.isc.org> In-Reply-To: <20130530064341.9F7DE34EC657@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] The RRTYPE topic X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 17:14:03 -0000 On 05/30/2013 02:43 AM, Mark Andrews expounded in part: > In message > , "Murray S. Kucherawy" writes: >> On Wed, May 29, 2013 at 5:39 PM, Mark Andrews wrote: >> >>> As for numbers the survey was taken *very* early in a transition >>> from TXT to SPF. SPF record have doubled as a percentage since the >>> initial survey was taken. >>> >>> >> RFC4408 was published in 2006, and SPF had been in extra-IETF development >> for a while before that. RFC6686 was published less than a year ago. I >> don't see how you can characterize that as "early". > In a project that I would expect to take 15+ years years to complete > yes it was early. For a project where the SPF propronent took until > 2008 to issue new library code that made type 99 lookups. Nameserver > vendors incorporated SPF support faster than the SPF propronent. > Then it required MTA vendors/package maintainers to use the new > code. There wasn't even one hardware replacement cycle allowed > for. It takes OS vendors years to integrate new nameserver code > into their releases. > > TXT to SPF transition was never going to be quick. It has/had a > timescale similar to A to MX only domain adoption. As far as I > could see the transition was roughly where I exected it to be. If > the SPF working group had wanted a faster transition they should > have set development milestones and requested that nameservers > vendors log missing type 99 records etc. > > Changing things in the DNS takes a lot of time. This is something > DNS developers know and accept. +1 4408bis makes a provision to endorse caching negative and error results for up to 24 hours. *That* (not throwing away the SPF record) is the solution to the broken nameserver problem. When you query SPF, and the request times out due to broken firewalls, broken nameserver, or whatever, then cache the result. If anything, it is time to remove the dual publishing (both TXT and SPF), and the administration/consistency problems that causes. From spf2@kitterman.com Thu May 30 10:21:10 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB4421F9602 for ; Thu, 30 May 2013 10:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0e8ovi2k82x for ; Thu, 30 May 2013 10:21:05 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id AC28521F9603 for ; Thu, 30 May 2013 10:21:04 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id B567ED0407D; Thu, 30 May 2013 12:21:03 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369934463; bh=VNWmErLQcy1VKTHKEiAJ+48DK+2aydaWznplktkDuyU=; h=In-Reply-To:References:Subject:From:Date:To:From; b=Os9FYWbYl/pcduh+CPGUAxH/CD84e6YBKIXs46/bdaIH3ftDzrmkUIAzVV3t300dZ 5SO/IPmh+5ecXnIrena11QkpTT2yT9rVyV9ZZ4EmAW0SwrNpdwV3IL3vFnlpe1odgm nhMBt2NMTl5SQW5q053zcgiCNlrgY3f0z1N0jjyw= Received: from [192.168.111.101] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 7278BD04051; Thu, 30 May 2013 12:21:03 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <51A7847B.1090303@gathman.org> References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> <20130529143635.GZ23227@verdi> <20130529202145.GA9506@mx1.yitter.info> <20130529212602.5909734DBABF@drugs.dv.isc.org> <20130529214234.GB9584@mx1.yitter.info> <20130529220822.2326134DBF6E@drugs.dv.isc.org> <20130530003906.6983934DF471@drugs.dv.isc.org> <20130530064341.9F7DE34EC657@drugs.dv.isc.org> <51A7847B.1090303@gathman.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 30 May 2013 13:21:02 -0400 To: spfbis@ietf.org Message-ID: <15249245-ac39-483f-93e6-c0b274c69ed2@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] The RRTYPE topic X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 17:21:10 -0000 Stuart D Gathman wrote: >On 05/30/2013 02:43 AM, Mark Andrews expounded in part: >> In message > >> , "Murray S. Kucherawy" writes: >>> On Wed, May 29, 2013 at 5:39 PM, Mark Andrews wrote: >>> >>>> As for numbers the survey was taken *very* early in a transition >>>> from TXT to SPF. SPF record have doubled as a percentage since the >>>> initial survey was taken. >>>> >>>> >>> RFC4408 was published in 2006, and SPF had been in extra-IETF >development >>> for a while before that. RFC6686 was published less than a year >ago. I >>> don't see how you can characterize that as "early". >> In a project that I would expect to take 15+ years years to complete >> yes it was early. For a project where the SPF propronent took until >> 2008 to issue new library code that made type 99 lookups. Nameserver >> vendors incorporated SPF support faster than the SPF propronent. >> Then it required MTA vendors/package maintainers to use the new >> code. There wasn't even one hardware replacement cycle allowed >> for. It takes OS vendors years to integrate new nameserver code >> into their releases. >> >> TXT to SPF transition was never going to be quick. It has/had a >> timescale similar to A to MX only domain adoption. As far as I >> could see the transition was roughly where I exected it to be. If >> the SPF working group had wanted a faster transition they should >> have set development milestones and requested that nameservers >> vendors log missing type 99 records etc. >> >> Changing things in the DNS takes a lot of time. This is something >> DNS developers know and accept. >+1 > >4408bis makes a provision to endorse caching negative and error results > >for up to 24 hours. *That* (not throwing away the SPF record) is the >solution to the broken nameserver problem. When you query SPF, and the > >request times out due to broken firewalls, broken nameserver, or >whatever, then cache the result. Took out what I think you're referring to due to negative WGLC comments. See -15. >If anything, it is time to remove the dual publishing (both TXT and >SPF), and the administration/consistency problems that causes. The current draft does that. Scott K From hallam@gmail.com Thu May 30 13:00:44 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285F721F9273; Thu, 30 May 2013 13:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fOgwDXBvjwQ; Thu, 30 May 2013 13:00:43 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9026221F9354; Thu, 30 May 2013 13:00:41 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id hn14so56458wib.14 for ; Thu, 30 May 2013 13:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aSF2ZcxNSEk8B6AEsM9NOfE/qPv9AH94fljFEeidwSM=; b=eFyS0wE3TXYdzhybVIdyJTK3obyfpIlfzY1H/xW0VDFlMinWb/rXl+GqXoMgj2TSou wurHhlMuOdz1S9JR9wG3S1GzS8upOieJymwNLBfsDfNegG/7CFU/9EUOiSQ1Umw2U8VW dNCPCwqnxaeFzIn+MbmMONj24rrZ0iUQakWkxERUci8ZWdmKy+k81e4k/9ThCW48wcJ1 JH9QkhRfHVWqKy0EbhsSlBpouDOfUrzNbtRkqblvqi2gPQoInMot26BfeiBv6fKDgCpy zIBCHM5e85zG//nzH+im/syuwyyplAC5UXO4vTqE8zCWGRv5Gtyl1VkgC3VBSZ4INNhv C76w== MIME-Version: 1.0 X-Received: by 10.194.172.66 with SMTP id ba2mr6394781wjc.22.1369944040627; Thu, 30 May 2013 13:00:40 -0700 (PDT) Received: by 10.194.44.100 with HTTP; Thu, 30 May 2013 13:00:40 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130523120130.0de4f6e0@elandnews.com> References: <6.2.5.6.2.20130523095247.0dc5a520@elandnews.com> <7E10E46C-D524-41F2-9546-09DC7E3426A1@gmail.com> <6.2.5.6.2.20130523120130.0de4f6e0@elandnews.com> Date: Thu, 30 May 2013 16:00:40 -0400 Message-ID: From: Phillip Hallam-Baker To: S Moonesamy Content-Type: multipart/alternative; boundary=089e01184dd4e766c804ddf4f3c1 X-Mailman-Approved-At: Thu, 30 May 2013 13:03:21 -0700 Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, "secdir@ietf.org" , Douglas Otis , "iesg@ietf.org" Subject: Re: [spfbis] draft-ietf-spfbis-4408bis-14 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 20:00:44 -0000 --089e01184dd4e766c804ddf4f3c1 Content-Type: text/plain; charset=ISO-8859-1 My point was a quibble, no more. The intent was clear enough to me and it is hard to imagine an implementer of code making a blunder if their code is timing out too often on real records they will raise their limits. A person writing records might however. I can see that attempting to clarify this point might add more confusion as John Levine pointed out. In fact that was the main concern I had with the document as a whole. I think it is done as well as it is going to be at this point. On Thu, May 23, 2013 at 3:14 PM, S Moonesamy wrote: > Hi Doug, > > At 11:58 23-05-2013, Douglas Otis wrote: > >> Greater clarity would have been achieved by separating transactions >> involving the SPF checkhost process (spfch-transactions) which may then >> generate some number of recursive dns server transactions >> (rdns-transactions). >> >> A transaction made at the spfch level will result in some number of >> transactions at the rdns level, which could then be described as >> representing some number of separate DNS queries. >> >> Confusion has been caused by conflating checkhost and recursive DNS >> transactions with that of non-recursive DNS which may involve dozens of >> unique queries to resolve any particular resource. This is bad and is a >> continuing source of confusion. >> > > What I noted among other things in the review was "the only quibble" and > "it is reasonably clear". > > > A practical means to simplify SPF's impact on a receiver's DNS is to >> first ignore SPF records containing macro expressions. This happens and >> this may explain the nearly 100% lack of macro use. They then limit the >> number of SPF resource records and MX mechanisms and ignore the PTR >> mechanism. Appreciate what receivers consider a reasonable demand on their >> resources that offers cache-able results. >> > > I don't see any relation between the security directorate review ( > http://www.ietf.org/mail-**archive/web/spfbis/current/**msg03679.html) to the above (quoted paragraph). If the security directorate reviewer is > of the opinion that it is related to his review I will ask the SPFBIS to > comment about the matter. > > > Regards, > S. Moonesamy (as document shepherd) > -- Website: http://hallambaker.com/ --089e01184dd4e766c804ddf4f3c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My point was a quibble, no more. The intent was clear enou= gh to me and it is hard to imagine an implementer of code making a blunder = if their code is timing out too often on real records they will raise their= limits. A person writing records might however.

I can see that attempting to clarify this point might = add more confusion as John Levine pointed out. In fact that was the main co= ncern I had with the document as a whole. I think it is done as well as it = is going to be at this point.


On Thu,= May 23, 2013 at 3:14 PM, S Moonesamy <sm+ietf@elandsys.com> wrote:
Hi Doug,

At 11:58 23-05-2013, Douglas Otis wrote:
Greater clarity would have been achieved by separating transactions involvi= ng the SPF checkhost process (spfch-transactions) which may then generate s= ome number of recursive dns server transactions (rdns-transactions).

A transaction made at the spfch level will result in some number of transac= tions at the rdns level, which could then be described as representing some= number of separate DNS queries.

Confusion has been caused by conflating checkhost and recursive DNS transac= tions with that of non-recursive DNS which may involve dozens of unique que= ries to resolve any particular resource. =A0This is bad and is a continuing= source of confusion.

What I noted among other things in the review was "the only quibble&qu= ot; and "it is reasonably clear".


A practical means to simplify SPF's impact on a receiver's DNS is t= o first ignore SPF records containing macro expressions. =A0This happens an= d this may explain the nearly 100% lack of macro use. =A0They then limit th= e number of SPF resource records and MX mechanisms and ignore the PTR mecha= nism. =A0Appreciate what receivers consider a reasonable demand on their re= sources that offers cache-able results.

I don't see any relation between the security directorate review ( http://www.ietf.org/mail-archive/web/spfbis/current= /msg03679.html ) to the above (quoted paragraph). =A0If the secu= rity directorate reviewer is of the opinion that it is related to his revie= w I will ask the SPFBIS to comment about the matter.


Regards,
S. Moonesamy (as document shepherd)



--
= Website: http://hallambaker.com/
--089e01184dd4e766c804ddf4f3c1-- From SRS0=NDU8O=PR==stuart@gathman.org Fri May 31 21:49:53 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D42F21F86C0 for ; Fri, 31 May 2013 21:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KO+ghI9zUeuH for ; Fri, 31 May 2013 21:49:53 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id DCE3D21F8657 for ; Fri, 31 May 2013 21:49:49 -0700 (PDT) Authentication-Results: mail.gathman.org; auth=pass (CRAM-MD5 sslbits=256) smtp.auth=stuart DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org; i=@gathman.org; q=dns/txt; s=default; t=1370062219; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=yHO9YCL/6tNq3xLCC4AgnCFICTrExUJk9V7+1NJy72A=; b=Iwp/ME5LCeqB0av69qysBKuPIu7DBNdAA+HdIzuTiYEcBsXDHtS9KKArwI8V9nBduhQxzf 9JAIb4U82d1agFpuWRbTMbnkYM/iV8QsPmWhzaNYkH1AOlyEFQcAn8ul5kQ+LMsL5kvpPzDY nRS62gly/BIsWRGiDRlGGsvlzelGU= Received: from melissa.gathman.org (ip72-205-26-231.dc.dc.cox.net [72.205.26.231]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r514oJeP022410 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 1 Jun 2013 00:50:19 -0400 Message-ID: <51A97D69.9040606@gathman.org> Date: Sat, 01 Jun 2013 00:49:45 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20130528130858.0db81cd0@resistor.net> <20130529143635.GZ23227@verdi> <20130529202145.GA9506@mx1.yitter.info> <20130529212602.5909734DBABF@drugs.dv.isc.org> <20130529214234.GB9584@mx1.yitter.info> <20130529220822.2326134DBF6E@drugs.dv.isc.org> <20130530003906.6983934DF471@drugs.dv.isc.org> <20130530064341.9F7DE34EC657@drugs.dv.isc.org> <51A7847B.1090303@gathman.org> <15249245-ac39-483f-93e6-c0b274c69ed2@email.android.com> In-Reply-To: <15249245-ac39-483f-93e6-c0b274c69ed2@email.android.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] The RRTYPE topic X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 04:54:20 -0000 Long ago, Nostradamus foresaw that on 05/30/2013 01:21 PM, Scott Kitterman would write: > > Stuart D Gathman wrote: > >> +1 >> >> 4408bis makes a provision to endorse caching negative and error results >> >> for up to 24 hours. *That* (not throwing away the SPF record) is the >> solution to the broken nameserver problem. When you query SPF, and the >> >> request times out due to broken firewalls, broken nameserver, or >> whatever, then cache the result. > Took out what I think you're referring to due to negative WGLC comments. See -15. > >> If anything, it is time to remove the dual publishing (both TXT and >> SPF), and the administration/consistency problems that causes. > The current draft does that. > It says MUST publish TXT - so if you publish SPF you must publish both. It could allow caching negative results for type SPF queries only. From spf2@kitterman.com Fri May 31 21:55:56 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215A121F8E6E for ; Fri, 31 May 2013 21:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+M3CXv1XfJw for ; Fri, 31 May 2013 21:55:51 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0B17821F89A6 for ; Fri, 31 May 2013 21:55:50 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B224C20E40CF; Sat, 1 Jun 2013 00:55:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1370062549; bh=OwejzjadMQHsj/svGhlyvSNiSx3eJIS8UxZHXGTbj28=; h=From:To:Subject:Date:In-Reply-To:References:From; b=c9sb59fuX9b1e+AbXiBW812tIWwPefXG4PlEUJ2QBopdsP8NaxjAja1uqhQMoJvYB I0ZqhVwWKCwm9fiOA9Elm8k/ipcwOabJK29lBZ7+l4p78uShx2GuVPvE1TDM1b3ST8 YKvf0jtP/JInLYgNJ6ka3CvXWtfJhmSRGf9TZc50= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9465720E40BE; Sat, 1 Jun 2013 00:55:49 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 01 Jun 2013 00:55:48 -0400 Message-ID: <2100860.3TqLYcDuTr@scott-latitude-e6320> User-Agent: KMail/4.10.3 (Linux/3.8.0-23-generic; KDE/4.10.3; i686; ; ) In-Reply-To: <51A97D69.9040606@gathman.org> References: <15249245-ac39-483f-93e6-c0b274c69ed2@email.android.com> <51A97D69.9040606@gathman.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] The RRTYPE topic X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 04:55:56 -0000 On Saturday, June 01, 2013 12:49:45 AM Stuart Gathman wrote: > Long ago, Nostradamus foresaw that on 05/30/2013 01:21 PM, Scott > > Kitterman would write: > > Stuart D Gathman wrote: > >> +1 > >> > >> 4408bis makes a provision to endorse caching negative and error results > >> > >> for up to 24 hours. *That* (not throwing away the SPF record) is the > >> solution to the broken nameserver problem. When you query SPF, and the > >> > >> request times out due to broken firewalls, broken nameserver, or > >> whatever, then cache the result. > > > > Took out what I think you're referring to due to negative WGLC comments. > > See -15.> > >> If anything, it is time to remove the dual publishing (both TXT and > >> SPF), and the administration/consistency problems that causes. > > > > The current draft does that. > > It says MUST publish TXT - so if you publish SPF you must publish both. > > It could allow caching negative results for type SPF queries only. Since the current draft removes type SPF, there's no dual publishing needed. Scott K