From doug.mtview@gmail.com Tue Oct 1 00:55: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 36C7721F93BF; Tue, 1 Oct 2013 00:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 rVyedfpzSkLW; Tue, 1 Oct 2013 00:55:37 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7357F21F89FF; Tue, 1 Oct 2013 00:55:37 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id x10so6864183pdj.15 for ; Tue, 01 Oct 2013 00:55:37 -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=xzGTk/YHvuVICyRNxMld0kiT+f/pUWjAspyQ3Zh0yrw=; b=0WxWXf9gdVkde3OdpzcR2/CB8Miovzllez5zRTfqPa1Xelq6fpVusPdlOkdyuO5JAe iYVCY8F3w2Q7JS6eqGL8jlufhMLKqboF87WCzLdn1960lOfh1kspFvZN6k1xhpJrEU2x zr0PqN+m97b29Bu+j9cBmi2xY+fMSYKaFYdxo/gZtF6X7i1H0fsxq1+bB3ui2ka/5hNt EmwTC9qqpiFfogIfcsOjf44Iq39VOGIe+7Gu49+GmNHz3wBz2TMVeMcJnLNYgMLARrRI qlyncEsyNjBz6ljXqYyXc/ttcfcHRozXvsdIiSJgt3zGE8VPHJX8nP/Zqv809tGkyNlW YaYA== X-Received: by 10.68.189.163 with SMTP id gj3mr28063389pbc.102.1380614137146; Tue, 01 Oct 2013 00:55:37 -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 k4sm5241939pbd.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Oct 2013 00:55:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Douglas Otis In-Reply-To: <20130912150227.57069.qmail@joyce.lan> Date: Tue, 1 Oct 2013 00:55:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <620FDB21-B8AD-41C4-BA4F-1616D8425B98@gmail.com> References: <20130912150227.57069.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1510) Cc: spfbis@ietf.org, "dnsext@ietf.org Group" 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: Tue, 01 Oct 2013 07:55:38 -0000 Dear John, See comments inline. =20 On Sep 12, 2013, at 8:02 AM, John Levine wrote: > 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. For the record, I would like to strongly disagree with this statement. = SPFbis represents a significant change in how DNS and DNSSEC can be = abused and network amplifications achieved. =20 SPF introduces predefined "mechanisms" in conjunction with "macros" that = operate on message elements rather than just DNS resources. These = "mechanisms" combine with "macros" (if actually implemented by large = providers) to allow any compromised system to leverage cached Resource = Records to induce recipients into making more than 222 uniquely directed = DNS transactions derived from check_host() message elements (111 DNS = transactions for each of the two SPFbis check_host() message elements). = NO MITIGATION of this type of threat is possible without ignoring SPFbis = records containing "macros". This mitigation remains practical only by = email providers (not DNS operators) since only 0.00053 of the domains = publish records with a "macro" feature. =20 When DNSSEC is used, network amplification calculations change = dramatically. For example, the "PTR" or "MX" "mechanism" can be invoked = 10 times where each instance can resolve addresses for 10 RRs. For the = PTR mechanism, each invocation is permitted to return any number of PTR = RRs where the upper bound on the response size could be 8x larger. = While SPFbis recommends against their publication, there is no = recommendation against these "mechanisms" being processed by recipients = which is where the threat is realized. The complexity is represented = by the target modulation permitted by SPFbis "macros". RFC4033 does not = offer any mitigation for this type of threat which becomes significantly = worse when the DNS Message constraint changes from 512 octets and each = message can then cause 222 massive UDP DNS transactions against two = likely unrelated names constructed by macro expansion that SPFbis = recommends be resolved. > On the other hand, it's not a big deal, if it'll make the discuss go = away, that's fine. I don't think any DNS abuse mitigation strategy would be effective = against SPFbis misuse of DNS. SPFbis offers unknown entities = significant access to DNS resources that can not be blocked by BCP38, = rate limiting, or even be identified by RR Type or naming convention. = Sending a 1KB message could result in network amplifications = significantly greater than that provided by source address spoofing. = The reason this is not likely an issue is that providers are not = processing SPF records that contain macros because they may prefetch SPF = records as a means of whitelisting which precludes use of "macros". If = so, "macros" may introduce significant interchange issues. Too bad no = survey was made regarding the publication or the processing of SPFbis = "macros".=20 Regards, Douglas Otis >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> 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. >>>=20 >>> I'll suggest: >>>=20 >>> and see RFC 4033 for a countermeasure. >>>=20 >>> and leave it to the SPFBIS WG to comment on the above. >>=20 >> That would work for me. > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From sm@elandsys.com Tue Oct 1 02:57: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 9942D21F8749 for ; Tue, 1 Oct 2013 02:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 hqSxUdsPE8A6 for ; Tue, 1 Oct 2013 02:57: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 1F04521F90CC for ; Tue, 1 Oct 2013 02:57:30 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.129.107]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r919v7ei002774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Oct 2013 02:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1380621444; bh=/NEjBPnnTXakQtAoaTBzsaCdLQkV/awhTXmXgpTkCWA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=x6gQEpYrVSHXf94tSbOft0FO61HTXnP4bWne/ZGB1/uw3bH9N4C6gnpFHjcyNsXqf rtnv1Q+D+vuL48eoNfDeyLVL3OvoPSVxNUJG4jZzIXMbWVq4opQv66T3120ThFCUXB /WbGn8z/AGjAybFcuhWhIsv4juR80KmcPhd4Hsew= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1380621444; i=@elandsys.com; bh=/NEjBPnnTXakQtAoaTBzsaCdLQkV/awhTXmXgpTkCWA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=AHD7YsrqtQg0rC386ZV14QU/dyLc2PvPpRYBfc3lB4QlCGJ9dbdKNFyppp5SEFVIX HWlrcFhZuHfvMAP1Oh1okpI90CsR4u6lhiQW/kz/XRJ9jMntsO6DaMmiBmbjHGXkDs YCHgouMXBmdXu/CpD8x8SdzMYrp3acb5Y+UYT3QE= Message-Id: <6.2.5.6.2.20131001024332.0c9271e0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 01 Oct 2013 02:55:20 -0700 To: "Murray S. Kucherawy" 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] 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 09:57:39 -0000 Hi Murray, At 22:46 30-09-2013, 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. Ok. >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? If there is a concern that this is going to be a pervasive problem my suggestion would be to carefully consider the matter and make the argument. It is suggested that factual information be provided so that people can verify for themselves and form an opinion. Regards, S. Moonesamy (as document shepherd) From hsantos@isdg.net Tue Oct 1 04:45: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 5538721F8A38 for ; Tue, 1 Oct 2013 04:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.645 X-Spam-Level: X-Spam-Status: No, score=-102.645 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 IG8h5LN6a2Uw for ; Tue, 1 Oct 2013 04:45:26 -0700 (PDT) Received: from ntbbs.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 076FA21F9FA2 for ; Tue, 1 Oct 2013 04:45:22 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2856; t=1380627915; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=8tdL6vEZeMzBSmfrAku8zYs+xPw=; b=NThYZwOXWDbNrx8CM7/E ljddNk0Exsdp4nLMlcj6WtsMtPxFymwCm9EoVzDXfIyQwJuefBWrzA3UQvn2EIYx wflLouqR5WWPEUy/t5MToOzDktLFE3dtjVgJjZ/O4bU5R4jElqvpXj+9zGhgaYu5 JozwosfeFZNz011nhmjNPvk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 01 Oct 2013 07:45:15 -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 2795422978.1978.5440; Tue, 01 Oct 2013 07:45:14 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2856; t=1380627532; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=vkGIKdM nHsuSO7wAXjMokJtZHS+VSFaC6IdAY2ttXao=; b=pwxWtTRdu+OF3N4Vt/vgzbT 1KP1mCjcoxtRQFJwmCQXxcQl9igBA6JndXP1OoDdx9s1zIDSMCA208X56SgjiE8X ADETTz8IxxGiLfvX8LhbwlylcN46N++8Oemq+9/+uIjqBju6nxr1+8Y0FrEscHoj JxrmYOLYP++8pVEn8yG8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 01 Oct 2013 07:38:52 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2241812784.9.6640; Tue, 01 Oct 2013 07:38:51 -0400 Message-ID: <524AB5C8.1080408@isdg.net> Date: Tue, 01 Oct 2013 07:45:12 -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: <6.2.5.6.2.20131001024332.0c9271e0@resistor.net> In-Reply-To: <6.2.5.6.2.20131001024332.0c9271e0@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org 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 11:45:32 -0000 This was known -- stated in the group in the past for SPFBIS consideration and unfortunately, ignored, skipped, went over heads, what have you. Too bad. However, it is isolated to certain hosting domains only. It is not a pervasive thing. The main issue is the REDUNDANT WASTE when done with SPF relaxed policies. So even if its just 8, 9 or limited to 10 calls, when done by common domains (most of the messages arriving at your receiver), then its all wasteful. It should of been added with some guideline but I don't feel its warrants a change at this point. It will go to the whole idea of how many INCLUDES is too much and the worth (type of policies) of the the calls. It could be that original receiver operations didn't have a limit and then added one (like us when RFC4408 was finally done). The SPF limit is 10 and we have that as a global option for operators to change. But in theory, technically, it has to be a learned process PER HOST and what I am pointing out it is limited to only certain hosting domains. At best, what can be stated is that "SPF service providers" SHOULD CONSIDER the worth of the calls. Don't do this if the end results are NEUTRAL (?ALL) or even SOFTFAIL (~ALL), although the latter does offer some worth. On 10/1/2013 5:55 AM, S Moonesamy wrote: > Hi Murray, > At 22:46 30-09-2013, 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. > > Ok. > >> 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? > > If there is a concern that this is going to be a pervasive problem my > suggestion would be to carefully consider the matter and make the > argument. It is suggested that factual information be provided so > that people can verify for themselves and form an opinion. > > Regards, > S. Moonesamy (as document shepherd) > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From superuser@gmail.com Tue Oct 1 05:11: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 058E821E80AA for ; Tue, 1 Oct 2013 05:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[AWL=-1.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LOAN=2.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 J5k7S5k5jeSH for ; Tue, 1 Oct 2013 05:11:05 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id BC94C21E80AC for ; Tue, 1 Oct 2013 05:11:02 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id n12so7223649wgh.27 for ; Tue, 01 Oct 2013 05:11:01 -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=GKeZyYSTJTB58AuXUZnlyWLcilSA2ZUZgKzXPxzNDxQ=; b=W3rx3CFww/LlqJIXGvuFp84m+T6ZnoFDS1uwaiZOhw+LZRQWp2OwtR04yBNr4jXJf2 jLLtwqyqfHcX58TUEMrpQOmkEhzEzUunc56A28SIjFhL1h+6bK5PqTQhv62swRHHGKJs 13mqEPscFK5JtPrmxPIreyE86FKD0VBR+U5eMfqcdKjaN1Sq9YdsL6e97fF2Dxpq5l2s QOLdXZwSD50BgMn7S+Tg4qYAZ5NRXEdVK3jftAJSwdOMIU3PCUki6J/r/ibQPTOtR9bS EcwGzXwwJjthcfsfJu19wotAIBB7BA+HXnNXjBK3erNPGUCcQYZhgSO3M/JbkUS/gMkt ataQ== MIME-Version: 1.0 X-Received: by 10.194.94.101 with SMTP id db5mr745095wjb.67.1380629461921; Tue, 01 Oct 2013 05:11:01 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Tue, 1 Oct 2013 05:11:01 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20131001024332.0c9271e0@resistor.net> References: <6.2.5.6.2.20131001024332.0c9271e0@resistor.net> Date: Tue, 1 Oct 2013 05:11:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=047d7beb93b4a4f74404e7acd8e6 Cc: "spfbis@ietf.org" 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 12:11:15 -0000 --047d7beb93b4a4f74404e7acd8e6 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 1, 2013 at 2:55 AM, S Moonesamy wrote: > > Do we need to find some way to provide some advice here? >> > > If there is a concern that this is going to be a pervasive problem my > suggestion would be to carefully consider the matter and make the argument. > It is suggested that factual information be provided so that people can > verify for themselves and form an opinion. > > I think Scott's idea of doing a FAQ entry is the most reasonable path forward here. This doesn't seem to be serious enough to warrant a new document or a modification to the bis draft at this stage. Given the size and popularity of the operators I've heard about, however, this is going to be a pain point for more than just the couple of operators I've heard from. Another issue that was suggested: If the first party's SPF record includes two or more others others, and those in turn include others but some of those overlap, should the redundant includes be counted against the 10? I don't agree that this is a configurable limit. The limit is fixed at 10; an implementation that allows the limit to be adjusted is non-standard and not interoperable. Have I misunderstood something here? -MSK --047d7beb93b4a4f74404e7acd8e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 1, 2013 at 2:55 AM, S Moonesamy <sm+ietf@e= landsys.com> wrote:

Do we need to find some way to provide some advice here?

If there is a concern that this is going to be a pervasive problem my sugge= stion would be to carefully consider the matter and make the argument. =A0I= t is suggested that factual information be provided so that people can veri= fy for themselves and form an opinion.


I think Scott's idea of doing a FA= Q entry is the most reasonable path forward here.=A0 This doesn't seem = to be serious enough to warrant a new document or a modification to the bis= draft at this stage.=A0 Given the size and popularity of the operators I&#= 39;ve heard about, however, this is going to be a pain point for more than = just the couple of operators I've heard from.

Another issue that was suggested: If the first party's S= PF record includes two or more others others, and those in turn include oth= ers but some of those overlap, should the redundant includes be counted aga= inst the 10?

I don't agree that this is a configurable limit.=A0 The = limit is fixed at 10; an implementation that allows the limit to be adjuste= d is non-standard and not interoperable.=A0 Have I misunderstood something = here?

-MSK
--047d7beb93b4a4f74404e7acd8e6-- From hsantos@isdg.net Tue Oct 1 05:44: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 70C6B21E813F for ; Tue, 1 Oct 2013 05:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.06 X-Spam-Level: X-Spam-Status: No, score=-101.06 tagged_above=-999 required=5 tests=[AWL=-1.625, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MANGLED_LOAN=2.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 cPOhBG7udTZK for ; Tue, 1 Oct 2013 05:44:14 -0700 (PDT) Received: from ntbbs.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 841E721F9FAC for ; Tue, 1 Oct 2013 05:44:13 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1258; t=1380631450; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=uu8kp1Ntah4i9Es8Q8kwu4544kQ=; b=a/iAz7VLOuOgidMlGNLG Lx2y7ClZwlHqUc952xDDyPekb9PrQiOgaLUxtQGyS5lsfCvN24FqQhIE5BSsuNS0 B+TLCZebqhC7eMF5x+iF6/spAO6d2iAhJdHQbCCa0QYc0WuEY3XRLOclaW/giil1 oxALIhRkveXuVdTVhoBrGoI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 01 Oct 2013 08:44:10 -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 2798958319.1978.3152; Tue, 01 Oct 2013 08:44:09 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1258; t=1380631069; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=+zOqqM7 3AyXtIj3LusUa+dbmnNgmVazMJIUAMK65nro=; b=qKlLcDsuN+fc46TDTCD79TO BkFRVJtq5A5n2IryntcP94KjuY2TAHNC2CGwepO5yB9dhVvJBsCmpRKWW0ASpBub 8fYHgYVx7YyCkSoXZjDJJkhP6R/D8R9QX5IUUribh3XE6YxfawihapL51Q2xoP12 Hgf3vBz4ez/Ug3LZBZa4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 01 Oct 2013 08:37:49 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2245350034.9.8972; Tue, 01 Oct 2013 08:37:48 -0400 Message-ID: <524AC39A.2070700@isdg.net> Date: Tue, 01 Oct 2013 08:44:10 -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: "Murray S. Kucherawy" References: <6.2.5.6.2.20131001024332.0c9271e0@resistor.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , S Moonesamy 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 12:44:21 -0000 On 10/1/2013 8:11 AM, Murray S. Kucherawy wrote: > I don't agree that this is a configurable limit. The limit is fixed at 10; > an implementation that allows the limit to be adjusted is non-standard and > not interoperable. Have I misunderstood something here? Early adopter like us didn't have limits. IOW, draft-mengwong-spf-00 did not have any limits written in. However, software stack recursion limits soon became apparent. When RFC4408 was finally release, early adopters updated and it was added then. So I would think these were added after the fact and as a global limit, and as a matter of fact, our default is actually set at 20 most likely it was too low for these types of spf service provider issues: ; RecursionLimit limits the number of SPF recursion calls by a domain RecursionLimit 20 You have to consider that SOFTWARE was optimized to also not fail. This 20 probably covers the ones or twos SPF service providers you are just now hearing about. But the overall issue has been long known and don't be surprise if there are some remaining implementations that don't have a limit or have it at some level so it doesn't fail at 11 or 12, etc. Consider the outcomes: PERMERROR vs REAL SPF RESULT -- HLS From dotzero@gmail.com Tue Oct 1 06:01: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 B218D21E81C8 for ; Tue, 1 Oct 2013 06:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LOAN=2.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 h2r5OqFtFZjh for ; Tue, 1 Oct 2013 06:01:08 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 18FE021E8149 for ; Tue, 1 Oct 2013 06:00:40 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id es20so5727056lab.24 for ; Tue, 01 Oct 2013 06:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9TG2hoURpDZegafMCc4hgyZ7mjpXWAk+ZU2q6XI56bo=; b=JJWELhiCWqiPCYOLkSa2h5CzH+VZFdUOeEfJjc/9a2cWkte63Pvuu12oc9bgmKAYs0 YC3sYFmAphuE4bC1kWmma6o2fkRg2dDyckLHni2RSjo6Evkz+LSIIj4yQn6JKhBr2xqN 7G7eFcvxcjSffYTpgWHnc7AsCr/lwoaWCSe16oJX19ESjE+slFGMiDd+RVQXTsFqraxG WAuoyxgfWeCt/PvLHfH4iCQKFUnVrJUcjPcgOB+dlBi4+ObhR3CiyCR4+0z17W30Z8EF 9sO3nFP7zN/OAHII/nqV3bMNyO2Xjd0epdlQLG+kXexWa/pABaYvvDuiKTyzyoMsMFlv 4Bcg== MIME-Version: 1.0 X-Received: by 10.112.77.134 with SMTP id s6mr1544425lbw.38.1380632438876; Tue, 01 Oct 2013 06:00:38 -0700 (PDT) Received: by 10.112.137.163 with HTTP; Tue, 1 Oct 2013 06:00:38 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20131001024332.0c9271e0@resistor.net> Date: Tue, 1 Oct 2013 09:00:38 -0400 Message-ID: From: Dotzero To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" , S Moonesamy 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 13:01:08 -0000 On Tue, Oct 1, 2013 at 8:11 AM, Murray S. Kucherawy wrote: > On Tue, Oct 1, 2013 at 2:55 AM, S Moonesamy wrote: >> >> >>> Do we need to find some way to provide some advice here? >> Patient: "Dr., it hurts when I do that. Dr.: "Then don't do that." >> >> If there is a concern that this is going to be a pervasive problem my >> suggestion would be to carefully consider the matter and make the argument. >> It is suggested that factual information be provided so that people can >> verify for themselves and form an opinion. >> > > I think Scott's idea of doing a FAQ entry is the most reasonable path > forward here. This doesn't seem to be serious enough to warrant a new > document or a modification to the bis draft at this stage. Given the size > and popularity of the operators I've heard about, however, this is going to > be a pain point for more than just the couple of operators I've heard from. > I have seen this problem as well. Shame on the operators. They should have been testing and noticed the problem and addressed it. That's part of what they are getting paid for. To a certain extent I say shame on the customers but I realize that many of them don't have the understanding, skillsets or even the ability to figure out where to find a tool to validate their record (including includes). I question how useful adding the FAQ will be (even though I agree it is the correct thing to do) in this respect. To summarize, I view it as more of a quality assurance issue for the service provider than something we can fix through documentation. > Another issue that was suggested: If the first party's SPF record includes > two or more others others, and those in turn include others but some of > those overlap, should the redundant includes be counted against the 10? > > I don't agree that this is a configurable limit. The limit is fixed at 10; > an implementation that allows the limit to be adjusted is non-standard and > not interoperable. Have I misunderstood something here? > > -MSK > > Mike From superuser@gmail.com Tue Oct 1 06:38: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 A46CE11E825F for ; Tue, 1 Oct 2013 06:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 GrZKnXu5WB8O for ; Tue, 1 Oct 2013 06:38:26 -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 8AB7311E8262 for ; Tue, 1 Oct 2013 06:36:20 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hn9so5548117wib.11 for ; Tue, 01 Oct 2013 06:36:19 -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=Zc3HDQ+NKWq2UdoNOMII6i6rDRb4mkLKYgxCTzsUtJo=; b=EvDKo/QdGgK3C8xDAxOrN0ivVjWZ/NSil7VCiRnvB1mddX+T/oShuBUrzlOhq4BNsY wcsEXaZNLepBiluqQC+DCnEqolOB4ftcQ23WMIJZtKE22lGu7aapV5CsF5bweUB7zNem TCgh+PiLkE4ULwJ5D3x4M1S5jolGNlwnqFHItTcb+s45Q79wkwRUbdbBaXqDX4W+hxvi 2Hzz0mBKF/XoK2dahkJAoh3hn33OFg4ejhK6Bsi/Y7lUpcn61cEOChJx4VGCOME3V4of JDntp2dkSSeClkp7Hk4LyaVJB0uWrGh2P0HM5fFg72wPDzUtELdZBINkvdHR4gjt85ti HjGg== MIME-Version: 1.0 X-Received: by 10.180.183.51 with SMTP id ej19mr18784717wic.60.1380634579720; Tue, 01 Oct 2013 06:36:19 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Tue, 1 Oct 2013 06:36:19 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20131001024332.0c9271e0@resistor.net> Date: Tue, 1 Oct 2013 06:36:19 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dotzero Content-Type: multipart/alternative; boundary=001a11c2409eb05f1f04e7ae09c8 Cc: "spfbis@ietf.org" , S Moonesamy 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 13:38:26 -0000 --001a11c2409eb05f1f04e7ae09c8 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 1, 2013 at 6:00 AM, Dotzero wrote: > I have seen this problem as well. Shame on the operators. They should > have been testing and noticed the problem and addressed it. That's > part of what they are getting paid for. > Another part of the problem is that there are implementations that don't impose any limit, or don't stick to the specified limit, which means the operator gets inconsistent feedback; some receivers bounce because the limit is reached, others don't. It gets very hard to make a choice about how to adjust the policy record to deal with a situation like that. -MSK --001a11c2409eb05f1f04e7ae09c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 1, 2013 at 6:00 AM, Dotzero = <dotzero@gmail.co= m> wrote:
I have seen this problem as well. Shame on the operators. They should
have been testing and noticed the problem and addressed it. That's
part of what they are getting paid for.

Another part of the problem is that there are implementations that don'= ;t impose any limit, or don't stick to the specified limit, which means= the operator gets inconsistent feedback; some receivers bounce because the= limit is reached, others don't.=A0 It gets very hard to make a choice = about how to adjust the policy record to deal with a situation like that.
-MSK
--001a11c2409eb05f1f04e7ae09c8-- From ogud@ogud.com Tue Oct 1 06:56: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 8E7DA21E81D3 for ; Tue, 1 Oct 2013 06:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.298 X-Spam-Level: X-Spam-Status: No, score=-101.298 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LOAN=2.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 PaVP38q2uQ9j for ; Tue, 1 Oct 2013 06:56:05 -0700 (PDT) Received: from smtp122.ord1c.emailsrvr.com (smtp122.ord1c.emailsrvr.com [108.166.43.122]) by ietfa.amsl.com (Postfix) with ESMTP id B650211E81DC for ; Tue, 1 Oct 2013 06:52:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp8.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 56F461A01A1 for ; Tue, 1 Oct 2013 09:52:45 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp8.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 253D01A0154 for ; Tue, 1 Oct 2013 09:52:44 -0400 (EDT) From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_7534DD35-4EE8-41ED-A500-4BE82CBEEDDE" Message-Id: <0F69D34C-137A-4838-8D23-1E621C6D8ADC@ogud.com> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Date: Tue, 1 Oct 2013 09:52:43 -0400 References: <6.2.5.6.2.20131001024332.0c9271e0@resistor.net> To: "spfbis@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1510) 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 13:56:27 -0000 --Apple-Mail=_7534DD35-4EE8-41ED-A500-4BE82CBEEDDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Oct 1, 2013, at 8:11 AM, Murray S. Kucherawy = wrote: > On Tue, Oct 1, 2013 at 2:55 AM, S Moonesamy = wrote: >=20 > Do we need to find some way to provide some advice here? >=20 > If there is a concern that this is going to be a pervasive problem my = suggestion would be to carefully consider the matter and make the = argument. It is suggested that factual information be provided so that = people can verify for themselves and form an opinion. >=20 >=20 > I think Scott's idea of doing a FAQ entry is the most reasonable path = forward here. This doesn't seem to be serious enough to warrant a new = document or a modification to the bis draft at this stage. Given the = size and popularity of the operators I've heard about, however, this is = going to be a pain point for more than just the couple of operators I've = heard from. >=20 > Another issue that was suggested: If the first party's SPF record = includes two or more others others, and those in turn include others but = some of those overlap, should the redundant includes be counted against = the 10? >=20 > I don't agree that this is a configurable limit. The limit is fixed = at 10; an implementation that allows the limit to be adjusted is = non-standard and not interoperable. Have I misunderstood something = here? >=20 > -MSK As the SPFBIS working group is almost done with its protocol specifying = milestones,=20 should it recharter and add the task of generating an operational = guidance/BCP document?=20 A if someone has a FAQ would be a good start, no matter if the WG takes = this on. Olafur --Apple-Mail=_7534DD35-4EE8-41ED-A500-4BE82CBEEDDE Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1

On Oct 1, 2013, at 8:11 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:

On Tue, Oct 1, 2013 at 2:55 AM, S Moonesamy <sm+ietf@elandsys.com> wrote:

Do we need to find some way to provide some advice here?

If there is a concern that this is going to be a pervasive problem my suggestion would be to carefully consider the matter and make the argument.  It is suggested that factual information be provided so that people can verify for themselves and form an opinion.


I think Scott's idea of doing a FAQ entry is the most reasonable path forward here.  This doesn't seem to be serious enough to warrant a new document or a modification to the bis draft at this stage.  Given the size and popularity of the operators I've heard about, however, this is going to be a pain point for more than just the couple of operators I've heard from.

Another issue that was suggested: If the first party's SPF record includes two or more others others, and those in turn include others but some of those overlap, should the redundant includes be counted against the 10?

I don't agree that this is a configurable limit.  The limit is fixed at 10; an implementation that allows the limit to be adjusted is non-standard and not interoperable.  Have I misunderstood something here?

-MSK

As the SPFBIS working group is almost done with its protocol specifying milestones, 
should it recharter and add the task of generating an operational guidance/BCP document? 

A if someone has a FAQ would be a good start, no matter if the WG takes this on.

Olafur

--Apple-Mail=_7534DD35-4EE8-41ED-A500-4BE82CBEEDDE-- From sm@elandsys.com Tue Oct 1 08:36: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 329F011E81B4 for ; Tue, 1 Oct 2013 08:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.386 X-Spam-Level: X-Spam-Status: No, score=-101.386 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_00=-2.599, MANGLED_LOAN=2.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 AiuAB21z7Bgx for ; Tue, 1 Oct 2013 08:36: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 C43B811E8143 for ; Tue, 1 Oct 2013 08:36:30 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.149.116]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r91FaB1r009358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Oct 2013 08:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1380641784; bh=72TAgqf12W5Snca1x6Bh8516uQNLlbrzlBwpXjce0d0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uB7UsahTaHje+Bbf5HNrxGCqXGxVVZI7aI3BpnJVYaJoWqzzLXWC47Ezi0ctWG5BD meyINbunC75ncrEgH+mK3eS3WXxd6kdJfn3Qe/mL3OJ70a5X62LeV0RyevQNgM5e4M ebI86O8WLYPtu3qcNBI1FOLBOQKGZSpyN88cOKNI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1380641784; i=@elandsys.com; bh=72TAgqf12W5Snca1x6Bh8516uQNLlbrzlBwpXjce0d0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=46lYTj0l95Y5IAF7daFQ++pugpwHGsg19ztwjCjxkxTV459xalb1Xs4EUZbko1Sa9 sHBoYK8L4PyY7GaBGQkipdOEa3TeolmtfrqqOpS+b/PPNHZogk/0RPrpW4OELjAQF+ ZJ3oCNUk6yorJ/ST78YNMxxmBxlwNP0N/mleE30k= Message-Id: <6.2.5.6.2.20131001075330.0cf17f18@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 01 Oct 2013 08:14:23 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20131001024332.0c9271e0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org 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 15:36:36 -0000 Hi Murray, At 05:11 01-10-2013, Murray S. Kucherawy wrote: >I think Scott's idea of doing a FAQ entry is the most reasonable >path forward here. This doesn't seem to be serious enough to >warrant a new document or a modification to the bis draft at this >stage. Given the size and popularity of the operators I've heard >about, however, this is going to be a pain point for more than just >the couple of operators I've heard from. Ok. >Another issue that was suggested: If the first party's SPF record >includes two or more others others, and those in turn include others >but some of those overlap, should the redundant includes be counted >against the 10? > >I don't agree that this is a configurable limit. The limit is fixed >at 10; an implementation that allows the limit to be adjusted is >non-standard and not interoperable. Have I misunderstood something here? I took a quick look at draft-ietf-spfbis-4408bis-21. The limit is set to 10. The argument for the limit is to avoid load on DNS. There is some text in the Security Considerations section which explains why there are processing limits in the specification. BTW, there would also be non-standard behavior if the limit is configurable. There may also be an interoperability issue. Regards, S. Moonesamy From sm@elandsys.com Tue Oct 1 08:36: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 D01F211E8129 for ; Tue, 1 Oct 2013 08:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 DH9wB4oIcoAF for ; Tue, 1 Oct 2013 08:36: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 90EDB11E8169 for ; Tue, 1 Oct 2013 08:36:34 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.149.116]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r91FaB1t009358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Oct 2013 08:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1380641791; bh=nrere/eOS+ZZOWEqaBtx+KhzQatk7LN4SJxjP8ag3Us=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LgHN359BszjMCAdpq6tyBdmltN226Wwgos6i2mU7iTqp2eUWVVP0aCPzUJTUpHGTy eDFBP83tmejDokDMWcxJ8BPq/1TVz7DTiD8NTLyPmRZPe0AzRPha8mVznSfeaTJsLH QlDstClalVaCN7Mm6aHwAJxmhRiSJSPFLwZx62cc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1380641791; i=@elandsys.com; bh=nrere/eOS+ZZOWEqaBtx+KhzQatk7LN4SJxjP8ag3Us=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=pp+cT2RexqVrHq8jxj8yvjfDNTczqcgCBvW/wVdPg76X7acdrphF4oGX1dbZKOdw4 iBWUj8czMl7NLx5ou6L/FitjCjbdo+MAkmP8rK+wpuE4i1Vj2CtdO/JitU/UwHbxvg XMFQ41I57VQm2Tahh/6X1IapdNBfEZVjmCEDGDZg= Message-Id: <6.2.5.6.2.20131001081527.0a923d58@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 01 Oct 2013 08:34:27 -0700 To: Olafur Gudmundsson From: S Moonesamy In-Reply-To: <0F69D34C-137A-4838-8D23-1E621C6D8ADC@ogud.com> References: <6.2.5.6.2.20131001024332.0c9271e0@resistor.net> <0F69D34C-137A-4838-8D23-1E621C6D8ADC@ogud.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: [spfbis] WG status (was: 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 15:36:42 -0000 Hi Olafur, At 06:52 01-10-2013, Olafur Gudmundsson wrote: >As the SPFBIS working group is almost done with its protocol >specifying milestones, >should it recharter and add the task of generating an operational >guidance/BCP document? There is a message from the SPFBIS WG Chairs at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10124.html Regards, S. Moonesamy From hsantos@isdg.net Tue Oct 1 09:09: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 66CBE21E8085 for ; Tue, 1 Oct 2013 09:09:56 -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 iIVWrbEHRV8C for ; Tue, 1 Oct 2013 09:09:51 -0700 (PDT) Received: from groups.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D98EF21E81B9 for ; Tue, 1 Oct 2013 09:09:50 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1457; t=1380643780; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=LbBdDhUmKVOZDELPaH2+0Ebb9PA=; b=tAlASc5kzc/pSldny/eE Tw5ApArxzsmMhE/8xyp532dV+PpPZ7txe4TKvYO5hmfMiGic6dib0pYoXs7BZLnx YZaOXjcBais4bDUSNEZTZ7U3hY+PN2+Hzy674ANIWBCLFoHxoysQCEIkqFvi5DyJ QTfFvXGFskYscd92DWKdQks= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 01 Oct 2013 12:09:40 -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 2811288747.1978.4940; Tue, 01 Oct 2013 12:09:40 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1457; t=1380643395; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=d4mCQvC YaV1zb7PvumpFO/eVXi8iVOiVjEBx+kvFBI4=; b=sFa8/T8NBzN2B4dR73PPRxw vQ37r9kuGEhnBGK+1HD+DxvSqMUGYb7NICUP4laNURyO9Bd8WJmcsM12HCE+W6aA TzRQjrZAZkD2SBUHIQBkqQh4Utz9btFfdkklH2NH+e9QPskdLSMAh5diSrh/Mdqp SsVL16/SuScF9TcC8cv0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 01 Oct 2013 12:03:15 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2257675956.9.10072; Tue, 01 Oct 2013 12:03:14 -0400 Message-ID: <524AF3C0.4000907@isdg.net> Date: Tue, 01 Oct 2013 12:09:36 -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: Dotzero References: <6.2.5.6.2.20131001024332.0c9271e0@resistor.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , "Murray S. Kucherawy" , S Moonesamy 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 16:09:56 -0000 On 10/1/2013 9:00 AM, Dotzero wrote: > On Tue, Oct 1, 2013 at 8:11 AM, Murray S. Kucherawy wrote: >> On Tue, Oct 1, 2013 at 2:55 AM, S Moonesamy wrote: >>> >>> >>>> Do we need to find some way to provide some advice here? >>> > > Patient: "Dr., it hurts when I do that. > Dr.: "Then don't do that." We get the point, but its not reality: Patient: "Dr., it hurts when I raise my arm" Dr.: "Then don't raise your arm!" is not the answer. The answer is A) awareness and B) allow implementators do deal with it, figure it out, i.e., with suggested limits and insights. But you have to consider that having something fail as a PERMERROR redundantly at the 11th call is just as illogical as the original SWAG (scientific wild-ass guess) of choosing 10 in the first place. The real problem is the WASTE with the relaxed policies. Vendors that do this as a service but have NO BANG for the SPF Calls Bucks! > I have seen this problem as well. Shame on the operators. They should > have been testing and noticed the problem and addressed it. That's > part of what they are getting paid for. It was only a problem from a SOFTWARE STACK standpoint and it that depends on the method of doing recursive or alternative (non-recursive) processing. So you only saw it when the with STACK exceptions and for most systems 10 is nothing, peanuts -- it was a SWAG limit. -- HLS From hsantos@isdg.net Tue Oct 1 09:16:28 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E959221E8085 for ; Tue, 1 Oct 2013 09:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.423 X-Spam-Level: X-Spam-Status: No, score=-101.423 tagged_above=-999 required=5 tests=[AWL=-1.124, BAYES_00=-2.599, MANGLED_LOAN=2.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 VS-j12RF5GHa for ; Tue, 1 Oct 2013 09:16:23 -0700 (PDT) Received: from groups.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 76D8B21E80C7 for ; Tue, 1 Oct 2013 09:16:23 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1142; t=1380644181; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=oJ2mxPM6Jm1Q99qtMgKcE8oT4Pk=; b=lCnOOLi3OxhVTxNrQl82 Mg4Hesqd6ZLM8+WSvWPcX8AEmGovcUOFP16k7kcWKCcE6r5U4AuCxaFiv5DvcdB5 tN/shAmw2h9fk3N7swutvxzW3wIte2mowYFuWBe0RvLmkEIkd3nEcNLwpdF5a870 EzPouAVUrlUjMzJTp7dnVDs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 01 Oct 2013 12:16:21 -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 2811689186.1978.3396; Tue, 01 Oct 2013 12:16:20 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1142; t=1380643796; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=oENw7je e+7jw1mD8yW2IsCY4DL5Jmsm1uNgTO2atQds=; b=ki3SRVl9n5hra4flP3av68z Acjh5W5ojTahQkjB+H6/b2R5vJ4n2d2Trd9zop2UEL2TpUrbFU0gH4txVr91dxpw gbRcdac4whfxeznWy5R0whneFFD4YCM0CrR0QUcmfSVwwbQFOIwMRXizomgGyxPk AV0y7YZWlaUfqIol9zQ0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 01 Oct 2013 12:09:56 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2258077394.9.6564; Tue, 01 Oct 2013 12:09:55 -0400 Message-ID: <524AF551.2080804@isdg.net> Date: Tue, 01 Oct 2013 12:16:17 -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: <6.2.5.6.2.20131001024332.0c9271e0@resistor.net> <6.2.5.6.2.20131001075330.0cf17f18@elandnews.com> In-Reply-To: <6.2.5.6.2.20131001075330.0cf17f18@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, "Murray S. Kucherawy" 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 16:16:29 -0000 On 10/1/2013 11:14 AM, S Moonesamy wrote: >> I don't agree that this is a configurable limit. The limit is fixed >> at 10; an implementation that allows the limit to be adjusted is >> non-standard and not interoperable. Have I misunderstood something >> here? > > I took a quick look at draft-ietf-spfbis-4408bis-21. The limit is set > to 10. The argument for the limit is to avoid load on DNS. There is > some text in the Security Considerations section which explains why > there are processing limits in the specification. BTW, there would > also be non-standard behavior if the limit is configurable. There may > also be an interoperability issue. Recursion limits is the principle reason because software breaks here, its real, that was an immediate symptom, even for processing the "good guys" publishers who just has too many includes. So the software had to be fine tuned to not fail. Remember, the 10, is just a SWAG. As I see, for our implementation, we have 20 as the limit, and I'm sure that was to cover the extremely few good guys who total calls was perhaps just over the subjective 10 limit. -- HLS From kurta@drkurt.com Tue Oct 1 09:33: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 EEAFC11E81AD for ; Tue, 1 Oct 2013 09:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 WTM6qqLuXUFH for ; Tue, 1 Oct 2013 09:33:05 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A9A6F11E8153 for ; Tue, 1 Oct 2013 09:33:04 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id p61so1410941wes.2 for ; Tue, 01 Oct 2013 09:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=SU657K0LbXYrt18LO1P4LcjQPKNsqaT+l9k3d5d93e8=; b=T1HMb9Ch4gW3puXgQdAo/u2ET6JN8aA0dXVcnPUWRinp6NQ232UpRQ5l3GhPWfgMrc yMgAxRCillD/JUPWaYB4nRaNODG2u/i02np7ANThXfD6wWa0MYNLL8Q0FYB2pTqhLpzs aWFjh3jvbJY2rM5Dkcyp+48HMh/MDGxB0N1Og= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=SU657K0LbXYrt18LO1P4LcjQPKNsqaT+l9k3d5d93e8=; b=QcfCgAbf/FRN9Som/t9SCJY5YL+ssPR585kor0mgzNCKR1WFvIf5TvZsxSSU1CSRjc 7Wh8VxUOqMfWVl4WJZjsLw4U8OxxZiYD6UM7Z56JcwM0EE72kJsbh9FUtSgvOqi164D6 bKHL4FazLgBbXjpwK5RN+1wTn1bIfFxILoxw3fUZOd4FR9fRgKDUl7gw+rVaMtYCPNnz CLacYu8JEhTeVTEri0957kPTgw2knt4IDWvKAA/gmDrvncFaoPU4RbmHzGlYTJz2t/D1 dxOzrQlC7+ZMtcNDQTecEYObM4qyugSOjtfBHum46lAO74cJSohTJvucdR18+CLSKiTr nV7Q== X-Gm-Message-State: ALoCoQlHnXO6Uneh8Q2+PJMaFmw3+KP+7sdBPXYA1SJeYjO85vErtofuaQ5vfJ55LS0sI7cdsIvL MIME-Version: 1.0 X-Received: by 10.180.13.83 with SMTP id f19mr19237141wic.54.1380645183637; Tue, 01 Oct 2013 09:33:03 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.21.97 with HTTP; Tue, 1 Oct 2013 09:33:03 -0700 (PDT) Date: Tue, 1 Oct 2013 09:33:03 -0700 X-Google-Sender-Auth: h6U0mxqABg8nzYhNSiNGKY9lmlI Message-ID: From: Kurt Andersen To: "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=001a11c24ababb5e2104e7b081c5 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 16:33:06 -0000 --001a11c24ababb5e2104e7b081c5 Content-Type: text/plain; charset=ISO-8859-1 On 2013-10-01 04:45 , "Hector Santos" wrote: > The main issue is the REDUNDANT WASTE when done with SPF relaxed > policies. So even if its just 8, 9 or limited to 10 calls, when done > by common domains (most of the messages arriving at your receiver), > then its all wasteful. Without any desire to provoke a flame war, relaxed policies are not entirely wasteful if one is using an "over the top" protocol such as DMARC. DMARC (and some individual receiver policies) work off of positive assertions, not the negative ones. --Kurt Andersen --001a11c24ababb5e2104e7b081c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 2013-10-01 04:45 , "Hector Santos" <hsantos@isdg.net> wrote:

> T= he main issue is the REDUNDANT WASTE when done with SPF relaxed
> pol= icies. So even if its just 8, 9 or limited to 10 calls,=A0 when done
> by common domains (most of the messages arriving at your receiver),> then its all wasteful.

Without any desire to provoke a flame w= ar, relaxed policies are not
entirely wasteful if one is using an "= over the top" protocol such as
DMARC. DMARC (and some individual receiver policies) work off of positiveassertions, not the negative ones.

--Kurt Andersen


--001a11c24ababb5e2104e7b081c5-- From hsantos@isdg.net Tue Oct 1 10:15: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 DD4EF21E81B9 for ; Tue, 1 Oct 2013 10:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.096 X-Spam-Level: X-Spam-Status: No, score=-102.096 tagged_above=-999 required=5 tests=[AWL=-0.361, 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 eazxWq454qsZ for ; Tue, 1 Oct 2013 10:15:18 -0700 (PDT) Received: from mail.santronics.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB1711E819F for ; Tue, 1 Oct 2013 10:15:17 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1902; t=1380647706; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=P13DK40jElrlabSY6PuKEnOTlgQ=; b=VBrWb77ovzF3dNxL3HEE h5ZGF3JbbEbfzc+bLNJ+J3mKkn2JGnqfcnXG2vRZPJY0/BxOwbqGIEPplc9YoLjU AJ+NJnHy/RjBB9uCoswuIdvbyvJZsH3sajvMcOfAbyrcxlFcc5Z9B+xShewFZ8s9 zml5u9pf6q3D9iJABL3Hmsg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 01 Oct 2013 13:15:06 -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 2815214544.1978.4008; Tue, 01 Oct 2013 13:15:06 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1902; t=1380647323; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=64qiE7V 47E07IVsO9lkH/7bzEPf+RdDE7wPon7V+U14=; b=YjAY3Zo9E/9MIlye0Rk/BkG E6RZMny1p6HES+uos3TqhqjBkJoNi7ADWTINA8V4l5AjumLRst5wEHoEaed/Ei3u oIaZfWVSjklH6eb7lNw8JDJeognBNQEV9Bu4igkiXkbC5Iisdpgtd1Agw/HKndy3 5pV9QEOY/mCQt6PSo9os= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 01 Oct 2013 13:08:43 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2261604206.9.2544; Tue, 01 Oct 2013 13:08:42 -0400 Message-ID: <524B0318.80006@isdg.net> Date: Tue, 01 Oct 2013 13:15:04 -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: Kurt Andersen References: <3560C13B3A3EC9408B4BFEDB3B72839509810721@ESV4-EXC02.linkedin.biz> In-Reply-To: <3560C13B3A3EC9408B4BFEDB3B72839509810721@ESV4-EXC02.linkedin.biz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "spfbis@ietf.org" , S Moonesamy 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 17:15:24 -0000 I agree, which tells ya, that this is material for a SPF "publishing" BCP that does take into account integrated concepts. But without it, this is just about weighting Waste versus Policy concepts. I personally don't think 10 should be labeled as a hard compliancy issue because as I pointed out, 10 was a SWAG, its too subjective and if we were to go on suggesting that if you don't follow "10" it will make you non-compliant, well, thats just more material to not support and ignore this BIS work. It was important early on so it should be pointed out of using limits, e.g.; 10, but the original issue, at least it was for us, was running into memory stack recursion limits. 10 is nothing and failing at 11 for a common domain, well, gets into political, tech support issues of who is right or wrong, the big vs small, passing the buck, etc. Remember, its not just about your own site, but a customer site who is seeing that one SPF service provider domain hitting their system with perhaps permerror results. After the more important and critical software stack design issue was first addressed (to address buffer overflow exploit attempts), this is most likely the reason we set the default of 20 as the limit, not 10. On 10/1/2013 12:23 PM, Kurt Andersen wrote: > On 2013-10-01 04:45 , "Hector Santos" wrote: > >> The main issue is the REDUNDANT WASTE when done with SPF relaxed >> policies. So even if its just 8, 9 or limited to 10 calls, when done >> by common domains (most of the messages arriving at your receiver), >> then its all wasteful. > > Without any desire to provoke a flame war, relaxed policies are not > entirely wasteful if one is using an "over the top" protocol such as > DMARC. DMARC (and some individual receiver policies) work off of positive > assertions, not the negative ones. > > --Kurt Andersen > > > -- HLS From prvs=9791300d2=kandersen@linkedin.com Tue Oct 1 09:23: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 7674711E8125 for ; Tue, 1 Oct 2013 09:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 QklkOFr3c5UO for ; Tue, 1 Oct 2013 09:23:26 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 82A5821E81BA for ; Tue, 1 Oct 2013 09:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1380644591; x=1412180591; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0pcLLY9gnj7r0utI654vsSxVmpzylEHsONZrZGcUq2s=; b=BN8GuTYisl1e+G91fzHTYTCJNYpKwVd0NqdXdwlnK2JRQVZoovzxaJmL 0nssuNsmmgDMKUcsQmXdb/VBM9gKJiRFCpYjxs79YUf+UZg3YDTsIlTKL 9wvVmcet5SWC7IPUN8ftI4tV972IsSiEm0p+El2yeD7OTsaH4lLaYPr2s U=; X-IronPort-AV: E=Sophos;i="4.90,1014,1371106800"; d="scan'208";a="64001293" Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.02.0328.011; Tue, 1 Oct 2013 09:23:55 -0700 From: Kurt Andersen To: Hector Santos , S Moonesamy Thread-Topic: [spfbis] Too many includes! Thread-Index: AQHOvmnCti0vcYfQSkGJmj6Ys4w3ppnfnNPGgACTEQD//9hHgA== Date: Tue, 1 Oct 2013 16:23:55 +0000 Message-ID: <3560C13B3A3EC9408B4BFEDB3B72839509810721@ESV4-EXC02.linkedin.biz> In-Reply-To: <524AB5C8.1080408@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.253] Content-Type: text/plain; charset="us-ascii" Content-ID: <0759C39E9BE2E247861E51F790773B86@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 01 Oct 2013 11:35:07 -0700 Cc: "spfbis@ietf.org" 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 16:23:33 -0000 On 2013-10-01 04:45 , "Hector Santos" wrote: >The main issue is the REDUNDANT WASTE when done with SPF relaxed >policies. So even if its just 8, 9 or limited to 10 calls, when done >by common domains (most of the messages arriving at your receiver), >then its all wasteful. Without any desire to provoke a flame war, relaxed policies are not entirely wasteful if one is using an "over the top" protocol such as DMARC. DMARC (and some individual receiver policies) work off of positive assertions, not the negative ones. --Kurt Andersen From superuser@gmail.com Tue Oct 1 11:50: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 DBA4C21E8204 for ; Tue, 1 Oct 2013 11:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 PhdkSuElL1Ls for ; Tue, 1 Oct 2013 11:50:24 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 649C121E81B9 for ; Tue, 1 Oct 2013 11:50:21 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id p61so1641289wes.30 for ; Tue, 01 Oct 2013 11:50:19 -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=AbnIwjlKBK76rb4q+bKVThf2wjAyig26XbaCqoKrkZA=; b=evTPbIzgVGXssqXGSJ0xi5rYSaRZMZv9hA1PVj8CzKx1VqDPOEcY4h+TsStVjjX81E xE+E9ayvvmzios8fn5REqODpb6k+LgUnU7NBktmTFRa/nvifBN51Cubr6nLEkTeS68Y3 ITZGYBaNDYkndm8QrPwS3t90r7BPhbJmgm9hN/hDz/hWKChRe/uguUiykihdddQRlJ4P efkYXRSJSECzukYSiJyAu/TUCDRfgbcoe87lzCxIwaXBUf3jTQj7RSlW7rH0oPj26Zsc PwsRDxKV+ZBFECd9jaQn8zFrT7PZOX6xDiC4dplxy/C/5bqGCvnrwGbAom+kU+jYapli zpKQ== MIME-Version: 1.0 X-Received: by 10.194.93.72 with SMTP id cs8mr3222331wjb.49.1380653419315; Tue, 01 Oct 2013 11:50:19 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Tue, 1 Oct 2013 11:50:19 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20131001081527.0a923d58@resistor.net> References: <6.2.5.6.2.20131001024332.0c9271e0@resistor.net> <0F69D34C-137A-4838-8D23-1E621C6D8ADC@ogud.com> <6.2.5.6.2.20131001081527.0a923d58@resistor.net> Date: Tue, 1 Oct 2013 11:50:19 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=047d7bb04d869dc88104e7b26c30 Cc: "spfbis@ietf.org" , Olafur Gudmundsson Subject: Re: [spfbis] WG status (was: 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 18:50:25 -0000 --047d7bb04d869dc88104e7b26c30 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 1, 2013 at 8:34 AM, S Moonesamy wrote: > Hi Olafur, > At 06:52 01-10-2013, Olafur Gudmundsson wrote: > >> As the SPFBIS working group is almost done with its protocol specifying >> milestones, >> should it recharter and add the task of generating an operational >> guidance/BCP document? >> > > There is a message from the SPFBIS WG Chairs at http://www.ietf.org/mail-* > *archive/web/apps-discuss/**current/msg10124.html > > > If the WG feels like this is something that needs doing, rechartering is always an option. That said, it's not the only option. -MSK --047d7bb04d869dc88104e7b26c30 Content-Type: text/html; charset=ISO-8859-1
On Tue, Oct 1, 2013 at 8:34 AM, S Moonesamy <sm+ietf@elandsys.com> wrote:
Hi Olafur,
At 06:52 01-10-2013, Olafur Gudmundsson wrote:
As the SPFBIS working group is almost done with its protocol specifying milestones,
should it recharter and add the task of generating an operational guidance/BCP document?

There is a message from the SPFBIS WG Chairs at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10124.html



If the WG feels like this is something that needs doing, rechartering is always an option.

That said, it's not the only option.

-MSK

--047d7bb04d869dc88104e7b26c30-- From johnl@iecc.com Tue Oct 1 12:07:39 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5739C21F9FD6 for ; Tue, 1 Oct 2013 12:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 JrlTp1+XdR4B for ; Tue, 1 Oct 2013 12:07:35 -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 DE16521F9E99 for ; Tue, 1 Oct 2013 12:07:34 -0700 (PDT) Received: (qmail 86090 invoked from network); 1 Oct 2013 19:07:33 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 1 Oct 2013 19:07:33 -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=524b1d75.xn--3zv.k1309; i=johnl@user.iecc.com; bh=kf/vn3yn4xbAHJvpK0SgwvgHCOWlq4kMZ9u7z80aXNw=; b=WG5OsoiBdEkbl7UdeRgE7711OAi3wzl61aSospsV+u63qyRpvKHpb936x9gqndi4yCCNr4tNFyxXfmy0EthUpfTtq66gpC7G7VlWb2ArHfqqGisQ7JylCRdW5U2FcCOD0ZHrAmfAk+1D1Y/XkLa/4KnvOaf2lD2wD81NdhDRhBqPwsfEPcDVKttK8K4G4LrxQXEIav0B+820QZ8TuS7nZhi1ASWQ8P3EYctIJ08Zpe5iLpkMtyla0jk8wZqYR/ef 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=524b1d75.xn--3zv.k1309; olt=johnl@user.iecc.com; bh=kf/vn3yn4xbAHJvpK0SgwvgHCOWlq4kMZ9u7z80aXNw=; b=OtgHFgG4IuitKez9WYEwF2BldC7FE+U4JOYdcAu8E6ZHHhk2ih0kSqhISLPXUWCJgXPLsOsXX08hQfpADgBwsnVA99hLpTZMN1Rxu/aOEHBrNqIxheDSfGHawz68IVW8xvV5E7k+k7TK/YKfkrKLOcQWX1g4XdXMstEykpSzLnpQMDDz0Y63OQTcvd/Uuq3RzmbLxgJG18ev8pBl+aMC4Oi9Jhc8dboCR812uLLs59B0MG6LKogXsmVVCONaiAMJ Date: 1 Oct 2013 19:07:11 -0000 Message-ID: <20131001190711.68316.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <0F69D34C-137A-4838-8D23-1E621C6D8ADC@ogud.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: ogud@ogud.com Subject: Re: [spfbis] 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 19:07:39 -0000 >As the SPFBIS working group is almost done with its protocol specifying milestones, >should it recharter and add the task of generating an operational guidance/BCP document? I don't think so. The issue of include explosions has been around as long as there has been SPF. Please let smoke settle, and see if there are enough non-obvious implementation issues that it's worth a separate document. This is hardly the only protocol with inconsistently enforced limits (512 byte DNS packets, anyone?), and I don't think it'd be a good idea to start publishing a document per protocol that says if you don't do what the standard says, it often won't work. R's, John From dotzero@gmail.com Tue Oct 1 12:16: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 5D82711E821A for ; Tue, 1 Oct 2013 12:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.575, 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 4By8ImZQTgIv for ; Tue, 1 Oct 2013 12:16:37 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id E9B3C21E80C7 for ; Tue, 1 Oct 2013 12:16:32 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id w7so6239235lbi.22 for ; Tue, 01 Oct 2013 12:16: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=UJ80arM7tb7kXlY6XGLEBcy4LoSyI/aFVT6HNSKj+lQ=; b=BzXilJWT2C2RUg8RfdHP7Hn6q9zxoajjSOcBVxJE4jCoq1Gk6mLFexWicSsfm4esWt rZLF4Yf6jwI8ePAme4M+9RlawqdfnCYjsFYPvd8k9hki7CutTUxa3JNQxSPd4of9GjS2 P/zmr75ylL6Z6FsyvCgCK6Ef7WebqPMBjvOO1dq6Wld9PXg5hd96e9AAk2K0ZsqCNx22 29qpfaUnYHzgWMB0RMetlsbBUHpoNJODk3uwVGcGzqLH29B/MQwpbUAqh/jzvMvMDRQz iMQUPyB+VsbmcjBm3wszwlPXUYpb8Zm5S+zmUb6yobVtVUoBV6AlQaMdzwxfNhDvjvcJ Zi4Q== MIME-Version: 1.0 X-Received: by 10.112.210.136 with SMTP id mu8mr28401867lbc.25.1380654991860; Tue, 01 Oct 2013 12:16:31 -0700 (PDT) Received: by 10.112.137.163 with HTTP; Tue, 1 Oct 2013 12:16:31 -0700 (PDT) In-Reply-To: <20131001190711.68316.qmail@joyce.lan> References: <0F69D34C-137A-4838-8D23-1E621C6D8ADC@ogud.com> <20131001190711.68316.qmail@joyce.lan> Date: Tue, 1 Oct 2013 15:16:31 -0400 Message-ID: From: Dotzero To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" , =?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?= 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 19:16:38 -0000 On Tue, Oct 1, 2013 at 3:07 PM, John Levine wrote: >>As the SPFBIS working group is almost done with its protocol specifying milestones, >>should it recharter and add the task of generating an operational guidance/BCP document? > > I don't think so. > > The issue of include explosions has been around as long as there has > been SPF. Please let smoke settle, and see if there are enough > non-obvious implementation issues that it's worth a separate document. > > This is hardly the only protocol with inconsistently enforced limits > (512 byte DNS packets, anyone?), and I don't think it'd be a good idea > to start publishing a document per protocol that says if you don't do > what the standard says, it often won't work. > > R's, > John One of the reasons I'm not particularly sympathetic is that of the problem records I've looked at/dug into with the publisher of the record there has invariably been a reasonable way to do things and stay within the limit. I'm not saying there won't potentially be some exceptions, but that has been my experience so far. From tim@eudaemon.net Tue Oct 1 12:24: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 C348811E8153 for ; Tue, 1 Oct 2013 12:24:44 -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=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSmmXtOWsVz7 for ; Tue, 1 Oct 2013 12:24:30 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id AD0BE21E8205 for ; Tue, 1 Oct 2013 12:24:21 -0700 (PDT) Received: from [10.0.1.15] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 124A8CB46 for ; Tue, 1 Oct 2013 15:24:53 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Tim Draegen In-Reply-To: Date: Tue, 1 Oct 2013 15:24:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <10384D54-5F64-4ACE-82AF-A004C6839C2C@eudaemon.net> References: <0F69D34C-137A-4838-8D23-1E621C6D8ADC@ogud.com> <20131001190711.68316.qmail@joyce.lan> To: "spfbis@ietf.org" X-Mailer: Apple Mail (2.1510) 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 19:24:45 -0000 On Oct 1, 2013, at 3:16 PM, Dotzero wrote: > One of the reasons I'm not particularly sympathetic is that of the > problem records I've looked at/dug into with the publisher of the > record there has invariably been a reasonable way to do things and > stay within the limit. I'm not saying there won't potentially be some > exceptions, but that has been my experience so far. My approach has been to make something that clearly shows that there is = a problem. Cycles: https://dmarcian.com/spf-survey/walmart.com Over-limit: https://dmarcian.com/spf-survey/microsoft.com I'm still trying to get the "clearly shows" part to better. Big red = blob =3D=3D problem seems to work. =3D- Tim From dotzero@gmail.com Tue Oct 1 13:04: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 826CD21E818A for ; Tue, 1 Oct 2013 13:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 wj2aGWwVuruT for ; Tue, 1 Oct 2013 13:04:30 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id F16B521E825B for ; Tue, 1 Oct 2013 13:04:27 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id eo20so6268048lab.20 for ; Tue, 01 Oct 2013 13:04:27 -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=2cWTeetZ7hQv8Atp53cD0r+kpO4HzF+zS/SFicJiTQ4=; b=Z+nNwqFCXiQsu8Rqs4wbvQD5L2a49Og6sRq3DHxIxwJbNAwSRRLjF4QoEMXuySaY/0 duP41Cqj3Mgrr6Tp1F1kz8mme3fPyWlEzzujcfEzPekpyQgLaIN0IL65w4zkfho2hs6d huwyi2akXchdXHyaO9EGCzIxkPfEw24iQfA+4L7WzN8y5gE8R9H+oxQjKYxglkub//0h kpKbRSLXXqNqg+LDuQdDcKgZC6DPEFEliRfY8tgXGzGjNJ5gdilGy8dAhC9kiTma0dPb cvy69yyftCzPyzM97SIDo979IyOKeyIZ4/2VTdmdUln8BbpLOEeaNWtUBDTm9/4IIMvg lQLA== MIME-Version: 1.0 X-Received: by 10.152.3.42 with SMTP id 10mr26694958laz.22.1380656204176; Tue, 01 Oct 2013 12:36:44 -0700 (PDT) Received: by 10.112.137.163 with HTTP; Tue, 1 Oct 2013 12:36:44 -0700 (PDT) In-Reply-To: <10384D54-5F64-4ACE-82AF-A004C6839C2C@eudaemon.net> References: <0F69D34C-137A-4838-8D23-1E621C6D8ADC@ogud.com> <20131001190711.68316.qmail@joyce.lan> <10384D54-5F64-4ACE-82AF-A004C6839C2C@eudaemon.net> Date: Tue, 1 Oct 2013 15:36:44 -0400 Message-ID: From: Dotzero To: Tim Draegen Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" 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 20:04:36 -0000 On Tue, Oct 1, 2013 at 3:24 PM, Tim Draegen wrote: > On Oct 1, 2013, at 3:16 PM, Dotzero wrote: >> One of the reasons I'm not particularly sympathetic is that of the >> problem records I've looked at/dug into with the publisher of the >> record there has invariably been a reasonable way to do things and >> stay within the limit. I'm not saying there won't potentially be some >> exceptions, but that has been my experience so far. > > My approach has been to make something that clearly shows that there is a problem. > But notice the difference between the problems. > Cycles: > https://dmarcian.com/spf-survey/walmart.com > Really? They have ~99,000 IPs sending mail on their behalf? I view their problem as more along the lines of administrative laziness. If someone at a site which receives a lot of mail from them were to check, I bet Walmart is actually sending mail from only a fraction of those. > Over-limit: > https://dmarcian.com/spf-survey/microsoft.com > 1 over the limit and with ~79k IPs. I am more likely to believe that MS needs lots of IPs/netblocks for mail given the services they host/provide including for others.. > I'm still trying to get the "clearly shows" part to better. Big red blob == problem seems to work. > > =- Tim > I think you are doing a great job with dmarcian Tim. Mike From spf2@kitterman.com Tue Oct 1 13:37: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 06DCF11E8211 for ; Tue, 1 Oct 2013 13:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.3 X-Spam-Level: ** X-Spam-Status: No, score=2.3 tagged_above=-999 required=5 tests=[MANGLED_LOAN=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 04I1MrsElgWK for ; Tue, 1 Oct 2013 13:37:03 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4E29C11E8153 for ; Tue, 1 Oct 2013 13:37:03 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 98739D04081; Tue, 1 Oct 2013 16:37:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1380659822; bh=hNL6uJBciFzFjKFs9F2neYC37H5NGBVHlAHz5o4j94g=; h=In-Reply-To:References:Subject:From:Date:To:From; b=Jge03LhG7PRIrdtJYiSOFNRHk1Um7LebVErxOxeFmRTfPr9uqnIKOpczCjpm8t9FE xLLjTYxqwwxMQyYqomIaHE4WACKwjP/9Jtngj4sEnxwqhJokOVuUBnSdl9XsbokF6K VY2phYAqQBQ6z+HcUj5Pxw6fW2MJdgKw5a051Bao= Received: from [IPV6:2600:1003:b00e:1858:27f8:a051:eca5:b07d] (unknown [IPv6:2600:1003:b00e:1858:27f8:a051:eca5:b07d]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 233E1D0405E; Tue, 1 Oct 2013 16:37:01 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <6.2.5.6.2.20131001024332.0c9271e0@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 01 Oct 2013 16:37:04 -0400 To: "spfbis@ietf.org" Message-ID: 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 20:37:10 -0000 You understand correctly. Scott K "Murray S. Kucherawy" wrote: >On Tue, Oct 1, 2013 at 2:55 AM, S Moonesamy >wrote: > >> >> Do we need to find some way to provide some advice here? >>> >> >> If there is a concern that this is going to be a pervasive problem my >> suggestion would be to carefully consider the matter and make the >argument. >> It is suggested that factual information be provided so that people >can >> verify for themselves and form an opinion. >> >> >I think Scott's idea of doing a FAQ entry is the most reasonable path >forward here. This doesn't seem to be serious enough to warrant a new >document or a modification to the bis draft at this stage. Given the >size >and popularity of the operators I've heard about, however, this is >going to >be a pain point for more than just the couple of operators I've heard >from. > >Another issue that was suggested: If the first party's SPF record >includes >two or more others others, and those in turn include others but some of >those overlap, should the redundant includes be counted against the 10? > >I don't agree that this is a configurable limit. The limit is fixed at >10; >an implementation that allows the limit to be adjusted is non-standard >and >not interoperable. Have I misunderstood something here? > >-MSK > > >------------------------------------------------------------------------ > >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From spf2@kitterman.com Tue Oct 1 13:51: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 587B211E8153 for ; Tue, 1 Oct 2013 13:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.3 X-Spam-Level: ** X-Spam-Status: No, score=2.3 tagged_above=-999 required=5 tests=[MANGLED_LOAN=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 Ll1x5aPCGU+9 for ; Tue, 1 Oct 2013 13:51:03 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id CB51F11E8211 for ; Tue, 1 Oct 2013 13:51:00 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id A32A7D04081; Tue, 1 Oct 2013 16:50:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1380660658; bh=zRub/b8NccyZqFJk+q5WSjrE5bsYcXSEf7eqgm3rQUc=; h=In-Reply-To:References:Subject:From:Date:To:From; b=PkUrKdg/wyFexpgHWfBS6hNdaVRloIjwifOcT/wEJRxk/ZHMS3v+7Yvg3x5gs/oO4 OIlbXjEZd1L2vLtS2Yw+YZS5qBxj6Q6rIpuVnaprZMC6mANJE/pPVijHZpgILqw4yw tTWeGeK5w3bRrlDwPB0dW4bdoyswxemp0phZ7RwA= Received: from [IPV6:2600:1003:b00e:1858:27f8:a051:eca5:b07d] (unknown [IPv6:2600:1003:b00e:1858:27f8:a051:eca5:b07d]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 3513AD0405E; Tue, 1 Oct 2013 16:50:58 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <524AC39A.2070700@isdg.net> References: <6.2.5.6.2.20131001024332.0c9271e0@resistor.net> <524AC39A.2070700@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 01 Oct 2013 16:51:01 -0400 To: "spfbis@ietf.org" Message-ID: <865935d1-3132-4515-bfec-d37475a82f7e@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 20:51:13 -0000 Hector Santos wrote: >On 10/1/2013 8:11 AM, Murray S. Kucherawy wrote: >> I don't agree that this is a configurable limit. The limit is fixed >at 10; >> an implementation that allows the limit to be adjusted is >non-standard and >> not interoperable. Have I misunderstood something here? > >Early adopter like us didn't have limits. IOW, draft-mengwong-spf-00 >did not have any limits written in. However, software stack >recursion limits soon became apparent. When RFC4408 was finally >release, early adopters updated and it was added then. > >So I would think these were added after the fact and as a global >limit, and as a matter of fact, our default is actually set at 20 >most likely it was too low for these types of spf service provider >issues: > >; RecursionLimit limits the number of SPF recursion calls by a domain > >RecursionLimit 20 > >You have to consider that SOFTWARE was optimized to also not fail. >This 20 probably covers the ones or twos SPF service providers you are >just now hearing about. But the overall issue has been long known and >don't be surprise if there are some remaining implementations that >don't have a limit or have it at some level so it doesn't fail at 11 >or 12, etc. > >Consider the outcomes: > > PERMERROR vs REAL SPF RESULT Permerror is the real SPF result. Super huge providers like Hotmail are able to (mostly) able publish compliant records. If they can do it, I have a hard time believing it's a problem that needs more than education to solve. This is unchanged from 4408, so it's nothing new. Scott K From spf2@kitterman.com Tue Oct 1 14:15: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 7E47321F9F9D for ; Tue, 1 Oct 2013 14:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.3 X-Spam-Level: ** X-Spam-Status: No, score=2.3 tagged_above=-999 required=5 tests=[MANGLED_LOAN=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 89kbHb3mQcyJ for ; Tue, 1 Oct 2013 14:15:15 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6555521F9F8F for ; Tue, 1 Oct 2013 14:15:13 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 129FED04092; Tue, 1 Oct 2013 17:15:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1380662113; bh=08v5NezVawpSMog+y+g7brM2EhClh9g0pxNGEsdVok4=; h=In-Reply-To:References:Subject:From:Date:To:From; b=QdteL4BUH1rB1ytI2qM5JHzqKAYHMHUN85SUH3f5neE0IVTWC3UGVqpUkTLD8HrWl uFJ9cQ5pjBjtfmv0hnKEhH5DWa/HYsEcktdmufskrm6zXERnIXGnAAdwwEy4dCO326 2OfhwWQ9FCJ0ZYgAxKUaYBF2iAhInZhHx9V+pJH4= Received: from [IPV6:2600:1003:b00e:1858:27f8:a051:eca5:b07d] (unknown [IPv6:2600:1003:b00e:1858:27f8:a051:eca5:b07d]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A5F9BD04091; Tue, 1 Oct 2013 17:15:12 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <524AF551.2080804@isdg.net> References: <6.2.5.6.2.20131001024332.0c9271e0@resistor.net> <6.2.5.6.2.20131001075330.0cf17f18@elandnews.com> <524AF551.2080804@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 01 Oct 2013 17:15:18 -0400 To: spfbis@ietf.org Message-ID: <259f3605-635e-4bf8-a785-24ad7cebc0fd@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 21:15:38 -0000 Hector Santos wrote: >On 10/1/2013 11:14 AM, S Moonesamy wrote: >>> I don't agree that this is a configurable limit. The limit is fixed >>> at 10; an implementation that allows the limit to be adjusted is >>> non-standard and not interoperable. Have I misunderstood something >>> here? >> >> I took a quick look at draft-ietf-spfbis-4408bis-21. The limit is >set >> to 10. The argument for the limit is to avoid load on DNS. There is >> some text in the Security Considerations section which explains why >> there are processing limits in the specification. BTW, there would >> also be non-standard behavior if the limit is configurable. There >may >> also be an interoperability issue. > >Recursion limits is the principle reason because software breaks here, >its real, that was an immediate symptom, even for processing the "good >guys" publishers who just has too many includes. So the software had >to be fine tuned to not fail. Remember, the 10, is just a SWAG. As >I see, for our implementation, we have 20 as the limit, and I'm sure >that was to cover the extremely few good guys who total calls was >perhaps just over the subjective 10 limit. Do you really mean recursion limit? The 4408/4408bis limits aren't related to recursion (unlike the pre-RFC limits which were recursion based). Scott K From doug.mtview@gmail.com Tue Oct 1 19:13: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 99B3E11E821A for ; Tue, 1 Oct 2013 19:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 sHAwGhEAvVp1 for ; Tue, 1 Oct 2013 19:13:20 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B3FED21F9A5F for ; Tue, 1 Oct 2013 19:13:09 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id md4so215076pbc.2 for ; Tue, 01 Oct 2013 19:13:09 -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=FI1p8B1R5lKqOXt+6xn+nFeXg2wPvgQMiW0ilPfUYRc=; b=zGrrTvvRzqzh/yDgRA1TxAFjPTVNK881Jm8l5JhDpiyeuwfhU0bdneSrhTG+Cvz3o3 nwR6mV4mnLtzsefdy2eI7GwLTYb/CDdlP/PCu89gLChIjn0FY14cqfaQogrptzewLCP+ DE71kkj5Usg3M/BxYL0is8vEAXPyHn+fqQiwS4g+5fMhWNRMR2nAoyyIWVyYsObMQScT s89M/wdS2zu6EkjDen1mXK6V/CmUI1rtf5+WX97kWBuyxa+6kLT5Ge+nQbGbHlft1P+E tXGGuHCHY4mK79znOR2KV6HgiLy2E9eZPZ0mHGL/BuLyw+746TEtyllEMOPYgnPcfS6r OXvw== X-Received: by 10.68.91.3 with SMTP id ca3mr32937700pbb.20.1380679989492; Tue, 01 Oct 2013 19:13:09 -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 fy4sm9716438pbb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Oct 2013 19:13:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Douglas Otis In-Reply-To: <3560C13B3A3EC9408B4BFEDB3B72839509810721@ESV4-EXC02.linkedin.biz> Date: Tue, 1 Oct 2013 19:13:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5649CB20-5C51-49DF-B8D7-2A9C6D853B71@gmail.com> References: <3560C13B3A3EC9408B4BFEDB3B72839509810721@ESV4-EXC02.linkedin.biz> To: Kurt Andersen X-Mailer: Apple Mail (2.1510) Cc: "spfbis@ietf.org" , Hector Santos , S Moonesamy 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: Wed, 02 Oct 2013 02:13:27 -0000 On Oct 1, 2013, at 9:23 AM, Kurt Andersen = wrote: > On 2013-10-01 04:45 , "Hector Santos" wrote: >=20 >> The main issue is the REDUNDANT WASTE when done with SPF relaxed >> policies. So even if its just 8, 9 or limited to 10 calls, when done >> by common domains (most of the messages arriving at your receiver), >> then its all wasteful. >=20 > Without any desire to provoke a flame war, relaxed policies are not > entirely wasteful if one is using an "over the top" protocol such as > DMARC. DMARC (and some individual receiver policies) work off of = positive > assertions, not the negative ones. Dear Kurt, Disagree. DMARC is attempting to elevate combined negative results into = something providers will consider actionable. This action is = independent of private arrangement or a domain's reputation as a means = to limit user exposure to spoofing attempts. The relatively high = exception rate needed for either SPF or DKIM has devolved into = strategies that do not function well with normal email. DMARC offers an = action when both SPF and DKIM offer negative results. Beyond dealing = with accepted email that can not be delivered (which should not happen), = most providers ignore negative results obtained from SPF despite = protocol specific policy assertions. This is also where DMARC may = conflict with advice offered by SPFbis which does not align with DMARC's = goal of reducing erroneous actions based on negative SPF results. In = other words, this is where there is any direct benefit, but likely only = for domains limited to transactional messaging.=20 Regards, Douglas Otis= From spf2@kitterman.com Tue Oct 1 19:25: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 45DF421E8274 for ; Tue, 1 Oct 2013 19:25:14 -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+Dt5H5MrH2e for ; Tue, 1 Oct 2013 19:25:05 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id A700021F9B86 for ; Tue, 1 Oct 2013 19:25:05 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 4190DD04092; Tue, 1 Oct 2013 22:25:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1380680704; bh=nsVOgw5+XI5JMQmnxW13FEETEk0d4xIjWn+OXOMGwgA=; h=In-Reply-To:References:Subject:From:Date:To:From; b=LJ7FAjCP4J36a5k5PEhh5ATwGwRwSGPh/RDSxpP4FwdoGY3RfyhPHZDvl63AbLhJv 4bR/Yd3HPevydjzmB4TNA/GSrtzrhmaWjZsAf02kmLJvntGG3aDMyJGaIrJkAmIKjj 1CVZJetvzpOp0jooKR4QUsMsBw/D5Qrb2CX1ncoM= Received: from [IPV6:2600:1003:b106:ddb6:167a:a21d:79e7:b91] (unknown [IPv6:2600:1003:b106:ddb6:167a:a21d:79e7:b91]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id D4ECBD04081; Tue, 1 Oct 2013 22:25:03 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <5649CB20-5C51-49DF-B8D7-2A9C6D853B71@gmail.com> References: <3560C13B3A3EC9408B4BFEDB3B72839509810721@ESV4-EXC02.linkedin.biz> <5649CB20-5C51-49DF-B8D7-2A9C6D853B71@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 01 Oct 2013 22:25:09 -0400 To: "spfbis@ietf.org" Message-ID: <302efccf-6ab6-4853-9875-79e5d1dc24d8@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: Wed, 02 Oct 2013 02:25:14 -0000 Please argue about DMARC in some DMARC related place. Scott K Douglas Otis wrote: > >On Oct 1, 2013, at 9:23 AM, Kurt Andersen >wrote: > >> On 2013-10-01 04:45 , "Hector Santos" wrote: >> >>> The main issue is the REDUNDANT WASTE when done with SPF relaxed >>> policies. So even if its just 8, 9 or limited to 10 calls, when >done >>> by common domains (most of the messages arriving at your receiver), >>> then its all wasteful. >> >> Without any desire to provoke a flame war, relaxed policies are not >> entirely wasteful if one is using an "over the top" protocol such as >> DMARC. DMARC (and some individual receiver policies) work off of >positive >> assertions, not the negative ones. > >Dear Kurt, > >Disagree. DMARC is attempting to elevate combined negative results >into something providers will consider actionable. This action is >independent of private arrangement or a domain's reputation as a means >to limit user exposure to spoofing attempts. The relatively high >exception rate needed for either SPF or DKIM has devolved into >strategies that do not function well with normal email. DMARC offers >an action when both SPF and DKIM offer negative results. Beyond >dealing with accepted email that can not be delivered (which should not >happen), most providers ignore negative results obtained from SPF >despite protocol specific policy assertions. This is also where DMARC >may conflict with advice offered by SPFbis which does not align with >DMARC's goal of reducing erroneous actions based on negative SPF >results. In other words, this is where there is any direct benefit, >but likely only for domains limited to transactional messaging. > >Regards, >Douglas Otis >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From doug.mtview@gmail.com Tue Oct 1 20:00: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 F0E6621E827F for ; Tue, 1 Oct 2013 20:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoq3lmFx9Ej8 for ; Tue, 1 Oct 2013 20:00:02 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id B13B521E8281 for ; Tue, 1 Oct 2013 19:59:54 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id aq17so523198iec.27 for ; Tue, 01 Oct 2013 19:59:54 -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=Ls138KYfa1PSFiT/iPrSZPpoBuTSSI9s4oodr8PYnvI=; b=LQ4F5IudyGcncJ8V+9i19aTG6uxdpVvGGPhwfd9c5uV7UjeS4YMkKU0XdhcxCJsuSX Y+ZtIqK3AxLZmy8aZx2F5nTI1vFVHf4+z0ekoq9wK69zElJ271UA4Y9clbnmLekeqWxk i8075Fb57oHTUceude13GAAwDYJjmeji5/7mG9D1/D+J3G37WYLYoSwkPvodqW38x06D Lp7gPxmFDJea1CZwLxdCL449A9Dld9PsvK0Jrrj/H+GIfH28Ymy+EPhtVCu5g/CAcWRI xq3hdYrFRoi8FO/yFp8BJc+6GJ2FUqfIiQGwdo9QW56oF60cckzJ2XK0e4jztpdaOFIg +Vrw== X-Received: by 10.43.11.69 with SMTP id pd5mr23299icb.62.1380682794283; Tue, 01 Oct 2013 19:59:54 -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 ih14sm7727952igb.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Oct 2013 19:59:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Douglas Otis In-Reply-To: <302efccf-6ab6-4853-9875-79e5d1dc24d8@email.android.com> Date: Tue, 1 Oct 2013 19:59:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5CFD9839-49CD-4557-9897-EEB561D75865@gmail.com> References: <3560C13B3A3EC9408B4BFEDB3B72839509810721@ESV4-EXC02.linkedin.biz> <5649CB20-5C51-49DF-B8D7-2A9C6D853B71@gmail.com> <302efccf-6ab6-4853-9875-79e5d1dc24d8@email.android.com> To: Scott Kitterman X-Mailer: Apple Mail (2.1510) Cc: "spfbis@ietf.org" 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: Wed, 02 Oct 2013 03:00:12 -0000 On Oct 1, 2013, at 7:25 PM, Scott Kitterman wrote: > Please argue about DMARC in some DMARC related place. Dear Scott, The message pointed out a conflict in how SPF views "-all" policy = assertions. It seems this might deserve some review by the SPFbis WG = since some large providers have stated SPF negatives do not offer safe = actions with respect to general acceptance due to SPF's high exception = rate from things like forwarded email, etc. Dealing with an accepted = message that can not be delivered falls into a different set of = considerations. Acknowledging this may suggest "~all" rather than = "-all" offers better advice when the domain offers a fallback scheme. = Is this consideration on-topic for this WG? Regards, Douglas Otis= From spf2@kitterman.com Tue Oct 1 22:19: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 9C27211E826C for ; Tue, 1 Oct 2013 22:19: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 I8R+2vRRWNsb for ; Tue, 1 Oct 2013 22:19:38 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A44B911E8252 for ; Tue, 1 Oct 2013 22:18:43 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4110120E40D4; Wed, 2 Oct 2013 01:18:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1380691115; bh=0iVxOKKR4keR5L5aClIMvWZgDqIq+5tQsJ0j75SFEX4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hGQeMi0IcRuKAYZgYb5zy1oRh1yCM5nzGFy2GhdYjAjYSaYhzawrYQwQ9Jga3nBYf 5KeAsAQNwi9C3CA+2taaUt9bAh1kFoG6nX4fC2L7QrtB/jCQ1QDNbLHKYVVGeiUdA0 p9N3f1QZZjG1RuV4MuBU2lq28/CIiorMYS8OhYDE= 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 2BB9D20E4062; Wed, 2 Oct 2013 01:18:35 -0400 (EDT) From: Scott Kitterman To: "spfbis@ietf.org" Date: Wed, 02 Oct 2013 01:18:34 -0400 Message-ID: <2075896.QN6rnYXVT1@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-31-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <5CFD9839-49CD-4557-9897-EEB561D75865@gmail.com> References: <3560C13B3A3EC9408B4BFEDB3B72839509810721@ESV4-EXC02.linkedin.biz> <302efccf-6ab6-4853-9875-79e5d1dc24d8@email.android.com> <5CFD9839-49CD-4557-9897-EEB561D75865@gmail.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] 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: Wed, 02 Oct 2013 05:19:49 -0000 On Tuesday, October 01, 2013 19:59:50 Douglas Otis wrote: > On Oct 1, 2013, at 7:25 PM, Scott Kitterman wrote: > > Please argue about DMARC in some DMARC related place. > > Dear Scott, > > The message pointed out a conflict in how SPF views "-all" policy > assertions. It seems this might deserve some review by the SPFbis WG since > some large providers have stated SPF negatives do not offer safe actions > with respect to general acceptance due to SPF's high exception rate from > things like forwarded email, etc. Dealing with an accepted message that > can not be delivered falls into a different set of considerations. > Acknowledging this may suggest "~all" rather than "-all" offers better > advice when the domain offers a fallback scheme. Is this consideration > on-topic for this WG? What WG deliverables would it be relevant to? There's an spf-discuss list on listbox for more general discussions about SPF. Scott K From doug.mtview@gmail.com Wed Oct 2 11:05: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 A991221F9D5D for ; Wed, 2 Oct 2013 11:05:09 -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 F38HV4NwjU+6 for ; Wed, 2 Oct 2013 11:04:59 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 57A7121F8578 for ; Wed, 2 Oct 2013 11:03:50 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id kq14so1361357pab.40 for ; Wed, 02 Oct 2013 11:03: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=rFo/OinxtACKj0TOhYlTDEMdYBoyvfmz6Sqh3XZiqM8=; b=k0W7LMd9Ju8yrhv07byBLKpntE1y0/3ijclBSU23FkTPnMWeCfKgPx1QeRhKiB1++x iOrGS32c/CW1QK/7hOBcWD22Lqh1fWaey1lUYFGFz6kRuJvSIFjdyZ0XXprGSLMR//cM HpuVndoHlf1dT5OWtyF0U7zNwIqHhcZYSt67aRAR+LPWUxbPiT7ew2tp5YgxLyCayz7Q FLQqaNi/PWEwRR7xcZqMGbAXJX2zBaQsywwLJ5aCCBD9qaaPDlo5vLgFbzcErgapAi4y Vphe0X5v+8dIzaVHeh2JmwyDI5Xxv2XR6DjClJpZ5smQexVT18KA76aoX+zf+BxZEgcM nzjQ== X-Received: by 10.68.50.106 with SMTP id b10mr3998633pbo.152.1380737030122; Wed, 02 Oct 2013 11:03:50 -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 f2sm3243253pbg.44.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Oct 2013 11:03:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Douglas Otis In-Reply-To: <2075896.QN6rnYXVT1@scott-latitude-e6320> Date: Wed, 2 Oct 2013 11:03:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <31DED52E-5A6B-40B9-A744-1E2D16BC0EE9@gmail.com> References: <3560C13B3A3EC9408B4BFEDB3B72839509810721@ESV4-EXC02.linkedin.biz> <302efccf-6ab6-4853-9875-79e5d1dc24d8@email.android.com> <5CFD9839-49CD-4557-9897-EEB561D75865@gmail.com> <2075896.QN6rnYXVT1@scott-latitude-e6320> To: Scott Kitterman X-Mailer: Apple Mail (2.1510) Cc: "spfbis@ietf.org" Subject: [spfbis] SPF policy not effective as documented X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Oct 2013 18:05:12 -0000 On Oct 1, 2013, at 10:18 PM, Scott Kitterman wrote: > On Tuesday, October 01, 2013 19:59:50 Douglas Otis wrote: >> On Oct 1, 2013, at 7:25 PM, Scott Kitterman = wrote: >>> Please argue about DMARC in some DMARC related place. >>=20 >> Dear Scott, >>=20 >> The message pointed out a conflict in how SPF views "-all" policy >> assertions. It seems this might deserve some review by the SPFbis WG = since >> some large providers have stated SPF negatives do not offer safe = actions >> with respect to general acceptance due to SPF's high exception rate = from >> things like forwarded email, etc. Dealing with an accepted message = that >> can not be delivered falls into a different set of considerations.=20 >> Acknowledging this may suggest "~all" rather than "-all" offers = better >> advice when the domain offers a fallback scheme. Is this = consideration >> on-topic for this WG? >=20 > What WG deliverables would it be relevant to? SPFbis related documents of course.=20 Domains attempting to protect recipients from spoofed messages find = "-all" (FAIL) policy assertions in SPFbis and section G2 stating "SPF = fail results can be used to reject messages during the SMTP transaction = based on either "MAIL FROM" or "HELO" identity results" are generally = ignored. Such rejections are ignored because this often induces support = issues caused by the loss of otherwise valid and desired messages. = There is some risk of "FAIL" being acted upon which interferes with = fallback strategies aimed at reducing support costs associated with SPF = handling where a "~all" SOFTFAIL offers better results. This has been = confirmed by large providers who report too many exceptions are needed = to reject messages based on "-all" FAIL results. Effective policy = enforcement becomes practical when SPFbis permits a fallback strategy to = reduce the number of exceptions likely encountered. Regards, Douglas Otis= From scott@kitterman.com Wed Oct 2 11:10:39 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7AE21F9D8D for ; Wed, 2 Oct 2013 11:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXafdRYQRS2u for ; Wed, 2 Oct 2013 11:10:27 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 32F2021F9D74 for ; Wed, 2 Oct 2013 11:07:30 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3852D20E4124; Wed, 2 Oct 2013 14:07:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1380737244; bh=9WWafWMNuKB8X9DW3BHKAMC0VL+f5S5o7o9Hvet6aRo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=lpEj5lneQpu6+4d5PWEbs3UO9Fs97HxSwODLLLOcS/mhYRiJ6ekDR27zzWDcajU9L THZrk6NLSdDAeWdls47zFqU14UL8KiUNegXX7q7m+EvLeANOwWaHGjd1sKbv48G2i1 Tr7B6k5AN3E3KVDg3MypOVPWSucJ0y0cj9dYs+Yo= 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 1BFBC20E4079; Wed, 2 Oct 2013 14:07:23 -0400 (EDT) From: Scott Kitterman To: "spfbis@ietf.org" Date: Wed, 02 Oct 2013 14:07:23 -0400 Message-ID: <1513440.9kNcAHKuKg@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-31-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <31DED52E-5A6B-40B9-A744-1E2D16BC0EE9@gmail.com> References: <3560C13B3A3EC9408B4BFEDB3B72839509810721@ESV4-EXC02.linkedin.biz> <2075896.QN6rnYXVT1@scott-latitude-e6320> <31DED52E-5A6B-40B9-A744-1E2D16BC0EE9@gmail.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, 02 Oct 2013 11:24:38 -0700 Subject: Re: [spfbis] SPF policy not effective as documented X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Oct 2013 18:10:39 -0000 X-List-Received-Date: Wed, 02 Oct 2013 18:10:39 -0000 On Wednesday, October 02, 2013 11:03:47 Douglas Otis wrote: > On Oct 1, 2013, at 10:18 PM, Scott Kitterman wrote: > > On Tuesday, October 01, 2013 19:59:50 Douglas Otis wrote: > >> On Oct 1, 2013, at 7:25 PM, Scott Kitterman wrote: > >>> Please argue about DMARC in some DMARC related place. > >> > >> Dear Scott, > >> > >> The message pointed out a conflict in how SPF views "-all" policy > >> assertions. It seems this might deserve some review by the SPFbis WG > >> since > >> some large providers have stated SPF negatives do not offer safe actions > >> with respect to general acceptance due to SPF's high exception rate from > >> things like forwarded email, etc. Dealing with an accepted message that > >> can not be delivered falls into a different set of considerations. > >> Acknowledging this may suggest "~all" rather than "-all" offers better > >> advice when the domain offers a fallback scheme. Is this consideration > >> on-topic for this WG? > > > > What WG deliverables would it be relevant to? > > SPFbis related documents of course. > > Domains attempting to protect recipients from spoofed messages find "-all" > (FAIL) policy assertions in SPFbis and section G2 stating "SPF fail results > can be used to reject messages during the SMTP transaction based on either > "MAIL FROM" or "HELO" identity results" are generally ignored. Such > rejections are ignored because this often induces support issues caused by > the loss of otherwise valid and desired messages. There is some risk of > "FAIL" being acted upon which interferes with fallback strategies aimed at > reducing support costs associated with SPF handling where a "~all" SOFTFAIL > offers better results. This has been confirmed by large providers who > report too many exceptions are needed to reject messages based on "-all" > FAIL results. Effective policy enforcement becomes practical when SPFbis > permits a fallback strategy to reduce the number of exceptions likely > encountered. Since neither RFC 4408 nor RFC 4408bis specify receiver behavior in this case, I don't get the connection to SPFbis work. Scott K From dotzero@gmail.com Wed Oct 2 11:34: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 5F12B21F943C for ; Wed, 2 Oct 2013 11:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 emKM-ezvUGRF for ; Wed, 2 Oct 2013 11:34:41 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B533A21F9A43 for ; Wed, 2 Oct 2013 11:30:01 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id eh20so1010321lab.19 for ; Wed, 02 Oct 2013 11:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q0uGXOOnCcnDCfyIZJ47BCq2uWpu7sMmV31QfPc1VBU=; b=jiziFPKht+mggzQFlMK+LNcRDV3KkBpKfWTHHPA4+gFLDD8nRdU7s+RSXvViUuDOS8 csolZ6rc+UWVaML+n0z4JwIhbG6NA1chjugTpdt/11O+QcUkq3CHTjYePgCniva4NEUM 6Awcn9kWbh5Bqn47Br1aQZrcrwxyLv3pHZV/Mjz8ot6vlrOPOTj3MoGnDlU4pWwBzNL0 7afx33yZaOtO3QXfX9UvIijwVMbvXiB/EhLQfOuD5XgQpNcBnVZlbvteKmaQUd7GLk+F sHg5gUwQV/V9vU1XtglRgWuODEYODSXpbf0ut2EqRbDIGBHICmTIrcwVO2i3WGR48T7M tl+g== MIME-Version: 1.0 X-Received: by 10.112.55.173 with SMTP id t13mr2610828lbp.39.1380738600708; Wed, 02 Oct 2013 11:30:00 -0700 (PDT) Received: by 10.112.137.163 with HTTP; Wed, 2 Oct 2013 11:30:00 -0700 (PDT) In-Reply-To: <1513440.9kNcAHKuKg@scott-latitude-e6320> References: <3560C13B3A3EC9408B4BFEDB3B72839509810721@ESV4-EXC02.linkedin.biz> <2075896.QN6rnYXVT1@scott-latitude-e6320> <31DED52E-5A6B-40B9-A744-1E2D16BC0EE9@gmail.com> <1513440.9kNcAHKuKg@scott-latitude-e6320> Date: Wed, 2 Oct 2013 14:30:00 -0400 Message-ID: From: Dotzero To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] SPF policy not effective as documented X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 02 Oct 2013 18:34:47 -0000 On Wed, Oct 2, 2013 at 2:07 PM, Scott Kitterman wrote: > > Since neither RFC 4408 nor RFC 4408bis specify receiver behavior in this case, > I don't get the connection to SPFbis work. > > Scott K > +1 I think this falls under the heading of local policy. If I were John Levine I would invoke King Canute. Mike From doug.mtview@gmail.com Thu Oct 3 10:47:55 2013 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457C111E8175 for ; Thu, 3 Oct 2013 10:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 ixJqSAWhYAW5 for ; Thu, 3 Oct 2013 10:47:46 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6617F11E8185 for ; Thu, 3 Oct 2013 10:30:46 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id q10so2749810pdj.7 for ; Thu, 03 Oct 2013 10: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 :message-id:references:to; bh=qUGS3hJgp3sDC9TuLoPIanHS3AhpJr0Ep2DARAGorTE=; b=TulvbNRHaVO8LdJbPGepU2Y+t/RK1t40Xo0PmWDJNpuYKnLabSZ1XqCAHCymjbhl26 /mTLhY3RfhUS8AXpOjRX8ec7WKEQontRyQoXtLNMQnPnU0sOLsIURFRLR3/MD+bQJg0G vqMtGAVSA2BsYsctZmHkiw+ZL+Jb8/KOyC91427vv4thBxravgoJp/A3RYUGF32ZitI+ bE7nbYxrmpPitTxMaXLXLLhOFMQ6f2IAeRvcTMG8oRIIrsM/G5pYDX0DS1Sd+9/mOoCx Ey5yMJLAsUdeLQZsQ1ywzZUwGVQErmu5yvRMpZt/EbRx9t1jCO2Ay7wqxhIB7qLNjoJQ zKAA== X-Received: by 10.68.129.40 with SMTP id nt8mr1749739pbb.108.1380821445162; Thu, 03 Oct 2013 10: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 ef10sm12091083pac.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Oct 2013 10:30:43 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F498DEFF-DD14-415A-BBE7-D0333E8F106A" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Douglas Otis In-Reply-To: Date: Thu, 3 Oct 2013 10:30:44 -0700 Message-Id: References: <3560C13B3A3EC9408B4BFEDB3B72839509810721@ESV4-EXC02.linkedin.biz> <2075896.QN6rnYXVT1@scott-latitude-e6320> <31DED52E-5A6B-40B9-A744-1E2D16BC0EE9@gmail.com> <1513440.9kNcAHKuKg@scott-latitude-e6320> To: Dotzero X-Mailer: Apple Mail (2.1510) Cc: Scott Kitterman , "spfbis@ietf.org" Subject: Re: [spfbis] SPF policy not effective as documented X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 03 Oct 2013 17:47:56 -0000 --Apple-Mail=_F498DEFF-DD14-415A-BBE7-D0333E8F106A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 2, 2013, at 11:30 AM, Dotzero wrote: > On Wed, Oct 2, 2013 at 2:07 PM, Scott Kitterman = wrote: >=20 >>=20 >> Since neither RFC 4408 nor RFC 4408bis specify receiver behavior in = this case, >> I don't get the connection to SPFbis work. >>=20 >> Scott K >>=20 >=20 > +1 I think this falls under the heading of local policy. If I were > John Levine I would invoke King Canute. Dear Mike and Scott, This is not about dictating, but about advice offered in SPFbis. =20 Please see:=20 http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-21#appendix-G.2 This section offers advice regarding local policy for "-all" (FAIL). It = seems a bit disingenuous to offer advice that overlooks some hard = learned lessons. The advice offered is not well considered for many = scenarios and why rejection remains an unlikely result. It seems any = future version should expand upon this section at least. After a = decade, the number of exceptions involved with SPF handling are not = likely to improve substantially, which suggests there should also be a = section for "~all" (SOFTFAIL). This result offers a safer outcome when = combined with fallback strategies where a resulting aggregate policy has = a better chance of actually being applied (if only for transactional = messages.) Regards, Douglas Otis --Apple-Mail=_F498DEFF-DD14-415A-BBE7-D0333E8F106A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii dotzero@gmail.com> = wrote:

On Wed, Oct 2, 2013 at 2:07 PM, Scott Kitterman <scott@kitterman.com> = wrote:


Since neither RFC 4408 nor = RFC 4408bis specify receiver behavior in this case,
I don't get the = connection to SPFbis work.

Scott K


+1 I = think this falls under the heading of local policy. If I were
John = Levine I would invoke King Canute.

Dear = Mike and Scott,

This is not about dictating, = but about advice offered in SPFbis. =  

Please see: 

This section offers advice regarding local policy for = "-all" (FAIL).  It seems a bit disingenuous to offer advice that = overlooks some hard learned lessons.  The advice offered is not = well considered for many scenarios and why rejection remains an unlikely = result.  It seems any future version should expand upon this = section at least.  After a decade, the number of exceptions = involved with SPF handling are not likely to improve substantially, = which suggests there should also be a section for "~all" (SOFTFAIL). =  This result offers a safer outcome when combined with fallback = strategies where a resulting aggregate policy has a better chance of = actually being applied (if only for transactional = messages.)

Regards,
Douglas = Otis


= --Apple-Mail=_F498DEFF-DD14-415A-BBE7-D0333E8F106A-- From superuser@gmail.com Fri Oct 4 16:09: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 1B81021F9B86 for ; Fri, 4 Oct 2013 16:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 Sr14Cs57Ntrc for ; Fri, 4 Oct 2013 16:09:16 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8729A21F9C83 for ; Fri, 4 Oct 2013 16:09:12 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id y10so4887449wgg.12 for ; Fri, 04 Oct 2013 16:09: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 :content-type; bh=efzcGdq+VQpVxM+MsSXAWOYeJXaaGCUDkeBCZoN0gWk=; b=IJdDTdjBsbqCDVKkwGfefJNcjchBuHMpMA+AkaMOEDsvbEI9GfTtD1/1hSlCY1h6hX Sw78N3np9TG6Cx4Eeyrmyh/mXuZndJ4QdUcYQWMkUE6TyohSy+jKuJPUSW9suIg6djSp gT3HASCIJFYs/DUdBjcsD/O4Gp2aOKW6HmwSwur6IrSEhCNDWp9SadCiaH02y2C3Sq89 8vxpBt3QgVz58yG+QLjXjowqsyMBxWuDFcmzQ4f+UMVuDLGAynYRbt2Xze3UZZjr2Owa W7CurFzGdU/LkTr0SeZ+9W9HpsjLcv/LoOA/ZAthptOtH/IfkDXvCEv1rCryatYhAlce jyMg== MIME-Version: 1.0 X-Received: by 10.180.72.226 with SMTP id g2mr9347311wiv.52.1380928149442; Fri, 04 Oct 2013 16:09:09 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Fri, 4 Oct 2013 16:09:09 -0700 (PDT) In-Reply-To: <20131004173149.22991.14931.idtracker@ietfa.amsl.com> References: <20131004173149.22991.14931.idtracker@ietfa.amsl.com> Date: Fri, 4 Oct 2013 16:09:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=f46d043890edced74904e7f2636e Subject: [spfbis] Fwd: NOMCOM 2013 - Second Call for Nominations - two weeks left X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Oct 2013 23:09:17 -0000 --f46d043890edced74904e7f2636e Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: NomCom Chair 2013 Date: Fri, Oct 4, 2013 at 10:31 AM Subject: NOMCOM 2013 - Second Call for Nominations - two weeks left To: IETF Announcement List Cc: IETF Discuss List Nominations for the IESG, IAB, and IAOC are due to the Nomcom by Friday, 18 October, 2013. Is there someone you work with at IETF who has leadership potential and a growing track record? Please read the Nomcom call for nominations and consider nominating her or him. Or several folks! Deadline for nominations is October 18. Nominate soon to give your nominee(s) plenty time to fill in the questionnaire. Information about the desired expertise for positions is here: https://datatracker.ietf.org/nomcom/2013/expertise Lots more, including which positions are open, how to make a nomination, and how to send us your feedback on the desired expertise, follows. IETFers, let's hear from you! Make nominations, accept nominations! If you have any questions about the process, feel free to get in touch with me. Best regards, Allison for the Nomcom Allison Mankin Nomcom Chair 2013-14 ----- The Info You Need for Nominating ----- The 2013-14 Nominating Committee (Nomcom) is seeking nominations from now until October 18, 2013. The open positions being considered by this year's Nomcom can be found later in this section, and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2013/ Nominations may be made by selecting the Nominate link at the top of the Nomcom 2013 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2013/nominate/ Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom13 at ietf.org. If you nominate by email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you use email, please use a separate email for each person you nominate, and for each position (if you are nominating one person for multiple positions). Self-nomination is welcome! No need to be shy. Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. In all other ways, the confidentiality requirements of RFC 3777/BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 18, 2013. Please submit your nominations as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which we are accepting nominations: IAOC Chris Griffiths IAB Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF. Also, please give serious consideration to accepting nominations you receive. The summaries of the desired expertise for the positions, developed by the respective bodies, are found at: https://datatracker.ietf.org/nomcom/2013/expertise/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. You can send us email about this to nomcom13 at ietf.org, and we will use this feedback actively. Thank you for your help in nominating a great pool of strong and interesting nominees! --f46d043890edced74904e7f2636e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


---------- Forwarded me= ssage ----------
From: NomCom Chair 2013 <nomc= om-chair-2013@ietf.org>
Date: Fri, Oct 4, 2013 at 10:31 AM
Subject: NOMCOM 2013 - Second Call fo= r Nominations - two weeks left
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: IETF = Discuss List <ietf@ietf.org>


Nominations for the IESG, IAB, and IAOC are due to the Nomcom by Fr= iday, 18 October, 2013.

Is there someone you work with at IETF who has leadership potential and a g= rowing track record? Please read the Nomcom call for nominations and consid= er nominating her or him. Or several folks! Deadline for nominations is Oct= ober 18. =A0Nominate soon to give your nominee(s) plenty time to fill in th= e questionnaire. Information about the desired expertise for positions is h= ere:
=A0 =A0 =A0 =A0 =A0 =A0https://datatracker.ietf.org/nomcom/2013/exper= tise

Lots more, including which positions are open, how to make a nomination, an= d how to
send us your feedback on the desired expertise, follows.

IETFers, let's hear from you! =A0Make nominations, accept nominations!<= br>
If you have any questions about the process, feel free to get in touch with= me.

Best regards,

Allison for the Nomcom

Allison Mankin
Nomcom Chair 2013-14

----- The Info You Need for Nominating -----

The 2013-14 Nominating Committee (Nomcom) is seeking nominations
from now until October 18, 2013. The open positions being considered
by this year's Nomcom can be found later in this section, and also on this year's Nomcom website:

htt= ps://datatracker.ietf.org/nomcom/2013/

Nominations may be made by selecting the Nominate link at the top of
the Nomcom 2013 home page, or by visiting the following URL:

https://datatracker.ietf.org/nomcom/2013/nominate/

Note that nominations made using the web tool require an ietf.org
datatracker account. You can create a datatracker ietf.org account
if you don't have one already by visiting the following URL:

https://datatracker.ietf.org/accounts/create/

Nominations may also be made by email to nomcom13 at ietf.org.
If you nominate by email, please include the word "Nominate" in t= he Subject
and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you
are making the nomination. If you use email, please use a separate email fo= r
each person you nominate, and for each position (if you are nominating one<= br> person for multiple positions).

Self-nomination is welcome! =A0No need to be shy.

Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing<= br> Nominees" described in RFC 5680. =A0As stated in RFC 5680: "The l= ist of
nominees willing to be considered for positions under review in the
current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a
datatracker account may access the lists. =A0In all other ways, the
confidentiality requirements of RFC 3777/BCP10 remain in effect. =A0All
feedback and all Nomcom deliberations will remain confidential and will
not be disclosed.

In order to ensure time to collect sufficient community feedback about
each of the willing nominees, nominations must be received by the
Nomcom on or before October 18, 2013. =A0Please submit your nominations
as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013.

The list of people and posts whose terms end with the March 2014 IETF meeti= ng,
and thus the positions for which we are accepting nominations:

IAOC
Chris Griffiths

IAB
Bernard Aboba
Marc Blanchet
Ross Callon
Eliot Lear
Hannes Tschofenig

IESG
Barry Leiba (Applications)
Brian Haberman (Internet)
Benoit Claise (Operations and Management)
Gonzalo Camarillo (RAI)
Stewart Bryant (Routing)
Sean Turner (Security)
Martin Stiemerling (Transport)

Please be resourceful in identifying possible candidates for these
positions, as developing our talent is a very crucial requirement for
the IETF. =A0Also, please give serious consideration to accepting nominatio= ns
you receive.

The summaries of the desired expertise for the positions, developed by the<= br> respective bodies, are found at:

https://datatracker.ietf.org/nomcom/2013/expertise/

In addition to nominations, the Nomcom seeks community input on
the positions themselves. =A0We need and welcome the community's
views and input on the jobs within each organization. If you
have ideas on the positions' responsibilities (more, less,
different), please let us know. =A0You can send us email about this to
nomcom13 at ietf.org, and= we will use this feedback actively.

Thank you for your help in nominating a great pool of strong and interestin= g
nominees!




--f46d043890edced74904e7f2636e--