From sm@elandsys.com Tue Sep 3 14:57: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 E75F921E8064; Tue, 3 Sep 2013 14:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 NsLI+JfAK9Ig; Tue, 3 Sep 2013 14:57: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 D36A921F9AE7; Tue, 3 Sep 2013 14:57:02 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.136.208]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r83LumQi008514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Sep 2013 14:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378245421; bh=9P5BeAornxeU1bcicdH83vuZkr8qlaIOqOVW+Q6liwg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kH/uhEVpfQd8AGmmeruGb/LhcAw4Ew+gVg7Bmq0Yig9as1F3fEHpmAMuWwZB1yJwu PbIMG7YEX4npgPYaUqFV7s+5Y2q2LRSluWk0BxgnL7nhpFz5htDfVJaqUYtg9F4h9D +d7zRkRP26m3pC/ZL9jSzxS8UtjGMjpQAxqcCs/Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378245421; i=@elandsys.com; bh=9P5BeAornxeU1bcicdH83vuZkr8qlaIOqOVW+Q6liwg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JixQO3v8ScO+lOFOsIC1yQWwXF/BSGF8u2M7lgjahFJBnf5U4LWCMmrgjPw3MII6b mccxtjUvsSEKhVGv1EZ4pnbLr8MNF+w1BQHVqbIlibPDyQmZWkW76kxK99jeJEiJ1Y 8dfUbpa7Od8wosonhvkjwyhBqsgW16VnToccr5sg= Message-Id: <6.2.5.6.2.20130903140642.0b5b1b00@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 03 Sep 2013 14:56:14 -0700 To: ietf@ietf.org From: S Moonesamy In-Reply-To: References: <20130902134703.19714.qmail@joyce.lan> <9A45A400-0378-4C36-BB3A-91BADA8A1C81@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org, Dan Schlitt Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 03 Sep 2013 21:57:04 -0000 Hello, This is a rough summary of the comments which=20 have been made on the Last Call for=20 draft-ietf-spfbis-4408bis-19 since I emailed Pete Resnick [1]. There were comments about the RFC 5507 concerns=20 from Patrik F=E4ltstr=F6m [2], Dave Crocker [3], Mark=20 Andrews [4] and John Klensin [5]. There were comments from Dan Schlitt [6] in which=20 he provided his perspective of the SPFBIS=20 discussions. In his opinion "it is unwise to=20 have a standards track protocol which overloads=20 the TXT record". He suggested that the=20 specification should be published as=20 Informational. The comments provided by Dave=20 Crocker [3] [7] and John Klensin [5][8] may also=20 be related to the intended status of the=20 specification. Phillip Hallam-Baker commented about the design objections= [9]. I'll ask the Responsible Area Director for=20 guidance about the above instead of suggesting that the SPFBIS WG address= them. Joe Abley commented about the usage of "messages=20 sent over UDP" [10]. This issue has been raised=20 by Douglas Otis. My suggestion to the SPFBIS WG is to address this issue. Please email me if you consider your comments as=20 not having been addressed correctly. I suggest=20 waiting for Pete Resnicks to send a message to=20 the mailing list if you sent Last Call comments before August 24. Regards, S. Moonesamy (as document shepherd) 1. http://www.ietf.org/mail-archive/web/ietf/current/msg81877.html 2. http://www.ietf.org/mail-archive/web/ietf/current/msg81887.html 3. http://www.ietf.org/mail-archive/web/ietf/current/msg81889.html 4. http://www.ietf.org/mail-archive/web/ietf/current/msg81891.html 5. http://www.ietf.org/mail-archive/web/ietf/current/msg81912.html 6. http://www.ietf.org/mail-archive/web/ietf/current/msg81939.html 7. http://www.ietf.org/mail-archive/web/ietf/current/msg81923.html 8. http://www.ietf.org/mail-archive/web/ietf/current/msg81924.html 9. http://www.ietf.org/mail-archive/web/ietf/current/msg81927.html 10. http://www.ietf.org/mail-archive/web/ietf/current/msg81862.html From presnick@qti.qualcomm.com Sat Sep 7 06:31: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 51E8021F9AD8; Sat, 7 Sep 2013 06:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 xBm6NpcBaOvh; Sat, 7 Sep 2013 06:31:53 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id EC55221F9611; Sat, 7 Sep 2013 06:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1378560713; x=1410096713; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=2kPtsNZltNFcEWB2Ae/4cymGs6tCJAwlTSpfC3Bf7LU=; b=EIz/LUHDH+ICCZX2nuzBJC7U2V5Fy1MQpkvdY0T1S0bDdXULnhQnbtZe CQUQE1VC6d/FSIzogYRimBjijOSe/4FxWi9NLr5iDU4xsOCFGZR0+nivJ iil1f5ZNSdi+3cMx3TC0qSx+rMQw3Kddpl3iUUcjcIpIGhABbUOd9jjG7 0=; X-IronPort-AV: E=McAfee;i="5400,1158,7190"; a="51135071" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 07 Sep 2013 06:31:52 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7190"; a="18998576" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Sep 2013 06:31:52 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.146.2; Sat, 7 Sep 2013 06:31:51 -0700 Message-ID: <522B2AC4.4090006@qti.qualcomm.com> Date: Sat, 7 Sep 2013 08:31:48 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: IETF-Discussion list Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: "spfbis@ietf.org" Subject: [spfbis] Conclusions of Last Call for draft-ietf-spfbis-4408bis 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, 07 Sep 2013 13:31:57 -0000 Below is the list of issues brought up during Last Call of draft-ietf-spfbis-4408bis. I have tried to collect together the common issues and tease out the ones that are slightly different. Below each issue, I've given what I take to be the answer to the issue (either the change that needs to be made, or the explanation of why no change is necessary). I've not put names to the objections or the answers, simply because multiple people gave different versions of the same objections or the same answers, and sorting that out seemed useless. Issues: 1. Overloading of the TXT RR for this use is bad. - As far as I can tell, there is nobody that disagrees with this statement. However, it is also not in-and-of-itself an objection to the document: Nobody seems to have argued that this document should forbid use of the TXT RR completely in SPF. The only question is whether the document should provide a transition mechanism to the SPF RR or whether it is reasonable to go forward with this protocol using only the TXT RR. There is the "precedent"objection I will discuss in 2 below, but the specific technical objections seem mostly *not* to be about forbidding TXT RR use from the get-go. Some of the specific objections could be taken as arguments against the document going forward if it has no transition mechanism, but I believe all of those have either been addressed or can be addressed with clarifying language in the document: - The only complete solution to many of the problems that fall under this category is if *all* misuse of TXT RR went away. There has been no convincing argument put forward that this is plausible in the foreseeable future. 1a. TXT RR can cause large RDATA. - In theory, that's certainly true. But I have not seen an argument that SPF is causing a major problem to date, nor that there is an expectation that it will in the future. - There were some suggested text clarifications for section 3.4 to make it clear which size limitations relate to DNS response size, UDP payload size, or MTU size. They seem reasonable and were not objected to. I'll work with the editor and others to clarify that text. 1b. Use of TXT RR can cause collisions with other applications. - Again, there is no indication that this has caused a problem for SPF (or others) to date, and SPF requires rejection of TXT RR data that does not conform to the spec, so I see no evidence of the existing harm, nor of a solid reason to believe there will be future harm. (Again, I'm leaving aside the "precedent" arguments until 2.) - There appears to be an effort underway to document (via an IANA registry) such uses to minimize the potential for these sorts of collision problems in the future. 1c. Use of TXT RR for multiple purposes makes it impossible to do access control based on type of data (i.e., to allow delegation of the management for TXT RRs that are solely for SPF use). - Many organizations have been managing these records already; no reasoning was given that this fine-grained management is necessary. - Delegation is possible by pointing a TXT RR of (e.g.) example.com to _spf.example.com, delegating the latter. - All of the above was discussed extensively in the WG and taken into consideration. Given the charter limitations, a reasonable choice was made. 2. Use of the TXT RR sets a bad precedent for future use. - Several people responded that some additional text in 3.1 or elsewhere (either by way of some sort of applicability guidance or an overt IESG Statement) would address this issue. I think an IESG Statement is unnecessary since I have not heard significant objection to including some guidance, and I think something reasonable along these lines can be crafted. I'll work with the editor and others to get such text in the document. - The impediments that caused SPF to use TXT RR in the first place are mostly gone. New protocols are unlikely to face the same challenges. 3. Removing SPF RR support is a charter violation. - Because the original spec has a non-interoperable mechanism for use, this constituted an "error" in the spec that was to be corrected. 4. A new transition mechanism from TXT RR to SPF RR should be put into the spec. - This was extensively considered by the WG. - Backward compatibility would require support of TXT RR for the forseeable future anyway. - The proposed transition mechanisms have technical issues: Doubling request traffic (e.g., doing queries in parallel), introducing delays (e.g., querying SPF RR first and running into firewalls, etc). - This would be a new, unchartered requirement for the WG. - The widely held conclusion was that such a transition plan would not be undertaken by implementers. (See also 5.) 5. That there will be a lack of adoption of SPF RR was based on RFC 6686, which does not support the conclusion. 5a. There is some current use of the SPF RR; it will increase if we put in a new transition mechanism. - 6686 showed only minimal use, and reports of those in the industry shows the use dropping (i.e., the momentum is in the other direction). - Bigger sites are conservative and will not transition for fear of breaking current usage. - No solid case was made for why to believe that the transition would occur. 5b. Use of SPF RR is on the increase now. - Claims that use is increasing are only anecdotal, and disagree with the experience of those in the industry. 5c. Things may have changed since 6686. We should do more data collection. - There's no reason to believe that the small amounts of recently presented data are representative. - Nobody presented any basis to doubt the folks working in the industry. - There has been ample opportunity (and motivation) for folks outside of the WG to do more data collection; none has been presented. - It is an unreasonable burden to place on the WG at this point. There were a few smaller issues: 6. The term "SPF records" is confusing because it could refer to SPF RR. - Because the document no longer uses SPF RR, this shouldn't be a problem in practice. 7. Clarifications are needed regarding the number of lookups to do in 4.6.4. - This will be reviewed prior to publication. 8. There should be a limit on PTR lookups. - This was already considered by the WG and rejected. The only looming issue large issue is the architectural one: 9. Using TXT RR for this purpose violates the architecture of the DNS. I list this separately because this is not about the immediate technical implications (like objection 1) or a claim about precedence setting (like objection 2), but appears to be a claim that violating the architecture is in and of itself a reason to not put something on the standards track. The problem I have with this is, short of actual technical harm, I'm not sure how to judge this. Our processes judge whether standards should be adopted on the basis of interoperability, deployment, and solving a useful problem. We have many examples of protocols that violate architectural principles, but standardize them nonetheless. (We can all name our most hated.) We have found it more useful to document how to interoperate with protocols that may not be ideal but are widely deployed rather than reject them on principle. I can't see how to treat this protocol differently. [There were a number of "straw men": There were responses to objections that never got brought up during Last Call, and a number of followups to responses to objections where the response was not one offered. Examples of these included: - A response to the objection that we haven't let the Experiment run long enough. (Nobody ever argued that during Last Call.) - A followup denying the contention that there is limited server support for SPF RRs. (Nobody ever said that the reason to use TXT RR now was because of limited server support.) I have ignored these threads.] So, my conclusions in summary are: - The document needs to make a statement in the document clarifying why the SPF RR is no longer used in the spec and making it clear that no precedent should be created by this protocol's continued use of TXT RR. - A few clarifications are required in the text (size limitations, perhaps number of lookup limitations). - The remainder of the objections were fully considered and understood by the WG, and were addressed to a reasonable extent, and therefore that there is rough consensus to go forward with this document. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From doug.mtview@gmail.com Mon Sep 9 02:24: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 0B3B711E81A5; Mon, 9 Sep 2013 02:24:49 -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 xD-ddxz0jLw3; Mon, 9 Sep 2013 02:24:40 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 788F921E80A3; Mon, 9 Sep 2013 02:24:33 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fz6so6031670pac.17 for ; Mon, 09 Sep 2013 02:24:33 -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; bh=DEGCzasnOgXZ3vKR5M4BazY2k6w1W2vBUSKtEtLzwuI=; b=uvj9AJr3hYaLAglPeGm9GqB7wf0U7cgc8YhLP+ADoJJLuyjM8fNbtcLwuiGc47F7oA F/ii5DXLsCX/VkVxjn6Teb3YYQPrwHPp4b6nUXsQcTor5Tcf2Bn8qYIij4Rwpq0lxFYi hO+AdLFuugL7qhMgicmBYec3bSMiYXAkeJc6WboSQGetyqwib5ZgvEUiES5pyHKAK3Cy joj1JfySmwq+EtS4Rm41cK4u1U1SeWo7dfLlSRo/ss4zZ2js2gdRTWO+59C1LxPHgt8y q4dgsNSv1E1OIjB0gZeRuEVAWpKgy6Mvh+L+YW9qihR58wEdpV0ZaWhI66MchhJB3br5 iPCQ== X-Received: by 10.66.227.2 with SMTP id rw2mr2360873pac.131.1378718673087; Mon, 09 Sep 2013 02:24:33 -0700 (PDT) Received: from [192.168.2.201] (c-24-6-103-174.hsd1.ca.comcast.net. [24.6.103.174]) by mx.google.com with ESMTPSA id xn12sm16379106pac.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 02:24:31 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Douglas Otis In-Reply-To: <522B2AC4.4090006@qti.qualcomm.com> Date: Mon, 9 Sep 2013 02:24:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <738E7638-DB74-4C12-B15E-42DA98721475@gmail.com> References: <522B2AC4.4090006@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1508) Cc: "spfbis@ietf.org" , IETF-Discussion list Subject: Re: [spfbis] Conclusions of Last Call for draft-ietf-spfbis-4408bis 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, 09 Sep 2013 09:24:49 -0000 On Sep 7, 2013, at 6:31 AM, Pete Resnick = wrote: > Below is the list of issues brought up during Last Call of = draft-ietf-spfbis-4408bis. I have tried to collect together the common = issues and tease out the ones that are slightly different. Below each = issue, I've given what I take to be the answer to the issue (either the = change that needs to be made, or the explanation of why no change is = necessary). I've not put names to the objections or the answers, simply = because multiple people gave different versions of the same objections = or the same answers, and sorting that out seemed useless. >=20 > Issues: >=20 > 1. Overloading of the TXT RR for this use is bad. > - As far as I can tell, there is nobody that disagrees with this = statement. However, it is also not in-and-of-itself an objection to the = document: Nobody seems to have argued that this document should forbid = use of the TXT RR completely in SPF. The only question is whether the = document should provide a transition mechanism to the SPF RR or whether = it is reasonable to go forward with this protocol using only the TXT RR. = There is the "precedent"objection I will discuss in 2 below, but the = specific technical objections seem mostly *not* to be about forbidding = TXT RR use from the get-go. Some of the specific objections could be = taken as arguments against the document going forward if it has no = transition mechanism, but I believe all of those have either been = addressed or can be addressed with clarifying language in the document: > - The only complete solution to many of the problems that fall = under this category is if *all* misuse of TXT RR went away. There has = been no convincing argument put forward that this is plausible in the = foreseeable future. >=20 > 1a. TXT RR can cause large RDATA. > - In theory, that's certainly true. But I have not seen an = argument that SPF is causing a major problem to date, nor that there is = an expectation that it will in the future. > - There were some suggested text clarifications for section 3.4 = to make it clear which size limitations relate to DNS response size, UDP = payload size, or MTU size. They seem reasonable and were not objected = to. I'll work with the editor and others to clarify that text. >=20 > 1b. Use of TXT RR can cause collisions with other applications. > - Again, there is no indication that this has caused a problem = for SPF (or others) to date, and SPF requires rejection of TXT RR data = that does not conform to the spec, so I see no evidence of the existing = harm, nor of a solid reason to believe there will be future harm. = (Again, I'm leaving aside the "precedent" arguments until 2.) > - There appears to be an effort underway to document (via an = IANA registry) such uses to minimize the potential for these sorts of = collision problems in the future. >=20 > 1c. Use of TXT RR for multiple purposes makes it impossible to do = access control based on type of data (i.e., to allow delegation of the = management for TXT RRs that are solely for SPF use). > - Many organizations have been managing these records already; = no reasoning was given that this fine-grained management is necessary. > - Delegation is possible by pointing a TXT RR of (e.g.) = example.com to _spf.example.com, delegating the latter. >=20 > - All of the above was discussed extensively in the WG and taken = into consideration. Given the charter limitations, a reasonable choice = was made. >=20 > 2. Use of the TXT RR sets a bad precedent for future use. > - Several people responded that some additional text in 3.1 or = elsewhere (either by way of some sort of applicability guidance or an = overt IESG Statement) would address this issue. I think an IESG = Statement is unnecessary since I have not heard significant objection to = including some guidance, and I think something reasonable along these = lines can be crafted. I'll work with the editor and others to get such = text in the document. > - The impediments that caused SPF to use TXT RR in the first place = are mostly gone. New protocols are unlikely to face the same challenges. >=20 > 3. Removing SPF RR support is a charter violation. > - Because the original spec has a non-interoperable mechanism for = use, this constituted an "error" in the spec that was to be corrected. >=20 > 4. A new transition mechanism from TXT RR to SPF RR should be put into = the spec. > - This was extensively considered by the WG. > - Backward compatibility would require support of TXT RR for the = forseeable future anyway. > - The proposed transition mechanisms have technical issues: = Doubling request traffic (e.g., doing queries in parallel), introducing = delays (e.g., querying SPF RR first and running into firewalls, etc). > - This would be a new, unchartered requirement for the WG. > - The widely held conclusion was that such a transition plan would = not be undertaken by implementers. (See also 5.) >=20 > 5. That there will be a lack of adoption of SPF RR was based on RFC = 6686, which does not support the conclusion. >=20 > 5a. There is some current use of the SPF RR; it will increase if we = put in a new transition mechanism. > - 6686 showed only minimal use, and reports of those in the = industry shows the use dropping (i.e., the momentum is in the other = direction). > - Bigger sites are conservative and will not transition for = fear of breaking current usage. > - No solid case was made for why to believe that the transition = would occur. >=20 > 5b. Use of SPF RR is on the increase now. > - Claims that use is increasing are only anecdotal, and = disagree with the experience of those in the industry. >=20 > 5c. Things may have changed since 6686. We should do more data = collection. > - There's no reason to believe that the small amounts of = recently presented data are representative. > - Nobody presented any basis to doubt the folks working in the = industry. > - There has been ample opportunity (and motivation) for folks = outside of the WG to do more data collection; none has been presented. > - It is an unreasonable burden to place on the WG at this = point. >=20 > There were a few smaller issues: > 6. The term "SPF records" is confusing because it could refer to = SPF RR. > - Because the document no longer uses SPF RR, this shouldn't be = a problem in practice. > 7. Clarifications are needed regarding the number of lookups to do = in 4.6.4. > - This will be reviewed prior to publication. > 8. There should be a limit on PTR lookups. > - This was already considered by the WG and rejected. >=20 > The only looming issue large issue is the architectural one: >=20 > 9. Using TXT RR for this purpose violates the architecture of the DNS. >=20 > I list this separately because this is not about the immediate = technical implications (like objection 1) or a claim about precedence = setting (like objection 2), but appears to be a claim that violating the = architecture is in and of itself a reason to not put something on the = standards track. The problem I have with this is, short of actual = technical harm, I'm not sure how to judge this. Our processes judge = whether standards should be adopted on the basis of interoperability, = deployment, and solving a useful problem. We have many examples of = protocols that violate architectural principles, but standardize them = nonetheless. (We can all name our most hated.) We have found it more = useful to document how to interoperate with protocols that may not be = ideal but are widely deployed rather than reject them on principle. I = can't see how to treat this protocol differently. >=20 > [There were a number of "straw men": There were responses to = objections that never got brought up during Last Call, and a number of = followups to responses to objections where the response was not one = offered. Examples of these included: > - A response to the objection that we haven't let the Experiment = run long enough. (Nobody ever argued that during Last Call.) > - A followup denying the contention that there is limited server = support for SPF RRs. (Nobody ever said that the reason to use TXT RR now = was because of limited server support.) > I have ignored these threads.] >=20 > So, my conclusions in summary are: >=20 > - The document needs to make a statement in the document clarifying = why the SPF RR is no longer used in the spec and making it clear that no = precedent should be created by this protocol's continued use of TXT RR. >=20 > - A few clarifications are required in the text (size limitations, = perhaps number of lookup limitations). >=20 > - The remainder of the objections were fully considered and understood = by the WG, and were addressed to a reasonable extent, and therefore that = there is rough consensus to go forward with this document. Dear Pete, You missed two concerns raised in the last call: 10. As DNSSEC becomes more broadly used with email, SPF is likely to = introduce problems neither foreseen nor properly considered by the WG. = "Not a problem for SPF" does not mean SPF will not impose problems for = DNS which may include DNSSEC. It should be obvious which protocol SPF = or DNS should receive greater consideration The SPF protocol also = ignores the number of PTR Resource Records returned by a query made by a = recipient on behalf of unknown senders against various third-party = domains. These domains can be constructed and modulated by message = elements via macro expansion greatly increasing the reflected = amplification this protocol enables. The same issue could occur with a = series of otherwise innocent TXT resource records that the SPF protocol = also permits. This "feature" could prove highly problematic and = extremely difficult if not impossible to defend against. Even limits on = NX domains can be easily sidestepped by malefactors leveraging the = practice of using synthetic domains to track users without the use of = cookies. 11. The continued specification of SPF macros inhibits interchange. = Because it is common for SPF records not to produce a pass, this issue = is not likely to have been given adequate attention. When SPF macros = are not implemented by receivers for any number of very valid reasons, = such as ensuring effective caching of DNS, their required use can and = will lead to interchange issues. SPF may impose complex macro handling = over multiple DNS responses determined by a sequence of queries that can = not be directly handled by DNS itself. Even the operation of SPF macros = represents security concerns threatening the integrity of the associated = SMTP and DNS servers. Since the publication of SPF macros is well = below the level used to justify removal of the SPF RR record type, the = same consideration should have been given SPF macros. Use of SPF macros = also interferes with forensic efforts at handling interchange problems. = As such, it is not surprising to find extremely few domains publish SPF = records using macros and large providers not processing SPF macros. The lack of consideration given DNS by the SPF protocol offers = overwhelming justification not to consider this protocol suitable for = endorsing as a standard. Going from experimental to informational = should not represent any hardship, but would serve as a warning = protocols should pay attention to their impact on underlying = infrastructure. There are limits on making it easy to send messages = since the Internet is not suffering from a message scarcity. Regards, Douglas Otis From presnick@qti.qualcomm.com Mon Sep 9 07:38: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 5DA6321E81DA; Mon, 9 Sep 2013 07:38:46 -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 IDeRHnmdg99s; Mon, 9 Sep 2013 07:38:35 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id B18FB21E808E; Mon, 9 Sep 2013 07:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1378736875; x=1410272875; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=9rD0J86xoxlIQ3Hw/f3QDo6aDfhMih4VuZrStYoDftE=; b=fa5Th9TVX44CB5FDoBYQlliACNRAbaOCnEaj6rR1ht4BN7JNYNcbaeKA ANlHymrCDKZvgkvFK+QJhCagwf0jWF24aAf5XwMRWBZAtwvcDnt0e9r5B ElOSIc+f1uhVZAVbLzCUIgK9HTt4b0Aa8p4YScOwbafxmLerV5G5UlSEx 4=; X-IronPort-AV: E=McAfee;i="5400,1158,7192"; a="51111126" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 09 Sep 2013 07:27:54 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7192"; a="544716061" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Sep 2013 07:27:54 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.146.2; Mon, 9 Sep 2013 07:27:54 -0700 Message-ID: <522DDAE7.20708@qti.qualcomm.com> Date: Mon, 9 Sep 2013 09:27:51 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Douglas Otis References: <522B2AC4.4090006@qti.qualcomm.com> <738E7638-DB74-4C12-B15E-42DA98721475@gmail.com> In-Reply-To: <738E7638-DB74-4C12-B15E-42DA98721475@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: "spfbis@ietf.org" , IETF-Discussion list Subject: Re: [spfbis] Conclusions of Last Call for draft-ietf-spfbis-4408bis 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, 09 Sep 2013 14:38:46 -0000 On 9/9/13 4:24 AM, Douglas Otis wrote: > On Sep 7, 2013, at 6:31 AM, Pete Resnick wrote: > > >> Below is the list of issues brought up during Last Call of draft-ietf-spfbis-4408bis. >> [...] >> 7. Clarifications are needed regarding the number of lookups to do in 4.6.4. >> - This will be reviewed prior to publication. >> 8. There should be a limit on PTR lookups. >> - This was already considered by the WG and rejected. >> > You missed two concerns raised in the last call: > > 10. As DNSSEC becomes more broadly used with email, SPF is likely to introduce problems neither foreseen nor properly considered by the WG.[...] > > 11. The continued specification of SPF macros inhibits interchange.[...] > I took your issue 10 to be covered under 8, and your issue 11 to be covered under 7. If this is not the case, you will need to explain more clearly. I will contact you offline with regard to why your messages were not clear and what you can do to help if you still believe these issues are not covered. Please do not write back to the IETF or SPFBIS list on these topics until you read that email. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From sm@elandsys.com Mon Sep 9 12:08: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 E178521E80AF; Mon, 9 Sep 2013 12:08: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 al2SgqEuW+sY; Mon, 9 Sep 2013 12:08:10 -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 3835521E80AB; Mon, 9 Sep 2013 12:08:10 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.133.235]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r89J7r03026002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Sep 2013 12:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378753688; bh=kHWEhmTah06sINHOtsdaEzb/XdS2xRMN2KHQHrLCWkw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bODKHQERHQMyn3TgNJnPzmgMvlgvSH2fs29JuDJ+NFy2XLJv0EXpL9182myvLVQVY 9GTSElNkld6FI9q/PFyEFYhfVpTOFuuliF6Mdz4X1GQLqyto529R/Jm+rJSqBOCXuH TQLzASUZVQqM8iaSGXFFD3sCQNGPQyWEi2FNiHYo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378753688; i=@elandsys.com; bh=kHWEhmTah06sINHOtsdaEzb/XdS2xRMN2KHQHrLCWkw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VsM5ZyJzfygTMmjViw1q9kEQFzabM6li230EzfGreeufje+IHVt9mS4/T2Q5+CLci FDgl1ly93uSxcg8L4yXoePLc1S24bL5iu1vtxfMr8+51CnKIhPIU4NH7+MZJRHMOXU Z4qXhagq0mh6d8r3hT5sr+hSAMGBCPjPwb9xrtfE= Message-Id: <6.2.5.6.2.20130909120150.06633298@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 09 Sep 2013 12:07:23 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Pete Resnick , draft-ietf-spfbis-4408bis@tools.ietf.org, iesg@ietf.org Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 09 Sep 2013 19:08:11 -0000 Hi Scott, Could you please address the following DISCUSS and the COMMENT? Thanks, S. Moonesamy (as document shepherd) At 06:55 07-09-2013, Pete Resnick wrote: >Pete Resnick has entered the following ballot position for >draft-ietf-spfbis-4408bis-19: Discuss > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/ > > > >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >Holding my own DISCUSS: > >Text needs to be created (probably for section 3.1) to better describe >the reason this document settled on TXT RR only and therefore why no >precedent is set for future use of the TXT RR. > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Clarifications needed regarding size limitations in 3.4, and perhaps some >clarifications in 4.6.4. From superuser@gmail.com Tue Sep 10 04:40: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 49ED621F8994; Tue, 10 Sep 2013 04:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 hka+Y5Z0yYZh; Tue, 10 Sep 2013 04:40:15 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC5821E80DF; Tue, 10 Sep 2013 04:39:30 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hq15so541506wib.12 for ; Tue, 10 Sep 2013 04:39:16 -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=BpkBhdXQ6cnGWkIQxKWHe3ZXb+yV235JaQO3I0aa+Rs=; b=PWObGrHtrh1SRWHeqnL2HlqMkOUAI7vHIwthdOLDEnZ+ixvf69NTjrf3acB8gU0HZ5 X/gZ0lyyt3SUUVwc4yIB0xrG3FjshiQSZZ24hEhmpCsPTmwZzVFh3ip74B0XdExCYrmK 5fZCfcIsHTN9yNbsA0ZFyu6T6IRdCUrD0qoT1soO57YRfR8+iqdM42u+aZkqAFPZsla9 BB8LviOo9tv8SQNgXzpAtwHJpdN/w++LgEBFUFjI7hHRFds2u3ay99WsNC84marSvzP3 gUHL2f6OJ30ovmqhrPHEhtYYrC61hGs6xEhl0d0zi3HCjZHFkhhICD/L1jlRYr8i5D8f hXOg== MIME-Version: 1.0 X-Received: by 10.180.183.51 with SMTP id ej19mr12601419wic.60.1378813156389; Tue, 10 Sep 2013 04:39:16 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Tue, 10 Sep 2013 04:39:16 -0700 (PDT) In-Reply-To: <2C6B0D9B-7E1E-4CC3-AA41-935D65E79A3F@frobbit.se> References: <522B2AC4.4090006@qti.qualcomm.com> <2C6B0D9B-7E1E-4CC3-AA41-935D65E79A3F@frobbit.se> Date: Tue, 10 Sep 2013 04:39:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: multipart/alternative; boundary=001a11c2409e65f8b904e605f41f Cc: "spfbis@ietf.org" , Pete Resnick , IETF-Discussion list Subject: Re: [spfbis] Conclusions of Last Call for draft-ietf-spfbis-4408bis 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, 10 Sep 2013 11:40:16 -0000 --001a11c2409e65f8b904e605f41f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Patrik, On Tue, Sep 10, 2013 at 4:04 AM, Patrik F=E4ltstr=F6m wrot= e: > What we did look at was first of all every query for an MX resource > record. Then we look at +/-1 second from the timestamp of that MX query f= or > TXT and/or SPF record for the same owner. We draw the conclusion that if > there is a query for an MX record, and then either TXT or SPF (or both) > within the approximately same timespan, then they are related queries. > > I'm not sure that's a valid conclusion. Since MX is needed only for a sending system, a receiving system doing an SPF check of either type has no reason to query for MX. The exception to this might be a heuristic check to see if the domain in the MAIL FROM has MX or A published such that a reply appears to be possible, but I wouldn't expect a strong correlation in your data. -MSK --001a11c2409e65f8b904e605f41f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Patrik,

On Tue, Sep 10, 2013 at 4:04 AM, Patrik = F=E4ltstr=F6m <paf@frobbit.se> wrote:
What we did look at was first of all every q= uery for an MX resource record. Then we look at +/-1 second from the timest= amp of that MX query for TXT and/or SPF record for the same owner. We draw = the conclusion that if there is a query for an MX record, and then either T= XT or SPF (or both) within the approximately same timespan, then they are r= elated queries.


I'm not sure that's a valid co= nclusion.=A0 Since MX is needed only for a sending system, a receiving syst= em doing an SPF check of either type has no reason to query for MX.=A0 The = exception to this might be a heuristic check to see if the domain in the MA= IL FROM has MX or A published such that a reply appears to be possible, but= I wouldn't expect a strong correlation in your data.

-MSK

--001a11c2409e65f8b904e605f41f-- From spf2@kitterman.com Tue Sep 10 05:16: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 3FEB221E80EE for ; Tue, 10 Sep 2013 05:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, NORMAL_HTTP_TO_IP=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 Izl1cUN7O3P6 for ; Tue, 10 Sep 2013 05:16:05 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 403CF21E808F for ; Tue, 10 Sep 2013 05:16:05 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 20E2820E40D5; Tue, 10 Sep 2013 08:16:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1378815364; bh=opVXcEKU7V0fWbF4xzkazb90GcqltbuerbrDx+s4MRg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TXHJOmSf5VChKyInaHi4s5neNNs66j/Vf2h12s4OD2lJyrjxSnlJjrcR7NPc/zCvm lSGVvvxB/1omD7JPBhdecod56586xR+a82wW7nV/DIZCw1LmYFHI3O1QR1Xi27xogD cj3SO+lNJGw8A+vuwk5Em+eVPDX2GfbdeqqU7CK8= 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 E299520E40C7; Tue, 10 Sep 2013 08:16:03 -0400 (EDT) From: Scott Kitterman To: S Moonesamy , Pete Resnick , spfbis-chairs@tools.ietf.org, spfbis@ietf.org Date: Tue, 10 Sep 2013 08:16:03 -0400 Message-ID: <24624534.FuUVENZpXd@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130909120150.06633298@elandnews.com> References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130909120150.06633298@elandnews.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart15323002.Ipxd0vRHzP" Content-Transfer-Encoding: 7Bit X-AV-Checked: ClamAV using ClamSMTP Cc: draft-ietf-spfbis-4408bis@tools.ietf.org Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 10 Sep 2013 12:16:10 -0000 This is a multi-part message in MIME format. --nextPart15323002.Ipxd0vRHzP Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Monday, September 09, 2013 12:07:23 S Moonesamy wrote: > Hi Scott, > > Could you please address the following DISCUSS and the COMMENT? > > Thanks, > S. Moonesamy (as document shepherd) Yes. See text at the end for proposed changes. I'm proposing changes regarding 3.1 and 3.4. I did review 4.6.4 again and did not determine a better way to say it, so no changes are proposed there. I'm also attaching a full rfcdiff of the changes I have locally for the to be 20. Some predate IETF Last Call and some (the ABNF changes) are changes I recommend based on the LC discussion. Scott K > At 06:55 07-09-2013, Pete Resnick wrote: > >Pete Resnick has entered the following ballot position for > >draft-ietf-spfbis-4408bis-19: Discuss > > > >When responding, please keep the subject line intact and reply to all > >email addresses included in the To and CC lines. (Feel free to cut this > >introductory paragraph, however.) > > > > > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > >for more information about IESG DISCUSS and COMMENT positions. > > > > > >The document, along with other ballot positions, can be found here: > >http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/ > > > > > > > >---------------------------------------------------------------------- > >DISCUSS: > >---------------------------------------------------------------------- > > > >Holding my own DISCUSS: > > > >Text needs to be created (probably for section 3.1) to better describe > >the reason this document settled on TXT RR only and therefore why no > >precedent is set for future use of the TXT RR. > > > > > >---------------------------------------------------------------------- > >COMMENT: > >---------------------------------------------------------------------- > > > >Clarifications needed regarding size limitations in 3.4, and perhaps some > >clarifications in 4.6.4. 3.1. DNS Resource Records SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only. The character content of the record is encoded as [US-ASCII]. Use of alternative DNS RR types was supported in WAS < SPF's experimental phase, but has been discontinued. See Appendix A < of [RFC6686] for further information. PROPOSED > SPF's experimental phase, but has been discontinued. > > In 2003, when SPF was first being developed, the requirements for > assignment of a new DNS RR type were considerably more stringent than > they are now. Additionally, support for easy deployment of new DNS > RR types was not widely deployed in DNS servers and and provisioning > systems. As a result, at that time, there was no reasonable > alternative to using the TXT RR type for SPF records. > > In its review of [RFC4408] the SPFbis working group concluded that > its dual RR type transition model was fundamentally flawed since it > contained no common RR type that implementers were required to serve > and required to check. Many alternatives were considered to resolve > this issue, but ultimately the working group concluded that > significant migration to the SPF RR type in the forseable future and > that the best solution for resolving this interoperability issue was > to drop support for the SPF RR type from SPF version 1. See Appendix > A of [RFC6686] for further information. > > The circumstances surrounding SPF's initial deploymenta decade ago > are unique and very, very unlikely to be repeated. SPF's use of the > TXT RR type for structured data should in no way be taken as > precedent for future protocol designers. Things have changed. 3.4. Record Size The published SPF record for a given domain name SHOULD remain small enough that the results of a query for it will fit within 512 octets. This UDP limit is defined in [RFC1035] section 2.3.4, although it was raised by [RFC2671]. Staying below 512 octets ought to prevent older DNS implementations from failing over to TCP,and will work with UDP in the absence of EDNS0 [RFC6891] support. Since the answer size is dependent on many things outside the scope of this document, it is WAS < only possible to give this guideline: If the combined length of the < DNS name and the text of all the records of a given type is under 450 < octets, then DNS answers ought to fit in UDP packets. Records that < are too long to fit in a single UDP packet could be silently ignored < by SPF verifiers due to firewall and other issues that interfere with < the operation of DNS over TCP or using ENDS0. PROPOSED > only possible to give this guideline: If the size of the DNS message, > the combined length of the DNS name and the text of all the records > of a given type is under 450 octets, then DNS answers ought to fit in > UDP packets. Records that are too long to fit in a single UDP packet > could be silently ignored by SPF verifiers due to firewall and other > issues that interfere with the operation of DNS over TCP or using > ENDS0. Note that when computing the sizes for replies to queries of the TXT format, one has to take into account any other TXT records published at the domain name. Similarly, the sizes for replies to all queries related to SPF have to be evaluated to fit in a single 512 octet UDP WAS < packet. PROPOSED > packet (i.e. DNS message size limited to 450 octects). --nextPart15323002.Ipxd0vRHzP Content-Disposition: attachment; filename="draft-ietf-spfbis-4408bis-20-from-19.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="draft-ietf-spfbis-4408bis-20-from-19.diff.html" Diff: draft-ietf-spfbis-4408bis-19.txt - draft-ietf-spfbis-4408bis-20.txt
 draft-ietf-spfbis-4408bis-19.txt   draft-ietf-spfbis-4408bis-20.txt 
Network Working Group S. Kitterman Network Working Group S. Kitterman
Internet-Draft Kitterman Technical Services Internet-Draft Kitterman Technical Services
Obsoletes: 4408 (if approved) August 17, 2013 Obsoletes: 4408 (if approved) September 10, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: February 18, 2014 Expires: March 14, 2014
Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email,
Version 1 Version 1
draft-ietf-spfbis-4408bis-19 draft-ietf-spfbis-4408bis-20
Abstract Abstract
Email on the Internet can be forged in a number of ways. In Email on the Internet can be forged in a number of ways. In
particular, existing protocols place no restriction on what a sending 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 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 SMTP HELO/EHLO commands. This document describes version 1 of
the Sender Policy Framework (SPF) protocol, whereby ADministrative the Sender Policy Framework (SPF) protocol, whereby ADministrative
Management Domains (ADMDs) can explicitly authorize the hosts that Management Domains (ADMDs) can explicitly authorize the hosts that
are allowed to use its domain names, and a receiving host can check are allowed to use its domain names, and a receiving host can check
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 18, 2014. This Internet-Draft will expire on March 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 11, line 45 skipping to change at page 11, line 45
2.6.5. Softfail 2.6.5. Softfail
The ADMD has published a weak statement that the host is probably not The ADMD has published a weak statement that the host is probably not
authorized. It has not published a stronger, more definitive policy authorized. It has not published a stronger, more definitive policy
that results in a "fail". that results in a "fail".
2.6.6. Temperror 2.6.6. Temperror
A "temperror" result means the SPF verifier encountered a transient A "temperror" result means the SPF verifier encountered a transient
(generally DNS) error while performing the check. A later retry may (generally DNS) error while performing the check. A later retry may
succeed without further operator action. succeed without further DNS operator action.
2.6.7. Permerror 2.6.7. Permerror
A "permerror" result means the domain's published records could not A "permerror" result means the domain's published records could not
be correctly interpreted. This signals an error condition that be correctly interpreted. This signals an error condition that
definitely requires operator intervention to be resolved. definitely requires DNS operator intervention to be resolved.
3. SPF Records 3. SPF Records
An SPF record is a DNS record that declares which hosts are, and are 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" not, authorized to use a domain name for the "HELO" and "MAIL FROM"
identities. Loosely, the record partitions hosts into permitted and identities. Loosely, the record partitions hosts into permitted and
not-permitted sets (though some hosts might fall into neither not-permitted sets (though some hosts might fall into neither
category). category).
The SPF record is expressed as a single string of text found in the The SPF record is expressed as a single string of text found in the
skipping to change at page 12, line 49 skipping to change at page 12, line 49
ADMDs publishing SPF records ought to keep the amount of DNS ADMDs publishing SPF records ought to keep the amount of DNS
information needed to evaluate a record to a minimum. Section 4.6.4 information needed to evaluate a record to a minimum. Section 4.6.4
and Section 10.1.1 provide some suggestions about "include" and Section 10.1.1 provide some suggestions about "include"
mechanisms and chained "redirect" modifiers. mechanisms and chained "redirect" modifiers.
3.1. DNS Resource Records 3.1. DNS Resource Records
SPF records MUST be published as a DNS TXT (type 16) Resource Record SPF records MUST be published as a DNS TXT (type 16) Resource Record
(RR) [RFC1035] only. The character content of the record is encoded (RR) [RFC1035] only. The character content of the record is encoded
as [US-ASCII]. Use of alternative DNS RR types was supported in as [US-ASCII]. Use of alternative DNS RR types was supported in
SPF's experimental phase, but has been discontinued. See Appendix A SPF's experimental phase, but has been discontinued.
of [RFC6686] for further information.
In 2003, when SPF was first being developed, the requirements for
assignment of a new DNS RR type were considerably more stringent than
they are now. Additionally, support for easy deployment of new DNS
RR types was not widely deployed in DNS servers and and provisioning
systems. As a result, at that time, there was no reasonable
alternative to using the TXT RR type for SPF records.
In its review of [RFC4408] the SPFbis working group concluded that
its dual RR type transition model was fundamentally flawed since it
contained no common RR type that implementers were required to serve
and required to check. Many alternatives were considered to resolve
this issue, but ultimately the working group concluded that
significant migration to the SPF RR type in the forseable future and
that the best solution for resolving this interoperability issue was
to drop support for the SPF RR type from SPF version 1. See Appendix
A of [RFC6686] for further information.
The circumstances surrounding SPF's initial deploymenta decade ago
are unique and very, very unlikely to be repeated. SPF's use of the
TXT RR type for structured data should in no way be taken as
precedent for future protocol designers. Things have changed.
3.2. Multiple DNS Records 3.2. Multiple DNS Records
A domain name MUST NOT have multiple records that would cause an A domain name MUST NOT have multiple records that would cause an
authorization check to select more than one record. See Section 4.5 authorization check to select more than one record. See Section 4.5
for the selection rules. for the selection rules.
3.3. Multiple Strings in a Single DNS record 3.3. Multiple Strings in a Single DNS record
As defined in [RFC1035] sections 3.3 and 3.3.14, a single text DNS As defined in [RFC1035] sections 3.3 and 3.3.14, a single text DNS
skipping to change at page 13, line 33 skipping to change at page 14, line 4
IN TXT "v=spf1 .... firstsecond string..." IN TXT "v=spf1 .... firstsecond string..."
TXT records containing multiple strings are useful in constructing TXT records containing multiple strings are useful in constructing
records that would exceed the 255-octet maximum length of a records that would exceed the 255-octet maximum length of a
character-string within a single TXT record. character-string within a single TXT record.
3.4. Record Size 3.4. Record Size
The published SPF record for a given domain name SHOULD remain small The published SPF record for a given domain name SHOULD remain small
enough that the results of a query for it will fit within 512 octets. enough that the results of a query for it will fit within 512 octets.
This UDP limit is defined in [RFC1035] section 2.3.4, although it was This UDP limit is defined in [RFC1035] section 2.3.4, although it was
raised by [RFC2671]. Staying below 512 octets ought to prevent older raised by [RFC2671]. Staying below 512 octets ought to prevent older
DNS implementations from failing over to TCP,and will work with UDP DNS implementations from failing over to TCP,and will work with UDP
in the absence of EDNS0 [RFC6891] support. Since the answer size is in the absence of EDNS0 [RFC6891] support. Since the answer size is
dependent on many things outside the scope of this document, it is dependent on many things outside the scope of this document, it is
only possible to give this guideline: If the combined length of the only possible to give this guideline: If the size of the DNS message,
DNS name and the text of all the records of a given type is under 450 the combined length of the DNS name and the text of all the records
octets, then DNS answers ought to fit in UDP packets. Records that of a given type is under 450 octets, then DNS answers ought to fit in
are too long to fit in a single UDP packet could be silently ignored UDP packets. Records that are too long to fit in a single UDP packet
by SPF verifiers due to firewall and other issues that interfere with could be silently ignored by SPF verifiers due to firewall and other
the operation of DNS over TCP or using ENDS0. issues that interfere with the operation of DNS over TCP or using
ENDS0.
Note that when computing the sizes for replies to queries of the TXT Note that when computing the sizes for replies to queries of the TXT
format, one has to take into account any other TXT records published format, one has to take into account any other TXT records published
at the domain name. Similarly, the sizes for replies to all queries at the domain name. Similarly, the sizes for replies to all queries
related to SPF have to be evaluated to fit in a single 512 octet UDP related to SPF have to be evaluated to fit in a single 512 octet UDP
packet. packet (i.e. DNS message size limited to 450 octects).
3.5. Wildcard Records 3.5. Wildcard Records
Use of wildcard records for publishing is discouraged and care has to Use of wildcard records for publishing is discouraged and care has to
be taken if they are used. If a zone includes wildcard MX records, be taken if they are used. If a zone includes wildcard MX records,
it might want to publish wildcard declarations, subject to the same it might want to publish wildcard declarations, subject to the same
requirements and problems. In particular, the declaration MUST be requirements and problems. In particular, the declaration MUST be
repeated for any host that has any RR records at all, and for repeated for any host that has any RR records at all, and for
subdomains thereof. Consider the example in [RFC1034], Section subdomains thereof. Consider the example in [RFC1034], Section
4.3.3. Based on that, we can do the following: 4.3.3. Based on that, we can do the following:
skipping to change at page 26, line 14 skipping to change at page 26, line 14
MUST support it. MUST support it.
5.6. "ip4" and "ip6" 5.6. "ip4" and "ip6"
These mechanisms test whether <ip> is contained within a given IP These mechanisms test whether <ip> is contained within a given IP
network. network.
ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ] ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ] ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
ip4-cidr-length = "/" 1*DIGIT ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32
ip6-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9 qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99 / %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199 / "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249 / "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255 / "25" %x30-35 ; 250-255
; as per conventional dotted quad notation. e.g., 192.0.2.0 ; as per conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as per [RFC 4291], section 2.2> ip6-network = <as per [RFC 4291], section 2.2>
skipping to change at page 36, line 7 skipping to change at page 36, line 7
%{d2}.trusted-domains.example.net %{d2}.trusted-domains.example.net
example.com.trusted-domains.example.net example.com.trusted-domains.example.net
IPv6: IPv6:
%{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0. %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com
8. Result Handling 8. Result Handling
This section provides guidance for operators in response to the This section provides guidance for SPF verifier operators in response
various possible outputs of check_host() on a message. Definitions to the various possible outputs of check_host() on a message.
of SPF results are presented in Section 2.6; this section provides Definitions of SPF results are presented in Section 2.6; this section
more detail on each for use in developing local policy for message provides more detail on each for use in developing local policy for
handling. message handling.
Every operating environment is different. There are some receivers Every operating environment is different. There are some receivers
for whom strict adherence to SPF is appropriate, and definitive for whom strict adherence to SPF is appropriate, and definitive
treatment of messages that are evaluated to be explicitly treatment of messages that are evaluated to be explicitly
unauthorized ("fail" and sometimes "softfail") is the norm. There unauthorized ("fail" and sometimes "softfail") is the norm. There
are others for which the "false negative" cases are more of a are others for which the "false negative" cases are more of a
concern. This concern is typically handled by merely recording the concern. This concern is typically handled by merely recording the
result in the header and allowing the message to pass on for result in the header and allowing the message to pass on for
additional processing. There are still others where SPF is one of additional processing. There are still others where SPF is one of
several inputs to the message handling decision. As such, there is several inputs to the message handling decision. As such, there is
skipping to change at page 38, line 28 skipping to change at page 38, line 28
software SHOULD use an SMTP reply code of 451 and, if supported, the software SHOULD use an SMTP reply code of 451 and, if supported, the
4.4.3 enhanced status code (see [RFC3463], Section 3.5). These 4.4.3 enhanced status code (see [RFC3463], Section 3.5). These
errors can be caused by problems in either the sender's or receiver's errors can be caused by problems in either the sender's or receiver's
DNS software. See Appendix H.4 for considerations on developing DNS software. See Appendix H.4 for considerations on developing
local policy. local policy.
8.7. Permerror 8.7. Permerror
A "permerror" result means the domain's published records could not A "permerror" result means the domain's published records could not
be correctly interpreted. This signals an error condition that be correctly interpreted. This signals an error condition that
definitely requires operator intervention to be resolved. If the definitely requires DNS operator intervention to be resolved. If the
message is rejected during the SMTP transaction for this reason, the message is rejected during the SMTP transaction for this reason, the
software SHOULD use an SMTP reply code of 550 and, if supported, the software SHOULD use an SMTP reply code of 550 and, if supported, the
5.5.2 enhanced status code (see [RFC3463], Section 3.6). Be aware 5.5.2 enhanced status code (see [RFC3463], Section 3.6). Be aware
that if the ADMD uses macros (Section 7), it is possible that this that if the ADMD uses macros (Section 7), it is possible that this
result is due to the checked identities having an unexpected format. result is due to the checked identities having an unexpected format.
It is also possible that this result is generated by certain SPF It is also possible that this result is generated by certain SPF
verifiers due to the input arguments having an unexpected format; see verifiers due to the input arguments having an unexpected format; see
Section 4.8. See Appendix H.3 for considerations on developing local Section 4.8. See Appendix H.3 for considerations on developing local
policy. policy.
9. Recording the Result 9. Recording the Result
To provide downstream agents, such as MUAs, with the information they To provide downstream agents, such as MUAs, with the information they
might need in terms of evaluating or representing the apparent safety might need in terms of evaluating or representing the apparent safety
of the message content, it is RECOMMENDED that SMTP receivers record of the message content, it is RECOMMENDED that SMTP receivers record
the result of SPF processing in the message header. For operators the result of SPF processing in the message header. For SPF verifier
that choose to record SPF results in the header of the message for operators that choose to record SPF results in the header of the
processing by internal filters or MUAs, two methods are presented. message for processing by internal filters or MUAs, two methods are
Section 9.1 defines the Received-SPF field, which is the results presented. Section 9.1 defines the Received-SPF field, which is the
field originally defined for SPF use. Section 9.2 discusses results field originally defined for SPF use. Section 9.2 discusses
Authentication-Results [RFC5451] which was specified more recently Authentication-Results [RFC5451] which was specified more recently
and is designed for use by SPF and other authentication methods. and is designed for use by SPF and other authentication methods.
Both are in common use, and hence both are included here. However, Both are in common use, and hence both are included here. However,
it is important to note that they were designed to serve slightly it is important to note that they were designed to serve slightly
different purposes. Received-SPF is intended to include enough different purposes. Received-SPF is intended to include enough
information to enable reconstruction of the SPF evaluation of the information to enable reconstruction of the SPF evaluation of the
message, while Authentication-Results is designed only to relay the message, while Authentication-Results is designed only to relay the
result itself and related output details of likely use to end users result itself and related output details of likely use to end users
(e.g., what property of the message was actually authenticated and (e.g., what property of the message was actually authenticated and
what it contained), leaving reconstructive work to the purview of what it contained), leaving reconstructive work to the purview of
system logs and the Received field contents. Also, Received-SPF system logs and the Received field contents. Also, Received-SPF
relies on compliance of agents within the receiving ADMD to adhere to relies on compliance of agents within the receiving ADMD to adhere to
the header field ordering rules of [RFC5321] and [RFC5322], while the header field ordering rules of [RFC5321] and [RFC5322], while
Authentication-Results includes some provisions to protect against Authentication-Results includes some provisions to protect against
non-compliant implementations. non-compliant implementations.
An operator could choose to use both to serve different downstream An SPF verifier operator could choose to use both to serve different
agents. In such cases, care needs to be taken to ensure both fields downstream agents. In such cases, care needs to be taken to ensure
are conveying the same details, or unexpected results can occur. both fields are conveying the same details, or unexpected results can
occur.
9.1. The Received-SPF Header Field 9.1. The Received-SPF Header Field
The Received-SPF header field is a trace field (see [RFC5322] Section 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 3.6.7) and SHOULD be prepended to the existing header, above the
Received: field that is generated by the SMTP receiver. It MUST Received: field that is generated by the SMTP receiver. It MUST
appear above all other Received-SPF fields in the message. The appear above all other Received-SPF fields in the message. The
header field has the following format: header field has the following format:
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
skipping to change at page 56, line 40 skipping to change at page 56, line 40
ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ] ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ] ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
exists = "exists" ":" domain-spec exists = "exists" ":" domain-spec
modifier = redirect / explanation / unknown-modifier modifier = redirect / explanation / unknown-modifier
redirect = "redirect" "=" domain-spec redirect = "redirect" "=" domain-spec
explanation = "exp" "=" domain-spec explanation = "exp" "=" domain-spec
unknown-modifier = name "=" macro-string unknown-modifier = name "=" macro-string
; where name is not any known modifier ; where name is not any known modifier
ip4-cidr-length = "/" 1*DIGIT ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32
ip6-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9 qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99 / %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199 / "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249 / "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255 / "25" %x30-35 ; 250-255
; conventional dotted quad notation. e.g., 192.0.2.0 ; conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as per [RFC 4291], section 2.2> ip6-network = <as per [RFC 4291], section 2.2>
skipping to change at page 69, line 28 skipping to change at page 69, line 28
receiver can do to draw attention to the difficulty encountered while receiver can do to draw attention to the difficulty encountered while
protecting itself from messages that do not have a definite SPF protecting itself from messages that do not have a definite SPF
result of some kind. However, if the SPF implementation is defective result of some kind. However, if the SPF implementation is defective
and returns spurious "permerror" results, only the sender is actively and returns spurious "permerror" results, only the sender is actively
notified of the defect (in the form of rejected mail), and not the notified of the defect (in the form of rejected mail), and not the
receiver making use of SPF. receiver making use of SPF.
The less intrusive handling choice is to deliver the message, perhaps The less intrusive handling choice is to deliver the message, perhaps
with some kind of annotation of the difficulty encountered and/or with some kind of annotation of the difficulty encountered and/or
logging of a similar nature. However, this will not be desirable to logging of a similar nature. However, this will not be desirable to
operators that wish to implement SPF checking as strictly as SPF verifier operators that wish to implement SPF checking as
possible, nor is this sort of passive problem reporting typically strictly as possible, nor is this sort of passive problem reporting
effective. typically effective.
There is of course the option placing this choice in the hands of the There is of course the option placing this choice in the hands of the
operator rather than the implementer since this kind of choice is SPF verifier operator rather than the implementer since this kind of
often a matter of local policy rather than a condition with a choice is often a matter of local policy rather than a condition with
universal solution, but this adds one more piece of complexity to an a universal solution, but this adds one more piece of complexity to
already non-trivial environment. an already non-trivial environment.
Both implementers and operators need to be cautious of all choices Both implementers and SPF verfier operators need to be cautious of
and outcomes when handling SPF results. all choices and outcomes when handling SPF results.
H.4. Policy For SPF Temperror H.4. Policy For SPF Temperror
The "temperror" result (see Section 2.6.6) indicates the SPF The "temperror" result (see Section 2.6.6) indicates the SPF
processing module at the receiver could not retrieve and SPF policy processing module at the receiver could not retrieve and SPF policy
record due to a (probably) transient condition. This gives no true record due to a (probably) transient condition. This gives no true
indication about the authorized use of the data found in the indication about the authorized use of the data found in the
envelope. envelope.
As with all results, implementers have a choice to make regarding As with all results, implementers have a choice to make regarding
skipping to change at page 70, line 23 skipping to change at page 70, line 23
Because of long queue lifetimes, it is possible that mail will be Because of long queue lifetimes, it is possible that mail will be
repeatedly deferred for several days and so any awareness by the repeatedly deferred for several days and so any awareness by the
sender of a problem could be quite delayed. If "temperrors" persist sender of a problem could be quite delayed. If "temperrors" persist
for multiple delivery attempts, it might be preferable to treat the for multiple delivery attempts, it might be preferable to treat the
error as permanent and reduce the amount of time the message is in error as permanent and reduce the amount of time the message is in
transit. transit.
The less intrusive handling choice is to deliver the message, perhaps The less intrusive handling choice is to deliver the message, perhaps
with some kind of annotation of the difficulty encountered and/or with some kind of annotation of the difficulty encountered and/or
logging of a similar nature. However, this will not be desirable to logging of a similar nature. However, this will not be desirable to
operators that wish to implement SPF checking as strictly as SPF verifier operators that wish to implement SPF checking as
possible, nor is this sort of passive problem reporting typically strictly as possible, nor is this sort of passive problem reporting
effective. typically effective.
There is of course the option placing this choice in the hands of the There is of course the option placing this choice in the hands of the
operator rather than the implementer since this kind of choice is SPF verifier operator rather than the implementer since this kind of
often a matter of local policy rather than a condition with a choice is often a matter of local policy rather than a condition with
universal solution, but this adds one more piece of complexity to an a universal solution, but this adds one more piece of complexity to
already non-trivial environment. an already non-trivial environment.
Both implementers and operators need to be cautious of all choices Both implementers and SPF verifier operators need to be cautious of
and outcomes when handling SPF results. all choices and outcomes when handling SPF results.
Appendix I. Protocol Status Appendix I. Protocol Status
NOTE TO RFC EDITOR: To be removed prior to publication. NOTE TO RFC EDITOR: To be removed prior to publication.
SPF has been in development since the summer of 2003 and has seen SPF has been in development since the summer of 2003 and has seen
deployment beyond the developers beginning in December 2003. The deployment beyond the developers beginning in December 2003. The
design of SPF slowly evolved until the spring of 2004 and has since design of SPF slowly evolved until the spring of 2004 and has since
stabilized. There have been quite a number of forms of SPF, some stabilized. There have been quite a number of forms of SPF, some
written up as documents, some submitted as Internet Drafts, and many written up as documents, some submitted as Internet Drafts, and many
 End of changes. 22 change blocks. 
51 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--nextPart15323002.Ipxd0vRHzP-- From paf@frobbit.se Tue Sep 10 04:04: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 47CC021E80F7; Tue, 10 Sep 2013 04:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 oQM4zsMs0qrE; Tue, 10 Sep 2013 04:04:13 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id E164C21E8138; Tue, 10 Sep 2013 04:04:06 -0700 (PDT) Received: from [10.0.0.23] (unknown [77.241.239.225]) by mail.frobbit.se (Postfix) with ESMTPSA id DF9B523F66; Tue, 10 Sep 2013 13:04:05 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <522B2AC4.4090006@qti.qualcomm.com> Date: Tue, 10 Sep 2013 13:04:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2C6B0D9B-7E1E-4CC3-AA41-935D65E79A3F@frobbit.se> References: <522B2AC4.4090006@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Tue, 10 Sep 2013 05:59:41 -0700 Cc: "spfbis@ietf.org" , IETF-Discussion list Subject: Re: [spfbis] Conclusions of Last Call for draft-ietf-spfbis-4408bis 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, 10 Sep 2013 11:04:14 -0000 On 7 sep 2013, at 15:31, Pete Resnick wrote: > 5c. Things may have changed since 6686. We should do more data = collection. > - There's no reason to believe that the small amounts of = recently presented data are representative. > - Nobody presented any basis to doubt the folks working in the = industry. > - There has been ample opportunity (and motivation) for folks = outside of the WG to do more data collection; none has been presented. > - It is an unreasonable burden to place on the WG at this = point. FWIW, we at Netnod that run i-root have been looking at the queries we = get to the root name server of ours. We have been looking at the data collected during the DITL collection = which is 30-48 hour collections of data that happens once a year. What we did look at was first of all every query for an MX resource = record. Then we look at +/-1 second from the timestamp of that MX query = for TXT and/or SPF record for the same owner. We draw the conclusion = that if there is a query for an MX record, and then either TXT or SPF = (or both) within the approximately same timespan, then they are related = queries. We did look at 2011, 2012 and 2013. The result is the following: Date MX TXT SPF %TXT/MX %SPF/MX %SPF/TXT 2011-06-07 148528658 7484035 784386 5.0% 0.5% 10.5% 2012-04-17 90779132 4839143 536467 5.3% 0.6% 11.1% 2013-05-28 114353838 11554391 1595777 10.1% 1.4% 13.8% What we see is that the percentage of TXT queries per MX query has gone = up from 5% to 10.1% and SPF queries went up from 0.5% to 1.4%. The = percentage of SPF queries compared to TXT went up from 10.5% to 13.8%. Regards, Patrik F=E4ltstr=F6m From paf@frobbit.se Tue Sep 10 05:32: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 308DC21E808F; Tue, 10 Sep 2013 05:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 ftbjvS39ocRE; Tue, 10 Sep 2013 05:32:27 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF7221E8053; Tue, 10 Sep 2013 05:32:24 -0700 (PDT) Received: from [10.0.0.23] (unknown [77.241.239.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 8753623F30; Tue, 10 Sep 2013 14:32:22 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D2D09CEC-BDA9-497F-9533-829AE0ED0EB6" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Tue, 10 Sep 2013 14:32:21 +0200 Message-Id: <0ECBFED5-CF62-4EC7-BE6D-DD65A8778D0A@frobbit.se> References: <522B2AC4.4090006@qti.qualcomm.com> <2C6B0D9B-7E1E-4CC3-AA41-935D65E79A3F@frobbit.se> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Tue, 10 Sep 2013 05:59:41 -0700 Cc: "spfbis@ietf.org" , Pete Resnick , IETF-Discussion list Subject: Re: [spfbis] Conclusions of Last Call for draft-ietf-spfbis-4408bis 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, 10 Sep 2013 12:32:29 -0000 --Apple-Mail=_D2D09CEC-BDA9-497F-9533-829AE0ED0EB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 10 sep 2013, at 13:39, "Murray S. Kucherawy" = wrote: > On Tue, Sep 10, 2013 at 4:04 AM, Patrik F=E4ltstr=F6m = wrote: > What we did look at was first of all every query for an MX resource = record. Then we look at +/-1 second from the timestamp of that MX query = for TXT and/or SPF record for the same owner. We draw the conclusion = that if there is a query for an MX record, and then either TXT or SPF = (or both) within the approximately same timespan, then they are related = queries. >=20 > I'm not sure that's a valid conclusion. Since MX is needed only for a = sending system, a receiving system doing an SPF check of either type has = no reason to query for MX. The exception to this might be a heuristic = check to see if the domain in the MAIL FROM has MX or A published such = that a reply appears to be possible, but I wouldn't expect a strong = correlation in your data. True. View my explanation just like it was, how we did our calculations. = Conclusions can anyone draw from the data. The problem is that if one look at just queries to a root server like = this, there is lots of what I would call "junk". When looking at TLDs, = we saw about 162 million different TLDs each 24h in the QNAME. We saw = this time also for example queries for SPF and other RR Types where the = QNAME was an IPv4 address (for example "10.2.3.4."). So, we found _some_ algorithm was needed instead of "just" counting = queries, and we did count the way I just explained. Patrik --Apple-Mail=_D2D09CEC-BDA9-497F-9533-829AE0ED0EB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 superuser@gmail.com> = wrote:
On Tue, Sep 10, 2013 at 4:04 AM, = Patrik F=E4ltstr=F6m <paf@frobbit.se> wrote:
What we did look at was first of all every query for an MX = resource record. Then we look at +/-1 second from the timestamp of that = MX query for TXT and/or SPF record for the same owner. We draw the = conclusion that if there is a query for an MX record, and then either = TXT or SPF (or both) within the approximately same timespan, then they = are related queries.

I'm not sure = that's a valid conclusion.  Since MX is needed only for a sending = system, a receiving system doing an SPF check of either type has no = reason to query for MX.  The exception to this might be a heuristic = check to see if the domain in the MAIL FROM has MX or A published such = that a reply appears to be possible, but I wouldn't expect a strong = correlation in your = data.

True.

View my explanation just like it was, how we did our = calculations. Conclusions can anyone draw from the = data.

The problem is that if one look at just = queries to a root server like this, there is lots of what I would call = "junk". When looking at TLDs, we saw about 162 million different TLDs = each 24h in the QNAME. We saw this time also for example queries for SPF = and other RR Types where the QNAME was an IPv4 address (for example = "10.2.3.4.").

So, we found _some_ algorithm was = needed instead of "just" counting queries, and we did count the way I = just explained.

  =  Patrik

= --Apple-Mail=_D2D09CEC-BDA9-497F-9533-829AE0ED0EB6-- From sm@elandsys.com Tue Sep 10 11:37: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 D5CE421E809C; Tue, 10 Sep 2013 11:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=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 yO+OmLvpJ0nA; Tue, 10 Sep 2013 11:37:28 -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 9E0F121F9B66; Tue, 10 Sep 2013 11:37:27 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.140.78]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8AIbCW6000674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Sep 2013 11:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378838246; bh=BVYCpkgoA/JmDDY2wTE01/6OOY0TmqDNM1Uy3XOMPkI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dQvd0mT1Jjb11rk2romR6wn89GNia7tBDjqhmvRHgArlld4oakBwQjXJhMxUhFm7z VbtR1u0rt5xm4EH54sgpzZfRV6Tk/k6NmSxd7cx2qbCrR0LZ6TRPwTndsR3zPz884d 8jmpphO7IVSHcsy1auJMciGT/Grk0f+CgnuYRHKo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378838246; i=@elandsys.com; bh=BVYCpkgoA/JmDDY2wTE01/6OOY0TmqDNM1Uy3XOMPkI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=GSNklozqGM+6BluJjgUWmR8uKcqoRrR6XoNYH4gK8VzqGU0ywLzpa5JDlc18LMntw gRkNeoF+ngGxAtCYI9EGLhnFRMcqtUBOynT0xorG6t0HUzPn852RvyBOd6vrYJxR5t qnoUeamz2RkO5RRKZj/uYZMVAoIBdk3UopSf5kbE= Message-Id: <6.2.5.6.2.20130910113052.0c339a60@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Sep 2013 11:33:43 -0700 To: Pete Resnick , The IESG From: S Moonesamy In-Reply-To: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 10 Sep 2013 18:37:30 -0000 Hi Pete, I'll post some text proposed by Scott Kitterman to address the DISCUSS. I am adding the SPFBIS WG to the Cc. At 06:55 07-09-2013, Pete Resnick wrote: >Pete Resnick has entered the following ballot position for >draft-ietf-spfbis-4408bis-19: Discuss [snip] >Holding my own DISCUSS: > >Text needs to be created (probably for section 3.1) to better describe >the reason this document settled on TXT RR only and therefore why no >precedent is set for future use of the TXT RR. [snip] >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Clarifications needed regarding size limitations in 3.4, and perhaps some >clarifications in 4.6.4. 3.1. DNS Resource Records SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only. The character content of the record is encoded as [US-ASCII]. Use of alternative DNS RR types was supported in WAS < SPF's experimental phase, but has been discontinued. See Appendix A < of [RFC6686] for further information. PROPOSED > SPF's experimental phase, but has been discontinued. > > In 2003, when SPF was first being developed, the requirements for > assignment of a new DNS RR type were considerably more stringent than > they are now. Additionally, support for easy deployment of new DNS > RR types was not widely deployed in DNS servers and and provisioning > systems. As a result, at that time, there was no reasonable > alternative to using the TXT RR type for SPF records. > > In its review of [RFC4408] the SPFbis working group concluded that > its dual RR type transition model was fundamentally flawed since it > contained no common RR type that implementers were required to serve > and required to check. Many alternatives were considered to resolve > this issue, but ultimately the working group concluded that > significant migration to the SPF RR type in the forseable future and > that the best solution for resolving this interoperability issue was > to drop support for the SPF RR type from SPF version 1. See Appendix > A of [RFC6686] for further information. > > The circumstances surrounding SPF's initial deploymenta decade ago > are unique and very, very unlikely to be repeated. SPF's use of the > TXT RR type for structured data should in no way be taken as > precedent for future protocol designers. Things have changed. 3.4. Record Size The published SPF record for a given domain name SHOULD remain small enough that the results of a query for it will fit within 512 octets. This UDP limit is defined in [RFC1035] section 2.3.4, although it was raised by [RFC2671]. Staying below 512 octets ought to prevent older DNS implementations from failing over to TCP,and will work with UDP in the absence of EDNS0 [RFC6891] support. Since the answer size is dependent on many things outside the scope of this document, it is WAS < only possible to give this guideline: If the combined length of the < DNS name and the text of all the records of a given type is under 450 < octets, then DNS answers ought to fit in UDP packets. Records that < are too long to fit in a single UDP packet could be silently ignored < by SPF verifiers due to firewall and other issues that interfere with < the operation of DNS over TCP or using ENDS0. PROPOSED > only possible to give this guideline: If the size of the DNS message, > the combined length of the DNS name and the text of all the records > of a given type is under 450 octets, then DNS answers ought to fit in > UDP packets. Records that are too long to fit in a single UDP packet > could be silently ignored by SPF verifiers due to firewall and other > issues that interfere with the operation of DNS over TCP or using > ENDS0. Note that when computing the sizes for replies to queries of the TXT format, one has to take into account any other TXT records published at the domain name. Similarly, the sizes for replies to all queries related to SPF have to be evaluated to fit in a single 512 octet UDP WAS < packet. PROPOSED > packet (i.e. DNS message size limited to 450 octects). Regards, S. Moonesamy (as document shepherd) From spencerdawkins.ietf@gmail.com Tue Sep 10 13:01: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 1B04421F9A16; Tue, 10 Sep 2013 13:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=0.318, 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 o8W7yOS7xITU; Tue, 10 Sep 2013 13:01:34 -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 1945E11E8101; Tue, 10 Sep 2013 13:01:23 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id b12so1049728wgh.3 for ; Tue, 10 Sep 2013 13:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6HYaPywn/lsySn32HHWDM7CZHsFRjw0Z5fET/MhxWok=; b=J0cIMseWtS4uHUouq5mam/L6o4qjkBXHSg/UJQCHUQe7sDsOw5We2JHrELvBxTa8H2 J+vqHfHf7R/qWtVmljRyrtY2ssYqAvWMF+I0ZOqE7RkSsTAm3Az7kBa4o0F7j+g3AWPl 7iiKsj6pQli20FhEmlkUTmxRUnTo0GcNMzQAB+V5wYSrYCQPZ2UIMGBvGg/PvXXDLHQv ogR/v0fBXOHv08P68zgdTUzGgLjX8ugVeSjKKzZop1I/Y5ohKn9Y+8J3aWGNa+IyRvv6 0VhkaTETVWSXpPMaOkH34jAWu1IBmV3AtpYssLegBUaoxYytrPV3eV/if7sT2VcRrwgF orvw== X-Received: by 10.180.12.45 with SMTP id v13mr14120295wib.57.1378843281272; Tue, 10 Sep 2013 13:01:21 -0700 (PDT) Received: from [192.168.0.30] (173-135-203-236.pools.spcsdns.net. [173.135.203.236]) by mx.google.com with ESMTPSA id li9sm5879544wic.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Sep 2013 13:01:20 -0700 (PDT) Message-ID: <522F7A8F.5060807@gmail.com> Date: Tue, 10 Sep 2013 15:01:19 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: S Moonesamy References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130910113052.0c339a60@elandnews.com> In-Reply-To: <6.2.5.6.2.20130910113052.0c339a60@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 10 Sep 2013 13:24:25 -0700 Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Pete Resnick , draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 10 Sep 2013 20:01:35 -0000 On 9/10/2013 1:33 PM, S Moonesamy wrote: Hi, SM, > PROPOSED > > > Many alternatives were considered to resolve > > this issue, but ultimately the working group concluded that > > significant migration to the SPF RR type in the forseable future and > > that the best solution for resolving this interoperability issue was > > to drop support for the SPF RR type from SPF version 1. I liked where the proposed text seemed to be headed, but this sentence didn't parse for me (missing words?), and it seems like a really important sentence ... Spencer From sm@elandsys.com Tue Sep 10 13:25: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 C164921E80B1; Tue, 10 Sep 2013 13:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ZDyCw5SAWuFS; Tue, 10 Sep 2013 13:25:35 -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 C0E7B21E80AF; Tue, 10 Sep 2013 13:25:35 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.140.78]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8AKPGTu009693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Sep 2013 13:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378844730; bh=iP4fmxYNB72oe2eTWLKLfEom/d37jj2+tmg5L0bDeBE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wy1BwVYJqr9kinogM8MB+4C3y0/Jv2XkBphdvFby+RN5HSejAOpmOa55gOXnwnLCU 7E4SrcWQhAxL0BtptHpP/YpeeqCz6yOJsk5SbfDyY++veeiXrFrBe+zr/uJBq0XtUo 1U93d66zIJ5+/GYYBKaRfPbZ456VFldlstqWZLbA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378844730; i=@elandsys.com; bh=iP4fmxYNB72oe2eTWLKLfEom/d37jj2+tmg5L0bDeBE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FCFrs/DMc5EU+ZSnA4GRLSJ80IheTA/3VW7B0dXC9lbNhIsBFTARuaHp4EzAuiOZB 8QArlbKV1VcGSU5sWnSgAYS2WEU4hMIHOI3PVsloMELAKnfWIeC9T2eEE43pEWHOGI 4cuwn85K6AmFcTFJb/QNQ8RQ4ZPTOvTBfP7rgBMI= Message-Id: <6.2.5.6.2.20130910131842.0cec1d40@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Sep 2013 13:24:05 -0700 To: Spencer Dawkins , spfbis@ietf.org From: S Moonesamy In-Reply-To: <522F7A8F.5060807@gmail.com> References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130910113052.0c339a60@elandnews.com> <522F7A8F.5060807@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Pete Resnick , draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 10 Sep 2013 20:25:43 -0000 Hi Spencer, At 13:01 10-09-2013, Spencer Dawkins wrote: >I liked where the proposed text seemed to be headed, but this >sentence didn't parse for me (missing words?), and it seems like a >really important sentence ... Yes, there are some words missing. Can the SPFBIS WG please review the text in the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg04104.html and suggest text to address the DISCUSS (see http://www.ietf.org/mail-archive/web/spfbis/current/msg04099.html ). Regards, S. Moonesamy (as document shepherd) From spf2@kitterman.com Tue Sep 10 18:38: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 EAB5A11E81D0; Tue, 10 Sep 2013 18:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.697 X-Spam-Level: X-Spam-Status: No, score=-0.697 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, NORMAL_HTTP_TO_IP=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 ym7MDFlwb8ju; Tue, 10 Sep 2013 18:38:07 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9618011E81DB; Tue, 10 Sep 2013 18:38:06 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 615A220E40D5; Tue, 10 Sep 2013 21:38:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1378863485; bh=boP7VusEo0O9ENCsx3c7kjqCp92Cagu9VfXV6LsB+FY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qNjze4Uzsj1CQxhaLAB4DCxVCcz2ihP0kaTZYziHnK06ddX+mYW/AA9BjIb7Klr8r E+0pe3XUIVapYus0C8dysgTaM+PW/WoubnPLjHxBkFtltbG4zo7FcvT1v4I7loPIYS KdM+gSuRDy/VT3G4QBJQ+TY9bkSZxnIGAcehqJNs= 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 3909B20E40C7; Tue, 10 Sep 2013 21:38:04 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org, S Moonesamy , Pete Resnick Date: Tue, 10 Sep 2013 21:38:01 -0400 Message-ID: <10370218.OEr9JV8dgx@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <522F7A8F.5060807@gmail.com> References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130910113052.0c339a60@elandnews.com> <522F7A8F.5060807@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart7749248.bf4gaU6bsf" Content-Transfer-Encoding: 7Bit X-AV-Checked: ClamAV using ClamSMTP Cc: spfbis-chairs@tools.ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, Spencer Dawkins , The IESG Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 01:38:12 -0000 This is a multi-part message in MIME format. --nextPart7749248.bf4gaU6bsf Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Tuesday, September 10, 2013 15:01:19 Spencer Dawkins wrote: > On 9/10/2013 1:33 PM, S Moonesamy wrote: > > Hi, SM, > > > PROPOSED > > > > > Many alternatives were considered to resolve > > > this issue, but ultimately the working group concluded that > > > significant migration to the SPF RR type in the forseable future and > > > that the best solution for resolving this interoperability issue was > > > to drop support for the SPF RR type from SPF version 1. > > I liked where the proposed text seemed to be headed, but this sentence > didn't parse for me (missing words?), and it seems like a really > important sentence ... Here's the fixed sentence. I suspect the truth may be less dramatic than you imagined. I also got a bit more expansive in the last paragraph. I've attached a revised rfcdiff for the total local diff I'm carrying now. Here's what I have now: 3.1. DNS Resource Records SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only. The character content of the record is encoded as [US-ASCII]. Use of alternative DNS RR types was supported in SPF's experimental phase, but has been discontinued. In 2003, when SPF was first being developed, the requirements for assignment of a new DNS RR type were considerably more stringent than they are now. Additionally, support for easy deployment of new DNS RR types was not widely deployed in DNS servers and and provisioning systems. As a result, at that time, there was no reasonable alternative to using the TXT RR type for SPF records. In its review of [RFC4408] the SPFbis working group concluded that its dual RR type transition model was fundamentally flawed since it contained no common RR type that implementers were required to serve and required to check. Many alternatives were considered to resolve this issue, but ultimately the working group concluded that significant migration to the SPF RR type in the forseable future was very unlikely and that the best solution for resolving this interoperability issue was to drop support for the SPF RR type from SPF version 1. See Appendix A of [RFC6686] for further information. The circumstances surrounding SPF's initial deploymenta decade ago are unique and very, very unlikely to be repeated. If a future update to a new SPF version that could not reuse existing SPF records were to be developed, it ought to use the SPF RR type. SPF's use of the TXT RR type for structured data should in no way be taken as precedent for future protocol designers. Things have changed. Scott K --nextPart7749248.bf4gaU6bsf Content-Disposition: attachment; filename="draft-ietf-spfbis-4408bis-20-from-19.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="draft-ietf-spfbis-4408bis-20-from-19.diff.html" Diff: draft-ietf-spfbis-4408bis-19.txt - draft-ietf-spfbis-4408bis-20.txt
 draft-ietf-spfbis-4408bis-19.txt   draft-ietf-spfbis-4408bis-20.txt 
Network Working Group S. Kitterman Network Working Group S. Kitterman
Internet-Draft Kitterman Technical Services Internet-Draft Kitterman Technical Services
Obsoletes: 4408 (if approved) August 17, 2013 Obsoletes: 4408 (if approved) September 10, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: February 18, 2014 Expires: March 14, 2014
Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email,
Version 1 Version 1
draft-ietf-spfbis-4408bis-19 draft-ietf-spfbis-4408bis-20
Abstract Abstract
Email on the Internet can be forged in a number of ways. In Email on the Internet can be forged in a number of ways. In
particular, existing protocols place no restriction on what a sending 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 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 SMTP HELO/EHLO commands. This document describes version 1 of
the Sender Policy Framework (SPF) protocol, whereby ADministrative the Sender Policy Framework (SPF) protocol, whereby ADministrative
Management Domains (ADMDs) can explicitly authorize the hosts that Management Domains (ADMDs) can explicitly authorize the hosts that
are allowed to use its domain names, and a receiving host can check are allowed to use its domain names, and a receiving host can check
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 18, 2014. This Internet-Draft will expire on March 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 32 skipping to change at page 3, line 32
2.6.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.6. Temperror . . . . . . . . . . . . . . . . . . . . . . 11 2.6.6. Temperror . . . . . . . . . . . . . . . . . . . . . . 11
2.6.7. Permerror . . . . . . . . . . . . . . . . . . . . . . 11 2.6.7. Permerror . . . . . . . . . . . . . . . . . . . . . . 11
3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. DNS Resource Records . . . . . . . . . . . . . . . . . . . 12 3.1. DNS Resource Records . . . . . . . . . . . . . . . . . . . 12
3.2. Multiple DNS Records . . . . . . . . . . . . . . . . . . . 13 3.2. Multiple DNS Records . . . . . . . . . . . . . . . . . . . 13
3.3. Multiple Strings in a Single DNS record . . . . . . . . . 13 3.3. Multiple Strings in a Single DNS record . . . . . . . . . 13
3.4. Record Size . . . . . . . . . . . . . . . . . . . . . . . 13 3.4. Record Size . . . . . . . . . . . . . . . . . . . . . . . 14
3.5. Wildcard Records . . . . . . . . . . . . . . . . . . . . . 14 3.5. Wildcard Records . . . . . . . . . . . . . . . . . . . . . 14
4. The check_host() Function . . . . . . . . . . . . . . . . . . 15 4. The check_host() Function . . . . . . . . . . . . . . . . . . 16
4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 16 4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 17
4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 16 4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 17
4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 16 4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 17
4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 16 4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 17
4.6.1. Term Evaluation . . . . . . . . . . . . . . . . . . . 17 4.6.1. Term Evaluation . . . . . . . . . . . . . . . . . . . 18
4.6.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 17 4.6.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 18
4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 18 4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 19
4.6.4. DNS Lookup Limits . . . . . . . . . . . . . . . . . . 18 4.6.4. DNS Lookup Limits . . . . . . . . . . . . . . . . . . 19
4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 19 4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 20
4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 19 4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 20
5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 21 5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 22
5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.5. "ptr" (do not use) . . . . . . . . . . . . . . . . . . . . 24 5.5. "ptr" (do not use) . . . . . . . . . . . . . . . . . . . . 25
5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 26 5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 27
5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 27
6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 28 6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 29
6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 28 6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 29
6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 29 6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 30
7. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1. Formal Specification . . . . . . . . . . . . . . . . . . . 31 7.1. Formal Specification . . . . . . . . . . . . . . . . . . . 32
7.2. Macro Definitions . . . . . . . . . . . . . . . . . . . . 31 7.2. Macro Definitions . . . . . . . . . . . . . . . . . . . . 32
7.3. Macro Processing Details . . . . . . . . . . . . . . . . . 32 7.3. Macro Processing Details . . . . . . . . . . . . . . . . . 33
7.4. Expansion Examples . . . . . . . . . . . . . . . . . . . . 34 7.4. Expansion Examples . . . . . . . . . . . . . . . . . . . . 35
8. Result Handling . . . . . . . . . . . . . . . . . . . . . . . 36 8. Result Handling . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 8.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . . . 36 8.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.6. Temperror . . . . . . . . . . . . . . . . . . . . . . . . 38 8.6. Temperror . . . . . . . . . . . . . . . . . . . . . . . . 39
8.7. Permerror . . . . . . . . . . . . . . . . . . . . . . . . 38 8.7. Permerror . . . . . . . . . . . . . . . . . . . . . . . . 39
9. Recording the Result . . . . . . . . . . . . . . . . . . . . . 39 9. Recording the Result . . . . . . . . . . . . . . . . . . . . . 40
9.1. The Received-SPF Header Field . . . . . . . . . . . . . . 39 9.1. The Received-SPF Header Field . . . . . . . . . . . . . . 40
9.2. SPF Results in the Authentication-Results Header Field . . 41 9.2. SPF Results in the Authentication-Results Header Field . . 42
10. Effects on Infrastructure . . . . . . . . . . . . . . . . . . 43 10. Effects on Infrastructure . . . . . . . . . . . . . . . . . . 44
10.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 43 10.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 44
10.1.1. DNS Resource Considerations . . . . . . . . . . . . . 43 10.1.1. DNS Resource Considerations . . . . . . . . . . . . . 44
10.1.2. Administrator's Considerations . . . . . . . . . . . . 44 10.1.2. Administrator's Considerations . . . . . . . . . . . . 45
10.1.3. Bounces . . . . . . . . . . . . . . . . . . . . . . . 45 10.1.3. Bounces . . . . . . . . . . . . . . . . . . . . . . . 46
10.2. Receivers . . . . . . . . . . . . . . . . . . . . . . . . 45 10.2. Receivers . . . . . . . . . . . . . . . . . . . . . . . . 46
10.3. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 45 10.3. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 46
11. Security Considerations . . . . . . . . . . . . . . . . . . . 47 11. Security Considerations . . . . . . . . . . . . . . . . . . . 48
11.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 47 11.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 48
11.2. SPF-Authorized Email May Contain Other False Identities . 48 11.2. SPF-Authorized Email May Contain Other False Identities . 49
11.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 48 11.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 49
11.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 48 11.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 49
11.5. Untrusted Information Sources . . . . . . . . . . . . . . 49 11.5. Untrusted Information Sources . . . . . . . . . . . . . . 50
11.5.1. Recorded Results . . . . . . . . . . . . . . . . . . . 49 11.5.1. Recorded Results . . . . . . . . . . . . . . . . . . . 50
11.5.2. External Explanations . . . . . . . . . . . . . . . . 49 11.5.2. External Explanations . . . . . . . . . . . . . . . . 50
11.5.3. Macro Expansion . . . . . . . . . . . . . . . . . . . 50 11.5.3. Macro Expansion . . . . . . . . . . . . . . . . . . . 51
11.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 50 11.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 51
11.7. Delivering Mail Producing a 'Fail' Result . . . . . . . . 50 11.7. Delivering Mail Producing a 'Fail' Result . . . . . . . . 51
12. Contributors and Acknowledgements . . . . . . . . . . . . . . 51 12. Contributors and Acknowledgements . . . . . . . . . . . . . . 52
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
13.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 52 13.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 53
13.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 52 13.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 53
13.3. SPF Modifier Registry . . . . . . . . . . . . . . . . . . 52 13.3. SPF Modifier Registry . . . . . . . . . . . . . . . . . . 53
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
14.1. Normative References . . . . . . . . . . . . . . . . . . . 53 14.1. Normative References . . . . . . . . . . . . . . . . . . . 54
14.2. Informative References . . . . . . . . . . . . . . . . . . 54 14.2. Informative References . . . . . . . . . . . . . . . . . . 55
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 56 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 57
Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 59 Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 60
B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 59 B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 60
B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 60 B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 61
B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 61 B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 62
B.4. Multiple Requirements Example . . . . . . . . . . . . . . 61 B.4. Multiple Requirements Example . . . . . . . . . . . . . . 62
Appendix C. Changes in implementation requirements from RFC Appendix C. Changes in implementation requirements from RFC
4408 . . . . . . . . . . . . . . . . . . . . . . . . 62 4408 . . . . . . . . . . . . . . . . . . . . . . . . 63
Appendix D. Further Testing Advice . . . . . . . . . . . . . . . 63 Appendix D. Further Testing Advice . . . . . . . . . . . . . . . 64
Appendix E. SPF/Mediator Interactions . . . . . . . . . . . . . . 64 Appendix E. SPF/Mediator Interactions . . . . . . . . . . . . . . 65
E.1. Originating ADMDs . . . . . . . . . . . . . . . . . . . . 64 E.1. Originating ADMDs . . . . . . . . . . . . . . . . . . . . 65
E.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 65 E.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 66
E.3. Receving ADMDs . . . . . . . . . . . . . . . . . . . . . . 65 E.3. Receving ADMDs . . . . . . . . . . . . . . . . . . . . . . 66
Appendix F. Mail Services . . . . . . . . . . . . . . . . . . . . 66 Appendix F. Mail Services . . . . . . . . . . . . . . . . . . . . 67
Appendix G. MTA Relays . . . . . . . . . . . . . . . . . . . . . 67 Appendix G. MTA Relays . . . . . . . . . . . . . . . . . . . . . 68
Appendix H. Local Policy Considerations . . . . . . . . . . . . . 68 Appendix H. Local Policy Considerations . . . . . . . . . . . . . 69
H.1. Policy For SPF Pass . . . . . . . . . . . . . . . . . . . 68 H.1. Policy For SPF Pass . . . . . . . . . . . . . . . . . . . 69
H.2. Policy For SPF Fail . . . . . . . . . . . . . . . . . . . 68 H.2. Policy For SPF Fail . . . . . . . . . . . . . . . . . . . 69
H.3. Policy For SPF Permerror . . . . . . . . . . . . . . . . . 69 H.3. Policy For SPF Permerror . . . . . . . . . . . . . . . . . 70
H.4. Policy For SPF Temperror . . . . . . . . . . . . . . . . . 69 H.4. Policy For SPF Temperror . . . . . . . . . . . . . . . . . 70
Appendix I. Protocol Status . . . . . . . . . . . . . . . . . . . 71 Appendix I. Protocol Status . . . . . . . . . . . . . . . . . . . 72
Appendix J. Change History . . . . . . . . . . . . . . . . . . . 72 Appendix J. Change History . . . . . . . . . . . . . . . . . . . 73
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 76
1. Introduction 1. Introduction
The current email infrastructure has the property that any host The current email infrastructure has the property that any host
injecting mail into the system can use any DNS domain name it wants injecting mail into the system can use any DNS domain name it wants
in each of the various identifiers specified by [RFC5321] and in each of the various identifiers specified by [RFC5321] and
[RFC5322]. Although this feature is desirable in some circumstances, [RFC5322]. Although this feature is desirable in some circumstances,
it is a major obstacle to reducing Unsolicited Bulk Email (UBE, aka it is a major obstacle to reducing Unsolicited Bulk Email (UBE, aka
spam). Furthermore, many domain owning ADMDs (as described in spam). Furthermore, many domain owning ADMDs (as described in
[RFC5598]) are understandably concerned about the ease with which [RFC5598]) are understandably concerned about the ease with which
skipping to change at page 11, line 45 skipping to change at page 11, line 45
2.6.5. Softfail 2.6.5. Softfail
The ADMD has published a weak statement that the host is probably not The ADMD has published a weak statement that the host is probably not
authorized. It has not published a stronger, more definitive policy authorized. It has not published a stronger, more definitive policy
that results in a "fail". that results in a "fail".
2.6.6. Temperror 2.6.6. Temperror
A "temperror" result means the SPF verifier encountered a transient A "temperror" result means the SPF verifier encountered a transient
(generally DNS) error while performing the check. A later retry may (generally DNS) error while performing the check. A later retry may
succeed without further operator action. succeed without further DNS operator action.
2.6.7. Permerror 2.6.7. Permerror
A "permerror" result means the domain's published records could not A "permerror" result means the domain's published records could not
be correctly interpreted. This signals an error condition that be correctly interpreted. This signals an error condition that
definitely requires operator intervention to be resolved. definitely requires DNS operator intervention to be resolved.
3. SPF Records 3. SPF Records
An SPF record is a DNS record that declares which hosts are, and are 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" not, authorized to use a domain name for the "HELO" and "MAIL FROM"
identities. Loosely, the record partitions hosts into permitted and identities. Loosely, the record partitions hosts into permitted and
not-permitted sets (though some hosts might fall into neither not-permitted sets (though some hosts might fall into neither
category). category).
The SPF record is expressed as a single string of text found in the The SPF record is expressed as a single string of text found in the
skipping to change at page 12, line 49 skipping to change at page 12, line 49
ADMDs publishing SPF records ought to keep the amount of DNS ADMDs publishing SPF records ought to keep the amount of DNS
information needed to evaluate a record to a minimum. Section 4.6.4 information needed to evaluate a record to a minimum. Section 4.6.4
and Section 10.1.1 provide some suggestions about "include" and Section 10.1.1 provide some suggestions about "include"
mechanisms and chained "redirect" modifiers. mechanisms and chained "redirect" modifiers.
3.1. DNS Resource Records 3.1. DNS Resource Records
SPF records MUST be published as a DNS TXT (type 16) Resource Record SPF records MUST be published as a DNS TXT (type 16) Resource Record
(RR) [RFC1035] only. The character content of the record is encoded (RR) [RFC1035] only. The character content of the record is encoded
as [US-ASCII]. Use of alternative DNS RR types was supported in as [US-ASCII]. Use of alternative DNS RR types was supported in
SPF's experimental phase, but has been discontinued. See Appendix A SPF's experimental phase, but has been discontinued.
of [RFC6686] for further information.
In 2003, when SPF was first being developed, the requirements for
assignment of a new DNS RR type were considerably more stringent than
they are now. Additionally, support for easy deployment of new DNS
RR types was not widely deployed in DNS servers and and provisioning
systems. As a result, at that time, there was no reasonable
alternative to using the TXT RR type for SPF records.
In its review of [RFC4408] the SPFbis working group concluded that
its dual RR type transition model was fundamentally flawed since it
contained no common RR type that implementers were required to serve
and required to check. Many alternatives were considered to resolve
this issue, but ultimately the working group concluded that
significant migration to the SPF RR type in the forseable future was
very unlikely and that the best solution for resolving this
interoperability issue was to drop support for the SPF RR type from
SPF version 1. See Appendix A of [RFC6686] for further information.
The circumstances surrounding SPF's initial deploymenta decade ago
are unique and very, very unlikely to be repeated. If a future
update to a new SPF version that could not reuse existing SPF records
were to be developed, it ought to use the SPF RR type. SPF's use of
the TXT RR type for structured data should in no way be taken as
precedent for future protocol designers. Things have changed.
3.2. Multiple DNS Records 3.2. Multiple DNS Records
A domain name MUST NOT have multiple records that would cause an A domain name MUST NOT have multiple records that would cause an
authorization check to select more than one record. See Section 4.5 authorization check to select more than one record. See Section 4.5
for the selection rules. for the selection rules.
3.3. Multiple Strings in a Single DNS record 3.3. Multiple Strings in a Single DNS record
As defined in [RFC1035] sections 3.3 and 3.3.14, a single text DNS As defined in [RFC1035] sections 3.3 and 3.3.14, a single text DNS
skipping to change at page 13, line 38 skipping to change at page 14, line 14
3.4. Record Size 3.4. Record Size
The published SPF record for a given domain name SHOULD remain small The published SPF record for a given domain name SHOULD remain small
enough that the results of a query for it will fit within 512 octets. enough that the results of a query for it will fit within 512 octets.
This UDP limit is defined in [RFC1035] section 2.3.4, although it was This UDP limit is defined in [RFC1035] section 2.3.4, although it was
raised by [RFC2671]. Staying below 512 octets ought to prevent older raised by [RFC2671]. Staying below 512 octets ought to prevent older
DNS implementations from failing over to TCP,and will work with UDP DNS implementations from failing over to TCP,and will work with UDP
in the absence of EDNS0 [RFC6891] support. Since the answer size is in the absence of EDNS0 [RFC6891] support. Since the answer size is
dependent on many things outside the scope of this document, it is dependent on many things outside the scope of this document, it is
only possible to give this guideline: If the combined length of the only possible to give this guideline: If the size of the DNS message,
DNS name and the text of all the records of a given type is under 450 the combined length of the DNS name and the text of all the records
octets, then DNS answers ought to fit in UDP packets. Records that of a given type is under 450 octets, then DNS answers ought to fit in
are too long to fit in a single UDP packet could be silently ignored UDP packets. Records that are too long to fit in a single UDP packet
by SPF verifiers due to firewall and other issues that interfere with could be silently ignored by SPF verifiers due to firewall and other
the operation of DNS over TCP or using ENDS0. issues that interfere with the operation of DNS over TCP or using
ENDS0.
Note that when computing the sizes for replies to queries of the TXT Note that when computing the sizes for replies to queries of the TXT
format, one has to take into account any other TXT records published format, one has to take into account any other TXT records published
at the domain name. Similarly, the sizes for replies to all queries at the domain name. Similarly, the sizes for replies to all queries
related to SPF have to be evaluated to fit in a single 512 octet UDP related to SPF have to be evaluated to fit in a single 512 octet UDP
packet. packet (i.e. DNS message size limited to 450 octects).
3.5. Wildcard Records 3.5. Wildcard Records
Use of wildcard records for publishing is discouraged and care has to Use of wildcard records for publishing is discouraged and care has to
be taken if they are used. If a zone includes wildcard MX records, be taken if they are used. If a zone includes wildcard MX records,
it might want to publish wildcard declarations, subject to the same it might want to publish wildcard declarations, subject to the same
requirements and problems. In particular, the declaration MUST be requirements and problems. In particular, the declaration MUST be
repeated for any host that has any RR records at all, and for repeated for any host that has any RR records at all, and for
subdomains thereof. Consider the example in [RFC1034], Section subdomains thereof. Consider the example in [RFC1034], Section
4.3.3. Based on that, we can do the following: 4.3.3. Based on that, we can do the following:
skipping to change at page 26, line 14 skipping to change at page 27, line 14
MUST support it. MUST support it.
5.6. "ip4" and "ip6" 5.6. "ip4" and "ip6"
These mechanisms test whether <ip> is contained within a given IP These mechanisms test whether <ip> is contained within a given IP
network. network.
ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ] ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ] ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
ip4-cidr-length = "/" 1*DIGIT ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32
ip6-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9 qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99 / %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199 / "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249 / "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255 / "25" %x30-35 ; 250-255
; as per conventional dotted quad notation. e.g., 192.0.2.0 ; as per conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as per [RFC 4291], section 2.2> ip6-network = <as per [RFC 4291], section 2.2>
skipping to change at page 36, line 7 skipping to change at page 37, line 7
%{d2}.trusted-domains.example.net %{d2}.trusted-domains.example.net
example.com.trusted-domains.example.net example.com.trusted-domains.example.net
IPv6: IPv6:
%{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0. %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com
8. Result Handling 8. Result Handling
This section provides guidance for operators in response to the This section provides guidance for SPF verifier operators in response
various possible outputs of check_host() on a message. Definitions to the various possible outputs of check_host() on a message.
of SPF results are presented in Section 2.6; this section provides Definitions of SPF results are presented in Section 2.6; this section
more detail on each for use in developing local policy for message provides more detail on each for use in developing local policy for
handling. message handling.
Every operating environment is different. There are some receivers Every operating environment is different. There are some receivers
for whom strict adherence to SPF is appropriate, and definitive for whom strict adherence to SPF is appropriate, and definitive
treatment of messages that are evaluated to be explicitly treatment of messages that are evaluated to be explicitly
unauthorized ("fail" and sometimes "softfail") is the norm. There unauthorized ("fail" and sometimes "softfail") is the norm. There
are others for which the "false negative" cases are more of a are others for which the "false negative" cases are more of a
concern. This concern is typically handled by merely recording the concern. This concern is typically handled by merely recording the
result in the header and allowing the message to pass on for result in the header and allowing the message to pass on for
additional processing. There are still others where SPF is one of additional processing. There are still others where SPF is one of
several inputs to the message handling decision. As such, there is several inputs to the message handling decision. As such, there is
skipping to change at page 38, line 28 skipping to change at page 39, line 28
software SHOULD use an SMTP reply code of 451 and, if supported, the software SHOULD use an SMTP reply code of 451 and, if supported, the
4.4.3 enhanced status code (see [RFC3463], Section 3.5). These 4.4.3 enhanced status code (see [RFC3463], Section 3.5). These
errors can be caused by problems in either the sender's or receiver's errors can be caused by problems in either the sender's or receiver's
DNS software. See Appendix H.4 for considerations on developing DNS software. See Appendix H.4 for considerations on developing
local policy. local policy.
8.7. Permerror 8.7. Permerror
A "permerror" result means the domain's published records could not A "permerror" result means the domain's published records could not
be correctly interpreted. This signals an error condition that be correctly interpreted. This signals an error condition that
definitely requires operator intervention to be resolved. If the definitely requires DNS operator intervention to be resolved. If the
message is rejected during the SMTP transaction for this reason, the message is rejected during the SMTP transaction for this reason, the
software SHOULD use an SMTP reply code of 550 and, if supported, the software SHOULD use an SMTP reply code of 550 and, if supported, the
5.5.2 enhanced status code (see [RFC3463], Section 3.6). Be aware 5.5.2 enhanced status code (see [RFC3463], Section 3.6). Be aware
that if the ADMD uses macros (Section 7), it is possible that this that if the ADMD uses macros (Section 7), it is possible that this
result is due to the checked identities having an unexpected format. result is due to the checked identities having an unexpected format.
It is also possible that this result is generated by certain SPF It is also possible that this result is generated by certain SPF
verifiers due to the input arguments having an unexpected format; see verifiers due to the input arguments having an unexpected format; see
Section 4.8. See Appendix H.3 for considerations on developing local Section 4.8. See Appendix H.3 for considerations on developing local
policy. policy.
9. Recording the Result 9. Recording the Result
To provide downstream agents, such as MUAs, with the information they To provide downstream agents, such as MUAs, with the information they
might need in terms of evaluating or representing the apparent safety might need in terms of evaluating or representing the apparent safety
of the message content, it is RECOMMENDED that SMTP receivers record of the message content, it is RECOMMENDED that SMTP receivers record
the result of SPF processing in the message header. For operators the result of SPF processing in the message header. For SPF verifier
that choose to record SPF results in the header of the message for operators that choose to record SPF results in the header of the
processing by internal filters or MUAs, two methods are presented. message for processing by internal filters or MUAs, two methods are
Section 9.1 defines the Received-SPF field, which is the results presented. Section 9.1 defines the Received-SPF field, which is the
field originally defined for SPF use. Section 9.2 discusses results field originally defined for SPF use. Section 9.2 discusses
Authentication-Results [RFC5451] which was specified more recently Authentication-Results [RFC5451] which was specified more recently
and is designed for use by SPF and other authentication methods. and is designed for use by SPF and other authentication methods.
Both are in common use, and hence both are included here. However, Both are in common use, and hence both are included here. However,
it is important to note that they were designed to serve slightly it is important to note that they were designed to serve slightly
different purposes. Received-SPF is intended to include enough different purposes. Received-SPF is intended to include enough
information to enable reconstruction of the SPF evaluation of the information to enable reconstruction of the SPF evaluation of the
message, while Authentication-Results is designed only to relay the message, while Authentication-Results is designed only to relay the
result itself and related output details of likely use to end users result itself and related output details of likely use to end users
(e.g., what property of the message was actually authenticated and (e.g., what property of the message was actually authenticated and
what it contained), leaving reconstructive work to the purview of what it contained), leaving reconstructive work to the purview of
system logs and the Received field contents. Also, Received-SPF system logs and the Received field contents. Also, Received-SPF
relies on compliance of agents within the receiving ADMD to adhere to relies on compliance of agents within the receiving ADMD to adhere to
the header field ordering rules of [RFC5321] and [RFC5322], while the header field ordering rules of [RFC5321] and [RFC5322], while
Authentication-Results includes some provisions to protect against Authentication-Results includes some provisions to protect against
non-compliant implementations. non-compliant implementations.
An operator could choose to use both to serve different downstream An SPF verifier operator could choose to use both to serve different
agents. In such cases, care needs to be taken to ensure both fields downstream agents. In such cases, care needs to be taken to ensure
are conveying the same details, or unexpected results can occur. both fields are conveying the same details, or unexpected results can
occur.
9.1. The Received-SPF Header Field 9.1. The Received-SPF Header Field
The Received-SPF header field is a trace field (see [RFC5322] Section 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 3.6.7) and SHOULD be prepended to the existing header, above the
Received: field that is generated by the SMTP receiver. It MUST Received: field that is generated by the SMTP receiver. It MUST
appear above all other Received-SPF fields in the message. The appear above all other Received-SPF fields in the message. The
header field has the following format: header field has the following format:
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
skipping to change at page 56, line 40 skipping to change at page 57, line 40
ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ] ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ] ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
exists = "exists" ":" domain-spec exists = "exists" ":" domain-spec
modifier = redirect / explanation / unknown-modifier modifier = redirect / explanation / unknown-modifier
redirect = "redirect" "=" domain-spec redirect = "redirect" "=" domain-spec
explanation = "exp" "=" domain-spec explanation = "exp" "=" domain-spec
unknown-modifier = name "=" macro-string unknown-modifier = name "=" macro-string
; where name is not any known modifier ; where name is not any known modifier
ip4-cidr-length = "/" 1*DIGIT ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32
ip6-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9 qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99 / %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199 / "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249 / "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255 / "25" %x30-35 ; 250-255
; conventional dotted quad notation. e.g., 192.0.2.0 ; conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as per [RFC 4291], section 2.2> ip6-network = <as per [RFC 4291], section 2.2>
skipping to change at page 69, line 28 skipping to change at page 70, line 28
receiver can do to draw attention to the difficulty encountered while receiver can do to draw attention to the difficulty encountered while
protecting itself from messages that do not have a definite SPF protecting itself from messages that do not have a definite SPF
result of some kind. However, if the SPF implementation is defective result of some kind. However, if the SPF implementation is defective
and returns spurious "permerror" results, only the sender is actively and returns spurious "permerror" results, only the sender is actively
notified of the defect (in the form of rejected mail), and not the notified of the defect (in the form of rejected mail), and not the
receiver making use of SPF. receiver making use of SPF.
The less intrusive handling choice is to deliver the message, perhaps The less intrusive handling choice is to deliver the message, perhaps
with some kind of annotation of the difficulty encountered and/or with some kind of annotation of the difficulty encountered and/or
logging of a similar nature. However, this will not be desirable to logging of a similar nature. However, this will not be desirable to
operators that wish to implement SPF checking as strictly as SPF verifier operators that wish to implement SPF checking as
possible, nor is this sort of passive problem reporting typically strictly as possible, nor is this sort of passive problem reporting
effective. typically effective.
There is of course the option placing this choice in the hands of the There is of course the option placing this choice in the hands of the
operator rather than the implementer since this kind of choice is SPF verifier operator rather than the implementer since this kind of
often a matter of local policy rather than a condition with a choice is often a matter of local policy rather than a condition with
universal solution, but this adds one more piece of complexity to an a universal solution, but this adds one more piece of complexity to
already non-trivial environment. an already non-trivial environment.
Both implementers and operators need to be cautious of all choices Both implementers and SPF verfier operators need to be cautious of
and outcomes when handling SPF results. all choices and outcomes when handling SPF results.
H.4. Policy For SPF Temperror H.4. Policy For SPF Temperror
The "temperror" result (see Section 2.6.6) indicates the SPF The "temperror" result (see Section 2.6.6) indicates the SPF
processing module at the receiver could not retrieve and SPF policy processing module at the receiver could not retrieve and SPF policy
record due to a (probably) transient condition. This gives no true record due to a (probably) transient condition. This gives no true
indication about the authorized use of the data found in the indication about the authorized use of the data found in the
envelope. envelope.
As with all results, implementers have a choice to make regarding As with all results, implementers have a choice to make regarding
skipping to change at page 70, line 23 skipping to change at page 71, line 23
Because of long queue lifetimes, it is possible that mail will be Because of long queue lifetimes, it is possible that mail will be
repeatedly deferred for several days and so any awareness by the repeatedly deferred for several days and so any awareness by the
sender of a problem could be quite delayed. If "temperrors" persist sender of a problem could be quite delayed. If "temperrors" persist
for multiple delivery attempts, it might be preferable to treat the for multiple delivery attempts, it might be preferable to treat the
error as permanent and reduce the amount of time the message is in error as permanent and reduce the amount of time the message is in
transit. transit.
The less intrusive handling choice is to deliver the message, perhaps The less intrusive handling choice is to deliver the message, perhaps
with some kind of annotation of the difficulty encountered and/or with some kind of annotation of the difficulty encountered and/or
logging of a similar nature. However, this will not be desirable to logging of a similar nature. However, this will not be desirable to
operators that wish to implement SPF checking as strictly as SPF verifier operators that wish to implement SPF checking as
possible, nor is this sort of passive problem reporting typically strictly as possible, nor is this sort of passive problem reporting
effective. typically effective.
There is of course the option placing this choice in the hands of the There is of course the option placing this choice in the hands of the
operator rather than the implementer since this kind of choice is SPF verifier operator rather than the implementer since this kind of
often a matter of local policy rather than a condition with a choice is often a matter of local policy rather than a condition with
universal solution, but this adds one more piece of complexity to an a universal solution, but this adds one more piece of complexity to
already non-trivial environment. an already non-trivial environment.
Both implementers and operators need to be cautious of all choices Both implementers and SPF verifier operators need to be cautious of
and outcomes when handling SPF results. all choices and outcomes when handling SPF results.
Appendix I. Protocol Status Appendix I. Protocol Status
NOTE TO RFC EDITOR: To be removed prior to publication. NOTE TO RFC EDITOR: To be removed prior to publication.
SPF has been in development since the summer of 2003 and has seen SPF has been in development since the summer of 2003 and has seen
deployment beyond the developers beginning in December 2003. The deployment beyond the developers beginning in December 2003. The
design of SPF slowly evolved until the spring of 2004 and has since design of SPF slowly evolved until the spring of 2004 and has since
stabilized. There have been quite a number of forms of SPF, some stabilized. There have been quite a number of forms of SPF, some
written up as documents, some submitted as Internet Drafts, and many written up as documents, some submitted as Internet Drafts, and many
 End of changes. 24 change blocks. 
140 lines changed or deleted 165 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--nextPart7749248.bf4gaU6bsf-- From hsantos@isdg.net Wed Sep 11 02:39: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 6F09821E809B for ; Wed, 11 Sep 2013 02:39:41 -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 RIGA5aatoRQE for ; Wed, 11 Sep 2013 02:39:36 -0700 (PDT) Received: from catinthebox.net (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CE1CD11E8111 for ; Wed, 11 Sep 2013 02:39:35 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3970; t=1378892365; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=2/1N/7waIdjIo2q0oGNbJuq1UTo=; b=Rp7SUEev/JXOUHC3XJ2k Rihhfv+7tnzYagNELBUg98DLiUNAQPuk0USaqb/QBfm+PqCKtSCRnYfEPDshPpHW gQj9JgeuC9DvfT1ymF8DvMbPNXdmmfT17ac1x1NGMhJ1MvHTRjqyCyk7HtJiujRn 4ASyzIvvKbC2c+ElC+Qs6fU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 11 Sep 2013 05:39:25 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1059893587.29028.1696; Wed, 11 Sep 2013 05:39:24 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3970; t=1378892017; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=KnuEuBn PvApyjDzy58d2Js02V0RT9ZAWrzqclV22pLE=; b=zYEVwHkgMWxu7sLyJaDCAS8 3qIH/bNSgaXcdP9kkXqtl0lpXQIkO0stxgAdxzwsX1/QqP4J0fQVp6YZHwrIML8k LxgglWc5hZlJ1UgQqirV2A9kw6s3siF/vfIkTi+PCbg53K0VxqSvg9MtO338LUpn cwDqGsl0A0ukHAUvVZkI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 11 Sep 2013 05:33:37 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 506297581.9.5604; Wed, 11 Sep 2013 05:33:36 -0400 Message-ID: <52303A4A.5070303@isdg.net> Date: Wed, 11 Sep 2013 05:39:22 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Scott Kitterman References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130910113052.0c339a60@elandnews.com> <522F7A8F.5060807@gmail.com> <10370218.OEr9JV8dgx@scott-latitude-e6320> In-Reply-To: <10370218.OEr9JV8dgx@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Pete Resnick , S Moonesamy , spfbis@ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, Spencer Dawkins , spfbis-chairs@tools.ietf.org, The IESG Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 09:39:41 -0000 On 9/10/2013 9:38 PM, Scott Kitterman wrote: > > Here's the fixed sentence. I suspect the truth may be less dramatic than you > imagined. I also got a bit more expansive in the last paragraph. I've > attached a revised rfcdiff for the total local diff I'm carrying now. Here's > what I have now: > > 3.1. DNS Resource Records > > SPF records MUST be published as a DNS TXT (type 16) Resource Record > (RR) [RFC1035] only. The character content of the record is encoded > as [US-ASCII]. Use of alternative DNS RR types was supported in > SPF's experimental phase, but has been discontinued. > > In 2003, when SPF was first being developed, the requirements for > assignment of a new DNS RR type were considerably more stringent than > they are now. Additionally, support for easy deployment of new DNS > RR types was not widely deployed in DNS servers and and provisioning > systems. As a result, at that time, there was no reasonable > alternative to using the TXT RR type for SPF records. > > In its review of [RFC4408] the SPFbis working group concluded that > its dual RR type transition model was fundamentally flawed since it > contained no common RR type that implementers were required to serve > and required to check. Many alternatives were considered to resolve > this issue, but ultimately the working group concluded that > significant migration to the SPF RR type in the forseable future was > very unlikely and that the best solution for resolving this > interoperability issue was to drop support for the SPF RR type from > SPF version 1. See Appendix A of [RFC6686] for further information. I would remove the word "fundamentally", fix up or remove the first sentence. The only real reason for lack of support is that DNS servers across the board were not ready for it. Consider: If the DNS servers were ready for it, then this would be a functional description correction not a removal. Consider: If the DNS Servers were ready for it, then the market would of figured out the best query method with minimal overhead, which is SPF first, TXT fallback. Publishers and Receivers would of figured it out and that would of been codified. But its lack of support was 100% related to the market not being ready to handle it. Period, and in my view, any future new RR type proposal will also be in the same position. > The circumstances surrounding SPF's initial deploymenta decade ago > are unique and very, very unlikely to be repeated. I don't think so. All it takes is someone to bring it up, like with DMARC. > If a future > update to a new SPF version that could not reuse existing SPF records > were to be developed, it ought to use the SPF RR type. Not until the DNS servers across the board support it. A future one will most likely use a subdomain TXT format. > SPF's use of > the TXT RR type for structured data should in no way be taken as > precedent for future protocol designers. Things have changed. No it hasn't change. DNS servers do no support them, period. Like it or not, we have to lump Microsoft servers in this support picture. Until MS DNS servers support it, we won't get wide support for this type99 type or any future new RR type proposal. We will be in the same predicament and it will not be practical to explore any new type other than TXT. Just look at DMARC. I extremely doubt a primary new RR type with a TXT fallback will be acceptable here by the key designers of it. So lets be real about this. I like the first paragraph. But the only reason for removal is lack of infrastructure support. Keep it simple. To me, the main lesson learned is that TXT is acceptable for future proposals (with a subdomain zone) and thats really all that is extractable by all this. TYPE99 didn't work for a lack for infrastructure support -- with Microsoft DNS servers included in the lack of support. Its not just a Bind world. -- HLS From sm@elandsys.com Wed Sep 11 05:59: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 326B911E8253; Wed, 11 Sep 2013 05:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 a9UW8UQNrX-D; Wed, 11 Sep 2013 05:59:40 -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 7253D11E8270; Wed, 11 Sep 2013 05:59:00 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.34]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8BCwRdx011603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Sep 2013 05:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378904322; bh=6c8M1Pb8coPDFiMdX6tTGr1V10knoHwQxomW/2hVVX8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dMK2EAp85W7ftJFDXXrjspqiJ1+piZyGkx1bLTtAY1SZ8H6rVWldJQLjSsjkDD8Sm v4bCC0FozlDqDmvmGo+n/VObCYeIE6o7MwECZRQI3IKtNqS8unahDshTT2IC2uzyvZ 3VRwTY2qt23WK53BX0yIsg8RLs7D1ydiokvlH3Jg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378904322; i=@elandsys.com; bh=6c8M1Pb8coPDFiMdX6tTGr1V10knoHwQxomW/2hVVX8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hM8K0qxqiTkHbJ3Z/iKuLxzFle5p+uZwhRX3bck95gb1o6IndUqAypvsVtflhl9Qb zNzvGI3TPquX5Mqvm6GExWgGuwQbCR1/SnI0Bvi1757wfvxTcASdVw3CgLHvcMad/B 6H+7CdQPEjm2ZHm5hCPZq2a621Sr/0hJ4FsVgv0g= Message-Id: <6.2.5.6.2.20130911050206.0dc1ff68@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Sep 2013 05:04:11 -0700 To: Barry Leiba , The IESG , draft-ietf-spfbis-4408bis@tools.ietf.org From: S Moonesamy In-Reply-To: <20130911015837.30196.11175.idtracker@ietfa.amsl.com> References: <20130911015837.30196.11175.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 12:59:42 -0000 Hello, Could the SPFBIS WG please review the following? Thanks, S. Moonesamy (as document shepherd) At 18:58 10-09-2013, Barry Leiba wrote: >Barry Leiba has entered the following ballot position for >draft-ietf-spfbis-4408bis-19: Discuss > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/ > > > >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >I have two very small points that I think are unclear, and important >enough that we have to get them right, both regarding the check_host() >function. These should be really easy to clear up: > >-- Section 4.6 -- > > The check_host() function parses and interprets the SPF record to > find a result for the current test. If there are any syntax errors > anywhere in the record, check_host() returns immediately with the > result "permerror", without further interpretation. > >I think you're trying to say that syntax checking is done before any >evaluation, but you aren't saying it. It matters, because >implementations that make different choices in that regard won't get the >same results from check_host() in all cases, as they're required to. >Maybe this?: > >NEW > The check_host() function parses and interprets the SPF record to > find a result for the current test. The syntax of the record is > validated first, and if there are any syntax errors anywhere in the > record, check_host() returns immediately with the result "permerror", > without further interpretation or evaluation. >END > >-- Section 5.5 -- > >I have to say that I'm not happy about the pseudocode here: what >situation are we in when the pseudocode differs from the text? Which >wins? > >I already see a case where they differ: the new pseudocode says "if more >than 10 sending-domain_names are found, use at most 10", and there's >nothing of the sort in the text. > >Does the working group really think there's enough value in having >pseudocode there that it's worth saying the same thing twice and relying >on them to be truly the same? And is it really worth it for mechanism >that's not recommended for use? > >I strongly suggest making sure that the text says what you want it to, >and removing the pseudocode. > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >I have a bunch of editorial comments that I'd like you to consider. >They're all non-blocking, but I think they'll improve the document, and >I'll be happy to chat about them if you like. > >-- Section 2.5 -- > > Performing the authorization check other than using the MAIL FROM and > client address at the time of the MAIL command during the SMTP > transaction can cause problems, such as the following: (1) It might > be difficult to accurately extract the required information from > potentially deceptive headers; (2) legitimate email might fail > because the sender's policy had since changed. > >I found that to be awkwardly worded and hard to understand. Please >consider this rewrite: > >NEW > The authorization check is performed during the SMTP transaction > at the time of the MAIL command, and uses the MAIL FROM value and > the client IP address. Performing the check at later times or > with other input can cause problems such as the following: > > * It might be difficult to accurately extract the required > information from potentially deceptive headers. > > * Legitimate email might fail the authorization check because > the sender's policy has since changed. >END > >-- Section 2.6 -- > >It would really read best if the subsections were worded to be parallel. >As it stands, subsections 1, 3, 4, 6, and 7 are worded as "result X means >Y", and subsections 2 and 5 are not. Can you re-word 2 and 5 to be >parallel to the others? > >Also, why are "neutral" and "fail" called "explicit statements", but >"pass", for example, is not? > >-- Section 3 -- > > Each SPF record is placed in the DNS tree at the owner name it > pertains to, not a subdomain under it, such as is done with SRV > records [RFC2782]. > >This looks like it's saying that SRV records are placed in subdomains, >and I don't think that's what you mean. Or is it? In any case, it's not >clear (and I know this text is from the original). > >Maybe this (which also avoids the two different "it"s)?: > >NEW > Each SPF record is placed in the DNS tree at the owner name it > pertains to, not in a subdomain under the owner name. This is > similar to how SRV records [RFC2782] are done. >END > > The example in this section might be published via these lines in a > domain zone file: > > example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" > smtp-out.example.com. TXT "v=spf1 a -all" > >What does "smtp-out" have to do with anything? It's not otherwise used, >and it seems to contradict what you say about subdomains in the previous >paragraph. > >-- Section 4 -- > > This description is not an API (Application Program Interface) > definition, > >Two total nits on this: >1. You never use "API" other than here, so there's no need to define it, >and >2. the usual expansion of "API" is application programMING interface. >I suggest, "This description is not an application programming interface >definition, [etc]." > >-- Section 4.5 -- > > Starting with the set of records that were returned by the lookup, > discard records that do not begin with a version section of exactly > "v=spf1". Note that the version section is terminated either by an > SP character or the end of the record. A record with a version > section of "v=spf10" does not match and is discarded. > >Sure, and "v=spf1.0" doesn't match, and "v=spf11" doesn't match, and.... >Why is it necessary or desirable to single out "v=spf10" here? > >-- Section 4.6.4 -- > > SPF implementations MUST limit the total number of mechanisms and > modifiers ("terms") that cause any DNS query to 10 during SPF > evaluation. Specifically, the "include", "a", "mx", "ptr", and > "exists" mechanisms as well as the "redirect" modifier count against > this collective limit. The "all", "ip4", and "ip6" mechanisms do not > count against this limit. If this number is exceeded during a check, > a "permerror" MUST be returned. The "exp" modifier does not count > against this limit because the DNS lookup to fetch the explanation > string occurs after the SPF record evaluation has been completed. > >When I read this, I start feeling like I'm being read the rules for >Fizzbin . I would >appreciate it if this was re-worded so that there are two clear lists >here: the terms that are included in the "limit of 10", and the terms >that are not (and are, presumably, unlimited). Perhaps something like >this: > >NEW > Some mechanisms and modifiers (collectively, "terms") cause DNS > queries at the time of evaluation, and some do not. The following > terms cause DNS queries: . SPF implementations > MUST limit the total number of those terms to 10 during SPF > evaluation, to avoid unreasonable load on the DNS. If this limit > is exceeded, the implementation MUST return "permerror". The other > terms () do not cause DNS queries at the time of > SPF evaluation, and their use is not subject to this limit. >END > >If you think it's necessary (I don't): > >NEW+ > The other > terms () do not cause DNS queries at the time of > SPF evaluation (the "exp" modifier causes a lookup at a later time), > and their use is not subject to this limit. >END > >Then in the next two paragraphs, I think it would improve clarity to make >a change such as this: > >OLD > When evaluating the "mx" mechanism, the number of "MX" resource > records queried is included in the overall limit of 10 mechanisms/ > modifiers that cause DNS lookups described above. The evaluation of > each "MX" record MUST NOT result in querying more than 10 address > records, >NEW > When evaluating the "mx" mechanism, the number of "MX" resource > records queried is included in the overall limit of 10 mechanisms/ > modifiers that cause DNS lookups described above. In addition to > that limit, the evaluation of each "MX" record MUST NOT result in > querying more than 10 address records, >END > >(And similarly for the "ptr" paragraph.) I know you say this in a >paragraph of its own ("These limits are per mechanism..."), but it's >helpful if people can understand things as they read them, and then to >emphasize it later... rather than having them scratch their heads for a >few paragraphs until they get to it. > >-- Section 4.7 -- > > It is better to use either a "redirect" modifier or an "all" > mechanism to explicitly terminate processing. Although the latter > has a default (specifically "?all"), it aids debugging efforts if it > is explicitly provided. > >I'm not sure what "the latter has a default" is trying to say. Do you >mean that "?all" is the default if you fall off the end, but you >shouldn't rely on that? Or do you mean that if you say "all", then >"?all" is taken as the default (I would think "all" would mean "+all")? >Will you try re-wording this, please? > >-- Section 5 -- > >What does "(do not publish)" mean next to "ptr" in the sender mechanisms >list? Ah; I see; it matches the "do not use" in Section 5.5. You should >probably change this to "(do not use; see the note in Section 5.5)". > >It would help, I think, to add to the end of the second paragraph, "The >basic mechanisms are as follows:", and to the end of the third paragraph, >"The designated sender mechanisms are as follows:". Otherwise, there are >just these disembodied lists, and the reader has to infer those >introductions. > >-- Section 5.1 -- > > Mechanisms after "all" will never be tested. Mechanisms listed after > "all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST be > ignored when there is an "all" mechanism in the record. > >This says that the redirect in the following record will be ignored: > > v=spf1 redirect=_spf.example.com +all > >That's sufficiently odd that it should be called out explicitly, perhaps >by adding "regardless of the relative ordering of the terms" to the last >sentence in the quote. > >-- Section 5.2 -- > > 3. The recursive evaluation returns either match, not match, or an > error. If it matches, then the appropriate result for the > include: mechanism is used (e.g. include or +include produces a > "pass" result and -include produces "fail"). > > 4. If there is no match, the parent check_host() resumes processing > as per the table below, with the previous value of > restored. > >A few things here: > >1. Nit: "either" is for two things; for more than two, please remove the >word "either" (or replace it with "one of", but that seems awkward >here). > >2. "If it matches" is not parallel to "returns match", and similarly for >"if there is no match". > >3. You don't say what happens if the recursive evaluation returns an >error. Unfortuately, "no match" and "not match" are sufficiently similar >to be confused. > >I suggest this: > >NEW > 3. The recursive evaluation returns match, not match, or an > error. > > 4. If it returns match, then the appropriate result for the > include: mechanism is used (e.g., include or +include produces > a "pass" result and -include produces "fail"). > > 5. If it returns not match or an error, the parent check_host() > resumes processing as per the table below, with the previous > value of restored. >END > > The "include" mechanism is intended for crossing administrative > boundaries. For example, if example.com and example.org were managed > by the same entity, and if the permitted set of hosts for both > domains was "mx:example.com", it would be possible for example.org to > specify "include:example.com", but it would be preferable to specify > "redirect=example.com" or even "mx:example.com". > >The text you eliminated here provided a buffer that's no longer there, >making the "For example," very odd. You talk about crossing admin >boundaries and immediately follow it with an example that does NOT. I >think it would be better to put a sentence in to restore that buffer -- >perhaps, "When remaining within one administrative authority, "include" >is usually not the best choice." > >-- Section 5.5 -- > > This mechanism SHOULD NOT be published. See below for discussion. > >It's quite a bit below. I suggest "See the note at the end of this >section for more information." It might even be worth putting that note >into a Section 5.5.1, so it's highlighted and more easily cited. > >-- Section 6 -- > > Unrecognized modifiers MUST be ignored no matter where in a record, > or how often. > >This is missing a couple of words: > >NEW > Unrecognized modifiers MUST be ignored no matter where in a record > they appear, or how often. >END > > For clarity, any "redirect" modifier SHOULD appear as the very last > term in a record. > >I don't usually recommend repeating things, but one thing from earlier >probably does bear repeating here: > >NEW > For clarity, any "redirect" modifier SHOULD appear as the very last > term in a record. Any "redirect" modifier MUST be ignored if there > is an "all" mechanism anywhere in the record. >END From sm@elandsys.com Wed Sep 11 06:23: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 CAA7311E81A0; Wed, 11 Sep 2013 06:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 grwWIslAHgv4; Wed, 11 Sep 2013 06:23:45 -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 EA52B11E8117; Wed, 11 Sep 2013 06:23:43 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.34]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8BDNQKV021962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Sep 2013 06:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378905820; bh=1BG+P+6sD+YJV3Lg0C6TOIXT80Wd9LP7kiYBEpHIh6U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=G2Nx/i3X0KzKz09wCPOFKCaBwgBcROZifapTi4/7xg0+sCF19N+/PYeP0y4zoRJH4 0Ci2cAp3btFCqtEhXsS9JESjoKuLqqEY29C63MB225Z3JxeZuWAbsqg4tymtW24ctT +d9jaQDWBmCDDVdW7a32Jf8f6JIB+0m3qDiQhz7s= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378905820; i=@elandsys.com; bh=1BG+P+6sD+YJV3Lg0C6TOIXT80Wd9LP7kiYBEpHIh6U=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=GJCChcv8bhGvYyGQFIoHpXgRQJbtOSolEu6IKjP3IVJ82qWMmqZFb82DnCHGJE1UF ZaM3sZHIYvKuSPkGf8Hv9NLZRT8EYqskos8ZsPhKEz9N+JFis4NRqFfGx/J94DSHFD XtBbaKZgSqxpXzaxowWczMhaN99tH2it5WbwTDf8= Message-Id: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Sep 2013 06:22:32 -0700 To: Phillip Hallam-Baker , draft-ietf-spfbis-4408bis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 11 Sep 2013 13:23:45 -0000 Hi Phillip, I am responding to the comment about DKIM only and wait for the SPFBIS WG to address the other issues. At 05:07 11-09-2013, Phillip Hallam-Baker wrote: >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the >IESG. Document editors and WG chairs should treat these comments just >like any other last call comments. > >The document has been produced as part of a proposal to upgrade SPF >to standards track recognizing the state of deployment experience. > >Minor issues. > >1.1.3. MAIL FROM Definition > >I found this section completely opaque and very confusing. It should >not be necessary to hunt through other specs to find a definition. >Particularly since the referenced specs do not give an explicit >definition for the term as used and the references point to the >whole spec rather than a particular section. I am commenting on the following paragraph only: >The Security Considerations section is adequate for the purpose >except that no mention is made anywhere in the specification about >DKIM and how a mail receiver should interpret presence of DKIM and >SPF policy at the same time. This is a legitimate concern since DKIM >is already a standards track proposal and SPF is only now being >promoted to Standards Track. Thus the SPF document should address >the question of dual use. There was a BoF at the last IETF meeting to discuss proposals about how to interpret the presence of DKIM and/or SPF policy at the same time ( http://www.ietf.org/proceedings/87/minutes/minutes-87-dmarc ). The dual use can be addressed as part of the DMARC effort. >8.7. Permerror > >" > >This signals an error condition that > > definitely requires operator intervention to be resolved." > >I cannot imagine a circumstance which definitely requires a human to >be involved in mail delivery. > > >11.2. SPF-Authorized Email May Contain Other False Identities > > Do not construe the "MAIL FROM" and "HELO" identity authorizations to > provide more assurance than they do. > >Document has quasi normative language that should be worded as >statements of fact rather than as direction. > >-- >Website: http://hallambaker.com/ From superuser@gmail.com Wed Sep 11 06:40: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 997C911E816D; Wed, 11 Sep 2013 06:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 HYNAkSuIHDMR; Wed, 11 Sep 2013 06:40:00 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4463D11E8171; Wed, 11 Sep 2013 06:39:59 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q59so7857155wes.6 for ; Wed, 11 Sep 2013 06:39: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=HZj/UI5a8gBi9lDv0kst9WwlmuowydkBqQQjwkaw/Ss=; b=zhfbH14CR9D0OnROC/KpxL2OzOU80vNPOdOt9r/Qhfx2H9tKgKbfdwhe/cKBuZhFU4 5vkXuD1CHsflwNqpyG0ODhY7VVzaJ3jg1GtRETcI16/RKzru3mCdYd3tBQpSvFnVmTm2 r5Yh/EJBXzYU3ewurrYmzjcICQGgiZSf3zc7gx+8fors4lp0ddqch3ZjZOM65H2QKzAA 6+87/xYNo8JG/2IAATYW/e6XbBIBCqip1kqV05XN7JknVI5FHTwf6C8SEOkAfx0S4jno ot+f8x9rmJnzlpx71e5Ia+G57N0DOy982yoCYiozYIeYwBEtnKwX3zWGh5OOowqup+9E qM6g== MIME-Version: 1.0 X-Received: by 10.180.189.132 with SMTP id gi4mr17603789wic.19.1378906798442; Wed, 11 Sep 2013 06:39:58 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Wed, 11 Sep 2013 06:39:58 -0700 (PDT) In-Reply-To: <10370218.OEr9JV8dgx@scott-latitude-e6320> References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130910113052.0c339a60@elandnews.com> <522F7A8F.5060807@gmail.com> <10370218.OEr9JV8dgx@scott-latitude-e6320> Date: Wed, 11 Sep 2013 06:39:58 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a11c35294e650c904e61bc1e5 Cc: Pete Resnick , S Moonesamy , "spfbis@ietf.org" , draft-ietf-spfbis-4408bis@tools.ietf.org, Spencer Dawkins , spfbis-chairs@tools.ietf.org, The IESG Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 13:40:01 -0000 --001a11c35294e650c904e61bc1e5 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 10, 2013 at 6:38 PM, Scott Kitterman wrote: > 3.1. DNS Resource Records > > SPF records MUST be published as a DNS TXT (type 16) Resource Record > (RR) [RFC1035] only. The character content of the record is encoded > as [US-ASCII]. Use of alternative DNS RR types was supported in > SPF's experimental phase, but has been discontinued. > > In 2003, when SPF was first being developed, the requirements for > assignment of a new DNS RR type were considerably more stringent than > they are now. Additionally, support for easy deployment of new DNS > RR types was not widely deployed in DNS servers and and provisioning > Drop one of those "and"s. I don't care which one. > systems. As a result, at that time, there was no reasonable > alternative to using the TXT RR type for SPF records. > > In its review of [RFC4408] the SPFbis working group concluded that > its dual RR type transition model was fundamentally flawed since it > contained no common RR type that implementers were required to serve > and required to check. Many alternatives were considered to resolve > this issue, but ultimately the working group concluded that > significant migration to the SPF RR type in the forseable future was > "foreseeable" > very unlikely and that the best solution for resolving this > interoperability issue was to drop support for the SPF RR type from > SPF version 1. See Appendix A of [RFC6686] for further information. > > The circumstances surrounding SPF's initial deploymenta decade ago > "deployment a" > are unique and very, very unlikely to be repeated. If a future > update to a new SPF version that could not reuse existing SPF records > were to be developed, it ought to use the SPF RR type. SPF's use of > the TXT RR type for structured data should in no way be taken as > precedent for future protocol designers. Things have changed. > What about "SPF's use of the TXT RR type located at the domain apex"? As I understand it, part of the complaint is the location of the record, not just its type. The underscore mechanism used by DKIM, DMARC, ADSP, VBR, etc. seems to be gaining acceptance, or at least tolerance, because it avoids query collisions. Otherwise, looks okay to me. -MSK --001a11c35294e650c904e61bc1e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 10, 2013 at 6:38 PM, Scott Kitterman <spf2@k= itterman.com> wrote:
3.1. =A0DNS Resource Records

=A0 =A0SPF records MUST be published as a DNS TXT (type 16) Resource Record=
=A0 =A0(RR) [RFC1035] only. =A0The character content of the record is encod= ed
=A0 =A0as [US-ASCII]. =A0Use of alternative DNS RR types was supported in
=A0 =A0SPF's experimental phase, but has been d= iscontinued.

=A0 =A0In 2003, when SPF was first being developed, the requirements for =A0 =A0assignment of a new DNS RR type were considerably more stringent tha= n
=A0 =A0they are now. =A0Additionally, support for easy deployment of new DN= S
=A0 =A0RR types was not widely deployed in DNS servers and and provisioning=

Drop one of those "and"= ;s.=A0 I don't care which one.
=A0
=A0 =A0systems. =A0As a result, at that time, there was no reasonable
=A0 =A0alternative to using the TXT RR type for SPF records.

=A0 =A0In its review of [RFC4408] the SPFbis working group concluded that =A0 =A0its dual RR type transition model was fundamentally flawed since it<= br> =A0 =A0contained no common RR type that implementers were required to serve=
=A0 =A0and required to check. =A0Many alternatives were considered to= resolve
=A0 =A0this issue, but ultimately the working group concl= uded that
=A0 =A0significant migration to the SPF RR type in the forseable futu= re was

"foreseeable"
=A0
=A0 =A0very unlikely and that the best solution for resolving this
=A0 =A0interoperability issue was to drop support for the= SPF RR type from
=A0 =A0SPF version 1. =A0See Appendix A of [RFC6686= ] for further information.

=A0 =A0The circumstances surrounding SPF's initial deploymenta decade a= go

"deployment a"
= =A0
=A0 =A0are unique and very, very unlikely to be repeated. =A0If a fut= ure
=A0 =A0update to a new SPF version that could not reuse existing SPF record= s
=A0 =A0were to be developed, it ought to use the SPF RR type. =A0SPF's = use of
=A0 =A0the TXT RR type for structured data should in no w= ay be taken as
=A0 =A0precedent for future protocol designers. =A0Things have changed.
=

What about "SPF's use of th= e TXT RR type located at the domain apex"?=A0 As I understand it, part= of the complaint is the location of the record, not just its type.=A0 The = underscore mechanism used by DKIM, DMARC, ADSP, VBR, etc. seems to be gaini= ng acceptance, or at least tolerance, because it avoids query collisions.
Otherwise, looks okay to me.

-MSK
--001a11c35294e650c904e61bc1e5-- From superuser@gmail.com Wed Sep 11 06:43: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 A74EE11E8171; Wed, 11 Sep 2013 06:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 KKE8144ORBzo; Wed, 11 Sep 2013 06:43:56 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3F36011E816D; Wed, 11 Sep 2013 06:43:55 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id a12so1880695wgh.2 for ; Wed, 11 Sep 2013 06:43: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=prERtaDMDdfMWqzcemXLy+KUBa2T0SgelMKfJ6xkY9I=; b=POiAlkwzK6xfbQB1XYQAz9/vBxUD9pBrvSCdr0cx9Vqx531i5J6J1KM3GiM3G0oERx MXeEwz1g2IfwZ1SF74+gQLSh8/GFnaDNGUwOiq8LhUlRiGazvkKRfFXSyKJ0UdOty35k 8CjCllve9ysglma9wBsmOJJQga8FG9BekDOpHidpfW1mzL2NeFYYdg/6zdgMjxh8Jur9 tpxyZjG/KIqqThPBdEir886a2Djd93YGHT4A7bT2ErdHsoYt0CuMeqcY/eAQMcC0qmBK PwIate4xuv40kxF5JhWhID4lAxxo5x1pr5NQcTCdgOBSgQr9+3dvsoy/wuuv3W5OJ/v8 lExQ== MIME-Version: 1.0 X-Received: by 10.194.23.196 with SMTP id o4mr1617606wjf.62.1378907034388; Wed, 11 Sep 2013 06:43:54 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Wed, 11 Sep 2013 06:43:54 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> References: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> Date: Wed, 11 Sep 2013 06:43:54 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=047d7b5d9c6bf6907e04e61bcfd2 Cc: "spfbis@ietf.org" , draft-ietf-spfbis-4408bis.all@tools.ietf.org, Phillip Hallam-Baker , The IESG , "secdir@ietf.org" Subject: Re: [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 11 Sep 2013 13:43:56 -0000 --047d7b5d9c6bf6907e04e61bcfd2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 11, 2013 at 6:22 AM, S Moonesamy wrote: > I am responding to the comment about DKIM only and wait for the SPFBIS WG > to address the other issues. > Was the SecDir review for this draft posted to the spfbis list? I haven't seen it. > > The Security Considerations section is adequate for the purpose except >> that no mention is made anywhere in the specification about DKIM and how a >> mail receiver should interpret presence of DKIM and SPF policy at the same >> time. This is a legitimate concern since DKIM is already a standards track >> proposal and SPF is only now being promoted to Standards Track. Thus the >> SPF document should address the question of dual use. >> > > There was a BoF at the last IETF meeting to discuss proposals about how to > interpret the presence of DKIM and/or SPF policy at the same time ( > http://www.ietf.org/**proceedings/87/minutes/**minutes-87-dmarc). The dual use can be addressed as part of the DMARC effort. > DKIM has no intrinsic policy component. Are we actually talking about ADSP here? Assuming we are, I think the best we could do is to note that it's possible for ADSP and SPF to yield conflicting policy results; one could be a "pass" while the other could be a "fail", meaning the receiving MTA now has one "reject" instruction and one "accept" instruction. The receiving ADMD will have to make a decision about which one ought to get precedence. -MSK --047d7b5d9c6bf6907e04e61bcfd2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 11, 2013 at 6:22 AM, S Moonesamy <sm+ietf@= elandsys.com> wrote:
I am responding to the comment about DKIM on= ly and wait for the SPFBIS WG to address the other issues.

Was the SecDir review for this draft posted to the spfb= is list?=A0 I haven't seen it.
=A0

The Security Considerations section is adequate for the purpose except that= no mention is made anywhere in the specification about DKIM and how a mail= receiver should interpret presence of DKIM and SPF policy at the same time= . This is a legitimate concern since DKIM is already a standards track prop= osal and SPF is only now being promoted to Standards Track. Thus the SPF do= cument should address the question of dual use.

There was a BoF at the last IETF meeting to discuss proposals about how to = interpret the presence of DKIM and/or SPF policy at the same time ( http://www.ietf.org/proceedings/87/minutes/minutes-87= -dmarc ). =A0The dual use can be addressed as part of the DMARC effort.=

DKIM has no intrinsic policy component. = =A0 Are we actually talking about ADSP here?

Assuming we = are, I think the best we could do is to note that it's possible for ADS= P and SPF to yield conflicting policy results; one could be a "pass&qu= ot; while the other could be a "fail", meaning the receiving MTA = now has one "reject" instruction and one "accept" instr= uction.=A0 The receiving ADMD will have to make a decision about which one = ought to get precedence.

-MSK
--047d7b5d9c6bf6907e04e61bcfd2-- From sm@elandsys.com Wed Sep 11 06: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 B16AB11E826D for ; Wed, 11 Sep 2013 06:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 nFmHcAptKczg for ; Wed, 11 Sep 2013 06:53:15 -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 E408911E824C for ; Wed, 11 Sep 2013 06:53:14 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.34]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8BDqwxP012897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Sep 2013 06:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378907590; bh=xAAVui2kPHs4Pt0jl8LDqgMB4tN5JiRlwWzIs0HLvtU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wzIDqotHPhMpFRO7UoK6neEAV+DApq1ZXezLGuoK490Ma2OHKJmbzLt4z15bGTjuz ZnT7azFwgc3LFcKB7zUFvVFDiQm8nMz1qkRrP/xtUvI4thiWdU/XuRqvQfnr7L+oWl NfEXSDDvte8f5UlSD6PJJ1cvBBRbbILFrNPF6BRo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378907590; i=@elandsys.com; bh=xAAVui2kPHs4Pt0jl8LDqgMB4tN5JiRlwWzIs0HLvtU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=gwB8hg75mqs72Q3ZmR6r0f9N/1zArUMrn/G8wUL2mAcTBZPcdU2DGmxdh70xARaAw vVNBJQVcllnt6qSL2OLOu027Qi2PvsEcE2cwJ/9aksejEQOpwjPdlXTCNXgrcb4IhG NpHrL4ISmxY1UMXxRfsUEQwPadpknRowToCtD/mI= Message-Id: <6.2.5.6.2.20130911064538.0bb48e10@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Sep 2013 06:52:26 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Phillip Hallam-Baker Subject: Re: [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 11 Sep 2013 13:53:16 -0000 Hi Murray, At 06:43 11-09-2013, Murray S. Kucherawy wrote: >Was the SecDir review for this draft posted to the spfbis list? I >haven't seen it. The entire SecDir review is in the reply I posted a few minutes ago (SECDIR in the subject line). Regards, S. Moonesamy From superuser@gmail.com Wed Sep 11 07:08: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 9AEA321E8117; Wed, 11 Sep 2013 07:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 BW-Tga9OI9lx; Wed, 11 Sep 2013 07:08:07 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 73FFC21E8115; Wed, 11 Sep 2013 07:07:44 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id b12so6951720wgh.35 for ; Wed, 11 Sep 2013 07:07:33 -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=1UNXUw/fhSE3AKNz6lr9kgSJ0fm72PWelo4ayKn0Iso=; b=SsmvnkDeDcGXoEeoIavQamAsbeedRlnGTiFWDHfxQ1pNHZm0WZTCYFfQ9Hkps4qQjg 04HIfqhD1341aIAMLqACOlmsvu2BPCnpDXRy2HQkm5vRIQqVIyzUKF+GddXwgwKi9bPA CS4QZ7x+USajJBSQcvTEGhScAo/B1jo9tVeQiqJAzArbn74JDQExzXczCNxLQ7y3eQpA GaBXEi4tq4TrK43ae8fLOkDxBW3mZve66D5se3ut0UkValLmlHxphw3ImvkKMmH2F74c dA1K34KWYPf6ZlUm+Ci5dc9XyyHMVn+ShVOYwH2P8BD/1c4wOjSkatrYILfoSDs62uM6 etEw== MIME-Version: 1.0 X-Received: by 10.194.23.73 with SMTP id k9mr1828819wjf.24.1378908453222; Wed, 11 Sep 2013 07:07:33 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Wed, 11 Sep 2013 07:07:33 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130911050206.0dc1ff68@elandnews.com> References: <20130911015837.30196.11175.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130911050206.0dc1ff68@elandnews.com> Date: Wed, 11 Sep 2013 07:07:33 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=047d7b5d439688418304e61c24a1 Cc: "spfbis@ietf.org" , spfbis-chairs@tools.ietf.org, Barry Leiba , draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG Subject: Re: [spfbis] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 14:08:07 -0000 --047d7b5d439688418304e61c24a1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 11, 2013 at 5:04 AM, S Moonesamy wrote: > > >> ------------------------------**------------------------------** >> ---------- >> DISCUSS: >> ------------------------------**------------------------------** >> ---------- >> >> I have two very small points that I think are unclear, and important >> enough that we have to get them right, both regarding the check_host() >> function. These should be really easy to clear up: >> >> -- Section 4.6 -- >> >> The check_host() function parses and interprets the SPF record to >> find a result for the current test. If there are any syntax errors >> anywhere in the record, check_host() returns immediately with the >> result "permerror", without further interpretation. >> >> I think you're trying to say that syntax checking is done before any >> evaluation, but you aren't saying it. It matters, because >> implementations that make different choices in that regard won't get the >> same results from check_host() in all cases, as they're required to. >> Maybe this?: >> >> NEW >> The check_host() function parses and interprets the SPF record to >> find a result for the current test. The syntax of the record is >> validated first, and if there are any syntax errors anywhere in the >> record, check_host() returns immediately with the result "permerror", >> without further interpretation or evaluation. >> END >> > Yep. > >> -- Section 5.5 -- >> >> I have to say that I'm not happy about the pseudocode here: what >> situation are we in when the pseudocode differs from the text? Which >> wins? >> >> I already see a case where they differ: the new pseudocode says "if more >> than 10 sending-domain_names are found, use at most 10", and there's >> nothing of the sort in the text. >> >> Does the working group really think there's enough value in having >> pseudocode there that it's worth saying the same thing twice and relying >> on them to be truly the same? And is it really worth it for mechanism >> that's not recommended for use? >> >> I strongly suggest making sure that the text says what you want it to, >> and removing the pseudocode. >> > I've written drafts (e.g., RFC5451) that contain prose and an algorithm description for the same thing, so it's possible to get this right. I'm not sure it's necessary here, so I agree we should consider dumping it. Will review the comment stuff later today. -MSK --047d7b5d439688418304e61c24a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 11, 2013 at 5:04 AM, S Moonesamy <sm+ietf@= elandsys.com> wrote:


-------------------------------------------------------------= ---------
DISCUSS:
-------------------------------------------------------------= ---------

I have two very small points that I think are unclear, and important
enough that we have to get them right, both regarding the check_host()
function. =A0These should be really easy to clear up:

-- Section 4.6 --

=A0 =A0The check_host() function parses and interprets the SPF record to =A0 =A0find a result for the current test. =A0If there are any syntax error= s
=A0 =A0anywhere in the record, check_host() returns immediately with the =A0 =A0result "permerror", without further interpretation.

I think you're trying to say that syntax checking is done before any evaluation, but you aren't saying it. =A0It matters, because
implementations that make different choices in that regard won't get th= e
same results from check_host() in all cases, as they're required to. Maybe this?:

NEW
=A0 =A0The check_host() function parses and interprets the SPF record to =A0 =A0find a result for the current test. =A0The syntax of the record is =A0 =A0validated first, and if there are any syntax errors anywhere in the<= br> =A0 =A0record, check_host() returns immediately with the result "perme= rror",
=A0 =A0without further interpretation or evaluation.
END

Yep.
=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

-- Section 5.5 --

I have to say that I'm not happy about the pseudocode here: what
situation are we in when the pseudocode differs from the text? =A0Which
wins?

I already see a case where they differ: the new pseudocode says "if mo= re
than 10 sending-domain_names are found, use at most 10", and there'= ;s
nothing of the sort in the text.

Does the working group really think there's enough value in having
pseudocode there that it's worth saying the same thing twice and relyin= g
on them to be truly the same? =A0And is it really worth it for mechanism that's not recommended for use?

I strongly suggest making sure that the text says what you want it to,
and removing the pseudocode.

I&= #39;ve written drafts (e.g., RFC5451) that contain prose and an algorithm d= escription for the same thing, so it's possible to get this right.=A0 I= 'm not sure it's necessary here, so I agree we should consider dump= ing it.

Will review the comment stuff later today.

-MSK
<= /div> --047d7b5d439688418304e61c24a1-- From superuser@gmail.com Wed Sep 11 07:08:30 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 3EC1821E80E5 for ; Wed, 11 Sep 2013 07:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 vWXgQn6Jp3lP for ; Wed, 11 Sep 2013 07:08:29 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 33A3321E808F for ; Wed, 11 Sep 2013 07:08:29 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id t60so6712307wes.8 for ; Wed, 11 Sep 2013 07:08:28 -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=d7N2W7DibmQ9TOHelYFZk7iCNsuhZiKt6UPaRBO5zSU=; b=fTdOgQD0Yx2XcMBHWc8wLq8xpdr6xY1fD8qbiOd6fzDLKaFelfM/s9JoYjE1cYwUdL MHgEPrziLwQWrbiSodFEJqFO6VGrcZvoO/aF/lCvkOif3Zfbp8cRmsem5GWsW5fDwoIr kaKbSA5x0nKGEjELLP8Rf/cednQVIzDg6qDd4LnvfRG1FqFpMSjSEyE/nptnnallOEr7 xoEubgDMdxrLiZQf+ixEQX4mi3zIoQOWwAG4oWeM9WYS8/RCrVsNQ7G31rPrKNe8nne/ RRL6fwBhuKLYqxMASYTeoXvnyA8/m1S5EpnG7NYaNDJ6UKrm5HokyMp4QW/dfxK/hL05 czbA== MIME-Version: 1.0 X-Received: by 10.180.189.132 with SMTP id gi4mr17718478wic.19.1378908508279; Wed, 11 Sep 2013 07:08:28 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Wed, 11 Sep 2013 07:08:28 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130911064538.0bb48e10@elandnews.com> References: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> <6.2.5.6.2.20130911064538.0bb48e10@elandnews.com> Date: Wed, 11 Sep 2013 07:08:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=001a11c35294d0598504e61c2747 Cc: "spfbis@ietf.org" , Phillip Hallam-Baker Subject: Re: [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 11 Sep 2013 14:08:30 -0000 --001a11c35294d0598504e61c2747 Content-Type: text/plain; charset=ISO-8859-1 Ah, sorry. My MUA cut it off and wasn't caffeinated enough to notice. On Wed, Sep 11, 2013 at 6:52 AM, S Moonesamy wrote: > Hi Murray, > > At 06:43 11-09-2013, Murray S. Kucherawy wrote: > >> Was the SecDir review for this draft posted to the spfbis list? I >> haven't seen it. >> > > The entire SecDir review is in the reply I posted a few minutes ago > (SECDIR in the subject line). > > Regards, > S. Moonesamy > --001a11c35294d0598504e61c2747 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ah, sorry.=A0 My MUA cut it off and wasn't caffeinated= enough to notice.


On Wed, Sep 11, 2013 at 6:52 AM, S Moonesamy <sm+ietf@= elandsys.com> wrote:
Hi Murray,

At 06:43 11-09-2013, Murray S. Kucherawy wrote:
Was the SecDir review for this draft posted to the spfbis list? =A0I haven&= #39;t seen it.

The entire SecDir review is in the reply I posted a few minutes ago (SECDIR= in the subject line).

Regards,
S. Moonesamy

--001a11c35294d0598504e61c2747-- From dotzero@gmail.com Wed Sep 11 07:43: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 3E60121E811B; Wed, 11 Sep 2013 07:43:34 -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 d4tMI+FgMre6; Wed, 11 Sep 2013 07:43:33 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id E008421E80B1; Wed, 11 Sep 2013 07:43:32 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id ev20so7299535lab.8 for ; Wed, 11 Sep 2013 07:43:31 -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=oQa+aiAN9WOxBEq8tB45uXMraS7w9sEwPffFK0PAPtU=; b=gzZFxCfxw50aD0c+fRKoPmePUJMKo0OAq1pmPKahIzV6WpzlnXPWYEo1lr3JzYites 2HylnTIbwrnnbkwLLQOhyIZIJfd3FAVci2Otybg37tAIb9eLDT6VgFZ2BwRoNze8T/TR MGh3tuZlOvNVjDSOEV5MUhPrUsSZ8Aj75ACv6MEUFZwhin38v7dQiOw78VEYkXzTUU0b AH/VnH4XR4VyRGpPQXHGwqPQog5IN3Ejcy9yyoaD21f5xEJ87/66V2NWQ3NzJIGLNznO TUv7aiG2iZSg+SsjKt07lA9hbP7lRJ15rtOc3tooaPkBLl9Hfl7f+ME53RgSeDbwqRnY B8oA== MIME-Version: 1.0 X-Received: by 10.112.11.20 with SMTP id m20mr17320lbb.56.1378910611771; Wed, 11 Sep 2013 07:43:31 -0700 (PDT) Received: by 10.112.137.163 with HTTP; Wed, 11 Sep 2013 07:43:31 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> Date: Wed, 11 Sep 2013 10:43:31 -0400 Message-ID: From: Dotzero To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "secdir@ietf.org" , S Moonesamy , "spfbis@ietf.org" , The IESG , draft-ietf-spfbis-4408bis.all@tools.ietf.org, Phillip Hallam-Baker Subject: Re: [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 11 Sep 2013 14:43:34 -0000 On Wed, Sep 11, 2013 at 9:43 AM, Murray S. Kucherawy wrote: > On Wed, Sep 11, 2013 at 6:22 AM, S Moonesamy wrote: >> >> I am responding to the comment about DKIM only and wait for the SPFBIS WG >> to address the other issues. > > > Was the SecDir review for this draft posted to the spfbis list? I haven't > seen it. > >> >> >>> The Security Considerations section is adequate for the purpose except >>> that no mention is made anywhere in the specification about DKIM and how a >>> mail receiver should interpret presence of DKIM and SPF policy at the same >>> time. This is a legitimate concern since DKIM is already a standards track >>> proposal and SPF is only now being promoted to Standards Track. Thus the SPF >>> document should address the question of dual use. >> >> >> There was a BoF at the last IETF meeting to discuss proposals about how to >> interpret the presence of DKIM and/or SPF policy at the same time ( >> http://www.ietf.org/proceedings/87/minutes/minutes-87-dmarc ). The dual use >> can be addressed as part of the DMARC effort. > > > DKIM has no intrinsic policy component. Are we actually talking about ADSP > here? > > Assuming we are, I think the best we could do is to note that it's possible > for ADSP and SPF to yield conflicting policy results; one could be a "pass" > while the other could be a "fail", meaning the receiving MTA now has one > "reject" instruction and one "accept" instruction. The receiving ADMD will > have to make a decision about which one ought to get precedence. > > ADSP should be relegated to historical. Very little implementation on the publishing side and even less validation on the receiving side. We (all of the usual suspects in this space) made compromises to get it out the door and we collectively got it wrong. Having said that, I could live with some kind of note in the SPFbis doc along the lines of what Murray suggests. Mike From dhc@dcrocker.net Wed Sep 11 07:51:40 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 D715621E80B6; Wed, 11 Sep 2013 07:51:40 -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 7L+pAmVMZyHg; Wed, 11 Sep 2013 07:51:36 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6F521F9EE9; Wed, 11 Sep 2013 07:51:36 -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 r8BEpJeo018418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Sep 2013 07:51:22 -0700 Message-ID: <52308352.2060902@dcrocker.net> Date: Wed, 11 Sep 2013 07:50:58 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> In-Reply-To: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> 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, 11 Sep 2013 07:51:22 -0700 (PDT) Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, Phillip Hallam-Baker , iesg@ietf.org, secdir@ietf.org Subject: Re: [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 11 Sep 2013 14:51:41 -0000 On 9/11/2013 6:22 AM, S Moonesamy wrote: > I am commenting on the following paragraph only: > >> The Security Considerations section is adequate for the purpose except >> that no mention is made anywhere in the specification about DKIM and >> how a mail receiver should interpret presence of DKIM and SPF policy >> at the same time. This is a legitimate concern since DKIM is already a >> standards track proposal and SPF is only now being promoted to >> Standards Track. Thus the SPF document should address the question of >> dual use. > > There was a BoF at the last IETF meeting to discuss proposals about how > to interpret the presence of DKIM and/or SPF policy at the same time ( > http://www.ietf.org/proceedings/87/minutes/minutes-87-dmarc ). The dual > use can be addressed as part of the DMARC effort. At the level of a fully-integrated email anti-abuse system, concern about possible SPF and DKIM presence and interaction effects is, of course, essential. However SPF is only a component technology. It's specification is not the place for discussing higher-level interaction effects. By way of example, imagine the specification for an automobile tire being expected to talk about design and operations issues when the tire is linked to 3 siblings and a suspension system, and a motor and... That's an important topic, but the tire spec is wrong venue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From barryleiba@gmail.com Wed Sep 11 08:08: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 6EAB211E8181; Wed, 11 Sep 2013 08:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.017 X-Spam-Level: X-Spam-Status: No, score=-102.017 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 ZW3EEDK7NVmI; Wed, 11 Sep 2013 08:08:09 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B900F21E80B1; Wed, 11 Sep 2013 08:08:03 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id eo20so7713310lab.3 for ; Wed, 11 Sep 2013 08:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yF3mqAXWnqw/HrFKWT3Mw6nEdVkWzBgZGXC7bbJVGpA=; b=hnsEINM8hhuMgDzQ4XNk984hu3jEh7GiVFbMtpmbgCQ/IUZxJSHqFVqUDhomxNkmWo oQdvqd5dknjkLFfLvrnu2Gvfj1SwD6OPNTcc9S/0W29XykO5VljthREA/2taCnatholg tilNsr2P7KS/2DBSHXzkes9+eXcPMPF6JfMTXOCNl59dkJU2yGyn/M70yL9HHhdOqsUb m/iztjiNIW/AgEIkD7LNZmt/w6qQ2kcyh+dvwNKCNQIef8f8DM3dzIZ6b1pAQFMW5wOE 1WnP1TwsiXTQczdFJ7EIRgHEu5w+6M31kM30S6frHu+RupIBMVQEm3BVrFTLfaP7vMTl VHPQ== MIME-Version: 1.0 X-Received: by 10.112.158.225 with SMTP id wx1mr1947339lbb.37.1378912082006; Wed, 11 Sep 2013 08:08:02 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.112.130.39 with HTTP; Wed, 11 Sep 2013 08:08:01 -0700 (PDT) In-Reply-To: References: <20130911015837.30196.11175.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130911050206.0dc1ff68@elandnews.com> Date: Wed, 11 Sep 2013 11:08:01 -0400 X-Google-Sender-Auth: sq0FcesR26c2o1rrxrCiNTmF4Wk Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" , "spfbis-chairs@tools.ietf.org" , draft-ietf-spfbis-4408bis@tools.ietf.org, S Moonesamy , The IESG Subject: Re: [spfbis] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 15:08:13 -0000 >> I have to say that I'm not happy about the pseudocode here: what >> situation are we in when the pseudocode differs from the text? Which >> wins? >> >> I already see a case where they differ: the new pseudocode says "if more >> than 10 sending-domain_names are found, use at most 10", and there's >> nothing of the sort in the text. >> >> Does the working group really think there's enough value in having >> pseudocode there that it's worth saying the same thing twice and relying >> on them to be truly the same? And is it really worth it for mechanism >> that's not recommended for use? >> >> I strongly suggest making sure that the text says what you want it to, >> and removing the pseudocode. > > I've written drafts (e.g., RFC5451) that contain prose and an algorithm > description for the same thing, so it's possible to get this right. I'm not > sure it's necessary here, so I agree we should consider dumping it. To be clear: I agree with you that it's possible to get it right and sometimes valuable. I'm suggesting removing it because I don't think it's valuable here. Thanks for considering that. Barry From hallam@gmail.com Wed Sep 11 07:33:48 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 D469921E80C3; Wed, 11 Sep 2013 07:33:48 -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 EafxDzFuf3NQ; Wed, 11 Sep 2013 07:33:48 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id BCA8621E812A; Wed, 11 Sep 2013 07:33:46 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id lv10so821243lab.9 for ; Wed, 11 Sep 2013 07:33:45 -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=oSxmF9jOzFdU7bl9ju6086GgfsTU/VQi8e3GGGxoB4I=; b=1CDMDGdhFQGH180Q6LdfOchU34qFsXhFlCAO3WkfeWDaJBjh6V5yRI9ryQIPI38ICe TO5HkA7jDtO4cZBsK3l+bgQFvWvCq032DMLcOL2ksF/ejJIUWA8RWM1mjmqhYV+J3wkh gQ/Fs4GYebbJiUZ1icd7VeMcE2riOUlohtmMnt8XFFRN/GykPz/U8VNrIi176xCwbV6r 14E3Zb2sAhc9JjbWq9Etk4iLuJ7dSu8oeVZJbv2BtEQbqww2I8V+X88mCI4LCJFyyzeL UeaXzm8gJkdR2xWXHvV9keeCw4MBhpf7KY3c1UD4dhjCHF9ZgMrJqFBpkxLXK0T9Ncn6 Ju5A== MIME-Version: 1.0 X-Received: by 10.152.4.6 with SMTP id g6mr340185lag.50.1378910025535; Wed, 11 Sep 2013 07:33:45 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Wed, 11 Sep 2013 07:33:45 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> Date: Wed, 11 Sep 2013 10:33:45 -0400 Message-ID: From: Phillip Hallam-Baker To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=089e013d1e603fd71604e61c82e5 X-Mailman-Approved-At: Wed, 11 Sep 2013 09:05:24 -0700 Cc: "spfbis@ietf.org" , draft-ietf-spfbis-4408bis.all@tools.ietf.org, "secdir@ietf.org" , S Moonesamy , The IESG Subject: Re: [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 11 Sep 2013 14:33:49 -0000 --089e013d1e603fd71604e61c82e5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 11, 2013 at 9:43 AM, Murray S. Kucherawy wrote: > On Wed, Sep 11, 2013 at 6:22 AM, S Moonesamy wrote: > >> I am responding to the comment about DKIM only and wait for the SPFBIS WG >> to address the other issues. >> > > Was the SecDir review for this draft posted to the spfbis list? I haven't > seen it. > The draft-ietf-spfbis-4408bis.all@tools.ietf.org doesn't cover it? I thought that was the point. > >> The Security Considerations section is adequate for the purpose except >>> that no mention is made anywhere in the specification about DKIM and how a >>> mail receiver should interpret presence of DKIM and SPF policy at the same >>> time. This is a legitimate concern since DKIM is already a standards track >>> proposal and SPF is only now being promoted to Standards Track. Thus the >>> SPF document should address the question of dual use. >>> >> >> There was a BoF at the last IETF meeting to discuss proposals about how >> to interpret the presence of DKIM and/or SPF policy at the same time ( >> http://www.ietf.org/**proceedings/87/minutes/**minutes-87-dmarc). The dual use can be addressed as part of the DMARC effort. >> > > DKIM has no intrinsic policy component. Are we actually talking about > ADSP here? > If a message has a DKIM signature and it is valid for the sending domain then that is strong evidence that the owner of the domain intended to send it. Hence DKIM Signature overlaps with SPF policy. Regardless RFC 5617 is standards track and it is a part of DKIM and the SPF document should probably mention it as well. > Assuming we are, I think the best we could do is to note that it's > possible for ADSP and SPF to yield conflicting policy results; one could be > a "pass" while the other could be a "fail", meaning the receiving MTA now > has one "reject" instruction and one "accept" instruction. The receiving > ADMD will have to make a decision about which one ought to get precedence. > I suspect that the answer is that SPF will take precedence simply because the MailFROM will be received and acted upon before the MTA has enough information to act on DKIM information. An MTA that decides email is spam on the basis of SPF is likely to drop the connection or tar pit it. I doubt it is going to bother to check a DKIM signature. -- Website: http://hallambaker.com/ --089e013d1e603fd71604e61c82e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Sep 11, 2013 at 9:43 AM, Murray S. Kucherawy <superuser@= gmail.com> wrote:
On Wed, Sep 11, 2013 at= 6:22 AM, S Moonesamy <sm+ietf@elandsys.com> wrote:
I am responding to the comment about DKIM only and wait fo= r the SPFBIS WG to address the other issues.

Was the SecDir review for this draft posted to th= e spfbis list?=A0 I haven't seen it.

The draft-ietf-spfbis-4408bis.all@tools.ietf.org doesn&#= 39;t cover it? I thought that was the point.


=A0

The Security Considerations section is adequate for the purpose except that= no mention is made anywhere in the specification about DKIM and how a mail= receiver should interpret presence of DKIM and SPF policy at the same time= . This is a legitimate concern since DKIM is already a standards track prop= osal and SPF is only now being promoted to Standards Track. Thus the SPF do= cument should address the question of dual use.

There was a BoF at the last IETF meeting to discuss proposals about how to = interpret the presence of DKIM and/or SPF policy at the same time ( http://www.ietf.org/proceedings/87/minutes/minutes-87= -dmarc ). =A0The dual use can be addressed as part of the DMARC effort.=

DKIM has no intrinsic policy compone= nt. =A0 Are we actually talking about ADSP here?

If a message has a DKIM signature and it = is valid for the sending domain then that is strong evidence that the owner= of the domain intended to send it. Hence DKIM Signature overlaps with SPF = policy.=A0

Regardless RFC 5617 is standards track and it is a part= of DKIM and the SPF document should probably mention it as well.

=A0
Assuming we are, I think the best we could do is to note that i= t's possible for ADSP and SPF to yield conflicting policy results; one = could be a "pass" while the other could be a "fail", me= aning the receiving MTA now has one "reject" instruction and one = "accept" instruction.=A0 The receiving ADMD will have to make a d= ecision about which one ought to get precedence.

I suspect that the answe= r is that SPF will take precedence simply because the MailFROM will be rece= ived and acted upon before the MTA has enough information to act on DKIM in= formation. An MTA that decides email is spam on the basis of SPF is likely = to drop the connection or tar pit it. I doubt it is going to bother to chec= k a DKIM signature.=A0

--
Website: ht= tp://hallambaker.com/
--089e013d1e603fd71604e61c82e5-- From scott@kitterman.com Tue Sep 10 16:32: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 83AB621F9B60; Tue, 10 Sep 2013 16:32: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] 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 vdPTUXdklQ6Y; Tue, 10 Sep 2013 16:32:20 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1D821F9AE3; Tue, 10 Sep 2013 16:32:20 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id BA05B956002; Tue, 10 Sep 2013 19:32:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1378855939; bh=XaCrJNA1fMHC/u7h59vnSE670rMjp7gNvHZPDxid0jg=; h=In-Reply-To:References:Subject:From:Date:To:CC:From; b=jk3vBDPcLm9MKNk6W2DLrl39nrrd2eRjjht+kccTAaeFlpc81FLRLcP+NKbYVfjpc hhrHXdQxkuNGTuP4KFhk8hM2dBiSOg72rzP94nxlIP4nuZdzMAqTJv1MqY7uoWZKjz +SqWT5bPYTwOqxWDDAnzpOQMJLTK4fVwK7ByPmU0= Received: from [IPV6:2600:1003:b000:f292:7bb6:5a70:5e2a:a8a8] (unknown [IPv6:2600:1003:b000:f292:7bb6:5a70:5e2a:a8a8]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DACBA956001; Tue, 10 Sep 2013 19:32:18 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20130910131842.0cec1d40@elandnews.com> References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130910113052.0c339a60@elandnews.com> <522F7A8F.5060807@gmail.com> <6.2.5.6.2.20130910131842.0cec1d40@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 10 Sep 2013 19:32:40 -0400 To: S Moonesamy , Spencer Dawkins , spfbis@ietf.org Message-ID: <1f9a8f6c-7508-43bf-97ef-2c47fd917480@email.android.com> X-AV-Checked: ClamAV using ClamSMTP X-Mailman-Approved-At: Wed, 11 Sep 2013 09:05:37 -0700 Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Pete Resnick , draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 10 Sep 2013 23:32:24 -0000 I was pretty fatigued when I wrote that. I promise it was beautiful in my head. Sorry for the confusion. I'll fix it tonight after I'm back with the computer ith the document on it. Scott K S Moonesamy wrote: >Hi Spencer, >At 13:01 10-09-2013, Spencer Dawkins wrote: >>I liked where the proposed text seemed to be headed, but this >>sentence didn't parse for me (missing words?), and it seems like a >>really important sentence ... > >Yes, there are some words missing. > >Can the SPFBIS WG please review the text in the message at >http://www.ietf.org/mail-archive/web/spfbis/current/msg04104.html and >suggest text to address the DISCUSS (see >http://www.ietf.org/mail-archive/web/spfbis/current/msg04099.html ). > >Regards, >S. Moonesamy (as document shepherd) From superuser@gmail.com Wed Sep 11 09:35: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 0C4B521E818E; Wed, 11 Sep 2013 09:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 VA0jNJwNVgkF; Wed, 11 Sep 2013 09:35:11 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3132521E813D; Wed, 11 Sep 2013 09:35:10 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id c10so2429971wiw.11 for ; Wed, 11 Sep 2013 09:35:09 -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=OFUEkfGms1yjtgV9g6CStIWaSTTg9EedrPvmm+62DuE=; b=lC9BqIACzOjHoq5zT09Z8dZ03ZRerzFXVllcP+H7mMwow3rZcW4Y2zNXQZXcXMy+Rr h84zmPDE69W5RGLMJKHRPAJCuxM/Vgvl7h3SuuvwdqhLFLzSsHuFFkmabUGCTxEKdgRP r0OWJixwg7Wtzedd2t8o1u3dZspTZOTI9S7HuX+pa95bglO5osSqly81ESOSnUbI9ATa HylXrglE8/8bw+FjOkZxHtw+EnOck6nUjI6yO9DdoDxVDL5IYxCnp/1nouvOUj4+++VY tWVSdWeu70y09HoFPFUTdtesfCoOtmWZcKQY/pUGe4YdtYHhh38bp+mFk4QbiLutRvYw HchA== MIME-Version: 1.0 X-Received: by 10.180.211.19 with SMTP id my19mr2155121wic.19.1378917309327; Wed, 11 Sep 2013 09:35:09 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Wed, 11 Sep 2013 09:35:09 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> Date: Wed, 11 Sep 2013 09:35:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=001a11c3855665aee904e61e3419 Cc: "spfbis@ietf.org" , draft-ietf-spfbis-4408bis.all@tools.ietf.org, "secdir@ietf.org" , S Moonesamy , The IESG Subject: Re: [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 11 Sep 2013 16:35:14 -0000 --001a11c3855665aee904e61e3419 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 11, 2013 at 7:33 AM, Phillip Hallam-Baker wrote: > On Wed, Sep 11, 2013 at 9:43 AM, Murray S. Kucherawy wrote: > >> On Wed, Sep 11, 2013 at 6:22 AM, S Moonesamy wrote: >> >>> I am responding to the comment about DKIM only and wait for the SPFBIS >>> WG to address the other issues. >>> >> >> Was the SecDir review for this draft posted to the spfbis list? I >> haven't seen it. >> > > The draft-ietf-spfbis-4408bis.all@tools.ietf.org doesn't cover it? I > thought that was the point. > I'm pretty sure it's authors, shepherds, and co-chairs only, not the whole WG. > > > > >> >>> The Security Considerations section is adequate for the purpose except >>>> that no mention is made anywhere in the specification about DKIM and how a >>>> mail receiver should interpret presence of DKIM and SPF policy at the same >>>> time. This is a legitimate concern since DKIM is already a standards track >>>> proposal and SPF is only now being promoted to Standards Track. Thus the >>>> SPF document should address the question of dual use. >>>> >>> >>> There was a BoF at the last IETF meeting to discuss proposals about how >>> to interpret the presence of DKIM and/or SPF policy at the same time ( >>> http://www.ietf.org/**proceedings/87/minutes/**minutes-87-dmarc). The dual use can be addressed as part of the DMARC effort. >>> >> >> DKIM has no intrinsic policy component. Are we actually talking about >> ADSP here? >> > > If a message has a DKIM signature and it is valid for the sending domain > then that is strong evidence that the owner of the domain intended to send > it. Hence DKIM Signature overlaps with SPF policy. > Ah, I see where you're going now. > > Regardless RFC 5617 is standards track and it is a part of DKIM and the > SPF document should probably mention it as well. > ADSP has seen so little adoption that I think it would actually be a mistake to pay it any homage here. I think your point above about DKIM proper is the more interesting one. > > > >> Assuming we are, I think the best we could do is to note that it's >> possible for ADSP and SPF to yield conflicting policy results; one could be >> a "pass" while the other could be a "fail", meaning the receiving MTA now >> has one "reject" instruction and one "accept" instruction. The receiving >> ADMD will have to make a decision about which one ought to get precedence. >> > > I suspect that the answer is that SPF will take precedence simply because > the MailFROM will be received and acted upon before the MTA has enough > information to act on DKIM information. An MTA that decides email is spam > on the basis of SPF is likely to drop the connection or tar pit it. I doubt > it is going to bother to check a DKIM signature. > Right, I had forgotten about this as well. I shouldn't reply to SecDir without being appropriately caffeinated. It's not necessarily the case that an SPF failure will be acted upon before DKIM even gets evaluated. Though that is clearly for many installations the optimal use because you don't have to deal with the body, any MTA that wants to give DKIM due consideration as well will have to store the SPF result and then decide on it later. And there are sites that do prefer it that way, not the least of which is the entire DMARC community. This draft is already worded such that one can merely observe the SPF result and record it rather than enacting it as soon as possible, possibly using it as one input to a larger equation. This use case could bolster that argument by providing an example, and could even be done without naming DKIM specifically. Of course, the downside is that the receiver has to deal with accepting the body. As long as the tradeoff is made clear (if it isn't already), we might consider adding it. -MSK --001a11c3855665aee904e61e3419 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 11, 2013 at 7:33 AM, Phillip Hallam-Baker <hal= lam@gmail.com> wrote:
On Wed, Sep 11, 2013 at 9:4= 3 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Wed, Sep 11, 2013 at 6:22 AM, S Moonesamy <sm+= ietf@elandsys.com> wrote:
I am responding to the comment about DKIM only and wait fo= r the SPFBIS WG to address the other issues.

Was the SecDir review for this draft posted to th= e spfbis list?=A0 I haven't seen it.

The draft-ietf-spfbis-4408bis.all@to= ols.ietf.org doesn't cover it? I thought that was the point.

I'm pretty sure it&#= 39;s authors, shepherds, and co-chairs only, not the whole WG.
=A0


=A0

The Security Considerations section is adequate for the purpose except that= no mention is made anywhere in the specification about DKIM and how a mail= receiver should interpret presence of DKIM and SPF policy at the same time= . This is a legitimate concern since DKIM is already a standards track prop= osal and SPF is only now being promoted to Standards Track. Thus the SPF do= cument should address the question of dual use.

There was a BoF at the last IETF meeting to discuss proposals about how to = interpret the presence of DKIM and/or SPF policy at the same time ( http://www.ietf.org/proceedings/87/minutes/minutes-87= -dmarc ). =A0The dual use can be addressed as part of the DMARC effort.=

DKIM has no intrinsic policy compone= nt. =A0 Are we actually talking about ADSP here?

If a message has a DKIM signature a= nd it is valid for the sending domain then that is strong evidence that the= owner of the domain intended to send it. Hence DKIM Signature overlaps wit= h SPF policy.

Ah, I see where you'= re going now.
=A0
=A0
Regardless RFC 5617 is standards t= rack and it is a part of DKIM and the SPF document should probably mention = it as well.

ADSP has seen= so little adoption that I think it would actually be a mistake to pay it a= ny homage here.=A0 I think your point above about DKIM proper is the more i= nteresting one.
=A0

=A0
Assuming we are, I think the best we could do is to note that i= t's possible for ADSP and SPF to yield conflicting policy results; one = could be a "pass" while the other could be a "fail", me= aning the receiving MTA now has one "reject" instruction and one = "accept" instruction.=A0 The receiving ADMD will have to make a d= ecision about which one ought to get precedence.

I suspect that the= answer is that SPF will take precedence simply because the MailFROM will b= e received and acted upon before the MTA has enough information to act on D= KIM information. An MTA that decides email is spam on the basis of SPF is l= ikely to drop the connection or tar pit it. I doubt it is going to bother t= o check a DKIM signature.=A0

Right, I had forgotten a= bout this as well.=A0 I shouldn't reply to SecDir without being appropr= iately caffeinated.

It's not necessarily the case tha= t an SPF failure will be acted upon before DKIM even gets evaluated.=A0 Tho= ugh that is clearly for many installations the optimal use because you don&= #39;t have to deal with the body, any MTA that wants to give DKIM due consi= deration as well will have to store the SPF result and then decide on it la= ter.=A0 And there are sites that do prefer it that way, not the least of wh= ich is the entire DMARC community.

This draft is already worded such that one can merely observ= e the SPF result and record it rather than enacting it as soon as possible,= possibly using it as one input to a larger equation.=A0 This use case coul= d bolster that argument by providing an example, and could even be done wit= hout naming DKIM specifically.=A0 Of course, the downside is that the recei= ver has to deal with accepting the body.=A0 As long as the tradeoff is made= clear (if it isn't already), we might consider adding it.

-MSK

--001a11c3855665aee904e61e3419-- From johnl@iecc.com Wed Sep 11 09:41: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 AE9AF21F9CA4 for ; Wed, 11 Sep 2013 09:41:59 -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 lCzcRhmVDY7a for ; Wed, 11 Sep 2013 09:41: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 6D0EC21F9C2E for ; Wed, 11 Sep 2013 09:41:54 -0700 (PDT) Received: (qmail 29131 invoked from network); 11 Sep 2013 16:41:51 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 11 Sep 2013 16:41:51 -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=52309d4f.xn--hew.k1309; i=johnl@user.iecc.com; bh=7+9LqEwvnPaehERKIPNY6DUVyTtmDQ1O8mYGIQHF0hM=; b=EQQBePZiz8PMFrfcPl379zv9pFfOBEDfB6H62hnmxPTEGMFw+o3GVUVqzShx2mBsXnoAvOulCFwHBtnjEo9HYgfDp9BJa+rSCa/hbjqWPYBBkfSWPQb96x2mhm8coVfTsaECjDoEV4Erl/cx+OqEvD8m9xXxInF6TEeygNFBL6KcKFLhsPA49RbPL/Gmg8Gx9CmK9A8YmpXeCEIczDgDG8+7R/WxkpLL//WjvQ+/k/Ad/8JkQhNpgimwIKbywq3+ 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=52309d4f.xn--hew.k1309; olt=johnl@user.iecc.com; bh=7+9LqEwvnPaehERKIPNY6DUVyTtmDQ1O8mYGIQHF0hM=; b=hNrQ7CuNAIhgpzUbFOXA6qKyUTwVs4nkoq1nYa+zykb2vvRwL7S/tSMFQjKLtfwEoKm6YAazGNKX9semfq/rzqTet+eKeJhvtN8wWXHS9l1+Zr7BHszNxMgqDeRpYoay+8Nlcv95kuSeJL5O9+mfXoAOHrrRNhMqhVOVASAFyUkoB5xRfEkhBavHLcAERhyakw4T2DBO1OO79wU2dqtAchdsPYq2jHtXNyv5OBkuuciGabeFvu/i0wOrykfNnZWK Date: 11 Sep 2013 16:41:29 -0000 Message-ID: <20130911164129.66943.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] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 11 Sep 2013 16:41:59 -0000 >> There was a BoF at the last IETF meeting to discuss proposals about how to >> interpret the presence of DKIM and/or SPF policy at the same time ( >>>). The >>dual use can be addressed as part of the DMARC effort. >DKIM has no intrinsic policy component. Are we actually talking about >ADSP here? Looks like DMARC to me. I don't see any reason to mention in in 4408bis. R's, John From spf2@kitterman.com Wed Sep 11 09:55: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 3E7B011E81CF for ; Wed, 11 Sep 2013 09:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=0.951, 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 XRGTGGuboYIZ for ; Wed, 11 Sep 2013 09:55:06 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0AB11E80FF for ; Wed, 11 Sep 2013 09:55:03 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id CDC2520E40EA; Wed, 11 Sep 2013 12:54:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1378918496; bh=IZ+lVzOOGb1mz4MfxslfQK7hbn4QFNOt/bIkP7h1jSo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bX/yDWCt/7o1HqAS+4WcVxnPK8SC6zYpT9lz/ZgyGJHt+YOoEz0/j2Zu+n+H5HxwP ozUCI5YozYa0XEds8BP2W9pfxzsyNQEzG6kHG+puEI1LDIGEkm1Z4HOt8TnnHVf+JU p+EdoCUn74m+mjm2YxawF8LyrJqiyG6KRt5ophlw= 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 B134E20E40D2; Wed, 11 Sep 2013 12:54:56 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 11 Sep 2013 12:54:54 -0400 Message-ID: <4509124.Paquit6mK7@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <10370218.OEr9JV8dgx@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] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 16:55:11 -0000 On Wednesday, September 11, 2013 06:39:58 Murray S. Kucherawy wrote: > On Tue, Sep 10, 2013 at 6:38 PM, Scott Kitterman wrote: > > 3.1. DNS Resource Records > > > > SPF records MUST be published as a DNS TXT (type 16) Resource Record > > (RR) [RFC1035] only. The character content of the record is encoded > > as [US-ASCII]. Use of alternative DNS RR types was supported in > > SPF's experimental phase, but has been discontinued. > > > > In 2003, when SPF was first being developed, the requirements for > > assignment of a new DNS RR type were considerably more stringent than > > they are now. Additionally, support for easy deployment of new DNS > > RR types was not widely deployed in DNS servers and and provisioning > > Drop one of those "and"s. I don't care which one. Fixed. > > systems. As a result, at that time, there was no reasonable > > alternative to using the TXT RR type for SPF records. > > > > In its review of [RFC4408] the SPFbis working group concluded that > > its dual RR type transition model was fundamentally flawed since it > > contained no common RR type that implementers were required to serve > > and required to check. Many alternatives were considered to resolve > > this issue, but ultimately the working group concluded that > > significant migration to the SPF RR type in the forseable future was > > "foreseeable" Fixed. > > very unlikely and that the best solution for resolving this > > interoperability issue was to drop support for the SPF RR type from > > SPF version 1. See Appendix A of [RFC6686] for further information. > > > > The circumstances surrounding SPF's initial deploymenta decade ago > > "deployment a" Fixed. > > are unique and very, very unlikely to be repeated. If a future > > update to a new SPF version that could not reuse existing SPF records > > were to be developed, it ought to use the SPF RR type. SPF's use of > > the TXT RR type for structured data should in no way be taken as > > precedent for future protocol designers. Things have changed. > > What about "SPF's use of the TXT RR type located at the domain apex"? As I > understand it, part of the complaint is the location of the record, not > just its type. The underscore mechanism used by DKIM, DMARC, ADSP, VBR, > etc. seems to be gaining acceptance, or at least tolerance, because it > avoids query collisions. > > Otherwise, looks okay to me. Given the discuss, I don't think so. Here's the text of the DISCUSS: > Text needs to be created (probably for section 3.1) to better describe > the reason this document settled on TXT RR only and therefore why no > precedent is set for future use of the TXT RR. I think adding something "if you use TXT anyway, use this underscore mechanism" isn't germane since it wasn't an option SPFbis could consider. I can add something along those lines, I guess, but I'm not sure it's needed. Scott K From spf2@kitterman.com Wed Sep 11 10:00: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 C6C0D21E8163 for ; Wed, 11 Sep 2013 10:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.634, 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 jQhlWP9IMqEz for ; Wed, 11 Sep 2013 10:00:39 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2719121F9D7B for ; Wed, 11 Sep 2013 09:59:38 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DE57E20E40EA; Wed, 11 Sep 2013 12:59:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1378918773; bh=k45WBVBpZcvuCWZKi6xeR7znz4rNoB3Bm1KOI1N92v0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WKSVFBBVAsBc0lLehI2n273yxuZlDH1ihdkZHeYF2VOfjAe7W7wD/nLJ9gVzM0ZEV q2r7IaWKH3e0IhLTPbuOO1edVC8WziMvcht7/NmPPFYxEUc9k+N4eLiGw9ZO5O6aOh 0gB8z6LGos22v1bre/Qu3GOWeV4b1pMsmg0R6zrQ= 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 C06F620E40D2; Wed, 11 Sep 2013 12:59:33 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 11 Sep 2013 12:59:33 -0400 Message-ID: <1722205.QZ2hcdPFdJ@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: References: <20130911015837.30196.11175.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130911050206.0dc1ff68@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] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 17:00:45 -0000 On Wednesday, September 11, 2013 07:07:33 Murray S. Kucherawy wrote: > On Wed, Sep 11, 2013 at 5:04 AM, S Moonesamy wrote: > >> ------------------------------**------------------------------** > >> ---------- > >> DISCUSS: > >> ------------------------------**------------------------------** > >> ---------- > >> > >> I have two very small points that I think are unclear, and important > >> enough that we have to get them right, both regarding the check_host() > >> function. These should be really easy to clear up: > >> > >> -- Section 4.6 -- > >> > >> The check_host() function parses and interprets the SPF record to > >> find a result for the current test. If there are any syntax errors > >> anywhere in the record, check_host() returns immediately with the > >> result "permerror", without further interpretation. > >> > >> I think you're trying to say that syntax checking is done before any > >> evaluation, but you aren't saying it. It matters, because > >> implementations that make different choices in that regard won't get the > >> same results from check_host() in all cases, as they're required to. > >> Maybe this?: > >> > >> NEW > >> > >> The check_host() function parses and interprets the SPF record to > >> find a result for the current test. The syntax of the record is > >> validated first, and if there are any syntax errors anywhere in the > >> record, check_host() returns immediately with the result "permerror", > >> without further interpretation or evaluation. > >> > >> END > > Yep. I think this change is fine. Should I make it? > >> -- Section 5.5 -- > >> > >> I have to say that I'm not happy about the pseudocode here: what > >> situation are we in when the pseudocode differs from the text? Which > >> wins? > >> > >> I already see a case where they differ: the new pseudocode says "if more > >> than 10 sending-domain_names are found, use at most 10", and there's > >> nothing of the sort in the text. > >> > >> Does the working group really think there's enough value in having > >> pseudocode there that it's worth saying the same thing twice and relying > >> on them to be truly the same? And is it really worth it for mechanism > >> that's not recommended for use? > >> > >> I strongly suggest making sure that the text says what you want it to, > >> and removing the pseudocode. > > I've written drafts (e.g., RFC5451) that contain prose and an algorithm > description for the same thing, so it's possible to get this right. I'm > not sure it's necessary here, so I agree we should consider dumping it. > > Will review the comment stuff later today. I think we can just remove it. Looking it over, I don't think it adds much, if anything. Scott K From superuser@gmail.com Wed Sep 11 10:04: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 9212211E8215 for ; Wed, 11 Sep 2013 10:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 0PLfXq0Q0Ynu for ; Wed, 11 Sep 2013 10:04:21 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 03D2511E81EA for ; Wed, 11 Sep 2013 10:02:59 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hm2so2477553wib.12 for ; Wed, 11 Sep 2013 10:02:57 -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=C0bSIpbROlsKtr0rVZKMNfKkdKqhGNlhH6J8UNAvSeE=; b=ooWtAhIWicJhUjjKHDgmhf1pCZcDxl3u8T+SKU29lZYilnVbezmbcBj0O4/ziOGq/c RhAfWpess4TPbShnYv50P3tyJkWY21OpMEgJc9mkxdMe83G0rG3D+arBI1uFHPNAuuda a3INCh+4JdbhdDCL843BGyL0H7JZWsteYM221lzsVFdbEOipwTuZmW5/pE9xpUBgbhSi ARZLmGX5e4nFMoef28jR8ctd4Lj+JI1VDWd5BjIkBKGhaQvj6+jXEFXUAzSSPp+Qkfzg eMwdd6992p/gNS11jDXbswNDJz5V60g4X70TZ8Qy1u+cFGgwQ7Kg5EMzdwkWlMzXFRz0 E6pA== MIME-Version: 1.0 X-Received: by 10.194.109.35 with SMTP id hp3mr2375440wjb.55.1378918977278; Wed, 11 Sep 2013 10:02:57 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Wed, 11 Sep 2013 10:02:57 -0700 (PDT) In-Reply-To: <4509124.Paquit6mK7@scott-latitude-e6320> References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <10370218.OEr9JV8dgx@scott-latitude-e6320> <4509124.Paquit6mK7@scott-latitude-e6320> Date: Wed, 11 Sep 2013 10:02:57 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=089e010d8574d0987804e61e97cd Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 17:04:48 -0000 --089e010d8574d0987804e61e97cd Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 11, 2013 at 9:54 AM, Scott Kitterman wrote: > > Drop one of those "and"s. I don't care which one. > > Fixed. > The WG may disagree with the choice you made as to which one you removed. Be prepared to explain it. > > > are unique and very, very unlikely to be repeated. If a future > > > update to a new SPF version that could not reuse existing SPF > records > > > were to be developed, it ought to use the SPF RR type. SPF's use of > > > the TXT RR type for structured data should in no way be taken as > > > precedent for future protocol designers. Things have changed. > > > > What about "SPF's use of the TXT RR type located at the domain apex"? > As I > > understand it, part of the complaint is the location of the record, not > > just its type. The underscore mechanism used by DKIM, DMARC, ADSP, VBR, > > etc. seems to be gaining acceptance, or at least tolerance, because it > > avoids query collisions. > > > > Otherwise, looks okay to me. > > Given the discuss, I don't think so. Here's the text of the DISCUSS: > > > Text needs to be created (probably for section 3.1) to better describe > > the reason this document settled on TXT RR only and therefore why no > > precedent is set for future use of the TXT RR. > > I think adding something "if you use TXT anyway, use this underscore > mechanism" isn't germane since it wasn't an option SPFbis could consider. > > I can add something along those lines, I guess, but I'm not sure it's > needed. > > My issue is that the second-last sentence there basically says "don't use TXT for structured data in the future" as a pretty absolute thing, but in fact the underscore "loophole" is currently something the community is tolerating. It seems incorrect. I know underscore wasn't an option for us, but as pedagogy for future protocol developers, it doesn't tell the whole story either. -MSK --089e010d8574d0987804e61e97cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 11, 2013 at 9:54 AM, Scott Kitterman <spf2@k= itterman.com> wrote:
> Drop one of those &qu= ot;and"s. =A0I don't care which one.

Fixed.

The WG may disagree with t= he choice you made as to which one you removed.=A0 Be prepared to explain i= t.
=A0
> > =A0 =A0are unique and very, very unlikely to be repeated. =A0If a= future
> > =A0 =A0update to a new SPF version that could not reuse existing = SPF records
> > =A0 =A0were to be developed, it ought to use the SPF RR type. =A0= SPF's use of
> > =A0 =A0the TXT RR type for structured data should in no way be ta= ken as
> > =A0 =A0precedent for future protocol designers. =A0Things have ch= anged.
>
> What about "SPF's use of the TXT RR type located at the domai= n apex"? =A0As I
> understand it, part of the complaint is the location of the record, no= t
> just its type. =A0The underscore mechanism used by DKIM, DMARC, ADSP, = VBR,
> etc. seems to be gaining acceptance, or at least tolerance, because it=
> avoids query collisions.
>
> Otherwise, looks okay to me.

Given the discuss, I don't think so. =A0Here's the text of th= e DISCUSS:

> Text needs to be created (probably for section 3.1) to better describe=
> the reason this document settled on TXT RR only and therefore why no > precedent is set for future use of the TXT RR.

I think adding something "if you use TXT anyway, use this unders= core
mechanism" isn't germane since it wasn't an option SPFbis coul= d consider.

I can add something along those lines, I guess, but I'm not sure it'= ;s needed.


My issue is that the second-last sente= nce there basically says "don't use TXT for structured data in the= future" as a pretty absolute thing, but in fact the underscore "= loophole" is currently something the community is tolerating.=A0 It se= ems incorrect.=A0 I know underscore wasn't an option for us, but as ped= agogy for future protocol developers, it doesn't tell the whole story e= ither.

-MSK
--089e010d8574d0987804e61e97cd-- From hsantos@isdg.net Wed Sep 11 10:16: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 C7AE321F8698 for ; Wed, 11 Sep 2013 10:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.716 X-Spam-Level: X-Spam-Status: No, score=-101.716 tagged_above=-999 required=5 tests=[AWL=0.019, 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 hJJ1Q7Czks3G for ; Wed, 11 Sep 2013 10:15:29 -0700 (PDT) Received: from pop3.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E78E521F9950 for ; Wed, 11 Sep 2013 10:15:25 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4115; t=1378919716; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=IoH/SYoT1ikEG1NbIKeXi9hMG3I=; b=lrEAo/bYuhinsM1bAfSS JZeeyyPgUuxZ0XopnOMgsDkQA79+wrWJaOnCiBpYO7vZfXq7sMAsmT0W8RhjL/fz pC9z9cMqzYh8ql8woqHqonMqO0qdYLgw8UChZDVcgyiGooDXayqoRhFa2rKT2TbR XKBq5TIOOeGIhsb7v8NA/gw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 11 Sep 2013 13:15:16 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1087244572.29028.2024; Wed, 11 Sep 2013 13:15:16 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4115; t=1378919368; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=FBXMq6v Vy6S9HPQvoktzEVSeZhwEBLC6QWMZ0OmY9Pg=; b=O5DNKbhO8pyAAZljEvg3GL/ SM4kkv3JPBHt9I+0rrN3m8wqFkre2STa5WKma/QC3IkGBgIqDE6Y2QjfNxjzJyEN AtJLtHZ4eG+5ZJ78QY4ogMyVV47Rdj58q34JpHUYJ/RB1xA6rCjyHzQ3x8FE/3YS AsRD8/PDhoSoksOl3sfU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 11 Sep 2013 13:09:28 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 533649034.9.6472; Wed, 11 Sep 2013 13:09:27 -0400 Message-ID: <5230A523.20504@isdg.net> Date: Wed, 11 Sep 2013 13:15:15 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> In-Reply-To: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 11 Sep 2013 17:16:17 -0000 I had an issue with SPFBIS limiting discussion with integrated technology that is 100% related and exist in the market place. Protocols SenderID and Submitter SMTP extension which can alter the way an SPF compliant package will work. Related, I had an issue with the limited modeling of check_host() function I/O which WOULD NOT fit the reality of an integrated system with SUBMITTER support with extended input parameters: spf_result = check_host(ehlo, mailfrom [,submitter]) I didn't see why this was not important other than to believe that SenderID/Submitter doesn't not exist. DKIM is not RELATED to SPF. To talk about unrelated DKIM required to talk about a very related item such as SenderID, SUBMITTER. In this vain, until the IETF can say something about a SPF-related technology in SenderID and especially SMTP level SUBMITTER protocol which will require to be fitted with a Check_Host() function, the "Experiment" was not really completely concluded. Keep in mind that SPF is a SMTP level technology (doesn't require the payload). DKIM requires the payload to be transferred and this diminished the optimization of an SPF method. For DKIM, like ADSP, DMARC also now depended on that Author Domain anchor (the single binding requirement for DKIM). SPF or the SenderID Submitter protocol do not depend on receiving the payload in other to function. A DKIM discussion will require how SMTP transaction is done with SPF receivers, that is mainly to always receive the payload. On 9/11/2013 9:22 AM, S Moonesamy wrote: > Hi Phillip, > > I am responding to the comment about DKIM only and wait for the SPFBIS > WG to address the other issues. > > At 05:07 11-09-2013, Phillip Hallam-Baker wrote: >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. Document editors and WG chairs should treat these comments just >> like any other last call comments. >> >> The document has been produced as part of a proposal to upgrade SPF >> to standards track recognizing the state of deployment experience. >> >> Minor issues. >> >> 1.1.3. MAIL FROM Definition >> >> I found this section completely opaque and very confusing. It should >> not be necessary to hunt through other specs to find a definition. >> Particularly since the referenced specs do not give an explicit >> definition for the term as used and the references point to the >> whole spec rather than a particular section. > > I am commenting on the following paragraph only: > >> The Security Considerations section is adequate for the purpose >> except that no mention is made anywhere in the specification about >> DKIM and how a mail receiver should interpret presence of DKIM and >> SPF policy at the same time. This is a legitimate concern since DKIM >> is already a standards track proposal and SPF is only now being >> promoted to Standards Track. Thus the SPF document should address >> the question of dual use. > > There was a BoF at the last IETF meeting to discuss proposals about > how to interpret the presence of DKIM and/or SPF policy at the same > time ( http://www.ietf.org/proceedings/87/minutes/minutes-87-dmarc ). > The dual use can be addressed as part of the DMARC effort. > >> 8.7. Permerror >> >> " >> >> This signals an error condition that >> >> definitely requires operator intervention to be resolved." >> >> I cannot imagine a circumstance which definitely requires a human to >> be involved in mail delivery. >> >> >> 11.2. SPF-Authorized Email May Contain Other False Identities >> >> Do not construe the "MAIL FROM" and "HELO" identity >> authorizations to >> provide more assurance than they do. >> >> Document has quasi normative language that should be worded as >> statements of fact rather than as direction. >> >> -- >> Website: http://hallambaker.com/ > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From superuser@gmail.com Wed Sep 11 10:24: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 734EB11E81A4; Wed, 11 Sep 2013 10:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 yKvNgLdQBjND; Wed, 11 Sep 2013 10:23:59 -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 8E8BF21F9E73; Wed, 11 Sep 2013 10:23:58 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x55so7065828wes.24 for ; Wed, 11 Sep 2013 10:23:57 -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=Lq3cA/aTGyt7AcNGbp+wb5U3vEFC8A8PR7963Cqx2eo=; b=KMxvL/joqAyq3n2W1u22DhxYB1FrmYKncTh5iNv4kUOYVMLnnW8viM1kBrgrUAp7fP b4jT61XVj4EfgkjnEFzeenV3EGitRl+tbpkuyTV4dDe2AtSA7DiypMUI5UlMf06rgnWU LpyN0IR2ZAFZVWv6YDN6oJxHmh0bqgUuPOBF29ZCQYX3NALAbBhWVhMVVxXWMb9BZha1 eFRQpHLFwRy4OEJkxfyXbZuRADnMKEK/gPdLrATplfhLQY64GTRY+Vl810iyTF3RNeAG f9uPMwF7Qb8dLVhg4Wxa0hMnqJensXuZucRoyXErUz41imRM3nV9D9NvVALI7p4C/pp0 lJEQ== MIME-Version: 1.0 X-Received: by 10.194.71.72 with SMTP id s8mr2523130wju.52.1378920237216; Wed, 11 Sep 2013 10:23:57 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Wed, 11 Sep 2013 10:23:57 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130911050206.0dc1ff68@elandnews.com> References: <20130911015837.30196.11175.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130911050206.0dc1ff68@elandnews.com> Date: Wed, 11 Sep 2013 10:23:57 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=047d7bd91a04e9bbab04e61ee240 Cc: "spfbis@ietf.org" , spfbis-chairs@tools.ietf.org, Barry Leiba , draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG Subject: Re: [spfbis] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 17:24:03 -0000 --047d7bd91a04e9bbab04e61ee240 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 11, 2013 at 5:04 AM, S Moonesamy wrote: > > >> ------------------------------**------------------------------** >> ---------- >> COMMENT: >> ------------------------------**------------------------------** >> ---------- >> >> I have a bunch of editorial comments that I'd like you to consider. >> They're all non-blocking, but I think they'll improve the document, and >> I'll be happy to chat about them if you like. >> >> -- Section 2.5 -- >> >> Performing the authorization check other than using the MAIL FROM and >> client address at the time of the MAIL command during the SMTP >> transaction can cause problems, such as the following: (1) It might >> be difficult to accurately extract the required information from >> potentially deceptive headers; (2) legitimate email might fail >> because the sender's policy had since changed. >> >> I found that to be awkwardly worded and hard to understand. Please >> consider this rewrite: >> >> NEW >> The authorization check is performed during the SMTP transaction >> at the time of the MAIL command, and uses the MAIL FROM value and >> the client IP address. Performing the check at later times or >> with other input can cause problems such as the following: >> >> * It might be difficult to accurately extract the required >> information from potentially deceptive headers. >> >> * Legitimate email might fail the authorization check because >> the sender's policy has since changed. >> END >> > Seems reasonable. > >> -- Section 2.6 -- >> >> It would really read best if the subsections were worded to be parallel. >> As it stands, subsections 1, 3, 4, 6, and 7 are worded as "result X means >> Y", and subsections 2 and 5 are not. Can you re-word 2 and 5 to be >> parallel to the others? >> > Seems reasonable. > >> Also, why are "neutral" and "fail" called "explicit statements", but >> "pass", for example, is not? >> > I agree, "pass" should be. > >> -- Section 3 -- >> >> Each SPF record is placed in the DNS tree at the owner name it >> pertains to, not a subdomain under it, such as is done with SRV >> records [RFC2782]. >> >> This looks like it's saying that SRV records are placed in subdomains, >> and I don't think that's what you mean. Or is it? In any case, it's not >> clear (and I know this text is from the original). >> >> Maybe this (which also avoids the two different "it"s)?: >> >> NEW >> Each SPF record is placed in the DNS tree at the owner name it >> pertains to, not in a subdomain under the owner name. This is >> similar to how SRV records [RFC2782] are done. >> END >> > Seems reasonable. > >> The example in this section might be published via these lines in a >> domain zone file: >> >> example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" >> smtp-out.example.com. TXT "v=spf1 a -all" >> >> What does "smtp-out" have to do with anything? It's not otherwise used, >> and it seems to contradict what you say about subdomains in the previous >> paragraph. >> > Hmm. Someone else will have to comment on this one. > >> -- Section 4 -- >> >> This description is not an API (Application Program Interface) >> definition, >> >> Two total nits on this: >> 1. You never use "API" other than here, so there's no need to define it, >> and >> 2. the usual expansion of "API" is application programMING interface. >> I suggest, "This description is not an application programming interface >> definition, [etc]." >> > Seems reasonable. > >> -- Section 4.5 -- >> >> Starting with the set of records that were returned by the lookup, >> discard records that do not begin with a version section of exactly >> "v=spf1". Note that the version section is terminated either by an >> SP character or the end of the record. A record with a version >> section of "v=spf10" does not match and is discarded. >> >> Sure, and "v=spf1.0" doesn't match, and "v=spf11" doesn't match, and.... >> Why is it necessary or desirable to single out "v=spf10" here? >> > I think "v=spf1.0" is actually the better (and perhaps intended) example, meaning "don't just stuff the part after 'spf' through a number parser and make sure 1 comes out". >> -- Section 4.6.4 -- >> >> SPF implementations MUST limit the total number of mechanisms and >> modifiers ("terms") that cause any DNS query to 10 during SPF >> evaluation. Specifically, the "include", "a", "mx", "ptr", and >> "exists" mechanisms as well as the "redirect" modifier count against >> this collective limit. The "all", "ip4", and "ip6" mechanisms do not >> count against this limit. If this number is exceeded during a check, >> a "permerror" MUST be returned. The "exp" modifier does not count >> against this limit because the DNS lookup to fetch the explanation >> string occurs after the SPF record evaluation has been completed. >> >> When I read this, I start feeling like I'm being read the rules for >> Fizzbin >. >> I would >> appreciate it if this was re-worded so that there are two clear lists >> here: the terms that are included in the "limit of 10", and the terms >> that are not (and are, presumably, unlimited). Perhaps something like >> this: >> >> NEW >> Some mechanisms and modifiers (collectively, "terms") cause DNS >> queries at the time of evaluation, and some do not. The following >> terms cause DNS queries: . SPF implementations >> MUST limit the total number of those terms to 10 during SPF >> evaluation, to avoid unreasonable load on the DNS. If this limit >> is exceeded, the implementation MUST return "permerror". The other >> terms () do not cause DNS queries at the time of >> SPF evaluation, and their use is not subject to this limit. >> END >> >> If you think it's necessary (I don't): >> >> NEW+ >> The other >> terms () do not cause DNS queries at the time of >> SPF evaluation (the "exp" modifier causes a lookup at a later time), >> and their use is not subject to this limit. >> END >> > I like the new text, and prefer the second bit be included. > >> Then in the next two paragraphs, I think it would improve clarity to make >> a change such as this: >> >> OLD >> When evaluating the "mx" mechanism, the number of "MX" resource >> records queried is included in the overall limit of 10 mechanisms/ >> modifiers that cause DNS lookups described above. The evaluation of >> each "MX" record MUST NOT result in querying more than 10 address >> records, >> NEW >> When evaluating the "mx" mechanism, the number of "MX" resource >> records queried is included in the overall limit of 10 mechanisms/ >> modifiers that cause DNS lookups described above. In addition to >> that limit, the evaluation of each "MX" record MUST NOT result in >> querying more than 10 address records, >> END >> >> (And similarly for the "ptr" paragraph.) I know you say this in a >> paragraph of its own ("These limits are per mechanism..."), but it's >> helpful if people can understand things as they read them, and then to >> emphasize it later... rather than having them scratch their heads for a >> few paragraphs until they get to it. >> >> +1 to that part too. > -- Section 4.7 -- >> >> It is better to use either a "redirect" modifier or an "all" >> mechanism to explicitly terminate processing. Although the latter >> has a default (specifically "?all"), it aids debugging efforts if it >> is explicitly provided. >> >> I'm not sure what "the latter has a default" is trying to say. Do you >> mean that "?all" is the default if you fall off the end, but you >> shouldn't rely on that? Or do you mean that if you say "all", then >> "?all" is taken as the default (I would think "all" would mean "+all")? >> Will you try re-wording this, please? >> > The former ("?all" is implicit if you fall off the end). Suggest: It is better to use either a "redirect" modifier or an "all" mechanism to explicitly terminate processing. Although there is in effect a "?all" implicit at the end of every record, it ads debigging efforts when it is explicitly provided. > >> -- Section 5 -- >> >> What does "(do not publish)" mean next to "ptr" in the sender mechanisms >> list? Ah; I see; it matches the "do not use" in Section 5.5. You should >> probably change this to "(do not use; see the note in Section 5.5)". >> > Seems reasonable. > >> It would help, I think, to add to the end of the second paragraph, "The >> basic mechanisms are as follows:", and to the end of the third paragraph, >> "The designated sender mechanisms are as follows:". Otherwise, there are >> just these disembodied lists, and the reader has to infer those >> introductions. >> > Sure. > >> -- Section 5.1 -- >> >> Mechanisms after "all" will never be tested. Mechanisms listed after >> "all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST be >> ignored when there is an "all" mechanism in the record. >> >> This says that the redirect in the following record will be ignored: >> >> v=spf1 redirect=_spf.example.com +all >> >> That's sufficiently odd that it should be called out explicitly, perhaps >> by adding "regardless of the relative ordering of the terms" to the last >> sentence in the quote. >> > Yep. > >> -- Section 5.2 -- >> >> 3. The recursive evaluation returns either match, not match, or an >> error. If it matches, then the appropriate result for the >> include: mechanism is used (e.g. include or +include produces a >> "pass" result and -include produces "fail"). >> >> 4. If there is no match, the parent check_host() resumes processing >> as per the table below, with the previous value of >> restored. >> >> A few things here: >> >> 1. Nit: "either" is for two things; for more than two, please remove the >> word "either" (or replace it with "one of", but that seems awkward >> here). >> >> 2. "If it matches" is not parallel to "returns match", and similarly for >> "if there is no match". >> >> 3. You don't say what happens if the recursive evaluation returns an >> error. Unfortuately, "no match" and "not match" are sufficiently similar >> to be confused. >> >> I suggest this: >> >> NEW >> 3. The recursive evaluation returns match, not match, or an >> error. >> >> 4. If it returns match, then the appropriate result for the >> include: mechanism is used (e.g., include or +include produces >> a "pass" result and -include produces "fail"). >> >> 5. If it returns not match or an error, the parent check_host() >> resumes processing as per the table below, with the previous >> value of restored. >> END >> > +1. > >> The "include" mechanism is intended for crossing administrative >> boundaries. For example, if example.com and example.org were managed >> by the same entity, and if the permitted set of hosts for both >> domains was "mx:example.com", it would be possible for example.org to >> specify "include:example.com", but it would be preferable to specify >> "redirect=example.com" or even "mx:example.com". >> >> The text you eliminated here provided a buffer that's no longer there, >> making the "For example," very odd. You talk about crossing admin >> boundaries and immediately follow it with an example that does NOT. I >> think it would be better to put a sentence in to restore that buffer -- >> perhaps, "When remaining within one administrative authority, "include" >> is usually not the best choice." >> > Sure. > >> -- Section 5.5 -- >> >> This mechanism SHOULD NOT be published. See below for discussion. >> >> It's quite a bit below. I suggest "See the note at the end of this >> section for more information." It might even be worth putting that note >> into a Section 5.5.1, so it's highlighted and more easily cited. >> > +1. > >> -- Section 6 -- >> >> Unrecognized modifiers MUST be ignored no matter where in a record, >> or how often. >> >> This is missing a couple of words: >> >> NEW >> Unrecognized modifiers MUST be ignored no matter where in a record >> they appear, or how often. >> END >> > +1. > >> For clarity, any "redirect" modifier SHOULD appear as the very last >> term in a record. >> >> I don't usually recommend repeating things, but one thing from earlier >> probably does bear repeating here: >> >> NEW >> For clarity, any "redirect" modifier SHOULD appear as the very last >> term in a record. Any "redirect" modifier MUST be ignored if there >> is an "all" mechanism anywhere in the record. >> END >> > > Seems reasonable. -MSK --047d7bd91a04e9bbab04e61ee240 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 11, 2013 at 5:04 AM, S Moonesamy <sm+ietf@= elandsys.com> wrote:


-------------------------------------------------------------= ---------
COMMENT:
-------------------------------------------------------------= ---------

I have a bunch of editorial comments that I'd like you to consider.
They're all non-blocking, but I think they'll improve the document,= and
I'll be happy to chat about them if you like.

-- Section 2.5 --

=A0 =A0Performing the authorization check other than using the MAIL FROM an= d
=A0 =A0client address at the time of the MAIL command during the SMTP
=A0 =A0transaction can cause problems, such as the following: (1) It might<= br> =A0 =A0be difficult to accurately extract the required information from
=A0 =A0potentially deceptive headers; (2) legitimate email might fail
=A0 =A0because the sender's policy had since changed.

I found that to be awkwardly worded and hard to understand. =A0Please
consider this rewrite:

NEW
=A0 =A0The authorization check is performed during the SMTP transaction
=A0 =A0at the time of the MAIL command, and uses the MAIL FROM value and =A0 =A0the client IP address. =A0Performing the check at later times or
=A0 =A0with other input can cause problems such as the following:

=A0 =A0* =A0It might be difficult to accurately extract the required
=A0 =A0 =A0 information from potentially deceptive headers.

=A0 =A0* =A0Legitimate email might fail the authorization check because
=A0 =A0 =A0 the sender's policy has since changed.
END

Seems reasonable.
= =A0

-- Section 2.6 --

It would really read best if the subsections were worded to be parallel. As it stands, subsections 1, 3, 4, 6, and 7 are worded as "result X me= ans
Y", and subsections 2 and 5 are not. =A0Can you re-word 2 and 5 to be<= br> parallel to the others?

Se= ems reasonable.
=A0

Also, why are "neutral" and "fail" called "explici= t statements", but
"pass", for example, is not?
I agree, "pass" should be.
=A0

-- Section 3 --

=A0 =A0Each SPF record is placed in the DNS tree at the owner name it
=A0 =A0pertains to, not a subdomain under it, such as is done with SRV
=A0 =A0records [RFC2782].

This looks like it's saying that SRV records are placed in subdomains,<= br> and I don't think that's what you mean. =A0Or is it? =A0In any case= , it's not
clear (and I know this text is from the original).

Maybe this (which also avoids the two different "it"s)?:

NEW
=A0 =A0Each SPF record is placed in the DNS tree at the owner name it
=A0 =A0pertains to, not in a subdomain under the owner name. =A0This is
=A0 =A0similar to how SRV records [RFC2782] are done.
END

Seems reasonable.
= =A0

=A0 =A0The example in this section might be published via these lines in a<= br> =A0 =A0domain zone file:

=A0 =A0 =A0 example.com. TXT "v=3Dspf1 +mx a:colo.example.com/28 -all"
=A0 =A0 =A0 smtp-= out.example.com. TXT "v=3Dspf1 a -all"

What does "smtp-out" have to do with anything? =A0It's not ot= herwise used,
and it seems to contradict what you say about subdomains in the previous paragraph.

Hmm.=A0 Someone= else will have to comment on this one.
=A0

-- Section 4 --

=A0 =A0This description is not an API (Application Program Interface)
=A0 =A0definition,

Two total nits on this:
1. You never use "API" other than here, so there's no need to= define it,
and
2. the usual expansion of "API" is application programMING interf= ace.
I suggest, "This description is not an application programming interfa= ce
definition, [etc]."

S= eems reasonable.
=A0

-- Section 4.5 --

=A0 =A0Starting with the set of records that were returned by the lookup, =A0 =A0discard records that do not begin with a version section of exactly<= br> =A0 =A0"v=3Dspf1". =A0Note that the version section is terminated= either by an
=A0 =A0SP character or the end of the record. =A0A record with a version =A0 =A0section of "v=3Dspf10" does not match and is discarded.
Sure, and "v=3Dspf1.0" doesn't match, and "v=3Dspf11&quo= t; doesn't match, and....
Why is it necessary or desirable to single out "v=3Dspf10" here?<= br>

I think "v=3Dspf1.0&q= uot; is actually the better (and perhaps intended) example, meaning "d= on't just stuff the part after 'spf' through a number parser an= d make sure 1 comes out".


-- Section 4.6.4 --

=A0 =A0SPF implementations MUST limit the total number of mechanisms and =A0 =A0modifiers ("terms") that cause any DNS query to 10 during = SPF
=A0 =A0evaluation. =A0Specifically, the "include", "a",= "mx", "ptr", and
=A0 =A0"exists" mechanisms as well as the "redirect" mo= difier count against
=A0 =A0this collective limit. =A0The "all", "ip4", and = "ip6" mechanisms do not
=A0 =A0count against this limit. =A0If this number is exceeded during a che= ck,
=A0 =A0a "permerror" MUST be returned. =A0The "exp" mod= ifier does not count
=A0 =A0against this limit because the DNS lookup to fetch the explanation =A0 =A0string occurs after the SPF record evaluation has been completed.
When I read this, I start feeling like I'm being read the rules for
Fizzbin <http://en.wikipedia.org/wiki/Fizzbin#Fizzbin>. = =A0I would
appreciate it if this was re-worded so that there are two clear lists
here: the terms that are included in the "limit of 10", and the t= erms
that are not (and are, presumably, unlimited). =A0Perhaps something like this:

NEW
=A0 =A0Some mechanisms and modifiers (collectively, "terms") caus= e DNS
=A0 =A0queries at the time of evaluation, and some do not. =A0The following=
=A0 =A0terms cause DNS queries: <list goes here>. =A0SPF implementati= ons
=A0 =A0MUST limit the total number of those terms to 10 during SPF
=A0 =A0evaluation, to avoid unreasonable load on the DNS. =A0If this limit<= br> =A0 =A0is exceeded, the implementation MUST return "permerror". = =A0The other
=A0 =A0terms (<list goes here>) do not cause DNS queries at the time = of
=A0 =A0SPF evaluation, and their use is not subject to this limit.
END

If you think it's necessary (I don't):

NEW+
=A0 =A0The other
=A0 =A0terms (<list goes here>) do not cause DNS queries at the time = of
=A0 =A0SPF evaluation (the "exp" modifier causes a lookup at a la= ter time),
=A0 =A0and their use is not subject to this limit.
END

I like the new text, a= nd prefer the second bit be included.
=A0

Then in the next two paragraphs, I think it would improve clarity to make a change such as this:

OLD
=A0 =A0When evaluating the "mx" mechanism, the number of "MX= " resource
=A0 =A0records queried is included in the overall limit of 10 mechanisms/ =A0 =A0modifiers that cause DNS lookups described above. =A0The evaluation = of
=A0 =A0each "MX" record MUST NOT result in querying more than 10 = address
=A0 =A0records,
NEW
=A0 =A0When evaluating the "mx" mechanism, the number of "MX= " resource
=A0 =A0records queried is included in the overall limit of 10 mechanisms/ =A0 =A0modifiers that cause DNS lookups described above. =A0In addition to<= br> =A0 =A0that limit, the evaluation of each "MX" record MUST NOT re= sult in
=A0 =A0querying more than 10 address records,
END

(And similarly for the "ptr" paragraph.) =A0I know you say this i= n a
paragraph of its own ("These limits are per mechanism..."), but i= t's
helpful if people can understand things as they read them, and then to
emphasize it later... rather than having them scratch their heads for a
few paragraphs until they get to it.


+1 to that part too.
= =A0
-- Section 4.7 --

=A0 =A0It is better to use either a "redirect" modifier or an &qu= ot;all"
=A0 =A0mechanism to explicitly terminate processing. =A0Although the latter=
=A0 =A0has a default (specifically "?all"), it aids debugging eff= orts if it
=A0 =A0is explicitly provided.

I'm not sure what "the latter has a default" is trying to say= . =A0Do you
mean that "?all" is the default if you fall off the end, but you<= br> shouldn't rely on that? =A0Or do you mean that if you say "all&quo= t;, then
"?all" is taken as the default (I would think "all" wou= ld mean "+all")?
Will you try re-wording this, please?
The former ("?all" is implicit if you fall off the en= d).=A0 Suggest:

It is better to use either a "redirect" mo= difier or an "all" mechanism to explicitly terminate processing.= =A0 Although there is in effect a "?all" implicit at the end of e= very record, it ads debigging efforts when it is explicitly provided.

=A0

-- Section 5 --

What does "(do not publish)" mean next to "ptr" in the = sender mechanisms
list? =A0Ah; I see; it matches the "do not use" in Section 5.5. = =A0You should
probably change this to "(do not use; see the note in Section 5.5)&quo= t;.

Seems reasonable.
= =A0

It would help, I think, to add to the end of the second paragraph, "Th= e
basic mechanisms are as follows:", and to the end of the third paragra= ph,
"The designated sender mechanisms are as follows:". =A0Otherwise,= there are
just these disembodied lists, and the reader has to infer those
introductions.

Sure.
= =A0

-- Section 5.1 --

=A0 =A0Mechanisms after "all" will never be tested. =A0Mechanisms= listed after
=A0 =A0"all" MUST be ignored. =A0Any "redirect" modifie= r (Section 6.1) MUST be
=A0 =A0ignored when there is an "all" mechanism in the record.
This says that the redirect in the following record will be ignored:

=A0 =A0v=3Dspf1 redirect=3D_spf.example.com +all

That's sufficiently odd that it should be called out explicitly, perhap= s
by adding "regardless of the relative ordering of the terms" to t= he last
sentence in the quote.

Yep= .
=A0

-- Section 5.2 --

=A0 =A03. =A0The recursive evaluation returns either match, not match, or a= n
=A0 =A0 =A0 =A0error. =A0If it matches, then the appropriate result for the=
=A0 =A0 =A0 =A0include: mechanism is used (e.g. include or +include produce= s a
=A0 =A0 =A0 =A0"pass" result and -include produces "fail&quo= t;).

=A0 =A04. =A0If there is no match, the parent check_host() resumes processi= ng
=A0 =A0 =A0 =A0as per the table below, with the previous value of <domai= n>
=A0 =A0 =A0 =A0restored.

A few things here:

1. Nit: "either" is for two things; for more than two, please rem= ove the
word "either" (or replace it with "one of", but that se= ems awkward
here).

2. "If it matches" is not parallel to "returns match", = and similarly for
"if there is no match".

3. You don't say what happens if the recursive evaluation returns an error. =A0Unfortuately, "no match" and "not match" are = sufficiently similar
to be confused.

I suggest this:

NEW
=A0 =A03. =A0The recursive evaluation returns match, not match, or an
=A0 =A0 =A0 =A0error.

=A0 =A04. =A0If it returns match, then the appropriate result for the
=A0 =A0 =A0 =A0include: mechanism is used (e.g., include or +include produc= es
=A0 =A0 =A0 =A0a "pass" result and -include produces "fail&q= uot;).

=A0 =A05. =A0If it returns not match or an error, the parent check_host() =A0 =A0 =A0 =A0resumes processing as per the table below, with the previous=
=A0 =A0 =A0 =A0value of <domain> restored.
END

+1.
=A0

=A0 =A0The "include" mechanism is intended for crossing administr= ative
=A0 =A0boundaries. =A0For example, if example.com and example.org were managed
=A0 =A0by the same entity, and if the permitted set of hosts for both
=A0 =A0domains was "mx:example.com", it would be possible for example.org to
=A0 =A0specify "include:example.com", but it would be preferable to specify
=A0 =A0"redirect=3Dex= ample.com" or even "mx:example.com".

The text you eliminated here provided a buffer that's no longer there,<= br> making the "For example," very odd. =A0You talk about crossing ad= min
boundaries and immediately follow it with an example that does NOT. =A0I think it would be better to put a sentence in to restore that buffer --
perhaps, "When remaining within one administrative authority, "in= clude"
is usually not the best choice."
Sure.
=A0

-- Section 5.5 --

=A0 =A0This mechanism SHOULD NOT be published. =A0See below for discussion.=

It's quite a bit below. =A0I suggest "See the note at the end of t= his
section for more information." =A0It might even be worth putting that = note
into a Section 5.5.1, so it's highlighted and more easily cited.

+1.
=A0

-- Section 6 --

=A0 =A0Unrecognized modifiers MUST be ignored no matter where in a record,<= br> =A0 =A0or how often.

This is missing a couple of words:

NEW
=A0 =A0Unrecognized modifiers MUST be ignored no matter where in a record =A0 =A0they appear, or how often.
END

+1.
=A0

=A0 =A0For clarity, any "redirect" modifier SHOULD appear as the = very last
=A0 =A0term in a record.

I don't usually recommend repeating things, but one thing from earlier<= br> probably does bear repeating here:

NEW
=A0 =A0For clarity, any "redirect" modifier SHOULD appear as the = very last
=A0 =A0term in a record. =A0Any "redirect" modifier MUST be ignor= ed if there
=A0 =A0is an "all" mechanism anywhere in the record.
END


Seems reasonable.

= -MSK
--047d7bd91a04e9bbab04e61ee240-- From spf2@kitterman.com Wed Sep 11 11:02: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 F094621F9BC1 for ; Wed, 11 Sep 2013 11:02:07 -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 sHgA7eqN5QAh for ; Wed, 11 Sep 2013 11:02:03 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id E913021F84CD for ; Wed, 11 Sep 2013 11:02:02 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 44CF7D04089; Wed, 11 Sep 2013 14:01:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1378922518; bh=+72vR6F7Y1wQi0fAs5GkxPh5JbzFNlT9ABx6YOa0JDs=; h=In-Reply-To:References:Subject:From:Date:To:From; b=NQ5I8+W7G0+x2GDGSCMwmraip6OYX7r+nEvP/QCYfwFrqGqWHE32NmYOnX+TO485R lEqPRkVsTkK03w0SkLpdG2gw29QiokNtzuOb2xZbSvWTWDEp29WpeuKCgRK2heXI7Y b1iVIVk7Z29PTGRUOlBapBs/cDQ4C0H5w48F28yI= Received: from [IPV6:2600:1003:b00a:49d5:f229:bcc4:d245:10a] (unknown [IPv6:2600:1003:b00a:49d5:f229:bcc4:d245:10a]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id D9AFDD0401E; Wed, 11 Sep 2013 14:01:57 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <10370218.OEr9JV8dgx@scott-latitude-e6320> <4509124.Paquit6mK7@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 11 Sep 2013 14:02:13 -0400 To: "spfbis@ietf.org" Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 18:02:13 -0000 "Murray S. Kucherawy" wrote: >On Wed, Sep 11, 2013 at 9:54 AM, Scott Kitterman >wrote: > >> > Drop one of those "and"s. I don't care which one. >> >> Fixed. >> > >The WG may disagree with the choice you made as to which one you >removed. >Be prepared to explain it. > > >> > > are unique and very, very unlikely to be repeated. If a >future >> > > update to a new SPF version that could not reuse existing SPF >> records >> > > were to be developed, it ought to use the SPF RR type. SPF's >use of >> > > the TXT RR type for structured data should in no way be taken >as >> > > precedent for future protocol designers. Things have changed. >> > >> > What about "SPF's use of the TXT RR type located at the domain >apex"? >> As I >> > understand it, part of the complaint is the location of the record, >not >> > just its type. The underscore mechanism used by DKIM, DMARC, ADSP, >VBR, >> > etc. seems to be gaining acceptance, or at least tolerance, because >it >> > avoids query collisions. >> > >> > Otherwise, looks okay to me. >> >> Given the discuss, I don't think so. Here's the text of the DISCUSS: >> >> > Text needs to be created (probably for section 3.1) to better >describe >> > the reason this document settled on TXT RR only and therefore why >no >> > precedent is set for future use of the TXT RR. >> >> I think adding something "if you use TXT anyway, use this underscore >> mechanism" isn't germane since it wasn't an option SPFbis could >consider. >> >> I can add something along those lines, I guess, but I'm not sure it's >> needed. >> >> >My issue is that the second-last sentence there basically says "don't >use >TXT for structured data in the future" as a pretty absolute thing, but >in >fact the underscore "loophole" is currently something the community is >tolerating. It seems incorrect. I know underscore wasn't an option >for >us, but as pedagogy for future protocol developers, it doesn't tell the >whole story either. I agree. I wasn't trying to to the whole story. I was trying to address the issue that was raised. In case Pete wants to include something about the "underscore loophole", would you suggest text please? Scott K From sm@elandsys.com Wed Sep 11 13:46: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 1CB3B21F9D8D for ; Wed, 11 Sep 2013 13:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 5jzujg8KAjUQ for ; Wed, 11 Sep 2013 13:46: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 610B421F9D87 for ; Wed, 11 Sep 2013 13:46:51 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.34]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8BKkWZC010785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Sep 2013 13:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378932408; bh=j39Kx2wU9wXsV83ErIjzdcujxhrTOSf1KYQdw7P9DUQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wS6o+et1cdREBf/PiSReVEfTOf4okt2Nt0QPsRUsjJ9EyqJU3ckG2caggHnx+95Bb feEZ2n0PhQU3ckY4gGJs2MDHNdigOsvWnV4yZbIzx12xPE/aB63oZvSV9GqYWlr8LY kuivwJybp5FBxF2F67TVu/55ptXlKAHcNbXmO5Cg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378932408; i=@elandsys.com; bh=j39Kx2wU9wXsV83ErIjzdcujxhrTOSf1KYQdw7P9DUQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QwgpnI63nchXq+9z2GU6KJjqvlSNV2LkgUuvFF+WR0AGBSiV8NMA9tPPYzh8GzsaO Ja6jgRYWrkdOlfH7Lju80l0Hj+GTiLv5dtXh3DB0NlpEPmXtfIZ9JvCyekj2uXM8nK JfvtR1OFpA9rZSxqDSKxrqFOTIQ0012hxukaIrrQ= Message-Id: <6.2.5.6.2.20130911133726.0ddba740@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Sep 2013 13:45:48 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: References: <20130911015837.30196.11175.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130911050206.0dc1ff68@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 20:46:52 -0000 Hi Scott, For context, Barry's DISCUSS message is at http://www.ietf.org/mail-archive/web/spfbis/current/msg04109.html I went through the comments sent by Murray (Murray, thanks for doing that). There was a comment from Barry: > The example in this section might be published via these lines in a > domain zone file: > > example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" > smtp-out.example.com. TXT "v=spf1 a -all" > >What does "smtp-out" have to do with anything? It's not otherwise used, >and it seems to contradict what you say about subdomains in the previous >paragraph. Could you please respond to the above? Regards, S. Moonesamy (as document shepherd) From spf2@kitterman.com Wed Sep 11 13:54: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 7201621E80E7 for ; Wed, 11 Sep 2013 13:54:06 -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 TC6fhVfqpgzH for ; Wed, 11 Sep 2013 13:54:02 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5732321E80CE for ; Wed, 11 Sep 2013 13:54:02 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 93EF0D04089; Wed, 11 Sep 2013 16:54:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1378932841; bh=TK1oZltYVirfZUr84ZCnU0q2YeY3X8NqxKMiKfH67d0=; h=In-Reply-To:References:Subject:From:Date:To:CC:From; b=D1+Sau5ccDpyHEEAAG0DbTomM/zRba2fc1U6IDVnmFMoadXFlUyFFhKveVMpFnfIA 7RznNwW7damXDwnKpLaaQP8iodDJgxmPN84ld2enMbAjgR6I74aGJgfpoWKWWETF0R AMkbsq8uI7u1BM8S5PgOyeEj0cdX24Nf2m7rsZOY= Received: from [IPV6:2600:1003:b00a:49d5:d4e4:e314:555a:211d] (unknown [IPv6:2600:1003:b00a:49d5:d4e4:e314:555a:211d]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 28A4BD04053; Wed, 11 Sep 2013 16:54:00 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20130911133726.0ddba740@elandnews.com> References: <20130911015837.30196.11175.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130911050206.0dc1ff68@elandnews.com> <6.2.5.6.2.20130911133726.0ddba740@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 11 Sep 2013 16:54:23 -0400 To: S Moonesamy Message-ID: <465f7cf5-94a5-4354-8f84-cce01601f471@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Cc: spfbis@ietf.org Subject: Re: [spfbis] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 20:54:06 -0000 Will do shortly. Scott K S Moonesamy wrote: >Hi Scott, > >For context, Barry's DISCUSS message is at >http://www.ietf.org/mail-archive/web/spfbis/current/msg04109.html I >went through the comments sent by Murray (Murray, thanks for doing >that). > >There was a comment from Barry: > >> The example in this section might be published via these lines in >a >> domain zone file: >> >> example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" >> smtp-out.example.com. TXT "v=spf1 a -all" >> >>What does "smtp-out" have to do with anything? It's not otherwise >used, >>and it seems to contradict what you say about subdomains in the >previous >>paragraph. > >Could you please respond to the above? > >Regards, >S. Moonesamy (as document shepherd) From sm@elandsys.com Wed Sep 11 13:54: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 8433221E80E2 for ; Wed, 11 Sep 2013 13:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 sEqx5kAfprr0 for ; Wed, 11 Sep 2013 13:54: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 3C67A21E80CE for ; Wed, 11 Sep 2013 13:54:31 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.34]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8BKsIg8022733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Sep 2013 13:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378932870; bh=n54e87Z8eGm/hFanvJJpfo6OzwZh2gG9XugG5by7oBk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pFB03juugOII3RHgv7PspSMgjX3K1QyEpe9OwH8iaFTZh6ltEdxZ5litq4QJ+/Jb7 kNS0aD9P5bPWXcluWM/nMXoEnX08W/n7HTDeFCq1BFNKIgm4IVtJs+kSQvFYklpKzs abuehNS2c9Gok8rivNOBZIslkcIabUVEavww8aXA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378932870; i=@elandsys.com; bh=n54e87Z8eGm/hFanvJJpfo6OzwZh2gG9XugG5by7oBk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NYSPSpsgIv7Kykw34PlbBKr6YzW0APZZ304Mv7BiwvUjFLAIYbADUowUlfOvdhgyZ ez7lIlomXunuaILYWPaT0M+lViodL9guyY0vBNaD4ATqnEQwlbGA0CLXlTxkA0iTMZ zTaYWpptoBOGZzGnjI+N77GOk7nw3ER3cSJUWCI4= Message-Id: <6.2.5.6.2.20130911134838.0c217ca8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Sep 2013 13:53:28 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <5230A523.20504@isdg.net> References: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> <5230A523.20504@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 11 Sep 2013 20:54:32 -0000 Hi Scott, I am copying the parts of the SECDIR review to which there hasn't been any response: Issue 1: >1.1.3. MAIL FROM Definition > >I found this section completely opaque and very confusing. It should >not be necessary to hunt through other specs to find a definition. >Particularly since the referenced specs do not give an explicit >definition for the term as used and the references point to the >whole spec rather than a particular section. Issue 2: >8.7. Permerror > >"This signals an error condition that definitely requires operator >intervention to be resolved." > >I cannot imagine a circumstance which definitely requires a human to >be involved in mail delivery. Issue 3: >11.2. SPF-Authorized Email May Contain Other False Identities > > Do not construe the "MAIL FROM" and "HELO" identity authorizations to > provide more assurance than they do. > >Document has quasi normative language that should be worded as >statements of fact rather than as direction. Could you please comment about the three issues? Thanks, S. Moonesamy (as document shepherd) From superuser@gmail.com Wed Sep 11 14:26:30 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 3F92611E821D for ; Wed, 11 Sep 2013 14:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 kNIM8FrvpqXo for ; Wed, 11 Sep 2013 14:26:29 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id C22F211E8197 for ; Wed, 11 Sep 2013 14:26:28 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id r10so9863049pdi.28 for ; Wed, 11 Sep 2013 14:26:28 -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=E4xl+/QQqpvIv8o7EVxSv5kq+u3VCjSxA5OgQHjSK74=; b=OgfFUT1oPfN4hfIeEPj72NFFmKUcSlCmnRjWmixvinydhcvkboyoUXjkiglOi8Dk9e aV69dg5oKvVmtG46dji4dy4IOYBMgXghSyv6yYRsvybhC7QT7uuAQvLtrooxr6E5xC+3 u27DTe7xfyWotUFmApyJ2wF1fe+WDl0fvOJTjG/WcId3B+6IP8fM5h1CX3/xdtyNSf+N ggfV04M7Tj6NE9ZekTGwVfBROce5Fy/AMJYVjqGkY6RZmE1D0p9bC9o/pOlyeqCxn6Op McUYt3c6NrIn9o5rO2BoQgvgEKi+lg6Aosj5/a/5KrQkXW3J7G8baOxzYDGn7lbDnBR6 ug/g== MIME-Version: 1.0 X-Received: by 10.68.255.69 with SMTP id ao5mr4124713pbd.66.1378934788459; Wed, 11 Sep 2013 14:26:28 -0700 (PDT) Received: by 10.67.5.225 with HTTP; Wed, 11 Sep 2013 14:26:28 -0700 (PDT) In-Reply-To: References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <10370218.OEr9JV8dgx@scott-latitude-e6320> <4509124.Paquit6mK7@scott-latitude-e6320> Date: Wed, 11 Sep 2013 14:26:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7b5d60223c18f104e622466f Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 21:26:30 -0000 --047d7b5d60223c18f104e622466f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 11, 2013 at 11:02 AM, Scott Kitterman wrote: > > I agree. I wasn't trying to to the whole story. I was trying to address > the issue that was raised. > > In case Pete wants to include something about the "underscore loophole", > would you suggest text please? > > Nevermind, Pete talked me out of it. I withdraw the suggestion. -MSK --047d7b5d60223c18f104e622466f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 11, 2013 at 11:02 AM, Scott Kitterman <spf2@= kitterman.com> wrote:

I agree. =A0I wasn't trying to to the whole story. =A0I was= trying to address the issue that was raised.

In case Pete wants to include something about the "underscore loophole= ", would you suggest text please?

<= br>
=A0Nevermind, Pete talked me out of it.=A0 I withdraw the sug= gestion.

-MSK
--047d7b5d60223c18f104e622466f-- From scott@kitterman.com Wed Sep 11 14:38: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 BB42811E81D6 for ; Wed, 11 Sep 2013 14:38:36 -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 d3Nf48EpZJbe for ; Wed, 11 Sep 2013 14:38:32 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A9E4321E80A9 for ; Wed, 11 Sep 2013 14:38:31 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A99B520E40EA; Wed, 11 Sep 2013 17:38:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1378935509; bh=6jaMV6+rDTmc5E1c0jRGMFSWSQQgdAiXXZ62+++eRWg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Nh0DK8j7fHl8ayZ47u6SGNFPW3GV7pQYmM+NZxUffcXtmA5hrSuYJ2qJfJ/0TwqcF DjcNseR7WTXt8OPgvWeJ+l3Z3NNRJ4+6Q5VI0+35AaxyRmPDaANFCOg8OrblfEBkvW LIsX4o/8jf4vpNu2ehWaHNxDD3G8N5yGtB1/wHsw= 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 8AC1720E40D2; Wed, 11 Sep 2013 17:38:29 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 11 Sep 2013 17:38:27 -0400 Message-ID: <1409783.xNJeGdWPul@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: References: <20130911015837.30196.11175.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130911050206.0dc1ff68@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP X-Mailman-Approved-At: Wed, 11 Sep 2013 14:41:40 -0700 Subject: Re: [spfbis] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 21:38:36 -0000 On Wednesday, September 11, 2013 10:23:57 Murray S. Kucherawy wrote: > On Wed, Sep 11, 2013 at 5:04 AM, S Moonesamy wrote: > >> ------------------------------**------------------------------** > >> ---------- > >> COMMENT: > >> ------------------------------**------------------------------** > >> ---------- > >> > >> I have a bunch of editorial comments that I'd like you to consider. > >> They're all non-blocking, but I think they'll improve the document, and > >> I'll be happy to chat about them if you like. > >> > >> -- Section 2.5 -- > >> > >> Performing the authorization check other than using the MAIL FROM and > >> client address at the time of the MAIL command during the SMTP > >> transaction can cause problems, such as the following: (1) It might > >> be difficult to accurately extract the required information from > >> potentially deceptive headers; (2) legitimate email might fail > >> because the sender's policy had since changed. > >> > >> I found that to be awkwardly worded and hard to understand. Please > >> consider this rewrite: > >> > >> NEW > >> > >> The authorization check is performed during the SMTP transaction > >> at the time of the MAIL command, and uses the MAIL FROM value and > >> the client IP address. Performing the check at later times or > >> with other input can cause problems such as the following: > >> > >> * It might be difficult to accurately extract the required > >> > >> information from potentially deceptive headers. > >> > >> * Legitimate email might fail the authorization check because > >> > >> the sender's policy has since changed. > >> > >> END > > Seems reasonable. Agreed. > >> -- Section 2.6 -- > >> > >> It would really read best if the subsections were worded to be parallel. > >> As it stands, subsections 1, 3, 4, 6, and 7 are worded as "result X means > >> Y", and subsections 2 and 5 are not. Can you re-word 2 and 5 to be > >> parallel to the others? > > Seems reasonable. Agreed. > >> Also, why are "neutral" and "fail" called "explicit statements", but > >> "pass", for example, is not? > > I agree, "pass" should be. Yep. > >> -- Section 3 -- > >> > >> Each SPF record is placed in the DNS tree at the owner name it > >> pertains to, not a subdomain under it, such as is done with SRV > >> records [RFC2782]. > >> > >> This looks like it's saying that SRV records are placed in subdomains, > >> and I don't think that's what you mean. Or is it? In any case, it's not > >> clear (and I know this text is from the original). > >> > >> Maybe this (which also avoids the two different "it"s)?: > >> > >> NEW > >> > >> Each SPF record is placed in the DNS tree at the owner name it > >> pertains to, not in a subdomain under the owner name. This is > >> similar to how SRV records [RFC2782] are done. > >> > >> END > > Seems reasonable. Agreed. > >> The example in this section might be published via these lines in a > >> domain zone file: > >> example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" > >> smtp-out.example.com. TXT "v=spf1 a -all" > >> > >> What does "smtp-out" have to do with anything? It's not otherwise used, > >> and it seems to contradict what you say about subdomains in the previous > >> paragraph. > > Hmm. Someone else will have to comment on this one. Those are just two examples, but the preceding text is poorly worded (I checked and it's no better in RFC 4408). How about this instead, to clarify: The example in this section (plus an additional SPF record for smtp-out.example.com) might be published via these lines in a domain zone file: example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" smtp-out.example.com. TXT "v=spf1 a -all" > >> -- Section 4 -- > >> > >> This description is not an API (Application Program Interface) > >> definition, > >> > >> Two total nits on this: > >> 1. You never use "API" other than here, so there's no need to define it, > >> and > >> 2. the usual expansion of "API" is application programMING interface. > >> I suggest, "This description is not an application programming interface > >> definition, [etc]." > > Seems reasonable. Agreed. > >> -- Section 4.5 -- > >> > >> Starting with the set of records that were returned by the lookup, > >> discard records that do not begin with a version section of exactly > >> "v=spf1". Note that the version section is terminated either by an > >> SP character or the end of the record. A record with a version > >> section of "v=spf10" does not match and is discarded. > >> > >> Sure, and "v=spf1.0" doesn't match, and "v=spf11" doesn't match, and.... > >> Why is it necessary or desirable to single out "v=spf10" here? > > I think "v=spf1.0" is actually the better (and perhaps intended) example, > meaning "don't just stuff the part after 'spf' through a number parser and > make sure 1 comes out". The intent here is to show that you have to look at least one character past "v=spf1" to know if it's an SPF record or not. It's an example. As such, it doesn't matter much wrt the point if it's "v=spf10", "v=spf1.0", or or "v=spf1hatespf". None of those start SPF records. What's there is unchanged from RFC 4408. I don't seem much of a point in changing it, but if others think 1.0 is better than 10, I don't mind. > >> -- Section 4.6.4 -- > >> > >> SPF implementations MUST limit the total number of mechanisms and > >> modifiers ("terms") that cause any DNS query to 10 during SPF > >> evaluation. Specifically, the "include", "a", "mx", "ptr", and > >> "exists" mechanisms as well as the "redirect" modifier count against > >> this collective limit. The "all", "ip4", and "ip6" mechanisms do not > >> count against this limit. If this number is exceeded during a check, > >> a "permerror" MUST be returned. The "exp" modifier does not count > >> against this limit because the DNS lookup to fetch the explanation > >> string occurs after the SPF record evaluation has been completed. > >> > >> When I read this, I start feeling like I'm being read the rules for > >> Fizzbin > >> >> wiki/Fizzbin#Fizzbin>>.>> > >> I would > >> > >> appreciate it if this was re-worded so that there are two clear lists > >> here: the terms that are included in the "limit of 10", and the terms > >> that are not (and are, presumably, unlimited). Perhaps something like > >> this: > >> > >> NEW > >> > >> Some mechanisms and modifiers (collectively, "terms") cause DNS > >> queries at the time of evaluation, and some do not. The following > >> terms cause DNS queries: . SPF implementations > >> MUST limit the total number of those terms to 10 during SPF > >> evaluation, to avoid unreasonable load on the DNS. If this limit > >> is exceeded, the implementation MUST return "permerror". The other > >> terms () do not cause DNS queries at the time of > >> SPF evaluation, and their use is not subject to this limit. > >> > >> END > >> > >> If you think it's necessary (I don't): > >> > >> NEW+ > >> > >> The other > >> terms () do not cause DNS queries at the time of > >> SPF evaluation (the "exp" modifier causes a lookup at a later time), > >> and their use is not subject to this limit. > >> > >> END > > I like the new text, and prefer the second bit be included. If we change, and I think that's reasonable, the second bit should definitely be included. "exp" not counting in the 10 has confused people and we should be explicit about it. > >> Then in the next two paragraphs, I think it would improve clarity to make > >> a change such as this: > >> > >> OLD > >> > >> When evaluating the "mx" mechanism, the number of "MX" resource > >> records queried is included in the overall limit of 10 mechanisms/ > >> modifiers that cause DNS lookups described above. The evaluation of > >> each "MX" record MUST NOT result in querying more than 10 address > >> records, > >> > >> NEW > >> > >> When evaluating the "mx" mechanism, the number of "MX" resource > >> records queried is included in the overall limit of 10 mechanisms/ > >> modifiers that cause DNS lookups described above. In addition to > >> that limit, the evaluation of each "MX" record MUST NOT result in > >> querying more than 10 address records, > >> > >> END > >> > >> (And similarly for the "ptr" paragraph.) I know you say this in a > >> paragraph of its own ("These limits are per mechanism..."), but it's > >> helpful if people can understand things as they read them, and then to > >> emphasize it later... rather than having them scratch their heads for a > >> few paragraphs until they get to it. > > +1 to that part too. Seems reasonable. > > -- Section 4.7 -- > > > >> It is better to use either a "redirect" modifier or an "all" > >> mechanism to explicitly terminate processing. Although the latter > >> has a default (specifically "?all"), it aids debugging efforts if it > >> is explicitly provided. > >> > >> I'm not sure what "the latter has a default" is trying to say. Do you > >> mean that "?all" is the default if you fall off the end, but you > >> shouldn't rely on that? Or do you mean that if you say "all", then > >> "?all" is taken as the default (I would think "all" would mean "+all")? > >> Will you try re-wording this, please? > > The former ("?all" is implicit if you fall off the end). Suggest: > > It is better to use either a "redirect" modifier or an "all" mechanism to > explicitly terminate processing. Although there is in effect a "?all" > implicit at the end of every record, it ads debigging efforts when it is > explicitly provided. How about: It is better to use either a "redirect" modifier or an "all" mechanism to explicitly terminate processing. Although there is an implicit "?all" at the end of every record that is not explicitly terminated, it aids debugging efforts when it is explicitly provided. > >> -- Section 5 -- > >> > >> What does "(do not publish)" mean next to "ptr" in the sender mechanisms > >> list? Ah; I see; it matches the "do not use" in Section 5.5. You should > >> probably change this to "(do not use; see the note in Section 5.5)". > > Seems reasonable. OK. > >> It would help, I think, to add to the end of the second paragraph, "The > >> basic mechanisms are as follows:", and to the end of the third paragraph, > >> "The designated sender mechanisms are as follows:". Otherwise, there are > >> just these disembodied lists, and the reader has to infer those > >> introductions. > > Sure. Agreed. > >> -- Section 5.1 -- > >> > >> Mechanisms after "all" will never be tested. Mechanisms listed after > >> "all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST be > >> ignored when there is an "all" mechanism in the record. > >> > >> This says that the redirect in the following record will be ignored: > >> v=spf1 redirect=_spf.example.com +all > >> > >> That's sufficiently odd that it should be called out explicitly, perhaps > >> by adding "regardless of the relative ordering of the terms" to the last > >> sentence in the quote. > > Yep. OK. > >> -- Section 5.2 -- > >> > >> 3. The recursive evaluation returns either match, not match, or an > >> error. If it matches, then the appropriate result for the > >> include: mechanism is used (e.g. include or +include produces a > >> "pass" result and -include produces "fail"). > >> > >> 4. If there is no match, the parent check_host() resumes processing > >> as per the table below, with the previous value of > >> restored. > >> > >> A few things here: > >> > >> 1. Nit: "either" is for two things; for more than two, please remove the > >> word "either" (or replace it with "one of", but that seems awkward > >> here). > >> > >> 2. "If it matches" is not parallel to "returns match", and similarly for > >> "if there is no match". > >> > >> 3. You don't say what happens if the recursive evaluation returns an > >> error. Unfortuately, "no match" and "not match" are sufficiently similar > >> to be confused. > >> > >> I suggest this: > >> > >> NEW > >> > >> 3. The recursive evaluation returns match, not match, or an > >> error. > >> > >> 4. If it returns match, then the appropriate result for the > >> include: mechanism is used (e.g., include or +include produces > >> a "pass" result and -include produces "fail"). > >> > >> 5. If it returns not match or an error, the parent check_host() > >> resumes processing as per the table below, with the previous > >> value of restored. > >> > >> END > > +1. I think this is fine. > >> The "include" mechanism is intended for crossing administrative > >> boundaries. For example, if example.com and example.org were managed > >> by the same entity, and if the permitted set of hosts for both > >> domains was "mx:example.com", it would be possible for example.org to > >> specify "include:example.com", but it would be preferable to specify > >> "redirect=example.com" or even "mx:example.com". > >> > >> The text you eliminated here provided a buffer that's no longer there, > >> making the "For example," very odd. You talk about crossing admin > >> boundaries and immediately follow it with an example that does NOT. I > >> think it would be better to put a sentence in to restore that buffer -- > >> perhaps, "When remaining within one administrative authority, "include" > >> is usually not the best choice." > > Sure. Agreed. > >> -- Section 5.5 -- > >> > >> This mechanism SHOULD NOT be published. See below for discussion. > >> > >> It's quite a bit below. I suggest "See the note at the end of this > >> section for more information." It might even be worth putting that note > >> into a Section 5.5.1, so it's highlighted and more easily cited. > > +1. OK. Someone let me know which way I should do it. I'm OK with either. > >> -- Section 6 -- > >> > >> Unrecognized modifiers MUST be ignored no matter where in a record, > >> or how often. > >> > >> This is missing a couple of words: > >> > >> NEW > >> > >> Unrecognized modifiers MUST be ignored no matter where in a record > >> they appear, or how often. > >> > >> END > > +1. OK. > >> For clarity, any "redirect" modifier SHOULD appear as the very last > >> term in a record. > >> > >> I don't usually recommend repeating things, but one thing from earlier > >> probably does bear repeating here: > >> > >> NEW > >> > >> For clarity, any "redirect" modifier SHOULD appear as the very last > >> term in a record. Any "redirect" modifier MUST be ignored if there > >> is an "all" mechanism anywhere in the record. > >> > >> END > > Seems reasonable. OK. Thanks for the detailed review and msk's comments on the comments. Scott K From sm@elandsys.com Wed Sep 11 14:52: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 2C79011E8106; Wed, 11 Sep 2013 14:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 uMqaVAARfdd3; Wed, 11 Sep 2013 14:52:02 -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 EDD1621F9A44; Wed, 11 Sep 2013 14:52:01 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.34]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8BLpUoq012270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Sep 2013 14:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378936305; bh=rnFmKwzOSAUZOMxqWaq/0ptnnmutlZZ4kOEJZKsZh2c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2ldakebpgacxN9PxAKEP5NlxN53rCOC0sUUtlp3kbJEymEDk8IlbOAq1gefYMcB3Z cE/zKOeAAqqQ3n3DaJV7Q+mIS/P/TBIPqski0se5lrdH/P28B7uZG5TFRl86Pcj/2s qLCCimEoQBgrDY7fpcVjCAmmGDikTbpGFqn1cx6A= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378936305; i=@elandsys.com; bh=rnFmKwzOSAUZOMxqWaq/0ptnnmutlZZ4kOEJZKsZh2c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NiUmlBfloRo2tTU5o9qhrKYRZ0++N+oFWHRzVNd/DRoZnAgc0kOY4k6p1E5ISBjXH mrLO6DDrgbZN/s/RA6N5oYDlmNHUFLf+f7VSZVxxrEs+bQfQfiZ6lA78ipmJRLzOWC YcKKnwl0sWxf4eFlnFmoIZ5Uwg6/bhy6Mu9eW8XE= Message-Id: <6.2.5.6.2.20130911144430.0c3f7f78@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Sep 2013 14:51:14 -0700 To: Barry Leiba From: S Moonesamy In-Reply-To: <1409783.xNJeGdWPul@scott-latitude-e6320> References: <20130911015837.30196.11175.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130911050206.0dc1ff68@elandnews.com> <1409783.xNJeGdWPul@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG Subject: Re: [spfbis] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 21:52:04 -0000 Hi Barry, Scott and Murray are okay with the text you suggested to address the DISCUSS ( http://www.ietf.org/mail-archive/web/spfbis/current/msg04114.html ). The SPFBIS WG seems okay with most of the text you suggested as COMMENT. There are some comments from Scott (see below) for the rest. Regards, S. Moonesamy At 14:38 11-09-2013, Scott Kitterman wrote: >On Wednesday, September 11, 2013 10:23:57 Murray S. Kucherawy wrote: > > On Wed, Sep 11, 2013 at 5:04 AM, S Moonesamy wrote: > > >> ------------------------------**------------------------------** > > >> ---------- > > >> COMMENT: > > >> ------------------------------**------------------------------** > > >> ---------- > > >> > > >> I have a bunch of editorial comments that I'd like you to consider. > > >> They're all non-blocking, but I think they'll improve the document, and > > >> I'll be happy to chat about them if you like. > > >> > > >> -- Section 2.5 -- > > >> > > >> Performing the authorization check other than using the MAIL FROM and > > >> client address at the time of the MAIL command during the SMTP > > >> transaction can cause problems, such as the following: (1) It might > > >> be difficult to accurately extract the required information from > > >> potentially deceptive headers; (2) legitimate email might fail > > >> because the sender's policy had since changed. > > >> > > >> I found that to be awkwardly worded and hard to understand. Please > > >> consider this rewrite: > > >> > > >> NEW > > >> > > >> The authorization check is performed during the SMTP transaction > > >> at the time of the MAIL command, and uses the MAIL FROM value and > > >> the client IP address. Performing the check at later times or > > >> with other input can cause problems such as the following: > > >> > > >> * It might be difficult to accurately extract the required > > >> > > >> information from potentially deceptive headers. > > >> > > >> * Legitimate email might fail the authorization check because > > >> > > >> the sender's policy has since changed. > > >> > > >> END > > > > Seems reasonable. > >Agreed. > > > >> -- Section 2.6 -- > > >> > > >> It would really read best if the subsections were worded to be parallel. > > >> As it stands, subsections 1, 3, 4, 6, and 7 are worded as > "result X means > > >> Y", and subsections 2 and 5 are not. Can you re-word 2 and 5 to be > > >> parallel to the others? > > > > Seems reasonable. > >Agreed. > > > >> Also, why are "neutral" and "fail" called "explicit statements", but > > >> "pass", for example, is not? > > > > I agree, "pass" should be. > >Yep. > > > >> -- Section 3 -- > > >> > > >> Each SPF record is placed in the DNS tree at the owner name it > > >> pertains to, not a subdomain under it, such as is done with SRV > > >> records [RFC2782]. > > >> > > >> This looks like it's saying that SRV records are placed in subdomains, > > >> and I don't think that's what you mean. Or is it? In any > case, it's not > > >> clear (and I know this text is from the original). > > >> > > >> Maybe this (which also avoids the two different "it"s)?: > > >> > > >> NEW > > >> > > >> Each SPF record is placed in the DNS tree at the owner name it > > >> pertains to, not in a subdomain under the owner name. This is > > >> similar to how SRV records [RFC2782] are done. > > >> > > >> END > > > > Seems reasonable. > >Agreed. > > > >> The example in this section might be published via these lines in a > > >> domain zone file: > > >> example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" > > >> smtp-out.example.com. TXT "v=spf1 a -all" > > >> > > >> What does "smtp-out" have to do with anything? It's not otherwise used, > > >> and it seems to contradict what you say about subdomains in the previous > > >> paragraph. > > > > Hmm. Someone else will have to comment on this one. > >Those are just two examples, but the preceding text is poorly worded (I >checked and it's no better in RFC 4408). How about this instead, to clarify: > > The example in this section (plus an additional SPF record for > smtp-out.example.com) might be published via these lines in a > domain zone file: > > example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" > smtp-out.example.com. TXT "v=spf1 a -all" > > > > >> -- Section 4 -- > > >> > > >> This description is not an API (Application Program Interface) > > >> definition, > > >> > > >> Two total nits on this: > > >> 1. You never use "API" other than here, so there's no need to define it, > > >> and > > >> 2. the usual expansion of "API" is application programMING interface. > > >> I suggest, "This description is not an application programming interface > > >> definition, [etc]." > > > > Seems reasonable. > >Agreed. > > > >> -- Section 4.5 -- > > >> > > >> Starting with the set of records that were returned by the lookup, > > >> discard records that do not begin with a version section of exactly > > >> "v=spf1". Note that the version section is terminated either by an > > >> SP character or the end of the record. A record with a version > > >> section of "v=spf10" does not match and is discarded. > > >> > > >> Sure, and "v=spf1.0" doesn't match, and "v=spf11" doesn't match, and.... > > >> Why is it necessary or desirable to single out "v=spf10" here? > > > > I think "v=spf1.0" is actually the better (and perhaps intended) example, > > meaning "don't just stuff the part after 'spf' through a number parser and > > make sure 1 comes out". > >The intent here is to show that you have to look at least one character past >"v=spf1" to know if it's an SPF record or not. It's an example. As such, it >doesn't matter much wrt the point if it's "v=spf10", "v=spf1.0", or or >"v=spf1hatespf". None of those start SPF records. What's there is unchanged >from RFC 4408. I don't seem much of a point in changing it, but if others >think 1.0 is better than 10, I don't mind. > > > >> -- Section 4.6.4 -- > > >> > > >> SPF implementations MUST limit the total number of mechanisms and > > >> modifiers ("terms") that cause any DNS query to 10 during SPF > > >> evaluation. Specifically, the "include", "a", "mx", "ptr", and > > >> "exists" mechanisms as well as the "redirect" modifier count against > > >> this collective limit. The "all", "ip4", and "ip6" mechanisms do not > > >> count against this limit. If this number is exceeded during a check, > > >> a "permerror" MUST be returned. The "exp" modifier does not count > > >> against this limit because the DNS lookup to fetch the explanation > > >> string occurs after the SPF record evaluation has been completed. > > >> > > >> When I read this, I start feeling like I'm being read the rules for > > >> Fizzbin > > >> > > >> wiki/Fizzbin#Fizzbin>>.>> > > >> I would > > >> > > >> appreciate it if this was re-worded so that there are two clear lists > > >> here: the terms that are included in the "limit of 10", and the terms > > >> that are not (and are, presumably, unlimited). Perhaps something like > > >> this: > > >> > > >> NEW > > >> > > >> Some mechanisms and modifiers (collectively, "terms") cause DNS > > >> queries at the time of evaluation, and some do not. The following > > >> terms cause DNS queries: . SPF implementations > > >> MUST limit the total number of those terms to 10 during SPF > > >> evaluation, to avoid unreasonable load on the DNS. If this limit > > >> is exceeded, the implementation MUST return "permerror". The other > > >> terms () do not cause DNS queries at the time of > > >> SPF evaluation, and their use is not subject to this limit. > > >> > > >> END > > >> > > >> If you think it's necessary (I don't): > > >> > > >> NEW+ > > >> > > >> The other > > >> terms () do not cause DNS queries at the time of > > >> SPF evaluation (the "exp" modifier causes a lookup at a later time), > > >> and their use is not subject to this limit. > > >> > > >> END > > > > I like the new text, and prefer the second bit be included. > >If we change, and I think that's reasonable, the second bit should definitely >be included. "exp" not counting in the 10 has confused people and we should >be explicit about it. > > > >> Then in the next two paragraphs, I think it would improve > clarity to make > > >> a change such as this: > > >> > > >> OLD > > >> > > >> When evaluating the "mx" mechanism, the number of "MX" resource > > >> records queried is included in the overall limit of 10 mechanisms/ > > >> modifiers that cause DNS lookups described above. The evaluation of > > >> each "MX" record MUST NOT result in querying more than 10 address > > >> records, > > >> > > >> NEW > > >> > > >> When evaluating the "mx" mechanism, the number of "MX" resource > > >> records queried is included in the overall limit of 10 mechanisms/ > > >> modifiers that cause DNS lookups described above. In addition to > > >> that limit, the evaluation of each "MX" record MUST NOT result in > > >> querying more than 10 address records, > > >> > > >> END > > >> > > >> (And similarly for the "ptr" paragraph.) I know you say this in a > > >> paragraph of its own ("These limits are per mechanism..."), but it's > > >> helpful if people can understand things as they read them, and then to > > >> emphasize it later... rather than having them scratch their heads for a > > >> few paragraphs until they get to it. > > > > +1 to that part too. > >Seems reasonable. > > > > -- Section 4.7 -- > > > > > >> It is better to use either a "redirect" modifier or an "all" > > >> mechanism to explicitly terminate processing. Although the latter > > >> has a default (specifically "?all"), it aids debugging efforts if it > > >> is explicitly provided. > > >> > > >> I'm not sure what "the latter has a default" is trying to say. Do you > > >> mean that "?all" is the default if you fall off the end, but you > > >> shouldn't rely on that? Or do you mean that if you say "all", then > > >> "?all" is taken as the default (I would think "all" would mean "+all")? > > >> Will you try re-wording this, please? > > > > The former ("?all" is implicit if you fall off the end). Suggest: > > > > It is better to use either a "redirect" modifier or an "all" mechanism to > > explicitly terminate processing. Although there is in effect a "?all" > > implicit at the end of every record, it ads debigging efforts when it is > > explicitly provided. > >How about: > > It is better to use either a "redirect" modifier or an "all" mechanism to > explicitly terminate processing. Although there is an implicit "?all" at > the end of every record that is not explicitly terminated, it aids > debugging efforts when it is explicitly provided. > > > >> -- Section 5 -- > > >> > > >> What does "(do not publish)" mean next to "ptr" in the sender mechanisms > > >> list? Ah; I see; it matches the "do not use" in Section > 5.5. You should > > >> probably change this to "(do not use; see the note in Section 5.5)". > > > > Seems reasonable. > >OK. > > > >> It would help, I think, to add to the end of the second paragraph, "The > > >> basic mechanisms are as follows:", and to the end of the third > paragraph, > > >> "The designated sender mechanisms are as > follows:". Otherwise, there are > > >> just these disembodied lists, and the reader has to infer those > > >> introductions. > > > > Sure. > >Agreed. > > > >> -- Section 5.1 -- > > >> > > >> Mechanisms after "all" will never be tested. Mechanisms listed after > > >> "all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST be > > >> ignored when there is an "all" mechanism in the record. > > >> > > >> This says that the redirect in the following record will be ignored: > > >> v=spf1 redirect=_spf.example.com +all > > >> > > >> That's sufficiently odd that it should be called out explicitly, perhaps > > >> by adding "regardless of the relative ordering of the terms" to the last > > >> sentence in the quote. > > > > Yep. > >OK. > > > >> -- Section 5.2 -- > > >> > > >> 3. The recursive evaluation returns either match, not match, or an > > >> error. If it matches, then the appropriate result for the > > >> include: mechanism is used (e.g. include or +include produces a > > >> "pass" result and -include produces "fail"). > > >> > > >> 4. If there is no match, the parent check_host() resumes processing > > >> as per the table below, with the previous value of > > >> restored. > > >> > > >> A few things here: > > >> > > >> 1. Nit: "either" is for two things; for more than two, please remove the > > >> word "either" (or replace it with "one of", but that seems awkward > > >> here). > > >> > > >> 2. "If it matches" is not parallel to "returns match", and similarly for > > >> "if there is no match". > > >> > > >> 3. You don't say what happens if the recursive evaluation returns an > > >> error. Unfortuately, "no match" and "not match" are > sufficiently similar > > >> to be confused. > > >> > > >> I suggest this: > > >> > > >> NEW > > >> > > >> 3. The recursive evaluation returns match, not match, or an > > >> error. > > >> > > >> 4. If it returns match, then the appropriate result for the > > >> include: mechanism is used (e.g., include or +include produces > > >> a "pass" result and -include produces "fail"). > > >> > > >> 5. If it returns not match or an error, the parent check_host() > > >> resumes processing as per the table below, with the previous > > >> value of restored. > > >> > > >> END > > > > +1. > >I think this is fine. > > > >> The "include" mechanism is intended for crossing administrative > > >> boundaries. For example, if example.com and example.org were managed > > >> by the same entity, and if the permitted set of hosts for both > > >> domains was "mx:example.com", it would be possible for example.org to > > >> specify "include:example.com", but it would be preferable to specify > > >> "redirect=example.com" or even "mx:example.com". > > >> > > >> The text you eliminated here provided a buffer that's no longer there, > > >> making the "For example," very odd. You talk about crossing admin > > >> boundaries and immediately follow it with an example that does NOT. I > > >> think it would be better to put a sentence in to restore that buffer -- > > >> perhaps, "When remaining within one administrative authority, "include" > > >> is usually not the best choice." > > > > Sure. > >Agreed. > > > >> -- Section 5.5 -- > > >> > > >> This mechanism SHOULD NOT be published. See below for discussion. > > >> > > >> It's quite a bit below. I suggest "See the note at the end of this > > >> section for more information." It might even be worth putting that note > > >> into a Section 5.5.1, so it's highlighted and more easily cited. > > > > +1. > >OK. Someone let me know which way I should do it. I'm OK with either. > > > >> -- Section 6 -- > > >> > > >> Unrecognized modifiers MUST be ignored no matter where in a record, > > >> or how often. > > >> > > >> This is missing a couple of words: > > >> > > >> NEW > > >> > > >> Unrecognized modifiers MUST be ignored no matter where in a record > > >> they appear, or how often. > > >> > > >> END > > > > +1. > >OK. > > > >> For clarity, any "redirect" modifier SHOULD appear as the very last > > >> term in a record. > > >> > > >> I don't usually recommend repeating things, but one thing from earlier > > >> probably does bear repeating here: > > >> > > >> NEW > > >> > > >> For clarity, any "redirect" modifier SHOULD appear as the very last > > >> term in a record. Any "redirect" modifier MUST be ignored if there > > >> is an "all" mechanism anywhere in the record. > > >> > > >> END > > > > Seems reasonable. > >OK. > >Thanks for the detailed review and msk's comments on the comments. > >Scott K From spf2@kitterman.com Wed Sep 11 14:53: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 BD65211E820F for ; Wed, 11 Sep 2013 14:53:40 -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 RVK7smeLrK6p for ; Wed, 11 Sep 2013 14:53:32 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E990B11E8106 for ; Wed, 11 Sep 2013 14:53:31 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5699320E40EA; Wed, 11 Sep 2013 17:53:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1378936411; bh=kuwe6jnOqhWgqoirYP0CWF8A9WrYWV9MQRQhteQLxlk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=C837U/eaG8MyJoOv5kCrgC9fT1TSYlDDBK+1zDKWPRkJElTDLGM6UarKJZ+lamuDk pbVNK+CoQBMnFeodezH0l/xLtVVfIDwEW6OJRXJ6ryASrfb+1IMiyZEiuSjjZ52+7E lMULKch6J/o8gyTLSK2tQeKaEG6pTmDFrnR3mffo= 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 39AE920E40D2; Wed, 11 Sep 2013 17:53:30 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 11 Sep 2013 17:53:30 -0400 Message-ID: <2297109.DlIYn73fZN@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130911134838.0c217ca8@resistor.net> References: <5230A523.20504@isdg.net> <6.2.5.6.2.20130911134838.0c217ca8@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] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 11 Sep 2013 21:53:44 -0000 On Wednesday, September 11, 2013 13:53:28 S Moonesamy wrote: > Hi Scott, > > I am copying the parts of the SECDIR review to which there hasn't > been any response: > > Issue 1: > >1.1.3. MAIL FROM Definition > > > >I found this section completely opaque and very confusing. It should > >not be necessary to hunt through other specs to find a definition. > >Particularly since the referenced specs do not give an explicit > >definition for the term as used and the references point to the > >whole spec rather than a particular section. It's a challenge, but I think it's better than inventing a new definition for SPF that may be different. Would someone be willing to dive into the relevant RFCs and see if they can make a recommendation about how better to reference this? > Issue 2: > >8.7. Permerror > > > >"This signals an error condition that definitely requires operator > >intervention to be resolved." > > > >I cannot imagine a circumstance which definitely requires a human to > >be involved in mail delivery. These are permanent DNS errors or SPF record errors. For example, if an SPF record requires too many DNS lookups, someone has to change the record to make the error go away. The definitely was intended to distinguish from cases such as a DNS SERVFAIL that may or may not be permanent, but are temperrors in SPF. In the case of ambiguity about if an error is temporary or permanent, it's treated in the design as assumed to be temporary. If this is confusing, someone please suggest an alternative. > Issue 3: > >11.2. SPF-Authorized Email May Contain Other False Identities > > > > Do not construe the "MAIL FROM" and "HELO" identity authorizations to > > provide more assurance than they do. > > > >Document has quasi normative language that should be worded as > >statements of fact rather than as direction. How about: The "MAIL FROM" and "HELO" identity authorizations do not provide assurance about the authorization/authenticity of other identities used in the message. > Could you please comment about the three issues? See above. Scott K From presnick@qti.qualcomm.com Wed Sep 11 14:57: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 20B0021F8415; Wed, 11 Sep 2013 14:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.542 X-Spam-Level: X-Spam-Status: No, score=-105.542 tagged_above=-999 required=5 tests=[AWL=1.057, 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 2uXbuf9YuR51; Wed, 11 Sep 2013 14:57:03 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 8C49721F8EDF; Wed, 11 Sep 2013 14:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1378936619; x=1410472619; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=56fHyYqCFdRXsnhNhPIjwDx8jxPr4AIBcQgU6Ryxysw=; b=ap2GEdSlCxTjJmtta4aU/tGDexylZnaXAb7OV+QhKdOPiWLZ5wv0lhZL Nn+A8p4W7ph8hjdbl00Tkyd4i+NAo+nC8Mf3/HRWWNDZfDudnyUMP3yK/ norKeJ8CCwnqWTlluTT9O031Im1TtLwx1rdYfc6o4g6Dj2EwIkzYu3Mcm s=; X-IronPort-AV: E=McAfee;i="5400,1158,7195"; a="73777133" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine01.qualcomm.com with ESMTP; 11 Sep 2013 14:56:55 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7195"; a="19258360" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Sep 2013 14:56:55 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.146.2; Wed, 11 Sep 2013 14:56:54 -0700 Message-ID: <5230E724.8000703@qti.qualcomm.com> Date: Wed, 11 Sep 2013 16:56:52 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Hector Santos References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130910113052.0c339a60@elandnews.com> <522F7A8F.5060807@gmail.com> <10370218.OEr9JV8dgx@scott-latitude-e6320> <52303A4A.5070303@isdg.net> In-Reply-To: <52303A4A.5070303@isdg.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: S Moonesamy , spfbis@ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, Scott Kitterman , The IESG , spfbis-chairs@tools.ietf.org, Spencer Dawkins Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 21:57:16 -0000 On 9/11/13 4:39 AM, Hector Santos wrote: > On 9/10/2013 9:38 PM, Scott Kitterman wrote: >> In 2003, when SPF was first being developed, the requirements for >> assignment of a new DNS RR type were considerably more stringent >> than >> they are now. I think this is reasonable to leave in, Hector's comments notwithstanding. It may not have been the primary problem, but it certainly didn't help. >> As a result, at that time, there was no reasonable >> alternative to using the TXT RR type for SPF records. No need to be overly proud here. I suggest, "As a result, proponents of SPF found it easier and more practical to use the TXT RR type for SPF records." >> In its review of [RFC4408] the SPFbis working group concluded that >> its dual RR type transition model was fundamentally flawed since it >> contained no common RR type that implementers were required to serve >> and required to check. > > I would remove the word "fundamentally" (*Shrug*) Stylistic choice. I don't think it makes a difference. >> The circumstances surrounding SPF's initial deploymenta decade ago >> are unique and very, very unlikely to be repeated. > > I don't think so. Yeah, I'd drop the "and very, very unlikely to be repeated." This document doesn't need to be in the soothsayer business. I'd also be OK with s/are unique/were different than the circumstances today. Either way. >> If a future >> update to a new SPF version that could not reuse existing SPF >> records >> were to be developed, it ought to use the SPF RR type. Not wishing to argue the point with Hector, but also not inclined to come down on one side or the other. How about: "If a future update to SPF were developed that did not reuse existing SPF records, it could use the SPF RR type." >> SPF's use of >> the TXT RR type for structured data should in no way be taken as >> precedent for future protocol designers. Things have changed. > > > No it hasn't change. Again, not wishing to argue the point, because it doesn't matter. I'm fine with striking "Things have changed". I'd also like to see an information reference, like: "Further discussion of design considerations when using new DNS RRs can be found in [RFC5507]." It is not the job of this document to debate or judge the actual state of the current DNS infrastructure, only to document what this protocol did in the past and give pointers for future debate. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From spf2@kitterman.com Wed Sep 11 14:59: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 A9B3A11E8186 for ; Wed, 11 Sep 2013 14:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.380, 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 hqzgxcRrDKVN for ; Wed, 11 Sep 2013 14:59:31 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E156F21E80A5 for ; Wed, 11 Sep 2013 14:59:29 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C9D2D20E40EA; Wed, 11 Sep 2013 17:59:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1378936755; bh=q4DmIOh70fklsE3IMijRrtTis5M3M7+GWHCnSI8Q3ww=; h=From:To:Subject:Date:In-Reply-To:References:From; b=j3iZ9yP3DWdNIqvVXBB3+KaQmdfrZsOH1tUrRoe0VPq+fTB35Q0X40fB2HypK2SyY BS9kw6mVwzT7FVp2PfGDiUxryvaGHQ5sbIUBg6Wm7O9zxA/6C4Sz+d6mAS+5VUXIVT Oa63X6obmhs8V8mV1+yN2nAZGRDzb1TRLUA07LGk= 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 AD71A20E40D2; Wed, 11 Sep 2013 17:59:15 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 11 Sep 2013 17:59:15 -0400 Message-ID: <1585871.AU1b4sgrpz@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <5230A523.20504@isdg.net> References: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> <5230A523.20504@isdg.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] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 11 Sep 2013 21:59:37 -0000 Submitter is unrelated to SPF and it would be wrong to treat anything related to submitter as an "spf_result". If you disagree, please point to me to the reference in RFC 4408 or documents referenced by RFC 4408 where submitter is described. Scott K On Wednesday, September 11, 2013 13:15:15 Hector Santos wrote: > I had an issue with SPFBIS limiting discussion with integrated > technology that is 100% related and exist in the market place. > Protocols SenderID and Submitter SMTP extension which can alter the > way an SPF compliant package will work. > > Related, I had an issue with the limited modeling of check_host() > function I/O which WOULD NOT fit the reality of an integrated system > with SUBMITTER support with extended input parameters: > > spf_result = check_host(ehlo, mailfrom [,submitter]) > > I didn't see why this was not important other than to believe that > SenderID/Submitter doesn't not exist. > > DKIM is not RELATED to SPF. To talk about unrelated DKIM required to > talk about a very related item such as SenderID, SUBMITTER. > > In this vain, until the IETF can say something about a SPF-related > technology in SenderID and especially SMTP level SUBMITTER protocol > which will require to be fitted with a Check_Host() function, the > "Experiment" was not really completely concluded. > > Keep in mind that SPF is a SMTP level technology (doesn't require the > payload). DKIM requires the payload to be transferred and this > diminished the optimization of an SPF method. For DKIM, like ADSP, > DMARC also now depended on that Author Domain anchor (the single > binding requirement for DKIM). SPF or the SenderID Submitter protocol > do not depend on receiving the payload in other to function. > > A DKIM discussion will require how SMTP transaction is done with SPF > receivers, that is mainly to always receive the payload. > > On 9/11/2013 9:22 AM, S Moonesamy wrote: > > Hi Phillip, > > > > I am responding to the comment about DKIM only and wait for the SPFBIS > > WG to address the other issues. > > > > At 05:07 11-09-2013, Phillip Hallam-Baker wrote: > >> I have reviewed this document as part of the security directorate's > >> ongoing effort to review all IETF documents being processed by the > >> IESG. Document editors and WG chairs should treat these comments just > >> like any other last call comments. > >> > >> The document has been produced as part of a proposal to upgrade SPF > >> to standards track recognizing the state of deployment experience. > >> > >> Minor issues. > >> > >> 1.1.3. MAIL FROM Definition > >> > >> I found this section completely opaque and very confusing. It should > >> not be necessary to hunt through other specs to find a definition. > >> Particularly since the referenced specs do not give an explicit > >> definition for the term as used and the references point to the > >> whole spec rather than a particular section. > > > > I am commenting on the following paragraph only: > >> The Security Considerations section is adequate for the purpose > >> except that no mention is made anywhere in the specification about > >> DKIM and how a mail receiver should interpret presence of DKIM and > >> SPF policy at the same time. This is a legitimate concern since DKIM > >> is already a standards track proposal and SPF is only now being > >> promoted to Standards Track. Thus the SPF document should address > >> the question of dual use. > > > > There was a BoF at the last IETF meeting to discuss proposals about > > how to interpret the presence of DKIM and/or SPF policy at the same > > time ( http://www.ietf.org/proceedings/87/minutes/minutes-87-dmarc ). > > The dual use can be addressed as part of the DMARC effort. > > > >> 8.7. Permerror > >> > >> " > >> > >> This signals an error condition that > >> > >> definitely requires operator intervention to be resolved." > >> > >> I cannot imagine a circumstance which definitely requires a human to > >> be involved in mail delivery. > >> > >> > >> 11.2. SPF-Authorized Email May Contain Other False Identities > >> > >> Do not construe the "MAIL FROM" and "HELO" identity > >> > >> authorizations to > >> > >> provide more assurance than they do. > >> > >> Document has quasi normative language that should be worded as > >> statements of fact rather than as direction. > >> > >> -- > >> Website: http://hallambaker.com/ > > > > _______________________________________________ > > spfbis mailing list > > spfbis@ietf.org > > https://www.ietf.org/mailman/listinfo/spfbis From spf2@kitterman.com Wed Sep 11 15:01: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 027EA21F8459; Wed, 11 Sep 2013 15:01:48 -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 YFlQUsSk2C6W; Wed, 11 Sep 2013 15:01:40 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 681F111E8186; Wed, 11 Sep 2013 15:01:32 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E23D220E40EA; Wed, 11 Sep 2013 18:01:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1378936891; bh=v992vqlwE5WoV/TwCJy6rz9KbciFm3HjQPeqVvYExGs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JdDY84l1Bg0un0hB6nA24BVAK3Ly0I+QZoDgaoU/dJBnQ0sutLt/LnkHEzL9PZ35d qduL5YvtgoAzwMAl8vV7OTUxQ2uhQOc2WevNyKKlYMrDGN01SqZpddTtuICk2ez93t /JSjvv78NOkSRIlHV4LKD493s7l0uboMbcllXJa4= 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 C810920E40D2; Wed, 11 Sep 2013 18:01:31 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org, S Moonesamy , The IESG Date: Wed, 11 Sep 2013 18:01:31 -0400 Message-ID: <1623078.iZZXT7WM88@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <5230E724.8000703@qti.qualcomm.com> References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <52303A4A.5070303@isdg.net> <5230E724.8000703@qti.qualcomm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: spfbis-chairs@tools.ietf.org, Pete Resnick , draft-ietf-spfbis-4408bis@tools.ietf.org, Spencer Dawkins Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 22:01:56 -0000 On Wednesday, September 11, 2013 16:56:52 Pete Resnick wrote: > On 9/11/13 4:39 AM, Hector Santos wrote: > > On 9/10/2013 9:38 PM, Scott Kitterman wrote: > >> In 2003, when SPF was first being developed, the requirements for > >> assignment of a new DNS RR type were considerably more stringent > >> > >> than > >> > >> they are now. > > I think this is reasonable to leave in, Hector's comments > notwithstanding. It may not have been the primary problem, but it > certainly didn't help. > > >> As a result, at that time, there was no reasonable > >> alternative to using the TXT RR type for SPF records. > > No need to be overly proud here. I suggest, "As a result, proponents of > SPF found it easier and more practical to use the TXT RR type for SPF > records." > > >> In its review of [RFC4408] the SPFbis working group concluded that > >> its dual RR type transition model was fundamentally flawed since it > >> contained no common RR type that implementers were required to serve > >> and required to check. > > > > I would remove the word "fundamentally" > > (*Shrug*) Stylistic choice. I don't think it makes a difference. > > >> The circumstances surrounding SPF's initial deploymenta decade ago > >> are unique and very, very unlikely to be repeated. > > > > I don't think so. > > Yeah, I'd drop the "and very, very unlikely to be repeated." This > document doesn't need to be in the soothsayer business. > > I'd also be OK with s/are unique/were different than the circumstances > today. > > Either way. > > >> If a future > >> update to a new SPF version that could not reuse existing SPF > >> > >> records > >> > >> were to be developed, it ought to use the SPF RR type. > > Not wishing to argue the point with Hector, but also not inclined to > come down on one side or the other. How about: > > "If a future update to SPF were developed that did not reuse existing > SPF records, it could use the SPF RR type." > > >> SPF's use of > >> the TXT RR type for structured data should in no way be taken as > >> precedent for future protocol designers. Things have changed. > > > > No it hasn't change. > > Again, not wishing to argue the point, because it doesn't matter. I'm > fine with striking "Things have changed". I'd also like to see an > information reference, like: "Further discussion of design > considerations when using new DNS RRs can be found in [RFC5507]." > > It is not the job of this document to debate or judge the actual state > of the current DNS infrastructure, only to document what this protocol > did in the past and give pointers for future debate. I think all of Pete's suggestions are good. Should I go ahead and update my local copy of the to be -20? Scott K From sm@elandsys.com Wed Sep 11 15:10: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 9E8FD11E8126; Wed, 11 Sep 2013 15:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 WV99DJ05J1-O; Wed, 11 Sep 2013 15:10: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 1C04311E8106; Wed, 11 Sep 2013 15:10:24 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.34]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8BMA8jm017323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Sep 2013 15:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378937422; bh=NhM+uyuxC+5GTcxH3BmFT27cD/yRELe4aTF/Cn+U91w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=4YgZjVaK0gnEecllNwHr2Et9v7fqbuP4nozPjXhIkwUTIEzdXeFuR3vgvYctsa7Nf da9rSND6+7pA65zto6I48FSpM6LtkSFWAiJyk4dkqWNMrqxWrk8Sek5CbMWHeUyHi8 i/VfoGKq+DDq/5MWQystyCiSyubUbmq4L5PfsMCs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378937422; i=@elandsys.com; bh=NhM+uyuxC+5GTcxH3BmFT27cD/yRELe4aTF/Cn+U91w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kAaWzbT0xLMXlST+e3qKa+c2yknJhy7MxgSk4PUhZEt3aorxdbfrqLRm+zJlf67RZ U3y9ZU37xQZ2gSdsFzZh4G0vCuztRVGOP2zfBqfoRva+JGTR9ERgkE5OqY/zlIrVwl bgNDx9yYGEiBP2NISxeCsjleraSI8GXCy0t3/D34= Message-Id: <6.2.5.6.2.20130911150339.0c435c60@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Sep 2013 15:09:37 -0700 To: Scott Kitterman , spfbis@ietf.org, The IESG From: S Moonesamy In-Reply-To: <1623078.iZZXT7WM88@scott-latitude-e6320> References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <52303A4A.5070303@isdg.net> <5230E724.8000703@qti.qualcomm.com> <1623078.iZZXT7WM88@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis-chairs@tools.ietf.org, Pete Resnick , draft-ietf-spfbis-4408bis@tools.ietf.org, Spencer Dawkins Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 22:10:25 -0000 Hi Scott, At 15:01 11-09-2013, Scott Kitterman wrote: >I think all of Pete's suggestions are good. Should I go ahead and update my >local copy of the to be -20? Okay. Please go ahead and update your local copy. Please do not post a new revision of the draft. Could you please send me the text or post the text to the SPFBIS mailing list so that this change is clear to everyone? This was the main issue raised during the Last Call. It would make the rest of the work easier if we can get this one out of the way. Regards, S. Moonesamy (as document shepherd) From marka@isc.org Wed Sep 11 15:22: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 E7A8921F8EB2; Wed, 11 Sep 2013 15:22: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 SgZFka1PCqUd; Wed, 11 Sep 2013 15:21:58 -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 7E55A21F9C8B; Wed, 11 Sep 2013 15:21:55 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 2E243C9473; Wed, 11 Sep 2013 22:21:33 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1378938115; bh=EpR/ypbpeoSTr2xpMRu9P7LI5abb0JdNCOSfbCeiNtc=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=AcgsBdnKs9CQaJTnFtm6sm5Y1wkRgPC3jaKOmsF+10f8K4Iadf7GadGYqcm2+uRYr iA+C6tEPJzwc3vSIMRwyafa4j9dMgDcp1P1LcjUcAKfWVm8GbwJJveCA7UPTGbrXHf EM0yEoAngDC3xuybrdo5/rKxfZWF3zJ0o74SXvQw= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 11 Sep 2013 22:21:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C36F2160446; Wed, 11 Sep 2013 22:23:16 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 5C72F160363; Wed, 11 Sep 2013 22:23:16 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 9E3FC6485A6; Thu, 12 Sep 2013 08:21:27 +1000 (EST) To: Scott Kitterman From: Mark Andrews References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <52303A4A.5070303@isdg.net> <5230E724.8000703@qti.qualcomm.com> <1623078.iZZXT7WM88@scott-latitude-e6320> In-reply-to: Your message of "Wed, 11 Sep 2013 18:01:31 -0400." <1623078.iZZXT7WM88@scott-latitude-e6320> Date: Thu, 12 Sep 2013 08:21:27 +1000 Message-Id: <20130911222127.9E3FC6485A6@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Pete Resnick , S Moonesamy , spfbis@ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG , spfbis-chairs@tools.ietf.org, Spencer Dawkins Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 22:22:05 -0000 Why don't we just be honest and state that the working group did not proceed with the migration because Microsoft failed to supply a RFC 1304 compliant resolver (no support for arbitary type lookups), and failed to supply a authoritative nameserver that supported arbitary types despite RFC 3597 (standards track) stating how to do so for the Microsoft Windows platform. They also failed to extend the resolver and nameserver to have type specific support for the SPF record in RFC 4408. This is despite all other major nameserver vendors having support for arbitary types and/or type specific support for the SPF record. In message <1623078.iZZXT7WM88@scott-latitude-e6320>, Scott Kitterman writes: > On Wednesday, September 11, 2013 16:56:52 Pete Resnick wrote: > > On 9/11/13 4:39 AM, Hector Santos wrote: > > > On 9/10/2013 9:38 PM, Scott Kitterman wrote: > > >> In 2003, when SPF was first being developed, the requirements for > > >> assignment of a new DNS RR type were considerably more stringent > > >> > > >> than > > >> > > >> they are now. > > > > I think this is reasonable to leave in, Hector's comments > > notwithstanding. It may not have been the primary problem, but it > > certainly didn't help. > > > > >> As a result, at that time, there was no reasonable > > >> alternative to using the TXT RR type for SPF records. > > > > No need to be overly proud here. I suggest, "As a result, proponents of > > SPF found it easier and more practical to use the TXT RR type for SPF > > records." > > > > >> In its review of [RFC4408] the SPFbis working group concluded that > > >> its dual RR type transition model was fundamentally flawed since it > > >> contained no common RR type that implementers were required to serve > > >> and required to check. > > > > > > I would remove the word "fundamentally" > > > > (*Shrug*) Stylistic choice. I don't think it makes a difference. > > > > >> The circumstances surrounding SPF's initial deploymenta decade ago > > >> are unique and very, very unlikely to be repeated. > > > > > > I don't think so. > > > > Yeah, I'd drop the "and very, very unlikely to be repeated." This > > document doesn't need to be in the soothsayer business. > > > > I'd also be OK with s/are unique/were different than the circumstances > > today. > > > > Either way. > > > > >> If a future > > >> update to a new SPF version that could not reuse existing SPF > > >> > > >> records > > >> > > >> were to be developed, it ought to use the SPF RR type. > > > > Not wishing to argue the point with Hector, but also not inclined to > > come down on one side or the other. How about: > > > > "If a future update to SPF were developed that did not reuse existing > > SPF records, it could use the SPF RR type." > > > > >> SPF's use of > > >> the TXT RR type for structured data should in no way be taken as > > >> precedent for future protocol designers. Things have changed. > > > > > > No it hasn't change. > > > > Again, not wishing to argue the point, because it doesn't matter. I'm > > fine with striking "Things have changed". I'd also like to see an > > information reference, like: "Further discussion of design > > considerations when using new DNS RRs can be found in [RFC5507]." > > > > It is not the job of this document to debate or judge the actual state > > of the current DNS infrastructure, only to document what this protocol > > did in the past and give pointers for future debate. > > I think all of Pete's suggestions are good. Should I go ahead and update my > local copy of the to be -20? > > 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 superuser@gmail.com Wed Sep 11 15:52: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 5C07D11E812E; Wed, 11 Sep 2013 15:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 EFKFOvDFPA-T; Wed, 11 Sep 2013 15:52:40 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id DB08711E8106; Wed, 11 Sep 2013 15:52:37 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id q59so7587503wes.13 for ; Wed, 11 Sep 2013 15:52:36 -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=AGy7ypFC3vMXiS84qnxjO/s620IXQAIuHwiL+3vBzVQ=; b=Y/RMU1jzjAHP6D3HOBBuzQKmaJkNv9zjqU/XFTWYPogXZCG+6lA4rd9GaNnDNNYOIH z8Fdg/JSWat2YJUvy+XdODFeaMS3L5L6cO6vHkXlJUJcRdqEefOaV3sQ+F18tBlWw/fQ vOflpMjcqYvj/oVXxUnrFkHLDiQ4Hjc2pZoHe4Ogl4hFRbQZr2kICzweI/nJInAebikX T3zgffvso+oVP4pAD5qeP3bhF0SD1ISdI9NI5UcjlGQpBwHJBhQRpLpOAj5zunDYaUqx 9Vnc6Qiet4WG4JiivO01nrcyqAifQxj0PYYdu9v74SJAYKJ59+Kji7nI7Ceo+qw5TsYr +yPA== MIME-Version: 1.0 X-Received: by 10.180.184.107 with SMTP id et11mr19323487wic.60.1378939956207; Wed, 11 Sep 2013 15:52:36 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Wed, 11 Sep 2013 15:52:36 -0700 (PDT) In-Reply-To: <20130911222127.9E3FC6485A6@rock.dv.isc.org> References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <52303A4A.5070303@isdg.net> <5230E724.8000703@qti.qualcomm.com> <1623078.iZZXT7WM88@scott-latitude-e6320> <20130911222127.9E3FC6485A6@rock.dv.isc.org> Date: Wed, 11 Sep 2013 15:52:36 -0700 Message-ID: From: "Murray S. Kucherawy" To: Mark Andrews Content-Type: multipart/alternative; boundary=001a11c227ee41a8bc04e6237abc Cc: Pete Resnick , S Moonesamy , Spencer Dawkins , "spfbis@ietf.org" , draft-ietf-spfbis-4408bis@tools.ietf.org, Scott Kitterman , spfbis-chairs@tools.ietf.org, The IESG Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 22:52:41 -0000 --001a11c227ee41a8bc04e6237abc Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 11, 2013 at 3:21 PM, Mark Andrews wrote: > Why don't we just be honest and state that the working group did > not proceed with the migration because Microsoft failed to supply > a RFC 1304 compliant resolver (no support for arbitary type lookups), > and failed to supply a authoritative nameserver that supported > arbitary types despite RFC 3597 (standards track) stating how to > do so for the Microsoft Windows platform. They also failed to > extend the resolver and nameserver to have type specific support > for the SPF record in RFC 4408. This is despite all other major > nameserver vendors having support for arbitary types and/or type > specific support for the SPF record. > > I wasn't aware that this had anything to do with Microsoft in particular. There have been ample examples presented on these threads of provisioning systems and the like failing to support type 99 that were not developed by Microsoft. I could be completely wrong, but this is the first I've heard of a specific vendor being identified as "the" problem. -MSK --001a11c227ee41a8bc04e6237abc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 11, 2013 at 3:21 PM, Mark Andrews <marka@isc.org<= /a>> wrote:
Why don't we just be honest and state that the working group did
not proceed with the migration because Microsoft failed to supply
a RFC 1304 compliant resolver (no support for arbitary type lookups),
and failed to supply a authoritative nameserver that supported
arbitary types despite RFC 3597 (standards track) stating how to
do so for the Microsoft Windows platform. =A0They also failed to
extend the resolver and nameserver to have type specific support
for the SPF record in RFC 4408. =A0This is despite all other major
nameserver vendors having support for arbitary types and/or type
specific support for the SPF record.

<= br>
I wasn't aware that this had anything to do with Microsof= t in particular.=A0 There have been ample examples presented on these threa= ds of provisioning systems and the like failing to support type 99 that wer= e not developed by Microsoft.=A0 I could be completely wrong, but this is t= he first I've heard of a specific vendor being identified as "the&= quot; problem.

-MSK
--001a11c227ee41a8bc04e6237abc-- From sm@elandsys.com Wed Sep 11 15:52: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 D55F811E80E7; Wed, 11 Sep 2013 15:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 98IiXH914IxD; Wed, 11 Sep 2013 15:52:41 -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 D49E711E8106; Wed, 11 Sep 2013 15:52:41 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.34]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8BMqEp4003669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Sep 2013 15:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378939950; bh=gQjaalsizu2q8+r6/GmFFItxF5qyLKhtJppAcaYDmas=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xjWIG7+UCU+PgIYK4eK5GVObgBHrGoowHgMTgo0nCaDUqRH7DqGk9yMNOJbmusGz8 FXXCzodhKZQNUmQJrbOud8x/lrojjFsg89sTP8Pd2smSYK5wKLQd85zpdbji2CzjED 2h6f/qDi77hTLIIOe2CZaS9O/JFulRDMq416ffa0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378939950; i=@elandsys.com; bh=gQjaalsizu2q8+r6/GmFFItxF5qyLKhtJppAcaYDmas=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Q5+QwRC3AYLKGWnRbJEmGy5nNLNRxLDQq+XD4WGs7cx0H7pGk8YbeuY9FgdRqEPVX 8/PTbD+9ANTZ6SD1GF5Znk1PkOVsDBPIm5efey6kePX9msg+AkZdqc+i/HdDjrOl2o yaazwB4veheV5yFFZ6ouCjCnMdpWbbpoMeX2r4OQ= Message-Id: <6.2.5.6.2.20130911152402.0c435da8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Sep 2013 15:51:17 -0700 To: Mark Andrews From: S Moonesamy In-Reply-To: <20130911222127.9E3FC6485A6@rock.dv.isc.org> References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <52303A4A.5070303@isdg.net> <5230E724.8000703@qti.qualcomm.com> <1623078.iZZXT7WM88@scott-latitude-e6320> <20130911222127.9E3FC6485A6@rock.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Pete Resnick , Scott Kitterman , S Moonesamy , spfbis@ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG , spfbis-chairs@tools.ietf.org, Spencer Dawkins Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 22:52:43 -0000 Hi Mark, At 15:21 11-09-2013, Mark Andrews wrote: >Why don't we just be honest and state that the working group did >not proceed with the migration because Microsoft failed to supply >a RFC 1304 compliant resolver (no support for arbitary type lookups), >and failed to supply a authoritative nameserver that supported >arbitary types despite RFC 3597 (standards track) stating how to >do so for the Microsoft Windows platform. They also failed to >extend the resolver and nameserver to have type specific support >for the SPF record in RFC 4408. This is despite all other major >nameserver vendors having support for arbitary types and/or type >specific support for the SPF record. I do not have any affiliation with the vendor mentioned above. The above (see quoted text) are DNS issues. Here is what Pete Resnick as Area Director wrote: "- The document needs to make a statement in the document clarifying why the SPF RR is no longer used in the spec and making it clear that no precedent should be created by this protocol's continued use of TXT RR." The SPFBIS WG is addressing the issue raised by the Area Director. I don't think that a specification about the SPF protocol is the place to get into an exhaustive discussion about DNS issues. Regards, S. Moonesamy (as document shepherd) From barryleiba@gmail.com Wed Sep 11 16:08: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 0B20211E815B; Wed, 11 Sep 2013 16:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.029 X-Spam-Level: X-Spam-Status: No, score=-102.029 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 y5oL-ZTVPJXY; Wed, 11 Sep 2013 16:08:34 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id E6CE511E820F; Wed, 11 Sep 2013 16:08:32 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id u14so215200lbd.40 for ; Wed, 11 Sep 2013 16:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5Jl7t/1uPXnecS+t9kbsiixfgDo55enrbgjU74YquVE=; b=d1tMeV2+EqGkSmqDB42LxsWHBT8Zsbha0M/neL/TAKp5Mru2RJ479lXDuQjZLb+ofT DceCDdL4Y7kv9zOPlmqda1xcQHfDEh/ACCPfkk8oFQnvwnNp18cRtPsFqkUHss6kZ1SL lw/jlqnmUAE7WefmXGM6KCrEznwv/OcxYilEkoEGjoHUEZBlN9OFzV6RmEAjh8RZIynr NzxTc9z7tii9uj7baS4m5pP8CnewboaSBQJ988hXrA//fHBZRZTsl5z1Nrq91BYy3Uzn 9WSlhBOu9kkZ7vhRYhWhHW/YmftRcVS6DwrMaS5H5UtOMP+rI3w1quajx1r9ffnvzmD0 t8Ew== MIME-Version: 1.0 X-Received: by 10.152.3.201 with SMTP id e9mr3412807lae.24.1378940898233; Wed, 11 Sep 2013 16:08:18 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.112.130.39 with HTTP; Wed, 11 Sep 2013 16:08:18 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130911144430.0c3f7f78@resistor.net> References: <20130911015837.30196.11175.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130911050206.0dc1ff68@elandnews.com> <1409783.xNJeGdWPul@scott-latitude-e6320> <6.2.5.6.2.20130911144430.0c3f7f78@resistor.net> Date: Wed, 11 Sep 2013 19:08:18 -0400 X-Google-Sender-Auth: klY9JSK5GrBqe7uGEaiaJtBCuTk Message-ID: From: Barry Leiba To: "spfbis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis-chairs@tools.ietf.org" , draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG Subject: Re: [spfbis] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 11 Sep 2013 23:08:35 -0000 > Scott and Murray are okay with the text you suggested to address the DISCUSS > ( http://www.ietf.org/mail-archive/web/spfbis/current/msg04114.html ). > > The SPFBIS WG seems okay with most of the text you suggested as COMMENT. > There are some comments from Scott (see below) for the rest. Thanks, SM, for brokering. As this is now going directly to the WG, Scott, Murray, or others can respond directly at this point. >> The example in this section might be published via these lines in a >> domain zone file: >> example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" >> smtp-out.example.com. TXT "v=spf1 a -all" >> >> What does "smtp-out" have to do with anything? It's not otherwise used, >> and it seems to contradict what you say about subdomains in the previous >> paragraph. > > Those are just two examples, but the preceding text is poorly worded (I > checked and it's no better in RFC 4408). How about this instead, to > clarify: > > The example in this section (plus an additional SPF record for > smtp-out.example.com) might be published via these lines in a > domain zone file: > > example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" > smtp-out.example.com. TXT "v=spf1 a -all" Well, OK... and it is a non-blocking comment, remember. But what value is there in including that second line at all? You're giving a specific example in that section, and this is supporting that example. If this were a general section of multiple examples, maybe. I think you should just strike it. But, again: non-blocking comment. Do as you think best, and this is the last I'll say about this. >>> -- Section 4.5 -- >>> >>> Starting with the set of records that were returned by the lookup, >>> discard records that do not begin with a version section of exactly >>> "v=spf1". Note that the version section is terminated either by an >>> SP character or the end of the record. A record with a version >>> section of "v=spf10" does not match and is discarded. >>> >>> Sure, and "v=spf1.0" doesn't match, and "v=spf11" doesn't match, >>> and.... Why is it necessary or desirable to single out "v=spf10" here? >> >> I think "v=spf1.0" is actually the better (and perhaps intended) example, >> meaning "don't just stuff the part after 'spf' through a number parser and >> make sure 1 comes out". > > The intent here is to show that you have to look at least one character > past "v=spf1" to know if it's an SPF record or not. It's an example. As > such, it doesn't matter much wrt the point if it's "v=spf10", "v=spf1.0", or > or "v=spf1hatespf". None of those start SPF records. What's there is > unchanged from RFC 4408. I don't seem much of a point in changing it, > but if others think 1.0 is better than 10, I don't mind. Again, non-blocking, so, again, do as you think is best, and this will be my last comment on it. It just seems bizarre to me to pick one particular invalid value and say that it doesn't match and is discarded. The point is that *anything* that isn't exactly "v=spf1" doesn't match and is discarded. Let me suggest a specific text change. Take it, leave it, or change it -- you don't need to bat it around with me further. NEW Starting with the set of records that were returned by the lookup, discard records that do not begin with a version section of exactly "v=spf1". The version section is terminated by either an SP character or the end of the record; if "v=spf1" is followed by any character other than SP, it does not match and that record is discarded. END >>> NEW >>> Some mechanisms and modifiers (collectively, "terms") cause DNS >>> queries at the time of evaluation, and some do not. The following >>> terms cause DNS queries: . SPF implementations >>> MUST limit the total number of those terms to 10 during SPF >>> evaluation, to avoid unreasonable load on the DNS. If this limit >>> is exceeded, the implementation MUST return "permerror". The other >>> terms () do not cause DNS queries at the time of >>> SPF evaluation (the "exp" modifier causes a lookup at a later time), >>> and their use is not subject to this limit. >>> END >> >> I like the new text, and prefer the second bit be included. > > If we change, and I think that's reasonable, the second bit should definitely > be included. "exp" not counting in the 10 has confused people and we > should be explicit about it. Kewl; thanks. >> How about: >> >> It is better to use either a "redirect" modifier or an "all" mechanism to >> explicitly terminate processing. Although there is an implicit "?all" at >> the end of every record that is not explicitly terminated, it aids >> debugging efforts when it is explicitly provided. Also nice. >>> -- Section 5.5 -- >>> >>> This mechanism SHOULD NOT be published. See below for discussion. >>> >>> It's quite a bit below. I suggest "See the note at the end of this >>> section for more information." It might even be worth putting that note >>> into a Section 5.5.1, so it's highlighted and more easily cited. >> >> +1. > > OK. Someone let me know which way I should do it. I'm OK with either. I kind of like the separate section, but it's a smaller change to just leave the note and say "see the note." Unless anyone feels strongly that a separate section is worth the trouble, I suggest just pointing people to the note explicitly. And again, thanks for all the work on this, and for considering my fairly long list. Barry From superuser@gmail.com Wed Sep 11 18:27: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 5630721F9123; Wed, 11 Sep 2013 18:27:08 -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 p4w6EhFKEwSe; Wed, 11 Sep 2013 18:27:07 -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 8398721F90CC; Wed, 11 Sep 2013 18:27:06 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ez12so2866582wid.8 for ; Wed, 11 Sep 2013 18:27:05 -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=caBxd+ASYoQ9QO0L+kgzw7F/GzxLoeuB1lQoAjlFBRo=; b=ni8W8s3b5qd9tp3HVicAR3B2YQ2OT09fD5UqewIDEGqff+UYlgxGqMQee6YAa6+zBn DFacO/HoZfVsIgGKoW8YYx1OVXkgJQXp0kVPa5VmF1O9YWT+uhqcsDNuUNLMXFimCohB 7RanIQ5eOT/XLMv3VGfpA1DP/X2XIqNF7vppsNJAeUmgwRi5xmzfx/RXaq4Tc8U1dfyu HwvYZg2vb6nvKb9ALLCldOsiQAhIfIOWLUYAPry4/GxZCBLu69q2uFXIHFankDZltQb4 D/EI5kzK/ekC512tQs50i3KK0KMeY8KCBiAbvqLa0tYr3NV+RFvtD4MjkaVu3ao9qv4x MAxA== MIME-Version: 1.0 X-Received: by 10.180.189.9 with SMTP id ge9mr3651644wic.52.1378949225672; Wed, 11 Sep 2013 18:27:05 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Wed, 11 Sep 2013 18:27:05 -0700 (PDT) In-Reply-To: References: <20130911015837.30196.11175.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130911050206.0dc1ff68@elandnews.com> <1409783.xNJeGdWPul@scott-latitude-e6320> <6.2.5.6.2.20130911144430.0c3f7f78@resistor.net> Date: Wed, 11 Sep 2013 18:27:05 -0700 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: multipart/alternative; boundary=001a11c34302c276c404e625a252 Cc: "spfbis@ietf.org" , "spfbis-chairs@tools.ietf.org" , draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG Subject: Re: [spfbis] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 12 Sep 2013 01:27:08 -0000 --001a11c34302c276c404e625a252 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 11, 2013 at 4:08 PM, Barry Leiba wrote: > >> The example in this section might be published via these lines in a > >> domain zone file: > >> example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" > >> smtp-out.example.com. TXT "v=spf1 a -all" > >> > >> What does "smtp-out" have to do with anything? It's not otherwise used, > >> and it seems to contradict what you say about subdomains in the previous > >> paragraph. > > > > Those are just two examples, but the preceding text is poorly worded (I > > checked and it's no better in RFC 4408). How about this instead, to > > clarify: > > > > The example in this section (plus an additional SPF record for > > smtp-out.example.com) might be published via these lines in a > > domain zone file: > > > > example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" > > smtp-out.example.com. TXT "v=spf1 a -all" > > Well, OK... and it is a non-blocking comment, remember. But what > value is there in including that second line at all? You're giving a > specific example in that section, and this is supporting that example. > If this were a general section of multiple examples, maybe. I think > you should just strike it. > I agree actually. I don't know what this adds, unless we want to explain what the use of the second record would be (e.g., there's an intent to say with a MAIL FROM domain of smtp-out.example.com is much more tightly constrained for some reason). If we don't want to describe the use case, we should strike the second record. NEW > Starting with the set of records that were returned by the lookup, > discard records that do not begin with a version section of exactly > "v=spf1". The version section is terminated by either an SP character > or the end of the record; if "v=spf1" is followed by any character > other than SP, it does not match and that record is discarded. > END > That'd be fine with me too. -MSK --001a11c34302c276c404e625a252 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 11, 2013 at 4:08 PM, Barry Leiba <barry= leiba@computer.org> wrote:
>> =A0 =A0The example in this section = might be published via these lines in a
>> =A0 =A0domain zone file:
>> =A0 =A0 =A0 examp= le.com. TXT "v=3Dspf1 +mx a:colo.example.com/28 -all"
>> =A0 =A0 =A0 smtp-out.example.com. TXT "v=3Dspf1 a -all"
>>
>> What does "smtp-out" have to do with anything? =A0It'= ;s not otherwise used,
>> and it seems to contradict what you say about subdomains in the pr= evious
>> paragraph.
>
> Those are just two examples, but the preceding= text is poorly worded (I
> checked and it's no better in RFC 4408). =A0How about this instead= , to
> clarify:
>
> =A0 =A0The example in this section (plus an additional SPF record for<= br> > =A0 =A0smtp-= out.example.com) might be published via these lines in a
> =A0 =A0domain zone file:
>
> =A0 =A0 =A0 example.c= om. =A0 =A0 =A0 =A0 =A0TXT "v=3Dspf1 +mx a:colo.example.com/28 -all"
> =A0 =A0 =A0 = smtp-out.example.com. TXT "v=3Dspf1 a -all"

Well, OK... and it is a non-blocking comment, remember. =A0But what value is there in including that second line at all? =A0You're giving a=
specific example in that section, and this is supporting that example.
=A0If this were a general section of multiple examples, maybe. =A0I think you should just strike it.

I agree actu= ally.=A0 I don't know what this adds, unless we want to explain what th= e use of the second record would be (e.g., there's an intent to say wit= h a MAIL FROM domain of smtp-out.ex= ample.com is much more tightly constrained for some reason).=A0 If we d= on't want to describe the use case, we should strike the second record.=
NEW
Starting with the se= t of records that were returned by the lookup,
discard records that do not begin with a version section of exactly
"v=3Dspf1". =A0The version section is terminated by either = an SP character
or the end of the record; if "v=3Dspf1" is followed by any charac= ter
other than SP, it does not match and that record is discarded.
END

That'd be fine with me too.
=
-MSK
--001a11c34302c276c404e625a252-- From johnl@iecc.com Wed Sep 11 18:33: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 82D6F11E80ED for ; Wed, 11 Sep 2013 18:33:53 -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 DDQB3H26uWMq for ; Wed, 11 Sep 2013 18:33:49 -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 0A65121F9E94 for ; Wed, 11 Sep 2013 18:33:36 -0700 (PDT) Received: (qmail 96841 invoked from network); 12 Sep 2013 01:33:36 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Sep 2013 01:33: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=523119f0.xn--i8sz2z.k1309; i=johnl@user.iecc.com; bh=BMWfCNvNS0QNaEl3P6aNx+PviLIhWbZfrigFbdTa5g0=; b=jCDcdFfJKXyoRAA2qPCP2GO8/PUOfZIUx0Jz42ZwyVEgllPVSTsGNDmGe27/eqE6umtgtfADd3oxFEEBS2OeMkuv7TJDs8c0466Zx9jJPAu5uo03aj/GUGc4l+WcC/kjgCvG6JMcoayrxyTFydzLURih8TBHpgPqAyGLpjJ5IrWvh7XVfcMdAI2Y4At3rkWZLfapuv6Xf7DkKVlpm9gYxYLm/LcK8DMelqcV2C6NO6DNVYYNPXWq1D3Jrfsu8iko 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=523119f0.xn--i8sz2z.k1309; olt=johnl@user.iecc.com; bh=BMWfCNvNS0QNaEl3P6aNx+PviLIhWbZfrigFbdTa5g0=; b=BTIZWvYCIKu2IoYfV6hnUGyxYnIO3TR24x06h1Y8Txi2HInM9xbJCf0sWehaee8sczDIhtSEwgMHBLuQni8WV4/+fCvGZrot1ehExVuhniPJQVMGN0i7qhxKoxotzk6ij9ZXoM9J7c14ufNBQgw+vT8eDxrp1jxp9SskDHjj06LUBx31umrjwas8mJVKVaPaX02DocGkkdBN3U2peOFZWlvmwO5+MOa3Ji41NXULCVLluNsXdspwzHEcpZHP+w1i Date: 12 Sep 2013 01:33:13 -0000 Message-ID: <20130912013313.42887.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <20130911222127.9E3FC6485A6@rock.dv.isc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: marka@isc.org Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 12 Sep 2013 01:33:53 -0000 In article <20130911222127.9E3FC6485A6@rock.dv.isc.org> you write: > >Why don't we just be honest and state that the working group did >not proceed with the migration because Microsoft failed to supply >a RFC 1304 compliant resolver (no support for arbitary type lookups), >and failed to supply a authoritative nameserver that supported >arbitary types despite RFC 3597 (standards track) stating how to >do so for the Microsoft Windows platform. Because it's not true. MS may have cruddy DNS software, but that was not and is not the only or the primary issue. See the previous million or so messages on this topic for details. R's, John From johnl@iecc.com Wed Sep 11 18:51: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 CFC8711E80F6 for ; Wed, 11 Sep 2013 18:51:09 -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 V1ZoHoNTPVS2 for ; Wed, 11 Sep 2013 18:51:05 -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 4869111E815F for ; Wed, 11 Sep 2013 18:51:05 -0700 (PDT) Received: (qmail 99313 invoked from network); 12 Sep 2013 01:51:02 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Sep 2013 01:51:02 -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=52311e06.xn--9vv.k1309; i=johnl@user.iecc.com; bh=TEX8xyKVTpqTRdFAHC/iw1Vhq7uChCtEle3Gkb6P6dU=; b=wKJe/SOofUvwbdUwqMXEi38tZG97B+rXpayiwKCFWUSCNy49oJRob3qzH1EI7+3MLeNmmWT30lNMtzUa65OXcAakv+S/0IAikjA0nhWUy4Lb5dhLsQUmknvIraaOmX49wt/OZ5q/FYPYPmrEdEO/pSgxU8XrFFcI9urdQwPTPH6Pnzr6lQw+UsyEL3AyKS+kHsjp7wnVMY/HRHFCXFhYWInmSy+srLpkfjRdAjo/MIf87VcjTzoI02WTWfy8KdIO 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=52311e06.xn--9vv.k1309; olt=johnl@user.iecc.com; bh=TEX8xyKVTpqTRdFAHC/iw1Vhq7uChCtEle3Gkb6P6dU=; b=F0h4DtGkOTmj1q/jfj2eTK5pvZvw9EeyYvYLi6IX2Ut2uGgXE1MCc5jqveX0+LefsIMCKwDAhyCZ2ecK6eWJfQC4Hhf8gquOx3Dv43pmnX9LcsGA4Ppes8sFCfi4Y1zzb8oG9MuT15z8FuoWEm8RrcxMMjLolSAhFUTd9g8NE2nG4eOjRGQPprEUbAH3Us7VRm/7zSHHS9CqoxADjsOUtKRFhACuZC9VXcIwQ6gtFUqA6fm7ZMhniOUaPsJIX5O4 Date: 12 Sep 2013 01:50:39 -0000 Message-ID: <20130912015039.43001.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] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 12 Sep 2013 01:51:09 -0000 >I agree actually. I don't know what this adds, unless we want to explain >what the use of the second record would be (e.g., there's an intent to say >with a MAIL FROM domain of smtp-out.example.com is much more tightly >constrained for some reason). If we don't want to describe the use case, >we should strike the second record. I'd think that smtp-out.example.com is the host name of the SMTP server so it appears in the EHLO, and SPF uses it for bounces with null senders. R's, John From marka@isc.org Wed Sep 11 18:59: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 4230211E80F6 for ; Wed, 11 Sep 2013 18:59:36 -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 d5Y8MqL0-k6t for ; Wed, 11 Sep 2013 18:59:30 -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 768DA21F8F9A for ; Wed, 11 Sep 2013 18:59:30 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 0480FC94B6; Thu, 12 Sep 2013 01:59:17 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1378951170; bh=gbF9ER+0XDGRN+KuYI1tFZEC0m3v+9X5R2t67pUG6+g=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=pKzhZdsizpO2fTDdhIRrL6vZ2EdMTDj2uxd7Puc4YEwreQTRlrJDUuVR3fUu1Ycq0 ZqMJkLIpDUqTGzQ5On1z0rl86x/qvSk3vb35E2hXIIoHG2BHYMH3qKtS++qKevEqU0 bhnN4SItz2Ftt+pjhlE2efLoSyV9NlGg907K3hts= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 12 Sep 2013 01:59:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4BD67160446; Thu, 12 Sep 2013 02:01:01 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 187FF160363; Thu, 12 Sep 2013 02:01:01 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 3186464C0A4; Thu, 12 Sep 2013 11:59:14 +1000 (EST) To: "John Levine" From: Mark Andrews References: <20130912013313.42887.qmail@joyce.lan> In-reply-to: Your message of "12 Sep 2013 01:33:13 +0000." <20130912013313.42887.qmail@joyce.lan> Date: Thu, 12 Sep 2013 11:59:14 +1000 Message-Id: <20130912015914.3186464C0A4@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: spfbis@ietf.org Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 12 Sep 2013 01:59:36 -0000 In message <20130912013313.42887.qmail@joyce.lan>, "John Levine" writes: > In article <20130911222127.9E3FC6485A6@rock.dv.isc.org> you write: > > > >Why don't we just be honest and state that the working group did > >not proceed with the migration because Microsoft failed to supply > >a RFC 1304 compliant resolver (no support for arbitary type lookups), > >and failed to supply a authoritative nameserver that supported > >arbitary types despite RFC 3597 (standards track) stating how to > >do so for the Microsoft Windows platform. > > Because it's not true. MS may have cruddy DNS software, but that was > not and is not the only or the primary issue. See the previous > million or so messages on this topic for details. Not having a manditory type was a bogus excuse as we needed to go from TXT only to SPF only. It was a MIGRATION. Having TXT only publisher not "working" with SPF only checkers was NOT broken. It should have been a INTENTED result of successful MIGTATION. The end state of the MIGRATION was SPF only for both publishers and checkers which would NEVER interoperate with "TXT only" publishers and checkers. Once you swallow the bogus arguement that "ALL publishers have to work with ALL checkers" you can't have a MIGRATION as it becomes logically impossible to do. Then it just came down to pragmatics. Microsoft's lack to support was a big part of the pragmatics arguement. Mark > R's, > John -- 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 Sep 11 21:34: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 6922E11E8130 for ; Wed, 11 Sep 2013 21:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.272, 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 AyqyNRwZaJhg for ; Wed, 11 Sep 2013 21:34:50 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C4CDB11E814E for ; Wed, 11 Sep 2013 21:34:47 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9CE0B20E40EA; Thu, 12 Sep 2013 00:34:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1378960485; bh=xhl73ibhsp9d7YTsAvWKKSQQNGmrCrkMT9qqEQw/G9I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ldU3mrIOoLUJcNLgg8zTcO9njnVowWnqkqXxGnEHWMojlqpC1rGeSDxO27bUpAedT /NiqtuoqmisPmRhTeLJDBM+yiM6XLB6QyhO1DSgjNNwFC77jbtI6zpnUzdcLjoDyJk 79Z3fJQwFlloA3jG5y0VcrBb+nvJnnNGXGjjLt1A= 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 803F920E40D2; Thu, 12 Sep 2013 00:34:45 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 12 Sep 2013 00:34:44 -0400 Message-ID: <1461923.BurkIj9pH1@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: References: <20130911015837.30196.11175.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130911144430.0c3f7f78@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] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 12 Sep 2013 04:34:54 -0000 On Wednesday, September 11, 2013 19:08:18 Barry Leiba wrote: > > Scott and Murray are okay with the text you suggested to address the > > DISCUSS ( > > http://www.ietf.org/mail-archive/web/spfbis/current/msg04114.html ). > > > > The SPFBIS WG seems okay with most of the text you suggested as COMMENT. > > There are some comments from Scott (see below) for the rest. > > Thanks, SM, for brokering. As this is now going directly to the WG, > Scott, Murray, or others can respond directly at this point. > > >> The example in this section might be published via these lines in a > >> > >> domain zone file: > >> example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" > >> smtp-out.example.com. TXT "v=spf1 a -all" > >> > >> What does "smtp-out" have to do with anything? It's not otherwise used, > >> and it seems to contradict what you say about subdomains in the previous > >> paragraph. > > > > Those are just two examples, but the preceding text is poorly worded (I > > checked and it's no better in RFC 4408). How about this instead, to > > > > clarify: > > The example in this section (plus an additional SPF record for > > smtp-out.example.com) might be published via these lines in a > > > > domain zone file: > > example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" > > smtp-out.example.com. TXT "v=spf1 a -all" > > Well, OK... and it is a non-blocking comment, remember. But what > value is there in including that second line at all? You're giving a > specific example in that section, and this is supporting that example. > If this were a general section of multiple examples, maybe. I think > you should just strike it. > > But, again: non-blocking comment. Do as you think best, and this is > the last I'll say about this. I think that makes sense. I removed it. > >>> -- Section 4.5 -- > >>> > >>> Starting with the set of records that were returned by the lookup, > >>> discard records that do not begin with a version section of exactly > >>> "v=spf1". Note that the version section is terminated either by an > >>> SP character or the end of the record. A record with a version > >>> section of "v=spf10" does not match and is discarded. > >>> > >>> Sure, and "v=spf1.0" doesn't match, and "v=spf11" doesn't match, > >>> and.... Why is it necessary or desirable to single out "v=spf10" here? > >> > >> I think "v=spf1.0" is actually the better (and perhaps intended) example, > >> meaning "don't just stuff the part after 'spf' through a number parser > >> and > >> make sure 1 comes out". > > > > The intent here is to show that you have to look at least one character > > past "v=spf1" to know if it's an SPF record or not. It's an example. As > > such, it doesn't matter much wrt the point if it's "v=spf10", "v=spf1.0", > > or or "v=spf1hatespf". None of those start SPF records. What's there is > > unchanged from RFC 4408. I don't seem much of a point in changing it, > > but if others think 1.0 is better than 10, I don't mind. > > Again, non-blocking, so, again, do as you think is best, and this will > be my last comment on it. > > It just seems bizarre to me to pick one particular invalid value and > say that it doesn't match and is discarded. The point is that > *anything* that isn't exactly "v=spf1" doesn't match and is discarded. > > Let me suggest a specific text change. Take it, leave it, or change > it -- you don't need to bat it around with me further. > > NEW > Starting with the set of records that were returned by the lookup, > discard records that do not begin with a version section of exactly > "v=spf1". The version section is terminated by either an SP character > or the end of the record; if "v=spf1" is followed by any character > other than SP, it does not match and that record is discarded. > END Thanks. I changed the existing text to have the sentence start, "As an example, ..." so that it's clear this is exemplary. I think that is the minimal change that should resolve this. > >>> NEW > >>> > >>> Some mechanisms and modifiers (collectively, "terms") cause DNS > >>> queries at the time of evaluation, and some do not. The following > >>> terms cause DNS queries: . SPF implementations > >>> MUST limit the total number of those terms to 10 during SPF > >>> evaluation, to avoid unreasonable load on the DNS. If this limit > >>> is exceeded, the implementation MUST return "permerror". The other > >>> terms () do not cause DNS queries at the time of > >>> SPF evaluation (the "exp" modifier causes a lookup at a later time), > >>> and their use is not subject to this limit. > >>> > >>> END > >> > >> I like the new text, and prefer the second bit be included. > > > > If we change, and I think that's reasonable, the second bit should > > definitely be included. "exp" not counting in the 10 has confused people > > and we should be explicit about it. > > Kewl; thanks. Did that. > >> How about: > >> It is better to use either a "redirect" modifier or an "all" mechanism > >> to > >> explicitly terminate processing. Although there is an implicit "?all" > >> at > >> the end of every record that is not explicitly terminated, it aids > >> > >> debugging efforts when it is explicitly provided. > > Also nice. Done. > >>> -- Section 5.5 -- > >>> > >>> This mechanism SHOULD NOT be published. See below for discussion. > >>> > >>> It's quite a bit below. I suggest "See the note at the end of this > >>> section for more information." It might even be worth putting that note > >>> into a Section 5.5.1, so it's highlighted and more easily cited. > >> > >> +1. > > > > OK. Someone let me know which way I should do it. I'm OK with either. > > I kind of like the separate section, but it's a smaller change to just > leave the note and say "see the note." Unless anyone feels strongly > that a separate section is worth the trouble, I suggest just pointing > people to the note explicitly. I just pointed at the note. > And again, thanks for all the work on this, and for considering my > fairly long list. Thanks for the feedback. I'll post a new diff shortly. Scott K From spf2@kitterman.com Wed Sep 11 21:49: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 7881311E80EA for ; Wed, 11 Sep 2013 21:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[AWL=-1.270, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, NORMAL_HTTP_TO_IP=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 lYo7+opTwVVx for ; Wed, 11 Sep 2013 21:49:20 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2005311E8137 for ; Wed, 11 Sep 2013 21:49:20 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id EA06920E40EA; Thu, 12 Sep 2013 00:49:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1378961357; bh=sCot8uDRcvvDsmrujOjvNFC6HgYec7b8nyoh+Dg8vBg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cpfVC3H+x1RFjyLur8H2mswwHIgs28zZ1gx+Ezi2c4Po2QsD0/aWB/+l0WNgwIuEZ rHKvSYej3XOefzZThhHbIM9OAuP2SBzlbTbQehMact5N75Ti/gXkv78BZvFpM8pONf gV+XF7Ll4Lq3P23ubzLJd2V2NSTtht2M97kcgXhs= 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 BDDB320E40D2; Thu, 12 Sep 2013 00:49:16 -0400 (EDT) From: Scott Kitterman To: S Moonesamy , Pete Resnick Date: Thu, 12 Sep 2013 00:49:16 -0400 Message-ID: <2405077.Cn8DraDvER@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130911150339.0c435c60@elandnews.com> References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <1623078.iZZXT7WM88@scott-latitude-e6320> <6.2.5.6.2.20130911150339.0c435c60@elandnews.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart459656491.JZNEy2MKK3" Content-Transfer-Encoding: 7Bit X-AV-Checked: ClamAV using ClamSMTP Cc: spfbis@ietf.org Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 12 Sep 2013 04:49:25 -0000 This is a multi-part message in MIME format. --nextPart459656491.JZNEy2MKK3 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Wednesday, September 11, 2013 15:09:37 S Moonesamy wrote: > Hi Scott, > > At 15:01 11-09-2013, Scott Kitterman wrote: > >I think all of Pete's suggestions are good. Should I go ahead and update > >my local copy of the to be -20? > > Okay. Please go ahead and update your local copy. Please do not > post a new revision of the draft. Done. rfcdiff of the full post -19 diff attached. I've applied the changes due to Barry's comments as well. > Could you please send me the text or post the text to the SPFBIS > mailing list so that this change is clear to everyone? This was the > main issue raised during the Last Call. It would make the rest of > the work easier if we can get this one out of the way. Here is the revised section 3.1: 3.1. DNS Resource Records SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only. The character content of the record is encoded as [US-ASCII]. Use of alternative DNS RR types was supported in - SPF's experimental phase, but has been discontinued. See Appendix A - of [RFC6686] for further information. + SPF's experimental phase, but has been discontinued. + In 2003, when SPF was first being developed, the requirements for + assignment of a new DNS RR type were considerably more stringent than + they are now. Additionally, support for easy deployment of new DNS + RR types was not widely deployed in DNS servers and provisioning + systems. As a result, developers of SPF found it easier and more + practical to use the TXT RR type for SPF records. + In its review of [RFC4408] the SPFbis working group concluded that + its dual RR type transition model was fundamentally flawed since it + contained no common RR type that implementers were required to serve + and required to check. Many alternatives were considered to resolve + this issue, but ultimately the working group concluded that + significant migration to the SPF RR type in the foreseeable future was + very unlikely and that the best solution for resolving this + interoperability issue was to drop support for the SPF RR type from + SPF version 1. See Appendix A of [RFC6686] for further information. + + The circumstances surrounding SPF's initial deployment a decade ago + are unique. If a future update to SPF were developed that did not + reuse existing SPF records, it could use the SPF RR type. SPF's use + of the TXT RR type for structured data should in no way be taken as + precedent for future protocol designers. Further discussion of + design considerations when using new DNS RR types can be found in + [RFC5507]. I am waiting any changes based on the SECDIR review for some responses to my last message on that topic. Scott K --nextPart459656491.JZNEy2MKK3 Content-Disposition: attachment; filename="draft-ietf-spfbis-4408bis-20-from-19.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="draft-ietf-spfbis-4408bis-20-from-19.diff.html" Diff: draft-ietf-spfbis-4408bis-19.txt - draft-ietf-spfbis-4408bis-20.txt
 draft-ietf-spfbis-4408bis-19.txt   draft-ietf-spfbis-4408bis-20.txt 
Network Working Group S. Kitterman Network Working Group S. Kitterman
Internet-Draft Kitterman Technical Services Internet-Draft Kitterman Technical Services
Obsoletes: 4408 (if approved) August 17, 2013 Obsoletes: 4408 (if approved) September 12, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: February 18, 2014 Expires: March 16, 2014
Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email,
Version 1 Version 1
draft-ietf-spfbis-4408bis-19 draft-ietf-spfbis-4408bis-20
Abstract Abstract
Email on the Internet can be forged in a number of ways. In Email on the Internet can be forged in a number of ways. In
particular, existing protocols place no restriction on what a sending 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 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 SMTP HELO/EHLO commands. This document describes version 1 of
the Sender Policy Framework (SPF) protocol, whereby ADministrative the Sender Policy Framework (SPF) protocol, whereby ADministrative
Management Domains (ADMDs) can explicitly authorize the hosts that Management Domains (ADMDs) can explicitly authorize the hosts that
are allowed to use its domain names, and a receiving host can check are allowed to use its domain names, and a receiving host can check
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 18, 2014. This Internet-Draft will expire on March 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 32 skipping to change at page 3, line 32
2.6.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.6. Temperror . . . . . . . . . . . . . . . . . . . . . . 11 2.6.6. Temperror . . . . . . . . . . . . . . . . . . . . . . 11
2.6.7. Permerror . . . . . . . . . . . . . . . . . . . . . . 11 2.6.7. Permerror . . . . . . . . . . . . . . . . . . . . . . 11
3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. DNS Resource Records . . . . . . . . . . . . . . . . . . . 12 3.1. DNS Resource Records . . . . . . . . . . . . . . . . . . . 12
3.2. Multiple DNS Records . . . . . . . . . . . . . . . . . . . 13 3.2. Multiple DNS Records . . . . . . . . . . . . . . . . . . . 13
3.3. Multiple Strings in a Single DNS record . . . . . . . . . 13 3.3. Multiple Strings in a Single DNS record . . . . . . . . . 13
3.4. Record Size . . . . . . . . . . . . . . . . . . . . . . . 13 3.4. Record Size . . . . . . . . . . . . . . . . . . . . . . . 14
3.5. Wildcard Records . . . . . . . . . . . . . . . . . . . . . 14 3.5. Wildcard Records . . . . . . . . . . . . . . . . . . . . . 14
4. The check_host() Function . . . . . . . . . . . . . . . . . . 15 4. The check_host() Function . . . . . . . . . . . . . . . . . . 16
4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 16 4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 17
4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 16 4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 17
4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 16 4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 17
4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 16 4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 17
4.6.1. Term Evaluation . . . . . . . . . . . . . . . . . . . 17 4.6.1. Term Evaluation . . . . . . . . . . . . . . . . . . . 18
4.6.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 17 4.6.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 18
4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 18 4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 19
4.6.4. DNS Lookup Limits . . . . . . . . . . . . . . . . . . 18 4.6.4. DNS Lookup Limits . . . . . . . . . . . . . . . . . . 19
4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 19 4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 20
4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 19 4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 20
5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 21 5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 22
5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.5. "ptr" (do not use) . . . . . . . . . . . . . . . . . . . . 24 5.5. "ptr" (do not use) . . . . . . . . . . . . . . . . . . . . 25
5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 26 5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 27
5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 27
6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 28 6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 29
6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 28 6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 29
6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 29 6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 30
7. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1. Formal Specification . . . . . . . . . . . . . . . . . . . 31 7.1. Formal Specification . . . . . . . . . . . . . . . . . . . 32
7.2. Macro Definitions . . . . . . . . . . . . . . . . . . . . 31 7.2. Macro Definitions . . . . . . . . . . . . . . . . . . . . 32
7.3. Macro Processing Details . . . . . . . . . . . . . . . . . 32 7.3. Macro Processing Details . . . . . . . . . . . . . . . . . 33
7.4. Expansion Examples . . . . . . . . . . . . . . . . . . . . 34 7.4. Expansion Examples . . . . . . . . . . . . . . . . . . . . 35
8. Result Handling . . . . . . . . . . . . . . . . . . . . . . . 36 8. Result Handling . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 8.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . . . 36 8.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.6. Temperror . . . . . . . . . . . . . . . . . . . . . . . . 38 8.6. Temperror . . . . . . . . . . . . . . . . . . . . . . . . 39
8.7. Permerror . . . . . . . . . . . . . . . . . . . . . . . . 38 8.7. Permerror . . . . . . . . . . . . . . . . . . . . . . . . 39
9. Recording the Result . . . . . . . . . . . . . . . . . . . . . 39 9. Recording the Result . . . . . . . . . . . . . . . . . . . . . 40
9.1. The Received-SPF Header Field . . . . . . . . . . . . . . 39 9.1. The Received-SPF Header Field . . . . . . . . . . . . . . 40
9.2. SPF Results in the Authentication-Results Header Field . . 41 9.2. SPF Results in the Authentication-Results Header Field . . 42
10. Effects on Infrastructure . . . . . . . . . . . . . . . . . . 43 10. Effects on Infrastructure . . . . . . . . . . . . . . . . . . 44
10.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 43 10.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 44
10.1.1. DNS Resource Considerations . . . . . . . . . . . . . 43 10.1.1. DNS Resource Considerations . . . . . . . . . . . . . 44
10.1.2. Administrator's Considerations . . . . . . . . . . . . 44 10.1.2. Administrator's Considerations . . . . . . . . . . . . 45
10.1.3. Bounces . . . . . . . . . . . . . . . . . . . . . . . 45 10.1.3. Bounces . . . . . . . . . . . . . . . . . . . . . . . 46
10.2. Receivers . . . . . . . . . . . . . . . . . . . . . . . . 45 10.2. Receivers . . . . . . . . . . . . . . . . . . . . . . . . 46
10.3. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 45 10.3. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 46
11. Security Considerations . . . . . . . . . . . . . . . . . . . 47 11. Security Considerations . . . . . . . . . . . . . . . . . . . 48
11.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 47 11.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 48
11.2. SPF-Authorized Email May Contain Other False Identities . 48 11.2. SPF-Authorized Email May Contain Other False Identities . 49
11.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 48 11.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 49
11.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 48 11.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 49
11.5. Untrusted Information Sources . . . . . . . . . . . . . . 49 11.5. Untrusted Information Sources . . . . . . . . . . . . . . 50
11.5.1. Recorded Results . . . . . . . . . . . . . . . . . . . 49 11.5.1. Recorded Results . . . . . . . . . . . . . . . . . . . 50
11.5.2. External Explanations . . . . . . . . . . . . . . . . 49 11.5.2. External Explanations . . . . . . . . . . . . . . . . 50
11.5.3. Macro Expansion . . . . . . . . . . . . . . . . . . . 50 11.5.3. Macro Expansion . . . . . . . . . . . . . . . . . . . 51
11.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 50 11.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 51
11.7. Delivering Mail Producing a 'Fail' Result . . . . . . . . 50 11.7. Delivering Mail Producing a 'Fail' Result . . . . . . . . 51
12. Contributors and Acknowledgements . . . . . . . . . . . . . . 51 12. Contributors and Acknowledgements . . . . . . . . . . . . . . 52
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
13.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 52 13.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 53
13.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 52 13.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 53
13.3. SPF Modifier Registry . . . . . . . . . . . . . . . . . . 52 13.3. SPF Modifier Registry . . . . . . . . . . . . . . . . . . 53
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
14.1. Normative References . . . . . . . . . . . . . . . . . . . 53 14.1. Normative References . . . . . . . . . . . . . . . . . . . 54
14.2. Informative References . . . . . . . . . . . . . . . . . . 54 14.2. Informative References . . . . . . . . . . . . . . . . . . 55
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 56 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 57
Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 59 Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 60
B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 59 B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 60
B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 60 B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 61
B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 61 B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 62
B.4. Multiple Requirements Example . . . . . . . . . . . . . . 61 B.4. Multiple Requirements Example . . . . . . . . . . . . . . 62
Appendix C. Changes in implementation requirements from RFC Appendix C. Changes in implementation requirements from RFC
4408 . . . . . . . . . . . . . . . . . . . . . . . . 62 4408 . . . . . . . . . . . . . . . . . . . . . . . . 63
Appendix D. Further Testing Advice . . . . . . . . . . . . . . . 63 Appendix D. Further Testing Advice . . . . . . . . . . . . . . . 64
Appendix E. SPF/Mediator Interactions . . . . . . . . . . . . . . 64 Appendix E. SPF/Mediator Interactions . . . . . . . . . . . . . . 65
E.1. Originating ADMDs . . . . . . . . . . . . . . . . . . . . 64 E.1. Originating ADMDs . . . . . . . . . . . . . . . . . . . . 65
E.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 65 E.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 66
E.3. Receving ADMDs . . . . . . . . . . . . . . . . . . . . . . 65 E.3. Receving ADMDs . . . . . . . . . . . . . . . . . . . . . . 66
Appendix F. Mail Services . . . . . . . . . . . . . . . . . . . . 66 Appendix F. Mail Services . . . . . . . . . . . . . . . . . . . . 67
Appendix G. MTA Relays . . . . . . . . . . . . . . . . . . . . . 67 Appendix G. MTA Relays . . . . . . . . . . . . . . . . . . . . . 68
Appendix H. Local Policy Considerations . . . . . . . . . . . . . 68 Appendix H. Local Policy Considerations . . . . . . . . . . . . . 69
H.1. Policy For SPF Pass . . . . . . . . . . . . . . . . . . . 68 H.1. Policy For SPF Pass . . . . . . . . . . . . . . . . . . . 69
H.2. Policy For SPF Fail . . . . . . . . . . . . . . . . . . . 68 H.2. Policy For SPF Fail . . . . . . . . . . . . . . . . . . . 69
H.3. Policy For SPF Permerror . . . . . . . . . . . . . . . . . 69 H.3. Policy For SPF Permerror . . . . . . . . . . . . . . . . . 70
H.4. Policy For SPF Temperror . . . . . . . . . . . . . . . . . 69 H.4. Policy For SPF Temperror . . . . . . . . . . . . . . . . . 70
Appendix I. Protocol Status . . . . . . . . . . . . . . . . . . . 71 Appendix I. Protocol Status . . . . . . . . . . . . . . . . . . . 72
Appendix J. Change History . . . . . . . . . . . . . . . . . . . 72 Appendix J. Change History . . . . . . . . . . . . . . . . . . . 73
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 76
1. Introduction 1. Introduction
The current email infrastructure has the property that any host The current email infrastructure has the property that any host
injecting mail into the system can use any DNS domain name it wants injecting mail into the system can use any DNS domain name it wants
in each of the various identifiers specified by [RFC5321] and in each of the various identifiers specified by [RFC5321] and
[RFC5322]. Although this feature is desirable in some circumstances, [RFC5322]. Although this feature is desirable in some circumstances,
it is a major obstacle to reducing Unsolicited Bulk Email (UBE, aka it is a major obstacle to reducing Unsolicited Bulk Email (UBE, aka
spam). Furthermore, many domain owning ADMDs (as described in spam). Furthermore, many domain owning ADMDs (as described in
[RFC5598]) are understandably concerned about the ease with which [RFC5598]) are understandably concerned about the ease with which
skipping to change at page 11, line 45 skipping to change at page 11, line 45
2.6.5. Softfail 2.6.5. Softfail
The ADMD has published a weak statement that the host is probably not The ADMD has published a weak statement that the host is probably not
authorized. It has not published a stronger, more definitive policy authorized. It has not published a stronger, more definitive policy
that results in a "fail". that results in a "fail".
2.6.6. Temperror 2.6.6. Temperror
A "temperror" result means the SPF verifier encountered a transient A "temperror" result means the SPF verifier encountered a transient
(generally DNS) error while performing the check. A later retry may (generally DNS) error while performing the check. A later retry may
succeed without further operator action. succeed without further DNS operator action.
2.6.7. Permerror 2.6.7. Permerror
A "permerror" result means the domain's published records could not A "permerror" result means the domain's published records could not
be correctly interpreted. This signals an error condition that be correctly interpreted. This signals an error condition that
definitely requires operator intervention to be resolved. definitely requires DNS operator intervention to be resolved.
3. SPF Records 3. SPF Records
An SPF record is a DNS record that declares which hosts are, and are 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" not, authorized to use a domain name for the "HELO" and "MAIL FROM"
identities. Loosely, the record partitions hosts into permitted and identities. Loosely, the record partitions hosts into permitted and
not-permitted sets (though some hosts might fall into neither not-permitted sets (though some hosts might fall into neither
category). category).
The SPF record is expressed as a single string of text found in the The SPF record is expressed as a single string of text found in the
skipping to change at page 12, line 32 skipping to change at page 12, line 32
"a:colo.example.com/28" (the + is implied), and "-all". "a:colo.example.com/28" (the + is implied), and "-all".
Each SPF record is placed in the DNS tree at the owner name it Each SPF record is placed in the DNS tree at the owner name it
pertains to, not a subdomain under it, such as is done with SRV pertains to, not a subdomain under it, such as is done with SRV
records [RFC2782]. records [RFC2782].
The example in this section might be published via these lines in a The example in this section might be published via these lines in a
domain zone file: domain zone file:
example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"
smtp-out.example.com. TXT "v=spf1 a -all"
Since TXT records have multiple uses, beware of other TXT records Since TXT records have multiple uses, beware of other TXT records
published there for other purposes. They might cause problems with published there for other purposes. They might cause problems with
size limits (see Section 3.4) and care has to be taken to ensure only size limits (see Section 3.4) and care has to be taken to ensure only
SPF records are used for SPF processing. SPF records are used for SPF processing.
ADMDs publishing SPF records ought to keep the amount of DNS ADMDs publishing SPF records ought to keep the amount of DNS
information needed to evaluate a record to a minimum. Section 4.6.4 information needed to evaluate a record to a minimum. Section 4.6.4
and Section 10.1.1 provide some suggestions about "include" and Section 10.1.1 provide some suggestions about "include"
mechanisms and chained "redirect" modifiers. mechanisms and chained "redirect" modifiers.
3.1. DNS Resource Records 3.1. DNS Resource Records
SPF records MUST be published as a DNS TXT (type 16) Resource Record SPF records MUST be published as a DNS TXT (type 16) Resource Record
(RR) [RFC1035] only. The character content of the record is encoded (RR) [RFC1035] only. The character content of the record is encoded
as [US-ASCII]. Use of alternative DNS RR types was supported in as [US-ASCII]. Use of alternative DNS RR types was supported in
SPF's experimental phase, but has been discontinued. See Appendix A SPF's experimental phase, but has been discontinued.
of [RFC6686] for further information.
In 2003, when SPF was first being developed, the requirements for
assignment of a new DNS RR type were considerably more stringent than
they are now. Additionally, support for easy deployment of new DNS
RR types was not widely deployed in DNS servers and provisioning
systems. As a result, developers of SPF found it easier and more
practical to use the TXT RR type for SPF records.
In its review of [RFC4408] the SPFbis working group concluded that
its dual RR type transition model was fundamentally flawed since it
contained no common RR type that implementers were required to serve
and required to check. Many alternatives were considered to resolve
this issue, but ultimately the working group concluded that
significant migration to the SPF RR type in the forseeable future was
very unlikely and that the best solution for resolving this
interoperability issue was to drop support for the SPF RR type from
SPF version 1. See Appendix A of [RFC6686] for further information.
The circumstances surrounding SPF's initial deployment a decade ago
are unique. If a future update to SPF were developed that did not
reuse existing SPF records, it could use the SPF RR type. SPF's use
of the TXT RR type for structured data should in no way be taken as
precedent for future protocol designers. Further discussion of
design considerations when using new DNS RR types can be found in
[RFC5507].
3.2. Multiple DNS Records 3.2. Multiple DNS Records
A domain name MUST NOT have multiple records that would cause an A domain name MUST NOT have multiple records that would cause an
authorization check to select more than one record. See Section 4.5 authorization check to select more than one record. See Section 4.5
for the selection rules. for the selection rules.
3.3. Multiple Strings in a Single DNS record 3.3. Multiple Strings in a Single DNS record
As defined in [RFC1035] sections 3.3 and 3.3.14, a single text DNS As defined in [RFC1035] sections 3.3 and 3.3.14, a single text DNS
skipping to change at page 13, line 38 skipping to change at page 14, line 14
3.4. Record Size 3.4. Record Size
The published SPF record for a given domain name SHOULD remain small The published SPF record for a given domain name SHOULD remain small
enough that the results of a query for it will fit within 512 octets. enough that the results of a query for it will fit within 512 octets.
This UDP limit is defined in [RFC1035] section 2.3.4, although it was This UDP limit is defined in [RFC1035] section 2.3.4, although it was
raised by [RFC2671]. Staying below 512 octets ought to prevent older raised by [RFC2671]. Staying below 512 octets ought to prevent older
DNS implementations from failing over to TCP,and will work with UDP DNS implementations from failing over to TCP,and will work with UDP
in the absence of EDNS0 [RFC6891] support. Since the answer size is in the absence of EDNS0 [RFC6891] support. Since the answer size is
dependent on many things outside the scope of this document, it is dependent on many things outside the scope of this document, it is
only possible to give this guideline: If the combined length of the only possible to give this guideline: If the size of the DNS message,
DNS name and the text of all the records of a given type is under 450 the combined length of the DNS name and the text of all the records
octets, then DNS answers ought to fit in UDP packets. Records that of a given type is under 450 octets, then DNS answers ought to fit in
are too long to fit in a single UDP packet could be silently ignored UDP packets. Records that are too long to fit in a single UDP packet
by SPF verifiers due to firewall and other issues that interfere with could be silently ignored by SPF verifiers due to firewall and other
the operation of DNS over TCP or using ENDS0. issues that interfere with the operation of DNS over TCP or using
ENDS0.
Note that when computing the sizes for replies to queries of the TXT Note that when computing the sizes for replies to queries of the TXT
format, one has to take into account any other TXT records published format, one has to take into account any other TXT records published
at the domain name. Similarly, the sizes for replies to all queries at the domain name. Similarly, the sizes for replies to all queries
related to SPF have to be evaluated to fit in a single 512 octet UDP related to SPF have to be evaluated to fit in a single 512 octet UDP
packet. packet (i.e. DNS message size limited to 450 octects).
3.5. Wildcard Records 3.5. Wildcard Records
Use of wildcard records for publishing is discouraged and care has to Use of wildcard records for publishing is discouraged and care has to
be taken if they are used. If a zone includes wildcard MX records, be taken if they are used. If a zone includes wildcard MX records,
it might want to publish wildcard declarations, subject to the same it might want to publish wildcard declarations, subject to the same
requirements and problems. In particular, the declaration MUST be requirements and problems. In particular, the declaration MUST be
repeated for any host that has any RR records at all, and for repeated for any host that has any RR records at all, and for
subdomains thereof. Consider the example in [RFC1034], Section subdomains thereof. Consider the example in [RFC1034], Section
4.3.3. Based on that, we can do the following: 4.3.3. Based on that, we can do the following:
skipping to change at page 16, line 40 skipping to change at page 17, line 40
4.5. Selecting Records 4.5. Selecting Records
Records begin with a version section: Records begin with a version section:
record = version terms *SP record = version terms *SP
version = "v=spf1" version = "v=spf1"
Starting with the set of records that were returned by the lookup, Starting with the set of records that were returned by the lookup,
discard records that do not begin with a version section of exactly discard records that do not begin with a version section of exactly
"v=spf1". Note that the version section is terminated either by an "v=spf1". Note that the version section is terminated either by an
SP character or the end of the record. A record with a version SP character or the end of the record. As an example, a record with
section of "v=spf10" does not match and is discarded. a version section of "v=spf10" does not match and is discarded.
If the resultant record set includes no records, check_host() If the resultant record set includes no records, check_host()
produces the "none" result. If the resultant record set includes produces the "none" result. If the resultant record set includes
more than one record, check_host() produces the "permerror" result. more than one record, check_host() produces the "permerror" result.
4.6. Record Evaluation 4.6. Record Evaluation
The check_host() function parses and interprets the SPF record to The check_host() function parses and interprets the SPF record to
find a result for the current test. If there are any syntax errors find a result for the current test. If there are any syntax errors
anywhere in the record, check_host() returns immediately with the anywhere in the record, check_host() returns immediately with the
skipping to change at page 18, line 27 skipping to change at page 19, line 27
4.6.3. Modifiers 4.6.3. Modifiers
Modifiers are not mechanisms. They do not return match or not-match. Modifiers are not mechanisms. They do not return match or not-match.
Instead, they provide additional information. Although modifiers do Instead, they provide additional information. Although modifiers do
not directly affect the evaluation of the record, the "redirect" not directly affect the evaluation of the record, the "redirect"
modifier has an effect after all the mechanisms have been evaluated. modifier has an effect after all the mechanisms have been evaluated.
4.6.4. DNS Lookup Limits 4.6.4. DNS Lookup Limits
SPF implementations MUST limit the total number of mechanisms and Some mechanisms and modifiers (collectively, "terms") cause DNS
modifiers ("terms") that cause any DNS query to 10 during SPF queries at the time of evaluation, and some do not. The following
evaluation. Specifically, the "include", "a", "mx", "ptr", and terms cause DNS queries: the "include", "a", "mx", "ptr", and
"exists" mechanisms as well as the "redirect" modifier count against "exists" mechanisms and the "redirect" modifier. SPF implementations
this collective limit. The "all", "ip4", and "ip6" mechanisms do not MUST limit the total number of those terms to 10 during SPF
count against this limit. If this number is exceeded during a check, evaluation, to avoid unreasonable load on the DNS. If this limit is
a "permerror" MUST be returned. The "exp" modifier does not count exceeded, the implementation MUST return "permerror". The other
against this limit because the DNS lookup to fetch the explanation terms: the "all", "ip4", and "ip6" mechanisms do not cause DNS
string occurs after the SPF record evaluation has been completed. queries at the time of SPF evaluation (the "exp" modifier causes a
lookup at a later time), and their use, including "exp", is not
subject to this limit.
When evaluating the "mx" mechanism, the number of "MX" resource When evaluating the "mx" mechanism, the number of "MX" resource
records queried is included in the overall limit of 10 mechanisms/ records queried is included in the overall limit of 10 mechanisms/
modifiers that cause DNS lookups described above. The evaluation of modifiers that cause DNS lookups described above. The evaluation of
each "MX" record MUST NOT result in querying more than 10 address each "MX" record MUST NOT result in querying more than 10 address
records, either "A" or "AAAA" resource records. If this limit is records, either "A" or "AAAA" resource records. If this limit is
exceeded, the "mx" mechanism MUST produce a "permerror" result. exceeded, the "mx" mechanism MUST produce a "permerror" result.
When evaluating the "ptr" mechanism or the %{p} macro, the number of When evaluating the "ptr" mechanism or the %{p} macro, the number of
"PTR" resource records queried is included in the overall limit of 10 "PTR" resource records queried is included in the overall limit of 10
skipping to change at page 19, line 32 skipping to change at page 20, line 34
limit configurable. In this case, a default of two is RECOMMENDED. limit configurable. In this case, a default of two is RECOMMENDED.
4.7. Default Result 4.7. Default Result
If none of the mechanisms match and there is no "redirect" modifier, If none of the mechanisms match and there is no "redirect" modifier,
then the check_host() returns a result of "neutral", just as if then the check_host() returns a result of "neutral", just as if
"?all" were specified as the last directive. If there is a "?all" were specified as the last directive. If there is a
"redirect" modifier, check_host() proceeds as defined in Section 6.1. "redirect" modifier, check_host() proceeds as defined in Section 6.1.
It is better to use either a "redirect" modifier or an "all" It is better to use either a "redirect" modifier or an "all"
mechanism to explicitly terminate processing. Although the latter mechanism to explicitly terminate processing. Although there is an
has a default (specifically "?all"), it aids debugging efforts if it implicit "?all" at the end of every record that is not explicitly
is explicitly provided. terminated, it aids debugging efforts when it is explicitly provided.
For example: For example:
v=spf1 +mx -all v=spf1 +mx -all
or or
v=spf1 +mx redirect=_spf.example.com v=spf1 +mx redirect=_spf.example.com
4.8. Domain Specification 4.8. Domain Specification
Several of these mechanisms and modifiers have a domain-spec section. Several of these mechanisms and modifiers have a domain-spec section.
skipping to change at page 24, line 43 skipping to change at page 25, line 43
the mechanism matches. the mechanism matches.
Note regarding implicit MXes: If the <target-name> has no MX record, Note regarding implicit MXes: If the <target-name> has no MX record,
check_host() MUST NOT apply the implicit MX rules of[RFC5321] by check_host() MUST NOT apply the implicit MX rules of[RFC5321] by
querying for an A or AAAA record for the same name. querying for an A or AAAA record for the same name.
5.5. "ptr" (do not use) 5.5. "ptr" (do not use)
This mechanism tests whether the DNS reverse-mapping for <ip> exists This mechanism tests whether the DNS reverse-mapping for <ip> exists
and correctly points to a domain name within a particular domain. and correctly points to a domain name within a particular domain.
This mechanism SHOULD NOT be published. See below for discussion. This mechanism SHOULD NOT be published. See the note at the end of
this section for more information.
ptr = "ptr" [ ":" domain-spec ] ptr = "ptr" [ ":" domain-spec ]
The <ip>'s name is looked up using this procedure: The <ip>'s name is looked up using this procedure:
o Perform a DNS reverse-mapping for <ip>: Look up the corresponding o Perform a DNS reverse-mapping for <ip>: Look up the corresponding
PTR record in "in-addr.arpa." if the address is an IPv4 one and in PTR record in "in-addr.arpa." if the address is an IPv4 one and in
"ip6.arpa." if it is an IPv6 address. "ip6.arpa." if it is an IPv6 address.
o For each record returned, validate the domain name by looking up o For each record returned, validate the domain name by looking up
skipping to change at page 26, line 14 skipping to change at page 27, line 16
MUST support it. MUST support it.
5.6. "ip4" and "ip6" 5.6. "ip4" and "ip6"
These mechanisms test whether <ip> is contained within a given IP These mechanisms test whether <ip> is contained within a given IP
network. network.
ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ] ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ] ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
ip4-cidr-length = "/" 1*DIGIT ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32
ip6-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9 qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99 / %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199 / "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249 / "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255 / "25" %x30-35 ; 250-255
; as per conventional dotted quad notation. e.g., 192.0.2.0 ; as per conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as per [RFC 4291], section 2.2> ip6-network = <as per [RFC 4291], section 2.2>
skipping to change at page 36, line 7 skipping to change at page 37, line 7
%{d2}.trusted-domains.example.net %{d2}.trusted-domains.example.net
example.com.trusted-domains.example.net example.com.trusted-domains.example.net
IPv6: IPv6:
%{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0. %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com
8. Result Handling 8. Result Handling
This section provides guidance for operators in response to the This section provides guidance for SPF verifier operators in response
various possible outputs of check_host() on a message. Definitions to the various possible outputs of check_host() on a message.
of SPF results are presented in Section 2.6; this section provides Definitions of SPF results are presented in Section 2.6; this section
more detail on each for use in developing local policy for message provides more detail on each for use in developing local policy for
handling. message handling.
Every operating environment is different. There are some receivers Every operating environment is different. There are some receivers
for whom strict adherence to SPF is appropriate, and definitive for whom strict adherence to SPF is appropriate, and definitive
treatment of messages that are evaluated to be explicitly treatment of messages that are evaluated to be explicitly
unauthorized ("fail" and sometimes "softfail") is the norm. There unauthorized ("fail" and sometimes "softfail") is the norm. There
are others for which the "false negative" cases are more of a are others for which the "false negative" cases are more of a
concern. This concern is typically handled by merely recording the concern. This concern is typically handled by merely recording the
result in the header and allowing the message to pass on for result in the header and allowing the message to pass on for
additional processing. There are still others where SPF is one of additional processing. There are still others where SPF is one of
several inputs to the message handling decision. As such, there is several inputs to the message handling decision. As such, there is
skipping to change at page 38, line 28 skipping to change at page 39, line 28
software SHOULD use an SMTP reply code of 451 and, if supported, the software SHOULD use an SMTP reply code of 451 and, if supported, the
4.4.3 enhanced status code (see [RFC3463], Section 3.5). These 4.4.3 enhanced status code (see [RFC3463], Section 3.5). These
errors can be caused by problems in either the sender's or receiver's errors can be caused by problems in either the sender's or receiver's
DNS software. See Appendix H.4 for considerations on developing DNS software. See Appendix H.4 for considerations on developing
local policy. local policy.
8.7. Permerror 8.7. Permerror
A "permerror" result means the domain's published records could not A "permerror" result means the domain's published records could not
be correctly interpreted. This signals an error condition that be correctly interpreted. This signals an error condition that
definitely requires operator intervention to be resolved. If the definitely requires DNS operator intervention to be resolved. If the
message is rejected during the SMTP transaction for this reason, the message is rejected during the SMTP transaction for this reason, the
software SHOULD use an SMTP reply code of 550 and, if supported, the software SHOULD use an SMTP reply code of 550 and, if supported, the
5.5.2 enhanced status code (see [RFC3463], Section 3.6). Be aware 5.5.2 enhanced status code (see [RFC3463], Section 3.6). Be aware
that if the ADMD uses macros (Section 7), it is possible that this that if the ADMD uses macros (Section 7), it is possible that this
result is due to the checked identities having an unexpected format. result is due to the checked identities having an unexpected format.
It is also possible that this result is generated by certain SPF It is also possible that this result is generated by certain SPF
verifiers due to the input arguments having an unexpected format; see verifiers due to the input arguments having an unexpected format; see
Section 4.8. See Appendix H.3 for considerations on developing local Section 4.8. See Appendix H.3 for considerations on developing local
policy. policy.
9. Recording the Result 9. Recording the Result
To provide downstream agents, such as MUAs, with the information they To provide downstream agents, such as MUAs, with the information they
might need in terms of evaluating or representing the apparent safety might need in terms of evaluating or representing the apparent safety
of the message content, it is RECOMMENDED that SMTP receivers record of the message content, it is RECOMMENDED that SMTP receivers record
the result of SPF processing in the message header. For operators the result of SPF processing in the message header. For SPF verifier
that choose to record SPF results in the header of the message for operators that choose to record SPF results in the header of the
processing by internal filters or MUAs, two methods are presented. message for processing by internal filters or MUAs, two methods are
Section 9.1 defines the Received-SPF field, which is the results presented. Section 9.1 defines the Received-SPF field, which is the
field originally defined for SPF use. Section 9.2 discusses results field originally defined for SPF use. Section 9.2 discusses
Authentication-Results [RFC5451] which was specified more recently Authentication-Results [RFC5451] which was specified more recently
and is designed for use by SPF and other authentication methods. and is designed for use by SPF and other authentication methods.
Both are in common use, and hence both are included here. However, Both are in common use, and hence both are included here. However,
it is important to note that they were designed to serve slightly it is important to note that they were designed to serve slightly
different purposes. Received-SPF is intended to include enough different purposes. Received-SPF is intended to include enough
information to enable reconstruction of the SPF evaluation of the information to enable reconstruction of the SPF evaluation of the
message, while Authentication-Results is designed only to relay the message, while Authentication-Results is designed only to relay the
result itself and related output details of likely use to end users result itself and related output details of likely use to end users
(e.g., what property of the message was actually authenticated and (e.g., what property of the message was actually authenticated and
what it contained), leaving reconstructive work to the purview of what it contained), leaving reconstructive work to the purview of
system logs and the Received field contents. Also, Received-SPF system logs and the Received field contents. Also, Received-SPF
relies on compliance of agents within the receiving ADMD to adhere to relies on compliance of agents within the receiving ADMD to adhere to
the header field ordering rules of [RFC5321] and [RFC5322], while the header field ordering rules of [RFC5321] and [RFC5322], while
Authentication-Results includes some provisions to protect against Authentication-Results includes some provisions to protect against
non-compliant implementations. non-compliant implementations.
An operator could choose to use both to serve different downstream An SPF verifier operator could choose to use both to serve different
agents. In such cases, care needs to be taken to ensure both fields downstream agents. In such cases, care needs to be taken to ensure
are conveying the same details, or unexpected results can occur. both fields are conveying the same details, or unexpected results can
occur.
9.1. The Received-SPF Header Field 9.1. The Received-SPF Header Field
The Received-SPF header field is a trace field (see [RFC5322] Section 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 3.6.7) and SHOULD be prepended to the existing header, above the
Received: field that is generated by the SMTP receiver. It MUST Received: field that is generated by the SMTP receiver. It MUST
appear above all other Received-SPF fields in the message. The appear above all other Received-SPF fields in the message. The
header field has the following format: header field has the following format:
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
skipping to change at page 55, line 11 skipping to change at page 56, line 11
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006. Plan", BCP 122, RFC 4632, August 2006.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension
for Authentication", RFC 4954, July 2007. for Authentication", RFC 4954, July 2007.
[RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design
Choices When Expanding the DNS", RFC 5507, April 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782,
February 2010. February 2010.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, November 2011. STD 72, RFC 6409, November 2011.
skipping to change at page 56, line 40 skipping to change at page 57, line 40
ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ] ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ] ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
exists = "exists" ":" domain-spec exists = "exists" ":" domain-spec
modifier = redirect / explanation / unknown-modifier modifier = redirect / explanation / unknown-modifier
redirect = "redirect" "=" domain-spec redirect = "redirect" "=" domain-spec
explanation = "exp" "=" domain-spec explanation = "exp" "=" domain-spec
unknown-modifier = name "=" macro-string unknown-modifier = name "=" macro-string
; where name is not any known modifier ; where name is not any known modifier
ip4-cidr-length = "/" 1*DIGIT ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32
ip6-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9 qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99 / %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199 / "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249 / "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255 / "25" %x30-35 ; 250-255
; conventional dotted quad notation. e.g., 192.0.2.0 ; conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as per [RFC 4291], section 2.2> ip6-network = <as per [RFC 4291], section 2.2>
skipping to change at page 69, line 28 skipping to change at page 70, line 28
receiver can do to draw attention to the difficulty encountered while receiver can do to draw attention to the difficulty encountered while
protecting itself from messages that do not have a definite SPF protecting itself from messages that do not have a definite SPF
result of some kind. However, if the SPF implementation is defective result of some kind. However, if the SPF implementation is defective
and returns spurious "permerror" results, only the sender is actively and returns spurious "permerror" results, only the sender is actively
notified of the defect (in the form of rejected mail), and not the notified of the defect (in the form of rejected mail), and not the
receiver making use of SPF. receiver making use of SPF.
The less intrusive handling choice is to deliver the message, perhaps The less intrusive handling choice is to deliver the message, perhaps
with some kind of annotation of the difficulty encountered and/or with some kind of annotation of the difficulty encountered and/or
logging of a similar nature. However, this will not be desirable to logging of a similar nature. However, this will not be desirable to
operators that wish to implement SPF checking as strictly as SPF verifier operators that wish to implement SPF checking as
possible, nor is this sort of passive problem reporting typically strictly as possible, nor is this sort of passive problem reporting
effective. typically effective.
There is of course the option placing this choice in the hands of the There is of course the option placing this choice in the hands of the
operator rather than the implementer since this kind of choice is SPF verifier operator rather than the implementer since this kind of
often a matter of local policy rather than a condition with a choice is often a matter of local policy rather than a condition with
universal solution, but this adds one more piece of complexity to an a universal solution, but this adds one more piece of complexity to
already non-trivial environment. an already non-trivial environment.
Both implementers and operators need to be cautious of all choices Both implementers and SPF verfier operators need to be cautious of
and outcomes when handling SPF results. all choices and outcomes when handling SPF results.
H.4. Policy For SPF Temperror H.4. Policy For SPF Temperror
The "temperror" result (see Section 2.6.6) indicates the SPF The "temperror" result (see Section 2.6.6) indicates the SPF
processing module at the receiver could not retrieve and SPF policy processing module at the receiver could not retrieve and SPF policy
record due to a (probably) transient condition. This gives no true record due to a (probably) transient condition. This gives no true
indication about the authorized use of the data found in the indication about the authorized use of the data found in the
envelope. envelope.
As with all results, implementers have a choice to make regarding As with all results, implementers have a choice to make regarding
skipping to change at page 70, line 23 skipping to change at page 71, line 23
Because of long queue lifetimes, it is possible that mail will be Because of long queue lifetimes, it is possible that mail will be
repeatedly deferred for several days and so any awareness by the repeatedly deferred for several days and so any awareness by the
sender of a problem could be quite delayed. If "temperrors" persist sender of a problem could be quite delayed. If "temperrors" persist
for multiple delivery attempts, it might be preferable to treat the for multiple delivery attempts, it might be preferable to treat the
error as permanent and reduce the amount of time the message is in error as permanent and reduce the amount of time the message is in
transit. transit.
The less intrusive handling choice is to deliver the message, perhaps The less intrusive handling choice is to deliver the message, perhaps
with some kind of annotation of the difficulty encountered and/or with some kind of annotation of the difficulty encountered and/or
logging of a similar nature. However, this will not be desirable to logging of a similar nature. However, this will not be desirable to
operators that wish to implement SPF checking as strictly as SPF verifier operators that wish to implement SPF checking as
possible, nor is this sort of passive problem reporting typically strictly as possible, nor is this sort of passive problem reporting
effective. typically effective.
There is of course the option placing this choice in the hands of the There is of course the option placing this choice in the hands of the
operator rather than the implementer since this kind of choice is SPF verifier operator rather than the implementer since this kind of
often a matter of local policy rather than a condition with a choice is often a matter of local policy rather than a condition with
universal solution, but this adds one more piece of complexity to an a universal solution, but this adds one more piece of complexity to
already non-trivial environment. an already non-trivial environment.
Both implementers and operators need to be cautious of all choices Both implementers and SPF verifier operators need to be cautious of
and outcomes when handling SPF results. all choices and outcomes when handling SPF results.
Appendix I. Protocol Status Appendix I. Protocol Status
NOTE TO RFC EDITOR: To be removed prior to publication. NOTE TO RFC EDITOR: To be removed prior to publication.
SPF has been in development since the summer of 2003 and has seen SPF has been in development since the summer of 2003 and has seen
deployment beyond the developers beginning in December 2003. The deployment beyond the developers beginning in December 2003. The
design of SPF slowly evolved until the spring of 2004 and has since design of SPF slowly evolved until the spring of 2004 and has since
stabilized. There have been quite a number of forms of SPF, some stabilized. There have been quite a number of forms of SPF, some
written up as documents, some submitted as Internet Drafts, and many written up as documents, some submitted as Internet Drafts, and many
 End of changes. 30 change blocks. 
156 lines changed or deleted 187 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--nextPart459656491.JZNEy2MKK3-- From spf2@kitterman.com Wed Sep 11 21:58: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 64E9621F9FAC for ; Wed, 11 Sep 2013 21:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.379, 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 UKdsluzP14+9 for ; Wed, 11 Sep 2013 21:58:09 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8860821F9FAD for ; Wed, 11 Sep 2013 21:58:09 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0B65920E40EA; Thu, 12 Sep 2013 00:58:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1378961889; bh=60MRm4DTjT1dJHLC9TfeqA8uXcWuaNGHZqpD99PHLk4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=He5gscUbaDTm88sCCwdwvDHOMrPjy+sWKHTbuTvvbrhSr2/99MqdFu9GMGfLsmPWw cpnNxcueMdIBoFBBhoOBOyLhYvqnoeQnHzI1UbG1FpxWarnprQT5Pu17XXFAVcUg08 NKg3RLr+ByOhu737VLq1pW5HqR4XrH9sq9YVI6TY= 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 DD87120E40D2; Thu, 12 Sep 2013 00:58:08 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 12 Sep 2013 00:58:08 -0400 Message-ID: <1876295.3zJYQE0Gan@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <1409783.xNJeGdWPul@scott-latitude-e6320> References: <20130911015837.30196.11175.idtracker@ietfa.amsl.com> <1409783.xNJeGdWPul@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] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 12 Sep 2013 04:58:14 -0000 On Wednesday, September 11, 2013 17:38:27 Scott Kitterman wrote: > On Wednesday, September 11, 2013 10:23:57 Murray S. Kucherawy wrote: > > On Wed, Sep 11, 2013 at 5:04 AM, S Moonesamy wrote: > > >> ------------------------------**------------------------------** > > >> ---------- > > >> COMMENT: > > >> ------------------------------**------------------------------** > > >> ---------- > > >> > > >> I have a bunch of editorial comments that I'd like you to consider. > > >> They're all non-blocking, but I think they'll improve the document, and > > >> I'll be happy to chat about them if you like. > > >> > > >> -- Section 2.5 -- > > >> > > >> Performing the authorization check other than using the MAIL FROM > > >> and > > >> client address at the time of the MAIL command during the SMTP > > >> transaction can cause problems, such as the following: (1) It might > > >> be difficult to accurately extract the required information from > > >> potentially deceptive headers; (2) legitimate email might fail > > >> because the sender's policy had since changed. > > >> > > >> I found that to be awkwardly worded and hard to understand. Please > > >> consider this rewrite: > > >> > > >> NEW > > >> > > >> The authorization check is performed during the SMTP transaction > > >> at the time of the MAIL command, and uses the MAIL FROM value and > > >> the client IP address. Performing the check at later times or > > >> with other input can cause problems such as the following: > > >> > > >> * It might be difficult to accurately extract the required > > >> > > >> information from potentially deceptive headers. > > >> > > >> * Legitimate email might fail the authorization check because > > >> > > >> the sender's policy has since changed. > > >> > > >> END > > > > Seems reasonable. > > Agreed. > > > >> -- Section 2.6 -- > > >> > > >> It would really read best if the subsections were worded to be > > >> parallel. > > >> As it stands, subsections 1, 3, 4, 6, and 7 are worded as "result X > > >> means > > >> Y", and subsections 2 and 5 are not. Can you re-word 2 and 5 to be > > >> parallel to the others? > > > > Seems reasonable. > > Agreed. > > > >> Also, why are "neutral" and "fail" called "explicit statements", but > > >> "pass", for example, is not? > > > > I agree, "pass" should be. > > Yep. > > > >> -- Section 3 -- > > >> > > >> Each SPF record is placed in the DNS tree at the owner name it > > >> pertains to, not a subdomain under it, such as is done with SRV > > >> records [RFC2782]. > > >> > > >> This looks like it's saying that SRV records are placed in subdomains, > > >> and I don't think that's what you mean. Or is it? In any case, it's > > >> not > > >> clear (and I know this text is from the original). > > >> > > >> Maybe this (which also avoids the two different "it"s)?: > > >> > > >> NEW > > >> > > >> Each SPF record is placed in the DNS tree at the owner name it > > >> pertains to, not in a subdomain under the owner name. This is > > >> similar to how SRV records [RFC2782] are done. > > >> > > >> END > > > > Seems reasonable. > > Agreed. > > > >> The example in this section might be published via these lines in a > > >> > > >> domain zone file: > > >> example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" > > >> smtp-out.example.com. TXT "v=spf1 a -all" > > >> > > >> What does "smtp-out" have to do with anything? It's not otherwise > > >> used, > > >> and it seems to contradict what you say about subdomains in the > > >> previous > > >> paragraph. > > > > Hmm. Someone else will have to comment on this one. > > Those are just two examples, but the preceding text is poorly worded (I > checked and it's no better in RFC 4408). How about this instead, to > clarify: > > The example in this section (plus an additional SPF record for > smtp-out.example.com) might be published via these lines in a > domain zone file: > > example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" > smtp-out.example.com. TXT "v=spf1 a -all" > > > >> -- Section 4 -- > > >> > > >> This description is not an API (Application Program Interface) > > >> definition, > > >> > > >> Two total nits on this: > > >> 1. You never use "API" other than here, so there's no need to define > > >> it, > > >> and > > >> 2. the usual expansion of "API" is application programMING interface. > > >> I suggest, "This description is not an application programming > > >> interface > > >> definition, [etc]." > > > > Seems reasonable. > > Agreed. > > > >> -- Section 4.5 -- > > >> > > >> Starting with the set of records that were returned by the lookup, > > >> discard records that do not begin with a version section of exactly > > >> "v=spf1". Note that the version section is terminated either by an > > >> SP character or the end of the record. A record with a version > > >> section of "v=spf10" does not match and is discarded. > > >> > > >> Sure, and "v=spf1.0" doesn't match, and "v=spf11" doesn't match, > > >> and.... > > >> Why is it necessary or desirable to single out "v=spf10" here? > > > > I think "v=spf1.0" is actually the better (and perhaps intended) example, > > meaning "don't just stuff the part after 'spf' through a number parser and > > make sure 1 comes out". > > The intent here is to show that you have to look at least one character past > "v=spf1" to know if it's an SPF record or not. It's an example. As such, > it doesn't matter much wrt the point if it's "v=spf10", "v=spf1.0", or or > "v=spf1hatespf". None of those start SPF records. What's there is > unchanged from RFC 4408. I don't seem much of a point in changing it, but > if others think 1.0 is better than 10, I don't mind. > > > >> -- Section 4.6.4 -- > > >> > > >> SPF implementations MUST limit the total number of mechanisms and > > >> modifiers ("terms") that cause any DNS query to 10 during SPF > > >> evaluation. Specifically, the "include", "a", "mx", "ptr", and > > >> "exists" mechanisms as well as the "redirect" modifier count against > > >> this collective limit. The "all", "ip4", and "ip6" mechanisms do > > >> not > > >> count against this limit. If this number is exceeded during a > > >> check, > > >> a "permerror" MUST be returned. The "exp" modifier does not count > > >> against this limit because the DNS lookup to fetch the explanation > > >> string occurs after the SPF record evaluation has been completed. > > >> > > >> When I read this, I start feeling like I'm being read the rules for > > >> Fizzbin > > >> > >> / > > >> wiki/Fizzbin#Fizzbin>>.>> > > >> > > >> I would > > >> > > >> appreciate it if this was re-worded so that there are two clear lists > > >> here: the terms that are included in the "limit of 10", and the terms > > >> that are not (and are, presumably, unlimited). Perhaps something like > > >> this: > > >> > > >> NEW > > >> > > >> Some mechanisms and modifiers (collectively, "terms") cause DNS > > >> queries at the time of evaluation, and some do not. The following > > >> terms cause DNS queries: . SPF implementations > > >> MUST limit the total number of those terms to 10 during SPF > > >> evaluation, to avoid unreasonable load on the DNS. If this limit > > >> is exceeded, the implementation MUST return "permerror". The other > > >> terms () do not cause DNS queries at the time of > > >> SPF evaluation, and their use is not subject to this limit. > > >> > > >> END > > >> > > >> If you think it's necessary (I don't): > > >> > > >> NEW+ > > >> > > >> The other > > >> terms () do not cause DNS queries at the time of > > >> SPF evaluation (the "exp" modifier causes a lookup at a later time), > > >> and their use is not subject to this limit. > > >> > > >> END > > > > I like the new text, and prefer the second bit be included. > > If we change, and I think that's reasonable, the second bit should > definitely be included. "exp" not counting in the 10 has confused people > and we should be explicit about it. > > > >> Then in the next two paragraphs, I think it would improve clarity to > > >> make > > >> a change such as this: > > >> > > >> OLD > > >> > > >> When evaluating the "mx" mechanism, the number of "MX" resource > > >> records queried is included in the overall limit of 10 mechanisms/ > > >> modifiers that cause DNS lookups described above. The evaluation of > > >> each "MX" record MUST NOT result in querying more than 10 address > > >> records, > > >> > > >> NEW > > >> > > >> When evaluating the "mx" mechanism, the number of "MX" resource > > >> records queried is included in the overall limit of 10 mechanisms/ > > >> modifiers that cause DNS lookups described above. In addition to > > >> that limit, the evaluation of each "MX" record MUST NOT result in > > >> querying more than 10 address records, > > >> > > >> END > > >> > > >> (And similarly for the "ptr" paragraph.) I know you say this in a > > >> paragraph of its own ("These limits are per mechanism..."), but it's > > >> helpful if people can understand things as they read them, and then to > > >> emphasize it later... rather than having them scratch their heads for a > > >> few paragraphs until they get to it. > > > > +1 to that part too. > > Seems reasonable. > > > > -- Section 4.7 -- > > > > > >> It is better to use either a "redirect" modifier or an "all" > > >> mechanism to explicitly terminate processing. Although the latter > > >> has a default (specifically "?all"), it aids debugging efforts if it > > >> is explicitly provided. > > >> > > >> I'm not sure what "the latter has a default" is trying to say. Do you > > >> mean that "?all" is the default if you fall off the end, but you > > >> shouldn't rely on that? Or do you mean that if you say "all", then > > >> "?all" is taken as the default (I would think "all" would mean "+all")? > > >> Will you try re-wording this, please? > > > > The former ("?all" is implicit if you fall off the end). Suggest: > > > > It is better to use either a "redirect" modifier or an "all" mechanism to > > explicitly terminate processing. Although there is in effect a "?all" > > implicit at the end of every record, it ads debigging efforts when it is > > explicitly provided. > > How about: > > It is better to use either a "redirect" modifier or an "all" mechanism to > explicitly terminate processing. Although there is an implicit "?all" at > the end of every record that is not explicitly terminated, it aids > debugging efforts when it is explicitly provided. > > > >> -- Section 5 -- > > >> > > >> What does "(do not publish)" mean next to "ptr" in the sender > > >> mechanisms > > >> list? Ah; I see; it matches the "do not use" in Section 5.5. You > > >> should > > >> probably change this to "(do not use; see the note in Section 5.5)". > > > > Seems reasonable. > > OK. > > > >> It would help, I think, to add to the end of the second paragraph, "The > > >> basic mechanisms are as follows:", and to the end of the third > > >> paragraph, > > >> "The designated sender mechanisms are as follows:". Otherwise, there > > >> are > > >> just these disembodied lists, and the reader has to infer those > > >> introductions. > > > > Sure. > > Agreed. > > > >> -- Section 5.1 -- > > >> > > >> Mechanisms after "all" will never be tested. Mechanisms listed > > >> after > > >> "all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST > > >> be > > >> ignored when there is an "all" mechanism in the record. > > >> > > >> This says that the redirect in the following record will be ignored: > > >> v=spf1 redirect=_spf.example.com +all > > >> > > >> That's sufficiently odd that it should be called out explicitly, > > >> perhaps > > >> by adding "regardless of the relative ordering of the terms" to the > > >> last > > >> sentence in the quote. > > > > Yep. > > OK. > > > >> -- Section 5.2 -- > > >> > > >> 3. The recursive evaluation returns either match, not match, or an > > >> > > >> error. If it matches, then the appropriate result for the > > >> include: mechanism is used (e.g. include or +include produces a > > >> "pass" result and -include produces "fail"). > > >> > > >> 4. If there is no match, the parent check_host() resumes processing > > >> > > >> as per the table below, with the previous value of > > >> restored. > > >> > > >> A few things here: > > >> > > >> 1. Nit: "either" is for two things; for more than two, please remove > > >> the > > >> word "either" (or replace it with "one of", but that seems awkward > > >> here). > > >> > > >> 2. "If it matches" is not parallel to "returns match", and similarly > > >> for > > >> "if there is no match". > > >> > > >> 3. You don't say what happens if the recursive evaluation returns an > > >> error. Unfortuately, "no match" and "not match" are sufficiently > > >> similar > > >> to be confused. > > >> > > >> I suggest this: > > >> > > >> NEW > > >> > > >> 3. The recursive evaluation returns match, not match, or an > > >> > > >> error. > > >> > > >> 4. If it returns match, then the appropriate result for the > > >> > > >> include: mechanism is used (e.g., include or +include produces > > >> a "pass" result and -include produces "fail"). > > >> > > >> 5. If it returns not match or an error, the parent check_host() > > >> > > >> resumes processing as per the table below, with the previous > > >> value of restored. > > >> > > >> END > > > > +1. > > I think this is fine. > > > >> The "include" mechanism is intended for crossing administrative > > >> boundaries. For example, if example.com and example.org were > > >> managed > > >> by the same entity, and if the permitted set of hosts for both > > >> domains was "mx:example.com", it would be possible for example.org > > >> to > > >> specify "include:example.com", but it would be preferable to specify > > >> "redirect=example.com" or even "mx:example.com". > > >> > > >> The text you eliminated here provided a buffer that's no longer there, > > >> making the "For example," very odd. You talk about crossing admin > > >> boundaries and immediately follow it with an example that does NOT. I > > >> think it would be better to put a sentence in to restore that buffer -- > > >> perhaps, "When remaining within one administrative authority, "include" > > >> is usually not the best choice." > > > > Sure. > > Agreed. > > > >> -- Section 5.5 -- > > >> > > >> This mechanism SHOULD NOT be published. See below for discussion. > > >> > > >> It's quite a bit below. I suggest "See the note at the end of this > > >> section for more information." It might even be worth putting that > > >> note > > >> into a Section 5.5.1, so it's highlighted and more easily cited. > > > > +1. > > OK. Someone let me know which way I should do it. I'm OK with either. > > > >> -- Section 6 -- > > >> > > >> Unrecognized modifiers MUST be ignored no matter where in a record, > > >> or how often. > > >> > > >> This is missing a couple of words: > > >> > > >> NEW > > >> > > >> Unrecognized modifiers MUST be ignored no matter where in a record > > >> they appear, or how often. > > >> > > >> END > > > > +1. > > OK. > > > >> For clarity, any "redirect" modifier SHOULD appear as the very last > > >> term in a record. > > >> > > >> I don't usually recommend repeating things, but one thing from earlier > > >> probably does bear repeating here: > > >> > > >> NEW > > >> > > >> For clarity, any "redirect" modifier SHOULD appear as the very last > > >> term in a record. Any "redirect" modifier MUST be ignored if there > > >> is an "all" mechanism anywhere in the record. > > >> > > >> END > > > > Seems reasonable. > > OK. > > Thanks for the detailed review and msk's comments on the comments. I just realized the update to the draft I just posted doesn't include any of these changes. They are not (now) forgotten. I'll included them next time I update things. Scott K From sm@elandsys.com Wed Sep 11 23:11: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 2FA4521E8148; Wed, 11 Sep 2013 23:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 06SMm+-IwKRv; Wed, 11 Sep 2013 23:11:20 -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 68F2121E8147; Wed, 11 Sep 2013 23:11:20 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.34]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8C6B13D012700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Sep 2013 23:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378966274; bh=0VZJJLP6m8JDQiZOt7SdPnM/FMg0WXHAqDWvGONY8zA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qaEdlz/a3J+C15vOGZOJxLN0Mu7Tx9jlVrWyUlrxDwPvF8AI7T4vnwq2Fka41DBPt 5b7sdr/dIzfTu25B6E5T2j70Kk2OETzpdKBgONhrQKyB7GAOsClx9HlNTya6LQ/leq QqlmCgjq1SFMKkun/vSi+3DdEZT2IzRNNZ3YYsyI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378966274; i=@elandsys.com; bh=0VZJJLP6m8JDQiZOt7SdPnM/FMg0WXHAqDWvGONY8zA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=s86cv391Q1UoOn1ILRWPczXEJrEbX8aKpqN3uxZMi8LFUWsWNq0F1xzNnRqIbHQkm yLPXnZCg7+R3xup5x3ZaYXa3nMYdZZGSf7C+3xN7HYmvLAVo+eVW6YRPmPZUGj5G7Q NKvMvi95tlFfpXTGmJVJ4QPA/voNI6MFb7knAZTs= Message-Id: <6.2.5.6.2.20130911224817.0bdcd030@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Sep 2013 22:54:54 -0700 To: Pete Resnick , The IESG From: S Moonesamy In-Reply-To: <2405077.Cn8DraDvER@scott-latitude-e6320> References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <1623078.iZZXT7WM88@scott-latitude-e6320> <6.2.5.6.2.20130911150339.0c435c60@elandnews.com> <2405077.Cn8DraDvER@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 12 Sep 2013 06:11:21 -0000 Hi Pete, The DISCUSS was as follows: >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >Holding my own DISCUSS: > >Text needs to be created (probably for section 3.1) to better describe >the reason this document settled on TXT RR only and therefore why no >precedent is set for future use of the TXT RR. Here is the revised section 3.1: 3.1. DNS Resource Records SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only. The character content of the record is encoded as [US-ASCII]. Use of alternative DNS RR types was supported in SPF's experimental phase, but has been discontinued. In 2003, when SPF was first being developed, the requirements for assignment of a new DNS RR type were considerably more stringent than they are now. Additionally, support for easy deployment of new DNS RR types was not widely deployed in DNS servers and provisioning systems. As a result, developers of SPF found it easier and more practical to use the TXT RR type for SPF records. In its review of [RFC4408] the SPFbis working group concluded that its dual RR type transition model was fundamentally flawed since it contained no common RR type that implementers were required to serve and required to check. Many alternatives were considered to resolve this issue, but ultimately the working group concluded that significant migration to the SPF RR type in the foreseeable future was very unlikely and that the best solution for resolving this interoperability issue was to drop support for the SPF RR type from SPF version 1. See Appendix A of [RFC6686] for further information. The circumstances surrounding SPF's initial deployment a decade ago are unique. If a future update to SPF were developed that did not reuse existing SPF records, it could use the SPF RR type. SPF's use of the TXT RR type for structured data should in no way be taken as precedent for future protocol designers. Further discussion of design considerations when using new DNS RR types can be found in [RFC5507]. Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Wed Sep 11 23:16:48 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 5AED521E813A for ; Wed, 11 Sep 2013 23:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 YmS1U7MiVULS for ; Wed, 11 Sep 2013 23:16:47 -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 415F821E814D for ; Wed, 11 Sep 2013 23:16:43 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.34]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8C6GRxP010540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Sep 2013 23:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378966599; bh=3EhDyqChkZLBEuUwGCOUt2t2Ri54neFBPqBzw7g92vo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jPbvPmGbvUKS5qtn2di1/nN7IcHl10S7mxBQ6w2wqcemQer6o4VGc1ixdz/cgmGmR xgqpNJ9qsepP7hyOcNN2ngaMv/7hE96bHe+eM2ogazfv/kcwLQWgZCsbfMd5TVMP33 H9cKuow+tH+bL2IWLXWp310cdUpOK0Ycnnl44B8U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378966599; i=@elandsys.com; bh=3EhDyqChkZLBEuUwGCOUt2t2Ri54neFBPqBzw7g92vo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fJhRH2PzWpZzsYRQf0KArZbvCUfs8afQe4XKaPxpH3pPiuwtiPP3QTORT0v6iMvvV HdDxPTNfLbzNDc6UGa53gpftfq5AzLEngoDm3e1Q7UeLRWI5CuKgrSnptsFnxxnntb xSvQ/htmyRTBnbwN0Hka7UfXPRL0DM8SgcSF66gw= Message-Id: <6.2.5.6.2.20130911225513.0cd8fc00@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Sep 2013 23:15:46 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <2405077.Cn8DraDvER@scott-latitude-e6320> References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <1623078.iZZXT7WM88@scott-latitude-e6320> <6.2.5.6.2.20130911150339.0c435c60@elandnews.com> <2405077.Cn8DraDvER@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: [spfbis] DISCUSSes and SecDir review (was: Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT)) 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, 12 Sep 2013 06:16:48 -0000 Hi Scott, Thanks for all the work. I'll wait for Pete's response. I suggest that we focus on the other parts of the draft as from now. At 21:49 11-09-2013, Scott Kitterman wrote: >Done. rfcdiff of the full post -19 diff attached. I've applied the >changes due >to Barry's comments as well. Ok. >Here is the revised section 3.1: Thanks. >I am waiting any changes based on the SECDIR review for some responses to my >last message on that topic. I'll send the reply to the SECDIR review. I'll recommend no change for the DKIM issue mentioned in the review. It should be possible to address Issue 1 ( http://www.ietf.org/mail-archive/web/spfbis/current/msg04135.html ). The response to Issues 2 and 3 look okay to me. There is already text from Barry's DISCUSS (Thanks, Barry) to fix Section 4.6. There was a comment from Pete about the size limitations in 3.4. I'll have to go over the discussion again for that one. As a note to the working group please let me know if I missed any part of the draft that requires a change in response to the IESG Evaluation. Regards, S. Moonesamy (as document shepherd) From mansaxel@besserwisser.org Thu Sep 12 00: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 5056211E817B; Thu, 12 Sep 2013 00:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=0.652, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 YmYfkEs8pAiM; Thu, 12 Sep 2013 00:14:07 -0700 (PDT) Received: from jaja.besserwisser.org (jaja.besserwisser.org [IPv6:2a01:298:4:0:211:43ff:fe36:1299]) by ietfa.amsl.com (Postfix) with ESMTP id B532511E8175; Thu, 12 Sep 2013 00:14:07 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id BE5CE9E99; Thu, 12 Sep 2013 09:14:04 +0200 (CEST) Date: Thu, 12 Sep 2013 09:14:04 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: S Moonesamy Message-ID: <20130912071404.GA21612@besserwisser.org> References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <1623078.iZZXT7WM88@scott-latitude-e6320> <6.2.5.6.2.20130911150339.0c435c60@elandnews.com> <2405077.Cn8DraDvER@scott-latitude-e6320> <6.2.5.6.2.20130911224817.0bdcd030@elandnews.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20130911224817.0bdcd030@elandnews.com> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Pete Resnick , draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 12 Sep 2013 07:14:08 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-1= 9: (with DISCUSS and COMMENT) Date: Wed, Sep 11, 2013 at 10:54:54PM -0700 Q= uoting S Moonesamy (sm+ietf@elandsys.com): > Hi Pete, >=20 > The DISCUSS was as follows: >=20 > >---------------------------------------------------------------------- > >DISCUSS: > >---------------------------------------------------------------------- > > > >Holding my own DISCUSS: > > > >Text needs to be created (probably for section 3.1) to better describe > >the reason this document settled on TXT RR only and therefore why no > >precedent is set for future use of the TXT RR. This text is a much more honest and clear description of the design mishaps and blunderations that led us into the current situation. I do not think we need do more to describe the state than so in this document. Having thus praised the editors for their thorough work, I'd like to state = that: Actions speak louder than words, and since we're all (apparently) reasonably in agreement about the undesirability of another protocol "simply using TXT" something heavier than "shame on us, ok for this time, don't do that again!" is needed. Thus, I am still opposed to deprecating SPF/99.=20 By the way, Carthago should be turned into rubble.=20 --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 The FALAFEL SANDWICH lands on my HEAD and I become a VEGETARIAN ... --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlIxabwACgkQ02/pMZDM1cU7+gCgkAC8M/9DnXKMCUaV+3hhwvZ6 uq0An25yIkNkAmLrZJG4H9zLa+13BITw =dQ21 -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From R.E.Sonneveld@sonnection.nl Thu Sep 12 01:23: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 A6C1921F9F2B for ; Thu, 12 Sep 2013 01:23:23 -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=[BAYES_00=-2.599, 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 uUEOqv-4fDe4 for ; Thu, 12 Sep 2013 01:23:18 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id A9FF521F9FB1 for ; Thu, 12 Sep 2013 01:23:10 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3cbCfN0lhmz1L8fB; Thu, 12 Sep 2013 10:23:08 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3cbCfM6YJ6z1L8f8; Thu, 12 Sep 2013 10:23:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id B6486123135; Thu, 12 Sep 2013 10:23:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2cEzuUpkOzGe; Thu, 12 Sep 2013 10:23:04 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 0F66D123156; Thu, 12 Sep 2013 10:23:04 +0200 (CEST) Message-ID: <523179E7.6090207@sonnection.nl> Date: Thu, 12 Sep 2013 10:23:03 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Scott Kitterman References: <5230A523.20504@isdg.net> <6.2.5.6.2.20130911134838.0c217ca8@resistor.net> <2297109.DlIYn73fZN@scott-latitude-e6320> In-Reply-To: <2297109.DlIYn73fZN@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1378974188; bh=Xhq/qGxr0jspNOu/ZtRIcbo51muphc4eXBZ343E0tPw=; h=Message-ID:Date:From:To:Subject:From; b=EXdKqvfa5UzhKcRXZcGYXvUyS9uM2W56CN3lK7VyVBF8ilyVe4bp4uA2VAibgZO10 D4zjECxuushOUPLhiWMFN/hG6W7lLyx93Z6Pwwlbn2LAVsG5kWySWwqKuWSWqqPVMW AHdFob0vqQdAfn3w3Oxc90KZqisRi/poO30Uf0bA= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3cbCfN0lhmz1L8fB Cc: spfbis@ietf.org Subject: Re: [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 08:23:23 -0000 Hi, Scott, On 09/11/2013 11:53 PM, Scott Kitterman wrote: > On Wednesday, September 11, 2013 13:53:28 S Moonesamy wrote: >> Hi Scott, >> >> I am copying the parts of the SECDIR review to which there hasn't >> been any response: >> >> Issue 1: >>> 1.1.3. MAIL FROM Definition >>> >>> I found this section completely opaque and very confusing. It should >>> not be necessary to hunt through other specs to find a definition. >>> Particularly since the referenced specs do not give an explicit >>> definition for the term as used and the references point to the >>> whole spec rather than a particular section. > It's a challenge, but I think it's better than inventing a new definition for > SPF that may be different. Would someone be willing to dive into the relevant > RFCs and see if they can make a recommendation about how better to reference > this? To avoid confusion it's better not to mention a whole list of possible names/aliases in this Definition paragraph. May I suggest the following text: 1.1.3. MAIL FROM Definition This document is concerned with the identity of the sender of a mail message, as referred to in [RFC5321]: "The transaction starts with a MAIL command that gives the sender identification." . Since there are many other names for this identity, it is important to choose a name that is: 1. commonly used 2. well defined As such, throughout this document the term "MAIL FROM" will be used, which is defined as the RFC5321.MailFrom identity described in [RFC5598]. -- /rolf From sm@elandsys.com Thu Sep 12 01:49: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 A70C421E818E; Thu, 12 Sep 2013 01:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 AOfl6cwTCwZl; Thu, 12 Sep 2013 01:49:16 -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 7C15221E8190; Thu, 12 Sep 2013 01:49:11 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.34]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8C8mm4F009475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 01:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378975741; bh=uIT2NCfbeAtbXcMTZ+X402mhn0E8B7aqxtpS6INwYlo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ehkZxbKoUAM2VshydbXlQZK1egUafHAX4O4Ljcv/dV1w/S66zN5La4bJdPrqmYr90 zpvZe6wIFPX0SEzs29VCG85rBqOeyG8j4O9LAkCWmukvL1qLizn+aW+aRS4dEg7O9T CjEbHRrrWZjFMjI6V8TBd075NIhyh6ikbnPdWe5E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378975741; i=@elandsys.com; bh=uIT2NCfbeAtbXcMTZ+X402mhn0E8B7aqxtpS6INwYlo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=4DqsMQCCszXNNz4kqa5j8Rg26ADX5Zp8n932s2P9otuU3RojsdjEQDIaLrATXmPyM 3OpzRS+BaflyLz29RuuSO8iRobF0elGylIT0V7qOoCBbuIFSNsuwHcFOkDiY0SmC31 TJ1uQINi67VL451Kr1JdcgR923hKU/Bm97o6Jkz0= Message-Id: <6.2.5.6.2.20130911234125.0d7cbbb0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Sep 2013 01:46:01 -0700 To: Douglas Otis From: S Moonesamy In-Reply-To: <6FC7A544-0AB5-4BC0-A0BF-D0D8D740D3B8@gmail.com> References: <6FC7A544-0AB5-4BC0-A0BF-D0D8D740D3B8@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, ietf@ietf.org, Andrew Sullivan Subject: Re: [spfbis] Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard 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, 12 Sep 2013 08:49:16 -0000 Hi Doug, At 21:55 11-09-2013, Douglas Otis wrote: >Recommended text is as follows: Thanks for suggesting text. I'll take this up with the SPFBIS WG after the (IESG) DISCUSSes have been addressed. Here are some quick comments. Section 4.6.4 was reviewed again in response to the DISCUSS from Barry Leiba. I will take the new changes into consideration when making a suggestion to the SPFBIS WG about that part of the draft. I'll also review the text proposed in the message at http://www.ietf.org/mail-archive/web/ietf/current/msg82402.html before making that suggestion. There were also some text clarifications to Section 5 in response to comments from Barry Leiba. I'll see whether the addition of the one sentence which you propose fits in. Some text was proposed to address the "DNS message" issue in Section 3.4 ( http://www.ietf.org/mail-archive/web/spfbis/current/msg04104.html ). I'll use your suggestion and some of the other suggestions to get this issue resolved. It is my understanding that you consider the "macro" issue (Section 11.5.3 in the text which was proposed) as a major one. The argument in your message starts with IPv6 or DNSSEC not being in the purview of draft-ietf-spfbis-4408bis. It is followed by EDNS0 is used with DNSSEC, and there is a discussion about MTU after that. The next paragraph starts with the argument that the SPF macro feature can be used for "attacks". The proposed text then argues that SPF records containing macros are to be ignored to mitigate such an attack. At the moment I do not know what I will suggest. I welcome any new input from anyone who has not commented about the "macro" issue. I suggest using the spfbis@ietf.org mailing list only for any follow-up about the above instead of copying the message to the ietf@ietf.org. Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Thu Sep 12 07:20: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 AEED111E8233; Thu, 12 Sep 2013 07:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 eWXmXI3uJ6CP; Thu, 12 Sep 2013 07:20:44 -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 B351411E8244; Thu, 12 Sep 2013 07:20:30 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.139.127]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8CEKEEk026591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 07:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378995628; bh=wCdvk6nVO1Ka9hJysa7hv5K+bvP1OhfZwg8D6bFcDSs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tnz5fpku/Vpqd59g7uwmSbZ/AkOSjlySIMSfeBcAWOmILYrhE5IIlJepR+/2eZhrn f04D0vikjhyAVFuHOJtr19nTp/XXs6ijPTuzDwjlAmosAdypmUpmwOSx035c+MJAvS xZcnKLTuSgncGDrEdG2gsKk75pKj8C3ETa42cx74= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378995628; i=@elandsys.com; bh=wCdvk6nVO1Ka9hJysa7hv5K+bvP1OhfZwg8D6bFcDSs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=X4KXQik6EqOk7Uvkq3nz4SluPkeRmkiNRrtEAKYgDh2PZxL2UPCII5qZCDhHSjDik cdkjLzwceagjJFG9xl67k1NdHgyJpEnntoszO1pPLc0mbD5OqgBpEPMUiZOW+aW1T9 xnHb3oGD2G5FAjg87QcA54BuEDyY8dTQTAQpxnIU= Message-Id: <6.2.5.6.2.20130912065558.0b960550@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Sep 2013 07:18:08 -0700 To: "Benoit Claise" , The IESG From: S Moonesamy In-Reply-To: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> References: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org Subject: Re: [spfbis] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 12 Sep 2013 14:20:50 -0000 Hi Benoit, At 03:47 12-09-2013, Benoit Claise wrote: >Benoit Claise has entered the following ballot position for >draft-ietf-spfbis-4408bis-19: No Objection [snip] ---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >disclaimer: I've only reviewed the changes compared to the RFC 4088. > >Regarding "Appendix J. Change History": > NOTE TO RFC EDITOR: Changes since RFC 4408 (to be removed prior to > publication) > >Personally, I like it when the new RFC has one section summarizing the >changes compared to the initial RFC. >This would be a mix of: > Appendix J. Change History", but no needs to mention the editorial >changes > Appendix C. Changes in implementation requirements from RFC 4408 Appendix C contains the changes between the draft and RFC 4408. The question of changes was mentioned by Eliot Lear in his AppsDir review (see http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10278.html ). My suggestion to the SPFBIS WG is to leave this as it is. Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Thu Sep 12 07:30:40 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 7CA6921E80B7; Thu, 12 Sep 2013 07:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 yCtZMCeAbhUj; Thu, 12 Sep 2013 07:30:39 -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 ADCBA11E812F; Thu, 12 Sep 2013 07:30:39 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.139.127]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8CEUFIT001105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 07:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378996230; bh=JayyQ7Z4Z1VSFLKNvL+tviw2bjQimMu5Bsm35EHJ0gA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TwPzvzL0zLx1YDqQGUWNh+KTduBs+bLk8gENuDU9nCNWOZXBErwznvjy7G6tDXe+k 8ePtFTvKJDe7evRpEK2w6iwRyr/6biYnJsP1h4TfWt6FJGgPbnpof5ECUAQn/CHJ7o LzNAsxY/cBy08RqyJjhbOaG9YIhYC4z4YsFyDVvk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378996230; i=@elandsys.com; bh=JayyQ7Z4Z1VSFLKNvL+tviw2bjQimMu5Bsm35EHJ0gA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uU4Ljx84uoMKVgyMQmPXhClW4tStqvJMXkln849zUAMY6c1OKPJ6eW2ZbJ3Jd+C6x XeZj9PhroD1A9Qc0JkxJdOL8EXeImG7TRmn8hr31OiX1+LLoHZjUsHlw/EHe48U8GZ +Bo1BWEDpscgOGmGPkQHDIqnzOWtBdGPqKWjTUTk= Message-Id: <6.2.5.6.2.20130912072207.0b998388@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Sep 2013 07:26:53 -0700 To: Sean Turner , The IESG From: S Moonesamy In-Reply-To: <20130912114310.25787.59356.idtracker@ietfa.amsl.com> References: <20130912114310.25787.59356.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org Subject: Re: [spfbis] Sean Turner's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 12 Sep 2013 14:30:40 -0000 Hi Sean, At 04:43 12-09-2013, Sean Turner wrote: >Sean Turner has entered the following ballot position for >draft-ietf-spfbis-4408bis-19: No Objection [snip] >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Should s11.3 also provide a mitigation via a reference for the spoofed >DNS? Right now it just points to the DNS threats RFC. I guess the >reader can infer they should use DNSSEC if they're worried but adding a >pointer to the right RFC would be better. Something as simple as adding >"... and see [RFCXYZ] for a countermeasure" or something like that. I'll suggest: and see RFC 4033 for a countermeasure. and leave it to the SPFBIS WG to comment on the above. Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Thu Sep 12 07:31: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 CC96B21E80FA; Thu, 12 Sep 2013 07:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 0F8k+f-GQ6LA; Thu, 12 Sep 2013 07:31:58 -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 07C8421E80DD; Thu, 12 Sep 2013 07:31:58 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.139.127]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8CEUFIV001105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 07:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378996236; bh=pF+bjubs2MhqqV8uN+XoT8xBs6zFrguEK6kaFqL7tm8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fG4lJvuFe+EhSeyGh7DPK6kyQJ6jcG8soT/YRHnbtKRTZJoISqSvhtLsblTCJvIes ffft7UWtlrouPXh1yi+qAKS7KjbFWZDUtu+TvflUmSfe7Wbs8IRDh/ovdVXwQWjILi rBp1Le3rspu+sGIJmvPh8ql9+7uAxWikexgSh2BM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378996236; i=@elandsys.com; bh=pF+bjubs2MhqqV8uN+XoT8xBs6zFrguEK6kaFqL7tm8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=W04iCT/WDHinhbd8l7vv5LqgiQWM8LmsUYYSiKGWHehwDA4VDcsqFA29g8vxFi8Ry 5QI4SQy9aPuQo5RuLlVJJbjZVnw4oRcS0cKbr7Krrj6ECBeubB7pqguwmXyHiq7zGc u4+MzwiT0LXfOwo+snEYWwyT1ptFZALeG4F5InJY= Message-Id: <6.2.5.6.2.20130912072800.0b998240@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Sep 2013 07:29:37 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20130912101511.20829.6656.idtracker@ietfa.amsl.com> References: <20130912101511.20829.6656.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis-chairs@tools.ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG , Stephen Farrell Subject: Re: [spfbis] Stephen Farrell's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 12 Sep 2013 14:31:58 -0000 Hello, Could the SPFBIS WG please address the following comment? Thanks, S. Moonesamy (as document shepherd) At 03:15 12-09-2013, Stephen Farrell wrote: >Stephen Farrell has entered the following ballot position for >draft-ietf-spfbis-4408bis-19: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > >- 4.1: given that recursion is allowed and that you have >overall limits on how many DNS transactions can be done, >is the "transactions-remaining" value also an implicit >parameter of a check_host() call? This is only a comment >since check_host is not a formal API but it'd seem to make >it easier to get right if you make that implicit parameter >explicit. Or do the limits apply to each call as you >recurse? That wasn't entirely clear to me. > >- I didn't get appendix D at all - what's that do? > >- Appendix E.1, 2nd bullet: what's that? I think it needs >a reference if you want it to be understood. From turners@ieca.com Thu Sep 12 07:40: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 2756D21E8105 for ; Thu, 12 Sep 2013 07:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 Fw6WoNF73lgU for ; Thu, 12 Sep 2013 07:40:31 -0700 (PDT) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [64.5.38.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3465211E821E for ; Thu, 12 Sep 2013 07:40:31 -0700 (PDT) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 0DA143DC2826E; Thu, 12 Sep 2013 09:39:31 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id D2AC93DC2821F for ; Thu, 12 Sep 2013 09:39:30 -0500 (CDT) Received: from [96.231.225.44] (port=61237 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VK84K-0000JV-UE; Thu, 12 Sep 2013 09:40:29 -0500 Message-ID: <5231D25B.6040004@ieca.com> Date: Thu, 12 Sep 2013 10:40:27 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: S Moonesamy References: <20130912114310.25787.59356.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130912072207.0b998388@elandnews.com> In-Reply-To: <6.2.5.6.2.20130912072207.0b998388@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:61237 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG Subject: Re: [spfbis] Sean Turner's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 12 Sep 2013 14:40:38 -0000 On 9/12/13 10:26 AM, S Moonesamy wrote: > Hi Sean, > At 04:43 12-09-2013, Sean Turner wrote: >> Sean Turner has entered the following ballot position for >> draft-ietf-spfbis-4408bis-19: No Objection > > [snip] > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Should s11.3 also provide a mitigation via a reference for the spoofed >> DNS? Right now it just points to the DNS threats RFC. I guess the >> reader can infer they should use DNSSEC if they're worried but adding a >> pointer to the right RFC would be better. Something as simple as adding >> "... and see [RFCXYZ] for a countermeasure" or something like that. > > I'll suggest: > > and see RFC 4033 for a countermeasure. > > and leave it to the SPFBIS WG to comment on the above. That would work for me. spt From bclaise@cisco.com Thu Sep 12 07:56: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 50D2711E8251; Thu, 12 Sep 2013 07:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 jZwNtbHXNMQ5; Thu, 12 Sep 2013 07:56:53 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADC811E8236; Thu, 12 Sep 2013 07:56:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r8CEuV94008039; Thu, 12 Sep 2013 16:56:31 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r8CEtZOH029145; Thu, 12 Sep 2013 16:55:51 +0200 (CEST) Message-ID: <5231D5E5.5070407@cisco.com> Date: Thu, 12 Sep 2013 16:55:33 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: S Moonesamy References: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130912065558.0b960550@elandnews.com> In-Reply-To: <6.2.5.6.2.20130912065558.0b960550@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG Subject: Re: [spfbis] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 12 Sep 2013 14:56:59 -0000 X-List-Received-Date: Thu, 12 Sep 2013 14:56:59 -0000 >> >> disclaimer: I've only reviewed the changes compared to the RFC 4088. >> >> Regarding "Appendix J. Change History": >> NOTE TO RFC EDITOR: Changes since RFC 4408 (to be removed prior to >> publication) >> >> Personally, I like it when the new RFC has one section summarizing the >> changes compared to the initial RFC. >> This would be a mix of: >> Appendix J. Change History", but no needs to mention the editorial >> changes >> Appendix C. Changes in implementation requirements from RFC 4408 > > Appendix C contains the changes between the draft and RFC 4408. Well, maybe "Changes in implementation requirements from RFC 4408" So my first question is: what are the changes that are not related to the implementation requirements? As a good example, http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis-04#appendix-B is useful. Anyway, I made my point, up to AD/document shepherd to decide. Regards, Benoit > The question of changes was mentioned by Eliot Lear in his AppsDir > review (see > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10278.html ). > My suggestion to the SPFBIS WG is to leave this as it is. > > Regards, > S. Moonesamy (as document shepherd) > From presnick@qti.qualcomm.com Thu Sep 12 08:03: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 5266C11E8238; Thu, 12 Sep 2013 08:02:58 -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 27YjGtjeK2US; Thu, 12 Sep 2013 08:02:46 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 917BE11E820D; Thu, 12 Sep 2013 08:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1378998137; x=1410534137; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=U9TBlUg7DJMxJ0KpMIrBv/GTOEwjCGu8eXycDPHSFgU=; b=mM0pRS0KU9A5Ubf1DGtOGeopvRft+PH1wbGeojFCsBNRKqJVnxMzB0rw 5ugYcPNe/u8tROpqdRt5KuZ3Dbo/Jr9trATHvV5Cv+ffXp385bQHGdE+N Uv9KwKFBDSyINS/Rkt3JMz09J0r0wYdrUdO97xu5d6zrjnLYRwRVK7QY1 U=; X-IronPort-AV: E=McAfee;i="5400,1158,7195"; a="51423751" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 12 Sep 2013 08:02:05 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7195"; a="19296631" Received: from nasanexhc03.na.qualcomm.com ([172.30.48.26]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Sep 2013 08:02:05 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC03.na.qualcomm.com (172.30.48.26) with Microsoft SMTP Server (TLS) id 14.3.146.2; Thu, 12 Sep 2013 08:02:05 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.146.2; Thu, 12 Sep 2013 08:02:05 -0700 Message-ID: <5231D76B.6040507@qti.qualcomm.com> Date: Thu, 12 Sep 2013 10:02:03 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: S Moonesamy References: <20130907135512.24084.48602.idtracker@ietfa.amsl.com> <1623078.iZZXT7WM88@scott-latitude-e6320> <6.2.5.6.2.20130911150339.0c435c60@elandnews.com> <2405077.Cn8DraDvER@scott-latitude-e6320> <6.2.5.6.2.20130911224817.0bdcd030@elandnews.com> In-Reply-To: <6.2.5.6.2.20130911224817.0bdcd030@elandnews.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG Subject: Re: [spfbis] Pete Resnick's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 12 Sep 2013 15:03:13 -0000 Looks good to me. I'll clear my DISCUSS during or just after the call. pr On 9/12/13 12:54 AM, S Moonesamy wrote: > Hi Pete, > > The DISCUSS was as follows: > >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Holding my own DISCUSS: >> >> Text needs to be created (probably for section 3.1) to better describe >> the reason this document settled on TXT RR only and therefore why no >> precedent is set for future use of the TXT RR. > > Here is the revised section 3.1: > > 3.1. DNS Resource Records > > SPF records MUST be published as a DNS TXT (type 16) Resource Record > (RR) [RFC1035] only. The character content of the record is encoded > as [US-ASCII]. Use of alternative DNS RR types was supported in > SPF's experimental phase, but has been discontinued. > > In 2003, when SPF was first being developed, the requirements for > assignment of a new DNS RR type were considerably more stringent than > they are now. Additionally, support for easy deployment of new DNS > RR types was not widely deployed in DNS servers and provisioning > systems. As a result, developers of SPF found it easier and more > practical to use the TXT RR type for SPF records. > > In its review of [RFC4408] the SPFbis working group concluded that > its dual RR type transition model was fundamentally flawed since it > contained no common RR type that implementers were required to serve > and required to check. Many alternatives were considered to resolve > this issue, but ultimately the working group concluded that > significant migration to the SPF RR type in the foreseeable future > was > very unlikely and that the best solution for resolving this > interoperability issue was to drop support for the SPF RR type from > SPF version 1. See Appendix A of [RFC6686] for further information. > > The circumstances surrounding SPF's initial deployment a decade ago > are unique. If a future update to SPF were developed that did not > reuse existing SPF records, it could use the SPF RR type. SPF's use > of the TXT RR type for structured data should in no way be taken as > precedent for future protocol designers. Further discussion of > design considerations when using new DNS RR types can be found in > [RFC5507]. > > Regards, > S. Moonesamy (as document shepherd) -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From johnl@iecc.com Thu Sep 12 08:03: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 DFA9421F84B1 for ; Thu, 12 Sep 2013 08:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.078, 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 MvY+EVae5U3F for ; Thu, 12 Sep 2013 08:03:43 -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 1764521E809F for ; Thu, 12 Sep 2013 08:02:51 -0700 (PDT) Received: (qmail 80177 invoked from network); 12 Sep 2013 15:02:49 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Sep 2013 15:02:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5231d799.xn--i8sz2z.k1309; i=johnl@user.iecc.com; bh=q+2IUzDt3vGZECd88lnEaGroes3I9mImeZu5pflId/E=; b=Gfq2BVc1vnY1gsQKpLxLSG9hEdD4U0Ns3u0zV17Xye1QggNNMxp4SHb1ygV97BQba4TapalANb8nfxoH5qH5/Egk+g5mM8tYbYT6NI6F0J252QsiZw3lIylxO4Zo+Jp/6EXy5Y1snVL2UMWbOPVAcW1m8APNGDr96VqbqZ8U/G+u5iEmhyhcvuuMbv/8PneXQ+znrFN0DLI3EFjRoVgqzKuyK1wVYi98RvGjo0EKZV1axDRNRVwBOizhK3PhXvCx DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5231d799.xn--i8sz2z.k1309; olt=johnl@user.iecc.com; bh=q+2IUzDt3vGZECd88lnEaGroes3I9mImeZu5pflId/E=; b=A+wti5jDevBH8lJdvjenxH59OoLTmm28Ncy8hsqODjXw2mVmxRhzczA1ue+OlCJ/zY121tCSdkxvVFycmVOubJdP/uYouf4KmOwuGsdfFD+/x5ihf8wYVeK7z/oVCeC9WTuc+2V+tqNzm53ppKygBNBUWOhKZNcmnuIBwoPbo+fQ6P/GY1OoGiU1vFJt4Aig/GnVJA261zW+FtEQATQ3bft67nUD1/cw0iqS0gOq8fD8Sk9EJwnh5NPrOpbQ6z1Z Date: 12 Sep 2013 15:02:27 -0000 Message-ID: <20130912150227.57069.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <5231D25B.6040004@ieca.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [spfbis] Sean Turner's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 12 Sep 2013 15:03:52 -0000 I don't see anything about SPF that makes DNS spoofing more of a problem than any other DNS application, so I don't see why it needs another plug for DNSSEC. On the other hand, it's not a big deal, if it'll make the discuss go away, that's fine. >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Should s11.3 also provide a mitigation via a reference for the spoofed >>> DNS? Right now it just points to the DNS threats RFC. I guess the >>> reader can infer they should use DNSSEC if they're worried but adding a >>> pointer to the right RFC would be better. Something as simple as adding >>> "... and see [RFCXYZ] for a countermeasure" or something like that. >> >> I'll suggest: >> >> and see RFC 4033 for a countermeasure. >> >> and leave it to the SPFBIS WG to comment on the above. > >That would work for me. From sm@elandsys.com Thu Sep 12 08:10: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 7AA6D11E816D; Thu, 12 Sep 2013 08:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 NIaA7Y52vCN1; Thu, 12 Sep 2013 08:10:32 -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 D4A3D11E822D; Thu, 12 Sep 2013 08:10:28 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.139.127]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8CFACr1023577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 08:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1378998626; bh=m+mcOiQ+w7oQOIKz78T7ULM28WmqnIBVpMhJxSMy82w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3ZlG44OfGaYyI8y1VFjMl46KxLPvOkCrHNT+qYH3m/V7nELtb0rJxJctIaeDwpILB 8eadnNv/MR7lc6x5WKRQwLiPIsAbl9NnLqG8YELhSIc1Sk0CXHFXERgz0AO5sb7pEh n5J4f46ZA0IZsXP/fnZHgxf6rt6X8kmyA5sJXxe8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1378998626; i=@elandsys.com; bh=m+mcOiQ+w7oQOIKz78T7ULM28WmqnIBVpMhJxSMy82w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Fb4nEh/e3cm/6rbX4bBEcPnd0mxOwkisl1D/p3QtcqjMS6afgAyJuJj4T4iDqxC1Q Z2yRWUDz55Td1bbA1sofD8ig4Pggs9nxj0Dmd1V3eV9Ml6QoDyJf7X9yUiZnmgkA8E 1OYvM5cEwQPyPOGGUCUL3QlS11ddRGvumbaqphAw= Message-Id: <6.2.5.6.2.20130912080503.0c90f9d0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Sep 2013 08:09:21 -0700 To: Benoit Claise From: S Moonesamy In-Reply-To: <5231D5E5.5070407@cisco.com> References: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130912065558.0b960550@elandnews.com> <5231D5E5.5070407@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG Subject: Re: [spfbis] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 12 Sep 2013 15:10:34 -0000 Hi Benoit, At 07:55 12-09-2013, Benoit Claise wrote: >Well, maybe "Changes in implementation requirements from RFC 4408" >So my first question is: what are the changes that are not related >to the implementation requirements? >As a good example, >http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis-04#appendix-B is useful. That is a good question (re. implementation requirements). I suggest following the example you provided if Pete Resnick is okay with that. Regards, S. Moonesamy (as document shepherd) From R.E.Sonneveld@sonnection.nl Thu Sep 12 08:36: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 0DFEE11E8274; Thu, 12 Sep 2013 08:36:37 -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=-0.001, 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 UtLJnOC35SAM; Thu, 12 Sep 2013 08:36:19 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id D222311E81BC; Thu, 12 Sep 2013 08:35:52 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3cbPFS5flHz1L8fM; Thu, 12 Sep 2013 17:35:40 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3cbPFS4ZCxz1L8fB; Thu, 12 Sep 2013 17:35:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 647781231E3; Thu, 12 Sep 2013 17:35:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 12WgKmWnrtbm; Thu, 12 Sep 2013 17:35:33 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id A8B3F1231DE; Thu, 12 Sep 2013 17:35:33 +0200 (CEST) Message-ID: <5231DF45.6070507@sonnection.nl> Date: Thu, 12 Sep 2013 17:35:33 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <522B2AC4.4090006@qti.qualcomm.com> <2C6B0D9B-7E1E-4CC3-AA41-935D65E79A3F@frobbit.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020203080500090801030802" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1379000140; bh=Ha917cQ67fh0zH0E/WSqu4Sn/FwIwLnT3l5sXTdXsY8=; h=Message-ID:Date:From:To:Subject:From; b=ERM1QIKZAs91n9qDyl0Xao8dTjFJiuNymGZFtxVNlu9sXKQ8RJxmklKn6BNBCR6ak WGIkl3scnifVag6hzfSKWP2xjx6+i+t8gIyaiHsrlRokRJ5YvjiQmSE8DKAVMV9UuH 1V22NAXSBU/XF0qwCzn0bwequtm2qPMuNmuNqwJQ= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3cbPFS5flHz1L8fM Cc: "spfbis@ietf.org" , Pete Resnick , IETF-Discussion list , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: [spfbis] Conclusions of Last Call for draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 15:36:38 -0000 This is a multi-part message in MIME format. --------------020203080500090801030802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 09/10/2013 01:39 PM, Murray S. Kucherawy wrote: > Hi Patrik, > > On Tue, Sep 10, 2013 at 4:04 AM, Patrik F=E4ltstr=F6m > wrote: > > What we did look at was first of all every query for an MX > resource record. Then we look at +/-1 second from the timestamp of > that MX query for TXT and/or SPF record for the same owner. We > draw the conclusion that if there is a query for an MX record, and > then either TXT or SPF (or both) within the approximately same > timespan, then they are related queries. > > > I'm not sure that's a valid conclusion. Since MX is needed only for a=20 > sending system, a receiving system doing an SPF check of either type=20 > has no reason to query for MX. The exception to this might be a=20 > heuristic check to see if the domain in the MAIL FROM has MX or A=20 > published such that a reply appears to be possible, but I wouldn't=20 > expect a strong correlation in your data. Well, if the TXT/SPF query precedes the MX query (so the case '-1=20 second' of the '+/-1 second' described by Patrik) it might indicate an=20 SPF record which includes an mx mechanism. In that case the queries are=20 related. /rolf --------------020203080500090801030802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/10/2013 01:39 PM, Murray S. Kucherawy wrote:
Hi Patrik,

On Tue, Sep 10, 2013 at 4:04 AM, Patrik Fältström <paf@frobbit.se> wrote:
What we did look at was first of all every query for an MX resource record. Then we look at +/-1 second from the timestamp of that MX query for TXT and/or SPF record for the same owner. We draw the conclusion that if there is a query for an MX record, and then either TXT or SPF (or both) within the approximately same timespan, then they are related queries.


I'm not sure that's a valid conclusion.  Since MX is needed only for a sending system, a receiving system doing an SPF check of either type has no reason to query for MX.  The exception to this might be a heuristic check to see if the domain in the MAIL FROM has MX or A published such that a reply appears to be possible, but I wouldn't expect a strong correlation in your data.

Well, if the TXT/SPF query precedes the MX query (so the case '-1 second' of the '+/-1 second' described by Patrik) it might indicate an SPF record which includes an mx mechanism. In that case the queries are related.

/rolf

--------------020203080500090801030802-- From sm@elandsys.com Thu Sep 12 10:00: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 5DE8C21E8107 for ; Thu, 12 Sep 2013 10:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 ot22cIHZIUcz for ; Thu, 12 Sep 2013 10:00:45 -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 8ACFC21E80FC for ; Thu, 12 Sep 2013 10:00:45 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.139.127]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8CH0WdB018292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 10:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379005243; bh=Z7jqBJm43rxk6FwrHEcXUENqghdgXgz+3A7POWqBCgs=; h=Date:To:From:Subject:Cc; b=iQh+CHDN0pNq+gu/XLcuz8kIOePLwp/u6xQrN9rkq203qpfv2L9EfnapHw/jhE8Ye Gk2LbYaRdjIyj143jRFVxHLOlVKfz+vjAm04MINmGtiAlfJ01dPNthn2Rx9sPwbkIv rCxCNij1cVCcBBQZYk03BimWsqjTHjSCn5Qlom9g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379005243; i=@elandsys.com; bh=Z7jqBJm43rxk6FwrHEcXUENqghdgXgz+3A7POWqBCgs=; h=Date:To:From:Subject:Cc; b=JtOqVVtb9X805PaZnjTHYGN7w82SsnttQi5+cU53gI89SGRG8kMZjH3DKgOxA8L7F wa5qCqxrSFePas2zakzLTOzhA9QJQEPDfoOzq4ntMcKHlYhb+iK/ei46zfk9fqb3Qy ZKfp2Di+wg7MOFOS5phNCUlz1UW9MYp+S9OwXVUk= Message-Id: <6.2.5.6.2.20130912094525.0ca26c60@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Sep 2013 10:00:08 -0700 To: Scott Kitterman From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: [spfbis] Revised I-D of draft-ietf-spfbis-4408bis 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, 12 Sep 2013 17:00:46 -0000 Hi Scott, Could you please post a revised I-D for draft-ietf-spfbis-4408bis? Pete Resnick, as Area Director, is okay with the text at http://www.ietf.org/mail-archive/web/spfbis/current/msg04161.html There's also the text from Barry Leiba's messages as Area Director (see http://www.ietf.org/mail-archive/web/spfbis/current/msg04150.html and the other messages on that thread). I'll go over the comments from the other Area Directors and we can work from -20. There will be editorial changes to address those comments and the feedback from participants. As a general note to the SPFBIS WG the document will be on the IESG telechat on September 26. It would be good if all the changes can be settled by September 19 so that the IESG has ample time for its review. Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Thu Sep 12 10:42: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 D18AE21E8181 for ; Thu, 12 Sep 2013 10:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 xsoRn73ZXH4m for ; Thu, 12 Sep 2013 10:42: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 3E79021E8151 for ; Thu, 12 Sep 2013 10:42:20 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.139.127]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8CHfqE1020525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 10:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379007728; bh=G538huDu51WuNZFM4irSzWXY89xWPTTahg2ku2wHW14=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1t2t17BriNW45UceKXG40SQ8N4E35AvcE1NZ+EWk/gMaOtRYtY58/T+cKgnQgFiVK xzt/bhagkVpNf5Xut5ebDSj9KGvDrEipOc7JJ64sFNX2bS6cq4ueaoCCE6ycnjcAqO fbDtSxzC5/1yqWxbX9frGN000OmT6HncT9cid1ic= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379007728; i=@elandsys.com; bh=G538huDu51WuNZFM4irSzWXY89xWPTTahg2ku2wHW14=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LeHmbGYFYhd/2ug5HbBj7f9bx76s/txgVvvQYBe+CjgZIqHX2WJHP1rHUc+coCgS3 yQWP8wIR3wODZWpqaFj5qGF4Ka99VVszZMF/nlxyFZ87rdqpBW8MoNG2X/Ub1UroP2 jWGRzHTUCoDmcLYj1GTFpt2gEzI8hIzxpae+ljGE= Message-Id: <6.2.5.6.2.20130912102324.0cb97a38@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Sep 2013 10:41:34 -0700 To: R.E.Sonneveld@sonnection.nl, "Murray S. Kucherawy" , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , =?iso-8859-1?Q?M=C3ns?= Nilsson , Scott Kitterman From: S Moonesamy In-Reply-To: <5231DF45.6070507@sonnection.nl> References: <522B2AC4.4090006@qti.qualcomm.com> <2C6B0D9B-7E1E-4CC3-AA41-935D65E79A3F@frobbit.se> <5231DF45.6070507@sonnection.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Pete Resnick Subject: Re: [spfbis] Conclusions of Last Call for draft-ietf-spfbis-4408bis 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, 12 Sep 2013 17:42:22 -0000 Hello, I read the message from M=C3ns Nilsson and the=20 messages from Patrik F=E4ltstr=F6m. I also received=20 an email with Scott Kitterman. Pete, Andrew,=20 please do correct me if I got this wrong: The second paragraph in Section 13.1 is about a=20 request for a IANA action. The paragraph can be=20 dropped as that action is not being taken. There will be an informative reference to RFC=20 5507 (see text for Pete's DISCUSS). This should hopefully conclude the discussion to everybody's satisfaction. Regards, S. Moonesamy (as document shepherd)=20 From spf2@kitterman.com Thu Sep 12 10:53: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 F357121F9D33 for ; Thu, 12 Sep 2013 10:53:32 -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 HnYb6m8z7lCh for ; Thu, 12 Sep 2013 10:53:32 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5547721F9D3A for ; Thu, 12 Sep 2013 10:53:27 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 61229D04089; Thu, 12 Sep 2013 13:53:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1379008406; bh=jDgd/AoeQQnopeoBcqt9/jlSbDXzpRJGR1GOVMYgwjY=; h=In-Reply-To:References:Subject:From:Date:To:CC:From; b=NOIe1sxfU8VICL5axuL089BfL033rLRq1mTpgMB/VzumyE6+OWyPao+UNsfpxWRs9 F+HRZGR/9s8E98vEwWGsg+4QoyUgMdhnRLojnyzT9c3ZWRDHztdOmtuXg11JvBjWU8 96P5MBuyOj9PonitL6jSLwHLCYleDy4gPE/sVW24= Received: from [IPV6:2600:1003:b015:b58:c632:b2ef:1dd7:f959] (unknown [IPv6:2600:1003:b015:b58:c632:b2ef:1dd7:f959]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DD498D04053; Thu, 12 Sep 2013 13:53:25 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20130912094525.0ca26c60@elandnews.com> References: <6.2.5.6.2.20130912094525.0ca26c60@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 12 Sep 2013 13:53:49 -0400 To: S Moonesamy Message-ID: X-AV-Checked: ClamAV using ClamSMTP Cc: spfbis@ietf.org Subject: Re: [spfbis] Revised I-D of draft-ietf-spfbis-4408bis 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, 12 Sep 2013 17:53:33 -0000 S Moonesamy wrote: >Hi Scott, > >Could you please post a revised I-D for draft-ietf-spfbis-4408bis? > I can, probably in about 10 hours. I'll be able to give more detailed email replies then too. Scott K From sklist@kitterman.com Thu Sep 12 11:01: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 9424011E80EC; Thu, 12 Sep 2013 11:01:06 -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 D-YBIOqbdwVI; Thu, 12 Sep 2013 11:01:01 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id B30FD21F9FCF; Thu, 12 Sep 2013 11:00:38 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 7C749D04089; Thu, 12 Sep 2013 14:00:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1379008830; bh=pR+G4HyKkcQ3CPiAIwe16KbNjqxcy94HxAGIRrOwPpg=; h=In-Reply-To:References:Subject:From:Date:To:CC:From; b=kNiuTboEqpM+QmGv/Wg/nnAUfNJdALUN/CIQ7Zw0SOXDoXm5wkNB1WA5BXr63l8M8 8w1bDvBrBi2n3gQ/TXtv4Pz5dtnXMQkeWNJhLKVi54pm+SFjVOn8xBAXgxEu2bw8Hb uEG5PfXA+hl+uV7wEa2/syjLk7w/vbUT8894mGEI= Received: from [IPV6:2600:1003:b015:b58:c632:b2ef:1dd7:f959] (unknown [IPv6:2600:1003:b015:b58:c632:b2ef:1dd7:f959]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id C3825D04053; Thu, 12 Sep 2013 14:00:29 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <5231D5E5.5070407@cisco.com> References: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130912065558.0b960550@elandnews.com> <5231D5E5.5070407@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 12 Sep 2013 14:00:41 -0400 To: Benoit Claise ,S Moonesamy Message-ID: X-AV-Checked: ClamAV using ClamSMTP X-Mailman-Approved-At: Thu, 12 Sep 2013 11:09:41 -0700 Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG Subject: Re: [spfbis] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 12 Sep 2013 18:01:07 -0000 There are any number of changes we made that don't affect implementation requirements. An example that comes immediately to mind is that the draft says do not use the "ptr" mechanism. That doesn't change implementation requirements because it's still part of the protocol for backward compatibility. Scott K Benoit Claise wrote: > >>> >>> disclaimer: I've only reviewed the changes compared to the RFC 4088. >>> >>> Regarding "Appendix J. Change History": >>> NOTE TO RFC EDITOR: Changes since RFC 4408 (to be removed prior >to >>> publication) >>> >>> Personally, I like it when the new RFC has one section summarizing >the >>> changes compared to the initial RFC. >>> This would be a mix of: >>> Appendix J. Change History", but no needs to mention the >editorial >>> changes >>> Appendix C. Changes in implementation requirements from RFC 4408 >> >> Appendix C contains the changes between the draft and RFC 4408. >Well, maybe "Changes in implementation requirements from RFC 4408" >So my first question is: what are the changes that are not related to >the implementation requirements? >As a good example, >http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis-04#appendix-B is > >useful. > >Anyway, I made my point, up to AD/document shepherd to decide. > >Regards, Benoit >> The question of changes was mentioned by Eliot Lear in his AppsDir >> review (see >> >http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10278.html >). >> My suggestion to the SPFBIS WG is to leave this as it is. >> >> Regards, >> S. Moonesamy (as document shepherd) >> > >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From presnick@qti.qualcomm.com Thu Sep 12 12:56:40 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 D74D111E81E3 for ; Thu, 12 Sep 2013 12:56:40 -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 sTOlXferORLR for ; Thu, 12 Sep 2013 12:56:36 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id A95FB11E81A3 for ; Thu, 12 Sep 2013 12:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1379015796; x=1410551796; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KVCY7Rs7UMrYkl4/kolCEctCicBjDwPkqhiXskksjyo=; b=ssHgXDo6djDZtENglx30rYzZM4Z9GnNQE4Dp8YkWmKfBTQ7ikID5RRkf aa/R4FX6thT30j3tSNjcgiq1nWueShDsNKYRA4GFf3Op2MaFEZovVhrbx wPhwuHGnCN+yn3V7uT5fwoPBxlmpB9YvddgzGWVBTwT9Liv1iG2yRXI6s g=; X-IronPort-AV: E=McAfee;i="5400,1158,7196"; a="51335274" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth01.qualcomm.com with ESMTP; 12 Sep 2013 12:56:35 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7196"; a="19349833" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Sep 2013 12:56:34 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.146.2; Thu, 12 Sep 2013 12:56:34 -0700 Message-ID: <52321C70.7060307@qti.qualcomm.com> Date: Thu, 12 Sep 2013 14:56:32 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20130912094525.0ca26c60@elandnews.com> In-Reply-To: <6.2.5.6.2.20130912094525.0ca26c60@elandnews.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] Revised I-D of draft-ietf-spfbis-4408bis 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, 12 Sep 2013 19:56:41 -0000 On 9/12/13 12:00 PM, S Moonesamy wrote: > As a general note to the SPFBIS WG the document will be on the IESG > telechat on September 26. It would be good if all the changes can be > settled by September 19 so that the IESG has ample time for its review. A little note on this, especially if you happen to follow the sausage-making that is the IESG process: The IESG was satisfied that all of the assorted Last Call comments and IESG comments were being addressed (as well as can be expected) in the upcoming new version of the draft. Normally, the IESG conditionally approves documents in that state, leaving it to the sponsoring AD to double-check before final approval. But there were a *lot* of comments and controversy regarding this document. So I offered to put the document back as a returning item on the next IESG agenda so that the IESG could confirm that all of the changes were in. I expect there to be no blocking ballots after -20 comes out, and then it's just a matter of SM and I confirming all of the changes for the IESG to sign off on. An out-of-the-ordinary step, but not unprecedented and nothing to be concerned about. The IESG discussion of the document went very well. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From spf2@kitterman.com Thu Sep 12 18:28:48 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 78F9411E813F for ; Thu, 12 Sep 2013 18:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.341, 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 Ht3iaZX2skZE for ; Thu, 12 Sep 2013 18:28:35 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C3E4A21F9D0C for ; Thu, 12 Sep 2013 18:28:35 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A0CF820E40F0; Thu, 12 Sep 2013 21:28:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1379035714; bh=gVeK8Jo5R+W5FtjYVTi16HnIwQAYJnQf7rj4ygNQUY8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ihxj15B6YBXyAv7u9MSDg1v/nyRqG+MN+kl8rMeyESMLF/j2ujxXIO5rZsTxYzupO jYO2jnwpMmK+/GOy/TzxdUYxxOfnf8GmAQ+8XrUjPEdrhUgXUiCuOluAmByNEb88QU khm5c5OwZ/ug7sNREISdPgZhP4cD2cYQ2Tw1wam8= 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 83BFB20E4076; Thu, 12 Sep 2013 21:28:34 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 12 Sep 2013 21:28:31 -0400 Message-ID: <7883048.PMslXZEC8x@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130912094525.0ca26c60@elandnews.com> References: <6.2.5.6.2.20130912094525.0ca26c60@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] Revised I-D of draft-ietf-spfbis-4408bis 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, 13 Sep 2013 01:28:48 -0000 On Thursday, September 12, 2013 10:00:08 S Moonesamy wrote: > Hi Scott, > > Could you please post a revised I-D for draft-ietf-spfbis-4408bis? In retrospect, it wasn't 100% clear if I'm supposed to post -20 as the last interim diff I sent to the list or work on other outstanding comments first. In the interest of being conservative, I'm posting -20 just as I last sent it to the list. Scott K From internet-drafts@ietf.org Thu Sep 12 18:30: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 1771011E819F; Thu, 12 Sep 2013 18:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, 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 FlzIOQXUmhcU; Thu, 12 Sep 2013 18:30:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E27411E825E; Thu, 12 Sep 2013 18:30:18 -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.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130913013018.21907.73813.idtracker@ietfa.amsl.com> Date: Thu, 12 Sep 2013 18:30:18 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-20.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 01:30:19 -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-20.txt Pages : 76 Date : 2013-09-12 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 ADministrative Management Domains (ADMDs) 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-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sm@elandsys.com Thu Sep 12 18:53: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 BDBC121F9E77 for ; Thu, 12 Sep 2013 18:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, 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 xcl4YdR39r-r for ; Thu, 12 Sep 2013 18:53:18 -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 2A8A421F9E6D for ; Thu, 12 Sep 2013 18:53:17 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.139.127]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8D1r3FS014890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 18:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379037195; bh=gc1GrqqK5rXuCT10HxEFD8bzhs3c9e8gX15BLyubhLE=; h=Date:To:From:Subject:In-Reply-To:References; b=1+Go8v/5/uY5Zp8mXrHMrku2aSqniFEvk7A6E6ieQB6UYrz3M4kdf6+qlLvMtUMMj 8bWA3F21FhSas56FanIHbMKTLhzO4EQc24PvvLBH9QkhEpj+u6rNXuRp3+69TyOU1E +Lgq9fLEAOLpiYCkNjt2vHC5B4LS0SuMu7onllg4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379037195; i=@elandsys.com; bh=gc1GrqqK5rXuCT10HxEFD8bzhs3c9e8gX15BLyubhLE=; h=Date:To:From:Subject:In-Reply-To:References; b=zuHk4R6q2voq/S/UKS3c6QRSanZyJ74+2AkkU2/83+asIhLW3cydat9McqT12+soG D1qctDHGBwvSfQXDmPwJTT3lOyABtpPWWsSShpVIr3PNdOlMn+qo/z6b3GcVO0Fc19 UiLa2hVWZcr6OJQ0Cb5Qoj/wHbKzhWYgBGxYvuLE= Message-Id: <6.2.5.6.2.20130912184532.0c912bc8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Sep 2013 18:52:40 -0700 To: Scott Kitterman , spfbis@ietf.org From: S Moonesamy In-Reply-To: <7883048.PMslXZEC8x@scott-latitude-e6320> References: <6.2.5.6.2.20130912094525.0ca26c60@elandnews.com> <7883048.PMslXZEC8x@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Revised I-D of draft-ietf-spfbis-4408bis 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, 13 Sep 2013 01:53:18 -0000 Hi Scott, At 18:28 12-09-2013, Scott Kitterman wrote: >In retrospect, it wasn't 100% clear if I'm supposed to post -20 as the last >interim diff I sent to the list or work on other outstanding >comments first. In >the interest of being conservative, I'm posting -20 just as I last sent it to >the list. It's okay. Let's work from draft-ietf-spfbis-4408bis-20. Before I forget Appendix A will have to be moved into a section (Pete Resnick commented about that previously). Regards, S. Moonesamy (as document shepherd) From doug.mtview@gmail.com Fri Sep 13 14:39: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 7255B21F9FB1 for ; Fri, 13 Sep 2013 14:39:45 -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, 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 pIZ98N7iQ+qo for ; Fri, 13 Sep 2013 14:39:44 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id DB91F21F9FC6 for ; Fri, 13 Sep 2013 14:39:43 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id lf1so3053523pab.10 for ; Fri, 13 Sep 2013 14:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:date:subject:cc:to; bh=Gj4Fs15oj3p3qReLm7fUNlTjcaaP8O51cuu9+lm8RFU=; b=eYwj8lOrvin1m+rrg/4rhWI7Hd1D3eKuTqF+l5P38Gf81p/g41JvSNGJmMDYw1QCxC OoXkginkyndTOrmYS/UaNAM284/jPUQtRYDSu3k/kL28shu5/fwbpUt917NGb2A/my7D gqPcQmMopS2kMk/m8bM2aiKVsW+Z4Iuwhx4xA1qMlFVjFsz+t5E07oLnbX8WmJeHukuh Hh2SQt4ilitBvYN1x5rb9WSFt5I1QlII+7CiaVV1Az5NMk8NQsqfdULd5/9qDzDnKZvO tUjfP+LdPa4Kvf/4IoEtrX5j+QpzSj8AknYmAUuKQuvxqUbuKfXOZJCtAtY4FFHrWQ26 yHZg== X-Received: by 10.66.145.4 with SMTP id sq4mr4326208pab.178.1379108383635; Fri, 13 Sep 2013 14:39:43 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id sy2sm13952926pbc.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 14:39:42 -0700 (PDT) From: Douglas Otis Content-Type: multipart/alternative; boundary="Apple-Mail=_93A89D89-ABB2-400E-AA9F-C13D530EED8D" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Fri, 13 Sep 2013 14:39:40 -0700 To: "spfbis@ietf.org" X-Mailer: Apple Mail (2.1508) Cc: S Moonesamy , Andrew Sullivan Subject: [spfbis] draft-ietf-spfbis-4408bis-20 review 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, 13 Sep 2013 21:39:45 -0000 --Apple-Mail=_93A89D89-ABB2-400E-AA9F-C13D530EED8D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear SPFbis WG, The section on DNS Lookup Limits is much better. Well done. However a few errors remain. I will attempt to explain this in a = friendly way. Any failure in this regard is not intentional. The last paragraph in 3.4. Record Size: ,--- Note that when computing the sizes for replies to queries of the TXT format, one has to take into account any other TXT records published at the domain name. Similarly, the sizes for replies to all queries related to SPF have to be evaluated to fit in a single 512 octet UDP packet (i.e. DNS message size limited to 450 octects). '-- It is wrong to refer to limiting the UDP packet to 512 octets. There = has never been a 512 octet packet MTU limitation. As I understand the = issue, this is to avoid CPE enforcement of DNS Message size. This limit = predates IPv6 which changed the minimum MTU from 576 to 1280 octets. = EDNS0 makes the limit explicit at 1280 octets or more. Please remove = the term 512 octet UDP packet. The evaluation should be to ensure the = generated response fits within a 512 octet DNS message and perhaps = recommend that this should be less than 450 octets (note the misspelling = of octets). Is this additional reduction to ensure 567 octet MTU = compliance with IPv6 headers (which seems unlikely necessary) or is this = to handle unexpected additional information included in a DNS response? = Either way, there has never been a 512 octet packet size constraint. It would also be better to ensure the recent change to "void" response = gets noticed. The last paragraph of section 5. Mechanism Definitions should make a reference to the last paragraph = in 4.6.4. DNS Lookup Limits. It is unfortunate there is still no mention of a macro's ability to = modulate what might be queried based upon message content rather than = information from DNS which greatly impacts network amplification = assessments. Since SPF uses neither a dedicated resource record type or = a standardized naming convention, mitigation efforts within DNS = operations are less assured. =20 If there is any interchange concern, some effort should be made to = determine whether SPF records containing macros suffer from similar = interchange issues as those related to SPF RR types. The extremely = infrequent use of macros should suggest an underlying reason. I am not = free to make any specific disclosures. Since this issue will impact = interchange, it seems this should be reviewed to benefit those deploying = SPF. Regards, Douglas Otis =20 =20 --Apple-Mail=_93A89D89-ABB2-400E-AA9F-C13D530EED8D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear SPFbis WG,

The section on = DNS Lookup Limits is much better.  Well = done.

However a few errors remain.  I will attempt to = explain this in a friendly way.  Any failure in this regard is not = intentional.

The last = paragraph in 3.4.  Record Size:
,---
Note that when = computing the sizes for replies to queries of the = TXT
format, one has to take into = account any other TXT records published
at the domain name. Similarly, the sizes for replies to = all queries
related to SPF have to = be evaluated to fit in a single 512 octet UDP
packet (i.e. DNS message size limited to 450 = octects).
'--

It is wrong = to refer to limiting the UDP packet to 512 octets.  There has never = been a 512 octet packet MTU limitation.  As I understand the issue, = this is to avoid CPE enforcement of DNS Message size. =  This limit predates IPv6 which changed the minimum MTU from 576 to = 1280 octets.  EDNS0 makes the limit explicit at 1280 octets or = more.  Please remove the term 512 octet UDP packet.  The = evaluation should be to ensure the generated response fits within a 512 = octet DNS message and perhaps recommend that this should be less than = 450 octets (note the misspelling of octets).  Is this additional = reduction to ensure 567 octet MTU compliance with IPv6 headers (which = seems unlikely necessary) or is this to handle unexpected additional = information included in a DNS response?  Either way, there has = never been a 512 octet packet size constraint.

It would also = be better to ensure the recent change to "void" response gets noticed. =  The last paragraph of section
5. Mechanism Definitions should make a reference to the = last paragraph in 4.6.4. DNS Lookup Limits.

It is = unfortunate there is still no mention of a macro's ability to modulate = what might be queried based upon message content rather than information = from DNS which greatly impacts network amplification assessments. =  Since SPF uses neither a dedicated resource record type or a = standardized naming convention, mitigation efforts within DNS operations = are less assured.  

If there is = any interchange concern, some effort should be made to determine whether = SPF records containing macros suffer from similar interchange issues as = those related to SPF RR types.  The extremely infrequent use of = macros should suggest an underlying reason.  I am not free to make = any specific disclosures.  Since this issue will impact = interchange, it seems this should be reviewed to benefit those deploying = SPF.

Regards,
Douglas = Otis

 

  






= --Apple-Mail=_93A89D89-ABB2-400E-AA9F-C13D530EED8D-- From sm@elandsys.com Fri Sep 13 15:36:48 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 AD98111E8192 for ; Fri, 13 Sep 2013 15:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 KSbqpiLZUK21 for ; Fri, 13 Sep 2013 15:36:48 -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 D40E811E8184 for ; Fri, 13 Sep 2013 15:36:47 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.219]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8DMaLk9003223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Sep 2013 15:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379111793; bh=F4VYfLeI4rnh+zTN085ywYBvKbOJCIlm3fRINOqRRGw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=KfnWtRv5t7D9PSnWFZs9pkk6DKuETuo8FV74gHv2rBaa7uzb6wffPAtYg41ehyv+h R61xZxOuVG4h1BH77rIQjiDNA3dYCP8eoSW4j9gzB578eb2tFvDGY7GEWZ58uBD3QT dbBabQckwBjZBWrZyiOIejMsIgBF6v12zUbfKQCw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379111793; i=@elandsys.com; bh=F4VYfLeI4rnh+zTN085ywYBvKbOJCIlm3fRINOqRRGw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1rO7FvfGEZrw2AqOxFjmjaYthhNIiipsjinDgKkSvUiV8xITtQqmTrkcpR0nqLEeS IuvG5cEw2KsQ2vY2WnIUlpyEGHZaBd5NImDxU9ED4TgWZb2s24lC2/I5pQLaYPFiYN F9OSHyy00j0A2266agVXJKLanTw0nYFh0BJFeFJk= Message-Id: <6.2.5.6.2.20130913152347.0c874cb8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 13 Sep 2013 15:36:01 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Douglas Otis Subject: Re: [spfbis] draft-ietf-spfbis-4408bis-20 review 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, 13 Sep 2013 22:36:49 -0000 Hi Scott, At 14:39 13-09-2013, Douglas Otis wrote: >It is wrong to refer to limiting the UDP packet to 512 >octets. There has never been a 512 octet packet MTU limitation. As >I understand the issue, this is to avoid CPE enforcement of DNS >Message size. This limit predates IPv6 which changed the minimum >MTU from 576 to 1280 octets. EDNS0 makes the limit explicit at 1280 >octets or more. Please remove the term 512 octet UDP packet. The >evaluation should be to ensure the generated response fits within a >512 octet DNS message and perhaps recommend that this should be less >than 450 octets (note the misspelling of octets). Is this >additional reduction to ensure 567 octet MTU compliance with IPv6 >headers (which seems unlikely necessary) or is this to handle >unexpected additional information included in a DNS >response? Either way, there has never been a 512 octet packet size constraint. As a note to Doug, I am responding to the above only. Please note that I am not ignoring the other comments. In my opinion this proposed change is about an editorial issue. The issue is about the term "UDP packet" as used in the first and second paragraphs of Section 3.4 of draft-ietf-spfbis-4408bis-20. Could you please propose text to address this? Thanks, S. Moonesamy (as document shepherd) From doug.mtview@gmail.com Fri Sep 13 16:30: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 6F17211E823B for ; Fri, 13 Sep 2013 16:30:46 -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 BqfJm7UiWQWS for ; Fri, 13 Sep 2013 16:30:46 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id E903411E823A for ; Fri, 13 Sep 2013 16:30:45 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so3126205pab.13 for ; Fri, 13 Sep 2013 16:30:45 -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; bh=8JMpFIVwM+rybnhLlj8NR+aVlz2QP7T8x4krA5A6VkU=; b=NGrWIjefEtYLxBWnh1MkJJciA7fBRdxRYnluy39NM2UCvQfMME5ueqBc5SiQ6CRFKT I9C9NckQDYpRKklxT/R8sH7T3BTTs78PudpOEMOGfthaejgAJdRHOM5Xo9lOODpaToi2 Z2dvV9EvXcMnpAJok7D64CwaMYOIGcrhssTdlxcA0EGbx77tMK72Rbf1iNc2ERnkDXcQ KLpyPp4+DaV1bUyftYWN5sft/sUsCabkjxi78DHJxzedAdFCPx54H/Exo8C8lfhWhKZc bN3ahT0KFskHer76quVq/F6BBkydx0w4fjWJwjIKkNIY5IdFA79ZmSUFd1USlqHhh8dX AW2A== X-Received: by 10.68.130.71 with SMTP id oc7mr16224190pbb.10.1379115045602; Fri, 13 Sep 2013 16:30:45 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id f2sm14300376pbg.44.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 16:30:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Douglas Otis In-Reply-To: <6.2.5.6.2.20130913152347.0c874cb8@elandnews.com> Date: Fri, 13 Sep 2013 16:30:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20130913152347.0c874cb8@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1508) Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] draft-ietf-spfbis-4408bis-20 review (response size) 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, 13 Sep 2013 23:30:46 -0000 On Sep 13, 2013, at 3:36 PM, S Moonesamy wrote: > Hi Scott, > At 14:39 13-09-2013, Douglas Otis wrote: >> It is wrong to refer to limiting the UDP packet to 512 octets. There = has never been a 512 octet packet MTU limitation. As I understand the = issue, this is to avoid CPE enforcement of DNS Message size. This limit = predates IPv6 which changed the minimum MTU from 576 to 1280 octets. = EDNS0 makes the limit explicit at 1280 octets or more. Please remove = the term 512 octet UDP packet. The evaluation should be to ensure the = generated response fits within a 512 octet DNS message and perhaps = recommend that this should be less than 450 octets (note the misspelling = of octets). Is this additional reduction to ensure 567 octet MTU = compliance with IPv6 headers (which seems unlikely necessary) or is this = to handle unexpected additional information included in a DNS response? = Either way, there has never been a 512 octet packet size constraint. >=20 > As a note to Doug, I am responding to the above only. Please note = that I am not ignoring the other comments. >=20 > In my opinion this proposed change is about an editorial issue. The = issue is about the term "UDP packet" as used in the first and second = paragraphs of Section 3.4 of draft-ietf-spfbis-4408bis-20. Dear SM,=20 Season to taste. ;^) Was: ,--- Note that when computing the sizes for replies to queries of the TXT format, one has to take into account any other TXT records published at the domain name. Similarly, the sizes for replies to all queries related to SPF have to be evaluated to fit in a single 512 octet UDP packet (i.e. DNS message size limited to 450 octects). '--- Change to: ,--- Note that when computing the sizes for replies to queries of the TXT format, one has to take into account any other TXT records published at the domain name. Similarly, the sizes for replies to all queries related to SPF have to be evaluated to fit in a 512 octet DNS=20 Message. Limiting responses to less than a 450 octet DNS Message may accommodate additional information added automatically. '--- Regards, Douglas Otis From sm@elandsys.com Fri Sep 13 17:02: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 DF65B11E80EE for ; Fri, 13 Sep 2013 17:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 H5C2xwlf+eko for ; Fri, 13 Sep 2013 17:02: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 50AAB11E8102 for ; Fri, 13 Sep 2013 17:02:11 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.219]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8E01kZG012437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Sep 2013 17:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379116924; bh=xxLOjkjw2+Somv9d0GyoGCGJ5gNTqAK4mJsSBZos34E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1c9XG6qlj3xMCp6wwu+pzAaG+9OLK2kvCBde8tvz2JL3pOwJu1slSIJaEC2ydUOS7 rlqSrvujyowqNQvbwcvXJYSoqWjBAhKGTUFBd1/e39OTm71C+0k9CJt08HkBfX/zP5 yfRk1ck3FCetF9LiUlYbO3in21q0Ph8MxjWssTms= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379116924; i=@elandsys.com; bh=xxLOjkjw2+Somv9d0GyoGCGJ5gNTqAK4mJsSBZos34E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tshh15QifxfiFXqPAEBzq0MtfbKnK+VnRW3LEbrttlNE30su87C3rl7b00Bwq/OZx oTfaaNMw6NqAusgm63vKP6Qz9xiLF8qPDeejtPt6t8iVYd5u2zxhSpDNBqsTfTBXI0 mf2zVHI0un2OF1VZ9PheRhtAEK2zwQD6SNgH/8Nw= Message-Id: <6.2.5.6.2.20130913165239.0be3fed0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 13 Sep 2013 17:01:24 -0700 To: Douglas Otis From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130913152347.0c874cb8@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] draft-ietf-spfbis-4408bis-20 review (response size) 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, 14 Sep 2013 00:02:13 -0000 Hi Doug, At 16:30 13-09-2013, Douglas Otis wrote: >Season to taste. ;^) :-) >Change to: >,--- >Note that when computing the sizes for replies to queries of the TXT >format, one has to take into account any other TXT records published >at the domain name. Similarly, the sizes for replies to all queries >related to SPF have to be evaluated to fit in a 512 octet DNS >Message. Limiting responses to less than a 450 octet DNS Message >may accommodate additional information added automatically. The above looks okay to me. The last sentence could be dropped. Regards, S. Moonesamy (as document shepherd) From ajs@anvilwalrusden.com Fri Sep 13 17:12: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 7C84B11E80EE for ; Fri, 13 Sep 2013 17:12:08 -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 eoiGPmB4V-Li for ; Fri, 13 Sep 2013 17:12:02 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id AC13211E80E9 for ; Fri, 13 Sep 2013 17:12:02 -0700 (PDT) Received: from mx1.yitter.info (ip-64-134-70-170.public.wayport.net [64.134.70.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B3DED8A031 for ; Sat, 14 Sep 2013 00:12:01 +0000 (UTC) Date: Fri, 13 Sep 2013 20:12:04 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130914001204.GB78680@mx1.yitter.info> References: <6.2.5.6.2.20130913152347.0c874cb8@elandnews.com> 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] draft-ietf-spfbis-4408bis-20 review (response size) 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, 14 Sep 2013 00:12:08 -0000 On Fri, Sep 13, 2013 at 04:30:42PM -0700, Douglas Otis wrote: > related to SPF have to be evaluated to fit in a single 512 octet UDP > packet (i.e. DNS message size limited to 450 octects). > Message. Limiting responses to less than a 450 octet DNS Message > may accommodate additional information added automatically. I must have missed it before, given the changes that are flying fast and furious, but where in the world did 450 octets come from? That's not a "DNS magic number" anywhere of which I am aware. A -- Andrew Sullivan ajs@anvilwalrusden.com From doug.mtview@gmail.com Fri Sep 13 17:25: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 9139311E80EE; Fri, 13 Sep 2013 17:25: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=[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 BSDTCM7CV879; Fri, 13 Sep 2013 17:25:33 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6027311E8128; Fri, 13 Sep 2013 17:25:22 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un15so1876371pbc.15 for ; Fri, 13 Sep 2013 17:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=L8NQ3BZV4j3hbfIKIqCdV8JoGOCo51zL7s3sKvJVgvQ=; b=FU7ujvSTFKkdFoWBgyIUVcVFOQ3yvKUFKg4Ja4THToeI6H0GmeQGthJWQA1XuYaRqO THT9H1qabOIDo7sbHvXje0nhlal5rGHjS+9kl8LO1v1G04FjZo08ZoLWQv2AoYHVS6NB qIMkB5fQGVfSY3zEYKVxSqTCbe5lGsiw8EWw76uKsEVeR1Y1K0KtgDzheiF4dIWEyHcM 6AllqvIbEwKxxzP+xySde40r5ckxeWMScK3t61nLnaTmjgcGmBHg8+FAsbCoUVRJltn0 I9Ge5QtxOGrGwNAspIqrn3WgjjcUCCp/4j336irdmzpVxV3KR7KgahEvIojb9w3cfEMy VZgQ== X-Received: by 10.66.122.40 with SMTP id lp8mr17946291pab.82.1379118322668; Fri, 13 Sep 2013 17:25:22 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id m4sm12026640pbg.38.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 17:25:21 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: Douglas Otis In-Reply-To: <6.2.5.6.2.20130912080503.0c90f9d0@elandnews.com> Date: Fri, 13 Sep 2013 17:25:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <18A91BEE-6360-4E1F-9B08-5E45C5217694@gmail.com> References: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130912065558.0b960550@elandnews.com> <5231D5E5.5070407@cisco.com> <6.2.5.6.2.20130912080503.0c90f9d0@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1508) Cc: Benoit Claise , spfbis@ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG , spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 14 Sep 2013 00:25:34 -0000 On Sep 12, 2013, at 8:09 AM, S Moonesamy wrote: > Hi Benoit, > At 07:55 12-09-2013, Benoit Claise wrote: >> Well, maybe "Changes in implementation requirements from RFC 4408" >> So my first question is: what are the changes that are not related to = the implementation requirements? >> As a good example, = http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis-04#appendix-B is = useful. >=20 > That is a good question (re. implementation requirements). I suggest = following the example you provided if Pete Resnick is okay with that. Dear SM, I would like to respond to this suggestion. This suggestion overlooks SPF parameters from email messages combine to = form DNS queries using macros in an endless number of ways. Our data = shows spam is largely emitted from compromised systems where SPF offers = a covert method of targeting victims. This form of abuse can increase = network amplification by a factor of 3 or more beyond typical DNS = attacks. This type of abuse also side steps Source Address Validation = BCP38 aimed at disabling source address spoofing as well as UDP Source = Port Randomization or even DNS Response Rate Limiting. =20 Such an attack is likely well beyond what DNS or DNSSEC can handle by = employing usual defenses. In addition, SPF does not use a dedicated = resource record type nor a naming convention and is likely to ignore = receipt of large TXT and PTR RRsets. With so few domains publishing SPF = macros, large providers already indicate they ignore SPF records = containing macros which reduces this threat. After all, if this type of = abuse were to occur, it would likely require a response from email = providers and not DNS operators. IMHO, the current specification has = not kept up with current practices. Regards, Douglas Otis From doug.mtview@gmail.com Fri Sep 13 17:34: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 D17DB11E80EE for ; Fri, 13 Sep 2013 17:34: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=[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 s0dqLfEueIAn for ; Fri, 13 Sep 2013 17:34:44 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5D51811E80E9 for ; Fri, 13 Sep 2013 17:34:44 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id g10so1887593pdj.2 for ; Fri, 13 Sep 2013 17:34:44 -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; bh=+DkoKKwgT4TAVGPSFxnSTC0O/UjV9rehrTgk5sh7dzE=; b=eRzesCOOHhIBCH6YGm1bSROy/+JjaGk1uBQ9VRSRWNsaix/opU9eihZXQcQAez7ZXs 7KD8t4zTnRZG14kkftDUO92H8ZlnYZGQjsmi2TSI1k9BI9MMigsqhoxcc6sH6RTbIuu7 +MX8lLlzLRmVNEaeQBoTrFnHfZ1F3o0kCBDjYVCU9/gzXxdBXODQHxJGqlKRfzG0U6bG nI/J6y1m11rwhJi6wcyYMe3J0FWBLHsHk+t4OJKiPrUQjXeAKfMmdUzorPIgEXMHhciy uMBneXi2ay41W4J3sh4pMJPCFTah/mBFxxigx8n6zHVcbGOeFWK4gdguAIrisO8kD8OI X7nw== X-Received: by 10.67.4.197 with SMTP id cg5mr18049597pad.10.1379118884026; Fri, 13 Sep 2013 17:34:44 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id fa4sm21049498pab.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 17:34:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Douglas Otis In-Reply-To: <20130914001204.GB78680@mx1.yitter.info> Date: Fri, 13 Sep 2013 17:34:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <72C262F1-0715-499D-948F-989A9A007824@gmail.com> References: <6.2.5.6.2.20130913152347.0c874cb8@elandnews.com> <20130914001204.GB78680@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1508) Cc: spfbis@ietf.org Subject: Re: [spfbis] draft-ietf-spfbis-4408bis-20 review (response size) 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, 14 Sep 2013 00:34:44 -0000 Dear Andrew, I did not recommend this value, but I did say it sounded like reasonable = advice. I have been burnt a number of times by "helpful" DNS servers = that decide to add some additional information. I also wondered if = this was about a IPv6 related issue, which may require a reduction of 40 = for the IP header assuming a goal was to retain a 576 octet MTU. But = this does not sound reasonable either.=20 Regard, Douglas Otis On Sep 13, 2013, at 5:12 PM, Andrew Sullivan = wrote: > On Fri, Sep 13, 2013 at 04:30:42PM -0700, Douglas Otis wrote: >> related to SPF have to be evaluated to fit in a single 512 octet UDP >> packet (i.e. DNS message size limited to 450 octects). >=20 >> Message. Limiting responses to less than a 450 octet DNS Message >> may accommodate additional information added automatically. >=20 > I must have missed it before, given the changes that are flying fast > and furious, but where in the world did 450 octets come from? That's > not a "DNS magic number" anywhere of which I am aware. >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From ajs@anvilwalrusden.com Fri Sep 13 17:37: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 F1A8811E8128; Fri, 13 Sep 2013 17:37:24 -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 i-vEVTQ-nD-5; Fri, 13 Sep 2013 17:37:11 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id B359B11E80E9; Fri, 13 Sep 2013 17:37:11 -0700 (PDT) Received: from mx1.yitter.info (ip-64-134-70-170.public.wayport.net [64.134.70.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 514D28A031; Sat, 14 Sep 2013 00:36:59 +0000 (UTC) Date: Fri, 13 Sep 2013 20:36:55 -0400 From: Andrew Sullivan To: Douglas Otis Message-ID: <20130914003652.GF78680@mx1.yitter.info> References: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130912065558.0b960550@elandnews.com> <5231D5E5.5070407@cisco.com> <6.2.5.6.2.20130912080503.0c90f9d0@elandnews.com> <18A91BEE-6360-4E1F-9B08-5E45C5217694@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18A91BEE-6360-4E1F-9B08-5E45C5217694@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: S Moonesamy , spfbis@ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG , Benoit Claise , spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 14 Sep 2013 00:37:25 -0000 Doug, I'm writing as co-chair on what I hope are strictly procedural matters. On Fri, Sep 13, 2013 at 05:25:20PM -0700, Douglas Otis wrote: > to ignore receipt of large TXT and PTR RRsets. With so few domains > publishing SPF macros, large providers already indicate they ignore > SPF records containing macros which reduces this threat. It would be nice if you would produce even one citation for this, since it's been asked of you repeatedly. > response from email providers and not DNS operators. IMHO, the > current specification has not kept up with current practices. That is entirely possible. The WG is not chartered to remove features that are in use. By anyone. We already had that appeal, and made that decision. So why does it matter if there is a feature in here that is falling out of favour? A later effort can remove it if it is really unused. But we can't. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From spf2@kitterman.com Fri Sep 13 20:32:17 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 8E8CC11E8131 for ; Fri, 13 Sep 2013 20:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 h9JoRbjQpWFz for ; Fri, 13 Sep 2013 20:32:12 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6B36211E815E for ; Fri, 13 Sep 2013 20:32:12 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BA35A20E40F6; Fri, 13 Sep 2013 23:32:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1379129526; bh=rZWrh6H5TToouD25dZdcie2cVz2sT0HcLcYvlddvVco=; h=From:To:Subject:Date:In-Reply-To:References:From; b=V1r1vD9OodI5QRXt3Fl8EvD6oxbUkTkiqKUFOfFwt9RWhr4GLuW/aNhSQ/4cQLEHA 448hN2s77TJKT4OzAYNQvacpagf35uOvVGWj10uO6a6rjPbavryr2fQWwtJSvvfc2U LDqLwgd0Uko8E3ZnYl9QW6N0+BYIIfx0CeQrsoWM= 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 9D8F720E40CB; Fri, 13 Sep 2013 23:32:06 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 13 Sep 2013 23:32:05 -0400 Message-ID: <5129719.PDZTiHcDZ6@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <20130914001204.GB78680@mx1.yitter.info> References: <20130914001204.GB78680@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] draft-ietf-spfbis-4408bis-20 review (response size) 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, 14 Sep 2013 03:32:17 -0000 On Friday, September 13, 2013 20:12:04 Andrew Sullivan wrote: > On Fri, Sep 13, 2013 at 04:30:42PM -0700, Douglas Otis wrote: > > related to SPF have to be evaluated to fit in a single 512 octet UDP > > packet (i.e. DNS message size limited to 450 octects). > > > > Message. Limiting responses to less than a 450 octet DNS Message > > may accommodate additional information added automatically. > > I must have missed it before, given the changes that are flying fast > and furious, but where in the world did 450 octets come from? That's > not a "DNS magic number" anywhere of which I am aware. It's from RFC 4408: 3.1.4. Record Size The published SPF record for a given domain name SHOULD remain small enough that the results of a query for it will fit within 512 octets. This will keep even older DNS implementations from falling over to TCP. Since the answer size is dependent on many things outside the scope of this document, it is only possible to give this guideline: If the combined length of the DNS name and the text of all the records of a given type (TXT or SPF) is under 450 characters, then DNS answers should fit in UDP packets. Note that when computing the sizes for queries of the TXT format, one must take into account any other TXT records published at the domain name. Records that are too long to fit in a single UDP packet MAY be silently ignored by SPF clients. It's meant to provide record publishers with a rule of thumb to use on how large an SPF record can be without risk of needing EDNS0 or TCP. Scott K From doug.mtview@gmail.com Fri Sep 13 20:57: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 4C6DF11E8131; Fri, 13 Sep 2013 20:57:06 -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=[AWL=-0.000, 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 OBDbAzUOEHrP; Fri, 13 Sep 2013 20:57:00 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9593F11E80ED; Fri, 13 Sep 2013 20:56:59 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fz6so3292520pac.31 for ; Fri, 13 Sep 2013 20:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=XLMSAlQ38ACDxkjE6ae9BpY5qXiObO2JVGGZBEUndmg=; b=Xqq/GK6HEAgHCTEsFYtwpp0SAgw8d+heUYcwgWmW5CXrgv6d3c4HwAXPHf4leOwnqE I6S6/oS427/ol8eYA6gPC4eiJvMceQcLms1lMAPMYRepQXdU8ZIPOgDksWL+Ks6g2DfX B6SS4GTSs6xKyA2yniMY3psgzBBJOeXgaattScrQp1XnyB3pi0trDjaxFVHIknTzxgQv 3GCyy4ItuLEZcvd3VP0b3W/BKEp86hPbqs4Y6wclIH8Lj+kTzxOvReDQHBl9wfJsQBNH ZEBrJ/xhXQSgS9iaSUA7LF2f/414rKsuGg2SL+VWCQdzb7y6uXaFfr1NVL8V97jjrEbM t3AA== X-Received: by 10.66.187.34 with SMTP id fp2mr18713588pac.12.1379131018118; Fri, 13 Sep 2013 20:56:58 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id mr3sm15393052pbb.27.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Sep 2013 20:56:57 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_74237C84-AEAA-4FAE-92BB-6B43AC0139D9" From: Douglas Otis In-Reply-To: <20130914003652.GF78680@mx1.yitter.info> Date: Fri, 13 Sep 2013 20:56:55 -0700 Message-Id: References: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130912065558.0b960550@elandnews.com> <5231D5E5.5070407@cisco.com> <6.2.5.6.2.20130912080503.0c90f9d0@elandnews.com> <18A91BEE-6360-4E1F-9B08-5E45C5217694@gmail.com> <20130914003652.GF78680@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1508) Cc: S Moonesamy , spfbis@ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG , Benoit Claise , spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 14 Sep 2013 03:57:06 -0000 --Apple-Mail=_74237C84-AEAA-4FAE-92BB-6B43AC0139D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Andrew, See comments inline. On Sep 13, 2013, at 5:36 PM, Andrew Sullivan = wrote: > Doug, >=20 > I'm writing as co-chair on what I hope are strictly procedural > matters. >=20 > On Fri, Sep 13, 2013 at 05:25:20PM -0700, Douglas Otis wrote: >> to ignore receipt of large TXT and PTR RRsets. With so few domains >> publishing SPF macros, large providers already indicate they ignore >> SPF records containing macros which reduces this threat. >=20 > It would be nice if you would produce even one citation for this, > since it's been asked of you repeatedly.=20 I fully understand a desire to limit discussions about aspects of this = protocol. This will take more time than anyone wants to afford for = email. In my prior response off list copied to Pete, this was agreeing = with your statement about the WG skill with DNS. Also, I am obligated = to keep some conversations in confidence. More than just IETF members = are involved. In my defense, may I ask whether the draft = http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-01 been = reviewed? It contains a reference to a survey by the SPF website = http://spf-all.com/stats.html which indicates of all domains publishing = SPF records 99.947% contain no macros. It seems a reasonable person = would wonder why. The issue of the PTR RRset is a matter of record. There are even recent = conversations with Scott where I noted the SPFbis protocol omits limits = on the number of PTR RRs unlike limits placed on MX RRs. I even = suggested text to remedy this oversight. He responded this was not an = issue for SPF. We are also going over language regarding response = sizes. May I point out there are no SPF error conditions caused by a = TXT RRset or PTR RRset being too large. I hope you can imagine what this might mean from the perspective of = network amplifications caused by a protocol that recommends resolving = two separate names using this highly inefficient protocol overlaying DNS = to provide massive automation for unknown entities that lacks any = dedicated resource record type or naming convention. Carefully review = the process for the PTR mechanism and estimate the DNS transactions and = the resulting network traffic that could be caused for each occurrence.=20= The MX mechanism can generate 111 DNS transactions with a recursive = server. This ignores supporting transactions likely needed in a = resolution process. Make that estimate again while assuming EDNS0 with = a 1410 octet MTU, and again with a 4096 octet MTU. As I had mentioned, = use of IPv6 and DNSSEC is not within the purview of SPF. The SPF = protocol should not be allowed to ignore its impact on DNSSEC despite a = steady insistence SPF does nothing special with DNS and any problem must = be considered the fault of DNS. The only remedy available is for = providers to ignore any SPF TXT resource records containing macros. = What else can be done? As an aside, at the time SPF was developed, there was already the binary = APL RR, that when combined the MX record, could define the entire = outbound address space within a single transaction. It seems one vendor = remains the major obstacle. Not surprisingly, this vendor is now seldom = used to directly interface with email. Why should their abstinence be = allowed to destroy safe deployment of DNSSEC? Why should SPF be allowed = to blame DNS? >> response from email providers and not DNS operators. IMHO, the >> current specification has not kept up with current practices. >=20 > That is entirely possible. The WG is not chartered to remove > features that are in use. By anyone. We already had that appeal, and > made that decision. So why does it matter if there is a feature in > here that is falling out of favour? A later effort can remove it if > it is really unused. But we can't. At the same time, it seems irresponsible to completely deprecate use of = the dedicated RR record type that had a much higher level of use while = not deprecating a far more dangerous macro option used by far fewer = domains. Such an oversight can not be excused by blaming the charter. If I have said something offensive, allow me once again to assure you = this was never my intent. Regards, Douglas Otis --Apple-Mail=_74237C84-AEAA-4FAE-92BB-6B43AC0139D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = Andrew,

See comments = inline.

On Sep 13, 2013, at 5:36 PM, = Andrew Sullivan <ajs@anvilwalrusden.com> = wrote:

Doug,

I'm writing as co-chair on what I hope are = strictly procedural
matters.

On Fri, Sep 13, 2013 at = 05:25:20PM -0700, Douglas Otis wrote:
to = ignore receipt of large TXT and PTR RRsets.  With so few = domains
publishing SPF macros, large providers already indicate they = ignore
SPF records containing macros which reduces this = threat.

It would be nice if you would produce even = one citation for this,
since it's been asked of you = repeatedly. 

I fully understand = a desire to limit discussions about aspects of this protocol.  This = will take more time than anyone wants to afford for email.  In my = prior response off list copied to Pete, this was agreeing with your = statement about the WG skill with DNS.  Also, I am obligated = to keep some conversations in confidence.  More than just IETF = members are involved.

In my defense, may I ask = whether the draft http= ://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-01 been = reviewed?

It contains a reference to a survey = by the SPF website http://spf-all.com/stats.html&n= bsp;which indicates of all domains publishing SPF = records 99.947% contain no macros.  It seems a reasonable = person would wonder why.

The issue of the = PTR RRset is a matter of record.  There are even recent = conversations with Scott where I noted the SPFbis protocol omits limits = on the number of PTR RRs unlike limits placed on MX RRs.  I even = suggested text to remedy this oversight.  He responded this was not = an issue for SPF.  We are also going over language regarding = response sizes.  May I point out there are no SPF error conditions = caused by a TXT RRset or PTR RRset being too = large.

I hope you can imagine what this might = mean from the perspective of network amplifications caused by a protocol = that recommends resolving two separate names using this highly = inefficient protocol overlaying DNS to provide massive automation for = unknown entities that lacks any dedicated resource record type or naming = convention.  Carefully review the process for the PTR mechanism and = estimate the DNS transactions and the resulting network traffic that = could be caused for each occurrence. 

The = MX mechanism can generate 111 DNS transactions with a recursive server. =  This ignores supporting transactions likely needed in a resolution = process.  Make that estimate again while assuming EDNS0 with a 1410 = octet MTU, and again with a 4096 octet MTU.  As I had mentioned, = use of IPv6 and DNSSEC is not within the purview of SPF.  The SPF = protocol should not be allowed to ignore its impact on DNSSEC despite a = steady insistence SPF does nothing special with DNS and any problem must = be considered the fault of DNS.  The only remedy available is for = providers to ignore any SPF TXT resource records containing macros. =  What else can be done?

As an aside, at = the time SPF was developed, there was already the binary APL RR, that = when combined the MX record, could define the entire outbound address = space within a single transaction.  It seems one vendor remains the = major obstacle.  Not surprisingly, this vendor is now seldom used = to directly interface with email.  Why should their abstinence be = allowed to destroy safe deployment of DNSSEC?  Why should SPF be = allowed to blame DNS?

response from email providers = and not DNS operators.  IMHO, the
current specification has not = kept up with current practices.

That is entirely = possible.  The WG is not chartered to remove
features that are = in use.  By anyone.  We already had that appeal, and
made = that decision.  So why does it matter if there is a feature = in
here that is falling out of favour?  A later effort can = remove it if
it is really unused.  But we = can't.

At the same time, it seems = irresponsible to completely deprecate use of the dedicated RR record = type that had a much higher level of use while not deprecating a far = more dangerous macro option used by far fewer domains.  Such an = oversight  can not be excused by blaming the = charter.

If I have said something offensive, = allow me once again to assure you this was never my = intent.

Regards,
Douglas = Otis





=

= --Apple-Mail=_74237C84-AEAA-4FAE-92BB-6B43AC0139D9-- From spf2@kitterman.com Fri Sep 13 21:18: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 0D90011E80F3 for ; Fri, 13 Sep 2013 21:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=0.284, 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 KiLQYczg1lhx for ; Fri, 13 Sep 2013 21:18:20 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BDAF011E80ED for ; Fri, 13 Sep 2013 21:18:20 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 048C220E40F6; Sat, 14 Sep 2013 00:18:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1379132300; bh=vT89KbbaX8rsysHnGbC5BXLHtOd3aEsKYvHqY++gALk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iZeX6duaEhtsPdWffX5huk3a27Ph3eUIIY6ThVzaxC7LU7x4elpYBadtCi+9GLQGs NwUBucfUEBSy9tQp9ux6ybzz4U+kRGK3Rbm9pUBUqnVuKWaZM0dT4TNVQoNh8jI1Tj hX80jcnn3wPEQCSpocLL4DqR6A1/dk4myugwvcDc= 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 DAE1820E40CB; Sat, 14 Sep 2013 00:18:19 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 14 Sep 2013 00:18:18 -0400 Message-ID: <2340356.St57jYUxEv@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: References: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> <20130914003652.GF78680@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] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 14 Sep 2013 04:18:26 -0000 On Friday, September 13, 2013 20:56:55 Douglas Otis wrote: .. > The issue of the PTR RRset is a matter of record. There are even recent > conversations with Scott where I noted the SPFbis protocol omits limits on > the number of PTR RRs unlike limits placed on MX RRs. I even suggested > text to remedy this oversight. He responded this was not an issue for > SPF. We are also going over language regarding response sizes. May I > point out there are no SPF error conditions caused by a TXT RRset or PTR > RRset being too large. ... To correct the record, I said it was intentional. The reason why it's treated different is explained on 4408bis. We had language that treated PTR like MX for lookup limits, but that was changed for the reasons explained. I didn't say it was "not an issue". It was a deliberate design choice based on two competing issues. We debated this in the WG already and I'm not aware of any new information that would make re-litigating it a reasonable thing to do. I'm only commenting on this part to correct what I see as an error relating to what I've said in the past. Scott K From spf2@kitterman.com Fri Sep 13 21:25: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 B300511E80ED for ; Fri, 13 Sep 2013 21:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, 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 ZDDbqkb-L3Sd for ; Fri, 13 Sep 2013 21:25:27 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4F93611E80E8 for ; Fri, 13 Sep 2013 21:25:25 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9232120E40F6; Sat, 14 Sep 2013 00:25:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1379132724; bh=khM93Pm1Y6QhLAeIVpgfMiKeuKqPUbSRoczdFJatHAQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nU8im31zhHBOWyUEjf7/Swqmv77My7VBQXqTJV+K/CG/QSVQXsLVwIt8olH3yDfj9 cQRxLAWD6NI2iC0GwO11ok3jzPmf1JSMgCZjKnPrVUv+LD8KXGg8hqqTUHefBbI3G2 /Qde7ZWWlJnDu3Zbi1p6ikE/cZHUB2b9Xmh5WEHo= 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 7CCA120E40CB; Sat, 14 Sep 2013 00:25:24 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 14 Sep 2013 00:25:23 -0400 Message-ID: <38312086.HKzMeyOO04@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130913165239.0be3fed0@elandnews.com> References: <6.2.5.6.2.20130913165239.0be3fed0@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] draft-ietf-spfbis-4408bis-20 review (response size) 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, 14 Sep 2013 04:25:33 -0000 On Friday, September 13, 2013 17:01:24 S Moonesamy wrote: > Hi Doug, > > At 16:30 13-09-2013, Douglas Otis wrote: > >Season to taste. ;^) > > > :-) > : > >Change to: > >,--- > >Note that when computing the sizes for replies to queries of the TXT > >format, one has to take into account any other TXT records published > >at the domain name. Similarly, the sizes for replies to all queries > >related to SPF have to be evaluated to fit in a 512 octet DNS > >Message. Limiting responses to less than a 450 octet DNS Message > >may accommodate additional information added automatically. > > The above looks okay to me. The last sentence could be dropped. No. The point is you can't use the entire 512 [insert term here] for the SPF record due to potentially other TXT records and DNS message overhead. The 450 number is a rule of thumb that was developed to provide a ~safe SPF record size in the absence of other TXT records. The propose language uses the term "DNS message" both for the UDP packet size and for the part of that packet that can be used for an SPF record. I strongly object to dropping the 450 recommendation based on no data that says it's bad (it is in RFC 4408 and no case to remove it has been recommended). All the rambling about IPv6, EDNS0, etc is irrelevant. The point is to keep the record small enough to make it reliable. Even if there was a point in the the change, the language is definitely a regression from what was there before because it uses the same term for two different things. Scott K From sm@elandsys.com Fri Sep 13 22:32: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 2EFCC21F9E96; Fri, 13 Sep 2013 22:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 JGLKLAl3CP1P; Fri, 13 Sep 2013 22:32:34 -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 05DE021F9E83; Fri, 13 Sep 2013 22:32:33 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.219]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8E5WDp0023061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Sep 2013 22:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379136747; bh=npQXH4yMBH4Gx/nt9cm5TpTSRsEsUB+3NfIoB92dQV8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=p3QchBnKAM5FTftTl6RTxrFZljFsmlsL1zErRr5C+7L0urBMLhMmLtfo4kn1nvPyR LFKwBvd+s7cnfPseHakBizO4xuQVXX0g7/UoXuACzBE34u+uBUs1eWLBKopv+Aj0T6 TNKX3wc2gFz3SEdcc1Lnfw3wPsOntucTVbDVKNC4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379136747; i=@elandsys.com; bh=npQXH4yMBH4Gx/nt9cm5TpTSRsEsUB+3NfIoB92dQV8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=i/5dRJOfUn4zpU0xA7nDH5QBDNgMgKj+XNgw2qmEm0R89acZtr/UbAN+h98sxsQNw LA6tyqOuy/em28MYsqEADa5UdxKM9CjI6+XT6PZJnpETTDb+ls7ecfUa05poqS/TNk MXPG8hP9PVZONtIdOsUMQBt8Pvfekhhe1SpXA+jI= Message-Id: <6.2.5.6.2.20130913211154.0c82ead8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 13 Sep 2013 22:31:42 -0700 To: Douglas Otis From: S Moonesamy In-Reply-To: <18A91BEE-6360-4E1F-9B08-5E45C5217694@gmail.com> References: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130912065558.0b960550@elandnews.com> <5231D5E5.5070407@cisco.com> <6.2.5.6.2.20130912080503.0c90f9d0@elandnews.com> <18A91BEE-6360-4E1F-9B08-5E45C5217694@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Benoit Claise , spfbis@ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG , spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 14 Sep 2013 05:32:35 -0000 Hi Doug, At 17:25 13-09-2013, Douglas Otis wrote: >I would like to respond to this suggestion. Andrew already commented on the response ( http://www.ietf.org/mail-archive/web/spfbis/current/msg04180.html ). I read the two messages from Benoit Claise, as Area Director, (see http://www.ietf.org/mail-archive/web/spfbis/current/msg04156.html and http://www.ietf.org/mail-archive/web/spfbis/current/msg04160.html ). The Area Director asked about changes and provided an example of what he means. I thought that what I suggested was clear. The matter is about how RFCs are written. I read the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg04178.html and I don't see anything relating to how RFCs are written. Regards, S. Moonesamy (as document shepherd) From d3e3e3@gmail.com Fri Sep 13 22:06: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 9AA2711E80E8; Fri, 13 Sep 2013 22:06:15 -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 3G44pvOVyVY7; Fri, 13 Sep 2013 22:06:15 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7D46411E80E0; Fri, 13 Sep 2013 22:06:14 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lj1so3337315pab.15 for ; Fri, 13 Sep 2013 22:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1fGFvAiCKyxqfGNJLZGMEKTk/bYfRkaQdIyHCCmdzHw=; b=KswIloL63gNhnd3vuXdcHycnN/Vjz7zGLfRzg282jWadOgum7AmIKwMI31VepZnBAx ZoQrWrnEMUe0z/7XLh3rXBC9cISvVTSO6zP4MuKiAhw2M0aLkBOAnqTpfDMiawdNhVAV qNSLbLCSigSEGMMvDePrSkvfzHH1u4LcITwcHKgxThjmFFSbfFnLpN4li2vx3+2y224p 04YIRKlzBVb3prYXeOtfaXNCVF5leWnujek6fGdudZv41gdKWiNUhKmIdxzmcaCY7CiF 2R2yO/VpgUa0YVdcPIGcYtcTcbXYn/U9/UuhLvCNABRwyMZ3ohlRvp26oJncFnS+g7og kTdQ== X-Received: by 10.68.196.234 with SMTP id ip10mr17301002pbc.18.1379135174072; Fri, 13 Sep 2013 22:06:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.91.143 with HTTP; Fri, 13 Sep 2013 22:05:54 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20130911060419.0ddb37c8@elandnews.com> From: Donald Eastlake Date: Sat, 14 Sep 2013 01:05:54 -0400 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 13 Sep 2013 22:32:42 -0700 Cc: "secdir@ietf.org" , S Moonesamy , "spfbis@ietf.org" , The IESG , draft-ietf-spfbis-4408bis.all@tools.ietf.org, Phillip Hallam-Baker Subject: Re: [spfbis] [secdir] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 14 Sep 2013 05:06:15 -0000 On Wed, Sep 11, 2013 at 12:35 PM, Murray S. Kucherawy wrote: > On Wed, Sep 11, 2013 at 7:33 AM, Phillip Hallam-Baker > wrote: >> >> On Wed, Sep 11, 2013 at 9:43 AM, Murray S. Kucherawy >> wrote: >>> >>> On Wed, Sep 11, 2013 at 6:22 AM, S Moonesamy >>> wrote: >>>> >>>> I am responding to the comment about DKIM only and wait for the SPFBIS >>>> WG to address the other issues. >>> >>> >>> Was the SecDir review for this draft posted to the spfbis list? I >>> haven't seen it. >> >> >> The draft-ietf-spfbis-4408bis.all@tools.ietf.org doesn't cover it? I >> thought that was the point. > > > I'm pretty sure it's authors, shepherds, and co-chairs only, not the whole > WG. It also includes the sponsoring AD. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From sm@elandsys.com Fri Sep 13 23:04: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 CC62211E80D1 for ; Fri, 13 Sep 2013 23:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 pd2sWX4kP9Ai for ; Fri, 13 Sep 2013 23:04:32 -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 1F17B21F9EC8 for ; Fri, 13 Sep 2013 23:04:32 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.219]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8E64DgM006849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Sep 2013 23:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379138666; bh=/4hIAUPq/wM+mISTXSJ1X4p+fqvgFxfmLG5Wj/p4SMI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qN/p6hF8LHZAVUBhXYOrai78HbhG0yCaafEM/Jv+TETXKivuyvsLUv1dflR9s0QjK rH6sesBv+L35kOVzGZnaTiiDPJJYhauswAmxyINm+grKkuhplh98lD+rAyWOMOe08m gwLAU2Vzpz5uXhJ/zFq0Dad0TYNCxiORukhsgT3w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379138666; i=@elandsys.com; bh=/4hIAUPq/wM+mISTXSJ1X4p+fqvgFxfmLG5Wj/p4SMI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=UreCXqHIqoTXUcKkHbPP2uEf+8hcAHR6Skbx/F8XQGO4Nc/qCmWneXWedcibusa03 mHPtXaZLP4KlLagvE9Hmz773UhHDV71DhEmFJl1D8ZdI6N3DTt13piphkfhpHnPujs yfle11xc00wAiU/4zt3jDJlNMxzIembNZGt/xYn4= Message-Id: <6.2.5.6.2.20130913224030.0cacb170@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 13 Sep 2013 23:01:37 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <38312086.HKzMeyOO04@scott-latitude-e6320> References: <6.2.5.6.2.20130913165239.0be3fed0@elandnews.com> <38312086.HKzMeyOO04@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Pete Resnick , Joe Abley Subject: Re: [spfbis] draft-ietf-spfbis-4408bis-20 review (response size) 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, 14 Sep 2013 06:04:32 -0000 Hi Scott, At 21:25 13-09-2013, Scott Kitterman wrote: >No. > >The point is you can't use the entire 512 [insert term here] for the SPF >record due to potentially other TXT records and DNS message >overhead. The 450 >number is a rule of thumb that was developed to provide a ~safe SPF record >size in the absence of other TXT records. The propose language uses the term >"DNS message" both for the UDP packet size and for the part of that packet >that can be used for an SPF record. > >I strongly object to dropping the 450 recommendation based on no data that >says it's bad (it is in RFC 4408 and no case to remove it has been >recommended). > >All the rambling about IPv6, EDNS0, etc is irrelevant. The point is to keep >the record small enough to make it reliable. > >Even if there was a point in the the change, the language is definitely a >regression from what was there before because it uses the same term for two >different things. There is a message of Joe Abley at http://www.ietf.org/mail-archive/web/ietf/current/msg81862.html Joe was correct in saying that my usage of "UDP message" is incorrect. I did not suggest dropping the "450 recommendation". The text suggested by Douglas Otis was for the second paragraph of Section 3.4. This is not related to IPv6 or EDNS0. The language that was there before is incorrect (see message from Joe Abley). Could you please propose text to address the terminology issue in Section 3.4? Regards, S. Moonesamy (as document shepherd) From spf2@kitterman.com Fri Sep 13 23:20: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 9F7CB11E80D1 for ; Fri, 13 Sep 2013 23:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=-0.056, 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 sYmNnas03jqj for ; Fri, 13 Sep 2013 23:20:51 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BFB6921E804B for ; Fri, 13 Sep 2013 23:20:42 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9226920E40F6; Sat, 14 Sep 2013 02:20:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1379139640; bh=7eXpG5p7o68UW4qyuhmtBNSm4PLBq9vIajVf5vpJMq0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ba+IhV8bZNtg6gHpyLMt6GyzwqqbtJKU9uA4sZcOEfgNDYOZgFmn88izdggI8yMa0 B4hsHq65c0a4wulQYY2wBy5bKiRyOZkAKT/UOUk/Yg+wrqNSZ43k855zij3kH6SrLf 5rjmQEnYGRPxM5KAOyB8rystwZqWcCoS8l4RIuiE= 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 73C6B20E40CB; Sat, 14 Sep 2013 02:20:40 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 14 Sep 2013 02:20:39 -0400 Message-ID: <2137735.9LNiMWPY5V@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130913224030.0cacb170@resistor.net> References: <38312086.HKzMeyOO04@scott-latitude-e6320> <6.2.5.6.2.20130913224030.0cacb170@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: Joe Abley , spfbis-chairs@tools.ietf.org, Pete Resnick , S Moonesamy , Scott Kitterman Subject: Re: [spfbis] draft-ietf-spfbis-4408bis-20 review (response size) 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, 14 Sep 2013 06:20:55 -0000 On Friday, September 13, 2013 23:01:37 S Moonesamy wrote: > Hi Scott, > > At 21:25 13-09-2013, Scott Kitterman wrote: > >No. > > > >The point is you can't use the entire 512 [insert term here] for the SPF > >record due to potentially other TXT records and DNS message > >overhead. The 450 > >number is a rule of thumb that was developed to provide a ~safe SPF record > >size in the absence of other TXT records. The propose language uses the > >term "DNS message" both for the UDP packet size and for the part of that > >packet that can be used for an SPF record. > > > >I strongly object to dropping the 450 recommendation based on no data that > >says it's bad (it is in RFC 4408 and no case to remove it has been > >recommended). > > > >All the rambling about IPv6, EDNS0, etc is irrelevant. The point is to > >keep the record small enough to make it reliable. > > > >Even if there was a point in the the change, the language is definitely a > >regression from what was there before because it uses the same term for two > >different things. > > There is a message of Joe Abley at > http://www.ietf.org/mail-archive/web/ietf/current/msg81862.html Joe > was correct in saying that my usage of "UDP message" is incorrect. > > I did not suggest dropping the "450 recommendation". The text > suggested by Douglas Otis was for the second paragraph of Section > 3.4. This is not related to IPv6 or EDNS0. > > The language that was there before is incorrect (see message from Joe > Abley). > > Could you please propose text to address the terminology issue in Section > 3.4? OK. OLD: 3.4. Record Size The published SPF record for a given domain name SHOULD remain small enough that the results of a query for it will fit within 512 octets. This UDP limit is defined in [RFC1035] section 2.3.4, although it was raised by [RFC2671]. Staying below 512 octets ought to prevent older DNS implementations from failing over to TCP,and will work with UDP in the absence of EDNS0 [RFC6891] support. Since the answer size is dependent on many things outside the scope of this document, it is only possible to give this guideline: If the size of the DNS message, the combined length of the DNS name and the text of all the records of a given type is under 450 octets, then DNS answers ought to fit in UDP packets. Records that are too long to fit in a single UDP packet could be silently ignored by SPF verifiers due to firewall and other issues that interfere with the operation of DNS over TCP or using ENDS0. Note that when computing the sizes for replies to queries of the TXT format, one has to take into account any other TXT records published at the domain name. Similarly, the sizes for replies to all queries related to SPF have to be evaluated to fit in a single 512 octet UDP packet (i.e. DNS message size limited to 450 octects). NEW: 3.4. Record Size The published SPF record for a given domain name SHOULD remain small enough that the results of a query for it will fit within 512 octets. This will keep even older DNS implementations from falling over to TCP. Since the answer size is dependent on many things outside the scope of this document, it is only possible to give this guideline: If the combined length of the DNS name and the text of all the TXT records is under 450 characters, then DNS answers should fit in UDP packets. Note that when computing the sizes for queries of the TXT format, one must take into account any other TXT records published at the domain name. Records that are too long to fit in a single UDP packet MAY be silently ignored by SPF clients. Note: The proposed "NEW" text is largely a reversion to what was in RFC 4408. I think it's shorter, clearer, and resolves the question at hand. Scott K From sm@elandsys.com Sat Sep 14 00:19: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 6CE9B21F9F31 for ; Sat, 14 Sep 2013 00:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.282 X-Spam-Level: X-Spam-Status: No, score=-102.282 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, J_CHICKENPOX_33=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 QPGDZfhQdxqN for ; Sat, 14 Sep 2013 00:19:18 -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 AC7D521F9F2D for ; Sat, 14 Sep 2013 00:19:17 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.219]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8E7J0PE010179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Sep 2013 00:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379143155; bh=nAVeNuxoZCqF4fzaH1Y72tSBSogVppFNKHmcASIPA0Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=E9M8LB3r1C8uXDqPlbtMGmED0uMFWW5bOmxGZwlfrywGAiN8WTCeGK/7H2uE29T4E e2wZfEDbycJleWo5bPUQZ10wzS7YEloykUi1w7TDwQpZ9CEe9YzpKJK4x+Ui8JvN77 qY0sy7Oc0HY0xYU2R4QV2Yb2F+ncAPcXeeztXWCE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379143155; i=@elandsys.com; bh=nAVeNuxoZCqF4fzaH1Y72tSBSogVppFNKHmcASIPA0Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=aI+UkYG9jD8Fpqfxxuzjy25Nwnll7+ROE33vLD0OTgu6j3ZlSql+VyIMizrjzhA1W ct8fJXf60/dh8EYyYQtsdkMWMC86Uy2pzOHS+amgJOTcGXV0EapxaeoVOx+8m3Syz/ l7oXmNdUk00QLLPWwVhJLFN3NE8/RdcC6HPb1Urw= Message-Id: <6.2.5.6.2.20130913234837.0beb6178@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 14 Sep 2013 00:18:42 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <2137735.9LNiMWPY5V@scott-latitude-e6320> References: <38312086.HKzMeyOO04@scott-latitude-e6320> <6.2.5.6.2.20130913224030.0cacb170@resistor.net> <2137735.9LNiMWPY5V@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Pete Resnick Subject: Re: [spfbis] draft-ietf-spfbis-4408bis-20 review (response size) 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, 14 Sep 2013 07:19:19 -0000 Hi Scott, At 23:20 13-09-2013, Scott Kitterman wrote: >OLD: > >3.4. Record Size > > The published SPF record for a given domain name SHOULD remain small > enough that the results of a query for it will fit within 512 octets. > This UDP limit is defined in [RFC1035] section 2.3.4, although it was > raised by [RFC2671]. Staying below 512 octets ought to prevent older > DNS implementations from failing over to TCP,and will work with UDP > in the absence of EDNS0 [RFC6891] support. Since the answer size is > dependent on many things outside the scope of this document, it is > only possible to give this guideline: If the size of the DNS message, > the combined length of the DNS name and the text of all the records > of a given type is under 450 octets, then DNS answers ought to fit in > UDP packets. Records that are too long to fit in a single UDP packet > could be silently ignored by SPF verifiers due to firewall and other > issues that interfere with the operation of DNS over TCP or using > ENDS0. > > Note that when computing the sizes for replies to queries of the TXT > format, one has to take into account any other TXT records published > at the domain name. Similarly, the sizes for replies to all queries > related to SPF have to be evaluated to fit in a single 512 octet UDP > packet (i.e. DNS message size limited to 450 octects). > >NEW: > >3.4. Record Size > > The published SPF record for a given domain name SHOULD remain small > enough that the results of a query for it will fit within 512 octets. > This will keep even older DNS implementations from falling over to > TCP. Since the answer size is dependent on many things outside the > scope of this document, it is only possible to give this guideline: > If the combined length of the DNS name and the text of all the > TXT records is under 450 characters, then DNS answers should fit in UDP > packets. > > Note that when computing the sizes for queries of the TXT format, one must > take into account any other TXT records published at the domain name. > Records that are too long to fit in a single UDP packet MAY be silently > ignored by SPF clients. > >Note: The proposed "NEW" text is largely a reversion to what was in >RFC 4408. >I think it's shorter, clearer, and resolves the question at hand. My recollection of the working group discussion about the RFC 4408 text is that the usage of "characters" in the text is incorrect. There was also a discussion (if I recall correctly) about RFC 2119 key words which led to the "MAY" being dropped. The discussion which led to EDNS0 being included is related to issue #24. The reversion might be a substantive change. I would prefer to avoid that as it can raise process questions. The issue is about the incorrect usage of technical terms. I suggest addressing that instead of having a substantive change. What I have taken into consideration is not to revisit issues which have been resolved and not to open the way for new issues at this stage when it is likely that the work is nearly complete. Regards, S. Moonesamy (as document shepherd) From sm@elandsys.com Sat Sep 14 13:27: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 5ADAC21E80E8 for ; Sat, 14 Sep 2013 13:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 1jyue4zUTXgf for ; Sat, 14 Sep 2013 13:27: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 AFA5621E80C8 for ; Sat, 14 Sep 2013 13:27:36 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.134.26]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8EKRNsP007279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Sep 2013 13:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379190455; bh=NoMdvwDZwsWMuba7kI+3Un0G0imI7yhrQlEi9jWH6hg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=A89c+zMOavBN9CliChG4QYaQ3VSsnR5lrns8JFSckbwhSkgeycuedn8jbhpS4B/du nv6Qmq65RDbWnCiQamwJ3jVb20PtIMssDEgBjll5Fj5IMJwtLk7zG6Vz1dkT4eJ6Nk yRoqQUgIYcThgq6/SPru8fI3WdiuFrTcMPufGW1Q= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379190455; i=@elandsys.com; bh=NoMdvwDZwsWMuba7kI+3Un0G0imI7yhrQlEi9jWH6hg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Fnxqgezn2PNhgkgeoDTnVMb/q8eUeMFXiX/B0BfHSN2kdTLT5oziHh/8K9iPB3ccu RLMlDNIp5FtXS8rIlDeY1Qi+IRsTma13KTAwaTffsppism1yxsxlhVXupEFFGgw4FD 2bvILPI3m2hI5iQlrLmDijye05XSWbUufDO9v4K0= Message-Id: <6.2.5.6.2.20130914130938.0b9416f8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 14 Sep 2013 13:20:53 -0700 To: R.E.Sonneveld@sonnection.nl From: S Moonesamy In-Reply-To: <523179E7.6090207@sonnection.nl> References: <5230A523.20504@isdg.net> <6.2.5.6.2.20130911134838.0c217ca8@resistor.net> <2297109.DlIYn73fZN@scott-latitude-e6320> <523179E7.6090207@sonnection.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 14 Sep 2013 20:27:38 -0000 Hi Rolf, At 01:23 12-09-2013, Rolf E. Sonneveld wrote: >To avoid confusion it's better not to mention a whole list of >possible names/aliases in this Definition paragraph. > >May I suggest the following text: Thanks for suggesting text. I'll comment below. >1.1.3. MAIL FROM Definition > > This document is concerned with the identity of the sender of a > mail message, as referred to in [RFC5321]: > > "The transaction starts with a MAIL command that gives the > sender identification." > >. Since there are many other names for this identity, it is > important to choose a name that is: > > 1. commonly used > 2. well defined > > As such, throughout this document the term "MAIL FROM" will be used, > which is defined as the RFC5321.MailFrom identity described in [RFC5598]. The issue raised in the SecDir review [1] is "the referenced specs do not give an explicit definition for the term as used and the references point to the whole spec rather than a particular section". The suggested text (see above) does not address that in my opinion. The question being asked is what is the definition for "MAIL FROM". The first sentence in your comment explains what can cause confusion. Regards, S. Moonesamy (as document shepherd) 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg04110.html From sm@elandsys.com Sat Sep 14 13:27: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 2A0AA21E8116 for ; Sat, 14 Sep 2013 13:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 n4bqBqjFxYf8 for ; Sat, 14 Sep 2013 13:27:41 -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 BB1BD21E80F1 for ; Sat, 14 Sep 2013 13:27:41 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.134.26]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8EKRNsR007279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Sep 2013 13:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379190460; bh=KZ8jmSGGo+sjqi/Vf5/AgN5lyKJzTh5kVBuwafMyGMk=; h=Date:To:From:Subject:Cc; b=1mxEmNxQDQXHkLCoQala8AjQZbjkmHevF7TyqxHMUvowaGfEnFFU47nDohLJl1cTY d/D4Uyr/NC+WB8oev1LvXGevLbOoAqufAtG/647eN4IZFRRqdu4kHLIhnFgrXdR81z Y66l7iMxdkrRD+FpDTVUJTyVS85+VO7YZyz0g8jQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379190460; i=@elandsys.com; bh=KZ8jmSGGo+sjqi/Vf5/AgN5lyKJzTh5kVBuwafMyGMk=; h=Date:To:From:Subject:Cc; b=MnTCLlm3ZxkBU2AmG39Mb7CwtsgHK0WfvtyZmKwUup6BQNnRNz4szAZEWZl1w1WEy Rrsuay9tDBRKHOsy4wkPih6JOZVcYCCdMRsDth0DblSu7rQNDjAebRfsSK6rK+JIiP sojGey+jkC3w9qutjDD8NMf6uCzoHKGHoiQzz2NI= Message-Id: <6.2.5.6.2.20130914132134.0de8f490@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 14 Sep 2013 13:26:11 -0700 To: Scott Kitterman From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Pete Resnick Subject: [spfbis] Addressing IESG 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: Sat, 14 Sep 2013 20:27:42 -0000 Hi Scott, There were several comments from the IESG Evaluation: Sean Turner commented in Section 11.3 (see http://www.ietf.org/mail-archive/web/spfbis/current/msg04159.html ). Are you okay with the change? There wasn't any response to the comment from Stephen Farrell (see http://www.ietf.org/mail-archive/web/spfbis/current/msg04158.html ). Could you please provide a reply? I'll discuss the comment from Benoit Claise with Pete Resnick. Thanks, S. Moonesamy (as document shepherd) From spf2@kitterman.com Sat Sep 14 14:04:48 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 3940A21E80FA for ; Sat, 14 Sep 2013 14:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.247, 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 sHMWzZlPGHFo for ; Sat, 14 Sep 2013 14:04:43 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id C092121E81C5 for ; Sat, 14 Sep 2013 14:04:43 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id ECC7BD04089; Sat, 14 Sep 2013 17:04:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1379192683; bh=U2oLaS803kjzVSRFEh/jbjyZ3CJIvyzCyhplGrNOCfw=; h=In-Reply-To:References:Subject:From:Date:To:CC:From; b=NtQgQEha980NdGth/+7fKnprsSl1M43rQG0Co2yq57CbcTZr+gPJjNh8f2pt9HODA zzb3Drc4q9NmDXhG/0TZMUqmmjNURhUImBOg6HAT94jROcTrsUlIOHbjOQ/QLZxCX1 yeygOwLgXyp8UQEYbXH4l1zM0Alidf1D19jEhgIM= Received: from [192.168.111.3] (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 9032CD0401E; Sat, 14 Sep 2013 17:04:42 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20130914132134.0de8f490@elandnews.com> References: <6.2.5.6.2.20130914132134.0de8f490@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sat, 14 Sep 2013 17:05:05 -0400 To: S Moonesamy Message-ID: X-AV-Checked: ClamAV using ClamSMTP Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Pete Resnick Subject: Re: [spfbis] Addressing IESG 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: Sat, 14 Sep 2013 21:04:48 -0000 S Moonesamy wrote: >Hi Scott, > >There were several comments from the IESG Evaluation: > >Sean Turner commented in Section 11.3 (see >http://www.ietf.org/mail-archive/web/spfbis/current/msg04159.html >). Are you okay with the change? > >There wasn't any response to the comment from Stephen Farrell (see >http://www.ietf.org/mail-archive/web/spfbis/current/msg04158.html >). Could you please provide a reply? > >I'll discuss the comment from Benoit Claise with Pete Resnick. There are several sets of comments to review. I've had almost no time for this since I pushed out -20. I'll review them all by Monday at the latest. Scott K From R.E.Sonneveld@sonnection.nl Sat Sep 14 15:05: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 393F311E810F for ; Sat, 14 Sep 2013 15:05:04 -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=[AWL=-0.000, 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 NtUUrZXZeUTZ for ; Sat, 14 Sep 2013 15:04:59 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 7251321E804C for ; Sat, 14 Sep 2013 15:04:57 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3ccnnc64Knz1L8fb; Sun, 15 Sep 2013 00:04:52 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3ccnnc4Zxvz1L8fV; Sun, 15 Sep 2013 00:04:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 8CDE812315A; Sun, 15 Sep 2013 00:04:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Mms8Zy05IMzn; Sun, 15 Sep 2013 00:04:42 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 0B8401230A0; Sun, 15 Sep 2013 00:04:42 +0200 (CEST) Message-ID: <5234DD79.4010407@sonnection.nl> Date: Sun, 15 Sep 2013 00:04:41 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: S Moonesamy References: <5230A523.20504@isdg.net> <6.2.5.6.2.20130911134838.0c217ca8@resistor.net> <2297109.DlIYn73fZN@scott-latitude-e6320> <523179E7.6090207@sonnection.nl> <6.2.5.6.2.20130914130938.0b9416f8@resistor.net> In-Reply-To: <6.2.5.6.2.20130914130938.0b9416f8@resistor.net> Content-Type: multipart/alternative; boundary="------------040601060400000809080905" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1379196292; bh=M1+7ZKZTyObvium7OIsa/Egj/XoXF70fztKIzGyDpZo=; h=Message-ID:Date:From:To:Subject:From; b=O89sB7io3hSrZ3IOqVye3B8BaFh1cceRnhAllP4NW38YTtpB83iCbkPgLLgHGApjd dxjFhwNtjyisEM91Tx/RQJ/0QlX9XhrDAtU3rj8yp8NXkxZrsSvKvhqDRuhXuZ5YdD DYgsl1JtqdNBpEp29KnwmFIYzKx1HucYXlKAyqgQ= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3ccnnc64Knz1L8fb Cc: spfbis@ietf.org Subject: Re: [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 22:05:06 -0000 This is a multi-part message in MIME format. --------------040601060400000809080905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, SM, On 09/14/2013 10:20 PM, S Moonesamy wrote: > Hi Rolf, > At 01:23 12-09-2013, Rolf E. Sonneveld wrote: >> To avoid confusion it's better not to mention a whole list of >> possible names/aliases in this Definition paragraph. >> >> May I suggest the following text: > > Thanks for suggesting text. I'll comment below. > >> 1.1.3. MAIL FROM Definition >> >> This document is concerned with the identity of the sender of a >> mail message, as referred to in [RFC5321]: >> >> "The transaction starts with a MAIL command that gives the >> sender identification." >> >> . Since there are many other names for this identity, it is >> important to choose a name that is: >> >> 1. commonly used >> 2. well defined >> >> As such, throughout this document the term "MAIL FROM" will be used, >> which is defined as the RFC5321.MailFrom identity described in >> [RFC5598]. > > The issue raised in the SecDir review [1] is "the referenced specs do > not give an explicit definition for the term as used and the > references point to the whole spec rather than a particular section". > The suggested text (see above) does not address that in my opinion. > The question being asked is what is the definition for "MAIL FROM". > The first sentence in your comment explains what can cause confusion. I intentionally did not refer to a specific paragraph within the referenced specs, as new versions of those referenced specs might invalidate the references in this spfbis document. Granted, chances that RFC5321 and/or RFC5598 will become obsoleted by newer versions are small, so here's an attempt to address part of the raised issue: 1.1.3. MAIL FROM Definition This document is concerned with the identity of the sender of a mail message, as referred to in par. 3.3 of [RFC5321]: "The transaction starts with a MAIL command that gives the sender identification." . Since there are many other names for this identity, it is important to choose a name that is: 1. commonly used 2. well defined As such, throughout this document the term "MAIL FROM" will be used, which is defined as the RFC5321.MailFrom identity, described in par. 4.1.4 of [RFC5598]. I'm not sure I agree with the SecDir review re. "the referenced specs do not give an explicit definition for the term as used [...]', as RFC5598 par. 4.1.4 describes the RFC5321.MailFrom identity quite well: RFC5321 .MailFrom: Set by - Originator This field is an end-to-end string that specifies an email address for receiving return control information, such as returned messages. [...] Regards, /rolf --------------040601060400000809080905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi, SM,

On 09/14/2013 10:20 PM, S Moonesamy wrote:
Hi Rolf,
At 01:23 12-09-2013, Rolf E. Sonneveld wrote:
To avoid confusion it's better not to mention a whole list of possible names/aliases in this Definition paragraph.

May I suggest the following text:

Thanks for suggesting text.  I'll comment below.

1.1.3.  MAIL FROM Definition

   This document is concerned with the identity of the sender of a
   mail message, as referred to in [RFC5321]:

       "The transaction starts with a MAIL command that gives the
       sender identification."

.  Since there are many other names for this identity, it is
   important to choose a name that is:

   1. commonly used
   2. well defined

   As such, throughout this document the term "MAIL FROM" will be used,
   which is defined as the RFC5321.MailFrom identity described in [RFC5598].

The issue raised in the SecDir review [1] is "the referenced specs do not give an explicit definition for the term as used and the references point to the whole spec rather than a particular section".  The suggested text (see above) does not address that in my opinion.  The question being asked is what is the definition for "MAIL FROM".  The first sentence in your comment explains what can cause confusion.

I intentionally did not refer to a specific paragraph within the referenced specs, as new versions of those referenced specs might invalidate the references in this spfbis document. Granted, chances that RFC5321 and/or RFC5598 will become obsoleted by newer versions are small, so here's an attempt to address part of the raised issue:

1.1.3.  MAIL FROM Definition

   This document is concerned with the identity of the sender of a
   mail message, as referred to in par. 3.3 of [RFC5321]:

       "The transaction starts with a MAIL command that gives the
       sender identification."

.  Since there are many other names for this identity, it is
   important to choose a name that is:

   1. commonly used
   2. well defined

   As such, throughout this document the term "MAIL FROM" will be used,
   which is defined as the RFC5321.MailFrom identity, described in par. 4.1.4 of [RFC5598].

I'm not sure I agree with the SecDir review re. "the referenced specs do not give an explicit definition for the term as used [...]', as RFC5598 par. 4.1.4 describes the RFC5321.MailFrom identity quite well:

   RFC5321.MailFrom:  Set by - Originator

      This field is an end-to-end string that specifies an email address
      for receiving return control information, such as returned
      messages. [...]

Regards,
/rolf
--------------040601060400000809080905-- From sm@elandsys.com Sat Sep 14 23:37: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 AB7CD21F9E76 for ; Sat, 14 Sep 2013 23:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 0cwdkBPsfHPE for ; Sat, 14 Sep 2013 23:37:35 -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 0C14B21E80A3 for ; Sat, 14 Sep 2013 23:37:30 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.134.26]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8F6b8OA001278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Sep 2013 23:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379227042; bh=NnVLuOufjUbN3qJuCB3VNAZA9XjNGCSxxnePI+/A00o=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=nyYZ/oD/t0O0X/VT+JVCnAI5NuYku7ry40BZHac2h01s4kdQUDFNwzVD4zNe11/Ol 1MXrxjJbZeEiqQAoWBFBI2UyOmClXv5S0HvztRjMJNgXB2VnUbCz7l6KYdTQnJJG8V iJ4JUsfu88CJoQFTCHg28l6lKgSmd5S7C2TKVCKo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379227042; i=@elandsys.com; bh=NnVLuOufjUbN3qJuCB3VNAZA9XjNGCSxxnePI+/A00o=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xi4jpbHjGfmJvzI4hioIIPhUzgEwp/vonxKCsDAVKoMfDTZsXX9jRAb9+vYcReoVR L6Acp1aKwaVON/0GXSj2vQwH8tWUBfHKQTs3EzP/b2M49q9mUxN/R/JO4hcOk/JPLU hjVA3s1IGPONnQU6/e+qz0mU8Klwnuhl6dwcgVso= Message-Id: <6.2.5.6.2.20130914224708.0c8d4af0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 14 Sep 2013 23:21:35 -0700 To: R.E.Sonneveld@sonnection.nl From: S Moonesamy In-Reply-To: <5234DD79.4010407@sonnection.nl> References: <5230A523.20504@isdg.net> <6.2.5.6.2.20130911134838.0c217ca8@resistor.net> <2297109.DlIYn73fZN@scott-latitude-e6320> <523179E7.6090207@sonnection.nl> <6.2.5.6.2.20130914130938.0b9416f8@resistor.net> <5234DD79.4010407@sonnection.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 15 Sep 2013 06:37:36 -0000 Hi Rolf, At 15:04 14-09-2013, Rolf E. Sonneveld wrote: >I intentionally did not refer to a specific paragraph within the >referenced specs, as new versions of those referenced specs might >invalidate the references in this spfbis document. Granted, chances >that RFC5321 and/or RFC5598 will become obsoleted by newer versions >are small, so here's an attempt to address part of the raised issue: Ok. >1.1.3. MAIL FROM Definition > > This document is concerned with the identity of the sender of a > mail message, as referred to in par. 3.3 of [RFC5321]: > > "The transaction starts with a MAIL command that gives the > sender identification." > >. Since there are many other names for this identity, it is > important to choose a name that is: > > 1. commonly used > 2. well defined > > As such, throughout this document the term "MAIL FROM" will be used, > which is defined as the RFC5321.MailFrom identity, described in > par. 4.1.4 of [RFC5598]. > >I'm not sure I agree with the SecDir review re. "the referenced >specs do not give an explicit definition for the term as used >[...]', as RFC5598 par. 4.1.4 describes the RFC5321.MailFrom >identity quite well: > > > RFC5321.MailFrom: Set by - Originator > > This field is an end-to-end string that specifies an email address > for receiving return control information, such as returned > messages. [...] I'll adapt your proposed text as follows: 1.1.3. MAIL FROM Definition This document uses "MAIL FROM" to refer to RFC5321.MailFrom (reverse-path). The RFC5321.MailFrom is defined in Section 4.4 of RFC 5598 as an end-to-end string that specifies an email address for receiving return control information, such as returned messages. I inserted the word "reverse-path" because of Section 2.4. If you are okay with the above I'll use it to respond to the SecDir review. Regards, S. Moonesamy From ajs@anvilwalrusden.com Sun Sep 15 14:36: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 C16F111E81FD for ; Sun, 15 Sep 2013 14:36:02 -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 aGdtBE556o0G for ; Sun, 15 Sep 2013 14:35:57 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id F313E11E81F8 for ; Sun, 15 Sep 2013 14:35:56 -0700 (PDT) Received: from mx1.yitter.info (d-173-44-101-71.cpe.metrocast.net [173.44.101.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 5E9498A031 for ; Sun, 15 Sep 2013 21:35:55 +0000 (UTC) Date: Sun, 15 Sep 2013 17:36:04 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130915213604.GB78902@mx1.yitter.info> References: <6.2.5.6.2.20130913152347.0c874cb8@elandnews.com> <20130914001204.GB78680@mx1.yitter.info> <72C262F1-0715-499D-948F-989A9A007824@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72C262F1-0715-499D-948F-989A9A007824@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] draft-ietf-spfbis-4408bis-20 review (response size) 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, 15 Sep 2013 21:36:02 -0000 No hat. On Fri, Sep 13, 2013 at 05:34:41PM -0700, Douglas Otis wrote: > > I did not recommend this value, but I did say it sounded like reasonable advice. There is exactly one historic built-in limit to the DNS for UDP packets, and that is 512 octets. Lots of middleboxes drop UDP packets on port 53 larger than 512 octets. Many equipment manufacturers have shipped equipment that, by default, drops packets over 512 octets on port 53. The 512 octets does not apply to TCP. If it did, zone transfers would be impossible. Everything else -- all the noise about MTUs and so on -- is rank speculation. There's _all kinds_ of breakage out there with large MTU sizes. Heck, some of the CGNs appear to end up with real MTUs across the network way below any threshold we're discussing. But this document should not be a general purpose document about all the possible ways this protocol could interact with everything else everywhere on the Internet. This is a protocol document. As I have said several times, if someone wants to write an operational guidance document, I have no objection. But the protocol document shouldn't be providing that, at least in detail. It is arguably already too heavy in that direction. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Sun Sep 15 14:38:40 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 7F59D21F9EE9 for ; Sun, 15 Sep 2013 14:38: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 ZGB06YlirhGP for ; Sun, 15 Sep 2013 14:38:34 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id ADA1211E81F9 for ; Sun, 15 Sep 2013 14:38:31 -0700 (PDT) Received: from mx1.yitter.info (d-173-44-101-71.cpe.metrocast.net [173.44.101.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 425C78A031; Sun, 15 Sep 2013 21:38:11 +0000 (UTC) Date: Sun, 15 Sep 2013 17:38:20 -0400 From: Andrew Sullivan To: Scott Kitterman Message-ID: <20130915213820.GC78902@mx1.yitter.info> References: <38312086.HKzMeyOO04@scott-latitude-e6320> <6.2.5.6.2.20130913224030.0cacb170@resistor.net> <2137735.9LNiMWPY5V@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2137735.9LNiMWPY5V@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Pete Resnick , S Moonesamy , Joe Abley Subject: Re: [spfbis] draft-ietf-spfbis-4408bis-20 review (response size) 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, 15 Sep 2013 21:38:40 -0000 On Sat, Sep 14, 2013 at 02:20:39AM -0400, Scott Kitterman wrote: > > NEW: > TXT records is under 450 characters, then DNS answers should fit in UDP s/characters/octets, or even "ASCII characters" if you must. "Characters" in the UTF-8 era is just too loaded a word. Otherwise, no objection here. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Mon Sep 16 07:41: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 CF30C21F9983 for ; Mon, 16 Sep 2013 07:41:33 -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 GPTIej4+V1r7 for ; Mon, 16 Sep 2013 07:41:29 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id F2B7021F9A5F for ; Mon, 16 Sep 2013 07:41:24 -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 0704E8A031 for ; Mon, 16 Sep 2013 14:41:24 +0000 (UTC) Date: Mon, 16 Sep 2013 10:41:35 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130916144135.GC79031@mx1.yitter.info> References: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130912065558.0b960550@elandnews.com> <5231D5E5.5070407@cisco.com> <6.2.5.6.2.20130912080503.0c90f9d0@elandnews.com> <18A91BEE-6360-4E1F-9B08-5E45C5217694@gmail.com> <20130914003652.GF78680@mx1.yitter.info> 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] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 16 Sep 2013 14:41:34 -0000 I've trimmed the ccs. This is clearly right back to fodder for the spfbis list. If I have a hat on below, I'll note it. On Fri, Sep 13, 2013 at 08:56:55PM -0700, Douglas Otis wrote: > In my defense, may I ask whether the draft > http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-01 been > reviewed? By me? Yes. Widely? Apparently not. > It contains a reference to a survey by the SPF website > http://spf-all.com/stats.html which indicates of all domains > publishing SPF records 99.947% contain no macros. It seems a > reasonable person would wonder why. Yes, and it is entirely reasonable that anyone might. But it doesn't matter, because there's half a percent that _do_ have macros, and SM and I (as chairs) already determined earlier in the WG's life that "unused" meant "not used at all". Therefore, macros cannot be deprecated by the WG. That's a consequence of our charter. > I hope you can imagine what this might mean from the perspective of > network amplifications I am somewhat conversant with network amplifications via DNS. It is interesting to me that, despite the attractive nuisance that DNS provides in terms of amplifications, for reasons totally mysterious to me I have never once, in any log I have reviewed, seen evidence of an SPF-based attack of the sort you keep talking about. That is not to say that your observations are wrong: SPF clearly provides an extremely useful attack vector. But I find it interesting that SPF does not appear to be central. This is quite possibly because mounting the SPF based attack you're talking about requires considerably more co-ordination among the moving parts than straightforward amplification via plain DNS spoofing. (I could come up with some other explanations, of equivalent degree of rank speculation if you'd like, but I think one such speculation is enough for these purposes.) > At the same time, it seems irresponsible to completely deprecate use > of the dedicated RR record type that had a much higher level of use > while not deprecating a far more dangerous macro option used by far > fewer domains. Such an oversight can not be excused by blaming the > charter. With my chair hat on: the reason RRTYPE 99 is deprecated is _not_ because it's unused, but because there is an interoperability problem in RFC 4408. We _had to_ do something, in order to move the protocol to the standards track, because a standards track document needs to have no such known and unaddressed flaws. The same is _not_ true of the options you're talking about: they may have some negative consequences, but those consequences are called out in the document. The WG was chartered on the condition, in effect, that it not change SPF unless something was totally broken or actually unused. Since you note, in your message, that macros and so on _are_ in fact used, and since there is no analagous problem with the specification _per se_ as there was in the case of the DNS RRTYPEs, we are not free to deprecate as you appear to want. I am pretty sure that has been explained on list more than once. If it is even remotely unclear to you, I suggest you contact me off list so that I can explain it in a way you can understand it. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Mon Sep 16 09:05: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 2724311E82E5; Mon, 16 Sep 2013 09:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 52E8og5o+lKI; Mon, 16 Sep 2013 09:04:56 -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 0BCF111E8127; Mon, 16 Sep 2013 09:02:53 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.146.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8GG2G85011670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Sep 2013 09:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379347355; bh=TUgWM+on/TxAY26GEe5jZtR1nxfw9oWUIGRm13KK3X0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=iUD6fKc1cMSGSGnLutJBTApaC/nVUVDbg6XPC5UUOBNXOFvdPCKLkBs8emzi30ZWk IZU3KPreJ091i3SrGHnSP+fSy5rvw0jE6Dl5rpkyFfJkApCsHVO+MBBUCcHCH8LJwx 0IMK+2JP+0XXA1YeNgelTLIyNnI8ddcuwJQMGa7c= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379347355; i=@elandsys.com; bh=TUgWM+on/TxAY26GEe5jZtR1nxfw9oWUIGRm13KK3X0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Yd7DiYssq1aQR9C+dsSZPyW2wuQNnC4AX8UDPaLoE2RPQwIZjIwalLgmdcYXdWZZZ UyGOd0l3G9kU07I850kUhwUeD98kFxeX6YaLPwYO1JAUlednUkwt74mhL3Yez9BdUS utnTmB64rBSPyTxLkJWycGPAJ+3xMIFbG/81MXH8= Message-Id: <6.2.5.6.2.20130916014542.0b496658@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 16 Sep 2013 09:00:22 -0700 To: Douglas Otis From: S Moonesamy In-Reply-To: <6FC7A544-0AB5-4BC0-A0BF-D0D8D740D3B8@gmail.com> References: <6FC7A544-0AB5-4BC0-A0BF-D0D8D740D3B8@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Pete Resnick , ietf@ietf.org, Scott Kitterman Subject: [spfbis] Macro Expansion (was: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard) 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, 16 Sep 2013 16:05:13 -0000 Hi Doug, At 21:55 11-09-2013, Douglas Otis wrote: >Add to: >11.5.3. Macro Expansion >,--- >It is not within SPF's purview whether IPv6 or DNSSEC is being >used. IPv6 (RFC2460) increased the minimum MTU size to 1280 >octets. DNSSEC is deployed with EDNS0 (RFC6891) to avoid TCP >fallback. EDNS0 suggests an MTU increase between 1280 and 1410 >octets offers a reasonable result starting from a request of 4096 >octets. A 1410 MTU offers a 2.4 times payload increase over the >assumed MTU of 576 octets and is widely supported by Customer >Premise Equipment. With increased MTUs being used with DNS over >UDP, network amplification concerns increase accordingly. > >SPF macros can utilize SPF parameters derived from email messages >that can modulate the names being queried in several ways without >publishing additional DNS resources. The SPF macro feature permits >malefactors a means to covertly orchestrate directed DDoS attacks >from an array of compromised systems while expending little of their >own resources. > >Since SPF does not make use of a dedicated resource record type or >naming convention, this leaves few solutions available to DNS >operations in offering a means to mitigate possible abuse. This >type of abuse becomes rather pernicious when used in conjunction >with synthetic domains now popular for tracking users without using >web cookies. > >However, email providers can mitigate this type of abuse by ignoring >SPF records containing macros. Very few domains make use of macros, >and ignoring these records result in neutral handling. Some large >providers have admitted they make use of this strategy without >experiencing any notable problem. AOL began their support of SPF by >saying they would use SPF to construct whitelists prior to receipt >of email. Clearly, such whitelisting practices tends to preclude >benefits derived from macro use. >'--- As background information I read draft-otis-spfbis-macros-nixed-01. I read the messages where EDNS0 was mentioned [1]. I read the messages on the thread starting with msg-id: 9884B9CD-0ED3-4D89-A100-58D05EA4BC98@gmail.com. I have followed the discussions about macros ever since the SPFBIS WG was chartered. The above suggestion is to add text in the Security Considerations section of the draft. The problem being pointed out is, in simple terms, DNS amplification. The first (quoted) paragraph argues that there can be an acute problem because of EDNS0 as specified in the Internet Standard. The second paragraph starts with SPF macros can utilize SPF parameters derived from email messages". I do not understand that. From what I understand the rest of the second (quoted) paragraph argues that the SPF macro feature permits evildoers to use it as an attack vector. The argument in the third (quoted) paragraph is that it is not possible to mitigate possible (DNS) abuse due to the SPF as it does not have a dedicated resource record type. The fourth (quoted) paragraph argues that macros should be ignored. That paragraph also mentions that some large providers admitted to using that strategy. I am not aware of any public reports about that. I read draft-otis-spfbis-macros-nixed-01 again to try and understand the problem. It seems to be the: '{%l}._spf.{%d} or exists:{%i}_spf.{%d} can be used in "specialized" DNS servers able to understand encrypted local-parts' which is discussed in Appendix E of draft-ietf-spfbis-4408bis-20. Arthur Thisell commented about the "specialized DNS server". He mentioned that at the time that text was written two people came forward to say that they were doing that. During the SPFBIS discussions nobody stated that he or she has implemented or is using a "specialized" DNS server. I'll ask the person editing draft-ietf-spfbis-4408bis or the SPFBIS WG to provide some publicly verifiable cases where these examples are used. I assume that the SPFBIS WG and the Responsible Area Director have understood the mathematics relating to EDNS0 and DNS amplification. Anyone who has not understood that part is welcome to raise the issue on the SPFBIS mailing list. The discussion about the "dedicated resource record type" has led to agreement. I'll describe the agreement as something people can live with. In my opinion it is better not to start another discussion about that. I hope that what I wrote above clearly explains what I have understood and what I have not understood. Regards, S. Moonesamy (as document shepherd) 1. message-id of messages: 4EF10B1F.5050406@mail-abuse.org 4F0E7154.4080208@isdg.net 29fba028-5881-4a04-95d4-227582a3801e@email.android.com Pine.GSO.4.62.1201121350550.3388@spaz.oit.wmich.edu 20120425152326.GE60024@mail.yitter.info 1545953.Y9VaoKsXxF@scott-latitude-e6320 20120704015156.GB12452@crankycanuck.ca 1977893.MDoye0cYQa@scott-latitude-e6320 20130122231357.GA6921@mx1.yitter.info 3896517.k8tBVMT4Fi@scott-latitude-e6320 CD246081.BBD2F%fmartin@linkedin.com 20130123010120.GC7073@crankycanuck.ca 271785100.KEZggNLeh1@scott-latitude-e6320 CAL0qLwaW1-dQg-NhwBNWAppXjfsoacO1Q8gHdPPvEGDssEpJQA@mail.gmail.com 20130125143603.GA11573@mx1.yitter.info 7ab574aa-d13c-44e2-968e-4946bd05808c@email.android.com 20130430103940.GB32695@besserwisser.org 517FBBCD.3010001@tana.it 20130624212511.GB44803@crankycanuck.ca 686233851.4iQopu4Yll@scott-latitude-e6320 24624534.FuUVENZpXd@scott-latitude-e6320 24624534.FuUVENZpXd@scott-latitude-e6320 B8983E88-14A1-4741-99ED-F43962B2497A@gmail.com BA4D9B3E-F9A6-46AF-BBA7-D6AD463020CA@gmail.com 5129719.PDZTiHcDZ6@scott-latitude-e6320 BD926F72-A6C3-4F0B-BBFB-A18668C9E4AF@gmail.com 38312086.HKzMeyOO04@scott-latitude-e6320 2137735.9LNiMWPY5V@scott-latitude-e6320 From superuser@gmail.com Mon Sep 16 12:05: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 8EDEC11E834A for ; Mon, 16 Sep 2013 12:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 NLQDvUlSMrwi for ; Mon, 16 Sep 2013 12:05:26 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 98F6611E8305 for ; Mon, 16 Sep 2013 12:03:48 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t60so4141500wes.28 for ; Mon, 16 Sep 2013 12:03:44 -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=Y3cXCNpzM/JZMwfKXaMX3KFJRlgsEPV4c7Zt4AmAwGs=; b=B/Hs6u9M5qIfVogHyOLVVFbVVKfC6gGnT+e/mLA/oCRc93hgkX3X9JHKQVY62Rjqmv q2R+16miHG1dNa1bLwT/Nae56H9irER/TLGgyq2LNph+Fdnsmo2dam9b63W933k/glHu HZD3F744lIuBrIdh6avbvZCn5wJvMveY8phF0ok1qWQlAg0Czqs9lD7I36SaYi3e3XzH q3Af+gc481Y8xnOyFFjo7+vjaGE6Bcz/D5gsoUoS/U4U6Q2N2cHt4yCJnwqn82y02RvG gO3/s/4ZC8WXqO0qIoSq22RZygzvU6k3cCzztXmzWdUro9PkMzzTKZgpouXMhuFad0q3 isSw== MIME-Version: 1.0 X-Received: by 10.180.184.107 with SMTP id et11mr14740134wic.60.1379358224640; Mon, 16 Sep 2013 12:03:44 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Mon, 16 Sep 2013 12:03:44 -0700 (PDT) In-Reply-To: <20130916144135.GC79031@mx1.yitter.info> References: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130912065558.0b960550@elandnews.com> <5231D5E5.5070407@cisco.com> <6.2.5.6.2.20130912080503.0c90f9d0@elandnews.com> <18A91BEE-6360-4E1F-9B08-5E45C5217694@gmail.com> <20130914003652.GF78680@mx1.yitter.info> <20130916144135.GC79031@mx1.yitter.info> Date: Mon, 16 Sep 2013 12:03:44 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11c227eeff737604e684dcf4 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 16 Sep 2013 19:05:27 -0000 --001a11c227eeff737604e684dcf4 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 16, 2013 at 7:41 AM, Andrew Sullivan wrote: > > In my defense, may I ask whether the draft > > http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-01 been > > reviewed? > > By me? Yes. Widely? Apparently not. > I reviewed it, though it was admittedly some time ago. I remember thinking these things: 1) The draft doesn't identify a single instance of a site that has chosen not implement macros. This is in contrast to the numerous applications that use libspf2 to build their SPF checking applications, and to the two commercial solutions with which I'm familiar, none of which permit one to selectively disable macros. I understand the need to keep client details confidential, but it leaves me wondering why your client base is so different than everything else I've observed. In contrast, RFC6648 revealed numerous details about its survey sources, and its methods could be repeated today, likely with similar results since they are so clearly described, so I would argue that it's far more credible work. 2) As Andrew observed, there has also not been a document case of the amplification attack in the wild. It seems to me that if this were an interesting or worthwhile exploit, we'd have seen one happen by now. 3) As Andrew also observed, we are unable to remove it even with the slim use that's been documented. People (including me) made a pretty hard push for it, but we are, at least right now, procedurally constrained against doing so. 4) Your co-author on this draft (and on the DKIM one, and on the recent IESG appeal about DKIM) is an awfully quiet person for such a passionate and potentially serious topic. Does he not care to help you defend the position you're taking? -MSK --001a11c227eeff737604e684dcf4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 16, 2013 at 7:41 AM, Andrew Sullivan <aj= s@anvilwalrusden.com> wrote:
> In my defense, may I ask whether the dr= aft
By me? =A0Yes. =A0Widely? =A0Apparently not.
I reviewed it, though it was admittedly some time ago.=A0 I rem= ember thinking these things:

1) The draft doesn't ide= ntify a single instance of a site that has chosen not implement macros.=A0 = This is in contrast to the numerous applications that use libspf2 to build = their SPF checking applications, and to the two commercial solutions with w= hich I'm familiar, none of which permit one to selectively disable macr= os.=A0 I understand the need to keep client details confidential, but it le= aves me wondering why your client base is so different than everything else= I've observed.=A0 In contrast, RFC6648 revealed numerous details about= its survey sources, and its methods could be repeated today, likely with s= imilar results since they are so clearly described, so I would argue that i= t's far more credible work.

2) As Andrew observed, there has also not been a document ca= se of the amplification attack in the wild.=A0 It seems to me that if this = were an interesting or worthwhile exploit, we'd have seen one happen by= now.

3) As Andrew also observed, we are unable to remove it even = with the slim use that's been documented.=A0 People (including me) made= a pretty hard push for it, but we are, at least right now, procedurally co= nstrained against doing so.

4) Your co-author on this draft (and on the DKIM = one, and on the recent IESG appeal about DKIM) is an awfully quiet person f= or such a passionate and potentially serious topic.=A0 Does he not care to = help you defend the position you're taking?

-MSK
--001a11c227eeff737604e684dcf4-- From marka@isc.org Mon Sep 16 15: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 CE35911E81C6 for ; Mon, 16 Sep 2013 15:04: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=[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 FSn6LxGV1b8r for ; Mon, 16 Sep 2013 15:04: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 7EC3411E819C for ; Mon, 16 Sep 2013 15:04:21 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id B779DC94C2; Mon, 16 Sep 2013 22:04:05 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1379369061; bh=7+PW5s7zlOP+fD2wmGSFztmX/osEbaxVUL1IoE8P0z4=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=BxcFjdIqWi49+1LckRVEjgFUfFTpzvCWGXAd/A3xOMofl0HXJ98qI5OLzkdb+WckP XPIQ+SzY3RwQW621abdTHmjFhsXkfZp2vDmNwQlY4XmElw6OvwIC2CIa+Dk8nWyaHe bIdgTtWRsenC+soRylgxNEntj9hdk7FVN6u8GOqs= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Mon, 16 Sep 2013 22:04:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 12A0A160446; Mon, 16 Sep 2013 22:06:11 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id D2F1E16034F; Mon, 16 Sep 2013 22:06:10 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7108E68DF84; Tue, 17 Sep 2013 08:04:03 +1000 (EST) To: "Murray S. Kucherawy" From: Mark Andrews References: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130912065558.0b960550@elandnews.com> <5231D5E5.5070407@cisco.com> <6.2.5.6.2.20130912080503.0c90f9d0@elandnews.com> <18A91BEE-6360-4E1F-9B08-5E45C5217694@gmail.com> <20130914003652.GF78680@mx1.yitter.info> <20130916144135.GC79031@mx1.yitter.info> In-reply-to: Your message of "Mon, 16 Sep 2013 12:03:44 -0700." Date: Tue, 17 Sep 2013 08:04:03 +1000 Message-Id: <20130916220403.7108E68DF84@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "spfbis@ietf.org" , Andrew Sullivan Subject: Re: [spfbis] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 16 Sep 2013 22:04:25 -0000 In message , "Murray S. Kucherawy" writes: > > On Mon, Sep 16, 2013 at 7:41 AM, Andrew Sullivan wrot > e: > > > > In my defense, may I ask whether the draft > > > http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-01 been > > > reviewed? > > > > By me? Yes. Widely? Apparently not. > > > > I reviewed it, though it was admittedly some time ago. I remember thinking > these things: > > 1) The draft doesn't identify a single instance of a site that has chosen > not implement macros. This is in contrast to the numerous applications > that use libspf2 to build their SPF checking applications, and to the two > commercial solutions with which I'm familiar, none of which permit one to > selectively disable macros. I understand the need to keep client details > confidential, but it leaves me wondering why your client base is so > different than everything else I've observed. In contrast, RFC6648 > revealed numerous details about its survey sources, and its methods could > be repeated today, likely with similar results since they are so clearly > described, so I would argue that it's far more credible work. > > 2) As Andrew observed, there has also not been a document case of the > amplification attack in the wild. It seems to me that if this were an > interesting or worthwhile exploit, we'd have seen one happen by now. No. This is bad reasoning. There have been lots of theoretical attacks that have taken a long time to before we see them used in anger. > 3) As Andrew also observed, we are unable to remove it even with the slim > use that's been documented. People (including me) made a pretty hard push > for it, but we are, at least right now, procedurally constrained against > doing so. > > 4) Your co-author on this draft (and on the DKIM one, and on the recent > IESG appeal about DKIM) is an awfully quiet person for such a passionate > and potentially serious topic. Does he not care to help you defend the > position you're taking? > > -MSK > -- 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 Sep 16 15:59: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 6041811E812F for ; Mon, 16 Sep 2013 15:59:51 -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 dHvLaVEqxj1j for ; Mon, 16 Sep 2013 15:59:45 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id CB34511E81CC for ; Mon, 16 Sep 2013 15:59:44 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B37A68A031 for ; Mon, 16 Sep 2013 22:59:43 +0000 (UTC) Date: Mon, 16 Sep 2013 18:59:39 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20130916225939.GA33519@mx1.yitter.info> References: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130912065558.0b960550@elandnews.com> <5231D5E5.5070407@cisco.com> <6.2.5.6.2.20130912080503.0c90f9d0@elandnews.com> <18A91BEE-6360-4E1F-9B08-5E45C5217694@gmail.com> <20130914003652.GF78680@mx1.yitter.info> <20130916144135.GC79031@mx1.yitter.info> <20130916220403.7108E68DF84@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130916220403.7108E68DF84@rock.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] value of attack path (was: Benoit Claise's No Objection ...) 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, 16 Sep 2013 22:59:51 -0000 No hat. On Tue, Sep 17, 2013 at 08:04:03AM +1000, Mark Andrews wrote: > No. This is bad reasoning. There have been lots of theoretical > attacks that have taken a long time to before we see them used in anger. Yes. That is why I asked about the liklihood of the attack in question being deployed. It seems to me that it is quite a lot more complicated than the attacks that are quite straightforwardly available to DNS as it stands, and which while individually less severe are much more easily delivered at large scale. So, in my opinion, the concern about SPF-based attacks using vast volumes of SPF processing triggering events due to macros and so on is misplaced. Supposing that I'm wrong, however, it seems to me that sites could trivially protect themselves from this by refusing to process macros anyway. So I just don't get what the excitement is about. It's a theoretically devastating attack, just like a full-on siege of the Maginot line with overwhelming force might have been. As we actually saw, there was a considerably less taxing path for attack. Unless there is some new evidence introduced, I'm not interested in this topic any more. It doesn't appear to be yielding any new evidence. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From john@jlc.net Mon Sep 16 16:49: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 359CA11E8156 for ; Mon, 16 Sep 2013 16:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.769 X-Spam-Level: X-Spam-Status: No, score=-104.769 tagged_above=-999 required=5 tests=[AWL=1.830, 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 2P9n8OWx+DBO for ; Mon, 16 Sep 2013 16:49:31 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id DBBC411E815A for ; Mon, 16 Sep 2013 16:49:30 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3D4ACC94C7; Mon, 16 Sep 2013 19:49:27 -0400 (EDT) Date: Mon, 16 Sep 2013 19:49:27 -0400 From: John Leslie To: Andrew Sullivan Message-ID: <20130916234927.GD59497@verdi> References: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130912065558.0b960550@elandnews.com> <5231D5E5.5070407@cisco.com> <6.2.5.6.2.20130912080503.0c90f9d0@elandnews.com> <18A91BEE-6360-4E1F-9B08-5E45C5217694@gmail.com> <20130914003652.GF78680@mx1.yitter.info> <20130916144135.GC79031@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130916144135.GC79031@mx1.yitter.info> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 16 Sep 2013 23:49:35 -0000 Andrew Sullivan wrote: > On Fri, Sep 13, 2013 at 08:56:55PM -0700, Douglas Otis wrote: > >> It contains a reference to a survey by the SPF website >> http://spf-all.com/stats.html which indicates of all domains >> publishing SPF records 99.947% contain no macros. It seems a >> reasonable person would wonder why. > > Yes, and it is entirely reasonable that anyone might. But it doesn't > matter, because there's half a percent that _do_ have macros, and SM > and I (as chairs) already determined earlier in the WG's life that > "unused" meant "not used at all". Therefore, macros cannot be > deprecated by the WG. That's a consequence of our charter. I chose not to question that interpretation -- it's not worth flamewars for an issue like this one. >> I hope you can imagine what this might mean from the perspective of >> network amplifications > > I am somewhat conversant with network amplifications via DNS. It is > interesting to me that, despite the attractive nuisance that DNS > provides in terms of amplifications, for reasons totally mysterious to > me I have never once, in any log I have reviewed, seen evidence of an > SPF-based attack of the sort you keep talking about. My preference would be to note the issue; and comment that such an occurance has never been observed. (I don't propose to deprecate macros at this time; but there may be reason to partially or fully deprecate them at some later time.) > The WG was chartered on the condition, in effect, that it not change > SPF unless something was totally broken or actually unused. Since you > note, in your message, that macros and so on _are_ in fact used, and > since there is no analagous problem with the specification _per se_ as > there was in the case of the DNS RRTYPEs, we are not free to deprecate > as you appear to want. I accept that. Nonetheless, The possible amplification is real, and IMHO deserves a mention in Security Considerations. > I am pretty sure that has been explained on list more than once. If > it is even remotely unclear to you, I suggest you contact me off > list so that I can explain it in a way you can understand it. Doug is an engineer at heart. He likes to _fix_ problems. There is a middle ground, where one documents problems, and leaves fixing them to some future action. -- John Leslie From spf2@kitterman.com Mon Sep 16 17:09: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 8D9A011E8156 for ; Mon, 16 Sep 2013 17:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 6msRPAXbAsyL for ; Mon, 16 Sep 2013 17:09:42 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E36E111E80D5 for ; Mon, 16 Sep 2013 17:09:41 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 20E2320E40EF; Mon, 16 Sep 2013 20:09:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1379376577; bh=yI3QgZd1M6VYJ7NiVe+AzdVMii105Ps5ST+fWGbp0dA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=XGtQwm8u17oG8fSNzQaizIHBvT22DaLcwjAFNxuw4VKcQntXnjlFc6ZaMO5JyVpMJ y8LSUakuYdwQtvXC878tJIQf3aTTdIe8OFTICuFImPcjGuvOcZ0So+1HtxM/vVzCL/ WGuVKEvokHZQ2O3GT4LRF6Dv/q90ik2X9H6XIFyE= 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 0683720E40C4; Mon, 16 Sep 2013 20:09:36 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 16 Sep 2013 20:09:36 -0400 Message-ID: <2034326.NFNlXHdOCs@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <20130916234927.GD59497@verdi> References: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> <20130916144135.GC79031@mx1.yitter.info> <20130916234927.GD59497@verdi> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 17 Sep 2013 00:09:46 -0000 On Monday, September 16, 2013 19:49:27 John Leslie wrote: > Andrew Sullivan wrote: > > On Fri, Sep 13, 2013 at 08:56:55PM -0700, Douglas Otis wrote: > >> It contains a reference to a survey by the SPF website > >> http://spf-all.com/stats.html which indicates of all domains > >> publishing SPF records 99.947% contain no macros. It seems a > >> reasonable person would wonder why. > > > > Yes, and it is entirely reasonable that anyone might. But it doesn't > > matter, because there's half a percent that _do_ have macros, and SM > > and I (as chairs) already determined earlier in the WG's life that > > "unused" meant "not used at all". Therefore, macros cannot be > > deprecated by the WG. That's a consequence of our charter. > > I chose not to question that interpretation -- it's not worth flamewars > for an issue like this one. > > >> I hope you can imagine what this might mean from the perspective of > >> network amplifications > > > > I am somewhat conversant with network amplifications via DNS. It is > > interesting to me that, despite the attractive nuisance that DNS > > provides in terms of amplifications, for reasons totally mysterious to > > me I have never once, in any log I have reviewed, seen evidence of an > > SPF-based attack of the sort you keep talking about. > > My preference would be to note the issue; and comment that such an > occurance has never been observed. (I don't propose to deprecate macros > at this time; but there may be reason to partially or fully deprecate > them at some later time.) > > > The WG was chartered on the condition, in effect, that it not change > > SPF unless something was totally broken or actually unused. Since you > > note, in your message, that macros and so on _are_ in fact used, and > > since there is no analagous problem with the specification _per se_ as > > there was in the case of the DNS RRTYPEs, we are not free to deprecate > > as you appear to want. > > I accept that. Nonetheless, The possible amplification is real, and > IMHO deserves a mention in Security Considerations. > > > I am pretty sure that has been explained on list more than once. If > > it is even remotely unclear to you, I suggest you contact me off > > list so that I can explain it in a way you can understand it. > > Doug is an engineer at heart. He likes to _fix_ problems. > > There is a middle ground, where one documents problems, and leaves > fixing them to some future action. There is a claimed problem. To the extent there is an actual problem, it's a DNS problem. There are many ways to get DNS amplification. This is (maybe) one example of a larger issue. SPF, by definition, inherits all of DNS' weaknesses. We don't document them all and I don't see any benefit in treating this one specially. Scott K From doug.mtview@gmail.com Tue Sep 17 00:34: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 7BE8B11E8392 for ; Tue, 17 Sep 2013 00:34: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=[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 Lz7v7oQYLGHT for ; Tue, 17 Sep 2013 00:34:27 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0790C11E8230 for ; Tue, 17 Sep 2013 00:34:27 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id uo5so5183214pbc.9 for ; Tue, 17 Sep 2013 00:34:26 -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; bh=SVaJSKcfJeJSeCmeYXiTXtdBWVwWVx1+lcqoQHYDuk8=; b=lwTTReiMpsH5ZJbpW3QbrzHOs300aaEHU+ZuP2kgek9BNc58lBqzArnVLCXdjmLrRI HXrrb/Lvjgp2rvyxZ0kVGffQNDQd+R6sJJstMlqz+RjbF6icxvDNJd+OdA5zwHeAZwfe N0JtbyKpa1TQygQCaaJs2cjjyDtHpExKUtkkL945rYZmhGt7QAAzGL/8G/Xmt23ou+L3 MBE9cqsqYYTZWmTNW3dTSkI7NuTgofHnDWKPdul3QeheTC9ZGz8X5kGBqbl+m+kJPuAE grP3spaWEPPMEMaRuNifm6EpTruFlHO7tlfQgW5vfyPsG3Al7VpPNMbiKkJyTKQhkEZv PvxQ== X-Received: by 10.68.223.161 with SMTP id qv1mr33472827pbc.79.1379403266689; Tue, 17 Sep 2013 00:34:26 -0700 (PDT) Received: from [192.168.2.201] (c-24-6-103-174.hsd1.ca.comcast.net. [24.6.103.174]) by mx.google.com with ESMTPSA id j9sm43945895paj.18.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 00:34:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Douglas Otis In-Reply-To: <20130916144135.GC79031@mx1.yitter.info> Date: Tue, 17 Sep 2013 00:34:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <76AD9C0E-62DC-4E55-94ED-59665D731532@gmail.com> References: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130912065558.0b960550@elandnews.com> <5231D5E5.5070407@cisco.com> <6.2.5.6.2.20130912080503.0c90f9d0@elandnews.com> <18A91BEE-6360-4E1F-9B08-5E45C5217694@gmail.com> <20130914003652.GF78680@mx1.yitter.info> <20130916144135.GC79031@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1508) Cc: spfbis@ietf.org Subject: Re: [spfbis] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 17 Sep 2013 07:34:29 -0000 Dear Andrew, See comments inline. On Sep 16, 2013, at 7:41 AM, Andrew Sullivan = wrote: > I've trimmed the ccs. This is clearly right back to fodder for the > spfbis list. If I have a hat on below, I'll note it. >=20 > On Fri, Sep 13, 2013 at 08:56:55PM -0700, Douglas Otis wrote:=20 >=20 >> In my defense, may I ask whether the draft >> http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-01 been >> reviewed? >=20 > By me? Yes. Widely? Apparently not. >=20 >> It contains a reference to a survey by the SPF website >> http://spf-all.com/stats.html which indicates of all domains >> publishing SPF records 99.947% contain no macros. It seems a >> reasonable person would wonder why. >=20 > Yes, and it is entirely reasonable that anyone might. But it doesn't > matter, because there's half a percent that _do_ have macros, and SM > and I (as chairs) already determined earlier in the WG's life that > "unused" meant "not used at all". Therefore, macros cannot be > deprecated by the WG. That's a consequence of our charter. May I make minor corrections to your comments? The number of domains publishing macros is not 0.5 percent but 0.05%. = There are 20 times this number of domains publish erroneous SPF records. = Does it really make sense to place DNSSEC at risk to support such a = vanishingly small minority? Removing a seldom used, highly complex, and = risky feature should be well within the charter. =20 >> I hope you can imagine what this might mean from the perspective of >> network amplifications=20 >=20 > I am somewhat conversant with network amplifications via DNS. It is > interesting to me that, despite the attractive nuisance that DNS > provides in terms of amplifications, for reasons totally mysterious to > me I have never once, in any log I have reviewed, seen evidence of an > SPF-based attack of the sort you keep talking about. This macro feature is not supported by major providers, where its use = threatens interchange and places DNS at risk. > That is not to > say that your observations are wrong: SPF clearly provides an > extremely useful attack vector. But I find it interesting that SPF > does not appear to be central. This is quite possibly because > mounting the SPF based attack you're talking about requires > considerably more co-ordination among the moving parts than > straightforward amplification via plain DNS spoofing. (I could come > up with some other explanations, of equivalent degree of rank > speculation if you'd like, but I think one such speculation is enough > for these purposes.) >=20 >> At the same time, it seems irresponsible to completely deprecate use >> of the dedicated RR record type that had a much higher level of use >> while not deprecating a far more dangerous macro option used by far >> fewer domains. Such an oversight can not be excused by blaming the >> charter. >=20 > With my chair hat on: the reason RRTYPE 99 is deprecated is _not_ > because it's unused, but because there is an interoperability problem > in RFC 4408. We _had to_ do something, in order to move the protocol > to the standards track, because a standards track document needs to > have no such known and unaddressed flaws. Having a completely indefensible macro feature dumping queries into DNS = is not a serious flaw? Purporting a feature that lacks negotiation in fact not widely supported = is not a serious flaw? If this document gets published, it should be as informational.=20 > The same is _not_ true of > the options you're talking about: they may have some negative > consequences, but those consequences are called out in the document. "Some negative" is a massive understatement. The potential, as I = understand the situation, is actively being suppressed. Enabling DNS = logging could confirm the level of support.=20 Ignoring SPF records that contain macros explains why erroneous SPF = records are present in much greater numbers. It seems everyone knows = publishing macros is clearly a mistake. > The WG was chartered on the condition, in effect, that it not change > SPF unless something was totally broken or actually unused. If the goal is to support interchange, remove macros. Assume macros was = a bad idea that never found traction or that were actively suppressed. > Since you > note, in your message, that macros and so on _are_ in fact used, and > since there is no analagous problem with the specification _per se_ as > there was in the case of the DNS RRTYPEs, we are not free to deprecate > as you appear to want. You are comparing an extra query to greatly increased gain enabled = through use of macros? I am at a loss to understand this line of = reasoning. A statement that some future version will remove use of TXT = records offers a clear incentive and solution. Those that don't change = receive neutral handling. Not a major issue. The same should be true = for the 0.053% of domains publishing macros. > I am pretty sure that has been explained on list more than once. If > it is even remotely unclear to you, I suggest you contact me off > list so that I can explain it in a way you can understand it. Clearly we see this issue much differently. Perhaps facing the brunt of = DDoS changes one's perspective. It is not right to suggest the risk = being created by this protocol offering automation of a massive sequence = of random queries from cached records by unknown entities is somehow up = to DNS to solve? Please describe how DNS can be defended when SPF = macros are being abused.=20 Regards, Douglas Otis From sm@elandsys.com Tue Sep 17 01:21: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 C222411E83A5; Tue, 17 Sep 2013 01:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 nubGhtYEGKDO; Tue, 17 Sep 2013 01:21: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 016B011E83A4; Tue, 17 Sep 2013 01:21:50 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.146.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8H8LRBK006285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Sep 2013 01:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379406101; bh=zq64VaMlu23G0SBrguiNJfHihcBMLsDmh2linByo9yo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=AzydwO0Zfc4tMf+cTmsdTD+UVflUllImPxZIyrIvrFAfhVhsmYd1MLBMA+8VwyLwY CaGJvkgS59WXRFO07pqVsOWeR9g3IlHly9GxDFFf3weFlCXkWUM+OV1n0rCu38piRj eYSR2vY5klaqi3lWqjHSqaUINwNTu44uktbCyPQM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379406101; i=@elandsys.com; bh=zq64VaMlu23G0SBrguiNJfHihcBMLsDmh2linByo9yo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=S7n9YJtgxv29q0ILom4JYHJ72ggg3hBOPZgQp0tL9QXSwexIXa7Et3w1iVuOiTedz NrG+rPg0JvAy7MRVAjPgk58CB367yGOOS0uiknTeWZjED8vIVZykXnSdUYZZJozLss rRvxzIfYAR05uvT/KEXsWIWuXjNn2oJXjYCV6Mzs= Message-Id: <6.2.5.6.2.20130917010720.06302bf8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 17 Sep 2013 01:19:44 -0700 To: Phillip Hallam-Baker , draft-ietf-spfbis-4408bis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 17 Sep 2013 08:21:52 -0000 Hi Phillip, At 05:07 11-09-2013, Phillip Hallam-Baker wrote: >Minor issues. > >1.1.3. MAIL FROM Definition > >I found this section completely opaque and very confusing. It should >not be necessary to hunt through other specs to find a definition. >Particularly since the referenced specs do not give an explicit >definition for the term as used and the references point to the >whole spec rather than a particular section. The text below is to address the comment about Section 1.1.3 (credits to Rolf E. Sonneveld): 1.1.3. MAIL FROM Definition This document uses "MAIL FROM" to refer to RFC5321.MailFrom (reverse-path). The RFC5321.MailFrom is defined in Section 4.4 of RFC 5598 as an end-to-end string that specifies an email address for receiving return control information, such as returned messages. >The Security Considerations section is adequate for the purpose >except that no mention is made anywhere in the specification about >DKIM and how a mail receiver should interpret presence of DKIM and >SPF policy at the same time. This is a legitimate concern since DKIM >is already a standards track proposal and SPF is only now being >promoted to Standards Track. Thus the SPF document should address >the question of dual use. I commented about the above in my previous reply. >8.7. Permerror >"This signals an error condition that definitely requires operator >intervention to be resolved." > >I cannot imagine a circumstance which definitely requires a human to >be involved in mail delivery. These are permanent DNS errors or SPF record errors. For example, if an SPF record requires too many DNS lookups, someone has to change the record to make the error go away. The definitely was intended to distinguish from cases such as a DNS SERVFAIL that may or may not be permanent, but are temperrors in SPF. In the case of ambiguity about if an error is temporary or permanent, it's treated in the design as assumed to be temporary. >11.2. SPF-Authorized Email May Contain Other False Identities > > Do not construe the "MAIL FROM" and "HELO" identity authorizations to > provide more assurance than they do. > >Document has quasi normative language that should be worded as >statements of fact rather than as direction. The following change is proposed is response to the above: The "MAIL FROM" and "HELO" identity authorizations do not provide assurance about the authorization/authenticity of other identities used in the message. Regards, S. Moonesamy (as document shepherd) From doug.mtview@gmail.com Wed Sep 18 09:08: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 0233411E8285 for ; Wed, 18 Sep 2013 09:08:07 -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, 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 OAN3OQN3u2zY for ; Wed, 18 Sep 2013 09:08:06 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A2B0F11E8256 for ; Wed, 18 Sep 2013 09:07:32 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa1so8409276pad.5 for ; Wed, 18 Sep 2013 09:07:26 -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; bh=2QpXdSMgnd7aUUvwB+3lZUf/OJ/6h2HcZ4CxbLEaq60=; b=NAWW4ZniK0ve+D+QoDDgsYlQevIuonP30ZtNeD2Sl9Y6et+ipXNuI8J1K4P1r4dW/7 +0KmTD5kCxoHEcvvnEWbn6jKXLnIBYwTTgs/cU2KuxlaCQZ22W+0G1LjtrBOBAgtvVTc Fcf/jufweJGJkt51XnW1s3oA/Q+A2Ui1MmXz1YmEKJGS4GTpUoz3LMSsfOuF/z9IVuJH n+7NMqh1Swl9k0N06dzA+CY89LTIUUKNc7rkC4RW2nXzdgXGz2hIfxX8K3Bnaz2P5kPl phZerZ5cfeZUaZm3YJBMAtrZ3YNBc4bp2fZgyVfzRmbgBooCQjDjVNSNUpSVaCWoB1IT 1OEg== X-Received: by 10.68.255.229 with SMTP id at5mr15821308pbd.130.1379520446083; Wed, 18 Sep 2013 09:07:26 -0700 (PDT) Received: from [192.168.2.232] (c-24-6-103-174.hsd1.ca.comcast.net. [24.6.103.174]) by mx.google.com with ESMTPSA id tx5sm2297304pbc.29.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 09:07:24 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6DFAEF46-564B-42C5-922B-3D0EC934993F" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Douglas Otis In-Reply-To: Date: Wed, 18 Sep 2013 09:07:27 -0700 Message-Id: References: <20130912104701.7259.79919.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130912065558.0b960550@elandnews.com> <5231D5E5.5070407@cisco.com> <6.2.5.6.2.20130912080503.0c90f9d0@elandnews.com> <18A91BEE-6360-4E1F-9B08-5E45C5217694@gmail.com> <20130914003652.GF78680@mx1.yitter.info> <20130916144135.GC79031@mx1.yitter.info> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1508) Cc: "spfbis@ietf.org" , Andrew Sullivan Subject: Re: [spfbis] Benoit Claise's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 18 Sep 2013 16:08:07 -0000 --Apple-Mail=_6DFAEF46-564B-42C5-922B-3D0EC934993F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Sep 16, 2013, at 12:03 PM, Murray S. Kucherawy = wrote: > On Mon, Sep 16, 2013 at 7:41 AM, Andrew Sullivan = wrote: > > In my defense, may I ask whether the draft > > http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-01 been > > reviewed? >=20 > By me? Yes. Widely? Apparently not. >=20 > I reviewed it, though it was admittedly some time ago. I remember = thinking these things: >=20 > 1) The draft doesn't identify a single instance of a site that has = chosen not implement macros. This is in contrast to the numerous = applications that use libspf2 to build their SPF checking applications, = and to the two commercial solutions with which I'm familiar, none of = which permit one to selectively disable macros. I understand the need = to keep client details confidential, but it leaves me wondering why your = client base is so different than everything else I've observed. In = contrast, RFC6648 revealed numerous details about its survey sources, = and its methods could be repeated today, likely with similar results = since they are so clearly described, so I would argue that it's far more = credible work. You meant RFC6686. Several assumptions are being made about the use of = macros in these conversations, but this survey ignored SPF macro = publication or SPF macro processing. As such there is no support = regarding the use or the problems such use should been expected to = cause. Lack of information does not offer any credible information = regarding this aspect of SPF. > 2) As Andrew observed, there has also not been a document case of the = amplification attack in the wild. It seems to me that if this were an = interesting or worthwhile exploit, we'd have seen one happen by now. Problems with making these assumptions: 1) SPF does not use dedicated resource records or naming conventions to = easily identify underlying sources of possible SPF driven queries. 2) DDoS attacks that exploit SPF can make a large number of "normal" = queries without identifying their use. 3) Not all DDoS attacks are being reported. Many are not. 4) Major providers will permit exploitation of their resources via SPF. Rather than enduring the massive code size and associated high DNS = overhead,=20 major providers are more likely to use SPF to weigh IP addresses = beforehand.=20 There have been recent massive DDoS attacks so extreme care must be = taken in this regard. > 3) As Andrew also observed, we are unable to remove it even with the = slim use that's been documented. People (including me) made a pretty = hard push for it, but we are, at least right now, procedurally = constrained against doing so. An argument can be made that when a very very small number of domains = publish a resource record, minimalistic publication should not be = considered evidence of use or to represent consensus about a feature = becoming part of a standard. This would suggest instead the document = should be considered informational on that basis. When 0.00053 of = domains publishing SPF records publish records containing macro expanded = terms this should not be considered evidence of use. Just the opposite = is more likely true. Secondly, there has not been any interchange = testing (even by way of DNS logging of macro derived targets) to confirm = whether such publication offers reasonably assured interchange. = Instead, this issue has been ignored by the survey and the WG in terms = of use and security considerations.=20 > 4) Your co-author on this draft (and on the DKIM one, and on the = recent IESG appeal about DKIM) is an awfully quiet person for such a = passionate and potentially serious topic. Does he not care to help you = defend the position you're taking? Does a low rate of emails equate to non-support? Regards, Douglas Otis --Apple-Mail=_6DFAEF46-564B-42C5-922B-3D0EC934993F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 superuser@gmail.com> = wrote:
On Mon, Sep 16, 2013 at 7:41 AM, Andrew = Sullivan <ajs@anvilwalrusden.com> wrote:
> In my defense, = may I ask whether the draft
By me?  Yes.  Widely?  Apparently = not.

I reviewed it, though it was = admittedly some time ago.  I remember thinking these = things:

1) The draft doesn't identify a single = instance of a site that has chosen not implement macros.  This is = in contrast to the numerous applications that use libspf2 to build their = SPF checking applications, and to the two commercial solutions with = which I'm familiar, none of which permit one to selectively disable = macros.  I understand the need to keep client details confidential, = but it leaves me wondering why your client base is so different than = everything else I've observed.  In contrast, RFC6648 revealed = numerous details about its survey sources, and its methods could be = repeated today, likely with similar results since they are so clearly = described, so I would argue that it's far more credible = work.

You meant = RFC6686.  Several assumptions are being made about the use of = macros in these conversations, but this survey ignored SPF macro = publication or SPF macro processing.   As such there is no support = regarding the use or the problems such use should been expected to = cause.  Lack of information does not offer any credible information = regarding this aspect of SPF.

2) As Andrew observed, there has also not = been a document case of the amplification attack in the wild.  It = seems to me that if this were an interesting or worthwhile exploit, we'd = have seen one happen by = now.

Problems = with making these assumptions:

1) SPF does not = use dedicated resource records or naming conventions to easily identify = underlying sources of possible SPF driven queries.
2) DDoS = attacks that exploit SPF can make a large number of "normal" queries = without identifying their use.
3) Not all DDoS attacks are = being reported.  Many are not.
4) Major providers will = permit exploitation of their resources via SPF.
    =  Rather than enduring the massive code size and associated high DNS = overhead, 
     major providers are more = likely to use SPF to weigh IP addresses = beforehand. 

There have been recent = massive DDoS attacks so extreme care must be taken in this = regard.

3) = As Andrew also observed, we are unable to remove it even with the slim = use that's been documented.  People (including me) made a pretty = hard push for it, but we are, at least right now, procedurally = constrained against doing = so.

An argument = can be made that when a very very small number of domains publish a = resource record, minimalistic publication should not be considered = evidence of use or to represent consensus about a feature becoming part = of a standard.  This would suggest instead the document should be = considered informational on that basis.  When 0.00053 of domains = publishing SPF records publish records containing macro expanded terms = this should not be considered evidence of use.  Just the opposite = is more likely true.  Secondly, there has not been any interchange = testing (even by way of DNS logging of macro derived targets) to confirm = whether such publication offers reasonably assured interchange. =  Instead, this issue has been ignored by the survey and the WG in = terms of use and security = considerations. 

4) Your co-author on this draft (and on the DKIM one, and on = the recent IESG appeal about DKIM) is an awfully quiet person for such a = passionate and potentially serious topic.  Does he not care to help = you defend the position you're = taking?

Does a = low rate of emails equate to = non-support?

Regards,
Douglas = Otis






= --Apple-Mail=_6DFAEF46-564B-42C5-922B-3D0EC934993F-- From doug.mtview@gmail.com Wed Sep 18 09:33: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 1FA9721F9935 for ; Wed, 18 Sep 2013 09:33: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 JKckFDLGjNZM for ; Wed, 18 Sep 2013 09:33:50 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0AD21F98AC for ; Wed, 18 Sep 2013 09:33:50 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr4so7187597pbb.6 for ; Wed, 18 Sep 2013 09:33:50 -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; bh=m2ojY1Ift7t2YyFLUP8jctsqZbt4VWZr/dP1MRjyGxk=; b=AEewS7ENfXY+JZye8B8FS1ScwLyjqYUh4fNfA9/EE1frGZeCSEp2cY50glvNms1+ee z6ARsT/bGUOA+DADgnNvhAsbxYJVsClnNd1kOUwo0hnVdRnrR89eXeBKKi8NK8I0qyM8 88htMbIA9fEF6YjtcT/yx6kLdtaUQATBekr76UDFZx4ePJsJd0/oNFBwVGFUOg6ioPjM BZcPZOhfRONCzx3OPoV7uGP7qEdjV+q6ceZrH5zJqFbwJesgIaegpoQR8PZC8oG5w42e AQz46E/7E77T69v6A7WdjXBrYbiIZpObZvdvY6y6cZNVX6OEeMWhn6xOnlQMCCe0/K5W WZQw== X-Received: by 10.66.249.134 with SMTP id yu6mr44336242pac.37.1379522030279; Wed, 18 Sep 2013 09:33:50 -0700 (PDT) Received: from [192.168.2.232] (c-24-6-103-174.hsd1.ca.comcast.net. [24.6.103.174]) by mx.google.com with ESMTPSA id fy4sm3571931pbb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 09:33:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Douglas Otis In-Reply-To: <20130915213604.GB78902@mx1.yitter.info> Date: Wed, 18 Sep 2013 09:33:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <74A0E850-9240-4EB4-8497-16DA31FB2B5E@gmail.com> References: <6.2.5.6.2.20130913152347.0c874cb8@elandnews.com> <20130914001204.GB78680@mx1.yitter.info> <72C262F1-0715-499D-948F-989A9A007824@gmail.com> <20130915213604.GB78902@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1508) Cc: spfbis@ietf.org Subject: Re: [spfbis] draft-ietf-spfbis-4408bis-20 review (response size) 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, 18 Sep 2013 16:33:51 -0000 On Sep 15, 2013, at 2:36 PM, Andrew Sullivan = wrote: > No hat. >=20 > On Fri, Sep 13, 2013 at 05:34:41PM -0700, Douglas Otis wrote: >>=20 >> I did not recommend this value, but I did say it sounded like = reasonable advice.=20 >=20 > There is exactly one historic built-in limit to the DNS for UDP > packets, and that is 512 octets. Dear Andrew, You have made the same mistake made in SPFbis. There has never been a = UDP limit imposed by DNS. There is however a DNS Message limit imposed = at 512 octets. In addition to the DNS Message, is the UDP and IP = header. The size of the IP and UDP header depends upon IP version.=20 > Lots of middleboxes drop UDP packets > on port 53 larger than 512 octets. They are likely dropping DNS Messages larger than 512 octets. They = might be dropping packets larger than 576 octets, but that seems = unlikely.=20 > Many equipment manufacturers have > shipped equipment that, by default, drops packets over 512 octets on > port 53. The 512 octets does not apply to TCP. If it did, zone > transfers would be impossible. This would be a correct statement only in regard to that of the DNS = Message size. > Everything else -- all the noise about MTUs and so on -- is rank > speculation. There's _all kinds_ of breakage out there with large MTU > sizes. Heck, some of the CGNs appear to end up with real MTUs across > the network way below any threshold we're discussing. But this > document should not be a general purpose document about all the > possible ways this protocol could interact with everything else > everywhere on the Internet. This is a protocol document. The MTU size MUST be increased to support DNSSEC. IPv6 also changes the = minimum MTU. Since SPFbis does not have purview over whether IPv6 or = DNSSEC is used, these environments MUST be considered with SPFbis's = incredibly complex macro expanded protocol able to emit hundreds of UDP = packet into DNS all on behalf of unknown entities where targets can be = modulated by message elements rather than DNS content. What might seem = like a subtle difference can lead to significant increase in network = amplification. > As I have said several times, if someone wants to write an operational > guidance document, I have no objection. But the protocol document > shouldn't be providing that, at least in detail. It is arguably > already too heavy in that direction. What type of operational guide? There is no operational defense able to = mitigate SPFbis macro use that I am aware of except for email providers = ignoring SPF records containing macros. What did you have in mind?=20 Regards, Douglas Otis= From doug.mtview@gmail.com Wed Sep 18 11:20: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 952AF11E80DE; Wed, 18 Sep 2013 11:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, 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 Rs3vF4jP+Udz; Wed, 18 Sep 2013 11:20:25 -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 790FB21F9C9A; Wed, 18 Sep 2013 11:20:25 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id up15so7293976pbc.40 for ; Wed, 18 Sep 2013 11:20: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; bh=6eFDg1BrMZy/NwQT1e4r/AkJlDx6kmWtkzB3ui6+W/M=; b=ITpgBUoVcTA0XKcSSSCDcGYerJ3pcT1p/zKzE+fY0NueF5WtxONqgW0WJTU6O/9xbj gz6m82EUgWpz0AiLGQPY+7D+/5LmX9UQWGJQpG/rW9J4oWkdQ7gOS3bsZy0kanZsFeHk gkRfe/vU7PygIMZqX/BGWOaP3a+vO/w7atpxkW10w4AiUTcCZEyRMiDKTFUSBpUE4lPZ eRUJJRQktMn7GiTB1UZbcfcELf5SwPmpfJRw3kX7XTrhCi6ByF773qlGElaXzY7T8DBX gov/BvM2A6+NFpDM7lLWHF4DvYUdNaQwmw5w69iKH2MREjnvRlSzxnf8Ft36hGPY8DlQ geHA== X-Received: by 10.66.163.164 with SMTP id yj4mr44971994pab.91.1379528420222; Wed, 18 Sep 2013 11:20:20 -0700 (PDT) Received: from [192.168.2.232] (c-24-6-103-174.hsd1.ca.comcast.net. [24.6.103.174]) by mx.google.com with ESMTPSA id yh1sm4030453pbc.21.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 11:20:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Douglas Otis In-Reply-To: <6.2.5.6.2.20130916014542.0b496658@elandnews.com> Date: Wed, 18 Sep 2013 11:20:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6F17786D-77A9-4B15-BA6B-FFA40E1E02D6@gmail.com> References: <6FC7A544-0AB5-4BC0-A0BF-D0D8D740D3B8@gmail.com> <6.2.5.6.2.20130916014542.0b496658@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1508) Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Pete Resnick , ietf@ietf.org, Scott Kitterman Subject: Re: [spfbis] Macro Expansion (was: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard) 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, 18 Sep 2013 18:20:26 -0000 Dear SM, See comments inline. On Sep 16, 2013, at 9:00 AM, S Moonesamy wrote: > Hi Doug, > At 21:55 11-09-2013, Douglas Otis wrote: >> Add to: >> 11.5.3. Macro Expansion >> ,--- >> It is not within SPF's purview whether IPv6 or DNSSEC is being used. = IPv6 (RFC2460) increased the minimum MTU size to 1280 octets. DNSSEC is = deployed with EDNS0 (RFC6891) to avoid TCP fallback. EDNS0 suggests an = MTU increase between 1280 and 1410 octets offers a reasonable result = starting from a request of 4096 octets. A 1410 MTU offers a 2.4 times = payload increase over the assumed MTU of 576 octets and is widely = supported by Customer Premise Equipment. With increased MTUs being used = with DNS over UDP, network amplification concerns increase accordingly. >>=20 >> SPF macros can utilize SPF parameters derived from email messages = that can modulate the names being queried in several ways without = publishing additional DNS resources. The SPF macro feature permits = malefactors a means to covertly orchestrate directed DDoS attacks from = an array of compromised systems while expending little of their own = resources. >>=20 >> Since SPF does not make use of a dedicated resource record type or = naming convention, this leaves few solutions available to DNS operations = in offering a means to mitigate possible abuse. This type of abuse = becomes rather pernicious when used in conjunction with synthetic = domains now popular for tracking users without using web cookies. >>=20 >> However, email providers can mitigate this type of abuse by ignoring = SPF records containing macros. Very few domains make use of macros, and = ignoring these records result in neutral handling. Some large providers = have admitted they make use of this strategy without experiencing any = notable problem. AOL began their support of SPF by saying they would = use SPF to construct whitelists prior to receipt of email. Clearly, = such whitelisting practices tends to preclude benefits derived from = macro use. >> '--- >=20 > As background information I read draft-otis-spfbis-macros-nixed-01. I = read the messages where EDNS0 was mentioned [1]. I read the messages on = the thread starting with msg-id: = 9884B9CD-0ED3-4D89-A100-58D05EA4BC98@gmail.com. I have followed the = discussions about macros ever since the SPFBIS WG was chartered. >=20 > The above suggestion is to add text in the Security Considerations = section of the draft. The problem being pointed out is, in simple = terms, DNS amplification. The first (quoted) paragraph argues that = there can be an acute problem because of EDNS0 as specified in the = Internet Standard. >=20 > The second paragraph starts with SPF macros can utilize SPF parameters = derived from email messages". I do not understand that. =46rom what I = understand the rest of the second (quoted) paragraph argues that the SPF = macro feature permits evildoers to use it as an attack vector. Since this was not understood, I'll attempt to clarify. An effort to = keep these conversations fairly concise seems to lead to a level of = confusion with those not familiar with DNS. DNS UDP traffic lacks congestion avoidance when used to covertly direct = attacks. Residential systems represent a large component of compromised = systems involved with email although data centers measured by overall = traffic is increasing. Network amplification is measured by gains = beyond exchanges initiating a higher volume of exchanges. DNS caching = tends to reduce subsequent exchanges. SPFbis macros inhibit normal = caching protections by imposing mechanisms not directly supported by DNS = and having targets constructed from email message components. SPFbis = mechanism names can be misleading since they are given a related = manipulated DNS resource name. One SPFbis mechanism can represent more = than 100 subsequent DNS transactions where normally resolving the = resource would represent a single transaction. Publishing new targets = within DNS resources to circumvent caching would normally be expensive = and unlikely to provide remarkable gain. SPFbis macros change this = equation significantly. SPFbis offers macros to translate code points, = restructure host labels, build labels from the client IP address, make = use of the local-part of the message return path or some label in the = EHLO hostname, etc. In other words, SPFbis macros permit malefactors a means to modulate the = target of their queries while still leveraging their own cached DNS = records. This means a malefactors' DNS resources can be highly = leveraged as a result of recipient SPFbis macro processing. Secondly, = SPFbis also ignores the overall size of the resources being queried in = many cases. The most egregious is perhaps that of the unlimited PTR = RRsets which then results in a series of address RRset resolutions = cascading down the hostname labels that happens for a maximum of 10 PTRs = that might be offered on either a random or round robin basis. It would = be extremely difficult to determine the number of transactions and = overall traffic volume any single PTR mechanism might impose, for = example.=20 > The argument in the third (quoted) paragraph is that it is not = possible to mitigate possible (DNS) abuse due to the SPF as it does not = have a dedicated resource record type. Or a naming convention that might support mitigation efforts. > The fourth (quoted) paragraph argues that macros should be ignored. = That paragraph also mentions that some large providers admitted to using = that strategy. I am not aware of any public reports about that. As was said, AOL made their use of prefetching of SPF public at the = beginning which precluded use of macros. Others have also adopted this = practice but have not made their use public. > I read draft-otis-spfbis-macros-nixed-01 again to try and understand = the problem. It seems to be the: >=20 > '{%l}._spf.{%d} or exists:{%i}_spf.{%d} can be used in "specialized" > DNS servers able to understand encrypted local-parts' There is nothing in SPFbis that limits the structured use of DNS = resources. In this example, it shows the expansion of the return path = local-part, which represents a non-suspicious variable not derived from = DNS, that can increase the leverage obtained in DNS related attacks. A = similar attack might manipulate HELO hostname or MAIL FROM domain = labels as well.=20 > which is discussed in Appendix E of draft-ietf-spfbis-4408bis-20. >=20 > Arthur Thisell commented about the "specialized DNS server". He = mentioned that at the time that text was written two people came forward = to say that they were doing that. During the SPFBIS discussions nobody = stated that he or she has implemented or is using a "specialized" DNS = server. >=20 > I'll ask the person editing draft-ietf-spfbis-4408bis or the SPFBIS WG = to provide some publicly verifiable cases where these examples are used. >=20 > I assume that the SPFBIS WG and the Responsible Area Director have = understood the mathematics relating to EDNS0 and DNS amplification. = Anyone who has not understood that part is welcome to raise the issue on = the SPFBIS mailing list. >=20 > The discussion about the "dedicated resource record type" has led to = agreement. I'll describe the agreement as something people can live = with. In my opinion it is better not to start another discussion about = that. >=20 > I hope that what I wrote above clearly explains what I have understood = and what I have not understood. >=20 > Regards, > S. Moonesamy (as document shepherd) Regards, Douglas Otis From presnick@qti.qualcomm.com Wed Sep 18 11:49: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 D279611E810B; Wed, 18 Sep 2013 11:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.407 X-Spam-Level: X-Spam-Status: No, score=-106.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 Rw1uvUhl9-Et; Wed, 18 Sep 2013 11:49:55 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEE511E8108; Wed, 18 Sep 2013 11:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1379530195; x=1411066195; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Ta580HfYO2qfxSmiK6AodmwdJozZpBRb7NGINPGSCFo=; b=FSaFTpz6BBvcIbAyhY27wShnSCEy1FKsBRkBiBnd1olE/kig72+TUptM kqJ0QGh5VpuKtalL03eTezC6/pGjHYB6tLKMMCOUyh1phq8WnTuQyTk8J etrriZIDzPUMI9QSLpTdagKHXp5x4EKTBfIR3Bu2tATQ0SBYHXcLTQAQn s=; X-IronPort-AV: E=McAfee;i="5400,1158,7202"; a="75363869" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 18 Sep 2013 11:49:55 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7202"; a="539263502" Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Sep 2013 11:49:55 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc12.na.qualcomm.com (172.30.39.187) with Microsoft SMTP Server (TLS) id 14.3.146.2; Wed, 18 Sep 2013 11:49:54 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.146.2; Wed, 18 Sep 2013 11:49:54 -0700 Message-ID: <5239F5D0.50600@qti.qualcomm.com> Date: Wed, 18 Sep 2013 13:49:52 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Douglas Otis X-Priority: 2 (High) References: <6FC7A544-0AB5-4BC0-A0BF-D0D8D740D3B8@gmail.com> <6.2.5.6.2.20130916014542.0b496658@elandnews.com> <6F17786D-77A9-4B15-BA6B-FFA40E1E02D6@gmail.com> In-Reply-To: <6F17786D-77A9-4B15-BA6B-FFA40E1E02D6@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Scott Kitterman , S Moonesamy , ietf@ietf.org Subject: Re: [spfbis] Macro Expansion 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, 18 Sep 2013 18:50:00 -0000 Posting as the responsible AD for the document in question. On 9/18/13 1:20 PM, Douglas Otis wrote: > Since this was not understood, I'll attempt to clarify. An effort to keep these conversations fairly concise seems to lead to a level of confusion with those not familiar with DNS. > I'm afraid I'm going to have to end this thread here and now. The problem is not that Doug has tried to keep his explanations concise, or that people are not familiar with the DNS and therefore confused. The latter may or may not be true, but the problem here is precisely that Doug has failed to keep things concise and on point. This is not meant as an insult to Doug, and I apologize to him publicly just in case he feels offended. It is simply the fact that he is unable to clearly and concisely explain to others the security problem he believes exists in this protocol. For example: > SPFbis macros inhibit normal caching protections by imposing mechanisms not directly supported by DNS and having targets constructed from email message components. Doug never explains in this sentence *what* the mechanisms are the SPFbis macros are using, he never explains *in what way* those mechanisms are not supported by the DNS, he never explains *how* use of these mechanisms inhibits caching, and never gives an example of *how* the targets (I presume attack targets) are constructed. After a long conversation with Doug, I *think* I may understand what he's raising. I *suspect* the issue could be addressed by a sentence or two added to 11.5.3 or, more likely, to the third and fourth bullet of 11.1. But I'm not sure, and even after that long conversation, I was unable to get a clean explanation of the problem or reasonable text for a solution. So, barring further information, I am simply forced to say that Doug is going to be in the rough part of the consensus. If someone else thinks they will be able to clearly and concisely characterize the problem and propose some text, I welcome such suggestions, though I ask that you communicate first with the SPFBIS chairs and/or myself to make sure that we all understand the specifics. We are far past the point of diminishing returns now, and I do not wish further disruption to either the IETF list or the SPFBIS list on this topic. Again, I intend no insult to Doug, and I again apologize to him for having to take this step publicly. I hope, if there is a problem here that needs to be noted, that Doug can work with someone else so that we can improve the document. Thanks. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From SRS0=Kz+Z0=S6==stuart@gathman.org Wed Sep 18 13:36: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 DA9BE11E8111 for ; Wed, 18 Sep 2013 13:36:37 -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 ty-7Um-bzjC2 for ; Wed, 18 Sep 2013 13:36:36 -0700 (PDT) Received: from mail.gathman.org (gathman.marcomm.net [IPv6:2001:470:8:688::10]) by ietfa.amsl.com (Postfix) with ESMTP id B26ED11E8138 for ; Wed, 18 Sep 2013 13:36:20 -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=1379536585; h=Message-ID : Date : From : MIME-Version : To : Subject : References : In-Reply-To : Content-Type : Content-Transfer-Encoding : Date : From : Subject; bh=lqFTjrm5gWvKyIQkBVEr1VgCSbuKlR1A49Q7PfXrWD8=; b=gqWmBO69/qMfVPqu76QVI7BaHQo6TOZhQk7pdJib0fTEGD5c1wNEtJP9d5aWkVGoLhP9J/ XvUGnYYsuQUSkhLqZT3KbnL0kkQCDB6NTiK8tbVACLJLLq0Z6P/oVrGiA4xo7fc11PXdKf8y sCM12YkzlOchB+ASewgCC6GMjuaBY= Received: from silver.gathman.org ([IPv6:2001:470:8:809:11::1015]) (authenticated bits=0) by mail.gathman.org (8.14.4/8.14.4) with ESMTP id r8IKaIs5027492 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 18 Sep 2013 16:36:24 -0400 Message-ID: <523A0EBA.6040104@gathman.org> Date: Wed, 18 Sep 2013 16:36:10 -0400 From: Stuart Gathman Organization: BWI Corporation User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: spfbis@ietf.org References: <6FC7A544-0AB5-4BC0-A0BF-D0D8D740D3B8@gmail.com> <6.2.5.6.2.20130916014542.0b496658@elandnews.com> <6F17786D-77A9-4B15-BA6B-FFA40E1E02D6@gmail.com> <5239F5D0.50600@qti.qualcomm.com> In-Reply-To: <5239F5D0.50600@qti.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Macro Expansion 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, 18 Sep 2013 20:47:29 -0000 On 09/18/2013 02:49 PM, Pete Resnick wrote: > > I'm afraid I'm going to have to end this thread here and now. The > problem is not that Doug has tried to keep his explanations concise, > or that people are not familiar with the DNS and therefore confused. > The latter may or may not be true, but the problem here is precisely > that Doug has failed to keep things concise and on point. This is not > meant as an insult to Doug, and I apologize to him publicly just in > case he feels offended. It is simply the fact that he is unable to > clearly and concisely explain to others the security problem he > believes exists in this protocol. For example: > >> SPFbis macros inhibit normal caching protections by imposing >> mechanisms not directly supported by DNS and having targets >> constructed from email message components. > > Doug never explains in this sentence *what* the mechanisms are the > SPFbis macros are using, he never explains *in what way* those > mechanisms are not supported by the DNS, he never explains *how* use > of these mechanisms inhibits caching, and never gives an example of > *how* the targets (I presume attack targets) are constructed. > Most macros are harmless, but the localpart macro is "constructed from email components" as is the helo macro. In particular, a malicious sender can vary the localpart with every MAIL FROM on the same connection, causing a unique set of DNS lookups when SPF is checked. (The HELO can only be varied every connection.) Of course, in real life, unless the malicious sender manages to actually send some mail (in which case the "amplification" aspect is moot), the IP is banned after a handful of attempts at such nonsense. From johnl@iecc.com Wed Sep 18 15:39: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 3394C11E81C6 for ; Wed, 18 Sep 2013 15:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 XX-rP3YxicWH for ; Wed, 18 Sep 2013 15:39:54 -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 0377F11E81A1 for ; Wed, 18 Sep 2013 15:39:53 -0700 (PDT) Received: (qmail 1680 invoked from network); 18 Sep 2013 22:39:48 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Sep 2013 22:39:48 -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=523a2bb4.xn--btvx9d.k1309; i=johnl@user.iecc.com; bh=7tSHvsYVoM9/lZbbF+9HDxEqhuUZofGUiV7Ge2SzyfI=; b=KTLoJnggfQCB5YaZa0+4NSGK2/TyNQ2m0UYt4rctJ2m4HKcmHFjP/k+qeto5qQ5TrGcP6g2O/mNF8qcjEVKdOWipxAxmfNs8iiPvKZbabFa3fIgySsUn6wvhcFq5TzRySI77abcaHdlQrMFyuX3mNCvpN/62dSx245JZOOnfiIeHq2IXUrXikppVEwwc5PjZ1hY9QkArjazLgN5a6COvwPw92+wJxaAKWF46PGhB9FxD52ZP69s7zmfb4FjhMOUR 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=523a2bb4.xn--btvx9d.k1309; olt=johnl@user.iecc.com; bh=7tSHvsYVoM9/lZbbF+9HDxEqhuUZofGUiV7Ge2SzyfI=; b=YREesJJ2GRqh+XmFyZiPHqHAiZlPOjqqMQo0if3tXGEuHavCEVNXCANx5PXYRE3Sada7pys84RH+V+Sok/9xRHRdKrmupuM603BdUilRMUsNH3fZ6M4v35Q37xEQ8QtkEHvnE/1GjmuRy/urVmb5DpmqDu96bE/uvh24GnpjpS2y+gyvH4aEVHbPnh4jy6qZaQ5imdkSnG2jX3CWnL46EB0gIl5Bu2U8jSZmGmwgKu/i6jlPYMZND1v4yOvhMHOB Date: 18 Sep 2013 22:39:25 -0000 Message-ID: <20130918223925.10877.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <523A0EBA.6040104@gathman.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: stuart@gathman.org Subject: Re: [spfbis] Macro Expansion 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, 18 Sep 2013 22:39:59 -0000 >Most macros are harmless, but the localpart macro is "constructed from >email components" as is the helo macro. In particular, a malicious >sender can vary the localpart with every MAIL FROM on the same >connection, causing a unique set of DNS lookups when SPF is checked. >(The HELO can only be varied every connection.) Sheesh. That's on a par with putting fake DKIM signatures with random selectors on your spam. Yes, it causes some DNS traffic, but there are much easier ways to provoke DNS floods if that's what you want to do. Enough, already. From spf2@kitterman.com Sun Sep 22 21:27: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 C191211E816F for ; Sun, 22 Sep 2013 21:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.07 X-Spam-Level: X-Spam-Status: No, score=0.07 tagged_above=-999 required=5 tests=[AWL=-2.232, BAYES_50=0.001, HTML_MESSAGE=0.001, MANGLED_SAVELE=2.3] 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 V5aiitDZw0qW for ; Sun, 22 Sep 2013 21:26:58 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8C95711E80D7 for ; Sun, 22 Sep 2013 21:26:57 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B558E20E4124; Mon, 23 Sep 2013 00:26:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1379910414; bh=vfbEqKqIHfOeggArvWnwVXLAMhc1caGYnT6XOrxvCeg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kdiKMQ9VYud2u2D4MY5aWrUbvrhxpczE1HWXzDxts6nKXHn7WHSK+vChp7Lu3ughf RPZP6ca9QdBTqkUYbbNjFnm++EL1NxcEmq/PAfi5CJNYdI+Zbvu7UM+mdGuZT4gAG0 LECzHZwBpgB7xMu95ICpotG5cipPmQlBkPkXCBEE= 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 9154820E4099; Mon, 23 Sep 2013 00:26:54 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 23 Sep 2013 00:26:53 -0400 Message-ID: <5681464.EQGBnZhqiI@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <1409783.xNJeGdWPul@scott-latitude-e6320> References: <20130911015837.30196.11175.idtracker@ietfa.amsl.com> <1409783.xNJeGdWPul@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart2989640.dMaItEDoA5" Content-Transfer-Encoding: 7Bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 23 Sep 2013 04:27:03 -0000 This is a multi-part message in MIME format. --nextPart2989640.dMaItEDoA5 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Finally getting back to addressing additional comments. I have it in my notes that we hadn't addressed the comment part of this in -20. Based on the comments I previously sent to the list, I'm attaching my proposed changes (so far - there are more messages needing processing) for -21. Additional comments embedded below. Scott K On Wednesday, September 11, 2013 17:38:27 Scott Kitterman wrote: > On Wednesday, September 11, 2013 10:23:57 Murray S. Kucherawy wrote: > > On Wed, Sep 11, 2013 at 5:04 AM, S Moonesamy wrote: > > >> ------------------------------**------------------------------** > > >> ---------- > > >> COMMENT: > > >> ------------------------------**------------------------------** > > >> ---------- > > >> > > >> I have a bunch of editorial comments that I'd like you to consider. > > >> They're all non-blocking, but I think they'll improve the document, and > > >> I'll be happy to chat about them if you like. > > >> > > >> -- Section 2.5 -- > > >> > > >> Performing the authorization check other than using the MAIL FROM > > >> and > > >> client address at the time of the MAIL command during the SMTP > > >> transaction can cause problems, such as the following: (1) It might > > >> be difficult to accurately extract the required information from > > >> potentially deceptive headers; (2) legitimate email might fail > > >> because the sender's policy had since changed. > > >> > > >> I found that to be awkwardly worded and hard to understand. Please > > >> consider this rewrite: > > >> > > >> NEW > > >> > > >> The authorization check is performed during the SMTP transaction > > >> at the time of the MAIL command, and uses the MAIL FROM value and > > >> the client IP address. Performing the check at later times or > > >> with other input can cause problems such as the following: > > >> > > >> * It might be difficult to accurately extract the required > > >> > > >> information from potentially deceptive headers. > > >> > > >> * Legitimate email might fail the authorization check because > > >> > > >> the sender's policy has since changed. > > >> > > >> END > > > > Seems reasonable. > > Agreed. Done. > > >> -- Section 2.6 -- > > >> > > >> It would really read best if the subsections were worded to be > > >> parallel. > > >> As it stands, subsections 1, 3, 4, 6, and 7 are worded as "result X > > >> means > > >> Y", and subsections 2 and 5 are not. Can you re-word 2 and 5 to be > > >> parallel to the others? > > > > Seems reasonable. > > Agreed. Done. > > >> Also, why are "neutral" and "fail" called "explicit statements", but > > >> "pass", for example, is not? > > > > I agree, "pass" should be. > > Yep. Done. > > >> -- Section 3 -- > > >> > > >> Each SPF record is placed in the DNS tree at the owner name it > > >> pertains to, not a subdomain under it, such as is done with SRV > > >> records [RFC2782]. > > >> > > >> This looks like it's saying that SRV records are placed in subdomains, > > >> and I don't think that's what you mean. Or is it? In any case, it's > > >> not > > >> clear (and I know this text is from the original). > > >> > > >> Maybe this (which also avoids the two different "it"s)?: > > >> > > >> NEW > > >> > > >> Each SPF record is placed in the DNS tree at the owner name it > > >> pertains to, not in a subdomain under the owner name. This is > > >> similar to how SRV records [RFC2782] are done. > > >> > > >> END > > > > Seems reasonable. > > Agreed. Done. > > >> The example in this section might be published via these lines in a > > >> > > >> domain zone file: > > >> example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" > > >> smtp-out.example.com. TXT "v=spf1 a -all" > > >> > > >> What does "smtp-out" have to do with anything? It's not otherwise > > >> used, > > >> and it seems to contradict what you say about subdomains in the > > >> previous > > >> paragraph. > > > > Hmm. Someone else will have to comment on this one. > > Those are just two examples, but the preceding text is poorly worded (I > checked and it's no better in RFC 4408). How about this instead, to > clarify: > > The example in this section (plus an additional SPF record for > smtp-out.example.com) might be published via these lines in a > domain zone file: > > example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" > smtp-out.example.com. TXT "v=spf1 a -all" Already fixed in -20. > > >> -- Section 4 -- > > >> > > >> This description is not an API (Application Program Interface) > > >> definition, > > >> > > >> Two total nits on this: > > >> 1. You never use "API" other than here, so there's no need to define > > >> it, > > >> and > > >> 2. the usual expansion of "API" is application programMING interface. > > >> I suggest, "This description is not an application programming > > >> interface > > >> definition, [etc]." > > > > Seems reasonable. > > Agreed. Done. > > >> -- Section 4.5 -- > > >> > > >> Starting with the set of records that were returned by the lookup, > > >> discard records that do not begin with a version section of exactly > > >> "v=spf1". Note that the version section is terminated either by an > > >> SP character or the end of the record. A record with a version > > >> section of "v=spf10" does not match and is discarded. > > >> > > >> Sure, and "v=spf1.0" doesn't match, and "v=spf11" doesn't match, > > >> and.... > > >> Why is it necessary or desirable to single out "v=spf10" here? > > > > I think "v=spf1.0" is actually the better (and perhaps intended) example, > > meaning "don't just stuff the part after 'spf' through a number parser and > > make sure 1 comes out". > > The intent here is to show that you have to look at least one character past > "v=spf1" to know if it's an SPF record or not. It's an example. As such, > it doesn't matter much wrt the point if it's "v=spf10", "v=spf1.0", or or > "v=spf1hatespf". None of those start SPF records. What's there is > unchanged from RFC 4408. I don't seem much of a point in changing it, but > if others think 1.0 is better than 10, I don't mind. There was already a change for this in -20. > > >> -- Section 4.6.4 -- > > >> > > >> SPF implementations MUST limit the total number of mechanisms and > > >> modifiers ("terms") that cause any DNS query to 10 during SPF > > >> evaluation. Specifically, the "include", "a", "mx", "ptr", and > > >> "exists" mechanisms as well as the "redirect" modifier count against > > >> this collective limit. The "all", "ip4", and "ip6" mechanisms do > > >> not > > >> count against this limit. If this number is exceeded during a > > >> check, > > >> a "permerror" MUST be returned. The "exp" modifier does not count > > >> against this limit because the DNS lookup to fetch the explanation > > >> string occurs after the SPF record evaluation has been completed. > > >> > > >> When I read this, I start feeling like I'm being read the rules for > > >> Fizzbin > > >> > >> / > > >> wiki/Fizzbin#Fizzbin>>.>> > > >> > > >> I would > > >> appreciate it if this was re-worded so that there are two clear lists > > >> here: the terms that are included in the "limit of 10", and the terms > > >> that are not (and are, presumably, unlimited). Perhaps something like > > >> this: > > >> > > >> NEW > > >> > > >> Some mechanisms and modifiers (collectively, "terms") cause DNS > > >> queries at the time of evaluation, and some do not. The following > > >> terms cause DNS queries: . SPF implementations > > >> MUST limit the total number of those terms to 10 during SPF > > >> evaluation, to avoid unreasonable load on the DNS. If this limit > > >> is exceeded, the implementation MUST return "permerror". The other > > >> terms () do not cause DNS queries at the time of > > >> SPF evaluation, and their use is not subject to this limit. > > >> > > >> END > > >> > > >> If you think it's necessary (I don't): > > >> > > >> NEW+ > > >> > > >> The other > > >> terms () do not cause DNS queries at the time of > > >> SPF evaluation (the "exp" modifier causes a lookup at a later time), > > >> and their use is not subject to this limit. > > >> > > >> END > > > > I like the new text, and prefer the second bit be included. > > If we change, and I think that's reasonable, the second bit should > definitely be included. "exp" not counting in the 10 has confused people > and we should be explicit about it. Done. > > >> Then in the next two paragraphs, I think it would improve clarity to > > >> make > > >> a change such as this: > > >> > > >> OLD > > >> > > >> When evaluating the "mx" mechanism, the number of "MX" resource > > >> records queried is included in the overall limit of 10 mechanisms/ > > >> modifiers that cause DNS lookups described above. The evaluation of > > >> each "MX" record MUST NOT result in querying more than 10 address > > >> records, > > >> > > >> NEW > > >> > > >> When evaluating the "mx" mechanism, the number of "MX" resource > > >> records queried is included in the overall limit of 10 mechanisms/ > > >> modifiers that cause DNS lookups described above. In addition to > > >> that limit, the evaluation of each "MX" record MUST NOT result in > > >> querying more than 10 address records, > > >> > > >> END > > >> > > >> (And similarly for the "ptr" paragraph.) I know you say this in a > > >> paragraph of its own ("These limits are per mechanism..."), but it's > > >> helpful if people can understand things as they read them, and then to > > >> emphasize it later... rather than having them scratch their heads for a > > >> few paragraphs until they get to it. > > > > +1 to that part too. > > Seems reasonable. Done. > > > -- Section 4.7 -- > > > > > >> It is better to use either a "redirect" modifier or an "all" > > >> mechanism to explicitly terminate processing. Although the latter > > >> has a default (specifically "?all"), it aids debugging efforts if it > > >> is explicitly provided. > > >> > > >> I'm not sure what "the latter has a default" is trying to say. Do you > > >> mean that "?all" is the default if you fall off the end, but you > > >> shouldn't rely on that? Or do you mean that if you say "all", then > > >> "?all" is taken as the default (I would think "all" would mean "+all")? > > >> Will you try re-wording this, please? > > > > The former ("?all" is implicit if you fall off the end). Suggest: > > > > It is better to use either a "redirect" modifier or an "all" mechanism to > > explicitly terminate processing. Although there is in effect a "?all" > > implicit at the end of every record, it ads debigging efforts when it is > > explicitly provided. > > How about: > > It is better to use either a "redirect" modifier or an "all" mechanism to > explicitly terminate processing. Although there is an implicit "?all" at > the end of every record that is not explicitly terminated, it aids > debugging efforts when it is explicitly provided. This was changed in -20. > > >> -- Section 5 -- > > >> > > >> What does "(do not publish)" mean next to "ptr" in the sender > > >> mechanisms > > >> list? Ah; I see; it matches the "do not use" in Section 5.5. You > > >> should > > >> probably change this to "(do not use; see the note in Section 5.5)". > > > > Seems reasonable. > > OK. Done. > > >> It would help, I think, to add to the end of the second paragraph, "The > > >> basic mechanisms are as follows:", and to the end of the third > > >> paragraph, > > >> "The designated sender mechanisms are as follows:". Otherwise, there > > >> are > > >> just these disembodied lists, and the reader has to infer those > > >> introductions. > > > > Sure. > > Agreed. Done. > > >> -- Section 5.1 -- > > >> > > >> Mechanisms after "all" will never be tested. Mechanisms listed > > >> after > > >> "all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST > > >> be > > >> ignored when there is an "all" mechanism in the record. > > >> > > >> This says that the redirect in the following record will be ignored: > > >> v=spf1 redirect=_spf.example.com +all > > >> > > >> That's sufficiently odd that it should be called out explicitly, > > >> perhaps > > >> by adding "regardless of the relative ordering of the terms" to the > > >> last > > >> sentence in the quote. > > > > Yep. > > OK. Done. > > >> -- Section 5.2 -- > > >> > > >> 3. The recursive evaluation returns either match, not match, or an > > >> > > >> error. If it matches, then the appropriate result for the > > >> include: mechanism is used (e.g. include or +include produces a > > >> "pass" result and -include produces "fail"). > > >> > > >> 4. If there is no match, the parent check_host() resumes processing > > >> > > >> as per the table below, with the previous value of > > >> restored. > > >> > > >> A few things here: > > >> > > >> 1. Nit: "either" is for two things; for more than two, please remove > > >> the > > >> word "either" (or replace it with "one of", but that seems awkward > > >> here). > > >> > > >> 2. "If it matches" is not parallel to "returns match", and similarly > > >> for > > >> "if there is no match". > > >> > > >> 3. You don't say what happens if the recursive evaluation returns an > > >> error. Unfortuately, "no match" and "not match" are sufficiently > > >> similar > > >> to be confused. > > >> > > >> I suggest this: > > >> > > >> NEW > > >> > > >> 3. The recursive evaluation returns match, not match, or an > > >> > > >> error. > > >> > > >> 4. If it returns match, then the appropriate result for the > > >> > > >> include: mechanism is used (e.g., include or +include produces > > >> a "pass" result and -include produces "fail"). > > >> > > >> 5. If it returns not match or an error, the parent check_host() > > >> > > >> resumes processing as per the table below, with the previous > > >> value of restored. > > >> > > >> END > > > > +1. > > I think this is fine. Done. > > >> The "include" mechanism is intended for crossing administrative > > >> boundaries. For example, if example.com and example.org were > > >> managed > > >> by the same entity, and if the permitted set of hosts for both > > >> domains was "mx:example.com", it would be possible for example.org > > >> to > > >> specify "include:example.com", but it would be preferable to specify > > >> "redirect=example.com" or even "mx:example.com". > > >> > > >> The text you eliminated here provided a buffer that's no longer there, > > >> making the "For example," very odd. You talk about crossing admin > > >> boundaries and immediately follow it with an example that does NOT. I > > >> think it would be better to put a sentence in to restore that buffer -- > > >> perhaps, "When remaining within one administrative authority, "include" > > >> is usually not the best choice." > > > > Sure. > > Agreed. Done. > > >> -- Section 5.5 -- > > >> > > >> This mechanism SHOULD NOT be published. See below for discussion. > > >> > > >> It's quite a bit below. I suggest "See the note at the end of this > > >> section for more information." It might even be worth putting that > > >> note > > >> into a Section 5.5.1, so it's highlighted and more easily cited. > > > > +1. > > OK. Someone let me know which way I should do it. I'm OK with either. The first option was done in -20. > > >> -- Section 6 -- > > >> > > >> Unrecognized modifiers MUST be ignored no matter where in a record, > > >> or how often. > > >> > > >> This is missing a couple of words: > > >> > > >> NEW > > >> > > >> Unrecognized modifiers MUST be ignored no matter where in a record > > >> they appear, or how often. > > >> > > >> END > > > > +1. > > OK. Done. > > >> For clarity, any "redirect" modifier SHOULD appear as the very last > > >> term in a record. > > >> > > >> I don't usually recommend repeating things, but one thing from earlier > > >> probably does bear repeating here: > > >> > > >> NEW > > >> > > >> For clarity, any "redirect" modifier SHOULD appear as the very last > > >> term in a record. Any "redirect" modifier MUST be ignored if there > > >> is an "all" mechanism anywhere in the record. > > >> > > >> END > > > > Seems reasonable. > > OK. > > Thanks for the detailed review and msk's comments on the comments. > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis --nextPart2989640.dMaItEDoA5 Content-Disposition: attachment; filename="draft-ietf-spfbis-4408bis-21-from-20.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="draft-ietf-spfbis-4408bis-21-from-20.diff.html" Diff: draft-ietf-spfbis-4408bis-20.txt - draft-ietf-spfbis-4408bis-21.txt
 draft-ietf-spfbis-4408bis-20.txt   draft-ietf-spfbis-4408bis-21.txt 
Network Working Group S. Kitterman Network Working Group S. Kitterman
Internet-Draft Kitterman Technical Services Internet-Draft Kitterman Technical Services
Obsoletes: 4408 (if approved) September 12, 2013 Obsoletes: 4408 (if approved) September 23, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: March 16, 2014 Expires: March 27, 2014
Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email,
Version 1 Version 1
draft-ietf-spfbis-4408bis-20 draft-ietf-spfbis-4408bis-21
Abstract Abstract
Email on the Internet can be forged in a number of ways. In Email on the Internet can be forged in a number of ways. In
particular, existing protocols place no restriction on what a sending 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 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 SMTP HELO/EHLO commands. This document describes version 1 of
the Sender Policy Framework (SPF) protocol, whereby ADministrative the Sender Policy Framework (SPF) protocol, whereby ADministrative
Management Domains (ADMDs) can explicitly authorize the hosts that Management Domains (ADMDs) can explicitly authorize the hosts that
are allowed to use its domain names, and a receiving host can check are allowed to use its domain names, and a receiving host can check
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 16, 2014. This Internet-Draft will expire on March 27, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 20 skipping to change at page 3, line 20
1.1.2. Imported Definitions . . . . . . . . . . . . . . . . . 6 1.1.2. Imported Definitions . . . . . . . . . . . . . . . . . 6
1.1.3. MAIL FROM Definition . . . . . . . . . . . . . . . . . 7 1.1.3. MAIL FROM Definition . . . . . . . . . . . . . . . . . 7
1.1.4. HELO Definition . . . . . . . . . . . . . . . . . . . 7 1.1.4. HELO Definition . . . . . . . . . . . . . . . . . . . 7
1.2. check_host() . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. check_host() . . . . . . . . . . . . . . . . . . . . . . . 7
2. Operational Overview . . . . . . . . . . . . . . . . . . . . . 8 2. Operational Overview . . . . . . . . . . . . . . . . . . . . . 8
2.1. Publishing Authorization . . . . . . . . . . . . . . . . . 8 2.1. Publishing Authorization . . . . . . . . . . . . . . . . . 8
2.2. Checking Authorization . . . . . . . . . . . . . . . . . . 8 2.2. Checking Authorization . . . . . . . . . . . . . . . . . . 8
2.3. The "HELO" Identity . . . . . . . . . . . . . . . . . . . 9 2.3. The "HELO" Identity . . . . . . . . . . . . . . . . . . . 9
2.4. The "MAIL FROM" Identity . . . . . . . . . . . . . . . . . 10 2.4. The "MAIL FROM" Identity . . . . . . . . . . . . . . . . . 10
2.5. Location of Checks . . . . . . . . . . . . . . . . . . . . 10 2.5. Location of Checks . . . . . . . . . . . . . . . . . . . . 10
2.6. Results of Evaluation . . . . . . . . . . . . . . . . . . 10 2.6. Results of Evaluation . . . . . . . . . . . . . . . . . . 11
2.6.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.6. Temperror . . . . . . . . . . . . . . . . . . . . . . 11 2.6.6. Temperror . . . . . . . . . . . . . . . . . . . . . . 11
2.6.7. Permerror . . . . . . . . . . . . . . . . . . . . . . 11 2.6.7. Permerror . . . . . . . . . . . . . . . . . . . . . . 12
3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. DNS Resource Records . . . . . . . . . . . . . . . . . . . 12 3.1. DNS Resource Records . . . . . . . . . . . . . . . . . . . 13
3.2. Multiple DNS Records . . . . . . . . . . . . . . . . . . . 13 3.2. Multiple DNS Records . . . . . . . . . . . . . . . . . . . 14
3.3. Multiple Strings in a Single DNS record . . . . . . . . . 13 3.3. Multiple Strings in a Single DNS record . . . . . . . . . 14
3.4. Record Size . . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Record Size . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Wildcard Records . . . . . . . . . . . . . . . . . . . . . 14 3.5. Wildcard Records . . . . . . . . . . . . . . . . . . . . . 15
4. The check_host() Function . . . . . . . . . . . . . . . . . . 16 4. The check_host() Function . . . . . . . . . . . . . . . . . . 17
4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 17 4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 18
4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 17 4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 18
4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 17 4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 18
4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 17 4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 18
4.6.1. Term Evaluation . . . . . . . . . . . . . . . . . . . 18 4.6.1. Term Evaluation . . . . . . . . . . . . . . . . . . . 19
4.6.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 18 4.6.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 19
4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 19 4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 20
4.6.4. DNS Lookup Limits . . . . . . . . . . . . . . . . . . 19 4.6.4. DNS Lookup Limits . . . . . . . . . . . . . . . . . . 20
4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 20 4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 21
4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 20 4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 21
5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 22 5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 23
5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.5. "ptr" (do not use) . . . . . . . . . . . . . . . . . . . . 25 5.5. "ptr" (do not use) . . . . . . . . . . . . . . . . . . . . 26
5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 27 5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 28
5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 28
6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 29 6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 30
6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 29 6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 30
6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 30 6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 31
7. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Formal Specification . . . . . . . . . . . . . . . . . . . 32 7.1. Formal Specification . . . . . . . . . . . . . . . . . . . 33
7.2. Macro Definitions . . . . . . . . . . . . . . . . . . . . 32 7.2. Macro Definitions . . . . . . . . . . . . . . . . . . . . 33
7.3. Macro Processing Details . . . . . . . . . . . . . . . . . 33 7.3. Macro Processing Details . . . . . . . . . . . . . . . . . 34
7.4. Expansion Examples . . . . . . . . . . . . . . . . . . . . 35 7.4. Expansion Examples . . . . . . . . . . . . . . . . . . . . 36
8. Result Handling . . . . . . . . . . . . . . . . . . . . . . . 37 8. Result Handling . . . . . . . . . . . . . . . . . . . . . . . 38
8.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.6. Temperror . . . . . . . . . . . . . . . . . . . . . . . . 39 8.6. Temperror . . . . . . . . . . . . . . . . . . . . . . . . 40
8.7. Permerror . . . . . . . . . . . . . . . . . . . . . . . . 39 8.7. Permerror . . . . . . . . . . . . . . . . . . . . . . . . 40
9. Recording the Result . . . . . . . . . . . . . . . . . . . . . 40 9. Recording the Result . . . . . . . . . . . . . . . . . . . . . 41
9.1. The Received-SPF Header Field . . . . . . . . . . . . . . 40 9.1. The Received-SPF Header Field . . . . . . . . . . . . . . 41
9.2. SPF Results in the Authentication-Results Header Field . . 42 9.2. SPF Results in the Authentication-Results Header Field . . 43
10. Effects on Infrastructure . . . . . . . . . . . . . . . . . . 44 10. Effects on Infrastructure . . . . . . . . . . . . . . . . . . 45
10.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 44 10.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 45
10.1.1. DNS Resource Considerations . . . . . . . . . . . . . 44 10.1.1. DNS Resource Considerations . . . . . . . . . . . . . 45
10.1.2. Administrator's Considerations . . . . . . . . . . . . 45 10.1.2. Administrator's Considerations . . . . . . . . . . . . 46
10.1.3. Bounces . . . . . . . . . . . . . . . . . . . . . . . 46 10.1.3. Bounces . . . . . . . . . . . . . . . . . . . . . . . 47
10.2. Receivers . . . . . . . . . . . . . . . . . . . . . . . . 46 10.2. Receivers . . . . . . . . . . . . . . . . . . . . . . . . 47
10.3. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 46 10.3. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 47
11. Security Considerations . . . . . . . . . . . . . . . . . . . 48 11. Security Considerations . . . . . . . . . . . . . . . . . . . 49
11.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 48 11.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 49
11.2. SPF-Authorized Email May Contain Other False Identities . 49 11.2. SPF-Authorized Email May Contain Other False Identities . 50
11.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 49 11.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 50
11.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 49 11.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 50
11.5. Untrusted Information Sources . . . . . . . . . . . . . . 50 11.5. Untrusted Information Sources . . . . . . . . . . . . . . 51
11.5.1. Recorded Results . . . . . . . . . . . . . . . . . . . 50 11.5.1. Recorded Results . . . . . . . . . . . . . . . . . . . 51
11.5.2. External Explanations . . . . . . . . . . . . . . . . 50 11.5.2. External Explanations . . . . . . . . . . . . . . . . 51
11.5.3. Macro Expansion . . . . . . . . . . . . . . . . . . . 51 11.5.3. Macro Expansion . . . . . . . . . . . . . . . . . . . 52
11.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 51 11.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 52
11.7. Delivering Mail Producing a 'Fail' Result . . . . . . . . 51 11.7. Delivering Mail Producing a 'Fail' Result . . . . . . . . 52
12. Contributors and Acknowledgements . . . . . . . . . . . . . . 52 12. Contributors and Acknowledgements . . . . . . . . . . . . . . 53
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
13.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 53 13.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 54
13.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 53 13.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 54
13.3. SPF Modifier Registry . . . . . . . . . . . . . . . . . . 53 13.3. SPF Modifier Registry . . . . . . . . . . . . . . . . . . 54
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
14.1. Normative References . . . . . . . . . . . . . . . . . . . 54 14.1. Normative References . . . . . . . . . . . . . . . . . . . 55
14.2. Informative References . . . . . . . . . . . . . . . . . . 55 14.2. Informative References . . . . . . . . . . . . . . . . . . 56
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 57 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 58
Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 60 Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 61
B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 60 B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 61
B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 61 B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 62
B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 62 B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 63
B.4. Multiple Requirements Example . . . . . . . . . . . . . . 62 B.4. Multiple Requirements Example . . . . . . . . . . . . . . 63
Appendix C. Changes in implementation requirements from RFC Appendix C. Changes in implementation requirements from RFC
4408 . . . . . . . . . . . . . . . . . . . . . . . . 63 4408 . . . . . . . . . . . . . . . . . . . . . . . . 64
Appendix D. Further Testing Advice . . . . . . . . . . . . . . . 64 Appendix D. Further Testing Advice . . . . . . . . . . . . . . . 65
Appendix E. SPF/Mediator Interactions . . . . . . . . . . . . . . 65 Appendix E. SPF/Mediator Interactions . . . . . . . . . . . . . . 66
E.1. Originating ADMDs . . . . . . . . . . . . . . . . . . . . 65 E.1. Originating ADMDs . . . . . . . . . . . . . . . . . . . . 66
E.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 66 E.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 67
E.3. Receving ADMDs . . . . . . . . . . . . . . . . . . . . . . 66 E.3. Receving ADMDs . . . . . . . . . . . . . . . . . . . . . . 67
Appendix F. Mail Services . . . . . . . . . . . . . . . . . . . . 67 Appendix F. Mail Services . . . . . . . . . . . . . . . . . . . . 68
Appendix G. MTA Relays . . . . . . . . . . . . . . . . . . . . . 68 Appendix G. MTA Relays . . . . . . . . . . . . . . . . . . . . . 69
Appendix H. Local Policy Considerations . . . . . . . . . . . . . 69 Appendix H. Local Policy Considerations . . . . . . . . . . . . . 70
H.1. Policy For SPF Pass . . . . . . . . . . . . . . . . . . . 69 H.1. Policy For SPF Pass . . . . . . . . . . . . . . . . . . . 70
H.2. Policy For SPF Fail . . . . . . . . . . . . . . . . . . . 69 H.2. Policy For SPF Fail . . . . . . . . . . . . . . . . . . . 70
H.3. Policy For SPF Permerror . . . . . . . . . . . . . . . . . 70 H.3. Policy For SPF Permerror . . . . . . . . . . . . . . . . . 71
H.4. Policy For SPF Temperror . . . . . . . . . . . . . . . . . 70 H.4. Policy For SPF Temperror . . . . . . . . . . . . . . . . . 71
Appendix I. Protocol Status . . . . . . . . . . . . . . . . . . . 72 Appendix I. Protocol Status . . . . . . . . . . . . . . . . . . . 73
Appendix J. Change History . . . . . . . . . . . . . . . . . . . 73 Appendix J. Change History . . . . . . . . . . . . . . . . . . . 74
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 77
1. Introduction 1. Introduction
The current email infrastructure has the property that any host The current email infrastructure has the property that any host
injecting mail into the system can use any DNS domain name it wants injecting mail into the system can use any DNS domain name it wants
in each of the various identifiers specified by [RFC5321] and in each of the various identifiers specified by [RFC5321] and
[RFC5322]. Although this feature is desirable in some circumstances, [RFC5322]. Although this feature is desirable in some circumstances,
it is a major obstacle to reducing Unsolicited Bulk Email (UBE, aka it is a major obstacle to reducing Unsolicited Bulk Email (UBE, aka
spam). Furthermore, many domain owning ADMDs (as described in spam). Furthermore, many domain owning ADMDs (as described in
[RFC5598]) are understandably concerned about the ease with which [RFC5598]) are understandably concerned about the ease with which
skipping to change at page 10, line 34 skipping to change at page 10, line 34
2.5. Location of Checks 2.5. Location of Checks
The authorization check SHOULD be performed during the processing of The authorization check SHOULD be performed during the processing of
the SMTP transaction that receives the mail. This reduces the the SMTP transaction that receives the mail. This reduces the
complexity of determining the correct IP address to use as an input complexity of determining the correct IP address to use as an input
to check_host() and allows errors to be returned directly to the to check_host() and allows errors to be returned directly to the
sending MTA by way of SMTP replies. Appendix C of [RFC5451] provides sending MTA by way of SMTP replies. Appendix C of [RFC5451] provides
a more thorough discussion of this topic. a more thorough discussion of this topic.
Performing the authorization check other than using the MAIL FROM and The authorization check is performed during the SMTP transaction at
client address at the time of the MAIL command during the SMTP the time of the MAIL command, and uses the MAIL FROM value and the
transaction can cause problems, such as the following: (1) It might client IP address. Performing the check at later times or with other
be difficult to accurately extract the required information from input can cause problems such as the following:
potentially deceptive headers; (2) legitimate email might fail
because the sender's policy had since changed. o It might be difficult to accurately extract the required
information from potentially deceptive headers.
o Legitimate email might fail the authorization check because the
sender's policy has since changed.
Generating non-delivery notifications to forged identities that have Generating non-delivery notifications to forged identities that have
failed the authorization check often constitutes backscatter, i.e., failed the authorization check often constitutes backscatter, i.e.,
inactionable, nuisance rejection notices. Operators are strongly inactionable, nuisance rejection notices. Operators are strongly
advised to avoid such practices. Section 2 of [RFC3834] describes advised to avoid such practices. Section 2 of [RFC3834] describes
backscatter and the problems it causes. backscatter and the problems it causes.
2.6. Results of Evaluation 2.6. Results of Evaluation
Section 4 defines check_host(), a model function definition that uses Section 4 defines check_host(), a model function definition that uses
skipping to change at page 11, line 22 skipping to change at page 11, line 28
2.6.1. None 2.6.1. None
A result of "none" means either (a) no syntactically valid DNS domain 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 name was extracted from the SMTP session that could be used as the
one to be authorized, or (b) no SPF records were retrieved from the one to be authorized, or (b) no SPF records were retrieved from the
DNS. DNS.
2.6.2. Neutral 2.6.2. Neutral
The ADMD has explicitly stated that it is not asserting whether the A "neutral" result means that the ADMD has explicitly stated that it
IP address is authorized. is not asserting whether the IP address is authorized.
2.6.3. Pass 2.6.3. Pass
A "pass" result means that the client is authorized to inject mail A "pass" result is an explicit statement that the client is
with the given identity. authorized to inject mail with the given identity.
2.6.4. Fail 2.6.4. Fail
A "fail" result is an explicit statement that the client is not A "fail" result is an explicit statement that the client is not
authorized to use the domain in the given identity. authorized to use the domain in the given identity.
2.6.5. Softfail 2.6.5. Softfail
The ADMD has published a weak statement that the host is probably not A "softfail" result is a weak statement by the publishing ADMD that
authorized. It has not published a stronger, more definitive policy the host is probably not authorized. It has not published a
that results in a "fail". stronger, more definitive policy that results in a "fail".
2.6.6. Temperror 2.6.6. Temperror
A "temperror" result means the SPF verifier encountered a transient A "temperror" result means the SPF verifier encountered a transient
(generally DNS) error while performing the check. A later retry may (generally DNS) error while performing the check. A later retry may
succeed without further DNS operator action. succeed without further DNS operator action.
2.6.7. Permerror 2.6.7. Permerror
A "permerror" result means the domain's published records could not A "permerror" result means the domain's published records could not
skipping to change at page 12, line 25 skipping to change at page 13, line 25
not permitted for the same owner name. The record format and the not permitted for the same owner name. The record format and the
process for selecting records is described below in Section 4. An process for selecting records is described below in Section 4. An
example record is the following: example record is the following:
v=spf1 +mx a:colo.example.com/28 -all v=spf1 +mx a:colo.example.com/28 -all
This record has a version of "spf1" and three directives: "+mx", This record has a version of "spf1" and three directives: "+mx",
"a:colo.example.com/28" (the + is implied), and "-all". "a:colo.example.com/28" (the + is implied), and "-all".
Each SPF record is placed in the DNS tree at the owner name it Each SPF record is placed in the DNS tree at the owner name it
pertains to, not a subdomain under it, such as is done with SRV pertains to, not in a subdomain under the owner name. This is
records [RFC2782]. similar to how SRV records [RFC2782] are done.
The example in this section might be published via these lines in a The example in this section might be published via these lines in a
domain zone file: domain zone file:
example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"
Since TXT records have multiple uses, beware of other TXT records Since TXT records have multiple uses, beware of other TXT records
published there for other purposes. They might cause problems with published there for other purposes. They might cause problems with
size limits (see Section 3.4) and care has to be taken to ensure only size limits (see Section 3.4) and care has to be taken to ensure only
SPF records are used for SPF processing. SPF records are used for SPF processing.
skipping to change at page 13, line 13 skipping to change at page 14, line 13
they are now. Additionally, support for easy deployment of new DNS they are now. Additionally, support for easy deployment of new DNS
RR types was not widely deployed in DNS servers and provisioning RR types was not widely deployed in DNS servers and provisioning
systems. As a result, developers of SPF found it easier and more systems. As a result, developers of SPF found it easier and more
practical to use the TXT RR type for SPF records. practical to use the TXT RR type for SPF records.
In its review of [RFC4408] the SPFbis working group concluded that In its review of [RFC4408] the SPFbis working group concluded that
its dual RR type transition model was fundamentally flawed since it its dual RR type transition model was fundamentally flawed since it
contained no common RR type that implementers were required to serve contained no common RR type that implementers were required to serve
and required to check. Many alternatives were considered to resolve and required to check. Many alternatives were considered to resolve
this issue, but ultimately the working group concluded that this issue, but ultimately the working group concluded that
significant migration to the SPF RR type in the foreseeable future was significant migration to the SPF RR type in the forseeable future was
very unlikely and that the best solution for resolving this very unlikely and that the best solution for resolving this
interoperability issue was to drop support for the SPF RR type from interoperability issue was to drop support for the SPF RR type from
SPF version 1. See Appendix A of [RFC6686] for further information. SPF version 1. See Appendix A of [RFC6686] for further information.
The circumstances surrounding SPF's initial deployment a decade ago The circumstances surrounding SPF's initial deployment a decade ago
are unique. If a future update to SPF were developed that did not are unique. If a future update to SPF were developed that did not
reuse existing SPF records, it could use the SPF RR type. SPF's use reuse existing SPF records, it could use the SPF RR type. SPF's use
of the TXT RR type for structured data should in no way be taken as of the TXT RR type for structured data should in no way be taken as
precedent for future protocol designers. Further discussion of precedent for future protocol designers. Further discussion of
design considerations when using new DNS RR types can be found in design considerations when using new DNS RR types can be found in
skipping to change at page 16, line 7 skipping to change at page 17, line 7
*.A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM *.A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
*.A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all" *.A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"
SPF records have to be listed twice for every name within the zone: SPF records have to be listed twice for every name within the zone:
once for the name, and once with a wildcard to cover the tree under once for the name, and once with a wildcard to cover the tree under
the name, in order to cover all domains in use in outgoing mail. the name, in order to cover all domains in use in outgoing mail.
4. The check_host() Function 4. The check_host() Function
This description is not an API (Application Program Interface) This description is not an application programming interface
definition, but rather a function description used to illustrate the definition, but rather a function description used to illustrate the
algorithm. A compliant SPF implementation MUST produce results algorithm. A compliant SPF implementation MUST produce results
semantically equivalent to this description. semantically equivalent to this description.
The check_host() function fetches SPF records, parses them, and The check_host() function fetches SPF records, parses them, and
evaluates them to determine whether a particular host is or is not evaluates them to determine whether a particular host is or is not
permitted to send mail with a given identity. Receiving ADMDs that permitted to send mail with a given identity. Receiving ADMDs that
perform this check MUST correctly evaluate the check_host() function perform this check MUST correctly evaluate the check_host() function
as described here. as described here.
skipping to change at page 19, line 34 skipping to change at page 20, line 34
4.6.4. DNS Lookup Limits 4.6.4. DNS Lookup Limits
Some mechanisms and modifiers (collectively, "terms") cause DNS Some mechanisms and modifiers (collectively, "terms") cause DNS
queries at the time of evaluation, and some do not. The following queries at the time of evaluation, and some do not. The following
terms cause DNS queries: the "include", "a", "mx", "ptr", and terms cause DNS queries: the "include", "a", "mx", "ptr", and
"exists" mechanisms and the "redirect" modifier. SPF implementations "exists" mechanisms and the "redirect" modifier. SPF implementations
MUST limit the total number of those terms to 10 during SPF MUST limit the total number of those terms to 10 during SPF
evaluation, to avoid unreasonable load on the DNS. If this limit is evaluation, to avoid unreasonable load on the DNS. If this limit is
exceeded, the implementation MUST return "permerror". The other exceeded, the implementation MUST return "permerror". The other
terms: the "all", "ip4", and "ip6" mechanisms do not cause DNS terms: the "all", "ip4", and "ip6" mechanisms and the "exp" modifier
queries at the time of SPF evaluation (the "exp" modifier causes a do not cause DNS queries at the time of SPF evaluation (the "exp"
lookup at a later time), and their use, including "exp", is not modifier only causes a lookup at a later time), and their use is not
subject to this limit. subject to this limit.
When evaluating the "mx" mechanism, the number of "MX" resource When evaluating the "mx" mechanism, the number of "MX" resource
records queried is included in the overall limit of 10 mechanisms/ records queried is included in the overall limit of 10 mechanisms/
modifiers that cause DNS lookups described above. The evaluation of modifiers that cause DNS lookups described above. In addition to
each "MX" record MUST NOT result in querying more than 10 address that limit, the evaluation of each "MX" record MUST NOT result in
records, either "A" or "AAAA" resource records. If this limit is querying more than 10 address records, either "A" or "AAAA" resource
exceeded, the "mx" mechanism MUST produce a "permerror" result. records. If this limit is exceeded, the "mx" mechanism MUST produce
a "permerror" result.
When evaluating the "ptr" mechanism or the %{p} macro, the number of When evaluating the "ptr" mechanism or the %{p} macro, the number of
"PTR" resource records queried is included in the overall limit of 10 "PTR" resource records queried is included in the overall limit of 10
mechanisms/modifiers that cause DNS lookups described above. The mechanisms/modifiers that cause DNS lookups described above. In
evaluation of each "PTR" record MUST NOT result in querying more than addition to that limit, the evaluation of each "PTR" record MUST NOT
10 address records, either "A" or "AAAA" resource records. If this result in querying more than 10 address records, either "A" or "AAAA"
limit is exceeded, all records other than the first 10 MUST be resource records. If this limit is exceeded, all records other than
ignored. the first 10 MUST be ignored.
The reason for the disparity is that the set of and contents of the The reason for the disparity is that the set of and contents of the
MX record are under control of the publishing ADMD, while the set of MX record are under control of the publishing ADMD, while the set of
and contents of PTR records are under control of the owner of the IP and contents of PTR records are under control of the owner of the IP
address actually making the connection. address actually making the connection.
These limits are per mechanism or macro in the record, and are in These limits are per mechanism or macro in the record, and are in
addition to the lookup limits specified above. addition to the lookup limits specified above.
MTAs or other processors SHOULD impose a limit on the maximum amount MTAs or other processors SHOULD impose a limit on the maximum amount
skipping to change at page 22, line 11 skipping to change at page 23, line 11
The result of evaluating check_host() with a syntactically invalid The result of evaluating check_host() with a syntactically invalid
domain is undefined. domain is undefined.
5. Mechanism Definitions 5. Mechanism Definitions
This section defines two types of mechanisms: basic language This section defines two types of mechanisms: basic language
framework mechanisms and designated sender mechanisms. framework mechanisms and designated sender mechanisms.
Basic mechanisms contribute to the language framework. They do not Basic mechanisms contribute to the language framework. They do not
specify a particular type of authorization scheme. specify a particular type of authorization scheme. The basic
mechanisms are as follows:
all all
include include
Designated sender mechanisms are used to identify a set of <ip> Designated sender mechanisms are used to identify a set of <ip>
addresses as being permitted or not permitted to use the <domain> for addresses as being permitted or not permitted to use the <domain> for
sending mail. sending mail. The designated sender mechanisms are as follows:
a a
mx mx
ptr (do not publish) ptr (do not use)
ip4 ip4
ip6 ip6
exists exists
The following conventions apply to all mechanisms that perform a The following conventions apply to all mechanisms that perform a
comparison between <ip> and an IP address at any point: comparison between <ip> and an IP address at any point:
If no CIDR prefix length is given in the directive, then <ip> and the If no CIDR prefix length is given in the directive, then <ip> and the
IP address are compared for equality. (Here, CIDR is Classless IP address are compared for equality. (Here, CIDR is Classless
Inter-Domain Routing, described in [RFC4632].) Inter-Domain Routing, described in [RFC4632].)
skipping to change at page 23, line 18 skipping to change at page 24, line 18
The "all" mechanism is a test that always matches. It is used as the The "all" mechanism is a test that always matches. It is used as the
rightmost mechanism in a record to provide an explicit default. rightmost mechanism in a record to provide an explicit default.
For example: For example:
v=spf1 a mx -all v=spf1 a mx -all
Mechanisms after "all" will never be tested. Mechanisms listed after Mechanisms after "all" will never be tested. Mechanisms listed after
"all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST be "all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST be
ignored when there is an "all" mechanism in the record. ignored when there is an "all" mechanism in the record regardless of
the relative ordering of the terms.
5.2. "include" 5.2. "include"
include = "include" ":" domain-spec include = "include" ":" domain-spec
The "include" mechanism triggers a recursive evaluation of The "include" mechanism triggers a recursive evaluation of
check_host(). check_host().
1. The domain-spec is expanded as per Section 7. 1. The domain-spec is expanded as per Section 7.
2. check_host() is evaluated with the resulting string as the 2. check_host() is evaluated with the resulting string as the
<domain>. The <ip> and <sender> arguments remain the same as in <domain>. The <ip> and <sender> arguments remain the same as in
the current evaluation of check_host(). the current evaluation of check_host().
3. The recursive evaluation returns either match, not match, or an 3. The recursive evaluation returns match, not match, or an error.
error. If it matches, then the appropriate result for the
include: mechanism is used (e.g. include or +include produces a
"pass" result and -include produces "fail").
4. If there is no match, the parent check_host() resumes processing 4. If it returns match, then the appropriate result for the include:
as per the table below, with the previous value of <domain> mechanism is used (e.g. include or +include produces a "pass"
restored. result and -include produces "fail").
5. If it returns no match or an error, the parent check_host()
resumes processing as per the table below, with the previous
value of <domain> restored.
In hindsight, the name "include" was poorly chosen. Only the In hindsight, the name "include" was poorly chosen. Only the
evaluated result of the referenced SPF record is used, rather than evaluated result of the referenced SPF record is used, rather than
literally including the mechanisms of the referenced record in the literally including the mechanisms of the referenced record in the
first. For example, evaluating a "-all" directive in the referenced first. For example, evaluating a "-all" directive in the referenced
record does not terminate the overall processing and does not record does not terminate the overall processing and does not
necessarily result in an overall "fail". (Better names for this necessarily result in an overall "fail". (Better names for this
mechanism would have been "if-match", "on-match", etc.) mechanism would have been "if-match", "on-match", etc.)
The "include" mechanism makes it possible for one domain to designate The "include" mechanism makes it possible for one domain to designate
skipping to change at page 24, line 39 skipping to change at page 25, line 41
| neutral | not match | | neutral | not match |
| | | | | |
| temperror | return temperror | | temperror | return temperror |
| | | | | |
| permerror | return permerror | | permerror | return permerror |
| | | | | |
| none | return permerror | | none | return permerror |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
The "include" mechanism is intended for crossing administrative The "include" mechanism is intended for crossing administrative
boundaries. For example, if example.com and example.org were managed boundaries. When remaining within one administrative authority,
by the same entity, and if the permitted set of hosts for both "include" is usually not the best choice. For example, if
domains was "mx:example.com", it would be possible for example.org to example.com and example.org were managed by the same entity, and if
specify "include:example.com", but it would be preferable to specify the permitted set of hosts for both domains was "mx:example.com", it
"redirect=example.com" or even "mx:example.com". would be possible for example.org to specify "include:example.com",
but it would be preferable to specify "redirect=example.com" or even
"mx:example.com".
With the "include" mechanism an administratively external set of With the "include" mechanism an administratively external set of
hosts can be authorized, but determination of sender policy is still hosts can be authorized, but determination of sender policy is still
a function of the original domain's SPF record (as determined by the a function of the original domain's SPF record (as determined by the
"all" mechanism in that record). The redirect modifier is more "all" mechanism in that record). The redirect modifier is more
suitable for consolidating both authorizations and policy into a suitable for consolidating both authorizations and policy into a
common set to be shared within an ADMD. Redirect is much more like a common set to be shared within an ADMD. Redirect is much more like a
common code element to be shared among records in a single ADMD. It common code element to be shared among records in a single ADMD. It
is possible to control both authorized hosts and policy for an is possible to control both authorized hosts and policy for an
arbitrary number of domains from a single record. arbitrary number of domains from a single record.
skipping to change at page 29, line 18 skipping to change at page 30, line 18
Modifiers always have an "=" separating the name and the value. Modifiers always have an "=" separating the name and the value.
The modifiers defined in this document ("redirect" and "exp") SHOULD The modifiers defined in this document ("redirect" and "exp") SHOULD
appear at the end of the record, after all mechanisms, though appear at the end of the record, after all mechanisms, though
syntactically they can appear anywhere in the record. Ordering of syntactically they can appear anywhere in the record. Ordering of
these two modifiers does not matter. These two modifiers MUST NOT these two modifiers does not matter. These two modifiers MUST NOT
appear in a record more than once each. If they do, then appear in a record more than once each. If they do, then
check_host() exits with a result of "permerror". check_host() exits with a result of "permerror".
Unrecognized modifiers MUST be ignored no matter where in a record, Unrecognized modifiers MUST be ignored no matter where in a record,
or how often. This allows implementations of this document to they appear or how often. This allows implementations of this
gracefully handle records with modifiers that are defined in other document to gracefully handle records with modifiers that are defined
specifications. in other specifications.
6.1. redirect: Redirected Query 6.1. redirect: Redirected Query
The redirect modifier is intended for consolidating both The redirect modifier is intended for consolidating both
authorizations and policy into a common set to be shared within a authorizations and policy into a common set to be shared within a
single ADMD. It is possible to control both authorized hosts and single ADMD. It is possible to control both authorized hosts and
policy for an arbitrary number of domains from a single record. policy for an arbitrary number of domains from a single record.
redirect = "redirect" "=" domain-spec redirect = "redirect" "=" domain-spec
skipping to change at page 30, line 21 skipping to change at page 31, line 21
the same record. This can be an administrative advantage. the same record. This can be an administrative advantage.
Note: In general, the domain "A" cannot reliably use a redirect to Note: In general, the domain "A" cannot reliably use a redirect to
another domain "B" not under the same administrative control. Since another domain "B" not under the same administrative control. Since
the <sender> stays the same, there is no guarantee that the record at the <sender> stays the same, there is no guarantee that the record at
domain "B" will correctly work for mailboxes in domain "A", domain "B" will correctly work for mailboxes in domain "A",
especially if domain "B" uses mechanisms involving local-parts. An especially if domain "B" uses mechanisms involving local-parts. An
"include" directive will generally be more appropriate. "include" directive will generally be more appropriate.
For clarity, any "redirect" modifier SHOULD appear as the very last For clarity, any "redirect" modifier SHOULD appear as the very last
term in a record. term in a record. Any "redirect" modifier MUST be ignored if there
is an "all" mechanism anywhere in the record.
6.2. exp: Explanation 6.2. exp: Explanation
explanation = "exp" "=" domain-spec explanation = "exp" "=" domain-spec
If check_host() results in a "fail" due to a mechanism match (such as If check_host() results in a "fail" due to a mechanism match (such as
"-all"), and the "exp" modifier is present, then the explanation "-all"), and the "exp" modifier is present, then the explanation
string returned is computed as described below. If no "exp" modifier string returned is computed as described below. If no "exp" modifier
is present, then either a default explanation string or an empty is present, then either a default explanation string or an empty
explanation string MUST be returned to the calling application. explanation string MUST be returned to the calling application.
 End of changes. 26 change blocks. 
149 lines changed or deleted 160 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--nextPart2989640.dMaItEDoA5-- From sm@elandsys.com Tue Sep 24 09:03: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 3021D21F967F; Tue, 24 Sep 2013 09:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 kzcE5fhbG1M6; Tue, 24 Sep 2013 09:03:56 -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 94A4A11E8171; Tue, 24 Sep 2013 09:03:00 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.142.228]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8OG2SbL027602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Sep 2013 09:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1380038565; bh=u3rBf+lSW2OAvBucDuIBxDM/obyRpxS0wjcD6f8SkT8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dF0aOL6nZ9752wOMmI++RmUXJ6iYRFwsTr8tg+gbeyZ1nBED3nrsZMFuYa3hjBwrt SgwNTjPnCv34a997XT93rIq9TtTbhh7xDTqxmhstIRDmimmoJtvqxK0axxvtyB/NDg 3fuvPZeVF340+1vOK3MzOPOICz3M485RW6k3ZiEI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1380038565; i=@elandsys.com; bh=u3rBf+lSW2OAvBucDuIBxDM/obyRpxS0wjcD6f8SkT8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=EMiIlkEw4Kv4HGdDNhldF4m6ows/q59tEEdsBXkciRpc5MHOW/giefr6VCDOyBXj4 jejrFlZX046qonjnfUlwADI6sNs4TH7p/SzKtIU8R/v+tWZO6VQrzq+KNvS6+OU0fi +B5Vh3RpwtmXTE1bnMM52pj7cGZuKdN5npGEqFX8= Message-Id: <6.2.5.6.2.20130924085503.0c765350@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 24 Sep 2013 09:00:24 -0700 To: Barry Leiba From: S Moonesamy In-Reply-To: <5681464.EQGBnZhqiI@scott-latitude-e6320> References: <20130911015837.30196.11175.idtracker@ietfa.amsl.com> <1409783.xNJeGdWPul@scott-latitude-e6320> <5681464.EQGBnZhqiI@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG Subject: Re: [spfbis] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 24 Sep 2013 16:03:58 -0000 Hi Barry, At 21:26 22-09-2013, Scott Kitterman wrote: >Finally getting back to addressing additional comments. I have it >in my notes >that we hadn't addressed the comment part of this in -20. Based on the >comments I previously sent to the list, I'm attaching my proposed changes (so >far - there are more messages needing processing) for -21. Additional >comments embedded below. Please see the comments from Scott Kitterman below (Thanks, Scott). The attachment which I am not forwarding can be found at http://www.ietf.org/mail-archive/web/spfbis/current/msg04212.html Regards, S. Moonesamy (as document shepherd) >On Wednesday, September 11, 2013 17:38:27 Scott Kitterman wrote: > > On Wednesday, September 11, 2013 10:23:57 Murray S. Kucherawy wrote: > > > On Wed, Sep 11, 2013 at 5:04 AM, S Moonesamy > wrote: > > > >> ------------------------------**------------------------------** > > > >> ---------- > > > >> COMMENT: > > > >> ------------------------------**------------------------------** > > > >> ---------- > > > >> > > > >> I have a bunch of editorial comments that I'd like you to consider. > > > >> They're all non-blocking, but I think they'll improve the > document, and > > > >> I'll be happy to chat about them if you like. > > > >> > > > >> -- Section 2.5 -- > > > >> > > > >> Performing the authorization check other than using the MAIL FROM > > > >> and > > > >> client address at the time of the MAIL command during the SMTP > > > >> transaction can cause problems, such as the following: (1) It might > > > >> be difficult to accurately extract the required information from > > > >> potentially deceptive headers; (2) legitimate email might fail > > > >> because the sender's policy had since changed. > > > >> > > > >> I found that to be awkwardly worded and hard to understand. Please > > > >> consider this rewrite: > > > >> > > > >> NEW > > > >> > > > >> The authorization check is performed during the SMTP transaction > > > >> at the time of the MAIL command, and uses the MAIL FROM value and > > > >> the client IP address. Performing the check at later times or > > > >> with other input can cause problems such as the following: > > > >> > > > >> * It might be difficult to accurately extract the required > > > >> > > > >> information from potentially deceptive headers. > > > >> > > > >> * Legitimate email might fail the authorization check because > > > >> > > > >> the sender's policy has since changed. > > > >> > > > >> END > > > > > > Seems reasonable. > > > > Agreed. > >Done. > > > > >> -- Section 2.6 -- > > > >> > > > >> It would really read best if the subsections were worded to be > > > >> parallel. > > > >> As it stands, subsections 1, 3, 4, 6, and 7 are worded as "result X > > > >> means > > > >> Y", and subsections 2 and 5 are not. Can you re-word 2 and 5 to be > > > >> parallel to the others? > > > > > > Seems reasonable. > > > > Agreed. > >Done. > > > > >> Also, why are "neutral" and "fail" called "explicit statements", but > > > >> "pass", for example, is not? > > > > > > I agree, "pass" should be. > > > > Yep. > >Done. > > > > >> -- Section 3 -- > > > >> > > > >> Each SPF record is placed in the DNS tree at the owner name it > > > >> pertains to, not a subdomain under it, such as is done with SRV > > > >> records [RFC2782]. > > > >> > > > >> This looks like it's saying that SRV records are placed in subdomains, > > > >> and I don't think that's what you mean. Or is it? In any case, it's > > > >> not > > > >> clear (and I know this text is from the original). > > > >> > > > >> Maybe this (which also avoids the two different "it"s)?: > > > >> > > > >> NEW > > > >> > > > >> Each SPF record is placed in the DNS tree at the owner name it > > > >> pertains to, not in a subdomain under the owner name. This is > > > >> similar to how SRV records [RFC2782] are done. > > > >> > > > >> END > > > > > > Seems reasonable. > > > > Agreed. > >Done. > > > > >> The example in this section might be published via these lines in a > > > >> > > > >> domain zone file: > > > >> example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" > > > >> smtp-out.example.com. TXT "v=spf1 a -all" > > > >> > > > >> What does "smtp-out" have to do with anything? It's not otherwise > > > >> used, > > > >> and it seems to contradict what you say about subdomains in the > > > >> previous > > > >> paragraph. > > > > > > Hmm. Someone else will have to comment on this one. > > > > Those are just two examples, but the preceding text is poorly worded (I > > checked and it's no better in RFC 4408). How about this instead, to > > clarify: > > > > The example in this section (plus an additional SPF record for > > smtp-out.example.com) might be published via these lines in a > > domain zone file: > > > > example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" > > smtp-out.example.com. TXT "v=spf1 a -all" > >Already fixed in -20. > > > > >> -- Section 4 -- > > > >> > > > >> This description is not an API (Application Program Interface) > > > >> definition, > > > >> > > > >> Two total nits on this: > > > >> 1. You never use "API" other than here, so there's no need to define > > > >> it, > > > >> and > > > >> 2. the usual expansion of "API" is application programMING interface. > > > >> I suggest, "This description is not an application programming > > > >> interface > > > >> definition, [etc]." > > > > > > Seems reasonable. > > > > Agreed. > >Done. > > > > >> -- Section 4.5 -- > > > >> > > > >> Starting with the set of records that were returned by the lookup, > > > >> discard records that do not begin with a version section of exactly > > > >> "v=spf1". Note that the version section is terminated either by an > > > >> SP character or the end of the record. A record with a version > > > >> section of "v=spf10" does not match and is discarded. > > > >> > > > >> Sure, and "v=spf1.0" doesn't match, and "v=spf11" doesn't match, > > > >> and.... > > > >> Why is it necessary or desirable to single out "v=spf10" here? > > > > > > I think "v=spf1.0" is actually the better (and perhaps intended) example, > > > meaning "don't just stuff the part after 'spf' through a number > parser and > > > make sure 1 comes out". > > > > The intent here is to show that you have to look at least one > character past > > "v=spf1" to know if it's an SPF record or not. It's an example. As such, > > it doesn't matter much wrt the point if it's "v=spf10", "v=spf1.0", or or > > "v=spf1hatespf". None of those start SPF records. What's there is > > unchanged from RFC 4408. I don't seem much of a point in changing it, but > > if others think 1.0 is better than 10, I don't mind. > >There was already a change for this in -20. > > > > >> -- Section 4.6.4 -- > > > >> > > > >> SPF implementations MUST limit the total number of mechanisms and > > > >> modifiers ("terms") that cause any DNS query to 10 during SPF > > > >> evaluation. Specifically, the "include", "a", "mx", "ptr", and > > > >> "exists" mechanisms as well as the "redirect" modifier > count against > > > >> this collective limit. The "all", "ip4", and "ip6" mechanisms do > > > >> not > > > >> count against this limit. If this number is exceeded during a > > > >> check, > > > >> a "permerror" MUST be returned. The "exp" modifier does not count > > > >> against this limit because the DNS lookup to fetch the explanation > > > >> string occurs after the SPF record evaluation has been completed. > > > >> > > > >> When I read this, I start feeling like I'm being read the rules for > > > >> Fizzbin > > > >> > > >> / > > > >> wiki/Fizzbin#Fizzbin>>.>> > > > >> > > > >> I would > > > >> appreciate it if this was re-worded so that there are two clear lists > > > >> here: the terms that are included in the "limit of 10", and the terms > > > >> that are not (and are, presumably, unlimited). Perhaps something like > > > >> this: > > > >> > > > >> NEW > > > >> > > > >> Some mechanisms and modifiers (collectively, "terms") cause DNS > > > >> queries at the time of evaluation, and some do not. The following > > > >> terms cause DNS queries: . SPF implementations > > > >> MUST limit the total number of those terms to 10 during SPF > > > >> evaluation, to avoid unreasonable load on the DNS. If this limit > > > >> is exceeded, the implementation MUST return "permerror". The other > > > >> terms () do not cause DNS queries at the time of > > > >> SPF evaluation, and their use is not subject to this limit. > > > >> > > > >> END > > > >> > > > >> If you think it's necessary (I don't): > > > >> > > > >> NEW+ > > > >> > > > >> The other > > > >> terms () do not cause DNS queries at the time of > > > >> SPF evaluation (the "exp" modifier causes a lookup at a > later time), > > > >> and their use is not subject to this limit. > > > >> > > > >> END > > > > > > I like the new text, and prefer the second bit be included. > > > > If we change, and I think that's reasonable, the second bit should > > definitely be included. "exp" not counting in the 10 has confused people > > and we should be explicit about it. > >Done. > > > > >> Then in the next two paragraphs, I think it would improve clarity to > > > >> make > > > >> a change such as this: > > > >> > > > >> OLD > > > >> > > > >> When evaluating the "mx" mechanism, the number of "MX" resource > > > >> records queried is included in the overall limit of 10 mechanisms/ > > > >> modifiers that cause DNS lookups described above. The > evaluation of > > > >> each "MX" record MUST NOT result in querying more than 10 address > > > >> records, > > > >> > > > >> NEW > > > >> > > > >> When evaluating the "mx" mechanism, the number of "MX" resource > > > >> records queried is included in the overall limit of 10 mechanisms/ > > > >> modifiers that cause DNS lookups described above. In addition to > > > >> that limit, the evaluation of each "MX" record MUST NOT result in > > > >> querying more than 10 address records, > > > >> > > > >> END > > > >> > > > >> (And similarly for the "ptr" paragraph.) I know you say this in a > > > >> paragraph of its own ("These limits are per mechanism..."), but it's > > > >> helpful if people can understand things as they read them, and then to > > > >> emphasize it later... rather than having them scratch their > heads for a > > > >> few paragraphs until they get to it. > > > > > > +1 to that part too. > > > > Seems reasonable. > >Done. > > > > > -- Section 4.7 -- > > > > > > > >> It is better to use either a "redirect" modifier or an "all" > > > >> mechanism to explicitly terminate processing. Although the latter > > > >> has a default (specifically "?all"), it aids debugging > efforts if it > > > >> is explicitly provided. > > > >> > > > >> I'm not sure what "the latter has a default" is trying to say. Do you > > > >> mean that "?all" is the default if you fall off the end, but you > > > >> shouldn't rely on that? Or do you mean that if you say "all", then > > > >> "?all" is taken as the default (I would think "all" would > mean "+all")? > > > >> Will you try re-wording this, please? > > > > > > The former ("?all" is implicit if you fall off the end). Suggest: > > > > > > It is better to use either a "redirect" modifier or an "all" mechanism to > > > explicitly terminate processing. Although there is in effect a "?all" > > > implicit at the end of every record, it ads debigging efforts when it is > > > explicitly provided. > > > > How about: > > > > It is better to use either a "redirect" modifier or an "all" > mechanism to > > explicitly terminate processing. Although there is an implicit "?all" at > > the end of every record that is not explicitly terminated, it aids > > debugging efforts when it is explicitly provided. > >This was changed in -20. > > > > >> -- Section 5 -- > > > >> > > > >> What does "(do not publish)" mean next to "ptr" in the sender > > > >> mechanisms > > > >> list? Ah; I see; it matches the "do not use" in Section 5.5. You > > > >> should > > > >> probably change this to "(do not use; see the note in Section 5.5)". > > > > > > Seems reasonable. > > > > OK. > >Done. > > > > >> It would help, I think, to add to the end of the second > paragraph, "The > > > >> basic mechanisms are as follows:", and to the end of the third > > > >> paragraph, > > > >> "The designated sender mechanisms are as follows:". Otherwise, there > > > >> are > > > >> just these disembodied lists, and the reader has to infer those > > > >> introductions. > > > > > > Sure. > > > > Agreed. > >Done. > > > > >> -- Section 5.1 -- > > > >> > > > >> Mechanisms after "all" will never be tested. Mechanisms listed > > > >> after > > > >> "all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST > > > >> be > > > >> ignored when there is an "all" mechanism in the record. > > > >> > > > >> This says that the redirect in the following record will be ignored: > > > >> v=spf1 redirect=_spf.example.com +all > > > >> > > > >> That's sufficiently odd that it should be called out explicitly, > > > >> perhaps > > > >> by adding "regardless of the relative ordering of the terms" to the > > > >> last > > > >> sentence in the quote. > > > > > > Yep. > > > > OK. > >Done. > > > > >> -- Section 5.2 -- > > > >> > > > >> 3. The recursive evaluation returns either match, not match, or an > > > >> > > > >> error. If it matches, then the appropriate result for the > > > >> include: mechanism is used (e.g. include or +include produces a > > > >> "pass" result and -include produces "fail"). > > > >> > > > >> 4. If there is no match, the parent check_host() resumes > processing > > > >> > > > >> as per the table below, with the previous value of > > > >> restored. > > > >> > > > >> A few things here: > > > >> > > > >> 1. Nit: "either" is for two things; for more than two, please remove > > > >> the > > > >> word "either" (or replace it with "one of", but that seems awkward > > > >> here). > > > >> > > > >> 2. "If it matches" is not parallel to "returns match", and similarly > > > >> for > > > >> "if there is no match". > > > >> > > > >> 3. You don't say what happens if the recursive evaluation returns an > > > >> error. Unfortuately, "no match" and "not match" are sufficiently > > > >> similar > > > >> to be confused. > > > >> > > > >> I suggest this: > > > >> > > > >> NEW > > > >> > > > >> 3. The recursive evaluation returns match, not match, or an > > > >> > > > >> error. > > > >> > > > >> 4. If it returns match, then the appropriate result for the > > > >> > > > >> include: mechanism is used (e.g., include or +include produces > > > >> a "pass" result and -include produces "fail"). > > > >> > > > >> 5. If it returns not match or an error, the parent check_host() > > > >> > > > >> resumes processing as per the table below, with the previous > > > >> value of restored. > > > >> > > > >> END > > > > > > +1. > > > > I think this is fine. > >Done. > > > > >> The "include" mechanism is intended for crossing administrative > > > >> boundaries. For example, if example.com and example.org were > > > >> managed > > > >> by the same entity, and if the permitted set of hosts for both > > > >> domains was "mx:example.com", it would be possible for example.org > > > >> to > > > >> specify "include:example.com", but it would be preferable > to specify > > > >> "redirect=example.com" or even "mx:example.com". > > > >> > > > >> The text you eliminated here provided a buffer that's no longer there, > > > >> making the "For example," very odd. You talk about crossing admin > > > >> boundaries and immediately follow it with an example that does NOT. I > > > >> think it would be better to put a sentence in to restore > that buffer -- > > > >> perhaps, "When remaining within one administrative > authority, "include" > > > >> is usually not the best choice." > > > > > > Sure. > > > > Agreed. > >Done. > > > > >> -- Section 5.5 -- > > > >> > > > >> This mechanism SHOULD NOT be published. See below for discussion. > > > >> > > > >> It's quite a bit below. I suggest "See the note at the end of this > > > >> section for more information." It might even be worth putting that > > > >> note > > > >> into a Section 5.5.1, so it's highlighted and more easily cited. > > > > > > +1. > > > > OK. Someone let me know which way I should do it. I'm OK with either. > >The first option was done in -20. > > > > >> -- Section 6 -- > > > >> > > > >> Unrecognized modifiers MUST be ignored no matter where in a record, > > > >> or how often. > > > >> > > > >> This is missing a couple of words: > > > >> > > > >> NEW > > > >> > > > >> Unrecognized modifiers MUST be ignored no matter where in a record > > > >> they appear, or how often. > > > >> > > > >> END > > > > > > +1. > > > > OK. > >Done. > > > > >> For clarity, any "redirect" modifier SHOULD appear as the very last > > > >> term in a record. > > > >> > > > >> I don't usually recommend repeating things, but one thing from earlier > > > >> probably does bear repeating here: > > > >> > > > >> NEW > > > >> > > > >> For clarity, any "redirect" modifier SHOULD appear as the very last > > > >> term in a record. Any "redirect" modifier MUST be ignored if there > > > >> is an "all" mechanism anywhere in the record. > > > >> > > > >> END > > > > > > Seems reasonable. > > > > OK. > > > > Thanks for the detailed review and msk's comments on the comments. > > > > Scott K From barryleiba@gmail.com Tue Sep 24 10:58: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 0DA2511E813A; Tue, 24 Sep 2013 10:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.981 X-Spam-Level: X-Spam-Status: No, score=-101.981 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 KNAm5Ot68sLK; Tue, 24 Sep 2013 10:58:01 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5852121F8E70; Tue, 24 Sep 2013 10:57:42 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id x19so3340918qcw.30 for ; Tue, 24 Sep 2013 10:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=I3hRakzt0MuVzXy5OFE0liDy2m7XH4XHav+hzGMREWA=; b=kdmhghiH6gndwO8eN5NX4f9cxrl+ADvW0Ekxalb3ePghKGdG+CZ+0bHNwuHrJABVaK wGXrroLMfO4H1f4LlWtHO+bmshJHy2j+v43ZRWxQNw+bFfggJGa+Vk30kiQEWdwHhuW0 60iDkeC7keqKXkY+IftUwcREZL7OEud+4VFmtKt+aMve80HuNAMTIvfcIHIGMdZ/NExf 5xDDHUeKmsggM5zh+IOSizskTxNz1gl5iUH4TQJcnakfLzPS1O7oreEXfTaw7JEII6dI 8JZL65aJFrOD66k9dKj24Y3Bp5tRgl4oxZd50lVadiJRtqnMMNggRBgPxoiGgLe0kggb 0OEw== MIME-Version: 1.0 X-Received: by 10.49.50.42 with SMTP id z10mr27645232qen.40.1380045460648; Tue, 24 Sep 2013 10:57:40 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.67.130 with HTTP; Tue, 24 Sep 2013 10:57:40 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130924085503.0c765350@resistor.net> References: <20130911015837.30196.11175.idtracker@ietfa.amsl.com> <1409783.xNJeGdWPul@scott-latitude-e6320> <5681464.EQGBnZhqiI@scott-latitude-e6320> <6.2.5.6.2.20130924085503.0c765350@resistor.net> Date: Tue, 24 Sep 2013 13:57:40 -0400 X-Google-Sender-Auth: DDnQn4GgCfyhmj06Q2-4cR48fEg Message-ID: From: Barry Leiba To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" , "spfbis-chairs@tools.ietf.org" , draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG Subject: Re: [spfbis] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT) 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, 24 Sep 2013 17:58:04 -0000 >> Finally getting back to addressing additional comments. I have it in >> my notes that we hadn't addressed the comment part of this in -20. >> Based on the comments I previously sent to the list, I'm attaching my >> proposed changes (so far - there are more messages needing >> processing) for -21. Additional comments embedded below. > > Please see the comments from Scott Kitterman below (Thanks, Scott). The > attachment which I am not forwarding can be found at > http://www.ietf.org/mail-archive/web/spfbis/current/msg04212.html Yes, thanks for addressing this stuff. When -21's posted, after all the changes are in, I'll review it and see where we are. I'm sure it'll have everything important taken care of. Barry From sm@elandsys.com Wed Sep 25 13:32: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 53AAD21E8055; Wed, 25 Sep 2013 13:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 B4wcGRGzoDQb; Wed, 25 Sep 2013 13:32: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 AA55821F9B86; Wed, 25 Sep 2013 13:32:42 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.132.253]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8PKV5IQ017898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Sep 2013 13:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1380141080; bh=0cCPa20U6Lrm2EG1vrwFmOQqL10ayePg/r8cub78ihE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=DYU9vwnGyUDy9urhQk+uOqr+3qniHMn+VY+PUm8C3u8cfAu47CVjfaN2GxiKiZ6hU W7V3dF84AqjNBbCugGFsiIMMpjKXpwZ9Au+pHQYryxVK0XPEq/Ya3ZlLgK8eBQsgkY Xa27MYiFK5c+t5j6iUr40C7CvwKWfr1D1mlA8qCA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1380141080; i=@elandsys.com; bh=0cCPa20U6Lrm2EG1vrwFmOQqL10ayePg/r8cub78ihE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ZKDDVr3hjpY1RKT+207Uuk1rUHYjoo+9t8dsR+UM5r9UNmcVa6VytJScbEWnJDzJA QEWwiX9sn/Ko8m4wejEbLG326MH8GVc7fI/QYXWL3xjtdJKQNdAmdOpfx2fGmm1LD9 tJLaILa8gCbMIo0kxX+9Iw6N4oJ1IDp6bGzyZaJ0= Message-Id: <6.2.5.6.2.20130925131612.0d8d3800@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 25 Sep 2013 13:30:47 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20130912101511.20829.6656.idtracker@ietfa.amsl.com> References: <20130912101511.20829.6656.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis-chairs@tools.ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG , Stephen Farrell Subject: Re: [spfbis] Stephen Farrell's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 25 Sep 2013 20:32:47 -0000 Hello, I would like to bring the message below to the attention of the working group. There has not been any response to it. Can a SPFBIS WG participant please respond to the message? Thanks, S. Moonesamy (as document shepherd) At 03:15 12-09-2013, Stephen Farrell wrote: >Stephen Farrell has entered the following ballot position for >draft-ietf-spfbis-4408bis-19: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > >- 4.1: given that recursion is allowed and that you have >overall limits on how many DNS transactions can be done, >is the "transactions-remaining" value also an implicit >parameter of a check_host() call? This is only a comment >since check_host is not a formal API but it'd seem to make >it easier to get right if you make that implicit parameter >explicit. Or do the limits apply to each call as you >recurse? That wasn't entirely clear to me. > >- I didn't get appendix D at all - what's that do? > >- Appendix E.1, 2nd bullet: what's that? I think it needs >a reference if you want it to be understood. From superuser@gmail.com Wed Sep 25 14:23: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 C62B521F922A; Wed, 25 Sep 2013 14:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 O5+bk9ySoGHA; Wed, 25 Sep 2013 14:23:44 -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 4D5B511E80DF; Wed, 25 Sep 2013 14:23:43 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cb5so283171wib.16 for ; Wed, 25 Sep 2013 14:23:42 -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=dXl42LgFJxn/ft1aKYhf+bUoL9cZocOxo6lrG9xxPVM=; b=hbNVc8CRCQ2Jz60iiHvve6fF7h8K49lGwLbCBvJS5pqw1WkSkm/aPTOyZw6cszWFl2 o+4/S5Nipe7rcAR5ALBX8LhZBq4xaxtWgYzLUOGCg0mkA5bFuKVNqQDxbXqFQjyjNeMv I5/VvfgtwdaZ1v1nCZ8ScBS4JjSTJCqfk7dNQLJKhi18KBEnbfwOBEM6po49Q/zX79Q2 zMBdfbuNR5zkoONJWibS9AVtXvhfTG5FdjUAZNx121s+agQSbA2EsyXxuhF9WOZL8QZ8 1n/0iRL1o8oT5HOQWPElGtypi2MLNcmoEOxGWeHdTvusjFu8lms04xaU2rwQAvCZklKT lY6Q== MIME-Version: 1.0 X-Received: by 10.194.174.36 with SMTP id bp4mr28431859wjc.7.1380144222373; Wed, 25 Sep 2013 14:23:42 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Wed, 25 Sep 2013 14:23:42 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130925131612.0d8d3800@elandnews.com> References: <20130912101511.20829.6656.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130925131612.0d8d3800@elandnews.com> Date: Wed, 25 Sep 2013 14:23:42 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=089e0141a0ae1d0c7304e73bdeb2 Cc: "spfbis@ietf.org" , "spfbis-chairs@tools.ietf.org" , draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG , Stephen Farrell Subject: Re: [spfbis] Stephen Farrell's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 25 Sep 2013 21:23:47 -0000 --089e0141a0ae1d0c7304e73bdeb2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 25, 2013 at 1:30 PM, S Moonesamy wrote: > Hello, > > I would like to bring the message below to the attention of the working > group. There has not been any response to it. Can a SPFBIS WG participant > please respond to the message? > > > Thanks, > S. Moonesamy (as document shepherd) > > At 03:15 12-09-2013, Stephen Farrell wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-spfbis-4408bis-19: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/**statement/discuss-criteria.** >> html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/**doc/draft-ietf-spfbis-4408bis/ >> >> >> >> ------------------------------**------------------------------** >> ---------- >> COMMENT: >> ------------------------------**------------------------------** >> ---------- >> >> >> - 4.1: given that recursion is allowed and that you have >> overall limits on how many DNS transactions can be done, >> is the "transactions-remaining" value also an implicit >> parameter of a check_host() call? This is only a comment >> since check_host is not a formal API but it'd seem to make >> it easier to get right if you make that implicit parameter >> explicit. Or do the limits apply to each call as you >> recurse? That wasn't entirely clear to me. >> > I suggest that it would be sufficient to add some prose that says the "transactions-remaining" count (or whatever we call it) has to apply through the recursions. We shouldn't make this look any more like an API definition than it already does. - I didn't get appendix D at all - what's that do? >> > I agree, we should explain it and include an example, or drop it. Someone closer to the implementation and the original material than I am is almost certainly able to come up with an appropriate example versus what I would invent. > >> - Appendix E.1, 2nd bullet: what's that? I think it needs >> a reference if you want it to be understood. >> > Same here; examples would probably be useful for all three sections. -MSK --089e0141a0ae1d0c7304e73bdeb2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 25, 2013 at 1:30 PM, S Moonesamy <sm+ietf@= elandsys.com> wrote:
Hello,

I would like to bring the message below to the attention of the working gro= up. =A0There has not been any response to it. =A0Can a SPFBIS WG participan= t please respond to the message?

Thanks,
S. Moonesamy (as document shepherd)

At 03:15 12-09-2013, Stephen Farrell wrote:
Stephen Farrell has entered the following ballot position for
draft-ietf-spfbis-4408bis-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discu= ss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408= bis/



-------------------------------------------------------------= ---------
COMMENT:
-------------------------------------------------------------= ---------


- 4.1: given that recursion is allowed and that you have
overall limits on how many DNS transactions can be done,
is the "transactions-remaining" value also an implicit
parameter of a check_host() call? This is only a comment
since check_host is not a formal API but it'd seem to make
it easier to get right if you make that implicit parameter
explicit. Or do the limits apply to each call as you
recurse? =A0That wasn't entirely clear to me.

I suggest that it would be sufficient to add= some prose that says the "transactions-remaining" count (or what= ever we call it) has to apply through the recursions.=A0 We shouldn't m= ake this look any more like an API definition than it already does.


- I didn't get appendix D at all - what's that do?
=

I agree, we should explain it = and include an example, or drop it.=A0 Someone closer to the implementation= and the original material than I am is almost certainly able to come up wi= th an appropriate example versus what I would invent.

=A0

- Appendix E.1, 2nd bullet: what's that? I think it needs
a reference if you want it to be understood.

Same here; examples would probably be useful= for all three sections.

-MSK
--089e0141a0ae1d0c7304e73bdeb2-- From hsantos@isdg.net Wed Sep 25 18:24: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 D07CC21F9EE1 for ; Wed, 25 Sep 2013 18:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.649 X-Spam-Level: X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 5RizXQ-NDVX5 for ; Wed, 25 Sep 2013 18:24:02 -0700 (PDT) Received: from winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 56AAB21F9ECA for ; Wed, 25 Sep 2013 18:24:01 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2213; t=1380158638; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=gzDLAIaLg7sHGxYwmUZnTpcYdA4=; b=PZQpn2keEW3Ge4FwWvna 1IbNJ5AJT6cxuUK264MUBGnCzj8ZYKxm0lJHFG99W+a5qOR2LMx6JhCfjQM11bhA f5tez6FUkN/vGdqY4HdNnghqC2bfjMj/i5j+BZBalVCfFXYloFVmMHApAH09XeIl l+K3Pxw2oBfsJKfRZXWmyk0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 25 Sep 2013 21:23:58 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2326151675.15876.4568; Wed, 25 Sep 2013 21:23:57 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2213; t=1380158267; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=HnX2r7l /JHXw31glLGx1rwGBd0AZ6x4nJAIpvn4xFeU=; b=0p7wJ2aZOoPydZb8smr4jq7 Pf6BCkiuNSknT0iuKS5AZt8heBexpKl3SILIIHv9XgF8zt7hnd/uLLSwjANxXLMx dv8zH6r3VwOCfpMaM32DohZTYcxUT866bduaEixfpCegP+XjG0NUx4Kw1eraek6r Qac+am2VUWZ7BBxPDOOo= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 25 Sep 2013 21:17:47 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1772547722.9.9148; Wed, 25 Sep 2013 21:17:46 -0400 Message-ID: <52438CAC.8060302@isdg.net> Date: Wed, 25 Sep 2013 21:23:56 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: S Moonesamy References: <20130912101511.20829.6656.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130925131612.0d8d3800@elandnews.com> In-Reply-To: <6.2.5.6.2.20130925131612.0d8d3800@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG , Stephen Farrell Subject: Re: [spfbis] Stephen Farrell's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 26 Sep 2013 01:24:08 -0000 On 9/25/2013 4:30 PM, S Moonesamy wrote: > Hello, > > I would like to bring the message below to the attention of the > working group. There has not been any response to it. Can a SPFBIS > WG participant please respond to the message? > > Thanks, > S. Moonesamy (as document shepherd) > > At 03:15 12-09-2013, Stephen Farrell wrote: >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - 4.1: given that recursion is allowed and that you have >> overall limits on how many DNS transactions can be done, >> is the "transactions-remaining" value also an implicit >> parameter of a check_host() call? This is only a comment >> since check_host is not a formal API but it'd seem to make >> it easier to get right if you make that implicit parameter >> explicit. Or do the limits apply to each call as you >> recurse? That wasn't entirely clear to me. For our implementation, it was a plug and play update and hence a global limit per check_host instance call. So its not done on a per domain basis although it is possible to load a per domain configuration. I don't know of anyone on our end (nor it is interesting for anyone to tell us what they are using) doing a per domain limit. BTW, for us CHECK_HOST() is an API and it takes submitter (RFC4405) MAIL FROM values: spf_result = CHECK_HOST(MAILFROM [,HELO] [,SUBMITTER]) Thats an integrator POV this SPFBIS draft refused to acknowledge. I don't get it, but I accept it. >> - I didn't get appendix D at all - what's that do? Same here. You have to guess what its talking about with the starting sentence. I guess its about a method to track/log calls. >> - Appendix E.1, 2nd bullet: what's that? I think it needs >> a reference if you want it to be understood. Overall, this Appendix E should be an BCP, i.e., what is a "specialized DNS server" but.... Personally, these sections intro can be written better. They need some sort of intros into what they are about. Probably restate what are the problems, deployment or SPF "applied" issues the outlined items are addressing. -- HLS From spf2@kitterman.com Wed Sep 25 20:48: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 3928E21F967F for ; Wed, 25 Sep 2013 20:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.342, 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 erccq0fUB5mH for ; Wed, 25 Sep 2013 20:47:59 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3E38221F999C for ; Wed, 25 Sep 2013 20:47:45 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 25CAD20E40D3; Wed, 25 Sep 2013 23:47:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1380167264; bh=HojFAPBaXb/eQ3jmm9rAn0aBzgk5dYqgHKTOtLJ1RQE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EWDlzoS9LWsYMGLyAKTgUzna7A15U+UPhQTuKGddDS2uac1eAJwhu1YgEaf1e/DKK zpHonJSeJk6rxOfMTYblk25O7z9Utt1W5HQtCHMNUsH5CBSOZDUNWTLLx7KcOf5Tpi DuoYmCMpEjEFB7xBj+0a7fAcGQXEkD7f8EkrUINs= 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 0720920E40C4; Wed, 25 Sep 2013 23:47:43 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 25 Sep 2013 23:47:43 -0400 Message-ID: <1687976.ZmVcDHSKqt@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <523179E7.6090207@sonnection.nl> References: <2297109.DlIYn73fZN@scott-latitude-e6320> <523179E7.6090207@sonnection.nl> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1485247.zHcWRnKJ30" Content-Transfer-Encoding: 7Bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 26 Sep 2013 03:48:04 -0000 This is a multi-part message in MIME format. --nextPart1485247.zHcWRnKJ30 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Thursday, September 12, 2013 10:23:03 Rolf E. Sonneveld wrote: > Hi, Scott, > > On 09/11/2013 11:53 PM, Scott Kitterman wrote: > > On Wednesday, September 11, 2013 13:53:28 S Moonesamy wrote: > >> Hi Scott, > >> > >> I am copying the parts of the SECDIR review to which there hasn't > >> been any response: > >> > >> Issue 1: > >>> 1.1.3. MAIL FROM Definition > >>> > >>> I found this section completely opaque and very confusing. It should > >>> not be necessary to hunt through other specs to find a definition. > >>> Particularly since the referenced specs do not give an explicit > >>> definition for the term as used and the references point to the > >>> whole spec rather than a particular section. > > > > It's a challenge, but I think it's better than inventing a new definition > > for SPF that may be different. Would someone be willing to dive into the > > relevant RFCs and see if they can make a recommendation about how better > > to reference this? > > To avoid confusion it's better not to mention a whole list of possible > names/aliases in this Definition paragraph. > > May I suggest the following text: > > > 1.1.3. MAIL FROM Definition > > This document is concerned with the identity of the sender of a > mail message, as referred to in [RFC5321]: > > "The transaction starts with a MAIL command that gives the > sender identification." > > . Since there are many other names for this identity, it is > important to choose a name that is: > > 1. commonly used > 2. well defined > > As such, throughout this document the term "MAIL FROM" will be used, > which is defined as the RFC5321.MailFrom identity described in > [RFC5598]. Thanks. After much delay, I've added this to my local copy. Diff from the last changeset I posted attached. Scott K --nextPart1485247.zHcWRnKJ30 Content-Disposition: attachment; filename="draft-ietf-spfbis-4408bis-21-from-21~1.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="draft-ietf-spfbis-4408bis-21-from-21~1.diff.html" Diff: draft-ietf-spfbis-4408bis-21~1.txt - draft-ietf-spfbis-4408bis-21.txt
 draft-ietf-spfbis-4408bis-21~1.txt   draft-ietf-spfbis-4408bis-21.txt 
Network Working Group S. Kitterman Network Working Group S. Kitterman
Internet-Draft Kitterman Technical Services Internet-Draft Kitterman Technical Services
Obsoletes: 4408 (if approved) September 23, 2013 Obsoletes: 4408 (if approved) September 25, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: March 27, 2014 Expires: March 29, 2014
Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email,
Version 1 Version 1
draft-ietf-spfbis-4408bis-21 draft-ietf-spfbis-4408bis-21
Abstract Abstract
Email on the Internet can be forged in a number of ways. In Email on the Internet can be forged in a number of ways. In
particular, existing protocols place no restriction on what a sending 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 host can use as the "MAIL FROM" of a message or the domain given on
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 27, 2014. This Internet-Draft will expire on March 29, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 7, line 8 skipping to change at page 7, line 8
The tokens "Local-part", "Domain", and "Mailbox are defined in The tokens "Local-part", "Domain", and "Mailbox are defined in
[RFC5321]. [RFC5321].
"dot-atom", "quoted-string", "comment", "CFWS" (comment folded white "dot-atom", "quoted-string", "comment", "CFWS" (comment folded white
space), "FWS" (folded white space), and "CRLF" (carriage-return/ space), "FWS" (folded white space), and "CRLF" (carriage-return/
line-feed) are defined in [RFC5322]. line-feed) are defined in [RFC5322].
1.1.3. MAIL FROM Definition 1.1.3. MAIL FROM Definition
This document is concerned with the portion of a mail message This document is concerned with the identity of the sender of a mail
commonly called "envelope sender", "return path", "reverse path", message, as referred to in [RFC5321]:
"bounce address", "5321 FROM", "MAIL FROM", or RFC5321.MailFrom.
Since these terms are either not well defined or often used casually, "The transaction starts with a MAIL command that gives the sender
this document uses "MAIL FROM" for consistency. This means the identification."
RFC5321.MailFrom as defined in [RFC5598]. Note that other terms that
might superficially look like the common terms, such as 'reverse- Since there are many other names for this identity, it is important
path', are used only as they are specified in their defining to choose a name that is:
documents.
1. commonly used
2. well defined
As such, throughout this document the term "MAIL FROM" will be used,
which is defined as the RFC5321.MailFrom identity described in
[RFC5598].
1.1.4. HELO Definition 1.1.4. HELO Definition
This document also makes use of the HELO/EHLO identity. The "HELO" This document also makes use of the HELO/EHLO identity. The "HELO"
identity derives from either the SMTP HELO or EHLO command (see identity derives from either the SMTP HELO or EHLO command (see
[RFC5321]). Since HELO and EHLO can, in many cases, be used [RFC5321]). Since HELO and EHLO can, in many cases, be used
interchangeably, they are identified commonly as "HELO" in this interchangeably, they are identified commonly as "HELO" in this
document. This means RFC5321.HELO/.EHLO as defined in [RFC5598]. document. This means RFC5321.HELO/.EHLO as defined in [RFC5598].
These commands supply the identity of the SMTP client (sending host) These commands supply the identity of the SMTP client (sending host)
for the SMTP session. for the SMTP session.
 End of changes. 4 change blocks. 
12 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--nextPart1485247.zHcWRnKJ30-- From spf2@kitterman.com Wed Sep 25 20:53: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 BB2F321F8467 for ; Wed, 25 Sep 2013 20:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.824 X-Spam-Level: X-Spam-Status: No, score=-0.824 tagged_above=-999 required=5 tests=[AWL=-1.126, BAYES_50=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MANGLED_SAVELE=2.3] 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 gnj4NEn-TXyU for ; Wed, 25 Sep 2013 20:53:36 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D71BB11E8135 for ; Wed, 25 Sep 2013 20:53:28 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 76D7320E40D3; Wed, 25 Sep 2013 23:53:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1380167603; bh=1Xcxua4JJO09SgPLf7wQE3F472qXA2m6x29RlKhn+Hk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pWwFwXJ5S9BXs7JsM5T+soo2UyKwm0+OQY0vOCKS1ZVgrgdDvDmd+e+KhTIbjQnvE o0oFOwTdYLROkUMa+Yj9rRyh9JiznWo2jJn7S5FD2nK623I5Wox5nZI2qizqoOBcVk UCWccQKdIEbA5MxlxywfHPoHAw95ib6TtLTndGqY= 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 492BC20E40C4; Wed, 25 Sep 2013 23:53:22 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 25 Sep 2013 23:53:22 -0400 Message-ID: <2808009.mOvCxSAQtd@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130912184532.0c912bc8@resistor.net> References: <6.2.5.6.2.20130912094525.0ca26c60@elandnews.com> <7883048.PMslXZEC8x@scott-latitude-e6320> <6.2.5.6.2.20130912184532.0c912bc8@resistor.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart2714318.S1THZF8FJm" Content-Transfer-Encoding: 7Bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Revised I-D of draft-ietf-spfbis-4408bis 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, 26 Sep 2013 03:53:49 -0000 This is a multi-part message in MIME format. --nextPart2714318.S1THZF8FJm Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Thursday, September 12, 2013 18:52:40 S Moonesamy wrote: > Hi Scott, > > At 18:28 12-09-2013, Scott Kitterman wrote: > >In retrospect, it wasn't 100% clear if I'm supposed to post -20 as the last > >interim diff I sent to the list or work on other outstanding > >comments first. In > >the interest of being conservative, I'm posting -20 just as I last sent it > >to the list. > > It's okay. Let's work from draft-ietf-spfbis-4408bis-20. > > Before I forget Appendix A will have to be moved into a section (Pete > Resnick commented about that previously). Attached (diff from the last diff, not from -20). Scott K --nextPart2714318.S1THZF8FJm Content-Disposition: attachment; filename="draft-ietf-spfbis-4408bis-21-from-21~2.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="draft-ietf-spfbis-4408bis-21-from-21~2.diff.html" Diff: draft-ietf-spfbis-4408bis-21~2.txt - draft-ietf-spfbis-4408bis-21.txt
 draft-ietf-spfbis-4408bis-21~2.txt   draft-ietf-spfbis-4408bis-21.txt 
skipping to change at page 4, line 43 skipping to change at page 4, line 43
11.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 49 11.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 49
11.2. SPF-Authorized Email May Contain Other False Identities . 50 11.2. SPF-Authorized Email May Contain Other False Identities . 50
11.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 50 11.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 50
11.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 50 11.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 50
11.5. Untrusted Information Sources . . . . . . . . . . . . . . 51 11.5. Untrusted Information Sources . . . . . . . . . . . . . . 51
11.5.1. Recorded Results . . . . . . . . . . . . . . . . . . . 51 11.5.1. Recorded Results . . . . . . . . . . . . . . . . . . . 51
11.5.2. External Explanations . . . . . . . . . . . . . . . . 51 11.5.2. External Explanations . . . . . . . . . . . . . . . . 51
11.5.3. Macro Expansion . . . . . . . . . . . . . . . . . . . 52 11.5.3. Macro Expansion . . . . . . . . . . . . . . . . . . . 52
11.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 52 11.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 52
11.7. Delivering Mail Producing a 'Fail' Result . . . . . . . . 52 11.7. Delivering Mail Producing a 'Fail' Result . . . . . . . . 52
12. Contributors and Acknowledgements . . . . . . . . . . . . . . 53 12. Collected ABNF . . . . . . . . . . . . . . . . . . . . . . . . 53
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 13. Contributors and Acknowledgements . . . . . . . . . . . . . . 56
13.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 54 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
13.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 54 14.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 57
13.3. SPF Modifier Registry . . . . . . . . . . . . . . . . . . 54 14.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 57
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 14.3. SPF Modifier Registry . . . . . . . . . . . . . . . . . . 57
14.1. Normative References . . . . . . . . . . . . . . . . . . . 55 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
14.2. Informative References . . . . . . . . . . . . . . . . . . 56 15.1. Normative References . . . . . . . . . . . . . . . . . . . 58
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 58 15.2. Informative References . . . . . . . . . . . . . . . . . . 59
Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 61
B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 61 Appendix A. Extended Examples . . . . . . . . . . . . . . . . . . 61
B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 62 A.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 61
B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 63 A.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 62
B.4. Multiple Requirements Example . . . . . . . . . . . . . . 63 A.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 63
Appendix C. Changes in implementation requirements from RFC A.4. Multiple Requirements Example . . . . . . . . . . . . . . 63
Appendix B. Changes in implementation requirements from RFC
4408 . . . . . . . . . . . . . . . . . . . . . . . . 64 4408 . . . . . . . . . . . . . . . . . . . . . . . . 64
Appendix D. Further Testing Advice . . . . . . . . . . . . . . . 65 Appendix C. Further Testing Advice . . . . . . . . . . . . . . . 65
Appendix E. SPF/Mediator Interactions . . . . . . . . . . . . . . 66 Appendix D. SPF/Mediator Interactions . . . . . . . . . . . . . . 66
E.1. Originating ADMDs . . . . . . . . . . . . . . . . . . . . 66 D.1. Originating ADMDs . . . . . . . . . . . . . . . . . . . . 66
E.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 67 D.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 67
E.3. Receving ADMDs . . . . . . . . . . . . . . . . . . . . . . 67 D.3. Receving ADMDs . . . . . . . . . . . . . . . . . . . . . . 67
Appendix F. Mail Services . . . . . . . . . . . . . . . . . . . . 68 Appendix E. Mail Services . . . . . . . . . . . . . . . . . . . . 68
Appendix G. MTA Relays . . . . . . . . . . . . . . . . . . . . . 69 Appendix F. MTA Relays . . . . . . . . . . . . . . . . . . . . . 69
Appendix H. Local Policy Considerations . . . . . . . . . . . . . 70 Appendix G. Local Policy Considerations . . . . . . . . . . . . . 70
H.1. Policy For SPF Pass . . . . . . . . . . . . . . . . . . . 70 G.1. Policy For SPF Pass . . . . . . . . . . . . . . . . . . . 70
H.2. Policy For SPF Fail . . . . . . . . . . . . . . . . . . . 70 G.2. Policy For SPF Fail . . . . . . . . . . . . . . . . . . . 70
H.3. Policy For SPF Permerror . . . . . . . . . . . . . . . . . 71 G.3. Policy For SPF Permerror . . . . . . . . . . . . . . . . . 71
H.4. Policy For SPF Temperror . . . . . . . . . . . . . . . . . 71 G.4. Policy For SPF Temperror . . . . . . . . . . . . . . . . . 71
Appendix I. Protocol Status . . . . . . . . . . . . . . . . . . . 73 Appendix H. Protocol Status . . . . . . . . . . . . . . . . . . . 73
Appendix J. Change History . . . . . . . . . . . . . . . . . . . 74 Appendix I. Change History . . . . . . . . . . . . . . . . . . . 74
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 77
1. Introduction 1. Introduction
The current email infrastructure has the property that any host The current email infrastructure has the property that any host
injecting mail into the system can use any DNS domain name it wants injecting mail into the system can use any DNS domain name it wants
in each of the various identifiers specified by [RFC5321] and in each of the various identifiers specified by [RFC5321] and
[RFC5322]. Although this feature is desirable in some circumstances, [RFC5322]. Although this feature is desirable in some circumstances,
it is a major obstacle to reducing Unsolicited Bulk Email (UBE, aka it is a major obstacle to reducing Unsolicited Bulk Email (UBE, aka
spam). Furthermore, many domain owning ADMDs (as described in spam). Furthermore, many domain owning ADMDs (as described in
skipping to change at page 39, line 15 skipping to change at page 39, line 15
"neutral" more harshly than "none" would discourage ADMDs from "neutral" more harshly than "none" would discourage ADMDs from
testing the use of SPF records (see Section 10.1). testing the use of SPF records (see Section 10.1).
8.3. Pass 8.3. Pass
A "pass" result means that the client is authorized to inject mail A "pass" result means that the client is authorized to inject mail
with the given identity. The domain can now, in the sense of with the given identity. The domain can now, in the sense of
reputation, be considered responsible for sending the message. reputation, be considered responsible for sending the message.
Further policy checks can now proceed with confidence in the Further policy checks can now proceed with confidence in the
legitimate use of the identity. This is further discussed in legitimate use of the identity. This is further discussed in
Appendix H.1. Appendix G.1.
8.4. Fail 8.4. Fail
A "fail" result is an explicit statement that the client is not A "fail" result is an explicit statement that the client is not
authorized to use the domain in the given identity. Disposition of authorized to use the domain in the given identity. Disposition of
SPF fail messages is a matter of local policy. See Appendix H.2 for SPF fail messages is a matter of local policy. See Appendix G.2 for
considerations on developing local policy. considerations on developing local policy.
If the checking software chooses to reject the mail during the SMTP If the checking software chooses to reject the mail during the SMTP
transaction, then it SHOULD use an SMTP reply code of 550 (see transaction, then it SHOULD use an SMTP reply code of 550 (see
[RFC5321]) and, if supported, the 5.7.1 enhanced status code (see [RFC5321]) and, if supported, the 5.7.1 enhanced status code (see
[RFC3463], Section 3.8), in addition to an appropriate reply text. [RFC3463], Section 3.8), in addition to an appropriate reply text.
The check_host() function will return either a default explanation The check_host() function will return either a default explanation
string or one from the domain that published the SPF records (see string or one from the domain that published the SPF records (see
Section 6.2). If the information does not originate with the Section 6.2). If the information does not originate with the
checking software, it is good to make it clear that the text is checking software, it is good to make it clear that the text is
skipping to change at page 40, line 21 skipping to change at page 40, line 21
8.6. Temperror 8.6. Temperror
A "temperror" result means the SPF verifier encountered a transient A "temperror" result means the SPF verifier encountered a transient
(generally DNS) error while performing the check. Checking software (generally DNS) error while performing the check. Checking software
can choose to accept or temporarily reject the message. If the can choose to accept or temporarily reject the message. If the
message is rejected during the SMTP transaction for this reason, the message is rejected during the SMTP transaction for this reason, the
software SHOULD use an SMTP reply code of 451 and, if supported, the software SHOULD use an SMTP reply code of 451 and, if supported, the
4.4.3 enhanced status code (see [RFC3463], Section 3.5). These 4.4.3 enhanced status code (see [RFC3463], Section 3.5). These
errors can be caused by problems in either the sender's or receiver's errors can be caused by problems in either the sender's or receiver's
DNS software. See Appendix H.4 for considerations on developing DNS software. See Appendix G.4 for considerations on developing
local policy. local policy.
8.7. Permerror 8.7. Permerror
A "permerror" result means the domain's published records could not A "permerror" result means the domain's published records could not
be correctly interpreted. This signals an error condition that be correctly interpreted. This signals an error condition that
definitely requires DNS operator intervention to be resolved. If the definitely requires DNS operator intervention to be resolved. If the
message is rejected during the SMTP transaction for this reason, the message is rejected during the SMTP transaction for this reason, the
software SHOULD use an SMTP reply code of 550 and, if supported, the software SHOULD use an SMTP reply code of 550 and, if supported, the
5.5.2 enhanced status code (see [RFC3463], Section 3.6). Be aware 5.5.2 enhanced status code (see [RFC3463], Section 3.6). Be aware
that if the ADMD uses macros (Section 7), it is possible that this that if the ADMD uses macros (Section 7), it is possible that this
result is due to the checked identities having an unexpected format. result is due to the checked identities having an unexpected format.
It is also possible that this result is generated by certain SPF It is also possible that this result is generated by certain SPF
verifiers due to the input arguments having an unexpected format; see verifiers due to the input arguments having an unexpected format; see
Section 4.8. See Appendix H.3 for considerations on developing local Section 4.8. See Appendix G.3 for considerations on developing local
policy. policy.
9. Recording the Result 9. Recording the Result
To provide downstream agents, such as MUAs, with the information they To provide downstream agents, such as MUAs, with the information they
might need in terms of evaluating or representing the apparent safety might need in terms of evaluating or representing the apparent safety
of the message content, it is RECOMMENDED that SMTP receivers record of the message content, it is RECOMMENDED that SMTP receivers record
the result of SPF processing in the message header. For SPF verifier the result of SPF processing in the message header. For SPF verifier
operators that choose to record SPF results in the header of the operators that choose to record SPF results in the header of the
message for processing by internal filters or MUAs, two methods are message for processing by internal filters or MUAs, two methods are
skipping to change at page 46, line 47 skipping to change at page 46, line 47
The hostname is generally the identity used in the 5321.HELO/.EHLO The hostname is generally the identity used in the 5321.HELO/.EHLO
command. In the case of messages with a null 5321.MailFrom, this is command. In the case of messages with a null 5321.MailFrom, this is
used as the domain for 5321.MailFrom SPF checks, in addition to being used as the domain for 5321.MailFrom SPF checks, in addition to being
used in 5321.HELO/.EHLO based SPF checks. The standard SPF record used in 5321.HELO/.EHLO based SPF checks. The standard SPF record
for an individual host that is involved in mail processing is: for an individual host that is involved in mail processing is:
relay.example.com. IN TXT "v=spf1 a -all" relay.example.com. IN TXT "v=spf1 a -all"
Validating correct deployment is difficult. [RFC6652] describes one Validating correct deployment is difficult. [RFC6652] describes one
mechanism for soliciting feedback on SPF failures. Another mechanism for soliciting feedback on SPF failures. Another
suggestion can be found in Appendix D. suggestion can be found in Appendix C.
Regardless of the method used, understanding the ADMD's outbound mail Regardless of the method used, understanding the ADMD's outbound mail
architecture is essential to effective deployment. architecture is essential to effective deployment.
10.1.3. Bounces 10.1.3. Bounces
As explained in Section 1.1.3, [RFC5321] allows the MAIL FROM to be As explained in Section 1.1.3, [RFC5321] allows the MAIL FROM to be
null, which is typical of some Delivery Status Notification null, which is typical of some Delivery Status Notification
[RFC3464], commonly called email bounces. In this case the only [RFC3464], commonly called email bounces. In this case the only
entity available for performing an SPF check is the "HELO" identity entity available for performing an SPF check is the "HELO" identity
skipping to change at page 47, line 31 skipping to change at page 47, line 31
SPF results can be used in combination with other methods to SPF results can be used in combination with other methods to
determine the final local disposition (either positive or negative) determine the final local disposition (either positive or negative)
of a message. It can also be considered dispositive on its own. of a message. It can also be considered dispositive on its own.
An attempt to have one organization (sender) direct the email An attempt to have one organization (sender) direct the email
handling policies of another (receiver) is inherently challenging and handling policies of another (receiver) is inherently challenging and
often controversial. As stated elsewhere in this document, there is often controversial. As stated elsewhere in this document, there is
no comprehensive normative requirement for specific handling of a no comprehensive normative requirement for specific handling of a
message based on SPF results. The information presented in Section 8 message based on SPF results. The information presented in Section 8
and in Appendix H is offered for receiver consideration when forming and in Appendix G is offered for receiver consideration when forming
local handling policies. local handling policies.
The primary considerations are that SPF might return "pass" for mail The primary considerations are that SPF might return "pass" for mail
that is ultimately harmful (e.g., spammers that arrange for SPF to that is ultimately harmful (e.g., spammers that arrange for SPF to
pass using disposable domain names, or virus or spam outbreaks from pass using disposable domain names, or virus or spam outbreaks from
within trusted sources), and might also return "fail" for mail that within trusted sources), and might also return "fail" for mail that
is ultimately legitimate (e.g., legitimate mail that has traversed a is ultimately legitimate (e.g., legitimate mail that has traversed a
mail alias). It is important take both of these cases under mail alias). It is important take both of these cases under
consideration when establishing local handling policy. consideration when establishing local handling policy.
skipping to change at page 48, line 14 skipping to change at page 48, line 14
Because SPF evaluation is based on the IP address of the "last" Because SPF evaluation is based on the IP address of the "last"
sending SMTP server, the address of the mediator will be used, rather 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 than the address of the SMTP server that sent the message to the
mediator. Some mediators retain the email address from the original mediator. Some mediators retain the email address from the original
message, while some use a new address. message, while some use a new address.
If the address is the same as for the original message, and the If the address is the same as for the original message, and the
original message had an associated SPF record, then the SPF original message had an associated SPF record, then the SPF
evaluation will fail unless mitigations such as those described in evaluation will fail unless mitigations such as those described in
Appendix E are used. Appendix D are used.
11. Security Considerations 11. Security Considerations
11.1. Processing Limits 11.1. Processing Limits
As with most aspects of email, there are a number of ways that As with most aspects of email, there are a number of ways that
malicious parties could use the protocol as an avenue for a malicious parties could use the protocol as an avenue for a
Denial-of-Service (DoS) attack. The processing limits outlined in Denial-of-Service (DoS) attack. The processing limits outlined in
Section 4.6.4 are designed to prevent attacks such as the following: Section 4.6.4 are designed to prevent attacks such as the following:
skipping to change at page 53, line 5 skipping to change at page 53, line 5
to likely harm. This is especially true for domains belonging to to likely harm. This is especially true for domains belonging to
known good actors that are typically well-behaved; unauthorized mail known good actors that are typically well-behaved; unauthorized mail
from those sources might well be subjected to much higher skepticism from those sources might well be subjected to much higher skepticism
and content analysis. and content analysis.
SPF does not, however, include the capacity for identifying good SPF does not, however, include the capacity for identifying good
actors from bad ones, nor does it handle the concept of known actors actors from bad ones, nor does it handle the concept of known actors
versus unknown ones. Those notions are out of scope for this versus unknown ones. Those notions are out of scope for this
specification. specification.
12. Contributors and Acknowledgements 12. Collected ABNF
This section is normative and any discrepancies with the ABNF
fragments in the preceding text are to be resolved in favor of this
grammar.
See [RFC5234] for ABNF notation. Please note that as per this ABNF
definition, literal text strings (those in quotes) are case-
insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx".
record = version terms *SP
version = "v=spf1"
terms = *( 1*SP ( directive / modifier ) )
directive = [ qualifier ] mechanism
qualifier = "+" / "-" / "?" / "~"
mechanism = ( all / include
/ a / mx / ptr / ip4 / ip6 / exists )
all = "all"
include = "include" ":" domain-spec
a = "a" [ ":" domain-spec ] [ dual-cidr-length ]
mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
ptr = "ptr" [ ":" domain-spec ]
ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
exists = "exists" ":" domain-spec
modifier = redirect / explanation / unknown-modifier
redirect = "redirect" "=" domain-spec
explanation = "exp" "=" domain-spec
unknown-modifier = name "=" macro-string
; where name is not any known modifier
ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32
ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
; conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as per [RFC 4291], section 2.2>
; e.g., 2001:DB8::CD30
domain-spec = macro-string domain-end
domain-end = ( "." toplabel [ "." ] ) / macro-expand
toplabel = ( *alphanum ALPHA *alphanum ) /
( 1*alphanum "-" *( alphanum / "-" ) alphanum )
; LDH rule plus additional TLD restrictions
; (see [RFC3696], Section 2 for background)
alphanum = ALPHA / DIGIT
explain-string = *( macro-string / SP )
macro-string = *( macro-expand / macro-literal )
macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-"
macro-literal = %x21-24 / %x26-7E
; visible characters except "%"
macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
"c" / "r" / "t" / "v"
transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
[ key-value-list ] CRLF
result = "pass" / "fail" / "softfail" / "neutral" /
"none" / "temperror" / "permerror"
key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
[";"]
key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
key = "client-ip" / "envelope-from" / "helo" /
"problem" / "receiver" / "identity" /
"mechanism" / name
identity = "mailfrom" ; for the "MAIL FROM" identity
/ "helo" ; for the "HELO" identity
/ name ; other identities
sender = Mailbox
ip = ip4-network / ip6-network
ALPHA = <A-Z / a-z as per [RFC5234]>
DIGIT = <0-9 as per [RFC5234]>
SP = <space character as per [RFC5234]>
dot-atom = <unquoted word as per [RFC5322]>
quoted-string = <quoted string as per [RFC5322]>
comment = <comment string as per [RFC5322]>
CFWS = <comment or folding white space as per [RFC5322]>
FWS = <folding white space as per [RFC5322]>
CRLF = <standard end-of-line token as per [RFC5322]>
13. Contributors and Acknowledgements
This document is largely based on the work of Meng Weng Wong, Mark This document is largely based on the work of Meng Weng Wong, Mark
Lentczner, and Wayne Schlitt. Although, as this section Lentczner, and Wayne Schlitt. Although, as this section
acknowledges, many people have contributed to this document, a very acknowledges, many people have contributed to this document, a very
large portion of the writing and editing are due to Meng, Mark, and large portion of the writing and editing are due to Meng, Mark, and
Wayne. Wayne.
This design owes a debt of parentage to [RMX] by Hadmut Danisch and This design owes a debt of parentage to [RMX] by Hadmut Danisch and
to [DMP] by Gordon Fecyk. The idea of using a DNS record to check to [DMP] by Gordon Fecyk. The idea of using a DNS record to check
the legitimacy of an email address traces its ancestry further back the legitimacy of an email address traces its ancestry further back
skipping to change at page 54, line 5 skipping to change at page 57, line 5
the development of this design. They are far too numerous to name, the development of this design. They are far too numerous to name,
but they include the following: but they include the following:
The participants in the SPFbis working group. The participants in the SPFbis working group.
The folks on the spf-discuss mailing list. The folks on the spf-discuss mailing list.
The folks on the SPAM-L mailing list. The folks on the SPAM-L mailing list.
The folks on the IRTF ASRG mailing list. The folks on the IRTF ASRG mailing list.
The folks on the IETF MARID mailing list. The folks on the IETF MARID mailing list.
The folks on #perl. The folks on #perl.
13. IANA Considerations 14. IANA Considerations
13.1. The SPF DNS Record Type 14.1. The SPF DNS Record Type
Per [RFC4408], the IANA assigned the Resource Record Type and Qtype Per [RFC4408], the IANA assigned the Resource Record Type and Qtype
from the DNS Parameters Registry for the SPF RR type with code 99. from the DNS Parameters Registry for the SPF RR type with code 99.
The format of this type is identical to the TXT RR [RFC1035]. The The format of this type is identical to the TXT RR [RFC1035]. The
character content of the record is encoded as [US-ASCII]. character content of the record is encoded as [US-ASCII].
Studies have shown that RRTYPE 99 has not seen any substantial use, Studies have shown that RRTYPE 99 has not seen any substantial use,
and in fact its existence and mechanism defined in [RFC4408] has led and in fact its existence and mechanism defined in [RFC4408] has led
to some interoperability issues. Accordingly, its use is now to some interoperability issues. Accordingly, its use is now
obsolete, and new implementations are not to use it. obsolete, and new implementations are not to use it.
IANA is requested to update the Resource Record (RR) TYPEs registry IANA is requested to update the Resource Record (RR) TYPEs registry
to indicate that this document is the reference document for that to indicate that this document is the reference document for that
RRTYPE. RRTYPE.
[NOTE TO RFC EDITOR: (to be changed to " ... has updated ..." upon [NOTE TO RFC EDITOR: (to be changed to " ... has updated ..." upon
publication)] publication)]
13.2. The Received-SPF Mail Header Field 14.2. The Received-SPF Mail Header Field
Per [RFC3864], the "Received-SPF:" header field is added to the IANA Per [RFC3864], the "Received-SPF:" header field is added to the IANA
Permanent Message Header Field Registry. The following is the Permanent Message Header Field Registry. The following is the
registration template: registration template:
Header field name: Received-SPF Header field name: Received-SPF
Applicable protocol: mail ([RFC5322]) Applicable protocol: mail ([RFC5322])
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): RFC XXXX Specification document(s): RFC XXXX
[NOTE TO RFC EDITOR: (this document)] [NOTE TO RFC EDITOR: (this document)]
13.3. SPF Modifier Registry 14.3. SPF Modifier Registry
IANA is requested to change the reference for the exp and redirect IANA is requested to change the reference for the exp and redirect
modifiers in the Modifier Names registry, under Sender Policy modifiers in the Modifier Names registry, under Sender Policy
Framework Parameters, from [RFC4408] to this document. Their status Framework Parameters, from [RFC4408] to this document. Their status
is unchanged. is unchanged.
14. References 15. References
14.1. Normative References 15.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 56, line 11 skipping to change at page 59, line 11
[US-ASCII] [US-ASCII]
American National Standards Institute (formerly United American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for States of America Standards Institute), "USA Code for
Information Interchange, X3.4", 1968. Information Interchange, X3.4", 1968.
ANSI X3.4-1968 has been replaced by newer versions with ANSI X3.4-1968 has been replaced by newer versions with
slight modifications, but the 1968 version remains slight modifications, but the 1968 version remains
definitive for the Internet. definitive for the Internet.
14.2. Informative References 15.2. Informative References
[DMP] Fecyk, G., "Designated Mailers Protocol". [DMP] Fecyk, G., "Designated Mailers Protocol".
Work In Progress Work In Progress
[Green] Green, D., "Domain-Authorized SMTP Mail", 2002. [Green] Green, D., "Domain-Authorized SMTP Mail", 2002.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
skipping to change at page 58, line 5 skipping to change at page 61, line 5
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
[RMX] Danisch, H., "The RMX DNS RR Type for light weight sender [RMX] Danisch, H., "The RMX DNS RR Type for light weight sender
authentication". authentication".
Work In Progress Work In Progress
[Vixie] Vixie, P., "Repudiating MAIL FROM", 2002. [Vixie] Vixie, P., "Repudiating MAIL FROM", 2002.
Appendix A. Collected ABNF Appendix A. Extended Examples
This section is normative and any discrepancies with the ABNF
fragments in the preceding text are to be resolved in favor of this
grammar.
See [RFC5234] for ABNF notation. Please note that as per this ABNF
definition, literal text strings (those in quotes) are case-
insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx".
record = version terms *SP
version = "v=spf1"
terms = *( 1*SP ( directive / modifier ) )
directive = [ qualifier ] mechanism
qualifier = "+" / "-" / "?" / "~"
mechanism = ( all / include
/ a / mx / ptr / ip4 / ip6 / exists )
all = "all"
include = "include" ":" domain-spec
a = "a" [ ":" domain-spec ] [ dual-cidr-length ]
mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
ptr = "ptr" [ ":" domain-spec ]
ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
exists = "exists" ":" domain-spec
modifier = redirect / explanation / unknown-modifier
redirect = "redirect" "=" domain-spec
explanation = "exp" "=" domain-spec
unknown-modifier = name "=" macro-string
; where name is not any known modifier
ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32
ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
; conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as per [RFC 4291], section 2.2>
; e.g., 2001:DB8::CD30
domain-spec = macro-string domain-end
domain-end = ( "." toplabel [ "." ] ) / macro-expand
toplabel = ( *alphanum ALPHA *alphanum ) /
( 1*alphanum "-" *( alphanum / "-" ) alphanum )
; LDH rule plus additional TLD restrictions
; (see [RFC3696], Section 2 for background)
alphanum = ALPHA / DIGIT
explain-string = *( macro-string / SP )
macro-string = *( macro-expand / macro-literal )
macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-"
macro-literal = %x21-24 / %x26-7E
; visible characters except "%"
macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
"c" / "r" / "t" / "v"
transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
[ key-value-list ] CRLF
result = "pass" / "fail" / "softfail" / "neutral" /
"none" / "temperror" / "permerror"
key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
[";"]
key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
key = "client-ip" / "envelope-from" / "helo" /
"problem" / "receiver" / "identity" /
"mechanism" / name
identity = "mailfrom" ; for the "MAIL FROM" identity
/ "helo" ; for the "HELO" identity
/ name ; other identities
sender = Mailbox
ip = ip4-network / ip6-network
ALPHA = <A-Z / a-z as per [RFC5234]>
DIGIT = <0-9 as per [RFC5234]>
SP = <space character as per [RFC5234]>
dot-atom = <unquoted word as per [RFC5322]>
quoted-string = <quoted string as per [RFC5322]>
comment = <comment string as per [RFC5322]>
CFWS = <comment or folding white space as per [RFC5322]>
FWS = <folding white space as per [RFC5322]>
CRLF = <standard end-of-line token as per [RFC5322]>
Appendix B. Extended Examples
These examples are based on the following DNS setup: These examples are based on the following DNS setup:
; A domain with two mail servers, two hosts ; A domain with two mail servers, two hosts
; and two servers at the domain name ; and two servers at the domain name
$ORIGIN example.com. $ORIGIN example.com.
@ MX 10 mail-a @ MX 10 mail-a
MX 20 mail-b MX 20 mail-b
A 192.0.2.10 A 192.0.2.10
A 192.0.2.11 A 192.0.2.11
skipping to change at page 61, line 42 skipping to change at page 61, line 42
66 PTR bob.example.com. 66 PTR bob.example.com.
129 PTR mail-a.example.com. 129 PTR mail-a.example.com.
130 PTR mail-b.example.com. 130 PTR mail-b.example.com.
140 PTR mail-c.example.org. 140 PTR mail-c.example.org.
; A rogue reverse IP domain that claims to be ; A rogue reverse IP domain that claims to be
; something it's not ; something it's not
$ORIGIN 0.0.10.in-addr.arpa. $ORIGIN 0.0.10.in-addr.arpa.
4 PTR bob.example.com. 4 PTR bob.example.com.
B.1. Simple Examples A.1. Simple Examples
These examples show various possible published records for These examples show various possible published records for
example.com and which values if <ip> would cause check_host() to example.com and which values if <ip> would cause check_host() to
return "pass". Note that <domain> is "example.com". return "pass". Note that <domain> is "example.com".
v=spf1 +all v=spf1 +all
-- any <ip> passes -- any <ip> passes
v=spf1 a -all v=spf1 a -all
-- hosts 192.0.2.10 and 192.0.2.11 pass -- hosts 192.0.2.10 and 192.0.2.11 pass
skipping to change at page 62, line 35 skipping to change at page 62, line 35
-- sending host 192.0.2.65 passes (reverse DNS is valid and is in -- sending host 192.0.2.65 passes (reverse DNS is valid and is in
example.com) example.com)
-- sending host 192.0.2.140 fails (reverse DNS is valid, but not -- sending host 192.0.2.140 fails (reverse DNS is valid, but not
in example.com) in example.com)
-- sending host 10.0.0.4 fails (reverse IP is not valid) -- sending host 10.0.0.4 fails (reverse IP is not valid)
v=spf1 ip4:192.0.2.128/28 -all v=spf1 ip4:192.0.2.128/28 -all
-- sending host 192.0.2.65 fails -- sending host 192.0.2.65 fails
-- sending host 192.0.2.129 passes -- sending host 192.0.2.129 passes
B.2. Multiple Domain Example A.2. Multiple Domain Example
These examples show the effect of related records: These examples show the effect of related records:
example.org: "v=spf1 include:example.com include:example.net -all" example.org: "v=spf1 include:example.com include:example.net -all"
This record would be used if mail from example.org actually came This record would be used if mail from example.org actually came
through servers at example.com and example.net. Example.org's through servers at example.com and example.net. Example.org's
designated servers are the union of example.com's and example.net's designated servers are the union of example.com's and example.net's
designated servers. designated servers.
la.example.org: "v=spf1 redirect=example.org" la.example.org: "v=spf1 redirect=example.org"
ny.example.org: "v=spf1 redirect=example.org" ny.example.org: "v=spf1 redirect=example.org"
sf.example.org: "v=spf1 redirect=example.org" sf.example.org: "v=spf1 redirect=example.org"
These records allow a set of domains that all use the same mail These records allow a set of domains that all use the same mail
system to make use of that mail system's record. In this way, only system to make use of that mail system's record. In this way, only
the mail system's record needs to be updated when the mail setup the mail system's record needs to be updated when the mail setup
changes. These domains' records never have to change. changes. These domains' records never have to change.
B.3. DNSBL Style Example A.3. DNSBL Style Example
Imagine that, in addition to the domain records listed above, there Imagine that, in addition to the domain records listed above, there
are these (see [RFC5782]): are these (see [RFC5782]):
$ORIGIN _spf.example.com. $ORIGIN _spf.example.com.
mary.mobile-users A 127.0.0.2 mary.mobile-users A 127.0.0.2
fred.mobile-users A 127.0.0.2 fred.mobile-users A 127.0.0.2
15.15.168.192.joel.remote-users A 127.0.0.2 15.15.168.192.joel.remote-users A 127.0.0.2
16.15.168.192.joel.remote-users A 127.0.0.2 16.15.168.192.joel.remote-users A 127.0.0.2
skipping to change at page 63, line 36 skipping to change at page 63, line 36
-all -all
mobile-users._spf.example.com: mobile-users._spf.example.com:
v=spf1 exists:%{l1r+}.%{d} v=spf1 exists:%{l1r+}.%{d}
remote-users._spf.example.com: remote-users._spf.example.com:
v=spf1 exists:%{ir}.%{l1r+}.%{d} v=spf1 exists:%{ir}.%{l1r+}.%{d}
B.4. Multiple Requirements Example A.4. Multiple Requirements Example
Say that your sender policy requires both that the IP address is Say that your sender policy requires both that the IP address is
within a certain range and that the reverse DNS for the IP matches. within a certain range and that the reverse DNS for the IP matches.
This can be done several ways, including the following: This can be done several ways, including the following:
example.com. SPF ( "v=spf1 " example.com. SPF ( "v=spf1 "
"-include:ip4._spf.%{d} " "-include:ip4._spf.%{d} "
"-include:ptr._spf.%{d} " "-include:ptr._spf.%{d} "
"+all" ) "+all" )
ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all" ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all"
ptr._spf.example.com. SPF "v=spf1 -ptr +all" ptr._spf.example.com. SPF "v=spf1 -ptr +all"
This example shows how the "-include" mechanism can be useful, how an This example shows how the "-include" mechanism can be useful, how an
SPF record that ends in "+all" can be very restrictive, and the use SPF record that ends in "+all" can be very restrictive, and the use
of De Morgan's Law. of De Morgan's Law.
Appendix C. Changes in implementation requirements from RFC 4408 Appendix B. Changes in implementation requirements from RFC 4408
The modifications to implementation requirements from [RFC4408] are The modifications to implementation requirements from [RFC4408] are
all either (a) corrections to errors in [RFC4408], or (b) additional all either (a) corrections to errors in [RFC4408], or (b) additional
documentation based on consensus of operational experience acquired documentation based on consensus of operational experience acquired
since publication of [RFC4408]. since publication of [RFC4408].
o Use of DNS RR type SPF (99) has been removed from the protocol, o Use of DNS RR type SPF (99) has been removed from the protocol,
see [RFC6686] for background. see [RFC6686] for background.
o A new DNS related processing limit based on "void lookups" has o A new DNS related processing limit based on "void lookups" has
skipping to change at page 64, line 28 skipping to change at page 64, line 28
o Use of the ptr mechanism and the %p macro have been strongly o Use of the ptr mechanism and the %p macro have been strongly
discouraged Section 5.5 and Section 7.2. They remain part of the discouraged Section 5.5 and Section 7.2. They remain part of the
protocol because they were found to be in use, but records ought protocol because they were found to be in use, but records ought
to be updated to avoid them. to be updated to avoid them.
o Use of the "Authentication-Results" header field [RFC5451] as a o Use of the "Authentication-Results" header field [RFC5451] as a
possible alternative to use of the "Received-SPF" header field is possible alternative to use of the "Received-SPF" header field is
discussed (Section 9.2). discussed (Section 9.2).
o There have been a number of minor corrections to the ABNF to make o There have been a number of minor corrections to the ABNF to make
it more clear and correct Appendix A. SPF library implementers it more clear and correct Section 12. SPF library implementers
should give the revised ABNF a careful review to determine if should give the revised ABNF a careful review to determine if
implementation changes are needed. implementation changes are needed.
o Use of X- fields in the ABNF has been removed see [RFC6648] for o Use of X- fields in the ABNF has been removed see [RFC6648] for
background. background.
o Ambiguity about how to deal with invalid domain-spec after macro o Ambiguity about how to deal with invalid domain-spec after macro
expansion has been documented. Depending on one specific behavior expansion has been documented. Depending on one specific behavior
has to be avoided (Section 4.8). has to be avoided (Section 4.8).
o General operational information has been updated and expanded o General operational information has been updated and expanded
based on eight years of post [RFC4408] operations experience. See based on eight years of post [RFC4408] operations experience. See
Section 10 and Appendices D - H below. Section 10 and Appendices D - H below.
o Security considerations have been reviewed and updated o Security considerations have been reviewed and updated
(Section 11). (Section 11).
Appendix D. Further Testing Advice Appendix C. Further Testing Advice
Another approach that can be helpful to publish records that include Another approach that can be helpful to publish records that include
a "tracking exists:" mechanism. By looking at the name server logs, a "tracking exists:" mechanism. By looking at the name server logs,
a rough list can then be generated. For example: a rough list can then be generated. For example:
v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all
Appendix E. SPF/Mediator Interactions Appendix D. SPF/Mediator Interactions
There are three places that techniques can be used to ameliorate There are three places that techniques can be used to ameliorate
unintended SPF failures with mediators. unintended SPF failures with mediators.
E.1. Originating ADMDs D.1. Originating ADMDs
The beginning, when email is first sent: The beginning, when email is first sent:
o "Neutral" results could be given for IP addresses that might be o "Neutral" results could be given for IP addresses that might be
forwarders, instead of "fail" results based on a list of known forwarders, instead of "fail" results based on a list of known
reliable forwarders. For example: reliable forwarders. For example:
"v=spf1 mx ?exists:%{ir}.whitlist.example.org -all" "v=spf1 mx ?exists:%{ir}.whitlist.example.org -all"
This would cause a lookup on an DNS white list (DNSWL) and cause a This would cause a lookup on an DNS white list (DNSWL) and cause a
skipping to change at page 67, line 7 skipping to change at page 67, line 7
rate-limit the email coming from unexpected IP addresses. rate-limit the email coming from unexpected IP addresses.
"v=spf1 mx exists:%{ir}._spf_rate.%{d} -all" "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"
o SPF allows the creation of per-user policies for special cases. o SPF allows the creation of per-user policies for special cases.
For example, the following SPF record and appropriate wildcard DNS For example, the following SPF record and appropriate wildcard DNS
records can be used: records can be used:
"v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}" "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"
E.2. Mediators D.2. Mediators
The middle, when email is forwarded:. The middle, when email is forwarded:.
o Mediators can solve the problem by rewriting the "MAIL FROM" to be o Mediators can solve the problem by rewriting the "MAIL FROM" to be
in their own domain. This means mail rejected from the external in their own domain. This means mail rejected from the external
mailbox will have to be forwarded back to the original sender by mailbox will have to be forwarded back to the original sender by
the forwarding service. Various schemes to do this exist though the forwarding service. Various schemes to do this exist though
they vary widely in complexity and resource requirements on the they vary widely in complexity and resource requirements on the
part of the mediator. part of the mediator.
skipping to change at page 67, line 29 skipping to change at page 67, line 29
"mailing list" semantics by configuring an additional alias with "mailing list" semantics by configuring an additional alias with
"owner-" prepended to the original alias name (e.g., an alias of "owner-" prepended to the original alias name (e.g., an alias of
"friends: george@example.com, fred@example.org" would need another "friends: george@example.com, fred@example.org" would need another
alias of the form "owner-friends: localowner"). alias of the form "owner-friends: localowner").
o Mediators could reject mail that would "fail" SPF if forwarded o Mediators could reject mail that would "fail" SPF if forwarded
using an SMTP reply code of 551, User not local, (see [RFC5321] using an SMTP reply code of 551, User not local, (see [RFC5321]
section 3.4) to communicate the correct target address to resend section 3.4) to communicate the correct target address to resend
the mail to. the mail to.
E.3. Receving ADMDs D.3. Receving ADMDs
The end, when email is received: The end, when email is received:
o If the owner of the external mailbox wishes to trust the mediator, o If the owner of the external mailbox wishes to trust the mediator,
he can direct the external mailbox's MTA to skip SPF tests when he can direct the external mailbox's MTA to skip SPF tests when
the client host belongs to the mediator. the client host belongs to the mediator.
o Tests against other identities, such as the "HELO" identity, can o Tests against other identities, such as the "HELO" identity, can
be used to override a failed test against the "MAIL FROM" be used to override a failed test against the "MAIL FROM"
identity. identity.
o For larger domains, it might not be possible to have a complete or o For larger domains, it might not be possible to have a complete or
accurate list of forwarding services used by the owners of the accurate list of forwarding services used by the owners of the
domain's mailboxes. In such cases, whitelists of generally- domain's mailboxes. In such cases, whitelists of generally-
recognized forwarding services could be employed. recognized forwarding services could be employed.
Appendix F. Mail Services Appendix E. Mail Services
MSPs (Mail Service Providers - [RFC5598] Section 2.3) that offer mail MSPs (Mail Service Providers - [RFC5598] Section 2.3) that offer mail
services to third-party domains, such as sending of bulk mail, might services to third-party domains, such as sending of bulk mail, might
want to adjust their configurations in light of the authorization want to adjust their configurations in light of the authorization
check described in this document. If the domain part of the "MAIL check described in this document. If the domain part of the "MAIL
FROM" identity used for such email uses the domain of one of the MSPs FROM" identity used for such email uses the domain of one of the MSPs
domain, then the provider needs only to ensure that its sending host domain, then the provider needs only to ensure that its sending host
is authorized by its own SPF record, if any. is authorized by its own SPF record, if any.
If the "MAIL FROM" identity does not use the MSP's domain, then extra If the "MAIL FROM" identity does not use the MSP's domain, then extra
care has to be taken. The SPF record format has several options for care has to be taken. The SPF record format has several options for
the third-party domain to authorize the service provider's MTAs to the third-party domain to authorize the service provider's MTAs to
send mail on its behalf. For MSPs, such as ISPs, that have a wide send mail on its behalf. For MSPs, such as ISPs, that have a wide
variety of customers using the same MTA, steps are required to variety of customers using the same MTA, steps are required to
mitigate the risk of cross-customer forgery (see Section 11.4). mitigate the risk of cross-customer forgery (see Section 11.4).
Appendix G. MTA Relays Appendix F. MTA Relays
Relays are described in [RFC5598] Section 2.2.2. The authorization Relays are described in [RFC5598] Section 2.2.2. The authorization
check generally precludes the use of arbitrary MTA relays between check generally precludes the use of arbitrary MTA relays between
sender and receiver of an email message. sender and receiver of an email message.
Within an organization, MTA relays can be effectively deployed. Within an organization, MTA relays can be effectively deployed.
However, for purposes of this document, such relays are effectively However, for purposes of this document, such relays are effectively
transparent. The SPF authorization check is a check between border transparent. The SPF authorization check is a check between border
MTAs of different ADMDs. MTAs of different ADMDs.
skipping to change at page 70, line 5 skipping to change at page 70, line 5
relayed mail stream) then do not perform the authorization test. To relayed mail stream) then do not perform the authorization test. To
perform the authorization test other than at the boundary, the host perform the authorization test other than at the boundary, the host
that first transferred the message to the receiving ADMD have to be that first transferred the message to the receiving ADMD have to be
determined, which can be difficult to extract from the message header determined, which can be difficult to extract from the message header
because (a) header fields can be forged or malformed, and (b) there's because (a) header fields can be forged or malformed, and (b) there's
no standard way to encode that information such that it can be no standard way to encode that information such that it can be
reliably extracted. Testing other than at the boundary is likely to reliably extracted. Testing other than at the boundary is likely to
produce unreliable results. This is described further in Appendix C produce unreliable results. This is described further in Appendix C
of [RFC5451]. of [RFC5451].
Appendix H. Local Policy Considerations Appendix G. Local Policy Considerations
SPF results can be used in combination with other methods to SPF results can be used in combination with other methods to
determine the final local disposition (either positive or negative of determine the final local disposition (either positive or negative of
a message. It can also be considered dispositive on its own. a message. It can also be considered dispositive on its own.
H.1. Policy For SPF Pass G.1. Policy For SPF Pass
SPF pass results can be used in combination with "white lists" of SPF pass results can be used in combination with "white lists" of
known "good" domains to bypass some or all additional pre-delivery known "good" domains to bypass some or all additional pre-delivery
email checks. Exactly which checks and how to determine appropriate email checks. Exactly which checks and how to determine appropriate
white list entries has to be based on local conditions and white list entries has to be based on local conditions and
requirements. requirements.
H.2. Policy For SPF Fail G.2. Policy For SPF Fail
SPF fail results can be used to reject messages during the SMTP SPF fail results can be used to reject messages during the SMTP
transaction based on either "MAIL FROM" or "HELO" identity results. transaction based on either "MAIL FROM" or "HELO" identity results.
This reduces resource requirements for various content filtering This reduces resource requirements for various content filtering
methods and conserves bandwidth since rejection can be done before methods and conserves bandwidth since rejection can be done before
the SMTP content is transferred. It also gives immediate feedback to the SMTP content is transferred. It also gives immediate feedback to
the sender who might then be able to resolve the issue. Due to some the sender who might then be able to resolve the issue. Due to some
of the issues described above in this section (Section 10), SPF based of the issues described above in this section (Section 10), SPF based
rejection does present some risk of rejecting legitimate email when rejection does present some risk of rejecting legitimate email when
rejecting based on "MAIL FROM" results. rejecting based on "MAIL FROM" results.
skipping to change at page 71, line 5 skipping to change at page 71, line 5
might result in email that was not authorized by the sending ADMD might result in email that was not authorized by the sending ADMD
being unknowingly delivered to end users. being unknowingly delivered to end users.
Either general approach can be used as they both leave a clear Either general approach can be used as they both leave a clear
disposition of emails. They are either delivered in some manner or disposition of emails. They are either delivered in some manner or
the sender is notified of the failure. Other dispositions such as the sender is notified of the failure. Other dispositions such as
"dropping" or deleting email after acceptance are inappropriate "dropping" or deleting email after acceptance are inappropriate
because they leave uncertainty and reduce the overall reliability and because they leave uncertainty and reduce the overall reliability and
utility of email across the Internet. utility of email across the Internet.
H.3. Policy For SPF Permerror G.3. Policy For SPF Permerror
The "permerror" result (see Section 2.6.7) indicates the SPF The "permerror" result (see Section 2.6.7) indicates the SPF
processing module at the receiver determined that the retrieved SPF processing module at the receiver determined that the retrieved SPF
policy record could not be interpreted. This gives no true policy record could not be interpreted. This gives no true
indication about the authorized use of the data found in the indication about the authorized use of the data found in the
envelope. envelope.
As with all results, implementers have a choice to make regarding As with all results, implementers have a choice to make regarding
what to do with a message that yields this result. SMTP allows only what to do with a message that yields this result. SMTP allows only
a few basic options. a few basic options.
skipping to change at page 71, line 41 skipping to change at page 71, line 41
There is of course the option placing this choice in the hands of the There is of course the option placing this choice in the hands of the
SPF verifier operator rather than the implementer since this kind of SPF verifier operator rather than the implementer since this kind of
choice is often a matter of local policy rather than a condition with choice is often a matter of local policy rather than a condition with
a universal solution, but this adds one more piece of complexity to a universal solution, but this adds one more piece of complexity to
an already non-trivial environment. an already non-trivial environment.
Both implementers and SPF verfier operators need to be cautious of Both implementers and SPF verfier operators need to be cautious of
all choices and outcomes when handling SPF results. all choices and outcomes when handling SPF results.
H.4. Policy For SPF Temperror G.4. Policy For SPF Temperror
The "temperror" result (see Section 2.6.6) indicates the SPF The "temperror" result (see Section 2.6.6) indicates the SPF
processing module at the receiver could not retrieve and SPF policy processing module at the receiver could not retrieve and SPF policy
record due to a (probably) transient condition. This gives no true record due to a (probably) transient condition. This gives no true
indication about the authorized use of the data found in the indication about the authorized use of the data found in the
envelope. envelope.
As with all results, implementers have a choice to make regarding As with all results, implementers have a choice to make regarding
what to do with a message that yields this result. SMTP allows only what to do with a message that yields this result. SMTP allows only
a few basic options. a few basic options.
skipping to change at page 73, line 5 skipping to change at page 73, line 5
There is of course the option placing this choice in the hands of the There is of course the option placing this choice in the hands of the
SPF verifier operator rather than the implementer since this kind of SPF verifier operator rather than the implementer since this kind of
choice is often a matter of local policy rather than a condition with choice is often a matter of local policy rather than a condition with
a universal solution, but this adds one more piece of complexity to a universal solution, but this adds one more piece of complexity to
an already non-trivial environment. an already non-trivial environment.
Both implementers and SPF verifier operators need to be cautious of Both implementers and SPF verifier operators need to be cautious of
all choices and outcomes when handling SPF results. all choices and outcomes when handling SPF results.
Appendix I. Protocol Status Appendix H. Protocol Status
NOTE TO RFC EDITOR: To be removed prior to publication. NOTE TO RFC EDITOR: To be removed prior to publication.
SPF has been in development since the summer of 2003 and has seen SPF has been in development since the summer of 2003 and has seen
deployment beyond the developers beginning in December 2003. The deployment beyond the developers beginning in December 2003. The
design of SPF slowly evolved until the spring of 2004 and has since design of SPF slowly evolved until the spring of 2004 and has since
stabilized. There have been quite a number of forms of SPF, some stabilized. There have been quite a number of forms of SPF, some
written up as documents, some submitted as Internet Drafts, and many written up as documents, some submitted as Internet Drafts, and many
discussed and debated in development forums. The protocol was discussed and debated in development forums. The protocol was
originally defined in [RFC4408], which this document replaces. originally defined in [RFC4408], which this document replaces.
skipping to change at page 74, line 5 skipping to change at page 74, line 5
SPF is widely deployed by large and small email providers alike. SPF is widely deployed by large and small email providers alike.
There are multiple, interoperable implementations. There are multiple, interoperable implementations.
For SPF (as documented in RFC 4408) a careful effort was made to For SPF (as documented in RFC 4408) a careful effort was made to
collect and document lessons learned and errata during the two year collect and document lessons learned and errata during the two year
period. The errata list has been stable (no new submissions) and period. The errata list has been stable (no new submissions) and
only minor protocol lessons learned were identified. Resolution of only minor protocol lessons learned were identified. Resolution of
the IESG's experiment is documented in [RFC6686]. the IESG's experiment is documented in [RFC6686].
Appendix J. Change History Appendix I. Change History
NOTE TO RFC EDITOR: Changes since RFC 4408 (to be removed prior to NOTE TO RFC EDITOR: Changes since RFC 4408 (to be removed prior to
publication) publication)
Moved to standards track Moved to standards track
Authors updated Authors updated
IESG Note regarding experimental use replaced with discussion of IESG Note regarding experimental use replaced with discussion of
results results
 End of changes. 38 change blocks. 
168 lines changed or deleted 169 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--nextPart2714318.S1THZF8FJm-- From spf2@kitterman.com Wed Sep 25 20:59: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 324DD11E8106 for ; Wed, 25 Sep 2013 20:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.381, 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 qaCQyGOtwt-2 for ; Wed, 25 Sep 2013 20:58:55 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 14A3F21F98AC for ; Wed, 25 Sep 2013 20:58:55 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8669A20E40D3; Wed, 25 Sep 2013 23:58:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1380167934; bh=7+4BJGELtNvFY2xnAU3byG0VX+C+ynlzQX6TsElsbzY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=m4h5FESAnG/cmmtefn/IBU1SZVIAz+D2VqmVkxYU6kqJiCI9X1Y3/Bj6pKUr7dWCA cQPwbToMqN/sVaE/DtE5AKNDdrs5HbPBOHslFJJTWF6ibfu3ZtPq21N67/KLt7jPX7 99E81KBVbSZKEd3/1204vIRB74gNphqG8CILjQB4= 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 6BEEA20E40C4; Wed, 25 Sep 2013 23:58:54 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 25 Sep 2013 23:58:53 -0400 Message-ID: <1758729.IvYqRXB7R5@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130914224708.0c8d4af0@elandnews.com> References: <5234DD79.4010407@sonnection.nl> <6.2.5.6.2.20130914224708.0c8d4af0@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] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 26 Sep 2013 03:59:00 -0000 On Saturday, September 14, 2013 23:21:35 S Moonesamy wrote: > Hi Rolf, > > At 15:04 14-09-2013, Rolf E. Sonneveld wrote: > >I intentionally did not refer to a specific paragraph within the > >referenced specs, as new versions of those referenced specs might > >invalidate the references in this spfbis document. Granted, chances > >that RFC5321 and/or RFC5598 will become obsoleted by newer versions > > >are small, so here's an attempt to address part of the raised issue: > Ok. > > >1.1.3. MAIL FROM Definition > > > > This document is concerned with the identity of the sender of a > > > > mail message, as referred to in par. 3.3 of [RFC5321]: > > "The transaction starts with a MAIL command that gives the > > sender identification." > > > >. Since there are many other names for this identity, it is > > > > important to choose a name that is: > > > > 1. commonly used > > 2. well defined > > > > As such, throughout this document the term "MAIL FROM" will be used, > > which is defined as the RFC5321.MailFrom identity, described in > > > > par. 4.1.4 of [RFC5598]. > > > >I'm not sure I agree with the SecDir review re. "the referenced > >specs do not give an explicit definition for the term as used > >[...]', as RFC5598 par. 4.1.4 describes the RFC5321.MailFrom > > > >identity quite well: > > RFC5321.MailFrom: Set by - Originator > > > > This field is an end-to-end string that specifies an email address > > for receiving return control information, such as returned > > messages. [...] > > I'll adapt your proposed text as follows: > > 1.1.3. MAIL FROM Definition > > This document uses "MAIL FROM" to refer to RFC5321.MailFrom > (reverse-path). The RFC5321.MailFrom is defined in Section 4.4 of RFC 5598 > as an end-to-end string that specifies an email address for receiving > return control information, such as returned messages. > > I inserted the word "reverse-path" because of Section 2.4. > > If you are okay with the above I'll use it to respond to the SecDir review. I added reverse-path to what I just published on 1.1.3. I'm not going to publish another diff just for that. Scott K From spf2@kitterman.com Wed Sep 25 21:02: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 CEDF311E80FA for ; Wed, 25 Sep 2013 21:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.362, 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 6D4AbrL81n6M for ; Wed, 25 Sep 2013 21:02:44 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 91F8721F941F for ; Wed, 25 Sep 2013 21:02:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 28B3920E40D3; Thu, 26 Sep 2013 00:02:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1380168164; bh=os5UszdhocjvfeCYwY3NU8LZ0IhfHDzDloMxWnE09To=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bNAhmkqWtZylmsQ5XFH0my73o50G+qSm7OGvPeHEj5hzO3iz10cte5vrufJuhPfRm wxxj7Qq/980Owg/rW9e3GJJENJg/BZnt8Uqrro+DEMq2lsa5jUIJNYWlvKXl/hEfE/ o2YVAu9Cuj58xCrt3Bf/k+5eTcpZnCc928LsvAiw= 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 0E67520E40C4; Thu, 26 Sep 2013 00:02:43 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 26 Sep 2013 00:02:43 -0400 Message-ID: <3847270.QmjG8bX0Jj@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20130917010720.06302bf8@elandnews.com> References: <6.2.5.6.2.20130917010720.06302bf8@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] SECDIR Review of draft-ietf-spfbis-4408bis-19 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, 26 Sep 2013 04:02:49 -0000 On Tuesday, September 17, 2013 01:19:44 S Moonesamy wrote: > Hi Phillip, > > At 05:07 11-09-2013, Phillip Hallam-Baker wrote: > >Minor issues. > > > >1.1.3. MAIL FROM Definition > > > >I found this section completely opaque and very confusing. It should > >not be necessary to hunt through other specs to find a definition. > >Particularly since the referenced specs do not give an explicit > >definition for the term as used and the references point to the > >whole spec rather than a particular section. > > The text below is to address the comment about Section 1.1.3 (credits > to Rolf E. Sonneveld): > > 1.1.3. MAIL FROM Definition > > This document uses "MAIL FROM" to refer to RFC5321.MailFrom > (reverse-path). The RFC5321.MailFrom is defined in Section 4.4 of RFC 5598 > as an end-to-end string that specifies an email address for receiving > return control information, such as returned messages. Incorporated as already mentioned. > >The Security Considerations section is adequate for the purpose > >except that no mention is made anywhere in the specification about > >DKIM and how a mail receiver should interpret presence of DKIM and > >SPF policy at the same time. This is a legitimate concern since DKIM > >is already a standards track proposal and SPF is only now being > >promoted to Standards Track. Thus the SPF document should address > >the question of dual use. > > I commented about the above in my previous reply. I don't think there's anything that's actionable within the charter on this. > >8.7. Permerror > >"This signals an error condition that definitely requires operator > >intervention to be resolved." > > > >I cannot imagine a circumstance which definitely requires a human to > >be involved in mail delivery. > > These are permanent DNS errors or SPF record errors. For example, if > an SPF record requires too many DNS lookups, someone has to change > the record to make the error go away. > > The definitely was intended to distinguish from cases such as a DNS > SERVFAIL that may or may not be permanent, but are temperrors in > SPF. In the case of ambiguity about if an error is temporary or > permanent, it's treated in the design as assumed to be temporary. I'm not making any changes for this. > >11.2. SPF-Authorized Email May Contain Other False Identities > > > > Do not construe the "MAIL FROM" and "HELO" identity authorizations to > > provide more assurance than they do. > > > >Document has quasi normative language that should be worded as > >statements of fact rather than as direction. > > The following change is proposed is response to the above: > > The "MAIL FROM" and "HELO" identity authorizations do not provide > assurance about the authorization/authenticity of other identities used in > the message. Incorporated locally. Scott K From spf2@kitterman.com Wed Sep 25 21:07: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 ED65511E8132 for ; Wed, 25 Sep 2013 21:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=0.346, 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 iJeKSx4d52q0 for ; Wed, 25 Sep 2013 21:07:51 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8647A11E80FA for ; Wed, 25 Sep 2013 21:07:51 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 142DB20E40D3; Thu, 26 Sep 2013 00:07:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1380168471; bh=a7ON+Nn7EUl4WEriGQQkS0uJwkcIB+etSqANTvGkbfU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LPc97TuzkrnxMfksJ5iQBREHfR2gFReCuMhXwyE/NkT8r+rF0Zzgl3km1whpWG/H5 v2HhyspYIK0fu75zl/GHMAAe8NFfSpU1QnbNS8bP/b1pByaFTJWwTa5fRC+HF2wB+m sR3PBJ8Rg/syBQjHGwTt/GzehlaMR7TBJKxLca4s= 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 EDCF020E40C4; Thu, 26 Sep 2013 00:07:50 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 26 Sep 2013 00:07:50 -0400 Message-ID: <1598361.7dTHHD5BrU@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <20130915213820.GC78902@mx1.yitter.info> References: <2137735.9LNiMWPY5V@scott-latitude-e6320> <20130915213820.GC78902@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] draft-ietf-spfbis-4408bis-20 review (response size) 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, 26 Sep 2013 04:07:57 -0000 On Sunday, September 15, 2013 17:38:20 Andrew Sullivan wrote: > On Sat, Sep 14, 2013 at 02:20:39AM -0400, Scott Kitterman wrote: > > NEW: > > TXT records is under 450 characters, then DNS answers should fit in UDP > > s/characters/octets, or even "ASCII characters" if you must. > "Characters" in the UTF-8 era is just too loaded a word. > > Otherwise, no objection here. It looks like I had fixed this already. It says octets. Scott K From spf2@kitterman.com Wed Sep 25 21:14: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 5810211E8135 for ; Wed, 25 Sep 2013 21:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=0.331, 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 VRJs9eoOmhg6 for ; Wed, 25 Sep 2013 21:14:22 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECCE21F995B for ; Wed, 25 Sep 2013 21:14:17 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 029A320E40D3; Thu, 26 Sep 2013 00:14:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1380168857; bh=BY6JG2MO2HFm0NtxiU7Lmq2Bq4X+ZaBAY1OPTdQlhmI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=K3ir/dfzhvnGsTjLIoFsOQ0Z090otgqAzqzl3NX0csNOUaJwU9PBYUV0mB4goyfjl DBGS7eBPXU5JE0mm63pzxGaj2hri/2IRkd6eaVKbh95nL5gh2fMjoTk4PiQQFfVEEx mzxJfEpgmQyXd03HeTCNlcam1SpTKHdvaKJ/orfc= 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 DC43120E40C4; Thu, 26 Sep 2013 00:14:16 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 26 Sep 2013 00:14:16 -0400 Message-ID: <4542820.U7qJIjvMcm@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <5231D25B.6040004@ieca.com> References: <20130912114310.25787.59356.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130912072207.0b998388@elandnews.com> <5231D25B.6040004@ieca.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] Sean Turner's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 26 Sep 2013 04:14:27 -0000 On Thursday, September 12, 2013 10:40:27 you wrote: > On 9/12/13 10:26 AM, S Moonesamy wrote: > > Hi Sean, > > > > At 04:43 12-09-2013, Sean Turner wrote: > >> Sean Turner has entered the following ballot position for > >> draft-ietf-spfbis-4408bis-19: No Objection > > > > [snip] > > > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> Should s11.3 also provide a mitigation via a reference for the spoofed > >> DNS? Right now it just points to the DNS threats RFC. I guess the > >> reader can infer they should use DNSSEC if they're worried but adding a > >> pointer to the right RFC would be better. Something as simple as adding > >> "... and see [RFCXYZ] for a countermeasure" or something like that. > > > > I'll suggest: > > and see RFC 4033 for a countermeasure. > > > > and leave it to the SPFBIS WG to comment on the above. > > That would work for me. > > spt I don't think this went to the WG list before, but I don't imagine it being controversial. Added as suggested. Scott K From spf2@kitterman.com Wed Sep 25 21:15: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 BD37511E8139 for ; Wed, 25 Sep 2013 21:15:50 -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 l0V4zHLREHhK for ; Wed, 25 Sep 2013 21:15:46 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 50BFD11E8106 for ; Wed, 25 Sep 2013 21:15:46 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DD2E820E40D3; Thu, 26 Sep 2013 00:15:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1380168945; bh=m/di3M6VahHrrecgBMn7e59R2GaccGPrGnHi2DcJjhE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=E13mhSg2Ys41EPZdpGCNRxOmxcsBWVYA8z/2QhaJkY91KORZq1gPegKsO1lLqUcNr o34D2BhLYL5+bvVxkf/J80uRNI9Fu+y5buuOErC/7O8x8JJ4HmIe4hUzUmH9jcPV6c WrVzczFkAE+qOFE3y78UMGpYSwAHe0mQfOhiNXP4= 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 C62E120E40C4; Thu, 26 Sep 2013 00:15:45 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 26 Sep 2013 00:15:45 -0400 Message-ID: <3693082.IWTNL7MlLQ@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <968D46D1-D7F1-4E23-9B59-1212AFA924B3@piuha.net> References: <968D46D1-D7F1-4E23-9B59-1212AFA924B3@piuha.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] [Gen-art] Gen-ART Telechat Call review of draft-ietf-spfbis-4408bis-19 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, 26 Sep 2013 04:15:50 -0000 On Thursday, September 12, 2013 22:19:56 you wrote: > Meral: Thank you for your review! > > Jari > > On Sep 5, 2013, at 5:40 AM, 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 wait for direction from your document shepherd or AD before posting > > a new version of the draft. > > > > Document: draft-ietf-spfbis-4408bis-19 > > Reviewer: Meral Shirazipour > > Review Date: 2013-09-04 > > IETF LC End Date: 2013-09-02 > > IESG Telechat date: 2013-09-12 > > > > Summary: This draft is ready to be published as Proposed Standard. > > > > > > Nits/editorial comments: > > Section E.3., Title, "Receving ADMDs" --typo--> "Receiving ADMDs" Fixed this. Scott K From spf2@kitterman.com Wed Sep 25 22:10: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 EE85D11E8135 for ; Wed, 25 Sep 2013 22:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] 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 Lc8Wauk8oMPo for ; Wed, 25 Sep 2013 22:10:04 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C0F5721F9E95 for ; Wed, 25 Sep 2013 22:10:03 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 50D3720E40D3; Thu, 26 Sep 2013 01:10:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1380172201; bh=codk5/F9ZV7nNi9bfTzZSeaIxm+BKL5Yt0H6xTAuT10=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mMghP2VUf+A+CCFh3QEsWT6X9cAQ+yZ8MSJogygYYv1nF7O+unnxQDsoazXKv9kHO /QT6ZWRNZ8atSCoN3urkJOYPVD39ERVvo/61SFa6lOI2WPoOTugKPfoM3/Cqv9jamV axDEuvl/4YqwH6i3xQQ1GA2vvqndb1xdNs+N5Qek= 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 0A96220E40C4; Thu, 26 Sep 2013 01:10:00 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 26 Sep 2013 01:09:59 -0400 Message-ID: <9521219.RXqIhQCEgb@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: References: <20130912101511.20829.6656.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130925131612.0d8d3800@elandnews.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart2796661.iiajMldlZ8" Content-Transfer-Encoding: 7Bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Stephen Farrell's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 26 Sep 2013 05:10:05 -0000 This is a multi-part message in MIME format. --nextPart2796661.iiajMldlZ8 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Wednesday, September 25, 2013 14:23:42 Murray S. Kucherawy wrote: > On Wed, Sep 25, 2013 at 1:30 PM, S Moonesamy wrote: > > Hello, > > > > I would like to bring the message below to the attention of the working > > group. There has not been any response to it. Can a SPFBIS WG > > participant > > please respond to the message? > > > > > > Thanks, > > S. Moonesamy (as document shepherd) > > > > At 03:15 12-09-2013, Stephen Farrell wrote: > >> Stephen Farrell has entered the following ballot position for > >> draft-ietf-spfbis-4408bis-19: No Objection > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut this > >> introductory paragraph, however.) > >> > >> > >> Please refer to http://www.ietf.org/iesg/**statement/discuss-criteria.** > >> html > >> for more information about IESG DISCUSS and COMMENT positions. > >> > >> > >> The document, along with other ballot positions, can be found here: > >> http://datatracker.ietf.org/**doc/draft-ietf-spfbis-4408bis/ >> racker.ietf.org/doc/draft-ietf-spfbis-4408bis/> > >> > >> > >> > >> ------------------------------**------------------------------** > >> ---------- > >> COMMENT: > >> ------------------------------**------------------------------** > >> ---------- > >> > >> > >> - 4.1: given that recursion is allowed and that you have > >> overall limits on how many DNS transactions can be done, > >> is the "transactions-remaining" value also an implicit > >> parameter of a check_host() call? This is only a comment > >> since check_host is not a formal API but it'd seem to make > >> it easier to get right if you make that implicit parameter > >> explicit. Or do the limits apply to each call as you > >> recurse? That wasn't entirely clear to me. > > I suggest that it would be sufficient to add some prose that says the > "transactions-remaining" count (or whatever we call it) has to apply > through the recursions. We shouldn't make this look any more like an API > definition than it already does. I agree that staying away from more API like language is good. I took a prose approach to describing this was a global limit and not a per-recursion limit. In the attached diff. > > - I didn't get appendix D at all - what's that do? > > > I agree, we should explain it and include an example, or drop it. Someone > closer to the implementation and the original material than I am is almost > certainly able to come up with an appropriate example versus what I would > invent. It made sense in context before we reorganized the document. I find it troubling that the author of the reorganization now doesn't understand part of the text he shuffled around. I'll take a stab at adding something. > >> - Appendix E.1, 2nd bullet: what's that? I think it needs > >> a reference if you want it to be understood. > > Same here; examples would probably be useful for all three sections. Generically, I agree, but it's beyond me to right it tonight. I think the information is all there to get someone started with concepts of how senders can deal with avoiding SPF problems related to forwarding. These are all unchanged from RFC 4408. I don't think we should be changing them now after all the reviews as it wouldn't be a small change to rework these sections as you suggest. Full diff from -20 attached. Scott K --nextPart2796661.iiajMldlZ8 Content-Disposition: attachment; filename="draft-ietf-spfbis-4408bis-21-from-0.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="draft-ietf-spfbis-4408bis-21-from-0.diff.html" Diff: draft-ietf-spfbis-4408bis-20.txt - draft-ietf-spfbis-4408bis-21.txt
 draft-ietf-spfbis-4408bis-20.txt   draft-ietf-spfbis-4408bis-21.txt 
Network Working Group S. Kitterman Network Working Group S. Kitterman
Internet-Draft Kitterman Technical Services Internet-Draft Kitterman Technical Services
Obsoletes: 4408 (if approved) September 12, 2013 Obsoletes: 4408 (if approved) September 26, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: March 16, 2014 Expires: March 30, 2014
Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email,
Version 1 Version 1
draft-ietf-spfbis-4408bis-20 draft-ietf-spfbis-4408bis-21
Abstract Abstract
Email on the Internet can be forged in a number of ways. In Email on the Internet can be forged in a number of ways. In
particular, existing protocols place no restriction on what a sending 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 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 SMTP HELO/EHLO commands. This document describes version 1 of
the Sender Policy Framework (SPF) protocol, whereby ADministrative the Sender Policy Framework (SPF) protocol, whereby ADministrative
Management Domains (ADMDs) can explicitly authorize the hosts that Management Domains (ADMDs) can explicitly authorize the hosts that
are allowed to use its domain names, and a receiving host can check are allowed to use its domain names, and a receiving host can check
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 16, 2014. This Internet-Draft will expire on March 30, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 20 skipping to change at page 3, line 20
1.1.2. Imported Definitions . . . . . . . . . . . . . . . . . 6 1.1.2. Imported Definitions . . . . . . . . . . . . . . . . . 6
1.1.3. MAIL FROM Definition . . . . . . . . . . . . . . . . . 7 1.1.3. MAIL FROM Definition . . . . . . . . . . . . . . . . . 7
1.1.4. HELO Definition . . . . . . . . . . . . . . . . . . . 7 1.1.4. HELO Definition . . . . . . . . . . . . . . . . . . . 7
1.2. check_host() . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. check_host() . . . . . . . . . . . . . . . . . . . . . . . 7
2. Operational Overview . . . . . . . . . . . . . . . . . . . . . 8 2. Operational Overview . . . . . . . . . . . . . . . . . . . . . 8
2.1. Publishing Authorization . . . . . . . . . . . . . . . . . 8 2.1. Publishing Authorization . . . . . . . . . . . . . . . . . 8
2.2. Checking Authorization . . . . . . . . . . . . . . . . . . 8 2.2. Checking Authorization . . . . . . . . . . . . . . . . . . 8
2.3. The "HELO" Identity . . . . . . . . . . . . . . . . . . . 9 2.3. The "HELO" Identity . . . . . . . . . . . . . . . . . . . 9
2.4. The "MAIL FROM" Identity . . . . . . . . . . . . . . . . . 10 2.4. The "MAIL FROM" Identity . . . . . . . . . . . . . . . . . 10
2.5. Location of Checks . . . . . . . . . . . . . . . . . . . . 10 2.5. Location of Checks . . . . . . . . . . . . . . . . . . . . 10
2.6. Results of Evaluation . . . . . . . . . . . . . . . . . . 10 2.6. Results of Evaluation . . . . . . . . . . . . . . . . . . 11
2.6.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.6. Temperror . . . . . . . . . . . . . . . . . . . . . . 11 2.6.6. Temperror . . . . . . . . . . . . . . . . . . . . . . 11
2.6.7. Permerror . . . . . . . . . . . . . . . . . . . . . . 11 2.6.7. Permerror . . . . . . . . . . . . . . . . . . . . . . 12
3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. DNS Resource Records . . . . . . . . . . . . . . . . . . . 12 3.1. DNS Resource Records . . . . . . . . . . . . . . . . . . . 13
3.2. Multiple DNS Records . . . . . . . . . . . . . . . . . . . 13 3.2. Multiple DNS Records . . . . . . . . . . . . . . . . . . . 14
3.3. Multiple Strings in a Single DNS record . . . . . . . . . 13 3.3. Multiple Strings in a Single DNS record . . . . . . . . . 14
3.4. Record Size . . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Record Size . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Wildcard Records . . . . . . . . . . . . . . . . . . . . . 14 3.5. Wildcard Records . . . . . . . . . . . . . . . . . . . . . 15
4. The check_host() Function . . . . . . . . . . . . . . . . . . 16 4. The check_host() Function . . . . . . . . . . . . . . . . . . 17
4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 17 4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 18
4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 17 4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 18
4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 17 4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 18
4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 17 4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 19
4.6.1. Term Evaluation . . . . . . . . . . . . . . . . . . . 18 4.6.1. Term Evaluation . . . . . . . . . . . . . . . . . . . 19
4.6.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 18 4.6.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 19
4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 19 4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 20
4.6.4. DNS Lookup Limits . . . . . . . . . . . . . . . . . . 19 4.6.4. DNS Lookup Limits . . . . . . . . . . . . . . . . . . 20
4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 20 4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 21
4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 20 4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 22
5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 22 5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 23
5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.5. "ptr" (do not use) . . . . . . . . . . . . . . . . . . . . 25 5.5. "ptr" (do not use) . . . . . . . . . . . . . . . . . . . . 26
5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 27 5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 28
5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 28
6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 29 6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 30
6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 29 6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 30
6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 30 6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 31
7. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Formal Specification . . . . . . . . . . . . . . . . . . . 32 7.1. Formal Specification . . . . . . . . . . . . . . . . . . . 33
7.2. Macro Definitions . . . . . . . . . . . . . . . . . . . . 32 7.2. Macro Definitions . . . . . . . . . . . . . . . . . . . . 33
7.3. Macro Processing Details . . . . . . . . . . . . . . . . . 33 7.3. Macro Processing Details . . . . . . . . . . . . . . . . . 34
7.4. Expansion Examples . . . . . . . . . . . . . . . . . . . . 35 7.4. Expansion Examples . . . . . . . . . . . . . . . . . . . . 36
8. Result Handling . . . . . . . . . . . . . . . . . . . . . . . 37 8. Result Handling . . . . . . . . . . . . . . . . . . . . . . . 38
8.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.6. Temperror . . . . . . . . . . . . . . . . . . . . . . . . 39 8.6. Temperror . . . . . . . . . . . . . . . . . . . . . . . . 40
8.7. Permerror . . . . . . . . . . . . . . . . . . . . . . . . 39 8.7. Permerror . . . . . . . . . . . . . . . . . . . . . . . . 40
9. Recording the Result . . . . . . . . . . . . . . . . . . . . . 40 9. Recording the Result . . . . . . . . . . . . . . . . . . . . . 41
9.1. The Received-SPF Header Field . . . . . . . . . . . . . . 40 9.1. The Received-SPF Header Field . . . . . . . . . . . . . . 41
9.2. SPF Results in the Authentication-Results Header Field . . 42 9.2. SPF Results in the Authentication-Results Header Field . . 43
10. Effects on Infrastructure . . . . . . . . . . . . . . . . . . 44 10. Effects on Infrastructure . . . . . . . . . . . . . . . . . . 45
10.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 44 10.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 45
10.1.1. DNS Resource Considerations . . . . . . . . . . . . . 44 10.1.1. DNS Resource Considerations . . . . . . . . . . . . . 45
10.1.2. Administrator's Considerations . . . . . . . . . . . . 45 10.1.2. Administrator's Considerations . . . . . . . . . . . . 46
10.1.3. Bounces . . . . . . . . . . . . . . . . . . . . . . . 46 10.1.3. Bounces . . . . . . . . . . . . . . . . . . . . . . . 47
10.2. Receivers . . . . . . . . . . . . . . . . . . . . . . . . 46 10.2. Receivers . . . . . . . . . . . . . . . . . . . . . . . . 47
10.3. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 46 10.3. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 47
11. Security Considerations . . . . . . . . . . . . . . . . . . . 48 11. Security Considerations . . . . . . . . . . . . . . . . . . . 49
11.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 48 11.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 49
11.2. SPF-Authorized Email May Contain Other False Identities . 49 11.2. SPF-Authorized Email May Contain Other False Identities . 50
11.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 49 11.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 50
11.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 49 11.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 50
11.5. Untrusted Information Sources . . . . . . . . . . . . . . 50 11.5. Untrusted Information Sources . . . . . . . . . . . . . . 51
11.5.1. Recorded Results . . . . . . . . . . . . . . . . . . . 50 11.5.1. Recorded Results . . . . . . . . . . . . . . . . . . . 51
11.5.2. External Explanations . . . . . . . . . . . . . . . . 50 11.5.2. External Explanations . . . . . . . . . . . . . . . . 51
11.5.3. Macro Expansion . . . . . . . . . . . . . . . . . . . 51 11.5.3. Macro Expansion . . . . . . . . . . . . . . . . . . . 52
11.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 51 11.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 52
11.7. Delivering Mail Producing a 'Fail' Result . . . . . . . . 51 11.7. Delivering Mail Producing a 'Fail' Result . . . . . . . . 52
12. Contributors and Acknowledgements . . . . . . . . . . . . . . 52 12. Collected ABNF . . . . . . . . . . . . . . . . . . . . . . . . 53
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 13. Contributors and Acknowledgements . . . . . . . . . . . . . . 56
13.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 53 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
13.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 53 14.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 57
13.3. SPF Modifier Registry . . . . . . . . . . . . . . . . . . 53 14.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 57
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 14.3. SPF Modifier Registry . . . . . . . . . . . . . . . . . . 57
14.1. Normative References . . . . . . . . . . . . . . . . . . . 54 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
14.2. Informative References . . . . . . . . . . . . . . . . . . 55 15.1. Normative References . . . . . . . . . . . . . . . . . . . 58
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 57 15.2. Informative References . . . . . . . . . . . . . . . . . . 59
Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 60
B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 60 Appendix A. Extended Examples . . . . . . . . . . . . . . . . . . 61
B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 61 A.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 61
B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 62 A.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 62
B.4. Multiple Requirements Example . . . . . . . . . . . . . . 62 A.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 63
Appendix C. Changes in implementation requirements from RFC A.4. Multiple Requirements Example . . . . . . . . . . . . . . 63
4408 . . . . . . . . . . . . . . . . . . . . . . . . 63 Appendix B. Changes in implementation requirements from RFC
Appendix D. Further Testing Advice . . . . . . . . . . . . . . . 64 4408 . . . . . . . . . . . . . . . . . . . . . . . . 64
Appendix E. SPF/Mediator Interactions . . . . . . . . . . . . . . 65 Appendix C. Further Testing Advice . . . . . . . . . . . . . . . 65
E.1. Originating ADMDs . . . . . . . . . . . . . . . . . . . . 65 Appendix D. SPF/Mediator Interactions . . . . . . . . . . . . . . 66
E.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 66 D.1. Originating ADMDs . . . . . . . . . . . . . . . . . . . . 66
E.3. Receving ADMDs . . . . . . . . . . . . . . . . . . . . . . 66 D.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 67
Appendix F. Mail Services . . . . . . . . . . . . . . . . . . . . 67 D.3. Receiving ADMDs . . . . . . . . . . . . . . . . . . . . . 67
Appendix G. MTA Relays . . . . . . . . . . . . . . . . . . . . . 68 Appendix E. Mail Services . . . . . . . . . . . . . . . . . . . . 68
Appendix H. Local Policy Considerations . . . . . . . . . . . . . 69 Appendix F. MTA Relays . . . . . . . . . . . . . . . . . . . . . 69
H.1. Policy For SPF Pass . . . . . . . . . . . . . . . . . . . 69 Appendix G. Local Policy Considerations . . . . . . . . . . . . . 70
H.2. Policy For SPF Fail . . . . . . . . . . . . . . . . . . . 69 G.1. Policy For SPF Pass . . . . . . . . . . . . . . . . . . . 70
H.3. Policy For SPF Permerror . . . . . . . . . . . . . . . . . 70 G.2. Policy For SPF Fail . . . . . . . . . . . . . . . . . . . 70
H.4. Policy For SPF Temperror . . . . . . . . . . . . . . . . . 70 G.3. Policy For SPF Permerror . . . . . . . . . . . . . . . . . 71
Appendix I. Protocol Status . . . . . . . . . . . . . . . . . . . 72 G.4. Policy For SPF Temperror . . . . . . . . . . . . . . . . . 71
Appendix J. Change History . . . . . . . . . . . . . . . . . . . 73 Appendix H. Protocol Status . . . . . . . . . . . . . . . . . . . 73
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 76 Appendix I. Change History . . . . . . . . . . . . . . . . . . . 74
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 77
1. Introduction 1. Introduction
The current email infrastructure has the property that any host The current email infrastructure has the property that any host
injecting mail into the system can use any DNS domain name it wants injecting mail into the system can use any DNS domain name it wants
in each of the various identifiers specified by [RFC5321] and in each of the various identifiers specified by [RFC5321] and
[RFC5322]. Although this feature is desirable in some circumstances, [RFC5322]. Although this feature is desirable in some circumstances,
it is a major obstacle to reducing Unsolicited Bulk Email (UBE, aka it is a major obstacle to reducing Unsolicited Bulk Email (UBE, aka
spam). Furthermore, many domain owning ADMDs (as described in spam). Furthermore, many domain owning ADMDs (as described in
[RFC5598]) are understandably concerned about the ease with which [RFC5598]) are understandably concerned about the ease with which
skipping to change at page 7, line 8 skipping to change at page 7, line 8
The tokens "Local-part", "Domain", and "Mailbox are defined in The tokens "Local-part", "Domain", and "Mailbox are defined in
[RFC5321]. [RFC5321].
"dot-atom", "quoted-string", "comment", "CFWS" (comment folded white "dot-atom", "quoted-string", "comment", "CFWS" (comment folded white
space), "FWS" (folded white space), and "CRLF" (carriage-return/ space), "FWS" (folded white space), and "CRLF" (carriage-return/
line-feed) are defined in [RFC5322]. line-feed) are defined in [RFC5322].
1.1.3. MAIL FROM Definition 1.1.3. MAIL FROM Definition
This document is concerned with the portion of a mail message This document is concerned with the identity of the sender of a mail
commonly called "envelope sender", "return path", "reverse path", message, as referred to in [RFC5321]:
"bounce address", "5321 FROM", "MAIL FROM", or RFC5321.MailFrom.
Since these terms are either not well defined or often used casually, "The transaction starts with a MAIL command that gives the sender
this document uses "MAIL FROM" for consistency. This means the identification."
RFC5321.MailFrom as defined in [RFC5598]. Note that other terms that
might superficially look like the common terms, such as 'reverse- Since there are many other names for this identity, it is important
path', are used only as they are specified in their defining to choose a name that is:
documents.
1. commonly used
2. well defined
As such, throughout this document the term "MAIL FROM" will be used,
which is defined as the RFC5321.MailFrom (reverse-path) identity
described in [RFC5598].
1.1.4. HELO Definition 1.1.4. HELO Definition
This document also makes use of the HELO/EHLO identity. The "HELO" This document also makes use of the HELO/EHLO identity. The "HELO"
identity derives from either the SMTP HELO or EHLO command (see identity derives from either the SMTP HELO or EHLO command (see
[RFC5321]). Since HELO and EHLO can, in many cases, be used [RFC5321]). Since HELO and EHLO can, in many cases, be used
interchangeably, they are identified commonly as "HELO" in this interchangeably, they are identified commonly as "HELO" in this
document. This means RFC5321.HELO/.EHLO as defined in [RFC5598]. document. This means RFC5321.HELO/.EHLO as defined in [RFC5598].
These commands supply the identity of the SMTP client (sending host) These commands supply the identity of the SMTP client (sending host)
for the SMTP session. for the SMTP session.
skipping to change at page 10, line 34 skipping to change at page 10, line 34
2.5. Location of Checks 2.5. Location of Checks
The authorization check SHOULD be performed during the processing of The authorization check SHOULD be performed during the processing of
the SMTP transaction that receives the mail. This reduces the the SMTP transaction that receives the mail. This reduces the
complexity of determining the correct IP address to use as an input complexity of determining the correct IP address to use as an input
to check_host() and allows errors to be returned directly to the to check_host() and allows errors to be returned directly to the
sending MTA by way of SMTP replies. Appendix C of [RFC5451] provides sending MTA by way of SMTP replies. Appendix C of [RFC5451] provides
a more thorough discussion of this topic. a more thorough discussion of this topic.
Performing the authorization check other than using the MAIL FROM and The authorization check is performed during the SMTP transaction at
client address at the time of the MAIL command during the SMTP the time of the MAIL command, and uses the MAIL FROM value and the
transaction can cause problems, such as the following: (1) It might client IP address. Performing the check at later times or with other
be difficult to accurately extract the required information from input can cause problems such as the following:
potentially deceptive headers; (2) legitimate email might fail
because the sender's policy had since changed. o It might be difficult to accurately extract the required
information from potentially deceptive headers.
o Legitimate email might fail the authorization check because the
sender's policy has since changed.
Generating non-delivery notifications to forged identities that have Generating non-delivery notifications to forged identities that have
failed the authorization check often constitutes backscatter, i.e., failed the authorization check often constitutes backscatter, i.e.,
inactionable, nuisance rejection notices. Operators are strongly inactionable, nuisance rejection notices. Operators are strongly
advised to avoid such practices. Section 2 of [RFC3834] describes advised to avoid such practices. Section 2 of [RFC3834] describes
backscatter and the problems it causes. backscatter and the problems it causes.
2.6. Results of Evaluation 2.6. Results of Evaluation
Section 4 defines check_host(), a model function definition that uses Section 4 defines check_host(), a model function definition that uses
skipping to change at page 11, line 22 skipping to change at page 11, line 28
2.6.1. None 2.6.1. None
A result of "none" means either (a) no syntactically valid DNS domain 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 name was extracted from the SMTP session that could be used as the
one to be authorized, or (b) no SPF records were retrieved from the one to be authorized, or (b) no SPF records were retrieved from the
DNS. DNS.
2.6.2. Neutral 2.6.2. Neutral
The ADMD has explicitly stated that it is not asserting whether the A "neutral" result means that the ADMD has explicitly stated that it
IP address is authorized. is not asserting whether the IP address is authorized.
2.6.3. Pass 2.6.3. Pass
A "pass" result means that the client is authorized to inject mail A "pass" result is an explicit statement that the client is
with the given identity. authorized to inject mail with the given identity.
2.6.4. Fail 2.6.4. Fail
A "fail" result is an explicit statement that the client is not A "fail" result is an explicit statement that the client is not
authorized to use the domain in the given identity. authorized to use the domain in the given identity.
2.6.5. Softfail 2.6.5. Softfail
The ADMD has published a weak statement that the host is probably not A "softfail" result is a weak statement by the publishing ADMD that
authorized. It has not published a stronger, more definitive policy the host is probably not authorized. It has not published a
that results in a "fail". stronger, more definitive policy that results in a "fail".
2.6.6. Temperror 2.6.6. Temperror
A "temperror" result means the SPF verifier encountered a transient A "temperror" result means the SPF verifier encountered a transient
(generally DNS) error while performing the check. A later retry may (generally DNS) error while performing the check. A later retry may
succeed without further DNS operator action. succeed without further DNS operator action.
2.6.7. Permerror 2.6.7. Permerror
A "permerror" result means the domain's published records could not A "permerror" result means the domain's published records could not
skipping to change at page 12, line 25 skipping to change at page 13, line 25
not permitted for the same owner name. The record format and the not permitted for the same owner name. The record format and the
process for selecting records is described below in Section 4. An process for selecting records is described below in Section 4. An
example record is the following: example record is the following:
v=spf1 +mx a:colo.example.com/28 -all v=spf1 +mx a:colo.example.com/28 -all
This record has a version of "spf1" and three directives: "+mx", This record has a version of "spf1" and three directives: "+mx",
"a:colo.example.com/28" (the + is implied), and "-all". "a:colo.example.com/28" (the + is implied), and "-all".
Each SPF record is placed in the DNS tree at the owner name it Each SPF record is placed in the DNS tree at the owner name it
pertains to, not a subdomain under it, such as is done with SRV pertains to, not in a subdomain under the owner name. This is
records [RFC2782]. similar to how SRV records [RFC2782] are done.
The example in this section might be published via these lines in a The example in this section might be published via these lines in a
domain zone file: domain zone file:
example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"
Since TXT records have multiple uses, beware of other TXT records Since TXT records have multiple uses, beware of other TXT records
published there for other purposes. They might cause problems with published there for other purposes. They might cause problems with
size limits (see Section 3.4) and care has to be taken to ensure only size limits (see Section 3.4) and care has to be taken to ensure only
SPF records are used for SPF processing. SPF records are used for SPF processing.
skipping to change at page 13, line 13 skipping to change at page 14, line 13
they are now. Additionally, support for easy deployment of new DNS they are now. Additionally, support for easy deployment of new DNS
RR types was not widely deployed in DNS servers and provisioning RR types was not widely deployed in DNS servers and provisioning
systems. As a result, developers of SPF found it easier and more systems. As a result, developers of SPF found it easier and more
practical to use the TXT RR type for SPF records. practical to use the TXT RR type for SPF records.
In its review of [RFC4408] the SPFbis working group concluded that In its review of [RFC4408] the SPFbis working group concluded that
its dual RR type transition model was fundamentally flawed since it its dual RR type transition model was fundamentally flawed since it
contained no common RR type that implementers were required to serve contained no common RR type that implementers were required to serve
and required to check. Many alternatives were considered to resolve and required to check. Many alternatives were considered to resolve
this issue, but ultimately the working group concluded that this issue, but ultimately the working group concluded that
significant migration to the SPF RR type in the foreseeable future was significant migration to the SPF RR type in the forseeable future was
very unlikely and that the best solution for resolving this very unlikely and that the best solution for resolving this
interoperability issue was to drop support for the SPF RR type from interoperability issue was to drop support for the SPF RR type from
SPF version 1. See Appendix A of [RFC6686] for further information. SPF version 1. See Appendix A of [RFC6686] for further information.
The circumstances surrounding SPF's initial deployment a decade ago The circumstances surrounding SPF's initial deployment a decade ago
are unique. If a future update to SPF were developed that did not are unique. If a future update to SPF were developed that did not
reuse existing SPF records, it could use the SPF RR type. SPF's use reuse existing SPF records, it could use the SPF RR type. SPF's use
of the TXT RR type for structured data should in no way be taken as of the TXT RR type for structured data should in no way be taken as
precedent for future protocol designers. Further discussion of precedent for future protocol designers. Further discussion of
design considerations when using new DNS RR types can be found in design considerations when using new DNS RR types can be found in
skipping to change at page 16, line 7 skipping to change at page 17, line 7
*.A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM *.A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
*.A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all" *.A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"
SPF records have to be listed twice for every name within the zone: SPF records have to be listed twice for every name within the zone:
once for the name, and once with a wildcard to cover the tree under once for the name, and once with a wildcard to cover the tree under
the name, in order to cover all domains in use in outgoing mail. the name, in order to cover all domains in use in outgoing mail.
4. The check_host() Function 4. The check_host() Function
This description is not an API (Application Program Interface) This description is not an application programming interface
definition, but rather a function description used to illustrate the definition, but rather a function description used to illustrate the
algorithm. A compliant SPF implementation MUST produce results algorithm. A compliant SPF implementation MUST produce results
semantically equivalent to this description. semantically equivalent to this description.
The check_host() function fetches SPF records, parses them, and The check_host() function fetches SPF records, parses them, and
evaluates them to determine whether a particular host is or is not evaluates them to determine whether a particular host is or is not
permitted to send mail with a given identity. Receiving ADMDs that permitted to send mail with a given identity. Receiving ADMDs that
perform this check MUST correctly evaluate the check_host() function perform this check MUST correctly evaluate the check_host() function
as described here. as described here.
skipping to change at page 16, line 38 skipping to change at page 17, line 38
<domain> - the domain that provides the sought-after authorization <domain> - the domain that provides the sought-after authorization
information; initially, the domain portion of the "MAIL information; initially, the domain portion of the "MAIL
FROM" or "HELO" identity. FROM" or "HELO" identity.
<sender> - the "MAIL FROM" or "HELO" identity. <sender> - the "MAIL FROM" or "HELO" identity.
For recursive evaluations, the domain portion of <sender> might not For recursive evaluations, the domain portion of <sender> might not
be the same as the <domain> argument when check_host() is initially be the same as the <domain> argument when check_host() is initially
evaluated. In most other cases it will be the same. (See evaluated. In most other cases it will be the same. (See
Section 5.2 below). Section 5.2 below). The overall DNS lookup limit for SPF terms
described below in Section 4.6.4 must be tracked as a single global
limit for all evaluations, not just for a single instance of a
recursive evaluation.
Note that the <domain> argument might not be a well-formed domain Note that the <domain> argument might not be a well-formed domain
name. For example, if the reverse-path was null, then the EHLO/HELO name. For example, if the reverse-path was null, then the EHLO/HELO
domain is used, with its associated problems (see Section 2.3). In domain is used, with its associated problems (see Section 2.3). In
these cases, check_host() is defined in Section 4.3 to return a these cases, check_host() is defined in Section 4.3 to return a
"none" result. "none" result.
4.2. Results 4.2. Results
The function check_host() can return one of several results described The function check_host() can return one of several results described
skipping to change at page 19, line 34 skipping to change at page 20, line 40
4.6.4. DNS Lookup Limits 4.6.4. DNS Lookup Limits
Some mechanisms and modifiers (collectively, "terms") cause DNS Some mechanisms and modifiers (collectively, "terms") cause DNS
queries at the time of evaluation, and some do not. The following queries at the time of evaluation, and some do not. The following
terms cause DNS queries: the "include", "a", "mx", "ptr", and terms cause DNS queries: the "include", "a", "mx", "ptr", and
"exists" mechanisms and the "redirect" modifier. SPF implementations "exists" mechanisms and the "redirect" modifier. SPF implementations
MUST limit the total number of those terms to 10 during SPF MUST limit the total number of those terms to 10 during SPF
evaluation, to avoid unreasonable load on the DNS. If this limit is evaluation, to avoid unreasonable load on the DNS. If this limit is
exceeded, the implementation MUST return "permerror". The other exceeded, the implementation MUST return "permerror". The other
terms: the "all", "ip4", and "ip6" mechanisms do not cause DNS terms: the "all", "ip4", and "ip6" mechanisms and the "exp" modifier
queries at the time of SPF evaluation (the "exp" modifier causes a do not cause DNS queries at the time of SPF evaluation (the "exp"
lookup at a later time), and their use, including "exp", is not modifier only causes a lookup at a later time), and their use is not
subject to this limit. subject to this limit.
When evaluating the "mx" mechanism, the number of "MX" resource When evaluating the "mx" mechanism, the number of "MX" resource
records queried is included in the overall limit of 10 mechanisms/ records queried is included in the overall limit of 10 mechanisms/
modifiers that cause DNS lookups described above. The evaluation of modifiers that cause DNS lookups described above. In addition to
each "MX" record MUST NOT result in querying more than 10 address that limit, the evaluation of each "MX" record MUST NOT result in
records, either "A" or "AAAA" resource records. If this limit is querying more than 10 address records, either "A" or "AAAA" resource
exceeded, the "mx" mechanism MUST produce a "permerror" result. records. If this limit is exceeded, the "mx" mechanism MUST produce
a "permerror" result.
When evaluating the "ptr" mechanism or the %{p} macro, the number of When evaluating the "ptr" mechanism or the %{p} macro, the number of
"PTR" resource records queried is included in the overall limit of 10 "PTR" resource records queried is included in the overall limit of 10
mechanisms/modifiers that cause DNS lookups described above. The mechanisms/modifiers that cause DNS lookups described above. In
evaluation of each "PTR" record MUST NOT result in querying more than addition to that limit, the evaluation of each "PTR" record MUST NOT
10 address records, either "A" or "AAAA" resource records. If this result in querying more than 10 address records, either "A" or "AAAA"
limit is exceeded, all records other than the first 10 MUST be resource records. If this limit is exceeded, all records other than
ignored. the first 10 MUST be ignored.
The reason for the disparity is that the set of and contents of the The reason for the disparity is that the set of and contents of the
MX record are under control of the publishing ADMD, while the set of MX record are under control of the publishing ADMD, while the set of
and contents of PTR records are under control of the owner of the IP and contents of PTR records are under control of the owner of the IP
address actually making the connection. address actually making the connection.
These limits are per mechanism or macro in the record, and are in These limits are per mechanism or macro in the record, and are in
addition to the lookup limits specified above. addition to the lookup limits specified above.
MTAs or other processors SHOULD impose a limit on the maximum amount MTAs or other processors SHOULD impose a limit on the maximum amount
skipping to change at page 22, line 11 skipping to change at page 23, line 11
The result of evaluating check_host() with a syntactically invalid The result of evaluating check_host() with a syntactically invalid
domain is undefined. domain is undefined.
5. Mechanism Definitions 5. Mechanism Definitions
This section defines two types of mechanisms: basic language This section defines two types of mechanisms: basic language
framework mechanisms and designated sender mechanisms. framework mechanisms and designated sender mechanisms.
Basic mechanisms contribute to the language framework. They do not Basic mechanisms contribute to the language framework. They do not
specify a particular type of authorization scheme. specify a particular type of authorization scheme. The basic
mechanisms are as follows:
all all
include include
Designated sender mechanisms are used to identify a set of <ip> Designated sender mechanisms are used to identify a set of <ip>
addresses as being permitted or not permitted to use the <domain> for addresses as being permitted or not permitted to use the <domain> for
sending mail. sending mail. The designated sender mechanisms are as follows:
a a
mx mx
ptr (do not publish) ptr (do not use)
ip4 ip4
ip6 ip6
exists exists
The following conventions apply to all mechanisms that perform a The following conventions apply to all mechanisms that perform a
comparison between <ip> and an IP address at any point: comparison between <ip> and an IP address at any point:
If no CIDR prefix length is given in the directive, then <ip> and the If no CIDR prefix length is given in the directive, then <ip> and the
IP address are compared for equality. (Here, CIDR is Classless IP address are compared for equality. (Here, CIDR is Classless
Inter-Domain Routing, described in [RFC4632].) Inter-Domain Routing, described in [RFC4632].)
skipping to change at page 23, line 18 skipping to change at page 24, line 18
The "all" mechanism is a test that always matches. It is used as the The "all" mechanism is a test that always matches. It is used as the
rightmost mechanism in a record to provide an explicit default. rightmost mechanism in a record to provide an explicit default.
For example: For example:
v=spf1 a mx -all v=spf1 a mx -all
Mechanisms after "all" will never be tested. Mechanisms listed after Mechanisms after "all" will never be tested. Mechanisms listed after
"all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST be "all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST be
ignored when there is an "all" mechanism in the record. ignored when there is an "all" mechanism in the record regardless of
the relative ordering of the terms.
5.2. "include" 5.2. "include"
include = "include" ":" domain-spec include = "include" ":" domain-spec
The "include" mechanism triggers a recursive evaluation of The "include" mechanism triggers a recursive evaluation of
check_host(). check_host().
1. The domain-spec is expanded as per Section 7. 1. The domain-spec is expanded as per Section 7.
2. check_host() is evaluated with the resulting string as the 2. check_host() is evaluated with the resulting string as the
<domain>. The <ip> and <sender> arguments remain the same as in <domain>. The <ip> and <sender> arguments remain the same as in
the current evaluation of check_host(). the current evaluation of check_host().
3. The recursive evaluation returns either match, not match, or an 3. The recursive evaluation returns match, not match, or an error.
error. If it matches, then the appropriate result for the
include: mechanism is used (e.g. include or +include produces a
"pass" result and -include produces "fail").
4. If there is no match, the parent check_host() resumes processing 4. If it returns match, then the appropriate result for the include:
as per the table below, with the previous value of <domain> mechanism is used (e.g. include or +include produces a "pass"
restored. result and -include produces "fail").
5. If it returns no match or an error, the parent check_host()
resumes processing as per the table below, with the previous
value of <domain> restored.
In hindsight, the name "include" was poorly chosen. Only the In hindsight, the name "include" was poorly chosen. Only the
evaluated result of the referenced SPF record is used, rather than evaluated result of the referenced SPF record is used, rather than
literally including the mechanisms of the referenced record in the literally including the mechanisms of the referenced record in the
first. For example, evaluating a "-all" directive in the referenced first. For example, evaluating a "-all" directive in the referenced
record does not terminate the overall processing and does not record does not terminate the overall processing and does not
necessarily result in an overall "fail". (Better names for this necessarily result in an overall "fail". (Better names for this
mechanism would have been "if-match", "on-match", etc.) mechanism would have been "if-match", "on-match", etc.)
The "include" mechanism makes it possible for one domain to designate The "include" mechanism makes it possible for one domain to designate
skipping to change at page 24, line 39 skipping to change at page 25, line 41
| neutral | not match | | neutral | not match |
| | | | | |
| temperror | return temperror | | temperror | return temperror |
| | | | | |
| permerror | return permerror | | permerror | return permerror |
| | | | | |
| none | return permerror | | none | return permerror |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
The "include" mechanism is intended for crossing administrative The "include" mechanism is intended for crossing administrative
boundaries. For example, if example.com and example.org were managed boundaries. When remaining within one administrative authority,
by the same entity, and if the permitted set of hosts for both "include" is usually not the best choice. For example, if
domains was "mx:example.com", it would be possible for example.org to example.com and example.org were managed by the same entity, and if
specify "include:example.com", but it would be preferable to specify the permitted set of hosts for both domains was "mx:example.com", it
"redirect=example.com" or even "mx:example.com". would be possible for example.org to specify "include:example.com",
but it would be preferable to specify "redirect=example.com" or even
"mx:example.com".
With the "include" mechanism an administratively external set of With the "include" mechanism an administratively external set of
hosts can be authorized, but determination of sender policy is still hosts can be authorized, but determination of sender policy is still
a function of the original domain's SPF record (as determined by the a function of the original domain's SPF record (as determined by the
"all" mechanism in that record). The redirect modifier is more "all" mechanism in that record). The redirect modifier is more
suitable for consolidating both authorizations and policy into a suitable for consolidating both authorizations and policy into a
common set to be shared within an ADMD. Redirect is much more like a common set to be shared within an ADMD. Redirect is much more like a
common code element to be shared among records in a single ADMD. It common code element to be shared among records in a single ADMD. It
is possible to control both authorized hosts and policy for an is possible to control both authorized hosts and policy for an
arbitrary number of domains from a single record. arbitrary number of domains from a single record.
skipping to change at page 29, line 18 skipping to change at page 30, line 18
Modifiers always have an "=" separating the name and the value. Modifiers always have an "=" separating the name and the value.
The modifiers defined in this document ("redirect" and "exp") SHOULD The modifiers defined in this document ("redirect" and "exp") SHOULD
appear at the end of the record, after all mechanisms, though appear at the end of the record, after all mechanisms, though
syntactically they can appear anywhere in the record. Ordering of syntactically they can appear anywhere in the record. Ordering of
these two modifiers does not matter. These two modifiers MUST NOT these two modifiers does not matter. These two modifiers MUST NOT
appear in a record more than once each. If they do, then appear in a record more than once each. If they do, then
check_host() exits with a result of "permerror". check_host() exits with a result of "permerror".
Unrecognized modifiers MUST be ignored no matter where in a record, Unrecognized modifiers MUST be ignored no matter where in a record,
or how often. This allows implementations of this document to they appear or how often. This allows implementations of this
gracefully handle records with modifiers that are defined in other document to gracefully handle records with modifiers that are defined
specifications. in other specifications.
6.1. redirect: Redirected Query 6.1. redirect: Redirected Query
The redirect modifier is intended for consolidating both The redirect modifier is intended for consolidating both
authorizations and policy into a common set to be shared within a authorizations and policy into a common set to be shared within a
single ADMD. It is possible to control both authorized hosts and single ADMD. It is possible to control both authorized hosts and
policy for an arbitrary number of domains from a single record. policy for an arbitrary number of domains from a single record.
redirect = "redirect" "=" domain-spec redirect = "redirect" "=" domain-spec
skipping to change at page 30, line 21 skipping to change at page 31, line 21
the same record. This can be an administrative advantage. the same record. This can be an administrative advantage.
Note: In general, the domain "A" cannot reliably use a redirect to Note: In general, the domain "A" cannot reliably use a redirect to
another domain "B" not under the same administrative control. Since another domain "B" not under the same administrative control. Since
the <sender> stays the same, there is no guarantee that the record at the <sender> stays the same, there is no guarantee that the record at
domain "B" will correctly work for mailboxes in domain "A", domain "B" will correctly work for mailboxes in domain "A",
especially if domain "B" uses mechanisms involving local-parts. An especially if domain "B" uses mechanisms involving local-parts. An
"include" directive will generally be more appropriate. "include" directive will generally be more appropriate.
For clarity, any "redirect" modifier SHOULD appear as the very last For clarity, any "redirect" modifier SHOULD appear as the very last
term in a record. term in a record. Any "redirect" modifier MUST be ignored if there
is an "all" mechanism anywhere in the record.
6.2. exp: Explanation 6.2. exp: Explanation
explanation = "exp" "=" domain-spec explanation = "exp" "=" domain-spec
If check_host() results in a "fail" due to a mechanism match (such as If check_host() results in a "fail" due to a mechanism match (such as
"-all"), and the "exp" modifier is present, then the explanation "-all"), and the "exp" modifier is present, then the explanation
string returned is computed as described below. If no "exp" modifier string returned is computed as described below. If no "exp" modifier
is present, then either a default explanation string or an empty is present, then either a default explanation string or an empty
explanation string MUST be returned to the calling application. explanation string MUST be returned to the calling application.
skipping to change at page 38, line 15 skipping to change at page 39, line 15
"neutral" more harshly than "none" would discourage ADMDs from "neutral" more harshly than "none" would discourage ADMDs from
testing the use of SPF records (see Section 10.1). testing the use of SPF records (see Section 10.1).
8.3. Pass 8.3. Pass
A "pass" result means that the client is authorized to inject mail A "pass" result means that the client is authorized to inject mail
with the given identity. The domain can now, in the sense of with the given identity. The domain can now, in the sense of
reputation, be considered responsible for sending the message. reputation, be considered responsible for sending the message.
Further policy checks can now proceed with confidence in the Further policy checks can now proceed with confidence in the
legitimate use of the identity. This is further discussed in legitimate use of the identity. This is further discussed in
Appendix H.1. Appendix G.1.
8.4. Fail 8.4. Fail
A "fail" result is an explicit statement that the client is not A "fail" result is an explicit statement that the client is not
authorized to use the domain in the given identity. Disposition of authorized to use the domain in the given identity. Disposition of
SPF fail messages is a matter of local policy. See Appendix H.2 for SPF fail messages is a matter of local policy. See Appendix G.2 for
considerations on developing local policy. considerations on developing local policy.
If the checking software chooses to reject the mail during the SMTP If the checking software chooses to reject the mail during the SMTP
transaction, then it SHOULD use an SMTP reply code of 550 (see transaction, then it SHOULD use an SMTP reply code of 550 (see
[RFC5321]) and, if supported, the 5.7.1 enhanced status code (see [RFC5321]) and, if supported, the 5.7.1 enhanced status code (see
[RFC3463], Section 3.8), in addition to an appropriate reply text. [RFC3463], Section 3.8), in addition to an appropriate reply text.
The check_host() function will return either a default explanation The check_host() function will return either a default explanation
string or one from the domain that published the SPF records (see string or one from the domain that published the SPF records (see
Section 6.2). If the information does not originate with the Section 6.2). If the information does not originate with the
checking software, it is good to make it clear that the text is checking software, it is good to make it clear that the text is
skipping to change at page 39, line 21 skipping to change at page 40, line 21
8.6. Temperror 8.6. Temperror
A "temperror" result means the SPF verifier encountered a transient A "temperror" result means the SPF verifier encountered a transient
(generally DNS) error while performing the check. Checking software (generally DNS) error while performing the check. Checking software
can choose to accept or temporarily reject the message. If the can choose to accept or temporarily reject the message. If the
message is rejected during the SMTP transaction for this reason, the message is rejected during the SMTP transaction for this reason, the
software SHOULD use an SMTP reply code of 451 and, if supported, the software SHOULD use an SMTP reply code of 451 and, if supported, the
4.4.3 enhanced status code (see [RFC3463], Section 3.5). These 4.4.3 enhanced status code (see [RFC3463], Section 3.5). These
errors can be caused by problems in either the sender's or receiver's errors can be caused by problems in either the sender's or receiver's
DNS software. See Appendix H.4 for considerations on developing DNS software. See Appendix G.4 for considerations on developing
local policy. local policy.
8.7. Permerror 8.7. Permerror
A "permerror" result means the domain's published records could not A "permerror" result means the domain's published records could not
be correctly interpreted. This signals an error condition that be correctly interpreted. This signals an error condition that
definitely requires DNS operator intervention to be resolved. If the definitely requires DNS operator intervention to be resolved. If the
message is rejected during the SMTP transaction for this reason, the message is rejected during the SMTP transaction for this reason, the
software SHOULD use an SMTP reply code of 550 and, if supported, the software SHOULD use an SMTP reply code of 550 and, if supported, the
5.5.2 enhanced status code (see [RFC3463], Section 3.6). Be aware 5.5.2 enhanced status code (see [RFC3463], Section 3.6). Be aware
that if the ADMD uses macros (Section 7), it is possible that this that if the ADMD uses macros (Section 7), it is possible that this
result is due to the checked identities having an unexpected format. result is due to the checked identities having an unexpected format.
It is also possible that this result is generated by certain SPF It is also possible that this result is generated by certain SPF
verifiers due to the input arguments having an unexpected format; see verifiers due to the input arguments having an unexpected format; see
Section 4.8. See Appendix H.3 for considerations on developing local Section 4.8. See Appendix G.3 for considerations on developing local
policy. policy.
9. Recording the Result 9. Recording the Result
To provide downstream agents, such as MUAs, with the information they To provide downstream agents, such as MUAs, with the information they
might need in terms of evaluating or representing the apparent safety might need in terms of evaluating or representing the apparent safety
of the message content, it is RECOMMENDED that SMTP receivers record of the message content, it is RECOMMENDED that SMTP receivers record
the result of SPF processing in the message header. For SPF verifier the result of SPF processing in the message header. For SPF verifier
operators that choose to record SPF results in the header of the operators that choose to record SPF results in the header of the
message for processing by internal filters or MUAs, two methods are message for processing by internal filters or MUAs, two methods are
skipping to change at page 45, line 47 skipping to change at page 46, line 47
The hostname is generally the identity used in the 5321.HELO/.EHLO The hostname is generally the identity used in the 5321.HELO/.EHLO
command. In the case of messages with a null 5321.MailFrom, this is command. In the case of messages with a null 5321.MailFrom, this is
used as the domain for 5321.MailFrom SPF checks, in addition to being used as the domain for 5321.MailFrom SPF checks, in addition to being
used in 5321.HELO/.EHLO based SPF checks. The standard SPF record used in 5321.HELO/.EHLO based SPF checks. The standard SPF record
for an individual host that is involved in mail processing is: for an individual host that is involved in mail processing is:
relay.example.com. IN TXT "v=spf1 a -all" relay.example.com. IN TXT "v=spf1 a -all"
Validating correct deployment is difficult. [RFC6652] describes one Validating correct deployment is difficult. [RFC6652] describes one
mechanism for soliciting feedback on SPF failures. Another mechanism for soliciting feedback on SPF failures. Another
suggestion can be found in Appendix D. suggestion can be found in Appendix C.
Regardless of the method used, understanding the ADMD's outbound mail Regardless of the method used, understanding the ADMD's outbound mail
architecture is essential to effective deployment. architecture is essential to effective deployment.
10.1.3. Bounces 10.1.3. Bounces
As explained in Section 1.1.3, [RFC5321] allows the MAIL FROM to be As explained in Section 1.1.3, [RFC5321] allows the MAIL FROM to be
null, which is typical of some Delivery Status Notification null, which is typical of some Delivery Status Notification
[RFC3464], commonly called email bounces. In this case the only [RFC3464], commonly called email bounces. In this case the only
entity available for performing an SPF check is the "HELO" identity entity available for performing an SPF check is the "HELO" identity
skipping to change at page 46, line 31 skipping to change at page 47, line 31
SPF results can be used in combination with other methods to SPF results can be used in combination with other methods to
determine the final local disposition (either positive or negative) determine the final local disposition (either positive or negative)
of a message. It can also be considered dispositive on its own. of a message. It can also be considered dispositive on its own.
An attempt to have one organization (sender) direct the email An attempt to have one organization (sender) direct the email
handling policies of another (receiver) is inherently challenging and handling policies of another (receiver) is inherently challenging and
often controversial. As stated elsewhere in this document, there is often controversial. As stated elsewhere in this document, there is
no comprehensive normative requirement for specific handling of a no comprehensive normative requirement for specific handling of a
message based on SPF results. The information presented in Section 8 message based on SPF results. The information presented in Section 8
and in Appendix H is offered for receiver consideration when forming and in Appendix G is offered for receiver consideration when forming
local handling policies. local handling policies.
The primary considerations are that SPF might return "pass" for mail The primary considerations are that SPF might return "pass" for mail
that is ultimately harmful (e.g., spammers that arrange for SPF to that is ultimately harmful (e.g., spammers that arrange for SPF to
pass using disposable domain names, or virus or spam outbreaks from pass using disposable domain names, or virus or spam outbreaks from
within trusted sources), and might also return "fail" for mail that within trusted sources), and might also return "fail" for mail that
is ultimately legitimate (e.g., legitimate mail that has traversed a is ultimately legitimate (e.g., legitimate mail that has traversed a
mail alias). It is important take both of these cases under mail alias). It is important take both of these cases under
consideration when establishing local handling policy. consideration when establishing local handling policy.
skipping to change at page 47, line 14 skipping to change at page 48, line 14
Because SPF evaluation is based on the IP address of the "last" Because SPF evaluation is based on the IP address of the "last"
sending SMTP server, the address of the mediator will be used, rather 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 than the address of the SMTP server that sent the message to the
mediator. Some mediators retain the email address from the original mediator. Some mediators retain the email address from the original
message, while some use a new address. message, while some use a new address.
If the address is the same as for the original message, and the If the address is the same as for the original message, and the
original message had an associated SPF record, then the SPF original message had an associated SPF record, then the SPF
evaluation will fail unless mitigations such as those described in evaluation will fail unless mitigations such as those described in
Appendix E are used. Appendix D are used.
11. Security Considerations 11. Security Considerations
11.1. Processing Limits 11.1. Processing Limits
As with most aspects of email, there are a number of ways that As with most aspects of email, there are a number of ways that
malicious parties could use the protocol as an avenue for a malicious parties could use the protocol as an avenue for a
Denial-of-Service (DoS) attack. The processing limits outlined in Denial-of-Service (DoS) attack. The processing limits outlined in
Section 4.6.4 are designed to prevent attacks such as the following: Section 4.6.4 are designed to prevent attacks such as the following:
skipping to change at page 49, line 17 skipping to change at page 50, line 17
encountered (defined in Section 4.6.4). encountered (defined in Section 4.6.4).
Of these, the case of a third party referenced in the SPF record is Of these, the case of a third party referenced in the SPF record is
the easiest for a DoS attack to effectively exploit. As a result, the easiest for a DoS attack to effectively exploit. As a result,
limits that might seem reasonable for an individual mail server can limits that might seem reasonable for an individual mail server can
still allow an unreasonable amount of bandwidth amplification. still allow an unreasonable amount of bandwidth amplification.
Therefore, the processing limits need to be quite low. Therefore, the processing limits need to be quite low.
11.2. SPF-Authorized Email May Contain Other False Identities 11.2. SPF-Authorized Email May Contain Other False Identities
Do not construe the "MAIL FROM" and "HELO" identity authorizations to The "MAIL FROM" and "HELO" identity authorizations do not provide
provide more assurance than they do. It is entirely possible for a assurance about the authorization/authenticity of other identities
malicious sender to inject a message using his own domain in the used in the message. It is entirely possible for a malicious sender
identities used by SPF, to have that domain's SPF record authorize to inject a message using his own domain in the identities used by
the sending host, and yet the message can easily list other SPF, to have that domain's SPF record authorize the sending host, and
identities in its header. Unless the user or the MUA takes care to yet the message can easily list other identities in its header.
note that the authorized identity does not match the other more Unless the user or the MUA takes care to note that the authorized
commonly-presented identities (such as the From: header field), the identity does not match the other more commonly-presented identities
user might be lulled into a false sense of security. (such as the From: header field), the user might be lulled into a
false sense of security.
11.3. Spoofed DNS and IP Data 11.3. Spoofed DNS and IP Data
There are two aspects of this protocol that malicious parties could There are two aspects of this protocol that malicious parties could
exploit to undermine the validity of the check_host() function: exploit to undermine the validity of the check_host() function:
o The evaluation of check_host() relies heavily on DNS. A malicious o The evaluation of check_host() relies heavily on DNS. A malicious
attacker could attack the DNS infrastructure and cause attacker could attack the DNS infrastructure and cause
check_host() to see spoofed DNS data, and then return incorrect check_host() to see spoofed DNS data, and then return incorrect
results. This could include returning "pass" for an <ip> value results. This could include returning "pass" for an <ip> value
where the actual domain's record would evaluate to "fail". See where the actual domain's record would evaluate to "fail". See
[RFC3833] for a description of DNS weaknesses. [RFC3833] for a description of DNS weaknesses and see [RFC4033]
for a countermeasure.
o The client IP address, <ip>, is assumed to be correct. In a o The client IP address, <ip>, is assumed to be correct. In a
modern, correctly configured system the risk of this not being modern, correctly configured system the risk of this not being
true is nil. true is nil.
11.4. Cross-User Forgery 11.4. Cross-User Forgery
By definition, SPF policies just map domain names to sets of By definition, SPF policies just map domain names to sets of
authorized MTAs, not whole email addresses to sets of authorized authorized MTAs, not whole email addresses to sets of authorized
users. Although the "l" macro (Section 7) provides a limited way to users. Although the "l" macro (Section 7) provides a limited way to
skipping to change at page 52, line 5 skipping to change at page 53, line 5
to likely harm. This is especially true for domains belonging to to likely harm. This is especially true for domains belonging to
known good actors that are typically well-behaved; unauthorized mail known good actors that are typically well-behaved; unauthorized mail
from those sources might well be subjected to much higher skepticism from those sources might well be subjected to much higher skepticism
and content analysis. and content analysis.
SPF does not, however, include the capacity for identifying good SPF does not, however, include the capacity for identifying good
actors from bad ones, nor does it handle the concept of known actors actors from bad ones, nor does it handle the concept of known actors
versus unknown ones. Those notions are out of scope for this versus unknown ones. Those notions are out of scope for this
specification. specification.
12. Contributors and Acknowledgements 12. Collected ABNF
This section is normative and any discrepancies with the ABNF
fragments in the preceding text are to be resolved in favor of this
grammar.
See [RFC5234] for ABNF notation. Please note that as per this ABNF
definition, literal text strings (those in quotes) are case-
insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx".
record = version terms *SP
version = "v=spf1"
terms = *( 1*SP ( directive / modifier ) )
directive = [ qualifier ] mechanism
qualifier = "+" / "-" / "?" / "~"
mechanism = ( all / include
/ a / mx / ptr / ip4 / ip6 / exists )
all = "all"
include = "include" ":" domain-spec
a = "a" [ ":" domain-spec ] [ dual-cidr-length ]
mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
ptr = "ptr" [ ":" domain-spec ]
ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
exists = "exists" ":" domain-spec
modifier = redirect / explanation / unknown-modifier
redirect = "redirect" "=" domain-spec
explanation = "exp" "=" domain-spec
unknown-modifier = name "=" macro-string
; where name is not any known modifier
ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32
ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
; conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as per [RFC 4291], section 2.2>
; e.g., 2001:DB8::CD30
domain-spec = macro-string domain-end
domain-end = ( "." toplabel [ "." ] ) / macro-expand
toplabel = ( *alphanum ALPHA *alphanum ) /
( 1*alphanum "-" *( alphanum / "-" ) alphanum )
; LDH rule plus additional TLD restrictions
; (see [RFC3696], Section 2 for background)
alphanum = ALPHA / DIGIT
explain-string = *( macro-string / SP )
macro-string = *( macro-expand / macro-literal )
macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-"
macro-literal = %x21-24 / %x26-7E
; visible characters except "%"
macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
"c" / "r" / "t" / "v"
transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
[ key-value-list ] CRLF
result = "pass" / "fail" / "softfail" / "neutral" /
"none" / "temperror" / "permerror"
key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
[";"]
key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
key = "client-ip" / "envelope-from" / "helo" /
"problem" / "receiver" / "identity" /
"mechanism" / name
identity = "mailfrom" ; for the "MAIL FROM" identity
/ "helo" ; for the "HELO" identity
/ name ; other identities
sender = Mailbox
ip = ip4-network / ip6-network
ALPHA = <A-Z / a-z as per [RFC5234]>
DIGIT = <0-9 as per [RFC5234]>
SP = <space character as per [RFC5234]>
dot-atom = <unquoted word as per [RFC5322]>
quoted-string = <quoted string as per [RFC5322]>
comment = <comment string as per [RFC5322]>
CFWS = <comment or folding white space as per [RFC5322]>
FWS = <folding white space as per [RFC5322]>
CRLF = <standard end-of-line token as per [RFC5322]>
13. Contributors and Acknowledgements
This document is largely based on the work of Meng Weng Wong, Mark This document is largely based on the work of Meng Weng Wong, Mark
Lentczner, and Wayne Schlitt. Although, as this section Lentczner, and Wayne Schlitt. Although, as this section
acknowledges, many people have contributed to this document, a very acknowledges, many people have contributed to this document, a very
large portion of the writing and editing are due to Meng, Mark, and large portion of the writing and editing are due to Meng, Mark, and
Wayne. Wayne.
This design owes a debt of parentage to [RMX] by Hadmut Danisch and This design owes a debt of parentage to [RMX] by Hadmut Danisch and
to [DMP] by Gordon Fecyk. The idea of using a DNS record to check to [DMP] by Gordon Fecyk. The idea of using a DNS record to check
the legitimacy of an email address traces its ancestry further back the legitimacy of an email address traces its ancestry further back
skipping to change at page 53, line 5 skipping to change at page 57, line 5
the development of this design. They are far too numerous to name, the development of this design. They are far too numerous to name,
but they include the following: but they include the following:
The participants in the SPFbis working group. The participants in the SPFbis working group.
The folks on the spf-discuss mailing list. The folks on the spf-discuss mailing list.
The folks on the SPAM-L mailing list. The folks on the SPAM-L mailing list.
The folks on the IRTF ASRG mailing list. The folks on the IRTF ASRG mailing list.
The folks on the IETF MARID mailing list. The folks on the IETF MARID mailing list.
The folks on #perl. The folks on #perl.
13. IANA Considerations 14. IANA Considerations
13.1. The SPF DNS Record Type 14.1. The SPF DNS Record Type
Per [RFC4408], the IANA assigned the Resource Record Type and Qtype Per [RFC4408], the IANA assigned the Resource Record Type and Qtype
from the DNS Parameters Registry for the SPF RR type with code 99. from the DNS Parameters Registry for the SPF RR type with code 99.
The format of this type is identical to the TXT RR [RFC1035]. The The format of this type is identical to the TXT RR [RFC1035]. The
character content of the record is encoded as [US-ASCII]. character content of the record is encoded as [US-ASCII].
Studies have shown that RRTYPE 99 has not seen any substantial use, Studies have shown that RRTYPE 99 has not seen any substantial use,
and in fact its existence and mechanism defined in [RFC4408] has led and in fact its existence and mechanism defined in [RFC4408] has led
to some interoperability issues. Accordingly, its use is now to some interoperability issues. Accordingly, its use is now
obsolete, and new implementations are not to use it. obsolete, and new implementations are not to use it.
IANA is requested to update the Resource Record (RR) TYPEs registry IANA is requested to update the Resource Record (RR) TYPEs registry
to indicate that this document is the reference document for that to indicate that this document is the reference document for that
RRTYPE. RRTYPE.
[NOTE TO RFC EDITOR: (to be changed to " ... has updated ..." upon [NOTE TO RFC EDITOR: (to be changed to " ... has updated ..." upon
publication)] publication)]
13.2. The Received-SPF Mail Header Field 14.2. The Received-SPF Mail Header Field
Per [RFC3864], the "Received-SPF:" header field is added to the IANA Per [RFC3864], the "Received-SPF:" header field is added to the IANA
Permanent Message Header Field Registry. The following is the Permanent Message Header Field Registry. The following is the
registration template: registration template:
Header field name: Received-SPF Header field name: Received-SPF
Applicable protocol: mail ([RFC5322]) Applicable protocol: mail ([RFC5322])
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): RFC XXXX Specification document(s): RFC XXXX
[NOTE TO RFC EDITOR: (this document)] [NOTE TO RFC EDITOR: (this document)]
13.3. SPF Modifier Registry 14.3. SPF Modifier Registry
IANA is requested to change the reference for the exp and redirect IANA is requested to change the reference for the exp and redirect
modifiers in the Modifier Names registry, under Sender Policy modifiers in the Modifier Names registry, under Sender Policy
Framework Parameters, from [RFC4408] to this document. Their status Framework Parameters, from [RFC4408] to this document. Their status
is unchanged. is unchanged.
14. References 15. References
14.1. Normative References 15.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 55, line 11 skipping to change at page 59, line 11
[US-ASCII] [US-ASCII]
American National Standards Institute (formerly United American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for States of America Standards Institute), "USA Code for
Information Interchange, X3.4", 1968. Information Interchange, X3.4", 1968.
ANSI X3.4-1968 has been replaced by newer versions with ANSI X3.4-1968 has been replaced by newer versions with
slight modifications, but the 1968 version remains slight modifications, but the 1968 version remains
definitive for the Internet. definitive for the Internet.
14.2. Informative References 15.2. Informative References
[DMP] Fecyk, G., "Designated Mailers Protocol". [DMP] Fecyk, G., "Designated Mailers Protocol".
Work In Progress Work In Progress
[Green] Green, D., "Domain-Authorized SMTP Mail", 2002. [Green] Green, D., "Domain-Authorized SMTP Mail", 2002.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
skipping to change at page 55, line 45 skipping to change at page 59, line 45
[RFC3696] Klensin, J., "Application Techniques for Checking and [RFC3696] Klensin, J., "Application Techniques for Checking and
Transformation of Names", RFC 3696, February 2004. Transformation of Names", RFC 3696, February 2004.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004. Name System (DNS)", RFC 3833, August 2004.
[RFC3834] Moore, K., "Recommendations for Automatic Responses to [RFC3834] Moore, K., "Recommendations for Automatic Responses to
Electronic Mail", RFC 3834, August 2004. Electronic Mail", RFC 3834, August 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1", for Authorizing Use of Domains in E-Mail, Version 1",
RFC 4408, April 2006. RFC 4408, April 2006.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006. Plan", BCP 122, RFC 4632, August 2006.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
skipping to change at page 57, line 5 skipping to change at page 61, line 5
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
[RMX] Danisch, H., "The RMX DNS RR Type for light weight sender [RMX] Danisch, H., "The RMX DNS RR Type for light weight sender
authentication". authentication".
Work In Progress Work In Progress
[Vixie] Vixie, P., "Repudiating MAIL FROM", 2002. [Vixie] Vixie, P., "Repudiating MAIL FROM", 2002.
Appendix A. Collected ABNF Appendix A. Extended Examples
This section is normative and any discrepancies with the ABNF
fragments in the preceding text are to be resolved in favor of this
grammar.
See [RFC5234] for ABNF notation. Please note that as per this ABNF
definition, literal text strings (those in quotes) are case-
insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx".
record = version terms *SP
version = "v=spf1"
terms = *( 1*SP ( directive / modifier ) )
directive = [ qualifier ] mechanism
qualifier = "+" / "-" / "?" / "~"
mechanism = ( all / include
/ a / mx / ptr / ip4 / ip6 / exists )
all = "all"
include = "include" ":" domain-spec
a = "a" [ ":" domain-spec ] [ dual-cidr-length ]
mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
ptr = "ptr" [ ":" domain-spec ]
ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
exists = "exists" ":" domain-spec
modifier = redirect / explanation / unknown-modifier
redirect = "redirect" "=" domain-spec
explanation = "exp" "=" domain-spec
unknown-modifier = name "=" macro-string
; where name is not any known modifier
ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32
ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
; conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as per [RFC 4291], section 2.2>
; e.g., 2001:DB8::CD30
domain-spec = macro-string domain-end
domain-end = ( "." toplabel [ "." ] ) / macro-expand
toplabel = ( *alphanum ALPHA *alphanum ) /
( 1*alphanum "-" *( alphanum / "-" ) alphanum )
; LDH rule plus additional TLD restrictions
; (see [RFC3696], Section 2 for background)
alphanum = ALPHA / DIGIT
explain-string = *( macro-string / SP )
macro-string = *( macro-expand / macro-literal )
macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-"
macro-literal = %x21-24 / %x26-7E
; visible characters except "%"
macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
"c" / "r" / "t" / "v"
transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
[ key-value-list ] CRLF
result = "pass" / "fail" / "softfail" / "neutral" /
"none" / "temperror" / "permerror"
key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
[";"]
key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
key = "client-ip" / "envelope-from" / "helo" /
"problem" / "receiver" / "identity" /
"mechanism" / name
identity = "mailfrom" ; for the "MAIL FROM" identity
/ "helo" ; for the "HELO" identity
/ name ; other identities
sender = Mailbox
ip = ip4-network / ip6-network
ALPHA = <A-Z / a-z as per [RFC5234]>
DIGIT = <0-9 as per [RFC5234]>
SP = <space character as per [RFC5234]>
dot-atom = <unquoted word as per [RFC5322]>
quoted-string = <quoted string as per [RFC5322]>
comment = <comment string as per [RFC5322]>
CFWS = <comment or folding white space as per [RFC5322]>
FWS = <folding white space as per [RFC5322]>
CRLF = <standard end-of-line token as per [RFC5322]>
Appendix B. Extended Examples
These examples are based on the following DNS setup: These examples are based on the following DNS setup:
; A domain with two mail servers, two hosts ; A domain with two mail servers, two hosts
; and two servers at the domain name ; and two servers at the domain name
$ORIGIN example.com. $ORIGIN example.com.
@ MX 10 mail-a @ MX 10 mail-a
MX 20 mail-b MX 20 mail-b
A 192.0.2.10 A 192.0.2.10
A 192.0.2.11 A 192.0.2.11
skipping to change at page 60, line 42 skipping to change at page 61, line 42
66 PTR bob.example.com. 66 PTR bob.example.com.
129 PTR mail-a.example.com. 129 PTR mail-a.example.com.
130 PTR mail-b.example.com. 130 PTR mail-b.example.com.
140 PTR mail-c.example.org. 140 PTR mail-c.example.org.
; A rogue reverse IP domain that claims to be ; A rogue reverse IP domain that claims to be
; something it's not ; something it's not
$ORIGIN 0.0.10.in-addr.arpa. $ORIGIN 0.0.10.in-addr.arpa.
4 PTR bob.example.com. 4 PTR bob.example.com.
B.1. Simple Examples A.1. Simple Examples
These examples show various possible published records for These examples show various possible published records for
example.com and which values if <ip> would cause check_host() to example.com and which values if <ip> would cause check_host() to
return "pass". Note that <domain> is "example.com". return "pass". Note that <domain> is "example.com".
v=spf1 +all v=spf1 +all
-- any <ip> passes -- any <ip> passes
v=spf1 a -all v=spf1 a -all
-- hosts 192.0.2.10 and 192.0.2.11 pass -- hosts 192.0.2.10 and 192.0.2.11 pass
skipping to change at page 61, line 35 skipping to change at page 62, line 35
-- sending host 192.0.2.65 passes (reverse DNS is valid and is in -- sending host 192.0.2.65 passes (reverse DNS is valid and is in
example.com) example.com)
-- sending host 192.0.2.140 fails (reverse DNS is valid, but not -- sending host 192.0.2.140 fails (reverse DNS is valid, but not
in example.com) in example.com)
-- sending host 10.0.0.4 fails (reverse IP is not valid) -- sending host 10.0.0.4 fails (reverse IP is not valid)
v=spf1 ip4:192.0.2.128/28 -all v=spf1 ip4:192.0.2.128/28 -all
-- sending host 192.0.2.65 fails -- sending host 192.0.2.65 fails
-- sending host 192.0.2.129 passes -- sending host 192.0.2.129 passes
B.2. Multiple Domain Example A.2. Multiple Domain Example
These examples show the effect of related records: These examples show the effect of related records:
example.org: "v=spf1 include:example.com include:example.net -all" example.org: "v=spf1 include:example.com include:example.net -all"
This record would be used if mail from example.org actually came This record would be used if mail from example.org actually came
through servers at example.com and example.net. Example.org's through servers at example.com and example.net. Example.org's
designated servers are the union of example.com's and example.net's designated servers are the union of example.com's and example.net's
designated servers. designated servers.
la.example.org: "v=spf1 redirect=example.org" la.example.org: "v=spf1 redirect=example.org"
ny.example.org: "v=spf1 redirect=example.org" ny.example.org: "v=spf1 redirect=example.org"
sf.example.org: "v=spf1 redirect=example.org" sf.example.org: "v=spf1 redirect=example.org"
These records allow a set of domains that all use the same mail These records allow a set of domains that all use the same mail
system to make use of that mail system's record. In this way, only system to make use of that mail system's record. In this way, only
the mail system's record needs to be updated when the mail setup the mail system's record needs to be updated when the mail setup
changes. These domains' records never have to change. changes. These domains' records never have to change.
B.3. DNSBL Style Example A.3. DNSBL Style Example
Imagine that, in addition to the domain records listed above, there Imagine that, in addition to the domain records listed above, there
are these (see [RFC5782]): are these (see [RFC5782]):
$ORIGIN _spf.example.com. $ORIGIN _spf.example.com.
mary.mobile-users A 127.0.0.2 mary.mobile-users A 127.0.0.2
fred.mobile-users A 127.0.0.2 fred.mobile-users A 127.0.0.2
15.15.168.192.joel.remote-users A 127.0.0.2 15.15.168.192.joel.remote-users A 127.0.0.2
16.15.168.192.joel.remote-users A 127.0.0.2 16.15.168.192.joel.remote-users A 127.0.0.2
skipping to change at page 62, line 36 skipping to change at page 63, line 36
-all -all
mobile-users._spf.example.com: mobile-users._spf.example.com:
v=spf1 exists:%{l1r+}.%{d} v=spf1 exists:%{l1r+}.%{d}
remote-users._spf.example.com: remote-users._spf.example.com:
v=spf1 exists:%{ir}.%{l1r+}.%{d} v=spf1 exists:%{ir}.%{l1r+}.%{d}
B.4. Multiple Requirements Example A.4. Multiple Requirements Example
Say that your sender policy requires both that the IP address is Say that your sender policy requires both that the IP address is
within a certain range and that the reverse DNS for the IP matches. within a certain range and that the reverse DNS for the IP matches.
This can be done several ways, including the following: This can be done several ways, including the following:
example.com. SPF ( "v=spf1 " example.com. SPF ( "v=spf1 "
"-include:ip4._spf.%{d} " "-include:ip4._spf.%{d} "
"-include:ptr._spf.%{d} " "-include:ptr._spf.%{d} "
"+all" ) "+all" )
ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all" ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all"
ptr._spf.example.com. SPF "v=spf1 -ptr +all" ptr._spf.example.com. SPF "v=spf1 -ptr +all"
This example shows how the "-include" mechanism can be useful, how an This example shows how the "-include" mechanism can be useful, how an
SPF record that ends in "+all" can be very restrictive, and the use SPF record that ends in "+all" can be very restrictive, and the use
of De Morgan's Law. of De Morgan's Law.
Appendix C. Changes in implementation requirements from RFC 4408 Appendix B. Changes in implementation requirements from RFC 4408
The modifications to implementation requirements from [RFC4408] are The modifications to implementation requirements from [RFC4408] are
all either (a) corrections to errors in [RFC4408], or (b) additional all either (a) corrections to errors in [RFC4408], or (b) additional
documentation based on consensus of operational experience acquired documentation based on consensus of operational experience acquired
since publication of [RFC4408]. since publication of [RFC4408].
o Use of DNS RR type SPF (99) has been removed from the protocol, o Use of DNS RR type SPF (99) has been removed from the protocol,
see [RFC6686] for background. see [RFC6686] for background.
o A new DNS related processing limit based on "void lookups" has o A new DNS related processing limit based on "void lookups" has
skipping to change at page 63, line 28 skipping to change at page 64, line 28
o Use of the ptr mechanism and the %p macro have been strongly o Use of the ptr mechanism and the %p macro have been strongly
discouraged Section 5.5 and Section 7.2. They remain part of the discouraged Section 5.5 and Section 7.2. They remain part of the
protocol because they were found to be in use, but records ought protocol because they were found to be in use, but records ought
to be updated to avoid them. to be updated to avoid them.
o Use of the "Authentication-Results" header field [RFC5451] as a o Use of the "Authentication-Results" header field [RFC5451] as a
possible alternative to use of the "Received-SPF" header field is possible alternative to use of the "Received-SPF" header field is
discussed (Section 9.2). discussed (Section 9.2).
o There have been a number of minor corrections to the ABNF to make o There have been a number of minor corrections to the ABNF to make
it more clear and correct Appendix A. SPF library implementers it more clear and correct Section 12. SPF library implementers
should give the revised ABNF a careful review to determine if should give the revised ABNF a careful review to determine if
implementation changes are needed. implementation changes are needed.
o Use of X- fields in the ABNF has been removed see [RFC6648] for o Use of X- fields in the ABNF has been removed see [RFC6648] for
background. background.
o Ambiguity about how to deal with invalid domain-spec after macro o Ambiguity about how to deal with invalid domain-spec after macro
expansion has been documented. Depending on one specific behavior expansion has been documented. Depending on one specific behavior
has to be avoided (Section 4.8). has to be avoided (Section 4.8).
o General operational information has been updated and expanded o General operational information has been updated and expanded
based on eight years of post [RFC4408] operations experience. See based on eight years of post [RFC4408] operations experience. See
Section 10 and Appendices D - H below. Section 10 and Appendices D - H below.
o Security considerations have been reviewed and updated o Security considerations have been reviewed and updated
(Section 11). (Section 11).
Appendix D. Further Testing Advice Appendix C. Further Testing Advice
Another approach that can be helpful to publish records that include Another approach that can be helpful to publish records that include
a "tracking exists:" mechanism. By looking at the name server logs, a "tracking exists:" mechanism. By looking at the name server logs,
a rough list can then be generated. For example: a rough list can then be generated. For example:
v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all
Appendix E. SPF/Mediator Interactions This associated macro expansion would cause the sending helo domain,
localpart of the sending email address, domain part of the sending
email address, and the IP address from which the connection was
received to be embdedded in an SPF query and logged in the sender's
DNS logs.
This approach, which has been used since very early in the SPF
project, allows senders to unilaterally collect data to evaluate the
correctness of their SPF records. Unlike newer feedback mechanisms,
it does not require an special cooperation from SPF verifiers. A
similar example, one of the earliest SPF records published, can still
be found as of this writing at altavista.net.
Appendix D. SPF/Mediator Interactions
There are three places that techniques can be used to ameliorate There are three places that techniques can be used to ameliorate
unintended SPF failures with mediators. unintended SPF failures with mediators.
E.1. Originating ADMDs D.1. Originating ADMDs
The beginning, when email is first sent: The beginning, when email is first sent:
o "Neutral" results could be given for IP addresses that might be o "Neutral" results could be given for IP addresses that might be
forwarders, instead of "fail" results based on a list of known forwarders, instead of "fail" results based on a list of known
reliable forwarders. For example: reliable forwarders. For example:
"v=spf1 mx ?exists:%{ir}.whitlist.example.org -all" "v=spf1 mx ?exists:%{ir}.whitelist.example.org -all"
This would cause a lookup on an DNS white list (DNSWL) and cause a 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 result of "fail" only for email not either coming from the
domain's mx host(s) (SPF pass) or white listed sources (SPF domain's mx host(s) (SPF pass) or white listed sources (SPF
neutral). This, in effect, outsources an element of sender policy neutral). This, in effect, outsources an element of sender policy
to the maintainer of the whitelist. to the maintainer of the whitelist.
o The "MAIL FROM" identity could have additional information in the o The "MAIL FROM" identity could have additional information in the
local-part that cryptographically identifies the mail as coming local-part that cryptographically identifies the mail as coming
from an authorized source. In this case, such an SPF record could from an authorized source. In this case, such an SPF record could
skipping to change at page 66, line 7 skipping to change at page 67, line 7
rate-limit the email coming from unexpected IP addresses. rate-limit the email coming from unexpected IP addresses.
"v=spf1 mx exists:%{ir}._spf_rate.%{d} -all" "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"
o SPF allows the creation of per-user policies for special cases. o SPF allows the creation of per-user policies for special cases.
For example, the following SPF record and appropriate wildcard DNS For example, the following SPF record and appropriate wildcard DNS
records can be used: records can be used:
"v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}" "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"
E.2. Mediators D.2. Mediators
The middle, when email is forwarded:. The middle, when email is forwarded:.
o Mediators can solve the problem by rewriting the "MAIL FROM" to be o Mediators can solve the problem by rewriting the "MAIL FROM" to be
in their own domain. This means mail rejected from the external in their own domain. This means mail rejected from the external
mailbox will have to be forwarded back to the original sender by mailbox will have to be forwarded back to the original sender by
the forwarding service. Various schemes to do this exist though the forwarding service. Various schemes to do this exist though
they vary widely in complexity and resource requirements on the they vary widely in complexity and resource requirements on the
part of the mediator. part of the mediator.
skipping to change at page 66, line 29 skipping to change at page 67, line 29
"mailing list" semantics by configuring an additional alias with "mailing list" semantics by configuring an additional alias with
"owner-" prepended to the original alias name (e.g., an alias of "owner-" prepended to the original alias name (e.g., an alias of
"friends: george@example.com, fred@example.org" would need another "friends: george@example.com, fred@example.org" would need another
alias of the form "owner-friends: localowner"). alias of the form "owner-friends: localowner").
o Mediators could reject mail that would "fail" SPF if forwarded o Mediators could reject mail that would "fail" SPF if forwarded
using an SMTP reply code of 551, User not local, (see [RFC5321] using an SMTP reply code of 551, User not local, (see [RFC5321]
section 3.4) to communicate the correct target address to resend section 3.4) to communicate the correct target address to resend
the mail to. the mail to.
E.3. Receving ADMDs D.3. Receiving ADMDs
The end, when email is received: The end, when email is received:
o If the owner of the external mailbox wishes to trust the mediator, o If the owner of the external mailbox wishes to trust the mediator,
he can direct the external mailbox's MTA to skip SPF tests when he can direct the external mailbox's MTA to skip SPF tests when
the client host belongs to the mediator. the client host belongs to the mediator.
o Tests against other identities, such as the "HELO" identity, can o Tests against other identities, such as the "HELO" identity, can
be used to override a failed test against the "MAIL FROM" be used to override a failed test against the "MAIL FROM"
identity. identity.
o For larger domains, it might not be possible to have a complete or o For larger domains, it might not be possible to have a complete or
accurate list of forwarding services used by the owners of the accurate list of forwarding services used by the owners of the
domain's mailboxes. In such cases, whitelists of generally- domain's mailboxes. In such cases, whitelists of generally-
recognized forwarding services could be employed. recognized forwarding services could be employed.
Appendix F. Mail Services Appendix E. Mail Services
MSPs (Mail Service Providers - [RFC5598] Section 2.3) that offer mail MSPs (Mail Service Providers - [RFC5598] Section 2.3) that offer mail
services to third-party domains, such as sending of bulk mail, might services to third-party domains, such as sending of bulk mail, might
want to adjust their configurations in light of the authorization want to adjust their configurations in light of the authorization
check described in this document. If the domain part of the "MAIL check described in this document. If the domain part of the "MAIL
FROM" identity used for such email uses the domain of one of the MSPs FROM" identity used for such email uses the domain of one of the MSPs
domain, then the provider needs only to ensure that its sending host domain, then the provider needs only to ensure that its sending host
is authorized by its own SPF record, if any. is authorized by its own SPF record, if any.
If the "MAIL FROM" identity does not use the MSP's domain, then extra If the "MAIL FROM" identity does not use the MSP's domain, then extra
care has to be taken. The SPF record format has several options for care has to be taken. The SPF record format has several options for
the third-party domain to authorize the service provider's MTAs to the third-party domain to authorize the service provider's MTAs to
send mail on its behalf. For MSPs, such as ISPs, that have a wide send mail on its behalf. For MSPs, such as ISPs, that have a wide
variety of customers using the same MTA, steps are required to variety of customers using the same MTA, steps are required to
mitigate the risk of cross-customer forgery (see Section 11.4). mitigate the risk of cross-customer forgery (see Section 11.4).
Appendix G. MTA Relays Appendix F. MTA Relays
Relays are described in [RFC5598] Section 2.2.2. The authorization Relays are described in [RFC5598] Section 2.2.2. The authorization
check generally precludes the use of arbitrary MTA relays between check generally precludes the use of arbitrary MTA relays between
sender and receiver of an email message. sender and receiver of an email message.
Within an organization, MTA relays can be effectively deployed. Within an organization, MTA relays can be effectively deployed.
However, for purposes of this document, such relays are effectively However, for purposes of this document, such relays are effectively
transparent. The SPF authorization check is a check between border transparent. The SPF authorization check is a check between border
MTAs of different ADMDs. MTAs of different ADMDs.
skipping to change at page 69, line 5 skipping to change at page 70, line 5
relayed mail stream) then do not perform the authorization test. To relayed mail stream) then do not perform the authorization test. To
perform the authorization test other than at the boundary, the host perform the authorization test other than at the boundary, the host
that first transferred the message to the receiving ADMD have to be that first transferred the message to the receiving ADMD have to be
determined, which can be difficult to extract from the message header determined, which can be difficult to extract from the message header
because (a) header fields can be forged or malformed, and (b) there's because (a) header fields can be forged or malformed, and (b) there's
no standard way to encode that information such that it can be no standard way to encode that information such that it can be
reliably extracted. Testing other than at the boundary is likely to reliably extracted. Testing other than at the boundary is likely to
produce unreliable results. This is described further in Appendix C produce unreliable results. This is described further in Appendix C
of [RFC5451]. of [RFC5451].
Appendix H. Local Policy Considerations Appendix G. Local Policy Considerations
SPF results can be used in combination with other methods to SPF results can be used in combination with other methods to
determine the final local disposition (either positive or negative of determine the final local disposition (either positive or negative of
a message. It can also be considered dispositive on its own. a message. It can also be considered dispositive on its own.
H.1. Policy For SPF Pass G.1. Policy For SPF Pass
SPF pass results can be used in combination with "white lists" of SPF pass results can be used in combination with "white lists" of
known "good" domains to bypass some or all additional pre-delivery known "good" domains to bypass some or all additional pre-delivery
email checks. Exactly which checks and how to determine appropriate email checks. Exactly which checks and how to determine appropriate
white list entries has to be based on local conditions and white list entries has to be based on local conditions and
requirements. requirements.
H.2. Policy For SPF Fail G.2. Policy For SPF Fail
SPF fail results can be used to reject messages during the SMTP SPF fail results can be used to reject messages during the SMTP
transaction based on either "MAIL FROM" or "HELO" identity results. transaction based on either "MAIL FROM" or "HELO" identity results.
This reduces resource requirements for various content filtering This reduces resource requirements for various content filtering
methods and conserves bandwidth since rejection can be done before methods and conserves bandwidth since rejection can be done before
the SMTP content is transferred. It also gives immediate feedback to the SMTP content is transferred. It also gives immediate feedback to
the sender who might then be able to resolve the issue. Due to some the sender who might then be able to resolve the issue. Due to some
of the issues described above in this section (Section 10), SPF based of the issues described above in this section (Section 10), SPF based
rejection does present some risk of rejecting legitimate email when rejection does present some risk of rejecting legitimate email when
rejecting based on "MAIL FROM" results. rejecting based on "MAIL FROM" results.
skipping to change at page 70, line 5 skipping to change at page 71, line 5
might result in email that was not authorized by the sending ADMD might result in email that was not authorized by the sending ADMD
being unknowingly delivered to end users. being unknowingly delivered to end users.
Either general approach can be used as they both leave a clear Either general approach can be used as they both leave a clear
disposition of emails. They are either delivered in some manner or disposition of emails. They are either delivered in some manner or
the sender is notified of the failure. Other dispositions such as the sender is notified of the failure. Other dispositions such as
"dropping" or deleting email after acceptance are inappropriate "dropping" or deleting email after acceptance are inappropriate
because they leave uncertainty and reduce the overall reliability and because they leave uncertainty and reduce the overall reliability and
utility of email across the Internet. utility of email across the Internet.
H.3. Policy For SPF Permerror G.3. Policy For SPF Permerror
The "permerror" result (see Section 2.6.7) indicates the SPF The "permerror" result (see Section 2.6.7) indicates the SPF
processing module at the receiver determined that the retrieved SPF processing module at the receiver determined that the retrieved SPF
policy record could not be interpreted. This gives no true policy record could not be interpreted. This gives no true
indication about the authorized use of the data found in the indication about the authorized use of the data found in the
envelope. envelope.
As with all results, implementers have a choice to make regarding As with all results, implementers have a choice to make regarding
what to do with a message that yields this result. SMTP allows only what to do with a message that yields this result. SMTP allows only
a few basic options. a few basic options.
skipping to change at page 70, line 41 skipping to change at page 71, line 41
There is of course the option placing this choice in the hands of the There is of course the option placing this choice in the hands of the
SPF verifier operator rather than the implementer since this kind of SPF verifier operator rather than the implementer since this kind of
choice is often a matter of local policy rather than a condition with choice is often a matter of local policy rather than a condition with
a universal solution, but this adds one more piece of complexity to a universal solution, but this adds one more piece of complexity to
an already non-trivial environment. an already non-trivial environment.
Both implementers and SPF verfier operators need to be cautious of Both implementers and SPF verfier operators need to be cautious of
all choices and outcomes when handling SPF results. all choices and outcomes when handling SPF results.
H.4. Policy For SPF Temperror G.4. Policy For SPF Temperror
The "temperror" result (see Section 2.6.6) indicates the SPF The "temperror" result (see Section 2.6.6) indicates the SPF
processing module at the receiver could not retrieve and SPF policy processing module at the receiver could not retrieve and SPF policy
record due to a (probably) transient condition. This gives no true record due to a (probably) transient condition. This gives no true
indication about the authorized use of the data found in the indication about the authorized use of the data found in the
envelope. envelope.
As with all results, implementers have a choice to make regarding As with all results, implementers have a choice to make regarding
what to do with a message that yields this result. SMTP allows only what to do with a message that yields this result. SMTP allows only
a few basic options. a few basic options.
skipping to change at page 72, line 5 skipping to change at page 73, line 5
There is of course the option placing this choice in the hands of the There is of course the option placing this choice in the hands of the
SPF verifier operator rather than the implementer since this kind of SPF verifier operator rather than the implementer since this kind of
choice is often a matter of local policy rather than a condition with choice is often a matter of local policy rather than a condition with
a universal solution, but this adds one more piece of complexity to a universal solution, but this adds one more piece of complexity to
an already non-trivial environment. an already non-trivial environment.
Both implementers and SPF verifier operators need to be cautious of Both implementers and SPF verifier operators need to be cautious of
all choices and outcomes when handling SPF results. all choices and outcomes when handling SPF results.
Appendix I. Protocol Status Appendix H. Protocol Status
NOTE TO RFC EDITOR: To be removed prior to publication. NOTE TO RFC EDITOR: To be removed prior to publication.
SPF has been in development since the summer of 2003 and has seen SPF has been in development since the summer of 2003 and has seen
deployment beyond the developers beginning in December 2003. The deployment beyond the developers beginning in December 2003. The
design of SPF slowly evolved until the spring of 2004 and has since design of SPF slowly evolved until the spring of 2004 and has since
stabilized. There have been quite a number of forms of SPF, some stabilized. There have been quite a number of forms of SPF, some
written up as documents, some submitted as Internet Drafts, and many written up as documents, some submitted as Internet Drafts, and many
discussed and debated in development forums. The protocol was discussed and debated in development forums. The protocol was
originally defined in [RFC4408], which this document replaces. originally defined in [RFC4408], which this document replaces.
skipping to change at page 73, line 5 skipping to change at page 74, line 5
SPF is widely deployed by large and small email providers alike. SPF is widely deployed by large and small email providers alike.
There are multiple, interoperable implementations. There are multiple, interoperable implementations.
For SPF (as documented in RFC 4408) a careful effort was made to For SPF (as documented in RFC 4408) a careful effort was made to
collect and document lessons learned and errata during the two year collect and document lessons learned and errata during the two year
period. The errata list has been stable (no new submissions) and period. The errata list has been stable (no new submissions) and
only minor protocol lessons learned were identified. Resolution of only minor protocol lessons learned were identified. Resolution of
the IESG's experiment is documented in [RFC6686]. the IESG's experiment is documented in [RFC6686].
Appendix J. Change History Appendix I. Change History
NOTE TO RFC EDITOR: Changes since RFC 4408 (to be removed prior to NOTE TO RFC EDITOR: Changes since RFC 4408 (to be removed prior to
publication) publication)
Moved to standards track Moved to standards track
Authors updated Authors updated
IESG Note regarding experimental use replaced with discussion of IESG Note regarding experimental use replaced with discussion of
results results
 End of changes. 67 change blocks. 
310 lines changed or deleted 351 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--nextPart2796661.iiajMldlZ8-- From internet-drafts@ietf.org Wed Sep 25 22:40: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 580F121F9AF0; Wed, 25 Sep 2013 22:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, 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 t99CjsNwl8Mg; Wed, 25 Sep 2013 22:40:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E511E11E8140; Wed, 25 Sep 2013 22:40:10 -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.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130926054010.30938.10948.idtracker@ietfa.amsl.com> Date: Wed, 25 Sep 2013 22:40:10 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-21.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 05:40:14 -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-21.txt Pages : 77 Date : 2013-09-25 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 ADministrative Management Domains (ADMDs) 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-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From spf2@kitterman.com Wed Sep 25 22:42:30 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 12F5B21F935A for ; Wed, 25 Sep 2013 22:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.304, 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 CPoA3khLf512 for ; Wed, 25 Sep 2013 22:42:25 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0136121F9AF0 for ; Wed, 25 Sep 2013 22:42:22 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 71E6320E40D3; Thu, 26 Sep 2013 01:42:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1380174141; bh=EzkWTx6Z7dD69nof0rh+BLAY9IvIuPa8S38mJZW1J/A=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EG3I9X7OcUqgFfxs75dRF2zpWrM1Kxou42bTUBJBzyyqBrnTNUiM5k5BIpwUFLHNd P9tT79xvN7z8vBbe+kkjzqtaXpmVWPM3RXUV8PRPu406ralFS56TLkPcuAmC76R4q7 cIrfkoqVQvmAhdY3IMKY8E+QrQLwr/mS/fr2dpmo= 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 5BF1A20E40C4; Thu, 26 Sep 2013 01:42:21 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 26 Sep 2013 01:42:21 -0400 Message-ID: <1710927.iDJcxKNrn7@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <20130926054010.30938.10948.idtracker@ietfa.amsl.com> References: <20130926054010.30938.10948.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] I-D Action: draft-ietf-spfbis-4408bis-21.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, 26 Sep 2013 05:42:30 -0000 On Wednesday, September 25, 2013 22:40:10 internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the SPF Update Working Group of > the IETF. > > Title : Sender Policy Framework (SPF) for Authorizing Use of > Domains in Email, Version 1 Author(s) : Scott Kitterman > Filename : draft-ietf-spfbis-4408bis-21.txt > Pages : 77 > Date : 2013-09-25 The is the same as the last diff I posted. Scott K From superuser@gmail.com Wed Sep 25 22:58: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 71BEA21F9228 for ; Wed, 25 Sep 2013 22:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 wZ39sSPh9xXD for ; Wed, 25 Sep 2013 22:57:59 -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 4DAF121F9346 for ; Wed, 25 Sep 2013 22:57:59 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id l18so619114wgh.28 for ; Wed, 25 Sep 2013 22:57: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=4xZ1oYl2Secfhdp6Mqe6tF9Nia4WutQKgIa6Y7Caxqs=; b=a6Uo8TthtURnbWOPMbJvmUPo97c5iyalnKk5t7AWsQF//SJtH4sqa91Pk5W8xnibOq J5nQuFYiw27H6zO36fkZoAyg30tK7ZHQyfuaF9kIqP9rfClKtFDrYzTfhIALeuEaYO+d wlUVcz+VLdhyPorio+0YDWoagUARBMbK5+CWNSq/nZVdA3jhGESZdIlANvS+to+V07LU QscTVqu8Y9RjtOYU6uzVP3VOV7YfqyPAhKO6Ih5GG6Z8tHjp6QQJsOl5tJgF/zmF/Lhm xoQH45h4LQZcQb6UL9h3AZhPUStQLxvVObbbDlfpwNtB0IECvmmDvLc0T0psM0dRW8Ee 38AQ== MIME-Version: 1.0 X-Received: by 10.194.240.197 with SMTP id wc5mr31440826wjc.23.1380175078432; Wed, 25 Sep 2013 22:57:58 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Wed, 25 Sep 2013 22:57:57 -0700 (PDT) In-Reply-To: <9521219.RXqIhQCEgb@scott-latitude-e6320> References: <20130912101511.20829.6656.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130925131612.0d8d3800@elandnews.com> <9521219.RXqIhQCEgb@scott-latitude-e6320> Date: Wed, 25 Sep 2013 22:57:57 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=089e013d19cc4725fa04e7430d60 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] Stephen Farrell's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 26 Sep 2013 05:58:00 -0000 --089e013d19cc4725fa04e7430d60 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 25, 2013 at 10:09 PM, Scott Kitterman wrote: > > - I didn't get appendix D at all - what's that do? > > > > > > I agree, we should explain it and include an example, or drop it. > Someone > > closer to the implementation and the original material than I am is > almost > > certainly able to come up with an appropriate example versus what I would > > invent. > > It made sense in context before we reorganized the document. I find it > troubling that the author of the reorganization now doesn't understand > part of > the text he shuffled around. > > I'll take a stab at adding something. > That was unnecessary, Scott. Furthermore, I didn't say I don't understand it. I merely suggested that someone (you perhaps) might already have an example in mind, perhaps from previous revisions or related work, rather than one I might contrive. > > > >> - Appendix E.1, 2nd bullet: what's that? I think it needs > > >> a reference if you want it to be understood. > > > > Same here; examples would probably be useful for all three sections. > > Generically, I agree, but it's beyond me to right it tonight. I think the > information is all there to get someone started with concepts of how > senders > can deal with avoiding SPF problems related to forwarding. These are all > unchanged from RFC 4408. I don't think we should be changing them now > after > all the reviews as it wouldn't be a small change to rework these sections > as > you suggest. > In what sense does adding an example, illustrative of the point being made, constitute "rework"? I'd be more than surprised if adding examples causes a full round of evaluation again. In any case, Stephen's comments were non-blocking (note COMMENT, not DISCUSS), so they're merely suggestions to improve or clarify. I think they're useful suggestions, but if it's really so arduous to do so, we can drop it. -MSK --089e013d19cc4725fa04e7430d60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 25, 2013 at 10:09 PM, Scott Kitterman <spf2@= kitterman.com> wrote:
> - I didn't get appendix D at all - = what's that do?
>
>
> I agree, we should explain it and include an example, or drop it. =A0S= omeone
> closer to the implementation and the original material than I am is al= most
> certainly able to come up with an appropriate example versus what I wo= uld
> invent.

It made sense in context before we reorganized the document. =A0I fin= d it
troubling that the author of the reorganization now doesn't understand = part of
the text he shuffled around.

I'll take a stab at adding something.

That was unnecessary, Scott.=A0 Furthermore, I didn't say I don'= t understand it.=A0 I merely suggested that someone (you perhaps) might alr= eady have an example in mind, perhaps from previous revisions or related wo= rk, rather than one I might contrive.
=A0

> >> - Appendix E.1, 2nd bullet: what's that? I think it needs=
> >> a reference if you want it to be understood.
>
> Same here; examples would probably be useful for all three sections.
Generically, I agree, but it's beyond me to right it tonight. =A0= I think the
information is all there to get someone started with concepts of how sender= s
can deal with avoiding SPF problems related to forwarding. =A0These are all=
unchanged from RFC 4408. =A0I don't think we should be changing them no= w after
all the reviews as it wouldn't be a small change to rework these sectio= ns as
you suggest.

In what sense does adding = an example, illustrative of the point being made, constitute "rework&q= uot;?=A0 I'd be more than surprised if adding examples causes a full ro= und of evaluation again.

In any case, Stephen's comments were non-blocking (note = COMMENT, not DISCUSS), so they're merely suggestions to improve or clar= ify.=A0 I think they're useful suggestions, but if it's really so a= rduous to do so, we can drop it.

-MSK
--089e013d19cc4725fa04e7430d60-- From spf2@kitterman.com Wed Sep 25 23:10: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 8E2F211E8147 for ; Wed, 25 Sep 2013 23:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=0.293, 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 TkEG93T8Fufx for ; Wed, 25 Sep 2013 23:10:37 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C2E8B11E8140 for ; Wed, 25 Sep 2013 23:10:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2D94220E40D3; Thu, 26 Sep 2013 02:10:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1380175833; bh=0keXUSqFBdVvsnYvPedDVO0lwsf3VKQVOTBDXCmd2l4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nD8rEK4OQ8zS4j9nFupQCeBFseipi2elH6bkkzY7PKpJQQQQLbPqQ49Jg0fwOLbX9 pesnZFcmTYFo5mrfehsIHNbHqe5TPtMNOZRlpuvdma61MjYx08plvoKDAsXz603yea mDV6Q7/P5c9CZriUUFvs4i776cRG0MEAleN8P4N0= 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 1094B20E40C4; Thu, 26 Sep 2013 02:10:32 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 26 Sep 2013 02:10:32 -0400 Message-ID: <4527957.brLT0mFqda@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-30-generic; KDE/4.10.5; i686; ; ) In-Reply-To: References: <20130912101511.20829.6656.idtracker@ietfa.amsl.com> <9521219.RXqIhQCEgb@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] Stephen Farrell's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 26 Sep 2013 06:10:42 -0000 On Wednesday, September 25, 2013 22:57:57 Murray S. Kucherawy wrote: > On Wed, Sep 25, 2013 at 10:09 PM, Scott Kitterman wrote: > > > - I didn't get appendix D at all - what's that do? > > > > > > > > > I agree, we should explain it and include an example, or drop it. > > > > Someone > > > > > closer to the implementation and the original material than I am is > > > > almost > > > > > certainly able to come up with an appropriate example versus what I > > > would > > > invent. > > > > It made sense in context before we reorganized the document. I find it > > troubling that the author of the reorganization now doesn't understand > > part of > > the text he shuffled around. > > > > I'll take a stab at adding something. > > That was unnecessary, Scott. Furthermore, I didn't say I don't understand > it. I merely suggested that someone (you perhaps) might already have an > example in mind, perhaps from previous revisions or related work, rather > than one I might contrive. > > > > >> - Appendix E.1, 2nd bullet: what's that? I think it needs > > > >> a reference if you want it to be understood. > > > > > > Same here; examples would probably be useful for all three sections. > > > > Generically, I agree, but it's beyond me to right it tonight. I think the > > information is all there to get someone started with concepts of how > > senders > > can deal with avoiding SPF problems related to forwarding. These are all > > unchanged from RFC 4408. I don't think we should be changing them now > > after > > all the reviews as it wouldn't be a small change to rework these sections > > as > > you suggest. > > In what sense does adding an example, illustrative of the point being made, > constitute "rework"? I'd be more than surprised if adding examples causes > a full round of evaluation again. > > In any case, Stephen's comments were non-blocking (note COMMENT, not > DISCUSS), so they're merely suggestions to improve or clarify. I think > they're useful suggestions, but if it's really so arduous to do so, we can > drop it. It's probably me being tired. Sorry. I disagree with removing text at this point that we've carried forward from RFC 4408. I couldn't think of a way to come up with short examples. It's not that what's there needs to be changed, but that an example that would make it easy to understand would take a lot of text that I'm just too tired to write tonight. Maybe when I'm better rested it'll be clearer to me how to do it in a more simple manner. Scott K From sm@elandsys.com Thu Sep 26 08:06: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 4196B21F9998; Thu, 26 Sep 2013 08:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 S4yeD+nvMmtu; Thu, 26 Sep 2013 08:06:43 -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 89CA011E8107; Thu, 26 Sep 2013 08:05:43 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.160]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8QF5BM4002689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Sep 2013 08:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1380207926; bh=VYt4/havLv2cJot5haBEXVM0jHRYoUM1lMB045mlgcA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0oVVc7VbpfSLMYISPt9vbDHMwB3lSfCdJcDhB8SK4X4X1GrhO/oo+XKKXnhN7Lnf4 LdjT2j2efvSenbqaP26Tn6jh1jOaGQ/wHRISbSi+6+RLuyTgvv7JH/uNCRnJeOzf/K eSfe0PRnAk3r+ze6z9c+GnnpmVxMuxhJl51XBgIw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1380207926; i=@elandsys.com; bh=VYt4/havLv2cJot5haBEXVM0jHRYoUM1lMB045mlgcA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=B0/ceDh7Fk1OtX8orht+oM5TCw49d+RkZ0/7Zt1s3GWjd9u1+b9uyfH7Gj/QnYZv5 nrYAn0KFswfV04ZxYXn7WC9pzCgOSyZoHZ40b06c2G/Ob0+sgpT+rT6PiGU/pTmvgX b6TF5lli34qGU4f56ohxoz58pxpKf0TvukLcRRVg= Message-Id: <6.2.5.6.2.20130926075151.0ec9f198@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 26 Sep 2013 08:05:01 -0700 To: "Barry Leiba" , The IESG From: S Moonesamy In-Reply-To: <20130926143718.29653.4925.idtracker@ietfa.amsl.com> References: <20130926143718.29653.4925.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, Scott Kitterman Subject: Re: [spfbis] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-21: (with DISCUSS and COMMENT) 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, 26 Sep 2013 15:06:44 -0000 Hi Barry, At 07:37 26-09-2013, Barry Leiba wrote: >Barry Leiba has entered the following ballot position for >draft-ietf-spfbis-4408bis-21: Discuss [snip] >DISCUSS: >---------------------------------------------------------------------- > >UPDATED for -21: It seems that resolutions for the DISCUSS points got >left out of the update. :-( >------------------------------------------------------- >I have two very small points that I think are unclear, and important >enough that we have to get them right, both regarding the check_host() >function. These should be really easy to clear up: > >-- Section 4.6 -- > > The check_host() function parses and interprets the SPF record to > find a result for the current test. If there are any syntax errors > anywhere in the record, check_host() returns immediately with the > result "permerror", without further interpretation. > >I think you're trying to say that syntax checking is done before any >evaluation, but you aren't saying it. It matters, because >implementations that make different choices in that regard won't get the >same results from check_host() in all cases, as they're required to. >Maybe this?: > >NEW > The check_host() function parses and interprets the SPF record to > find a result for the current test. The syntax of the record is > validated first, and if there are any syntax errors anywhere in the > record, check_host() returns immediately with the result "permerror", > without further interpretation or evaluation. >END Scott Kitterman agreed to the proposed text previously ( http://www.ietf.org/mail-archive/web/spfbis/current/msg04124.html ). What follows is the change to address to DISCUSS: OLD The check_host() function parses and interprets the SPF record to find a result for the current test. If there are any syntax errors anywhere in the record, check_host() returns immediately with the result "permerror", without further interpretation. END NEW The check_host() function parses and interprets the SPF record to find a result for the current test. The syntax of the record is validated first, and if there are any syntax errors anywhere in the record, check_host() returns immediately with the result "permerror", without further interpretation or evaluation. END >-- Section 5.5 -- > >I have to say that I'm not happy about the pseudocode here: what >situation are we in when the pseudocode differs from the text? Which >wins? > >I already see a case where they differ: the new pseudocode says "if more >than 10 sending-domain_names are found, use at most 10", and there's >nothing of the sort in the text. > >Does the working group really think there's enough value in having >pseudocode there that it's worth saying the same thing twice and relying >on them to be truly the same? And is it really worth it for mechanism >that's not recommended for use? > >I strongly suggest making sure that the text says what you want it to, >and removing the pseudocode. Scott Kitterman agreed that the pseudocode can be removed ( http://www.ietf.org/mail-archive/web/spfbis/current/msg04124.html ). The OLD text is below; there isn't any NEW text as it is a removal. OLD Pseudocode: sending-domain_names := ptr_lookup(sending-host_IP); if more than 10 sending-domain_names are found, use at most 10. for each name in (sending-domain_names) { IP_addresses := a_lookup(name); if the sending-domain_IP is one of the IP_addresses { validated-sending-domain_names += name; } } for each name in (validated-sending-domain_names) { if name ends in , return match. if name is , return match. } return no-match. END Regards, S. Moonesamy (as document shepherd) From presnick@qti.qualcomm.com Thu Sep 26 08:10: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 B33A621F92B9; Thu, 26 Sep 2013 08:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 g0x49JBQyb+r; Thu, 26 Sep 2013 08:10:15 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id EC0DC21E8051; Thu, 26 Sep 2013 08:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1380208125; x=1411744125; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PTzcIBvw4Go2u8uHrbgmD4DYk6dlwio+qa5Q7kdfnG8=; b=PSGl6D5QIQyp6dVOA8UcvVT5NyKF6WsGBc5ARcbUbBvPcRSJeJsG36UE rzNMmB4dK/6+7/fZoP+pEqhevswQ4p3sSHuAnRKtonXsiNHhUF1IhSCcp N2u8ItWJIQfZfXZdkSvyJiJJrXkNS9A6du+XdSb2C0XF1S27paO2ngGJp E=; X-IronPort-AV: E=McAfee;i="5400,1158,7209"; a="52283044" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 26 Sep 2013 08:08:42 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7209"; a="20214776" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 26 Sep 2013 08:08:41 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Sep 2013 08:08:41 -0700 Message-ID: <52444DF7.5070504@qti.qualcomm.com> Date: Thu, 26 Sep 2013 10:08:39 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: S Moonesamy References: <20130926143718.29653.4925.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130926075151.0ec9f198@elandnews.com> In-Reply-To: <6.2.5.6.2.20130926075151.0ec9f198@elandnews.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG , spfbis-chairs@tools.ietf.org, Barry Leiba , Scott Kitterman Subject: Re: [spfbis] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-21: (with DISCUSS and COMMENT) 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, 26 Sep 2013 15:10:21 -0000 X-List-Received-Date: Thu, 26 Sep 2013 15:10:21 -0000 Thanks SM. I will put these in an RFC Editor Note so that Barry can clear. pr On 9/26/13 10:05 AM, S Moonesamy wrote: > Hi Barry, > At 07:37 26-09-2013, Barry Leiba wrote: >> Barry Leiba has entered the following ballot position for >> draft-ietf-spfbis-4408bis-21: Discuss > > [snip] > >> DISCUSS: >> ---------------------------------------------------------------------- >> >> UPDATED for -21: It seems that resolutions for the DISCUSS points got >> left out of the update. :-( >> ------------------------------------------------------- >> I have two very small points that I think are unclear, and important >> enough that we have to get them right, both regarding the check_host() >> function. These should be really easy to clear up: >> >> -- Section 4.6 -- >> >> The check_host() function parses and interprets the SPF record to >> find a result for the current test. If there are any syntax errors >> anywhere in the record, check_host() returns immediately with the >> result "permerror", without further interpretation. >> >> I think you're trying to say that syntax checking is done before any >> evaluation, but you aren't saying it. It matters, because >> implementations that make different choices in that regard won't get the >> same results from check_host() in all cases, as they're required to. >> Maybe this?: >> >> NEW >> The check_host() function parses and interprets the SPF record to >> find a result for the current test. The syntax of the record is >> validated first, and if there are any syntax errors anywhere in the >> record, check_host() returns immediately with the result "permerror", >> without further interpretation or evaluation. >> END > > Scott Kitterman agreed to the proposed text previously ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg04124.html ). > What follows is the change to address to DISCUSS: > > OLD > > The check_host() function parses and interprets the SPF record to > find a result for the current test. If there are any syntax errors > anywhere in the record, check_host() returns immediately with the > result "permerror", without further interpretation. > > END > > NEW > The check_host() function parses and interprets the SPF record to > find a result for the current test. The syntax of the record is > validated first, and if there are any syntax errors anywhere in the > record, check_host() returns immediately with the result "permerror", > without further interpretation or evaluation. > END > >> -- Section 5.5 -- >> >> I have to say that I'm not happy about the pseudocode here: what >> situation are we in when the pseudocode differs from the text? Which >> wins? >> >> I already see a case where they differ: the new pseudocode says "if more >> than 10 sending-domain_names are found, use at most 10", and there's >> nothing of the sort in the text. >> >> Does the working group really think there's enough value in having >> pseudocode there that it's worth saying the same thing twice and relying >> on them to be truly the same? And is it really worth it for mechanism >> that's not recommended for use? >> >> I strongly suggest making sure that the text says what you want it to, >> and removing the pseudocode. > > Scott Kitterman agreed that the pseudocode can be removed ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg04124.html ). > The OLD text is below; there isn't any NEW text as it is a removal. > > OLD > > Pseudocode: > > sending-domain_names := ptr_lookup(sending-host_IP); > if more than 10 sending-domain_names are found, use at most 10. > for each name in (sending-domain_names) { > IP_addresses := a_lookup(name); > if the sending-domain_IP is one of the IP_addresses { > validated-sending-domain_names += name; > } > } > > for each name in (validated-sending-domain_names) { > if name ends in , return match. > if name is , return match. > } > return no-match. > END > > Regards, > S. Moonesamy (as document shepherd) > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From hsantos@isdg.net Thu Sep 26 08:50: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 F1E2521E80A5 for ; Thu, 26 Sep 2013 08:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.646 X-Spam-Level: X-Spam-Status: No, score=-102.646 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=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 1tTLmeuTaKaa for ; Thu, 26 Sep 2013 08:50:52 -0700 (PDT) Received: from mail.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5982321E80A7 for ; Thu, 26 Sep 2013 08:49:15 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5046; t=1380210545; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=/J4pPw7bAa//f99UshQmi1flYeE=; b=JoPJC+2gBKeosuRq7nwp tDJDRDAqp02bTBWVUz3IaYVjADUFkHD4YLWiFRMiH4QtDGc+/0i85MnIAYwwmCNh H4weh2X9gNtpUiIgWDJ7FVHoLz4NmVBPAXpHzqDvXF+rGc5oCSetqahjQwLAydU4 B/XnH/tX0lwMD08vKf7Yu2g= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 26 Sep 2013 11:49:05 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2378057918.16763.4364; Thu, 26 Sep 2013 11:49:04 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5046; t=1380210170; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=vMv3XmL 950zhSyYk9OrJ64rwylTbYd6Wct9tM5QmGK4=; b=smrHI3PZI+fOvhPHQAdYTY/ FtpxwEkyDSUqz1RNHm57u6Ig/Tcr10aez7xlrH27I54/226eVJbeLBlJngPtwsab pkRUUf6VJnARc3aZO2+4g0gr/lBljhmmQolZEvSTzl/+tYcLyK5ePynojQddZ69r v/NwbM8NaOn2/yNmj79Y= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 26 Sep 2013 11:42:50 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1824450831.9.9324; Thu, 26 Sep 2013 11:42:49 -0400 Message-ID: <5244576D.4020905@isdg.net> Date: Thu, 26 Sep 2013 11:49:01 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: S Moonesamy References: <20130926143718.29653.4925.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130926075151.0ec9f198@elandnews.com> In-Reply-To: <6.2.5.6.2.20130926075151.0ec9f198@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis@tools.ietf.org, The IESG , spfbis-chairs@tools.ietf.org, Barry Leiba , Scott Kitterman Subject: Re: [spfbis] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-21: (with DISCUSS and COMMENT) 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, 26 Sep 2013 15:50:54 -0000 On 9/26/2013 11:05 AM, S Moonesamy wrote: > OLD > > The check_host() function parses and interprets the SPF record to > find a result for the current test. If there are any syntax errors > anywhere in the record, check_host() returns immediately with the > result "permerror", without further interpretation. > > END > > NEW > The check_host() function parses and interprets the SPF record to > find a result for the current test. The syntax of the record is > validated first, and if there are any syntax errors anywhere in the > record, check_host() returns immediately with the result "permerror", > without further interpretation or evaluation. > END For the record, our implementation does not have what is effectively described above as a two-pass parser. IMO, it is technically a waste and not optimal in the long run (of continued operations) -- most records are not invalid. And its also a implementation method, not required to be a two-pass parser. Probably, what you mean with the second sentence: The syntax of a directive or mechanism is checked first. If there are any syntax errors, check_host() returns immediately with the result "permerror", without further interpretation or evaluation. > >> -- Section 5.5 -- >> >> I have to say that I'm not happy about the pseudocode here: what >> situation are we in when the pseudocode differs from the text? Which >> wins? >> >> I already see a case where they differ: the new pseudocode says "if >> more >> than 10 sending-domain_names are found, use at most 10", and there's >> nothing of the sort in the text. >> >> Does the working group really think there's enough value in having >> pseudocode there that it's worth saying the same thing twice and >> relying >> on them to be truly the same? And is it really worth it for mechanism >> that's not recommended for use? >> >> I strongly suggest making sure that the text says what you want it to, >> and removing the pseudocode. > > Scott Kitterman agreed that the pseudocode can be removed ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg04124.html ). > The OLD text is below; there isn't any NEW text as it is a removal. > > OLD > > Pseudocode: > > sending-domain_names := ptr_lookup(sending-host_IP); > if more than 10 sending-domain_names are found, use at most 10. > for each name in (sending-domain_names) { > IP_addresses := a_lookup(name); > if the sending-domain_IP is one of the IP_addresses { > validated-sending-domain_names += name; > } > } > > for each name in (validated-sending-domain_names) { > if name ends in , return match. > if name is , return match. > } > return no-match. > END hmmmm, to tell you the truth I though the "10" limit was on the number of total lookups, not in the the BUFFER storage restrictions on a PTR lookup. I don't think you can tell DNS server "please only give me 10" PTR query records, so the overhead concern "to avoid unreasonable load on the DNS" stated in section 4.6.4 would not be correct. However, there could be limits to save recursion stack limits if its not dynamically allocated implementation design. Also more importantly, if you need to single source the DNS API interface (for local caching designs) across different applications, I found it to be better to increase the potential records returned (allocate more space) otherwise you can get false positive/negative under SPF. In fact, for historical reasons, our records for 208.247.131.9 are 14 records. M:\rfc\spf>nslookup -query=ptr 208.247.131.9 Non-authoritative answer: 9.131.247.208.in-addr.arpa name = ntbbs.santronics.com 9.131.247.208.in-addr.arpa name = mail.catinthebox.net 9.131.247.208.in-addr.arpa name = ftp.catinthebox.net 9.131.247.208.in-addr.arpa name = news.winserver.com 9.131.247.208.in-addr.arpa name = listserv.winserver.com 9.131.247.208.in-addr.arpa name = groups.winserver.com 9.131.247.208.in-addr.arpa name = mail.santronics.com 9.131.247.208.in-addr.arpa name = mail.winserver.com 9.131.247.208.in-addr.arpa name = ntbbs.winserver.com 9.131.247.208.in-addr.arpa name = winserver.com 9.131.247.208.in-addr.arpa name = catinthebox.net 9.131.247.208.in-addr.arpa name = secure.winserver.com 9.131.247.208.in-addr.arpa name = pop3.winserver.com 9.131.247.208.in-addr.arpa name = dkim.winserver.com I'm sure we are not the only server with this historical layout. I think don't the issue is related to the concept of deprecating PTR publishing. SPF MUST support the PTR logic. No parser can get around that complaint protocol design requirement. But we can do is save the overhead and minimize wasted processing because SPF parser limited the PTR resultant record to 10. In this case, allow implementators to set their own limits because a) we can afford it today, and b) there is no DNS concern in this regard (can't set a limit to 10 to query DNS). I thought the "10 limit" was for total DNS queries. -- HLS From superuser@gmail.com Mon Sep 30 22:46: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 3D18321F8948 for ; Mon, 30 Sep 2013 22:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 qOesAJ9AK-GF for ; Mon, 30 Sep 2013 22:46:09 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id B131A21F8BFD for ; Mon, 30 Sep 2013 22:46:07 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id ez12so4997984wid.9 for ; Mon, 30 Sep 2013 22:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=29swkkKVT6Awwxi6a0qteMvSByQblbzVCCqQlKDf9KQ=; b=ke5iGg6z3/sD9bk37IZeXxyAaqkSICPjg0/IRleNduJkmrltyHGbFnX5+Po2KZIXKW /D2vdRErYyLjdj9K86oIiDpz8jkwIxKR8PKv++1HeCV42YFKzphnlLz+lxdPA9ef7SgE V3XWpOA7TCGQho6tA1T9VRcQC+FakZtz6Wu9szrgk80DHJVtp9JkK6GzWff1WAVR7FdD 9xMj3oo8KgLErEYSXBZQx1S/1ppPFrh5H7wZuHyt5CZRuEegZwO9eeyPQHQI8npk0VYx +plEipD+N9QLd9PLAhIDq9SO4vmvj/23cafS2HcDc5SfEiqduZNix6i7hk1b4Zrpn2hR XADg== MIME-Version: 1.0 X-Received: by 10.194.104.42 with SMTP id gb10mr20869644wjb.16.1380606364237; Mon, 30 Sep 2013 22:46:04 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Mon, 30 Sep 2013 22:46:04 -0700 (PDT) Date: Mon, 30 Sep 2013 22:46:04 -0700 Message-ID: From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf19852ea46dd04e7a7773f Subject: [spfbis] Too many includes! 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, 01 Oct 2013 05:46:10 -0000 --047d7bf19852ea46dd04e7a7773f Content-Type: text/plain; charset=ISO-8859-1 For the second time in recent memory, I'm being consulted about an issue where some outsourced mail service provider has its customers publish an SPF policy that has an "include:" referring to some name the service provider has defined. That include refers to a number of other includes, which in turn contain as many "ip4" rules as will fit in an UDP DNS reply. This consumes most of the ten lookups the overall limit allows. I'm concerned that this is going to become a pervasive problem. In offlist conversations the consensus has clearly been "Yeah, don't do that." I wonder, though, if we need to say something more formal, be it inside spfbis or elsewhere. It seems to me that if we do decide we want to say something someplace, we need to come up with "Don't do that, do this other thing" and give at least one alternative to do the same thing. Do we need to find some way to provide some advice here? -MSK --047d7bf19852ea46dd04e7a7773f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For the second time in recent memory, I'm be= ing consulted about an issue where some outsourced mail service provider ha= s its customers publish an SPF policy that has an "include:" refe= rring to some name the service provider has defined.=A0 That include refers= to a number of other includes, which in turn contain as many "ip4&quo= t; rules as will fit in an UDP DNS reply.=A0 This consumes most of the ten = lookups the overall limit allows.

I'm concerned that this is going to become a pervasive proble= m.=A0 In offlist conversations the consensus has clearly been "Yeah, d= on't do that."=A0 I wonder, though, if we need to say something mo= re formal, be it inside spfbis or elsewhere.=A0 It seems to me that if we d= o decide we want to say something someplace, we need to come up with "= Don't do that, do this other thing" and give at least one alternat= ive to do the same thing.

Do we need to find some way to provide some advice here?
=
-MSK
--047d7bf19852ea46dd04e7a7773f-- From spf2@kitterman.com Mon Sep 30 22:57: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 C6D1721F92DA for ; Mon, 30 Sep 2013 22:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.282, 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 ShvspqZmGvGH for ; Mon, 30 Sep 2013 22:57:49 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFF321F853A for ; Mon, 30 Sep 2013 22:57:49 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id ADF34D04081; Tue, 1 Oct 2013 01:57:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1380607067; bh=+WlrzcBK+NGGWR9O2qct7AWN6UPJKa0Xeii9jLG80tc=; h=In-Reply-To:References:Subject:From:Date:To:From; b=FwtvaKzTPpsI3riDlxszwFjiih5NXVGY29FCLJxjczdCv7Wpvm5IBPcX5yTOjJMxw gJjYzpPgp/Pa6njhkmi7KXuAdy6xyZkkirv7gVw+32S49mCJ3cuE95D+KBpYXoyj2Z kxEeXVMytDsiRxE+mWjSPVpC/ccY7ZlnTZwUfpoE= Received: from [192.168.111.106] (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 56C88D0405E; Tue, 1 Oct 2013 01:57:47 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 01 Oct 2013 01:57:41 -0400 To: "spfbis@ietf.org" Message-ID: <2594c731-a8c6-4bc3-95d9-891caf8e9bd8@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Too many includes! 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, 01 Oct 2013 05:57:49 -0000 "Murray S. Kucherawy" wrote: >For the second time in recent memory, I'm being consulted about an >issue >where some outsourced mail service provider has its customers publish >an >SPF policy that has an "include:" referring to some name the service >provider has defined. That include refers to a number of other >includes, >which in turn contain as many "ip4" rules as will fit in an UDP DNS >reply. >This consumes most of the ten lookups the overall limit allows. > >I'm concerned that this is going to become a pervasive problem. In >offlist >conversations the consensus has clearly been "Yeah, don't do that." I >wonder, though, if we need to say something more formal, be it inside >spfbis or elsewhere. It seems to me that if we do decide we want to >say >something someplace, we need to come up with "Don't do that, do this >other >thing" and give at least one alternative to do the same thing. > >Do we need to find some way to provide some advice here? I'll be glad to add it to the FAQ or other appropriate place on openspf.org if someone wants to write something up. It's certainly come up before. Scott K