From sm@elandsys.com Sat Sep 1 00:54:14 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492D121F84E6 for ; Sat, 1 Sep 2012 00:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjjaDhEIcTKA for ; Sat, 1 Sep 2012 00:54:13 -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 7EC7A21F84D4 for ; Sat, 1 Sep 2012 00:54:13 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.222]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q817s1Rw001286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 1 Sep 2012 00:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346486052; bh=iN7Ai2jF+2KKWuK8bbvGLPa91hV0hjbTLRBAUjAmZGA=; h=Date:To:From:Subject:Cc; b=r7RHNUoVXKVywpNowq49KEGzI2kr0x66GrSjG2+dR7zJuGRr65BCGvyTYSM0qgtWX gn367EZMGRDLSwNbFtVp1I1msfiT3XJ+TO33KZh0C9USb0vSelT9RzV7pyVpQVB1lK ijWKmSenvKZwrO0diEaKavZfmnb3Pm/u5LqsagYE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346486052; i=@elandsys.com; bh=iN7Ai2jF+2KKWuK8bbvGLPa91hV0hjbTLRBAUjAmZGA=; h=Date:To:From:Subject:Cc; b=orqpID2q56rOhicQUlw8sf6vsVHAlzctkDbDVmUHtqsJgOnw7N0KzJdZF/tW5Dn6U FRFoARmnPd70uKoZRrGp7/Wgrg2qSjtRliuyduzZ25cJgpD6iodI2FAe5epcR0hHPX WlGIXBk5Xgh/r3Mwy/E76XbUDW/okvWSo9YB4Abg= Message-Id: <6.2.5.6.2.20120831223438.09fe98d8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 31 Aug 2012 23:14:45 -0700 To: spfbis@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Section 1 of raft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 07:54:14 -0000 Hello, There comments are about Section 1 of draft-ietf-spfbis-4408bis-06. "Furthermore, many domain owning ADMDs (ADministrative Management Domains, see [RFC5598]) are understandably concerned about the ease with which other entities can make use of their domain names, often with malicious intent." The "domain owning ADMDs" wording is unclear. As a nit, the ADMDs should be exapanded on first using the acronym first. 'Compliant ADMDs publish Sender Policy Framework (SPF) records in the DNS specifying which hosts are permitted to use their names, and compliant mail receivers use the published SPF records to test the authorization of sending Mail Transfer Agents (MTAs) using a given "HELO" or "MAIL FROM" identity during a mail transaction.' The switch from "domain holders" to ADMDs makes the above unclear. Section 1.1 is about "Protocol Status". "The goal of this document is to clearly document the protocol defined by earlier draft specifications of SPF as used in existing implementations." According to the SPFBIS Charter, the document is work based on RFC 4408. The charter does not mention earlier draft specifications. I suggest finding a better title for the subsection and reviewing the sentence. Section 1.2 is about "Experimental History". RFC 6686 discusses about the experiments. The quick fix would be to drop the subsection. From Section 1.3.3: 'This document is concerned with the portion of a mail message commonly called "envelope sender", "return path", "reverse path", "bounce address", "5321 FROM", "MAIL FROM", or RFC5321.MailFrom. Since these terms are either not well defined or often used casually, this document uses "MAIL FROM" for consistency. This means the RFC5321.MailFrom as defined in [RFC5598]. Note that other terms that might superficially look like the common terms, such as "reverse- path", are used only with the defined meanings from normative documents.' There is a normative reference to RFC 5321 and RFC 5598. The definitions in the document are a mix of RFC 4408 and RFC 5598. I suggest choosing one of the for consistency. In Section 1.3.5: "There are [RFC4408] features that are marked "deprecated". In the context of this document, deprecated means that senders SHOULD NOT publish SPF records that make use of such features because they might be removed entirely in future updates to the protocol. Such features do, however, remain part of the SPF protocol and receiving systems MUST support them unless this document explicitly says otherwise." The above introduces two new RFC 2119 key words. The text mentions senders while ADMDs are mentioned in previous subsections. I suggest dropping the RFC 2119 key words. There isn't any mention of "deprecated" in Section 3. Section 5.5 deprecates the "ptr" mechanism. Regards, S. Moonesamy From sm@elandsys.com Sat Sep 1 01:16:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D81E21F850D for ; Sat, 1 Sep 2012 01:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eEkqXJepzFR for ; Sat, 1 Sep 2012 01:16:44 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D674621F8514 for ; Sat, 1 Sep 2012 01:16:43 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.222]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q818GUJ5028014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 1 Sep 2012 01:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346487402; bh=PiWiHXBFXhqTQuUH5X4jqE0ExXl1P+tjQwirLt1jjvE=; h=Date:To:From:Subject:Cc; b=HpNgWSkooH3N753QSRupkqxxxQ3E7aOXfvrN61Gwhe4ifM3hG44yTFVTuqj2yT6mG nbo8/9dxNeMlJ/SNS+Ny7TuX06I29dZ8CF0ooCk6E5WTTlIgiPKrl7Fqg0oFevKhO8 fSG+IKXanSIK7pCxFEa5RiaWFRitDik9t4M6W5/w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346487402; i=@elandsys.com; bh=PiWiHXBFXhqTQuUH5X4jqE0ExXl1P+tjQwirLt1jjvE=; h=Date:To:From:Subject:Cc; b=JRHULhY2csBAyqzpo/vwgprg/Nv2c6Allfr7WJU+fJXU719dOPlcU61OumteiDONd xCfHJBLy3P2Qutjn/O9vZR5nIEXZkcIKzWGFWONVusFY+a3v99Q1PzS4DSzNwZzGXz CpXjFnUxCQWR8e5PlBAf307H1vEQjj3fs8j5L4MQ= Message-Id: <6.2.5.6.2.20120831232330.09fe9648@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 01 Sep 2012 01:14:16 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Section 2 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 08:16:46 -0000 Hello, These comments are about Section 2 of draft-ietf-spfbis-4408bis-06. From Section 2.1 of RFC 4408: 'It is RECOMMENDED that SPF clients not only check the "MAIL FROM" identity, but also separately check the "HELO" identity by applying the check_host() function (Section 4) to the "HELO" identity as the .' And Section 2.1 of the draft: 'SPF verifiers MUST check the ""MAIL FROM" identity if a completed "HELO" check has not reached a definitive policy result by applying the check_host() function to the "MAIL FROM" identity as the .' There is a change from RFC 2119 recommendation to RFC 2119 requirement in the above. This is related to Issue #15. 'Additionally, since SPF records published for "HELO" identities refer to a single host, when available, they are a very reliable source of host authorization status.' I don't recall this being discussed on the mailing list. I am making a note of it as it is a change from RFC 4408. 'Note that requirements for the domain presented in the EHLO or HELO command are not always clear to the sending party, and SPF verifiers MUST be prepared for the "HELO" identity to be malformed or an IP address literal.' There is an additional RFC 2119 requirement compared to what is in RFC 4408. From Section 2.2 of RFC 4408: 'SPF verifiers MUST check the ""MAIL FROM" identity if a completed "HELO" check has not reached a definitive policy result by applying the check_host() function to the "MAIL FROM" identity as the .' From the draft: 'SPF clients MUST check the "MAIL FROM" identity. SPF clients check the "MAIL FROM" identity by applying the check_host() function to the "MAIL FROM" identity as the .' It would be better to have this in one sentence to have the RFC 2119 requirement clear. In Section 2.3: 'An SPF-compliant domain MUST have valid SPF records as described in Section 3.' This is similar to what is in RFC 2119. From RFC 4408: 'If domain owners choose to publish SPF records, it is RECOMMENDED that they end in "-all", or redirect to other records that do, so that a definitive determination of authorization can be made.' And the draft: 'If domain owners choose to publish SPF records and want to support receivers making negative authorization determinations, then they MUST publish records that end in "-all", or redirect to other records that do, otherwise, no definitive determination of authorization can be made. Potential issues and mitigations associated with negative determinations are discussed in Section 9.' The terminology (domain owners in this case) is inconsistent when compared with other sections of the draft. The RFC 2119 requirement is a significant change. From the draft: "This can be as much as 30 days." There was a short discussion about this change on the mailing list. From Section 2.4: 'A mail receiver can perform a set of SPF checks for each mail message it receives.' What is a mail receiver? "When a mail receiver decides to perform an SPF check, it MUST use a correctly-implemented check_host() function (Section 4) evaluated with the correct parameters." This is an unnecessary RFC 2119 requirement. "Although the test as a whole is optional, once it has been decided to perform a test it MUST be performed as specified so that the correct semantics are preserved between publisher and receiver." A new RFC 2119 has been added compared to RFC 4408. 'Implementations MUST take care to correctly extract the from the data given with the SMTP MAIL FROM command as many MTAs will still accept such things as source routes (see [RFC5321], Appendix C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]).' There is a new RFC 2119 requirement compared to RFC 4408. As a nit, the above text creates two normative references causing more required reading. From Section 2.5 of the draft: "Performing the authorization other than using the return-path and client address at the time of the MAIL command during the SMTP transaction can cause problems, such as the following" The usage of return-path is inconsistent with Section 1.3.3. From RFC 4408: "Generating non-delivery notifications to forged identities that have failed the authorization check is generally abusive and against the explicit wishes of the identity owner." And the draft: "Generating non-delivery notifications to forged identities that have failed the authorization check is a source of backscatter and SHOULD be avoided. [RFC3834] section 2 describes backscatter and the problems it causes." A RFC 2119 recommendation was added. Section 2 of RFC 3834 is about automated responses. From Section 2.5.1 of RFC 4408: 'A result of "None" means that no records were published by the domain or that no checkable sender domain could be determined from the given identity. The checking software cannot ascertain whether or not the client host is authorized.' And the draft: 'A result of "none" means either (a) no syntactically valid DNS domain name was extracted from the SMTP session that could be used as the one to be authorized, or (b) no TXT records were retrieved from the DNS that appeared to be intended for use by SPF verifiers.' That could be considered as a clarrification. Section 2.5.4 generated significant discussion. Regards, S. Moonesamy From vesely@tana.it Sat Sep 1 04:06:50 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE48521F84FA for ; Sat, 1 Sep 2012 04:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.324 X-Spam-Level: X-Spam-Status: No, score=-4.324 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWo5tva8Jz8F for ; Sat, 1 Sep 2012 04:06:50 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0D14C21F84F8 for ; Sat, 1 Sep 2012 04:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346497607; bh=yBhg6t6YIMvlvVD1Akc7akfiUGxDq7FlD9lDnE8OCw4=; l=1843; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=dqDdsLT6iy1TrsGBKx4GLqIKyMywc9hk797yI+0+suX2MTxsEqYn8c64sQji8figh ggCdwhG18G68eEikBbYcPw0FuHrL/dGP+nd1o6tDbKI7oiEjl/LBknUh3SO371WvAG zBIzru+LGBHqMPvQ25jtVGHl28yTXQoufMXyEZE0= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 01 Sep 2012 13:06:47 +0200 id 00000000005DC033.000000005041EC47.00001560 Message-ID: <5041EC47.3010908@tana.it> Date: Sat, 01 Sep 2012 13:06:47 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1346376279.88598.YahooMailClassic@web125403.mail.ne1.yahoo.com> <54350d13-e507-44b7-a4f6-03e19399c171@email.android.com> <5040732A.4080802@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 11:06:51 -0000 On Fri 31/Aug/2012 16:18:32 +0200 Murray S. Kucherawy wrote: > On Fri, Aug 31, 2012 at 1:17 AM, Alessandro Vesely wrote: >> Non-match makes sense in case the record is correct, but the parameter >> is malicious, e.g.: > > Is there a deterministic way to identify abuse? > > "Do X if the input data is malicious" is not a recipe for normative > guidance. Right. Scott said to leave specific wording aside for a moment. I don't think it's worth attempting an exact definition of "malicious" anyway. An idea is to do something like the following after macro expansion but before DNS lookup: if (is_malformed(term.domain) || strlen(term.domain) > 63) { if (is_malformed(parameter) || strlen(parameter) > REASONABLE_LENGTH) return NO_MATCH; report_error(spf_rec, &term, ERR_MALFORMED); return PERMERROR; } > We need to pick the one that's more generally applicable, and move > forward with it. It seems to me that not only local macros are involved, but also intermixed use of domain macros during HELO evaluation, and %h during MAIL FROM. We could have restricted the use of those macros to terms that imply no DNS query, such as explanations. Now, assuming we didn't intend to do that, we need to grant them a fair usability. Taking into account that SPF grammar provides no way to guard against malformed parameters, /any/ non-trivial use of those macros can result in a malformed domain, potentially. Hence, inflexibly mandating permerror implies an unintentional penalty for users of those macros, inasmuch as (1) there is an attack path whereby an abuser of the domain name can get --by design-- a permerror rather than the stipulated result, and (2) the rr=e tag of RFC 6652 will not be limited to real errors, but include items rather akin to rr=f or similar. From agthisell@yahoo.com Sat Sep 1 08:31:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF4721F87D0 for ; Sat, 1 Sep 2012 08:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GTBGPD6EZAg for ; Sat, 1 Sep 2012 08:31:15 -0700 (PDT) Received: from nm20-vm2.bullet.mail.ne1.yahoo.com (nm20-vm2.bullet.mail.ne1.yahoo.com [98.138.91.208]) by ietfa.amsl.com (Postfix) with SMTP id A235921F87CF for ; Sat, 1 Sep 2012 08:31:15 -0700 (PDT) Received: from [98.138.90.49] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 01 Sep 2012 15:31:10 -0000 Received: from [98.138.226.166] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 01 Sep 2012 15:31:10 -0000 Received: from [127.0.0.1] by omp1067.mail.ne1.yahoo.com with NNFMP; 01 Sep 2012 15:31:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 186346.4128.bm@omp1067.mail.ne1.yahoo.com Received: (qmail 87265 invoked by uid 60001); 1 Sep 2012 15:31:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346513469; bh=/52yBFvvuWioa8k9Y0KaPBg7bLudbMF7j/S13FkdtIM=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=s5Y2cz55S248UH18ArPXs7BGBwUY+hAjVywJ81lAyHZFuev5v14T7cRvVpgZmomPu++E8Hd1l0m6tJFwAHT+WCADlFsJALRQhUcRa+WgZtcnhOl2GzUymvOgJdhBCDG7dwYWyDzZvfhcYRWzrOi2NPNAxcipFMhvf62I0u+GEVY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=jFEV/2iPEVnmoH4cmerw6GxbYsOGrNb+CbkyYeLdzlO5mwkLFv3ZI8DtE+pcbkNzaewrvWO9YyWdN+XRkFszKHeGjzcsbXgDj1spjeiQrfG6TNBKOdRwXc+D29/AqdMOGu8ANMTno8T8WTZMfy9JSHCpLgd3QFmvxVpl6pjnaKI=; X-YMail-OSG: _SvGlw0VM1m_61bWKgYrAawvmSLhIGFCiiCBtjtHyUIj2bE 9MT2vrC.DPTtuYwPMUdUvgoCBmJ1omBR0y1rhEyxz_Dz00XuNX7uHxweOHLL r39OxmfNnpg4kzrgn5pDltB3utac_WAvnsrMD_s_nFVqkWm5qnsfEeak8kAK KSPIjudwNacutKPzYugZdWSRuJVfmr3pa.5lmpWfRMjNyawTe2dufKeTd18x UdXzUM5Tl_CHyK9RPjgamO7Je8Wo29rmGtoT57zDsrMme1os9NN4zyd3H128 DHZywZuvW.JIOHzMaY_589a1Bl4V.S8hERcgR0hS7tK6dvq1EidHQ68EAPt5 ZbZE_gkeHags8Xb8lcrdEBCmOycdPRsgOf6CmJgdQ3mtrfEYAtxCvUcpdAqF a8d2w6kIV82VSHh63YKmbPgh24pbXLD0LYMtT6Wqn8zmj1gDIrVT8vFXpDEQ 09veSSsXJr4NG_ZW21qg- Received: from [71.61.133.134] by web125403.mail.ne1.yahoo.com via HTTP; Sat, 01 Sep 2012 08:31:09 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346513469.86413.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Sat, 1 Sep 2012 08:31:09 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 15:31:16 -0000 I never much liked section 9, it seemed to be too much of a how-to/advocacy/anti-FUD section. RFC 4408 is, IMHO, better than earlier drafts of SPF, but times have changed. SPF has not, as some critics claimed, destroyed email and the DNS and we no longer need to refute such claims in the draft. The number of people demanding "I'll never adopt SPF until I can handle " has given way with people just using a simpler subset of SPF. We no longer need to have a section of "yes, you can handle by this!" in the spec. That said, I'm not sure the charter really allows ripping it out. > From RFC 4408 Section 9.1: > > 'Domains that wish to be compliant with this specification will need > > IETF specifications do not generally mention compliance. During the drafting of early SPF specs, there were a lot of people complaining that they would be forced to adopt SPF. Wording such as this was mostly to make it clear that SPF was optional. We probably should have said "wish to adopt" or some such thing. I don't think there is as much FUD/confusion now, so we can probably drop the weasel words entirely. > From Section 9.2.1 of the draft: > > "Mailing lists have to be aware > > It is not clear why there is even a requirement to RFC 1123. I'm not sure what is not clear about it. Section 5.3.6 of RFC 1123 talks about what mailing lists must do and the difference between an "alias" and a "list". > The term used has always been "alias" and not "mail list". I'm confused by this. For example, section 3.9 of RFC 5321 is titled "mailing lists and aliases" and discusses the difference between these two models. > "Then, a specialized DNS server can be set up to serve the > _spf_verify subdomain that validates the local-part." > > This text was also in RFC 4408. Are there any widespread specialized DNS > servers providing this type of service? I don't know about today. At the time that this was written, two people had come forward to say they were doing this. I suspect that there never were many. Similar things can be said about the example of a rate-limiting DNS server. Yeah, at least one existed at one time, but it is an edge-case that people have not seen a great need to deal with. From vesely@tana.it Sat Sep 1 09:16:49 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340F91F041A for ; Sat, 1 Sep 2012 09:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.621 X-Spam-Level: X-Spam-Status: No, score=-4.621 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqXAav7C4v7F for ; Sat, 1 Sep 2012 09:16:48 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 372E71F0419 for ; Sat, 1 Sep 2012 09:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346516204; bh=PJccsxgLrQUSitDma9r2ni+ilZ1wBhpQ2k4yLGI13Lo=; l=1316; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=QNRsSjBvXc+gCJwp02Je/VXiheNwvLSKOZfzLul/NLU7V7i8h8UcsZgsrG0YOpTLz SuO6LRbDhHRgt206x4ilxcUBTmsQ/VDVylgCzn0Y3q9q/q0a6eF2jPSxQhPM5aJSO/ 6GuuF23bkzpTKltyAUWZb7rSSdrpHZw95UjFKoyc= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 01 Sep 2012 18:16:44 +0200 id 00000000005DC033.00000000504234EC.000058F7 Message-ID: <504234EC.8000505@tana.it> Date: Sat, 01 Sep 2012 18:16:44 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <2385202.ToyOPapQOP@scott-latitude-e6320> In-Reply-To: <2385202.ToyOPapQOP@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 16:16:49 -0000 On Fri 31/Aug/2012 20:51:30 +0200 Scott Kitterman wrote: > On Friday, August 31, 2012 10:39:19 AM Murray S. Kucherawy wrote: >> For example: >> >> > > I think (with the RECOMMENDED change already discussed upstream) this is > pretty good. Can we squeeze the suggestion to use the SPF-Received key-value- > list to add details to A-R into here? I don't think it needs to be more than > 'here's a reasonable way to do it', but I'd like to at least suggest something > if people want to go down this path (and it helps support the example, which > does exactly that). I dislike suggesting a kludge as 'a reasonable way to do it'. I know that examples are not normative, but that one is likely the single one example of A-R usage that we are going to give, hence its value is almost that of a SHOULD, RFC 2119 notwithstanding. *Standardizing kludges is evil*. If the forensics data that Received-SPF: conveys is what is wanted, then use that field, period. For the security aspect, I already mentioned the solution of renaming existing fields to Old-Received-SPF before adding new ones: http://www.ietf.org/mail-archive/web/spfbis/current/msg01029.html The package implementing that is in multiple Linux distributions, so it can be considered widespread, no? From vesely@tana.it Sat Sep 1 10:04:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF8A1F0419 for ; Sat, 1 Sep 2012 10:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.622 X-Spam-Level: X-Spam-Status: No, score=-4.622 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-0KaOiY8S80 for ; Sat, 1 Sep 2012 10:04:46 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFA41F040A for ; Sat, 1 Sep 2012 10:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346519085; bh=UqSHc/TLmtIwF1SFqvm9pGxneO/yuZIJ4ZUdfkDnZlA=; l=1981; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=U+TI4zs+6g3rtLTc4Ae1MTAGvXI+eRdUTXPQXCIWaRoHKQIdtPKaW+iW3YR+jCVhO m3paGliE6fqWBTta2Q0I1sJbP7twwKFUEQcyo54DKkNqef1FZI+LBLPrGm/CfrFKyF UGRKphLQqfPiTc1XijuzlapgMvsOB4J9Y33erWtw= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 01 Sep 2012 19:04:44 +0200 id 00000000005DC033.000000005042402D.000062DC Message-ID: <5042402C.10009@tana.it> Date: Sat, 01 Sep 2012 19:04:44 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <6.2.5.6.2.20120831180612.098d0090@elandnews.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 17:04:47 -0000 On Sat 01/Sep/2012 05:26:34 +0200 Murray S. Kucherawy wrote: > On Fri, Aug 31, 2012 at 6:23 PM, S Moonesamy wrote: >> [At 17:54 31-08-2012, Murray S. Kucherawy wrote:] >>> Perhaps the simplest thing to do is to start an individual submission >>> to collect this stuff, and move it out of here. +1 >>> The trick, though, is that RFC4408bis itself should then refer >>> to it, which will delay its publication until that document >>> finds a new home or an AD sponsor and is also published. Isn't it possible to just mention "an applicability statement to be published next" sort of thing? Part two will then refer to RFC4408bis. >>> (And I can tell you that we're very unlikely to take it in >>> APPSAWG.) >> >> I don't know what to suggest. I won't suggest APPSAWG. :-) > > The APPSAWG co-chair thanks you. (Seriously, though, there are > several procedural things blocking that path.) +1 (as APPSAWG participant) > If we do split the work in this way, we technically still hit our > deliverable even if it lands in the RFC Editor queue and stalls there > until the second document finishes via whatever path is chosen for it. Rechartering is the best way, IMHO. > We just have to accept the unpredictable delay. The only work then > is to decide what parts of the current Section 9 are required to make > the document whole (those should stay) and which constitute > non-critical implementation advice (those should move). > > It's possible that new content from other sections is also a candidate > for such a migration, which would make Arthur happy. Yes, I don't think splitting the document is a silly idea. Indeed, it reflects the "second life" of SPF pretty well. While some parts of Section 9 are almost fine where they are, any rejection-related advice should be moved to part two, possibly including the exp= modifier. > Oh, and you need to find an editor(s). ;-) May I volunteer for that? From agthisell@yahoo.com Sat Sep 1 10:43:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3521F041B for ; Sat, 1 Sep 2012 10:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBj3bDB9NAE1 for ; Sat, 1 Sep 2012 10:43:25 -0700 (PDT) Received: from nm5-vm2.bullet.mail.ne1.yahoo.com (nm5-vm2.bullet.mail.ne1.yahoo.com [98.138.90.153]) by ietfa.amsl.com (Postfix) with SMTP id 74C3E1F041A for ; Sat, 1 Sep 2012 10:43:24 -0700 (PDT) Received: from [98.138.90.53] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 01 Sep 2012 17:40:56 -0000 Received: from [98.138.89.197] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 01 Sep 2012 17:40:56 -0000 Received: from [127.0.0.1] by omp1055.mail.ne1.yahoo.com with NNFMP; 01 Sep 2012 17:40:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 626691.71487.bm@omp1055.mail.ne1.yahoo.com Received: (qmail 25311 invoked by uid 60001); 1 Sep 2012 17:40:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346521256; bh=3jpV3Ua3jRGiv43YrzUpvcB4eVH9jx3vYKl8Kc0yViw=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=CFfUVkxuyC3HGN9RhpgNjNRVpYJAO97NUDtp1PB2TpoPjgZeypszUAm3WuUA1ojZM8AJGqBTU8DN4LGBSUYxQWfJD8CNEpYBHt8yaAHMdepOsgprNy0fajgNpuOHJZzY5HcsaZqxuSPVeCLTg4W4FLjek+XIpgZm8uYYPfiTk1A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=PVnBwxvXiSYvs0qwxUU34c2evrBH9mZyP8agQXnY5V3jWaxFjxjbscSmQ05DAsVIwV4Sxya8r6Aj8s755ZNRJADwxaZYFXVCVYLkzpHHzmIZIO+wVgKTZJ1crmcGFa6/z5C3HLcYoekFmOa5DuSfnEmqXQM7OwpiTsoCrkIIyjY=; X-YMail-OSG: rN5CnecVM1mS9Z_YLVFIIsrEu8IIf4md_.DcBBbkm4_sQcp 3K3B0DTBKlB0ymXZB85iVghGxUiQkQUIhzkV6QFFbvnz16suoUEgvD894UUm _YuNGMrY87zY6DhHG.FggM4oXD0BlLBW.jtpWBDy3O4Mj4E.L.jTS9So32kt _IaDBqKeKlI3Gd65HS4dnnBQZoY615NOg0omt9bGwkCWzE.OFDZyzLL4ehdD mO6qxLj3eXxvJymcoBMSTN61Ttpru72Fu2QZ7q2yUWdTZB8FtAWd6ThFYbTd ndP0JlthSxFf7o0xRhuFKPvXjNHGV.NuvjgrolblPhmI83FmKq6fzFQQvJc8 I_cT4iBlpKeb96vmJX5MmDhvprQF1F148EU__TXzz5WUelFDJSiiNQzKfGeV VPRmyL6u6PdnSHMoyGVTcaHQHjaX_2mcYbS8fGgc9oSm3oGi.GCPNbEJCun4 gLqlPV6eMTSEKt.IB10Y- Received: from [71.61.133.134] by web125406.mail.ne1.yahoo.com via HTTP; Sat, 01 Sep 2012 10:40:56 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346521256.15470.YahooMailClassic@web125406.mail.ne1.yahoo.com> Date: Sat, 1 Sep 2012 10:40:56 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] if RFC 4408 is split in two... X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 17:43:26 -0000 >> Oh, and you need to find an editor(s). ;-) > > May I volunteer for that? IMHO, it would make a lot more sense to have Scott be the editor of both drafts. One editor would make it much easier to make sure nothing was put into both drafts, nor dropped from both drafts, nor having conflicting text between the drafts. Besides, I think Scott is doing an excellent of editing the SPF draft and I can't think of anyone who knows more about the current deployment and operation of SPF than Scott. From sm@elandsys.com Sat Sep 1 10:44:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B551F041C for ; Sat, 1 Sep 2012 10:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmYER6CVqCKU for ; Sat, 1 Sep 2012 10:44:03 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 015A91F041A for ; Sat, 1 Sep 2012 10:44:02 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.222]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q81Hho47023629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 1 Sep 2012 10:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346521441; bh=BLxAiIQAWGQjM2mjcU+2YZ1WLdGtOOTXZUHBMpJM4uw=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=YNaaQXFmf79tdkI7LOx6Mk/mRPgCPvpJf1MOXZuzavllRY5rLXHH8ue4KCuUMqW0Z TRaRiDZ6RcSJTAF6oiH8KqoCxBmZMY4AIvlxPfN34pc69fqcv3JX1Gnv3M31LpC2tF 2snzUezMtX6E4n22XlI6BQxC7xbsdPxgm9rDqUuU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346521441; i=@elandsys.com; bh=BLxAiIQAWGQjM2mjcU+2YZ1WLdGtOOTXZUHBMpJM4uw=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=bybORmZCfFBeRRCHkmzM0izAYf3Qcow/mMYEkSILdMZJFTf4PWkEP82xTcTNDp/Gk CYWZSomgRpAQwSq0k81NX8eYk5ilT7flnrGqiUgVkd1d7ZzR1AOjLm08UrpnURC6jl /0BH/7AEI1QwTK68L8HHFLsgyK0PBjKGdMDRJWuY= Message-Id: <6.2.5.6.2.20120901094420.093bbf88@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 01 Sep 2012 10:42:53 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1346513469.86413.YahooMailClassic@web125403.mail.ne1.yahoo .com> References: <1346513469.86413.YahooMailClassic@web125403.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 17:44:04 -0000 At 08:31 01-09-2012, Arthur Thisell wrote: >I'm not sure what is not clear about it. Section 5.3.6 of RFC 1123 >talks about what mailing lists must do and the difference between an >"alias" and a "list". RFC 5321 mentions that it updates RFC 1123 replacing the mail transport materials. As the text from Section 5.3.6 of RFC 1123 is in RFC 5321 I consider it as replaced. The RFC 1123 reference in that part of Section 9 is not needed. >I'm confused by this. For example, section 3.9 of RFC 5321 is >titled "mailing lists and aliases" and discusses the difference >between these two models. I'll quote the subsection for context: '9.2.2. Forwarding Services and Aliases Forwarding services take mail that is received at a mailbox and direct it to some external mailbox. At the time of this writing, the near-universal practice of such services is to use the original "MAIL FROM" of a message when re-injecting it for delivery to the external mailbox. [RFC1123] and [RFC5321] describe this action as an "alias" rather than a "mail list". This means the external mailbox's MTA sees all such mail in a connection from a host of the forwarding service, and so the "MAIL FROM" identity will not, in general, pass authorization.' The subsection discusses about forwarding services and aliases. The previous subsection (9.2.1) is about "Mailing Lists". My understanding is that a forwarding service is not a mailing list. I would drop the "rather than" part of the sentence to keep it simple and clear. On an unrelated note, RFC 5598 describes the enhanced Internet Mail architecture, reflecting the current service. RFC 5321 is a specification of the basic protocol for Internet electronic mail transport. The reader goes through three discussions about aliases. Regards, S. Moonesamy From dhc@dcrocker.net Sat Sep 1 10:59:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608241F041B for ; Sat, 1 Sep 2012 10:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7bEiTy0Kskd for ; Sat, 1 Sep 2012 10:59:51 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A00A81F041A for ; Sat, 1 Sep 2012 10:59:51 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q81Hxatw029091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 1 Sep 2012 10:59:36 -0700 Message-ID: <50424CFC.6080308@dcrocker.net> Date: Sat, 01 Sep 2012 10:59:24 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: S Moonesamy References: <1346513469.86413.YahooMailClassic@web125403.mail.ne1.yahoo.com> <6.2.5.6.2.20120901094420.093bbf88@resistor.net> In-Reply-To: <6.2.5.6.2.20120901094420.093bbf88@resistor.net> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 01 Sep 2012 10:59:37 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 17:59:52 -0000 On 9/1/2012 10:42 AM, S Moonesamy wrote: > On an unrelated note, RFC 5598 describes the enhanced Internet Mail > architecture, reflecting the current service. RFC 5321 is a > specification of the basic protocol for Internet electronic mail > transport. The reader goes through three discussions about aliases. I am, understandably, completely biased. However I'd urge that the current spec merely make a normative reference to RFC 5598, importing the terms and concepts that are relevant to SPFbis, rather than re-defining things. RFC5598 was motivated by the observation that the industry lacked much cohesiveness about email terminology and architectural detail. Anything that moves us towards the cohesiveness would be an improvement, IMO, and citing a common architecture/terminology document does move in that direction. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Sat Sep 1 11:18:06 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C22721F8766 for ; Sat, 1 Sep 2012 11:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB1NuHWw+HVg for ; Sat, 1 Sep 2012 11:18:05 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E0E21F8764 for ; Sat, 1 Sep 2012 11:18:04 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.222]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q81IHqTI029279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Sep 2012 11:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346523484; bh=XBNjPJG+XjbmnkrWbdW5rSd6Tk201UqB176hDgIlL8o=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YgAE0q03LbLEQM1tS1EWNAx8I051NB5ILx0th7Zen8d6dm+F+83tYeCipU/MMP3+i 2zVUnenmqWDogTfPn72P/pCRYEjepAW/6hUcgU6fEzPr4NhQ3vUsIZz7wBuTVKPKbs n4w/Oo7rJ//3rft2afAj2Nzt5E/jJDJRWgQR3fLY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346523484; i=@elandsys.com; bh=XBNjPJG+XjbmnkrWbdW5rSd6Tk201UqB176hDgIlL8o=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wD96XbT4VtxCR8Vtxu1S+6Lx7vZ/vwBNbfJ9SPEzBtvpLFBG16xfRhDRGrmFCe3Iz ZvvMCzItysB4MJ/6IG+pdt2GF+Gs5/qgWHQng2YQMjeJkBQvBYHu8AyLhBErL9OD74 SM6OaG0vilxzJ5eC4P5LR6vkUJ/vCgaey6VIjzmk= Message-Id: <6.2.5.6.2.20120901110019.093bcda0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 01 Sep 2012 11:17:12 -0700 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <5042402C.10009@tana.it> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <6.2.5.6.2.20120831180612.098d0090@elandnews.com> <5042402C.10009@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 18:18:06 -0000 Hi Alessandro, At 10:04 01-09-2012, Alessandro Vesely wrote: >May I volunteer for that? Yes, if there was a WG draft. :-) There wasn't much enthusiasm to work in such an I-D when the question came up. There is nothing stopping you from submitting an I-D. I'll ask for it not to be discussed on this mailing list as the working group is working on draft-ietf-spfbis-4408bis. Regards, S. Moonesamy From vesely@tana.it Sun Sep 2 05:17:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995FB21F8A31 for ; Sun, 2 Sep 2012 05:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.624 X-Spam-Level: X-Spam-Status: No, score=-4.624 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umSenVHFpj4J for ; Sun, 2 Sep 2012 05:17:20 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A163021F869A for ; Sun, 2 Sep 2012 05:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346588232; bh=nOVP42Ld4nwQYW1kO+5BMoguePnioCa7/XK33ThuU7M=; l=2746; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=MmynwPYotxatMM5y8sV1L2wjZbxmaWEzt7BLLare5qF451lM8Z5C/A8GZibDA9jgm JRTZ9QbKWZ5TPEEWDLiBP7BLPJxdYdnCdYMQv8cVGhg+6c2dsJhNljeSBqKSC8aqzT z1JuO6F/nF+1NPfw/SKlSIxH0ZU+NMXDVaVhZP6E= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 02 Sep 2012 14:17:12 +0200 id 00000000005DC035.0000000050434E48.00005C63 Message-ID: <50434E48.8060200@tana.it> Date: Sun, 02 Sep 2012 14:17:12 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <6.2.5.6.2.20120831180612.098d0090@elandnews.com> <5042402C.10009@tana.it> <6.2.5.6.2.20120901110019.093bcda0@resistor.net> In-Reply-To: <6.2.5.6.2.20120901110019.093bcda0@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [spfbis] SPF split and rechartering, facet of Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 12:17:21 -0000 Hi SM and All, On Sat 01/Sep/2012 20:17:12 +0200 S Moonesamy wrote: > At 10:04 01-09-2012, Alessandro Vesely wrote: >> May I volunteer for that? > > Yes, if there was a WG draft. :-) There wasn't much enthusiasm to > work in such an I-D when the question came up. There is nothing > stopping you from submitting an I-D. I had considered the possibility to submit a new I-D a few days before this thread began [28]. Then, this possibility resurfaced with this thread, superseding my earlier intention. So I'd need some more encouragement than that in order to go ahead and write it. [28] http://www.ietf.org/mail-archive/web/spfbis/current/msg02414.html > I'll ask for it not to be discussed on this mailing list as the > working group is working on draft-ietf-spfbis-4408bis. The new I-D and draft-ietf-spfbis-4408bis will depend on one another, since we consider moving some parts, such as sections 6.2 and 9.2, from one document to the other. That requires rough WG consensus. I'd imagine the procedure to reach it would go as steps 1-7 below (please correct me as necessary): 1 Someone prepares the new I-D and submits it, 2 WG participants look at it, then 3 WG participants agree on the split. Those three steps will consume some discussion resources on this list. It can be easily anticipated that discussing the split will naturally result in discussing some of the new I-D's details. Such items are to be saved for a later stage, but they will unavoidably consume some more discussion resource as they emerge. Then, assuming 1, 2, and 3 succeeded: 4 The new I-D is registered as a WG I-D, 5 duplicated parts are removed from draft-ietf-spfbis-4408bis, 6 rechartering process gets started, and 7 draft-ietf-spfbis-4408bis undergoes WGLC and IESG submission. I volunteered for editing the new I-D because I envision it as a much awaited clarification of receiver behavior: An applicability statement that specifies how a server may reject mail that is definitely abusive, based on the SPF results obtained during the earlier stages of an SMTP transaction. The purpose is to save the server's resources without disrupting the mail flow. It can stick to the original SPF catch, "you have to register a domain before you transmit DATA", taking into account also non-rewriting forwarders. While that obviously needs rechartering, step 5 above does not, since receiver behavior was never 2119-wise specified. However, some confidence about the fate of the new I-D --see steps 4 and 6-- is requisite in order to seriously consider step 5. OTOH, if there is still not much enthusiasm, please let's drop the idea of moving Section 9 for good, and have Scott post -07. From hsantos@isdg.net Sun Sep 2 07:58:24 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0656321F84A7 for ; Sun, 2 Sep 2012 07:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.925 X-Spam-Level: X-Spam-Status: No, score=-101.925 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBXnvt6AdQ0b for ; Sun, 2 Sep 2012 07:58:23 -0700 (PDT) Received: from mail.catinthebox.net (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id DD38121F8450 for ; Sun, 2 Sep 2012 07:58:22 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3268; t=1346597892; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=+H3ZrHL1i1T8WWWjbYXbljNpY3E=; b=VJu5JtHn3Wg1bdnpR7Dh FffyZnGv5rI+kBUDWLRWhqeeL3JaRyw/7M/ilPTFLyhrB/oUdhjZh4Du2vOdslU5 ZCzoIFOL+bdxVEXnIcKEn5r4a/BOAC4tlb/uOlgty+/A+D8R0Dha1kd6cp7spvv2 EcaBz+BarJ8K2f0oxCKVTcE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 02 Sep 2012 10:58:12 -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 2619679793.1452.5180; Sun, 02 Sep 2012 10:58:12 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3268; t=1346597680; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=50H0lMR NzRVFe9jPbK0n/k1M6R9v4sxRirUBBcLZZyc=; b=pzpxGdK9d1hjPYtfoSMYG8E kF0iagLNPvRcjI2V7QXAFZPF1aSWhE4G7rN6XsDd2pZPJQsP5SmyM8tV711j6Tnv on/DZql383uy6hcrTzaYSmeShAZHdaEybukqEFfLcKFa83MqCPekUe3Y+NBWjgVM KcwiNXqvfl3LLzTJix6w= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 02 Sep 2012 10:54:40 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3218478317.9.5384; Sun, 02 Sep 2012 10:54:39 -0400 Message-ID: <504373E7.2050600@isdg.net> Date: Sun, 02 Sep 2012 10:57:43 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alessandro Vesely References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <6.2.5.6.2.20120831180612.098d0090@elandnews.com> <5042402C.10009@tana.it> <6.2.5.6.2.20120901110019.093bcda0@resistor.net> <50434E48.8060200@tana.it> In-Reply-To: <50434E48.8060200@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF split and rechartering, facet of Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 14:58:24 -0000 Hi Alessandro, As an early system integrator and adopter of most email security related methods, protocols, experimental, standards, pilots, etc, I have long sought an ideal completion of the SPF "experiment" work to not only finally IETF standardize the protocol but to incorporate integrated related technologies that were learned, evolved and matured over the years. I firmly believe it can be done from a cooperative competition stand point where the IETF community benefits, accepted "chartered" work items can be completed and foremost, its done with little to no impact, "No Surprises" with backward compatibility. When one puts engineering trust on their industry peers who is able to do the work and documentation, there should be no losers except the problem it addresses. Unfortunately, as I cited in an April or earlier list post during the original charter revision discussions, repeated during the IETF83 SPF meeting jabber session, and now you reminded me here with your statement: "The new I-D and draft-ietf-spfbis-4408bis will depend on one another, since we consider moving some parts, such as sections 6.2 and 9.2, from one document to the other." [1] My main concern was basically how a fast track I-D, presumingly only possible as a BCP or Informational status RFC, could be used to redefine the charter, scope of the work, framework of the work, by promoting certain deployments that is not considered ideal or better universal for SPF operations. In this case I cited: "While I not at all adverse to good solid integrated designs, the concern was how it change the SPFBIS WG focus towards MARKING instead of REJECTION for FAIL policy results." [2] In other words, controversial ideas and methods can be embedded into WG work that are technically out side the work scope defined by the charter. The IETF83 SPF jabber session response to my channeled voice concern stated it is a recognized WGC management problem and it would watched and not intentionally allowed to all. I accepted this response. Refer to the actual phrased chair response [3] to the concern in the jabber audio (I seem to recall it wasn't scribed in the log). I agreed that it is a management problem, however, I had a concern it has become a recent trend to change a charter direction or get around controversial issues hence why I cited the concern. As long as it is consistent and persistent with the charter, does not open loopholes, back door methods to introduce specific methods and/or get around recommended methods in the main WG work product, etc, overall, "NO SURPRISES!" then IMO, I think it can work. But then again, to me, what will you write about? Do you have an ideal of an outline and purpose of such an I-D? How far does it go? I personally believe only 2.5.4 needs to be rewritten. We don't need section 7 or 9. -- HLS [1] SPF split and rechartering... http://www.ietf.org/mail-archive/web/spfbis/current/msg02568.html [2] Hector Santos follow up correction to IETFi83 SPF minutes notes http://www.ietf.org/mail-archive/web/spfbis/current/msg01408.html [3] IETF83 SPFBIS Session Audio Recording http://www.ietf.org/audio/ietf83/ietf83-252a-20120330-0855-am.mp3 From sm@elandsys.com Sun Sep 2 08:59:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7777521F84BF for ; Sun, 2 Sep 2012 08:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMANxk1HhsIE for ; Sun, 2 Sep 2012 08:59:47 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4B721F84B2 for ; Sun, 2 Sep 2012 08:59:47 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.236.63]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q82FxX1M018978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Sep 2012 08:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346601585; bh=Jl5QZdFes/uYRqsPIIjYfah/YDPZRgyUgB+kjBG6abk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=j55TFX96a+lRzrnVqJ5jGlIKzYFuQgq3gjCbpjvU3odPyCl8If2m6AS0awt7P590M y+XYTyBFsIMz5vMfGZDISxdfQQ7IxbHfNTaAaw/mjuuFfLHio0VXTWOVocyIn9efs3 UZrFX+j0iMhW/4MMS+cD87rXvYS1FOnTcf+lMNE8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346601585; i=@elandsys.com; bh=Jl5QZdFes/uYRqsPIIjYfah/YDPZRgyUgB+kjBG6abk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uN8vBkvv+U8lq2eKwlgeT81xHEzhprdKy+HwL1wH4WKnYTCIP3Uhxv+RTlyOhq14g g2HPOZoSZ+AAjNqAQexi4PM+iszj6aRl1oSv0Sxs6v+cETxh6rTd1+Qej5gyAtibBi 837ngHx2twcVjCBByxIfhjAi/kEDJ7gMT/VEosa4= Message-Id: <6.2.5.6.2.20120902081446.095d7fe8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 02 Sep 2012 08:17:59 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <5083185.69cuoQvzXM@scott-latitude-e6320> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <4094761.6jIeQ51N6G@scott-latitude-e6320> <6.2.5.6.2.20120831230912.0a0a7df0@resistor.net> <5083185.69cuoQvzXM@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 15:59:48 -0000 Hi Scott, Sorry, that sounded a bit too authoritarian. Your earlier comment is interesting. I never thought of the charter meaning that. Let me think about that and confer with my co-chair, but initially I don't think moving a section around is a big deal. I'll consider your comment and get back to you." Regards, S. Moonesamy From superuser@gmail.com Sun Sep 2 11:45:29 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8955D21F8458 for ; Sun, 2 Sep 2012 11:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.627 X-Spam-Level: X-Spam-Status: No, score=-3.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4-y1xemPc5n for ; Sun, 2 Sep 2012 11:45:29 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2D021F84E7 for ; Sun, 2 Sep 2012 11:45:27 -0700 (PDT) Received: by lahm15 with SMTP id m15so3882569lah.31 for ; Sun, 02 Sep 2012 11:45:26 -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=xj+i5huM/UIOtTnKMz+mlc5XPJ15Qz/8EFz1LvGMDcc=; b=eG/cHNfc0Hfx4N9XhFNfwnxmlijoDMZRS+pS1OnZG/8bx/Cggi0kocSQtHFn6TANRP IbdkpoGgW9H1BiJa3UHxpl3HjOrOWnYoiXaSNQBgr8msAc0CrP7vQe6zCgObr8jbGWYy X6fdQGSJY8+3H3Y0tdQWAr7BQQat/RRoOSwF3kL1KYqQuoiJ88m1aPyEc1cnusCz63GM wvMjvr03iU7z25BmubX9XCYCnxFzD/Ta39RIRCXrXH3uqL8/6nE5wQTnplWT3oyOfeJg Y1CGQ/u1/xHP/f2q1wtq6Kmm8+LpcHLLv9Dttxrf1XfuM4RndgOA0cZ7/HZZ5p2m7ApZ YMDg== MIME-Version: 1.0 Received: by 10.112.31.233 with SMTP id d9mr4663777lbi.116.1346611526449; Sun, 02 Sep 2012 11:45:26 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Sun, 2 Sep 2012 11:45:26 -0700 (PDT) In-Reply-To: <4094761.6jIeQ51N6G@scott-latitude-e6320> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <6.2.5.6.2.20120831213948.09fb49a8@elandnews.com> <4094761.6jIeQ51N6G@scott-latitude-e6320> Date: Sun, 2 Sep 2012 11:45:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 18:45:29 -0000 On Fri, Aug 31, 2012 at 10:35 PM, Scott Kitterman wrote: > The charter says: > >> Changes to the SPF specification will be limited to the correction >> of errors, removal of unused features, addition of any enhancements >> that have already gained widespread support, and addition of >> clarifying language. > > Moving section 9 to an appendix is none of those things. Here's a monkey wrench for that logic: Section 9, as it is explicitly non-normative, doesn't actually specify anything. Thus, rewriting, extending, removing, or repositioning it is not a change to "the SPF specification". -MSK From superuser@gmail.com Sun Sep 2 11:50:10 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7251621F8458 for ; Sun, 2 Sep 2012 11:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.627 X-Spam-Level: X-Spam-Status: No, score=-3.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Esc4E5gkHQMG for ; Sun, 2 Sep 2012 11:50:09 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF6321F8450 for ; Sun, 2 Sep 2012 11:50:09 -0700 (PDT) Received: by lahm15 with SMTP id m15so3884040lah.31 for ; Sun, 02 Sep 2012 11:50:08 -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=hOP0cSDNTWMc72NeqTqBu3H/ygBJ6GFt90r/GJuBWu4=; b=Gz5aEgTw93xR29THFk7jgHRj//cKS/NufA/CEaaKlfHSjWijAYltZ5PdN0ogsM1aGY lJlnzoNBLAqdZDddM32p9GmrJJ7fhebliXbUO7rzfeUrH6pKqex1Mo+Xo7rh3CNUkNik sgSV6Vlq87zl11TGUZjvCnNYciadF/H/qRs4TXjC0P371Ne+TZGz4YrmmHveJN0JhZSn h50F2ELdJ5ya5V55ulrM3p0GFyCvOL/aEF9fxiHxWiOTWYJSfpdVNFu/+JqlhQMzZGqx j/GcWLqWJvQt5mLsug5oDuitB7EfQyUJyoJttsVOxuWmy3y6yu4QvvqMeXJkCKhWOa+V aswg== MIME-Version: 1.0 Received: by 10.152.125.116 with SMTP id mp20mr11935156lab.19.1346611808394; Sun, 02 Sep 2012 11:50:08 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Sun, 2 Sep 2012 11:50:08 -0700 (PDT) In-Reply-To: <504234EC.8000505@tana.it> References: <2385202.ToyOPapQOP@scott-latitude-e6320> <504234EC.8000505@tana.it> Date: Sun, 2 Sep 2012 11:50:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 18:50:10 -0000 On Sat, Sep 1, 2012 at 9:16 AM, Alessandro Vesely wrote: > I dislike suggesting a kludge as 'a reasonable way to do it'. I know > that examples are not normative, but that one is likely the single one > example of A-R usage that we are going to give, hence its value is > almost that of a SHOULD, RFC 2119 notwithstanding. I don't agree with that claim at all. However, I'm not going to object if we were to dump the example of how to shoe-horn Received-SPF into Authentication-Results. > If the forensics data that Received-SPF: conveys is > what is wanted, then use that field, period. We do say that. > For the security aspect, I already mentioned the solution of renaming > existing fields to Old-Received-SPF before adding new ones: > http://www.ietf.org/mail-archive/web/spfbis/current/msg01029.html > The package implementing that is in multiple Linux distributions, so > it can be considered widespread, no? Maybe, but isn't it easier to refer to published security text rather than introduce yet another "to solve problem X, you could do something like Y"? -MSK From superuser@gmail.com Sun Sep 2 13:42:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB3621F84F6 for ; Sun, 2 Sep 2012 13:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.626 X-Spam-Level: X-Spam-Status: No, score=-3.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpWziNuNnNSj for ; Sun, 2 Sep 2012 13:42:35 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4231021F84F5 for ; Sun, 2 Sep 2012 13:42:35 -0700 (PDT) Received: by lbky2 with SMTP id y2so2723353lbk.31 for ; Sun, 02 Sep 2012 13:42:34 -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=sX395c3heCWKkXDviPwR/8E7H5/IgpOh9XBauhqsBBg=; b=hIe4PgP71EGL/S1TBD9Zd0UMz7uvZXBVLhIxWbyFk7QiVZ+3RmX98PFBK7IQ/+I3jG Z80aDGV9pkGYguLykk69wiVl5XlglQ4XZb7w8D18/zpFgkAVwsUi1mvVu5kvpadndKHF a5JpPuQsvjVaLJiQQ/2csD+KBajTXMJFsDO5Tqp76Oo9z/kxYubNHjW30FUMq7KpAbHB WgnyKuCCMxceXx4Pbz0yFNCAr82mzsKcRPcU8DH8961gGHQeU1d5yXiVhCLXcYWXRso4 t85yxPgybXcaUv6wlI8sD0A7Z6YzfIXRg2Wr9Q6Aj3E36OJWDdXhAwxb4Ch04B1rpYF0 Kgjw== MIME-Version: 1.0 Received: by 10.152.109.166 with SMTP id ht6mr11917395lab.46.1346618554015; Sun, 02 Sep 2012 13:42:34 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Sun, 2 Sep 2012 13:42:33 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120831223438.09fe98d8@elandnews.com> References: <6.2.5.6.2.20120831223438.09fe98d8@elandnews.com> Date: Sun, 2 Sep 2012 13:42:33 -0700 Message-ID: From: "Murray S. Kucherawy" To: SM Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 1 of raft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 20:42:36 -0000 On Fri, Aug 31, 2012 at 11:14 PM, SM wrote: > "Furthermore, many domain owning ADMDs (ADministrative > Management Domains, see [RFC5598]) are understandably concerned about > the ease with which other entities can make use of their domain > names, often with malicious intent." > > The "domain owning ADMDs" wording is unclear. In what sense? > As a nit, the ADMDs should be > exapanded on first using the acronym first. Agreed. > Section 1.1 is about "Protocol Status". > > "The goal of this document is to clearly document the protocol defined > by earlier draft specifications of SPF as used in existing > implementations." > > According to the SPFBIS Charter, the document is work based on RFC 4408. > The charter does not mention earlier draft specifications. I suggest > finding a better title for the subsection and reviewing the sentence. ...or removing it. Since this one will obsolete RFC4408, isn't that implicit? > Section 1.2 is about "Experimental History". RFC 6686 discusses about the > experiments. The quick fix would be to drop the subsection. ...or include a reference to RFC6686 as recommended reading. > From Section 1.3.3: > > 'This document is concerned with the portion of a mail message > commonly called "envelope sender", "return path", "reverse path", > "bounce address", "5321 FROM", "MAIL FROM", or RFC5321.MailFrom. > Since these terms are either not well defined or often used casually, > this document uses "MAIL FROM" for consistency. This means the > RFC5321.MailFrom as defined in [RFC5598]. Note that other terms that > might superficially look like the common terms, such as "reverse- > path", are used only with the defined meanings from normative > documents.' > > There is a normative reference to RFC 5321 and RFC 5598. The definitions in > the document are a mix of RFC 4408 and RFC 5598. I suggest choosing one of > the for consistency. Agree. > In Section 1.3.5: > > "There are [RFC4408] features that are marked "deprecated". In the > context of this document, deprecated means that senders SHOULD NOT > publish SPF records that make use of such features because they might > be removed entirely in future updates to the protocol. Such features > do, however, remain part of the SPF protocol and receiving systems > MUST support them unless this document explicitly says otherwise." > > The above introduces two new RFC 2119 key words. That would require updating RFC2119, which we aren't doing. I don't think this is a correct characterization. Rather, it merely defines one term. > The text mentions senders > while ADMDs are mentioned in previous subsections. I suggest dropping the > RFC 2119 key words. There isn't any mention of "deprecated" in Section 3. > Section 5.5 deprecates the "ptr" mechanism. I don't agree. An ADMD is an conceptual entity, while a sender is an identity in the context of email. -MSK From sm@elandsys.com Sun Sep 2 15:36:07 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CD421F84CF for ; Sun, 2 Sep 2012 15:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipllgVkUdMaJ for ; Sun, 2 Sep 2012 15:36:07 -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 2C26821F84B6 for ; Sun, 2 Sep 2012 15:36:07 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.167]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q82MZmxF008719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Sep 2012 15:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346625360; bh=8X0junV8chOTYmBKzlTZyeW5NwZVFRCbG77QfFOJVFM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wTk6sYcMu+rAo3pgUVfhkYFiwqCXIEhjtn0pISskYRP/y9V4hYiQd1wwYlS98MIN5 mCkMM7N134mZ0erMagm5cgRBYazftSepTpY1VS14Bl3Mo18o1DbSm94nSGl9ERFwTV 5hR9bmjA2qzsV2RYvHP3LAQp68cXyIqZCI8QIrtM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346625360; i=@elandsys.com; bh=8X0junV8chOTYmBKzlTZyeW5NwZVFRCbG77QfFOJVFM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=p2HKj187FR5mnfq9vNksFOK96eQrMIIEg/r6hWXpkqvCIwb7ZYSoZ4BML32qjcJs7 v12M4+jNSZy75F32w8PkBlYExV7JRaJL2016/Jj/PGZ8uuhmjWUPrVl5VjwWv9pHES L6/UiZABVmZkFasemlnnuJt6SF6BIMFLV22cscE4= Message-Id: <6.2.5.6.2.20120902134804.0981f0c8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 02 Sep 2012 15:02:45 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20120831223438.09fe98d8@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 1 of raft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 22:36:07 -0000 Hi Murray, At 13:42 02-09-2012, Murray S. Kucherawy wrote: >In what sense? If I recall correctly, and after referring to RFC 5598, ADministrative Management Domains was introduced as there are different groups involved from an operational perspective. The "domain owner" is the entity who registered the domain. It's mixing two different things. >...or removing it. Since this one will obsolete RFC4408, isn't that implicit? That's an alternative. There will be a "status of this memo" section. >...or include a reference to RFC6686 as recommended reading. That's one more document >That would require updating RFC2119, which we aren't doing. I don't >think this is a correct characterization. Rather, it merely defines >one term. I wrote the comment as a note of a change. I didn't word the comment properly. >I don't agree. An ADMD is an conceptual entity, while a sender is an >identity in the context of email. Yes. The text does not follow what was stated in Section 1. Regards, S. Moonesamy (speaking for myself) From superuser@gmail.com Sun Sep 2 20:02:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F5621F843C for ; Sun, 2 Sep 2012 20:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.626 X-Spam-Level: X-Spam-Status: No, score=-3.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvQ4leJfcZCy for ; Sun, 2 Sep 2012 20:02:47 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 754F821F842E for ; Sun, 2 Sep 2012 20:02:46 -0700 (PDT) Received: by lahm15 with SMTP id m15so4031197lah.31 for ; Sun, 02 Sep 2012 20:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ByzSL5FEwQcMuKTrYw+qJFa4eIzFyA6xfguyU2yQL0o=; b=NdVMFGB1rHPBsjop8Z/Sh7o/sXTHXMMdY57el17o1ZtU62ktK/LX+0Xb9rTk3mTTeS JpnJzgv3NqYmDTqddkJvYqfIrJ0685yyuif2kjKDFs/j0TXPohhrSWVXhLgv+x1pPoxr POFLnG7g6Wk/tG2S6z03CtVZGdFIURDYcj/xODz3K2eJlAWu64QOJlbudj4Yi5hu//BQ Ucsrc5lsWd8lL5gRGgSGgmgJiVeq5dvJPQ4TIrK5aWMWfRiLpJ73MFLo/v09kA3S0aX1 OWiDePSLIel6oHOjXNUqLHTPrhG9Tenb4YDYNS/Iz8drncj4gzENEwirDgF5P37kdudL PrSA== MIME-Version: 1.0 Received: by 10.152.148.199 with SMTP id tu7mr12459947lab.37.1346641365100; Sun, 02 Sep 2012 20:02:45 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Sun, 2 Sep 2012 20:02:44 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120831232330.09fe9648@elandnews.com> References: <6.2.5.6.2.20120831232330.09fe9648@elandnews.com> Date: Sun, 2 Sep 2012 20:02:44 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 2 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 03:02:48 -0000 On Sat, Sep 1, 2012 at 1:14 AM, S Moonesamy wrote: > From Section 2.1 of RFC 4408: > > 'It is RECOMMENDED that SPF clients not only check the "MAIL FROM" > identity, but also separately check the "HELO" identity by applying > the check_host() function (Section 4) to the "HELO" identity as the > .' > > And Section 2.1 of the draft: > > 'SPF verifiers MUST check the ""MAIL FROM" identity if a completed > "HELO" check has not reached a definitive policy result by applying > the check_host() function to the "MAIL FROM" identity as the > .' > > There is a change from RFC 2119 recommendation to RFC 2119 requirement in > the above. This is related to Issue #15. I agree that the logic should be consolidated. > 'Additionally, since SPF records published for "HELO" identities > refer to a single host, when available, they are a very reliable > source of host authorization status.' > > I don't recall this being discussed on the mailing list. I am making a note > of it as it is a change from RFC 4408. It's a useful clarification and is not normative, so I don't think it's a big deal. > 'Note that requirements for the domain presented in the EHLO or HELO > command are not always clear to the sending party, and SPF verifiers > MUST be prepared for the "HELO" identity to be malformed or an IP > address literal.' > > There is an additional RFC 2119 requirement compared to what is in RFC 4408. I think it's important to point out that the HELO/EHLO parameter might not be a fully-qualified domain name and might not resolve. However, RFC5321 already does this as I recall. The MUSTard can probably go here, therefore. > From Section 2.2 of RFC 4408: > > 'SPF verifiers MUST check the ""MAIL FROM" identity if a completed > "HELO" check has not reached a definitive policy result by applying > the check_host() function to the "MAIL FROM" identity as the > .' > > From the draft: > > 'SPF clients MUST check the "MAIL FROM" identity. SPF clients check > the "MAIL FROM" identity by applying the check_host() function to the > "MAIL FROM" identity as the .' > > It would be better to have this in one sentence to have the RFC 2119 > requirement clear. The sentences are so short already that I don't think it matters that much. > In Section 2.3: > > 'An SPF-compliant domain MUST have valid SPF records as described in > Section 3.' > > This is similar to what is in RFC 2119. Sorry, can you clarify? RFC2119 says something like this? > From RFC 4408: > > 'If domain owners choose to publish SPF records, it is RECOMMENDED > that they end in "-all", or redirect to other records that do, so > that a definitive determination of authorization can be made.' > > And the draft: > > 'If domain owners choose to publish SPF records and want to support > receivers making negative authorization determinations, then they > MUST publish records that end in "-all", or redirect to other > records that do, otherwise, no definitive determination of > authorization can be made. Potential issues and mitigations > associated with negative determinations are discussed in Section 9.' > > The terminology (domain owners in this case) is inconsistent when compared > with other sections of the draft. ADMD is probably appropriate here. > The RFC 2119 requirement is a significant > change. The RFC2119 change is appropriate, because interoperability of the stated goal (negative determinations) requires "-all". It is not the default. > From the draft: > > "This can be as much as 30 days." > > There was a short discussion about this change on the mailing list. The question was asked where this value came from. I never saw an answer. Perhaps it's better to use a term like "arbitrarily long". > From Section 2.4: > > 'A mail receiver can perform a set of SPF checks for each mail message > it receives.' > > What is a mail receiver? RFC5598 defines "recipient"; we should use that. > "When a mail receiver decides to perform an SPF check, it MUST use a > correctly-implemented check_host() function (Section 4) evaluated > with the correct parameters." > > This is an unnecessary RFC 2119 requirement. +1. > "Although the test as a whole is optional, once it has been decided > to perform a test it MUST be performed as specified so that the > correct semantics are preserved between publisher and receiver." > > A new RFC 2119 has been added compared to RFC 4408. I think it's an unnecessary statement overall. > 'Implementations MUST take care to correctly extract the from > the data given with the SMTP MAIL FROM command as many MTAs will > still accept such things as source routes (see [RFC5321], Appendix > C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]).' > > There is a new RFC 2119 requirement compared to RFC 4408. As a nit, the > above text creates two normative references causing more required reading. I would change MUST to "need to". > From RFC 4408: > > "Generating non-delivery notifications to forged identities that have > failed the authorization check is generally abusive and against the > explicit wishes of the identity owner." > > And the draft: > > "Generating non-delivery notifications to forged identities that have > failed the authorization check is a source of backscatter and SHOULD > be avoided. [RFC3834] section 2 describes backscatter and the > problems it causes." > > A RFC 2119 recommendation was added. Section 2 of RFC 3834 is about > automated responses. I think the normative recommendation is reasonable; it avoids an undesirable side effect of interoperability in certain cases. > From Section 2.5.1 of RFC 4408: > > 'A result of "None" means that no records were published by the domain > or that no checkable sender domain could be determined from the given > identity. The checking software cannot ascertain whether or not the > client host is authorized.' > > And the draft: > > 'A result of "none" means either (a) no syntactically valid DNS domain > name was extracted from the SMTP session that could be used as the > one to be authorized, or (b) no TXT records were retrieved from the > DNS that appeared to be intended for use by SPF verifiers.' > > That could be considered as a clarrification. +1; it fits. -MSK From superuser@gmail.com Sun Sep 2 20:26:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3EEF21F847D for ; Sun, 2 Sep 2012 20:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.626 X-Spam-Level: X-Spam-Status: No, score=-3.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Wp91+qiUQAK for ; Sun, 2 Sep 2012 20:26:23 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CEB1D21F8472 for ; Sun, 2 Sep 2012 20:26:22 -0700 (PDT) Received: by lahm15 with SMTP id m15so4039794lah.31 for ; Sun, 02 Sep 2012 20:26:21 -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=REHrJ2okLRaQD+TPDCW4vo2o8I/PZkFgzyGWaVmpQ9s=; b=yXhzs1ISXaA8j9qJdUm9wSw4+OMeZFtUvm7Q0YSqk2iH5OFZusGpZq8XHL2QdG/os6 Zy6kQJL6O8u7QhdnP+iJYu5o1sT6PtNsueh7cboLwgbl5DgeVI0XOtCA8iYXpO2ZLUs4 QF/I1QnDl4xwYyst0d+AL8kClgzM/835NT4Ab+N1y6vLfui66s8OkjqmJ6yKKHgOKarG nJxxNxgXg6LhOid1GUW/kOPkJ7NsoNR9GpNqnFkt0ZxuFWF4CWP066yzuvr9BXzfFp3R wp0u1fSgRPXrwetb0oR54D+LlatCp8wBt/0WsFhfrwj3WK5P87y63ioQbm6l9VJrut+8 Zhcg== MIME-Version: 1.0 Received: by 10.112.88.73 with SMTP id be9mr4984160lbb.72.1346642781663; Sun, 02 Sep 2012 20:26:21 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Sun, 2 Sep 2012 20:26:21 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120901110019.093bcda0@resistor.net> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <6.2.5.6.2.20120831180612.098d0090@elandnews.com> <5042402C.10009@tana.it> <6.2.5.6.2.20120901110019.093bcda0@resistor.net> Date: Sun, 2 Sep 2012 20:26:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, Alessandro Vesely Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 03:26:23 -0000 On Sat, Sep 1, 2012 at 11:17 AM, S Moonesamy wrote: >> May I volunteer for that? Whoa, let's not get ahead of ourselves here. I almost regret suggesting it for fear of distracting us from finishing rfc4408bis itself. But then, if there are solid concerns about the volume of added text and questions about why certain things were there in the first place, this is one way out of that mess. It's up to the co-chairs; it was only a procedural suggestion. Let's not start jockeying for position before the decision is made and a path forward is chosen. -MSK From spf2@kitterman.com Sun Sep 2 22:06:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F24A21F8495 for ; Sun, 2 Sep 2012 22:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkflYspvHOaf for ; Sun, 2 Sep 2012 22:06:34 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EE92E21F8470 for ; Sun, 2 Sep 2012 22:06:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B4ACD20E40BA; Mon, 3 Sep 2012 01:06:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346648789; bh=7BEHos/qzArGzvE9OoqAj746QkEtMyg+yrG0iSdng08=; h=From:To:Subject:Date:In-Reply-To:References:From; b=C+4lI16JIWg7ZXkmgAWxlXRoNfzO7vQZsGeInGpAqrww/4j6a9/wwOCEuaxmzCb0m /Yx/m6lJF7BmAxPpXS6KoJ0P4dvjYo2pi8i3LY9TD/PtPtVj7TrzUlDzujH1tJGI3A uon/LwGMWi4YA+scaKNp2dyE4/ajLnw4ZJ/Mxk58= 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 8C1EF20E40B2; Mon, 3 Sep 2012 01:06:28 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 03 Sep 2012 01:06:28 -0400 Message-ID: <3564786.BIr6kOu5E1@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120831223438.09fe98d8@elandnews.com> References: <6.2.5.6.2.20120831223438.09fe98d8@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 1 of raft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 05:06:35 -0000 On Friday, August 31, 2012 11:14:45 PM SM wrote: > Hello, > > There comments are about Section 1 of draft-ietf-spfbis-4408bis-06. > > "Furthermore, many domain owning ADMDs (ADministrative > Management Domains, see [RFC5598]) are understandably concerned about > the ease with which other entities can make use of their domain > names, often with malicious intent." > > The "domain owning ADMDs" wording is unclear. As a nit, the ADMDs > should be exapanded on first using the acronym first. > > 'Compliant ADMDs publish Sender Policy Framework (SPF) records in the > DNS specifying which hosts are permitted to use their names, and > compliant mail receivers use the published SPF records to test the > authorization of sending Mail Transfer Agents (MTAs) using a given > "HELO" or "MAIL FROM" identity during a mail transaction.' > > The switch from "domain holders" to ADMDs makes the above unclear. > > Section 1.1 is about "Protocol Status". > > "The goal of this document is to clearly document the protocol defined > by earlier draft specifications of SPF as used in existing > implementations." > > According to the SPFBIS Charter, the document is work based on RFC > 4408. The charter does not mention earlier draft specifications. I > suggest finding a better title for the subsection and reviewing the > sentence. > > Section 1.2 is about "Experimental History". RFC 6686 discusses > about the experiments. The quick fix would be to drop the subsection. > > From Section 1.3.3: > > 'This document is concerned with the portion of a mail message > commonly called "envelope sender", "return path", "reverse path", > "bounce address", "5321 FROM", "MAIL FROM", or RFC5321.MailFrom. > Since these terms are either not well defined or often used casually, > this document uses "MAIL FROM" for consistency. This means the > RFC5321.MailFrom as defined in [RFC5598]. Note that other terms that > might superficially look like the common terms, such as "reverse- > path", are used only with the defined meanings from normative > documents.' > > There is a normative reference to RFC 5321 and RFC 5598. The > definitions in the document are a mix of RFC 4408 and RFC 5598. I > suggest choosing one of the for consistency. The document uses "MAIL FROM" throughout unless I missed something. > In Section 1.3.5: > > "There are [RFC4408] features that are marked "deprecated". In the > context of this document, deprecated means that senders SHOULD NOT > publish SPF records that make use of such features because they might > be removed entirely in future updates to the protocol. Such features > do, however, remain part of the SPF protocol and receiving systems > MUST support them unless this document explicitly says otherwise." > > The above introduces two new RFC 2119 key words. The text mentions > senders while ADMDs are mentioned in previous subsections. I suggest > dropping the RFC 2119 key words. There isn't any mention of > "deprecated" in Section 3. Section 5.5 deprecates the "ptr" mechanism. I don't understand this comment beyond the bit about ADMDs. Why does section 3 matter? Why remove the 2119 words? Scott K From spf2@kitterman.com Sun Sep 2 22:21:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F4F21F8496 for ; Sun, 2 Sep 2012 22:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqIn+jHv02OX for ; Sun, 2 Sep 2012 22:21:21 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC9721F8495 for ; Sun, 2 Sep 2012 22:21:21 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BC83820E40BA; Mon, 3 Sep 2012 01:21:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346649680; bh=n7DBN+dZ863/z34OI+lTchlasJeBb7YW6O57yFRyV3M=; h=From:To:Subject:Date:In-Reply-To:References:From; b=k9JReNq5D6h0b0jTjB+uHUiZdrZyPCI100cWbJNw+QOpItm2QhHg0q5Ek4+LjPWsT m+yZKW+TSNypwt8+1ih2SJvaN1NZG0XwJnLyn95sGihFRvyEnA6EMGvCfFvCJqgLrg bqmO/KpVJf6IkWfPNxDLYNBqNvuQalZVz29oJdbI= 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 996EC20E40B2; Mon, 3 Sep 2012 01:21:20 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 03 Sep 2012 01:21:19 -0400 Message-ID: <5242106.sm99VaUiMo@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120831232330.09fe9648@elandnews.com> References: <6.2.5.6.2.20120831232330.09fe9648@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 2 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 05:21:22 -0000 On Saturday, September 01, 2012 01:14:16 AM S Moonesamy wrote: > Hello, > > These comments are about Section 2 of draft-ietf-spfbis-4408bis-06. > > From Section 2.1 of RFC 4408: > > 'It is RECOMMENDED that SPF clients not only check the "MAIL FROM" > identity, but also separately check the "HELO" identity by applying > the check_host() function (Section 4) to the "HELO" identity as the > .' > > And Section 2.1 of the draft: > > 'SPF verifiers MUST check the ""MAIL FROM" identity if a completed > "HELO" check has not reached a definitive policy result by applying > the check_host() function to the "MAIL FROM" identity as the > .' > > There is a change from RFC 2119 recommendation to RFC 2119 > requirement in the above. This is related to Issue #15. This is a change, but it relaxes a requirement, it doesn't impose any new requirement. > 'Additionally, since SPF records published for "HELO" identities > refer to a single host, when available, they are a very reliable > source of host authorization status.' > > I don't recall this being discussed on the mailing list. I am making > a note of it as it is a change from RFC 4408. It was. > 'Note that requirements for the domain presented in the EHLO or HELO > command are not always clear to the sending party, and SPF verifiers > MUST be prepared for the "HELO" identity to be malformed or an IP > address literal.' > > There is an additional RFC 2119 requirement compared to what is in RFC 4408. This is one that is part of my global changes from 4408 to 4408bis. It seems to me reasonable to change this because there will be interoperability problems if one does not do that. > From Section 2.2 of RFC 4408: > > 'SPF verifiers MUST check the ""MAIL FROM" identity if a completed > "HELO" check has not reached a definitive policy result by applying > the check_host() function to the "MAIL FROM" identity as the > .' > > From the draft: > > 'SPF clients MUST check the "MAIL FROM" identity. SPF clients check > the "MAIL FROM" identity by applying the check_host() function to the > "MAIL FROM" identity as the .' > > It would be better to have this in one sentence to have the RFC 2119 > requirement clear. You have these reversed. The first one is from the draft and the second is from 4408. > In Section 2.3: > > 'An SPF-compliant domain MUST have valid SPF records as described in > Section 3.' > > This is similar to what is in RFC 2119. > > From RFC 4408: > > 'If domain owners choose to publish SPF records, it is RECOMMENDED > that they end in "-all", or redirect to other records that do, so > that a definitive determination of authorization can be made.' > > And the draft: > > > 'If domain owners choose to publish SPF records and want to support > receivers making negative authorization determinations, then they > MUST publish records that end in "-all", or redirect to other > records that do, otherwise, no definitive determination of > authorization can be made. Potential issues and mitigations > associated with negative determinations are discussed in Section 9.' > > The terminology (domain owners in this case) is inconsistent when > compared with other sections of the draft. The RFC 2119 requirement > is a significant change. This should be matched to be consistent terminology wise, but now is the MUST significant? What would be an SPF compliant domain with no SPF record? Of course it MUST publish one. > From the draft: > > "This can be as much as 30 days." > > There was a short discussion about this change on the mailing list. > > From Section 2.4: > > 'A mail receiver can perform a set of SPF checks for each mail message > it receives.' > > What is a mail receiver? What terminology would you suggest? > "When a mail receiver decides to perform an SPF check, it MUST use a > correctly-implemented check_host() function (Section 4) evaluated > with the correct parameters." > > This is an unnecessary RFC 2119 requirement. How so? You can't get a correct SPF result without a correct implementation. There are pseudo SPF implementations out there and they should not call their results SPF results. Doing so creates confusion. I think it's reasonable to state that the SPF check must be done correctly or not at all (or not called an SPF check). > "Although the test as a whole is optional, once it has been decided > to perform a test it MUST be performed as specified so that the > correct semantics are preserved between publisher and receiver." > > A new RFC 2119 has been added compared to RFC 4408. This is perhaps redundant with the previous one, so I guess we might pick one. > 'Implementations MUST take care to correctly extract the from > the data given with the SMTP MAIL FROM command as many MTAs will > still accept such things as source routes (see [RFC5321], Appendix > C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]).' > > There is a new RFC 2119 requirement compared to RFC 4408. As a nit, > the above text creates two normative references causing more required > reading. This is another must/MUST change. I think it is reasonable, since if you extract the wrong domain, it's pretty well all over as far a interoperability goes. > From Section 2.5 of the draft: > > "Performing the authorization other than using the return-path and > client address at the time of the MAIL command during the SMTP > transaction can cause problems, such as the following" > > The usage of return-path is inconsistent with Section 1.3.3. No. It's not. > From RFC 4408: > > "Generating non-delivery notifications to forged identities that have > failed the authorization check is generally abusive and against the > explicit wishes of the identity owner." > > And the draft: > > "Generating non-delivery notifications to forged identities that have > failed the authorization check is a source of backscatter and SHOULD > be avoided. [RFC3834] section 2 describes backscatter and the > problems it causes." > > A RFC 2119 recommendation was added. Section 2 of RFC 3834 is about > automated responses. This was discussed on the list and was considered to be an improvement in the draft. > From Section 2.5.1 of RFC 4408: > > 'A result of "None" means that no records were published by the domain > or that no checkable sender domain could be determined from the given > identity. The checking software cannot ascertain whether or not the > client host is authorized.' > > And the draft: > > 'A result of "none" means either (a) no syntactically valid DNS domain > name was extracted from the SMTP session that could be used as the > one to be authorized, or (b) no TXT records were retrieved from the > DNS that appeared to be intended for use by SPF verifiers.' > > That could be considered as a clarrification. > > Section 2.5.4 generated significant discussion. Scott K From spf2@kitterman.com Sun Sep 2 22:28:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E68621F846B for ; Sun, 2 Sep 2012 22:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqYcpNxc-PhG for ; Sun, 2 Sep 2012 22:28:30 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C270D21F845A for ; Sun, 2 Sep 2012 22:28:30 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id EC6C520E40BA; Mon, 3 Sep 2012 01:28:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346650108; bh=8+KjbotFipRyNenvZbfXXFN1vvWLHW79It0bMJvRkNE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YFhnSg6MjoJtyWOapSvCFKQ5DLdxxP2mJ9SoS/6wEeSz5t4kG1hG+SX+fYM3kRVCn Zh8o5g9+WAItDrOGZ8FgMGQFVsNQOhzeJyxfpdFToAu3ArobXHmOFbiB6fX6io0Tmq IewTsdSp6hKQZJvu+wYcQgefu8bzVfZi43nCDn9M= 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 BFC7C20E40B2; Mon, 3 Sep 2012 01:28:27 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 03 Sep 2012 01:28:26 -0400 Message-ID: <2807745.DgKN7pdKFO@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <5041EC47.3010908@tana.it> References: <1346376279.88598.YahooMailClassic@web125403.mail.ne1.yahoo.com> <5041EC47.3010908@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 05:28:31 -0000 On Saturday, September 01, 2012 01:06:47 PM Alessandro Vesely wrote: > On Fri 31/Aug/2012 16:18:32 +0200 Murray S. Kucherawy wrote: > > On Fri, Aug 31, 2012 at 1:17 AM, Alessandro Vesely wrote: > >> Non-match makes sense in case the record is correct, but the parameter > >> is malicious, e.g.: > > Is there a deterministic way to identify abuse? > > > > "Do X if the input data is malicious" is not a recipe for normative > > guidance. > > Right. Scott said to leave specific wording aside for a moment. I > don't think it's worth attempting an exact definition of "malicious" > anyway. > > An idea is to do something like the following after macro expansion > but before DNS lookup: > > if (is_malformed(term.domain) || strlen(term.domain) > 63) > { > if (is_malformed(parameter) || > strlen(parameter) > REASONABLE_LENGTH) > return NO_MATCH; > > report_error(spf_rec, &term, ERR_MALFORMED); > return PERMERROR; > } > > > We need to pick the one that's more generally applicable, and move > > forward with it. > > It seems to me that not only local macros are involved, but also > intermixed use of domain macros during HELO evaluation, and %h during > MAIL FROM. > > We could have restricted the use of those macros to terms that imply > no DNS query, such as explanations. Now, assuming we didn't intend to > do that, we need to grant them a fair usability. Taking into account > that SPF grammar provides no way to guard against malformed > parameters, /any/ non-trivial use of those macros can result in a > malformed domain, potentially. > > Hence, inflexibly mandating permerror implies an unintentional penalty > for users of those macros, inasmuch as (1) there is an attack path > whereby an abuser of the domain name can get --by design-- a permerror > rather than the stipulated result, and (2) the rr=e tag of RFC 6652 > will not be limited to real errors, but include items rather akin to > rr=f or similar. I think the 'attack' path is limited to 'p'. In all other cases additional information that's looked up in DNS is based on the domain owner's DNS. Scott K From spf2@kitterman.com Sun Sep 2 22:32:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112A321F8495 for ; Sun, 2 Sep 2012 22:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYaigdKi5ScZ for ; Sun, 2 Sep 2012 22:32:15 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4603B21F846B for ; Sun, 2 Sep 2012 22:32:15 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9C4C720E40BA; Mon, 3 Sep 2012 01:32:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346650334; bh=S4AwVvxl1CdxZWH2xeTEmwtSDroK+vekULVd+AEaLmw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qdObZx21Mu2Crw5XRbFcBBu0CpDXfDx4haTi3VTmVR+FwWUm3UjMOkHBU7EyxiwVo Xrn9vAYDh7dviUyoqM0Knq41X0ekAsAIoYyioXK2+48OUNn7ZH7eQEz1enpCo+Ncre zV7PepZKyIEty78qgnG3d6+j2CnFE8IuyqHyOIx8= 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 71D4C20E40B2; Mon, 3 Sep 2012 01:32:14 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 03 Sep 2012 01:32:13 -0400 Message-ID: <1381988.MgFA4MVS4M@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <504234EC.8000505@tana.it> References: <2385202.ToyOPapQOP@scott-latitude-e6320> <504234EC.8000505@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 05:32:16 -0000 On Saturday, September 01, 2012 06:16:44 PM Alessandro Vesely wrote: > On Fri 31/Aug/2012 20:51:30 +0200 Scott Kitterman wrote: > > On Friday, August 31, 2012 10:39:19 AM Murray S. Kucherawy wrote: > >> For example: > >> > >> > > > > I think (with the RECOMMENDED change already discussed upstream) this is > > pretty good. Can we squeeze the suggestion to use the SPF-Received > > key-value- list to add details to A-R into here? I don't think it needs > > to be more than 'here's a reasonable way to do it', but I'd like to at > > least suggest something if people want to go down this path (and it helps > > support the example, which does exactly that). > > I dislike suggesting a kludge as 'a reasonable way to do it'. I know > that examples are not normative, but that one is likely the single one > example of A-R usage that we are going to give, hence its value is > almost that of a SHOULD, RFC 2119 notwithstanding. *Standardizing > kludges is evil*. If the forensics data that Received-SPF: conveys is > what is wanted, then use that field, period. What kludge? A-R has optional fields and room for comments, so I don't see anything kludgy about suggesting a way to fill them out. > For the security aspect, I already mentioned the solution of renaming > existing fields to Old-Received-SPF before adding new ones: > http://www.ietf.org/mail-archive/web/spfbis/current/msg01029.html > The package implementing that is in multiple Linux distributions, so > it can be considered widespread, no? What package? Generally, I think if you trust the header you should leave it untouched and if you don't you should probably remove it. I don't see value in leaving untrusted content. Scott K From spf2@kitterman.com Sun Sep 2 22:40:09 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBB121F8491 for ; Sun, 2 Sep 2012 22:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yjHJfdJsE3x for ; Sun, 2 Sep 2012 22:40:08 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7212521F8464 for ; Sun, 2 Sep 2012 22:40:08 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id EA62C20E40BA; Mon, 3 Sep 2012 01:40:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346650808; bh=pmwbkMq0uI2Qh7+v2tDK3xqr7gzYMo8gLg+5ReBbXHA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Dqdl67hjfkn/93ctK6puT+ZesN/bcQ0C91OYIA7OM6ddR31iWIfuIZBXkpMZEViYQ PNPrGf6KXT8LQkTdQSX3qBHAQyGwMmYvl0Yzs6CSTYWQsl8gr3l9dbQNT+WUuWUE2D 4GTdGRlMppHNxeN49AY28iQbcmci9DOiRc7yhMts= 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 C891F20E40B2; Mon, 3 Sep 2012 01:40:07 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 03 Sep 2012 01:40:07 -0400 Message-ID: <23220341.zrDTuUZbFe@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <5042402C.10009@tana.it> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <5042402C.10009@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 05:40:09 -0000 On Saturday, September 01, 2012 07:04:44 PM Alessandro Vesely wrote: > On Sat 01/Sep/2012 05:26:34 +0200 Murray S. Kucherawy wrote: > > On Fri, Aug 31, 2012 at 6:23 PM, S Moonesamy wrote: > >> [At 17:54 31-08-2012, Murray S. Kucherawy wrote:] > >> > >>> Perhaps the simplest thing to do is to start an individual submission > >>> to collect this stuff, and move it out of here. > > +1 First, IIRC we decided we'd get to the end of doing the draft and then decide if it needed splitting then, so I don't understand the sudden rush to judgment on this topic. Second, I think it would be a mistake to make completion of the working group's effort contingent on completion of work we aren't chartered to do. If we decide that 4408bis needs to be split, then I think we should really recharter to do it. > >>> The trick, though, is that RFC4408bis itself should then refer > >>> to it, which will delay its publication until that document > >>> finds a new home or an AD sponsor and is also published. > > Isn't it possible to just mention "an applicability statement to be > published next" sort of thing? Part two will then refer to RFC4408bis. No. Section 9 is pretty solidly intertwined in the main body in a number of places. Such a document would need to have a normative reference from 4408bis and so they'd have to be published together. In any case, if we rip out section 9 (which was in 4408) then we're outside our charter regardless of where we put it. If we're going to recharter, then let's just recharter to do the work of the group in two documents, rather than leave it half done. > >>> (And I can tell you that we're very unlikely to take it in > >>> APPSAWG.) > >> > >> I don't know what to suggest. I won't suggest APPSAWG. :-) > > > > The APPSAWG co-chair thanks you. (Seriously, though, there are > > several procedural things blocking that path.) > > +1 (as APPSAWG participant) > > > If we do split the work in this way, we technically still hit our > > deliverable even if it lands in the RFC Editor queue and stalls there > > until the second document finishes via whatever path is chosen for it. > > Rechartering is the best way, IMHO. > > > We just have to accept the unpredictable delay. The only work then > > > > is to decide what parts of the current Section 9 are required to make > > the document whole (those should stay) and which constitute > > non-critical implementation advice (those should move). > > > > It's possible that new content from other sections is also a candidate > > for such a migration, which would make Arthur happy. > > Yes, I don't think splitting the document is a silly idea. Indeed, it > reflects the "second life" of SPF pretty well. While some parts of > Section 9 are almost fine where they are, any rejection-related advice > should be moved to part two, possibly including the exp= modifier. This makes no sense to me. One of the hardest things for me to understand about splitting is how 4408bis would be complete without the receiver policy discussion. We could move that back into the main part of the document, but I think it's better where it is. > > Oh, and you need to find an editor(s). ;-) > > May I volunteer for that? If the group's going to decide the document I've been working on should be split in two, then I'd prefer to keep working on both parts of it. Scott K From spf2@kitterman.com Sun Sep 2 22:42:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF1321F8491 for ; Sun, 2 Sep 2012 22:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K25ireQtWaVH for ; Sun, 2 Sep 2012 22:42:23 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EC89621F8464 for ; Sun, 2 Sep 2012 22:42:22 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6F6C620E40BA; Mon, 3 Sep 2012 01:42:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346650942; bh=YGOWrTMFEX3g2vPH+4FHxbFodka6j3aK/ZRQ+ot0C5s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hUGtPLbT8z3QS+zL76gVU7ygLrBaGL3Xb6BeOBnsxS5lHBIdtaFRnNBmN+nLKjKht XL/A567TUROLeUFJ3gM0unxTvk7UVHP3WmzFrwEvwi2UHCMpJVGpPjRxkO0uVOsU1P zCD2/m00CAIvQGCMx2QYDn6zQHHfIBS/7YEWqEFE= 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 4191E20E40B2; Mon, 3 Sep 2012 01:42:21 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 03 Sep 2012 01:42:21 -0400 Message-ID: <3916906.fAeFKLSl3f@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120901094420.093bbf88@resistor.net> References: <1346513469.86413.YahooMailClassic@web125403.mail.ne1.yahoo.com> <6.2.5.6.2.20120901094420.093bbf88@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 05:42:23 -0000 On Saturday, September 01, 2012 10:42:53 AM S Moonesamy wrote: > At 08:31 01-09-2012, Arthur Thisell wrote: > >I'm not sure what is not clear about it. Section 5.3.6 of RFC 1123 > >talks about what mailing lists must do and the difference between an > >"alias" and a "list". > > RFC 5321 mentions that it updates RFC 1123 replacing the mail > transport materials. As the text from Section 5.3.6 of RFC 1123 is > in RFC 5321 I consider it as replaced. The RFC 1123 reference in > that part of Section 9 is not needed. > > >I'm confused by this. For example, section 3.9 of RFC 5321 is > >titled "mailing lists and aliases" and discusses the difference > >between these two models. > > I'll quote the subsection for context: > > '9.2.2. Forwarding Services and Aliases > > Forwarding services take mail that is received at a mailbox and > direct it to some external mailbox. At the time of this writing, the > near-universal practice of such services is to use the original "MAIL > FROM" of a message when re-injecting it for delivery to the external > mailbox. [RFC1123] and [RFC5321] describe this action as an "alias" > rather than a "mail list". This means the external mailbox's MTA > sees all such mail in a connection from a host of the forwarding > service, and so the "MAIL FROM" identity will not, in general, pass > authorization.' > > The subsection discusses about forwarding services and aliases. The > previous subsection (9.2.1) is about "Mailing Lists". My > understanding is that a forwarding service is not a mailing list. I > would drop the "rather than" part of the sentence to keep it simple and > clear. > > On an unrelated note, RFC 5598 describes the enhanced Internet Mail > architecture, reflecting the current service. RFC 5321 is a > specification of the basic protocol for Internet electronic mail > transport. The reader goes through three discussions about aliases. Yes, but 5598 is an informational document. For things like mailing lists that are well described in 5321, I think it's better to use the standard definition. Scott K From spf2@kitterman.com Sun Sep 2 22:43:49 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6035421F8491 for ; Sun, 2 Sep 2012 22:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2o0YsGt9mOtW for ; Sun, 2 Sep 2012 22:43:48 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B551121F846A for ; Sun, 2 Sep 2012 22:43:48 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2EC2220E40BA; Mon, 3 Sep 2012 01:43:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346651028; bh=5sUTM+A5l75VDYjEa4Ho11yAnXcfZoaxv4Ggo6YeF6U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mG8E0bTfndeNvZgh45SyOUnMtRN0y0OA6Q4Fl+F3dXXVRoYgQhGrUwgsOG+sB2YdR 0zi+1U3KnGGb2Ed7x29z/tzSJYxufe9hjohItfAYH8XWOeUUeRBLXKgEkht2TM+pmF 3v1OQoxwV0QpUdPInjP58rgNbtRmlH2BL6RIjPWE= 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 1D79920E40B2; Mon, 3 Sep 2012 01:43:48 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 03 Sep 2012 01:43:47 -0400 Message-ID: <5346077.oY5HV8JcnX@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <50424CFC.6080308@dcrocker.net> References: <1346513469.86413.YahooMailClassic@web125403.mail.ne1.yahoo.com> <6.2.5.6.2.20120901094420.093bbf88@resistor.net> <50424CFC.6080308@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 05:43:49 -0000 On Saturday, September 01, 2012 10:59:24 AM Dave Crocker wrote: > On 9/1/2012 10:42 AM, S Moonesamy wrote: > > On an unrelated note, RFC 5598 describes the enhanced Internet Mail > > architecture, reflecting the current service. RFC 5321 is a > > specification of the basic protocol for Internet electronic mail > > transport. The reader goes through three discussions about aliases. > > I am, understandably, completely biased. > > However I'd urge that the current spec merely make a normative reference > to RFC 5598, importing the terms and concepts that are relevant to > SPFbis, rather than re-defining things. > > RFC5598 was motivated by the observation that the industry lacked much > cohesiveness about email terminology and architectural detail. Anything > that moves us towards the cohesiveness would be an improvement, IMO, and > citing a common architecture/terminology document does move in that > direction. I did make an effort in this direction already. If you've got specific recommendations about further improvements, I'd be interested in them for once work has resumed on the draft. Scott K From spf2@kitterman.com Sun Sep 2 22:46:54 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4794721F8496 for ; Sun, 2 Sep 2012 22:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGFEmEL+wtoH for ; Sun, 2 Sep 2012 22:46:53 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4431F21F8495 for ; Sun, 2 Sep 2012 22:46:53 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B7A2420E40BA; Mon, 3 Sep 2012 01:46:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346651212; bh=d3be+Y7f0ySWz+crH0oQUzrvpoNEtjQhH/ldbMB49uk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UDo/yrUDdewFSiJGkxXsjGyRb8oh1oNZULToEe5g2otZkMJ1SGHSZNcUvYQoI2HjA ic3Gt3yA6Ey3yR+2SiRdp19Rq9SRKD5CNrkJ3nSXqZBX/WmLJN46x29qpTpN/veS5p wQpHp84D91idlys4AHQFNliFUf6CXc6MNspjNDKw= 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 917EC20E40B2; Mon, 3 Sep 2012 01:46:52 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 03 Sep 2012 01:46:51 -0400 Message-ID: <3097973.E0hN90lcdm@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <50434E48.8060200@tana.it> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <6.2.5.6.2.20120901110019.093bcda0@resistor.net> <50434E48.8060200@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] SPF split and rechartering, facet of Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 05:46:54 -0000 On Sunday, September 02, 2012 02:17:12 PM Alessandro Vesely wrote: > Hi SM and All, > > On Sat 01/Sep/2012 20:17:12 +0200 S Moonesamy wrote: > > At 10:04 01-09-2012, Alessandro Vesely wrote: > >> May I volunteer for that? > > > > Yes, if there was a WG draft. :-) There wasn't much enthusiasm to > > work in such an I-D when the question came up. There is nothing > > stopping you from submitting an I-D. > > I had considered the possibility to submit a new I-D a few days before > this thread began [28]. Then, this possibility resurfaced with this > thread, superseding my earlier intention. So I'd need some more > encouragement than that in order to go ahead and write it. > [28] http://www.ietf.org/mail-archive/web/spfbis/current/msg02414.html > > > I'll ask for it not to be discussed on this mailing list as the > > working group is working on draft-ietf-spfbis-4408bis. > > The new I-D and draft-ietf-spfbis-4408bis will depend on one another, > since we consider moving some parts, such as sections 6.2 and 9.2, > from one document to the other. That requires rough WG consensus. > I'd imagine the procedure to reach it would go as steps 1-7 below > (please correct me as necessary): > > 1 Someone prepares the new I-D and submits it, > > 2 WG participants look at it, then > > 3 WG participants agree on the split. > > Those three steps will consume some discussion resources on this list. > It can be easily anticipated that discussing the split will naturally > result in discussing some of the new I-D's details. Such items are to > be saved for a later stage, but they will unavoidably consume some > more discussion resource as they emerge. > > Then, assuming 1, 2, and 3 succeeded: > > 4 The new I-D is registered as a WG I-D, > > 5 duplicated parts are removed from draft-ietf-spfbis-4408bis, > > 6 rechartering process gets started, and > > 7 draft-ietf-spfbis-4408bis undergoes WGLC and IESG submission. > > I volunteered for editing the new I-D because I envision it as a much > awaited clarification of receiver behavior: An applicability > statement that specifies how a server may reject mail that is > definitely abusive, based on the SPF results obtained during the > earlier stages of an SMTP transaction. The purpose is to save the > server's resources without disrupting the mail flow. It can stick to > the original SPF catch, "you have to register a domain before you > transmit DATA", taking into account also non-rewriting forwarders. > > While that obviously needs rechartering, step 5 above does not, since > receiver behavior was never 2119-wise specified. However, some > confidence about the fate of the new I-D --see steps 4 and 6-- is > requisite in order to seriously consider step 5. > > OTOH, if there is still not much enthusiasm, please let's drop the > idea of moving Section 9 for good, and have Scott post -07. I am against individuals submitting I-D's that duplicate work that the WG is chartered to do. We can't remove section 9 and be compliant with the charter, so we need to make a decision about this and get rechartered, if needed, before doing anything. Scott K From spf2@kitterman.com Sun Sep 2 22:51:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9A421F8495 for ; Sun, 2 Sep 2012 22:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5BvTfkfRVBX for ; Sun, 2 Sep 2012 22:51:26 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 83CD521F846B for ; Sun, 2 Sep 2012 22:51:26 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 03EDB20E40BA; Mon, 3 Sep 2012 01:51:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346651486; bh=9f+9rq51TBA+y8nkwQR1FkXgCYVQECKAyRA5r6/lI/w=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UVTMw5EBbq3tC2Fs0/o507RViF1cBD8fotvH0AZQ46dv2apz5TWk8pjfzOrFmxu8Y zyvRZIWPPQth5mhgbgfHS3QGNAOtVlXz7S0sUNCxScPFsB9PxFvcj0sJUP4j2KbLmG 2Yg+YL4Ay5KnDESRMPJirvIwSaQH0qL80ZOvQpU0= 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 D0BA120E40B2; Mon, 3 Sep 2012 01:51:25 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 03 Sep 2012 01:51:25 -0400 Message-ID: <1508545.ZfpJVO7p0U@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120902081446.095d7fe8@elandnews.com> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <5083185.69cuoQvzXM@scott-latitude-e6320> <6.2.5.6.2.20120902081446.095d7fe8@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 05:51:27 -0000 On Sunday, September 02, 2012 08:17:59 AM S Moonesamy wrote: > Hi Scott, > > Sorry, that sounded a bit too authoritarian. Your earlier comment is > interesting. I never thought of the charter meaning that. Let me > think about that and confer with my co-chair, but initially I don't > think moving a section around is a big deal. I'll consider your > comment and get back to you." Thanks, I don't think that moving a section around is inherently against our charter. I think it should be avoided because it could cause confusion. I do feel that there is some difference in the semantics of a non-normative discussion in the body of an RFC and an appendix to the RFC, so there I think it's a bit gray. I do think that if we are going to undertake such reorganizations there ought to be some discussion about it. I believe that removing section 9 is definitely outside the scope of our charter. Part of the reason that I have taken such a strong position on this is that it appears to me that the direction to move it to an appendix is prepartory to removal and that I think we definitely cannot do. Scott K From spf2@kitterman.com Sun Sep 2 22:52:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8B521F8495 for ; Sun, 2 Sep 2012 22:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zvx3Ycv2k2ZY for ; Sun, 2 Sep 2012 22:52:42 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D487021F846B for ; Sun, 2 Sep 2012 22:52:42 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C52AF20E40BA; Mon, 3 Sep 2012 01:52:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346651556; bh=5NKyJ0IHUvHeyPIi8sTLDxgS8h12ukDoWWqt9szgkS0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=A5EvgIbONm7JY0RQV43mt7bTkZ8zYq9YwLSkVurNnlyxalBOh4a12jM8aBD1yad+c zZyG6P0tDxosmjDYRX9l1GRkyHUU55vIwuoRDEcWcaZYFwUc6/tdOn7UH/bZaFLADS zxZiR5iQ7aepmVMXUN+qOlg7VcLPjmm6PwujQ+L8= 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 AEA2B20E40B2; Mon, 3 Sep 2012 01:52:36 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 03 Sep 2012 01:52:36 -0400 Message-ID: <6354353.tSmACd1r1W@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <4094761.6jIeQ51N6G@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 05:52:43 -0000 On Sunday, September 02, 2012 11:45:26 AM Murray S. Kucherawy wrote: > On Fri, Aug 31, 2012 at 10:35 PM, Scott Kitterman wrote: > > The charter says: > >> Changes to the SPF specification will be limited to the correction > >> of errors, removal of unused features, addition of any enhancements > >> that have already gained widespread support, and addition of > >> clarifying language. > > > > Moving section 9 to an appendix is none of those things. > > Here's a monkey wrench for that logic: Section 9, as it is explicitly > non-normative, doesn't actually specify anything. Thus, rewriting, > extending, removing, or repositioning it is not a change to "the SPF > specification". Then I guess removing all the security considerations wouldn't be a change to the SPF specification either? Scott K From sm@elandsys.com Sun Sep 2 23:59:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684B621F84B8 for ; Sun, 2 Sep 2012 23:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cT0RrHTfpPao for ; Sun, 2 Sep 2012 23:59:20 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC98621F84B6 for ; Sun, 2 Sep 2012 23:59:20 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.158]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q836x3aw011130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Sep 2012 23:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346655556; bh=O/o480yXzao11QWAI0I/Z8wWczyHwaxwsO2t1az4ekk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xFdWfboutwzuUQHjKm6zpxcTt0p22QjZu3RUsqqvVG0vWzUtmjnwTsrQxlkME3DKF GLBNRcN15QExxHhTHvNEMY0HeZlMKl4hZFfUg4l3bvd6mDPZhkViUpIDjiPv7DhG7M abFoxUl62ijvnoRXvs0gV7I1VFRetoybkNdFd5fw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346655556; i=@elandsys.com; bh=O/o480yXzao11QWAI0I/Z8wWczyHwaxwsO2t1az4ekk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=g9Z0+9zODUvz3akI3r3LPQ94un/0OZQxguQIETLno8S4Gi5gV+23KSH2sHLPbfk6E xwiuQUqwENjMtHAM5fRPWtBa/pY5jW3d9t8Ckamz0ZTYONrkNq4UC+iWPt+mw6FMZy CGaFqf4lwfaYnpSqJzChplxnAdgUKgRrMUwaDVaI= Message-Id: <6.2.5.6.2.20120902222427.08a96658@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 02 Sep 2012 22:34:50 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20120831232330.09fe9648@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 2 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 06:59:21 -0000 Hi Murray, At 20:02 02-09-2012, Murray S. Kucherawy wrote: >Sorry, can you clarify? RFC2119 says something like this? It was a typo. I should have written that it was similar to what is in RFC 4408. Regards, S. Moonesamy From sm@elandsys.com Sun Sep 2 23:59:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B72621F84B6 for ; Sun, 2 Sep 2012 23:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWa42jjaWB9R for ; Sun, 2 Sep 2012 23:59:20 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D8421F842B for ; Sun, 2 Sep 2012 23:59:20 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.158]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q836x3b0011130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 2 Sep 2012 23:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346655559; bh=qDvGdFluPcszF6Vf8OkJejYkZK0cClzvwvLg+cNJeE8=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=REd/TFGR9GE4kplvcesXkEuaGNX9WsX4YcMkibTJartkKooj8R/sbUNGZTQbprP// TPkAVR2JO8aQ7oeqJdmxalgEHqHNxMUCc6fnosbp2qFTQy600u1ja85uMdOy67piM5 se6MN/vFkynY/gaZtXxszsN6LNKoU2yAdF+A2qu8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346655559; i=@elandsys.com; bh=qDvGdFluPcszF6Vf8OkJejYkZK0cClzvwvLg+cNJeE8=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=HvSvY2ysg2IVESMzNUrCEIK79eSwdEX5yuF/DJM+XNs0ShuSITMl2bDqhTgzkiwMv FsK768803IcgNl+KlokvOe/UCko3rkXBfCyBfB2pRQlw9h3X2r4rxNRctPhyfmE6uZ 2Yr2dPQbLnHyMs84SiSZ76bz/51UqmAVBD90o1Sw= Message-Id: <6.2.5.6.2.20120902224500.08a9f490@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 02 Sep 2012 23:06:40 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <3564786.BIr6kOu5E1@scott-latitude-e6320> References: <6.2.5.6.2.20120831223438.09fe98d8@elandnews.com> <3564786.BIr6kOu5E1@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Section 1 of raft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 06:59:21 -0000 At 22:06 02-09-2012, Scott Kitterman wrote: >I don't understand this comment beyond the bit about ADMDs. Why does section >3 matter? Why remove the 2119 words? The text mentions SPF records. SPF records are discussed is Section 3. The question which arises is about why is it important to add a "SHOULD" not" and a "MUST". Quoting from RFC 2119: "Imperatives of the type defined in this memo must be used with care and sparingly." Regards, S. Moonesamy (speaking for myself) From vesely@tana.it Mon Sep 3 01:46:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B008521F84DE for ; Mon, 3 Sep 2012 01:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.325 X-Spam-Level: X-Spam-Status: No, score=-4.325 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ur+x04W9qChB for ; Mon, 3 Sep 2012 01:46:00 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id BD73B21F84D4 for ; Mon, 3 Sep 2012 01:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346661956; bh=aXmsowSefp0WpAzLD7L6mXeKV+Gu0upAVSXFEuTYyPE=; l=2210; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=d9AGPX7PJ8eveyAZ8LCtrfQtmiGLMRbFHW73i/O9LGL+u5uXhMjoUs6sw7CBF9hpW Hq8I3raP5s5VeSPkXR92ABy0RrZ3+uuarW0lSEiDa0pXOOZOI6FctlIl8QuU+9XBrC SIpMXnQiSGkOr3vS2Lb2XJ2pjhEAemS2Z8RE5C64= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 03 Sep 2012 10:45:56 +0200 id 00000000005DC039.0000000050446E44.000066FA Message-ID: <50446E44.3070103@tana.it> Date: Mon, 03 Sep 2012 10:45:56 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1346376279.88598.YahooMailClassic@web125403.mail.ne1.yahoo.com> <5041EC47.3010908@tana.it> <2807745.DgKN7pdKFO@scott-latitude-e6320> In-Reply-To: <2807745.DgKN7pdKFO@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 08:46:00 -0000 On Mon 03/Sep/2012 07:28:26 +0200 Scott Kitterman wrote: > On Saturday, September 01, 2012 01:06:47 PM Alessandro Vesely wrote: >> >> It seems to me that not only local macros are involved, but also >> intermixed use of domain macros during HELO evaluation, and %h during >> MAIL FROM. >> >> We could have restricted the use of those macros to terms that imply >> no DNS query, such as explanations. Now, assuming we didn't intend to >> do that, we need to grant them a fair usability. Taking into account >> that SPF grammar provides no way to guard against malformed >> parameters, /any/ non-trivial use of those macros can result in a >> malformed domain, potentially. >> >> Hence, inflexibly mandating permerror implies an unintentional penalty >> for users of those macros, inasmuch as (1) there is an attack path >> whereby an abuser of the domain name can get --by design-- a permerror >> rather than the stipulated result, and (2) the rr=e tag of RFC 6652 >> will not be limited to real errors, but include items rather akin to >> rr=f or similar. > > I think the 'attack' path is limited to 'p'. In all other cases additional > information that's looked up in DNS is based on the domain owner's DNS. Can you make an example with 'p'? What I meant is, say: domain.example TXT "v=spf1 exists:{%h}._spf.domain.example -all" Dunno why anyone would do so. It is a non-trivial use of %h. Now, an abuser who knows no valid host name can avoid to "fail" like so: S: 220 some.server.example C: HELO some..funny.name..U..never.find..or..longer..stuff... S: 250 Ok. C: MAIL FROM: Now the verifier finds the SPF record and gets a malformed domain name. Instead of "fail" it gets "permerror", which is incorrect IMHO. A symmetric example could be built using %o during a helo check. It would looks less significant because tricking just the helo check isn't worth. BTW, several implementation evaluate HELO before getting MAIL FROM. (That is, before a transaction gets started.) What do they do if they find %{o} in the record? And does %{d} expand the same as %{h} in that case? I'm not sure the I-D explains that beyond any doubt. From vesely@tana.it Mon Sep 3 02:07:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C7F21F84FC for ; Mon, 3 Sep 2012 02:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.622 X-Spam-Level: X-Spam-Status: No, score=-4.622 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjSjXzvV5Asb for ; Mon, 3 Sep 2012 02:07:03 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id B24AF21F84FA for ; Mon, 3 Sep 2012 02:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346663220; bh=Rk/R7kVYv7NhJ94WJ6erPbhhAx0EiqGuJ/GQDau7q9I=; l=1304; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=kuv2Cxb3/k3vdc9aUskufzS5u37dHhpoWpKIzvE60tGCRBVizmH1jnQy1o2lI2PCz fh+O3S0THmg4G5wzIgBu4fDUgBH81nHSm0znun5+pQixBoJ3GJFxjXH4MgKy4+ToXB +8gWpyZyMIPNoVD+/Fu7bVANH75Ac9ogpUz/bbKQ= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 03 Sep 2012 11:07:00 +0200 id 00000000005DC039.0000000050447334.00006B8D Message-ID: <50447333.60102@tana.it> Date: Mon, 03 Sep 2012 11:06:59 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <2385202.ToyOPapQOP@scott-latitude-e6320> <504234EC.8000505@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 09:07:08 -0000 On Sun 02/Sep/2012 20:50:08 +0200 Murray S. Kucherawy wrote: > On Sat, Sep 1, 2012 at 9:16 AM, Alessandro Vesely wrote: > >> For the security aspect, I already mentioned the solution of renaming >> existing fields to Old-Received-SPF before adding new ones: >> http://www.ietf.org/mail-archive/web/spfbis/current/msg01029.html >> The package implementing that is in multiple Linux distributions, so >> it can be considered widespread, no? > > Maybe, but isn't it easier to refer to published security text rather > than introduce yet another "to solve problem X, you could do something > like Y"? RFC 5451 not only has Section 7.1, it also relies on Section 5. I see two difficulties in transporting that semantics as-is: The first one is formal, as the spec there does not provide a general algorithm for ensuring authenticity of any trace field, but is specific to A-R. Simply saying "do with Received-SPF: the same that RFC 5451 specifies for Authentication-Results:" is rather vague. The second difficulty is backward compatibility. Existing verifiers may not bother setting a "receiver" tag at all in the Recaived-SPF: they generate, or they may set it to a value not compatible with the trustworthiness determination specified by Section 5 of RFC 5451. From vesely@tana.it Mon Sep 3 02:07:09 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF1021F84FC for ; Mon, 3 Sep 2012 02:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.323 X-Spam-Level: X-Spam-Status: No, score=-4.323 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74UfLMaszkVV for ; Mon, 3 Sep 2012 02:07:05 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1C52B21F84F9 for ; Mon, 3 Sep 2012 02:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346663224; bh=C7i2FYV2a5XWZeYasqOuZ5Kn1rDyI77fT7Pvg6QCQ+g=; l=3090; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Qbx/QmOif79mO0hPlVuxZMYFxbOTz5W2J4y9JauqrSTsHTstclcFxxe9xivLmom06 LpDL5vFYfxnPWE4NMBfNhKnal8xzrPaiqpdUhlws1Bs6TfVS5zvbnL/O1GAOCZJG3i tOVXpn2L/AJibkBnkfkjfW1vneampVAREj8bUeDk= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 03 Sep 2012 11:07:04 +0200 id 00000000005DC039.0000000050447338.00006BA4 Message-ID: <50447338.7050708@tana.it> Date: Mon, 03 Sep 2012 11:07:04 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <2385202.ToyOPapQOP@scott-latitude-e6320> <504234EC.8000505@tana.it> <1381988.MgFA4MVS4M@scott-latitude-e6320> In-Reply-To: <1381988.MgFA4MVS4M@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 09:07:10 -0000 On Mon 03/Sep/2012 07:32:13 +0200 Scott Kitterman wrote: > On Saturday, September 01, 2012 06:16:44 PM Alessandro Vesely wrote: >> >> I dislike suggesting a kludge as 'a reasonable way to do it'. I know >> that examples are not normative, but that one is likely the single one >> example of A-R usage that we are going to give, hence its value is >> almost that of a SHOULD, RFC 2119 notwithstanding. *Standardizing >> kludges is evil*. If the forensics data that Received-SPF: conveys is >> what is wanted, then use that field, period. > > What kludge? A-R has optional fields and room for comments, so I don't see > anything kludgy about suggesting a way to fill them out. Just recall the history of stuffing data into Received:. If you still don't see it, consider: MIME-Version: 1.0 X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , How about stuffing that into an A-R instead of using each header field for the value(s) that belong to it? E.g. like so: MIME-Version: 1.0 X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Proposed Section 7 update Authentication-Results: some.host.example; auth=none reason="X-BeenThere:spfbis@ietf.orgX-Mailma n-Version:2.1.12Precedence:listList-Id:SPFbis d iscussion listList-Unsubscribe:,List-Archive: List-Pos t:List-Help: List-Subscribe: ," >> For the security aspect, I already mentioned the solution of renaming >> existing fields to Old-Received-SPF before adding new ones: >> http://www.ietf.org/mail-archive/web/spfbis/current/msg01029.html >> The package implementing that is in multiple Linux distributions, so >> it can be considered widespread, no? > > What package? Courier-MTA. How do other packages tackle that problem? > Generally, I think if you trust the header you should leave it untouched and > if you don't you should probably remove it. I don't see value in leaving > untrusted content. More precisely, you should trust your border MTAs only. However, the SPF results obtained by a non-suspect external host can be handy if you happen to manually inspect the header of a forwarded message. From vesely@tana.it Mon Sep 3 02:58:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E9621F84EF for ; Mon, 3 Sep 2012 02:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.621 X-Spam-Level: X-Spam-Status: No, score=-4.621 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKiEbYHY432V for ; Mon, 3 Sep 2012 02:58:26 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0E47721F84A6 for ; Mon, 3 Sep 2012 02:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346666303; bh=VMl8SBLijUNDU7YCXE4BIE6Egr++9gdAsXpriQGlXM0=; l=4503; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=P7IAGryYxUkNaxN2t8w0KS9EwKyVYrB9gn7U3xXoKNWoPN7bbr5EBoEd30MJGFOz/ TuvKWvmIaIi69Fh+0o0C2BW+303QW+iDZi4l9stEzFBV6hQTQMfiNBTxjQMQd0zADH o/l87fUfKEfPbL2GYTu7knxCrTcGG5DsdzyJLKxI= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 03 Sep 2012 11:58:23 +0200 id 00000000005DC039.0000000050447F3F.000078C8 Message-ID: <50447F3E.7070702@tana.it> Date: Mon, 03 Sep 2012 11:58:22 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <5042402C.10009@tana.it> <23220341.zrDTuUZbFe@scott-latitude-e6320> In-Reply-To: <23220341.zrDTuUZbFe@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 09:58:27 -0000 On Mon 03/Sep/2012 07:40:07 +0200 Scott Kitterman wrote: > On Saturday, September 01, 2012 07:04:44 PM Alessandro Vesely wrote: >> On Sat 01/Sep/2012 05:26:34 +0200 Murray S. Kucherawy wrote: >>> On Fri, Aug 31, 2012 at 6:23 PM, S Moonesamy wrote: >>>> [At 17:54 31-08-2012, Murray S. Kucherawy wrote:] >>>> >>>>> Perhaps the simplest thing to do is to start an individual submission >>>>> to collect this stuff, and move it out of here. >> >> +1 > > First, IIRC we decided we'd get to the end of doing the draft and then decide > if it needed splitting then, so I don't understand the sudden rush to judgment > on this topic. > > Second, I think it would be a mistake to make completion of the working > group's effort contingent on completion of work we aren't chartered to do. If > we decide that 4408bis needs to be split, then I think we should really > recharter to do it. Yes. The point is that, if we delay the decision to write part two until after part one is submitted, we won't be able to change part one any more. I attempted a step by step outline in a later message. >>>>> The trick, though, is that RFC4408bis itself should then refer >>>>> to it, which will delay its publication until that document >>>>> finds a new home or an AD sponsor and is also published. >> >> Isn't it possible to just mention "an applicability statement to be >> published next" sort of thing? Part two will then refer to RFC4408bis. > > No. Section 9 is pretty solidly intertwined in the main body in a > number of places. Such a document would need to have a normative > reference from 4408bis and so they'd have to be published > together. That's part of the changes to part one. It seems not overly difficult to me, but I'd need to actually try it in order to be sure. > In any case, if we rip out section 9 (which was in 4408) then we're > outside our charter regardless of where we put it. I think Murray's monkey wrench works on that point. We just wouldn't want to do it unless we were preparing a better place to put it into. > If we're going to recharter, then let's just recharter to do the > work of the group in two documents, rather than leave it half > done. Yes. It just takes time to get there, after we make that decision. >>> We just have to accept the unpredictable delay. The only work then >>> is to decide what parts of the current Section 9 are required to make >>> the document whole (those should stay) and which constitute >>> non-critical implementation advice (those should move). >>> >>> It's possible that new content from other sections is also a candidate >>> for such a migration, which would make Arthur happy. >> >> Yes, I don't think splitting the document is a silly idea. Indeed, it >> reflects the "second life" of SPF pretty well. While some parts of >> Section 9 are almost fine where they are, any rejection-related advice >> should be moved to part two, possibly including the exp= modifier. > > This makes no sense to me. One of the hardest things for me to > understand about splitting is how 4408bis would be complete without > the receiver policy discussion. Part one will define the results and the algorithm to compute them. It will also define header fields usage and the like, but nothing about receiver behavior. That way, part one would be the minimal amount of specification for someone, like Yahoo!, say, who just needs SPF to comply with DMARC. It's an annoyance to those users to have to go through the countless advices about rejection. > We could move that back into the main part of the document, but I > think it's better where it is. If it stays non-normative, I agree. In any case, I think we should remove the parts that didn't get any deployment, such as operations that assume a specialized DNS server. >>> Oh, and you need to find an editor(s). ;-) >> >> May I volunteer for that? > > If the group's going to decide the document I've been working on > should be split in two, then I'd prefer to keep working on both > parts of it. That's fine for me, if you have the cycles. The only point is that it's easier for me to write a tentative split than to explain down to an actionable level of detail why, say, we don't need forward references from part one to part two. Even then, it would take many hours to complete it, more than what I'd be willing to spend for the mere purpose of proving the concept. From hsantos@isdg.net Mon Sep 3 05:07:53 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF3121F8464 for ; Mon, 3 Sep 2012 05:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.084 X-Spam-Level: X-Spam-Status: No, score=-102.084 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xk10kMt21-vP for ; Mon, 3 Sep 2012 05:07:52 -0700 (PDT) Received: from groups.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8D85821F8468 for ; Mon, 3 Sep 2012 05:07:51 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2160; t=1346674064; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ZxoVkHygOVCV03lW04XdI1Y3m94=; b=Em6nr7hz5QHrz0zSNV71 aIkv4rk8jCjlJTr2s0EGDc3MLzKedlTd8QiEBRRBv8XJonE4NHGVv5EExyxLwMvs hr0Y7odqwSQgp1Op2l+2QIrUNRcnn5cN5NF6VCkTth7xhrycJ0aVqPoVAxMJRemE GuEIBC6pFdlu7hI5SmREp+Q= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 03 Sep 2012 08:07:44 -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 2695850681.2700.4084; Mon, 03 Sep 2012 08:07:44 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2160; t=1346673851; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0Xi21rp TySlxmLUU089TphnfbXefEv2xmnbHOJmAGeY=; b=sVHZgj+oTmg5olnoiSiuYyR GQ7On4c3tafumAnXcwmZetH1nVJJHyPkrweEAvdbkOEQISZ9tZqVDABNeBXd8Lci E3+2t/r0CgHGdNEiOUFPI5ZW9E4AlP8FYD5/rHtkRgQ9bXWcTEhRf1C3nROfIofQ CnK4sNIX5jxnG4vP+Dk8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 03 Sep 2012 08:04:11 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3294649458.9.1540; Mon, 03 Sep 2012 08:04:10 -0400 Message-ID: <50449DA1.6070206@isdg.net> Date: Mon, 03 Sep 2012 08:08:01 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alessandro Vesely References: <2385202.ToyOPapQOP@scott-latitude-e6320> <504234EC.8000505@tana.it> <50447333.60102@tana.it> In-Reply-To: <50447333.60102@tana.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, "spf2@kitterman.com >> Scott Kitterman" Subject: [spfbis] Suggestion: Remove A-R from 4408BIS X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 12:07:53 -0000 It seems there is too drama regarding A-R and trying to add it. It drastically alter scope of SPF with ACCEPT+MARK mode of receiver behavior, it created new security issues and conflicts of major opinion almost surely to raise WGLC issues. SUGGESTION: Remove A-R from 4408BIS and all related changes due to it and if we someone believes it is still useful for SPF, then write a I-D for it, perhaps with a title Reporting SPF with Authentication-Results and this I-D can go into extensive concepts of not only how to write it, but perhaps also how to combine it with other A-R marking for receiver evaluations, etc. Alessandro Vesely wrote: > On Sun 02/Sep/2012 20:50:08 +0200 Murray S. Kucherawy wrote: >> On Sat, Sep 1, 2012 at 9:16 AM, Alessandro Vesely wrote: >> >>> For the security aspect, I already mentioned the solution of renaming >>> existing fields to Old-Received-SPF before adding new ones: >>> http://www.ietf.org/mail-archive/web/spfbis/current/msg01029.html >>> The package implementing that is in multiple Linux distributions, so >>> it can be considered widespread, no? >> Maybe, but isn't it easier to refer to published security text rather >> than introduce yet another "to solve problem X, you could do something >> like Y"? > > RFC 5451 not only has Section 7.1, it also relies on Section 5. I see > two difficulties in transporting that semantics as-is: > > The first one is formal, as the spec there does not provide a general > algorithm for ensuring authenticity of any trace field, but is > specific to A-R. Simply saying "do with Received-SPF: the same that > RFC 5451 specifies for Authentication-Results:" is rather vague. > > The second difficulty is backward compatibility. Existing verifiers > may not bother setting a "receiver" tag at all in the Recaived-SPF: > they generate, or they may set it to a value not compatible with the > trustworthiness determination specified by Section 5 of RFC 5451. > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From spf2@kitterman.com Mon Sep 3 11:03:50 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9FF21F8587 for ; Mon, 3 Sep 2012 11:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z41qdlYNko+R for ; Mon, 3 Sep 2012 11:03:49 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 848CE21F8575 for ; Mon, 3 Sep 2012 11:03:49 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 5856DD04061; Mon, 3 Sep 2012 13:03:48 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346695428; bh=TSLoByvJAHcFi08ZYGW+A9tCP6fn6xZC08h/eb33F3o=; h=References:In-Reply-To:Subject:From:Date:To:From; b=Dfw/VYazXWnNdZvSBErGV2UO6nTvyH/v9uOwb8GKD9jQx8PFaDrFzdFM4OewambjK E3PWtBgl8qKDu6rsvyivb1JtDyyE9RUvnTKYS1k08vElLhS0dfA/3ARgj04lwlYfTZ Cto+H7Ewmw/bfUIfa/vGIT8zgLva8PXfkD53nPOk= Received: from [IPV6:2600:1003:b006:8be1:eb40:e0aa:485c:a5ab] (unknown [IPv6:2600:1003:b006:8be1:eb40:e0aa:485c:a5ab]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DE102D04050; Mon, 3 Sep 2012 13:03:47 -0500 (CDT) References: <1346376279.88598.YahooMailClassic@web125403.mail.ne1.yahoo.com> <5041EC47.3010908@tana.it> <2807745.DgKN7pdKFO@scott-latitude-e6320> <50446E44.3070103@tana.it> User-Agent: K-9 Mail for Android In-Reply-To: <50446E44.3070103@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Mon, 03 Sep 2012 14:03:46 -0400 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 18:03:50 -0000 Alessandro Vesely wrote: >On Mon 03/Sep/2012 07:28:26 +0200 Scott Kitterman wrote: >> On Saturday, September 01, 2012 01:06:47 PM Alessandro Vesely wrote: >>> >>> It seems to me that not only local macros are involved, but also >>> intermixed use of domain macros during HELO evaluation, and %h >during >>> MAIL FROM. >>> >>> We could have restricted the use of those macros to terms that imply >>> no DNS query, such as explanations. Now, assuming we didn't intend >to >>> do that, we need to grant them a fair usability. Taking into >account >>> that SPF grammar provides no way to guard against malformed >>> parameters, /any/ non-trivial use of those macros can result in a >>> malformed domain, potentially. >>> >>> Hence, inflexibly mandating permerror implies an unintentional >penalty >>> for users of those macros, inasmuch as (1) there is an attack path >>> whereby an abuser of the domain name can get --by design-- a >permerror >>> rather than the stipulated result, and (2) the rr=e tag of RFC 6652 >>> will not be limited to real errors, but include items rather akin to >>> rr=f or similar. >> >> I think the 'attack' path is limited to 'p'. In all other cases >additional >> information that's looked up in DNS is based on the domain owner's >DNS. > >Can you make an example with 'p'? > >What I meant is, say: > > domain.example TXT "v=spf1 exists:{%h}._spf.domain.example -all" > >Dunno why anyone would do so. It is a non-trivial use of %h. Now, an >abuser who knows no valid host name can avoid to "fail" like so: > >S: 220 some.server.example >C: HELO some..funny.name..U..never.find..or..longer..stuff... >S: 250 Ok. >C: MAIL FROM: > >Now the verifier finds the SPF record and gets a malformed domain >name. Instead of "fail" it gets "permerror", which is incorrect IMHO. > >A symmetric example could be built using %o during a helo check. It >would looks less significant because tricking just the helo check >isn't worth. > >BTW, several implementation evaluate HELO before getting MAIL FROM. >(That is, before a transaction gets started.) What do they do if they >find %{o} in the record? And does %{d} expand the same as %{h} in >that case? I'm not sure the I-D explains that beyond any doubt. The SPF record for both the Mail From and HELO domains are published by the domain owner, so in order for the concerning behavior you describe to occur, the domain owner would have had to published a record asking for it. PTR and the "p" macro are different because they involve name attributes associated with the connecting IP address, which is under control of the attacker or their ISP. Given that there is a precise description of what to use for localpart in HELO checks, I don't understand what's confusing? Scott K From hsantos@isdg.net Mon Sep 3 13:03:02 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E1321F84CF for ; Mon, 3 Sep 2012 13:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.383 X-Spam-Level: X-Spam-Status: No, score=-102.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZAj3EE9led6 for ; Mon, 3 Sep 2012 13:03:01 -0700 (PDT) Received: from secure.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8D37A21F8466 for ; Mon, 3 Sep 2012 13:03:01 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=481; t=1346702575; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=qYc+AI47PoMGBwtwexxmRrE7gpk=; b=l/IT2OWR60Wj327ETT2t 7QbG0MMpHXIhR40uMJHp3LwMm8hu67bb9NuPevFOAZ6d2Hn+eMZCF9WycsDFSwBd a9Kmls7qs/ko0yyhU7VenCYkF2lEmmSDlbweATfhktdsKlX8Pb1YEd86FeS6bvSu qH5DpHwdErbGxRZ7Im4XvwY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 03 Sep 2012 16:02:55 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2724361081.2700.5740; Mon, 03 Sep 2012 16:02:54 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=481; t=1346702365; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0MvlTDv 0kFM1RYItwa3cEgl9dEFOiYJiyUywKQp+xF8=; b=iHNR8dcBO+7WhZQVXkc3zT+ 0If0V7mfVOivnBhz0I649sMoifuEzr2RIwO4DEtItPRON/BnkPPCRSAcunotAvNu vfpl4iz1XKDILTkolELF+iOceDe7ohWq82pfXIDSJN3hsXAmr/goKzS6LtR630gl 1t21swD49TiMRYiNLULI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 03 Sep 2012 15:59:25 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3323162817.9.3836; Mon, 03 Sep 2012 15:59:24 -0400 Message-ID: <50450D03.5080202@isdg.net> Date: Mon, 03 Sep 2012 16:03:15 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] Possible ABNF nit with Received-SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 20:03:02 -0000 In 4408 section 7 (7.1 for BIS), there is: key = "client-ip" / "envelope-from" / "helo" / "problem" / "receiver" / "identity" / mechanism / name identity = "mailfrom" ; for the "MAIL FROM" identity / "helo" ; for the "HELO" identity / name ; other identities Isn't the keys for identity redundant for the regular set of possible keys? "mailfrom" same as "envelope-from" for key "helo" same as "helo" for key "name same as "name" for key -- HLS From agthisell@yahoo.com Mon Sep 3 13:27:38 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B2E21F8597 for ; Mon, 3 Sep 2012 13:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.736 X-Spam-Level: X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[AWL=-1.388, BAYES_05=-1.11, MISSING_SUBJECT=1.762] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dw1TxLeseHKY for ; Mon, 3 Sep 2012 13:27:38 -0700 (PDT) Received: from nm21-vm0.bullet.mail.ne1.yahoo.com (nm21-vm0.bullet.mail.ne1.yahoo.com [98.138.90.94]) by ietfa.amsl.com (Postfix) with ESMTP id C4DA521F8587 for ; Mon, 3 Sep 2012 13:27:37 -0700 (PDT) Received: from [98.138.90.52] by nm21.bullet.mail.ne1.yahoo.com with NNFMP; 03 Sep 2012 20:27:33 -0000 Received: from [98.138.89.167] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 03 Sep 2012 20:27:33 -0000 Received: from [127.0.0.1] by omp1023.mail.ne1.yahoo.com with NNFMP; 03 Sep 2012 20:27:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 409990.3667.bm@omp1023.mail.ne1.yahoo.com Received: (qmail 26476 invoked by uid 60001); 3 Sep 2012 20:27:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346704053; bh=P/KUdAfDm29AuUOJBor23LfkFbRxmFpqdVs9CxFbdnU=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:To:MIME-Version:Content-Type; b=Ya1tLYE3nbuZE2rD07sSJtJZk5GRoXc/6DBQsPqywNgX17gAFwITZn3UQsZ5iuCXJmlNdxv2LmHJfKul0NUmHEV9ZMf51uxji6kx5PAsjpYj9SL9lp+FCHzcQkGX934TQRGodK72U3b2m78w9BpWZWQTnqy9gzfIphHjjOrDWro= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:To:MIME-Version:Content-Type; b=bnI0VzACTAQ89L9P4J4Hp40tjJA7i1smhjm5dbjzbRkJmJDTDxDiWRWt3hrlHYG8jwwxrngcKbTBL1G2PyTwGw6wBJ70vOhVsbrvOppG1Tb4HuYIWOMZqwTsZGvUCvRcn2LcxwL4T6Xx9GU89dWjzAsZ3qfjBRYq0FG1AyFyriI=; X-YMail-OSG: b.aUYuUVM1nkRq8.bTgp8gfCjPm1v6uykRluSMnNNDdRFnu 0bdLjqm_9te1E1F8CSNnToUy8CTYVToR9DaRBMEr51O6TKI1rjaZJz1wX9qJ f0stf1PHaOcHtEnPWYv609Yhc.XJHdJoaINo5Sm4d3O0kMZe4ETzINk3lWjv QMIpCt0tKqLtxqT15t.F2zJbMtfKsXhhAd7eFpQHzQ7nRD5b4s_U6FAqKOQ0 So5WZ8uq7FCL7c3VC8gT23d3ITKNSFkO9p7yIYBWhuX7jNWwArk4OSYfZVRw bNF15GoZUEEZk._wDmbTSwtg5fiJUVjiso9qFFwApYq9M6lyL3FmBI3do3Op qGMLmjpYQ6ZnBpjtNCEgpRALST7cAsFONoHdxFOqLpmgv4JDyvjiarIBtLUj g7lQ6ADnoLhqeiTubaJnR38xydjNCugMf8uzwLIbbn5r6l6fJ.cBV9ZsW2Wq ZRpgk6uHh_C4Eo1LHwA-- Received: from [71.61.133.134] by web125403.mail.ne1.yahoo.com via HTTP; Mon, 03 Sep 2012 13:27:32 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346704052.26366.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Mon, 3 Sep 2012 13:27:32 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] (no subject) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 20:27:38 -0000 > Isn't the keys for identity redundant for the regular set of possible keys? No. Keep reading the RFC, later paragraphs explains everything. In particular: identity the identity that was checked; see the ABNF rule From W.Doust@racingvictoria.net.au Mon Sep 3 16:29:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2567A21F858A for ; Mon, 3 Sep 2012 16:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[AWL=-0.498, BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKmaPgMRlmOY for ; Mon, 3 Sep 2012 16:29:15 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 675E521F8575 for ; Mon, 3 Sep 2012 16:29:15 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v7, 1, 0, 4874) id ; Tue, 04 Sep 2012 09:29:06 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Sep 2012 09:28:27 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF010D49C4@XCHANGE.rvl.internal> In-Reply-To: <5a1418c7-e88a-4543-b155-bd26d680b334@email.android.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] Deployment guide Thread-Index: Ac2G3Y0ADUVgdQgsT6+wVHLR31yJ7wDTMtBg References: <20120324090349.15462.qmail@joyce.lan><2230111.fUdp390bGt@scott-latitude-e6320><4F8884A7.6080404@isdg.net><10035218.VxSKd6zvrx@scott-latitude-e6320><9452079D1A51524AA5749AD23E0039280F1346@exch-mbx901.corp.cloudmark.com><6.2.5.6.2.20120830100555.09761cd0@resistor.net> <5a1418c7-e88a-4543-b155-bd26d680b334@email.android.com> From: "Wayne Doust" To: "Scott Kitterman" , Subject: Re: [spfbis] Deployment guide X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 23:29:16 -0000 -----Original Message----- From: spfbis-bounces@ietf.org [mailto:spfbis-bounces@ietf.org] On Behalf Of Scott Kitterman Sent: Friday, 31 August 2012 4:30 AM To: spfbis@ietf.org Subject: Re: [spfbis] Deployment guide I don't think this is a good idea. Scott K _______________________________________________ Whilst a deployment guide inside the rfc is probably not a great thing, some text to strongly point to deployment guides - perhaps leading eventually to an rfc deployment guide is essential. In the absence of such direction, it would be better to have it in the appendix than not at all. The number of faulty SPF records I receive on a daily basis is simply ridiculous. Over 50% of these fall into two camps: duplicate entries and the use of quotes without spaces. Others make basic mistakes such as "ipv4:" or don't check their include references. This is not to mention the email appliances that are broken. Regards, Wayne Doust From vesely@tana.it Mon Sep 3 23:49:50 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C842321F8512 for ; Mon, 3 Sep 2012 23:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.23 X-Spam-Level: X-Spam-Status: No, score=-3.23 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhMPH6o0zb1N for ; Mon, 3 Sep 2012 23:49:50 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2815921F84FD for ; Mon, 3 Sep 2012 23:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346741384; bh=zRAwqHONBasiIVrdxXQsq8puONEnn9lbWZQFzP/Ilrw=; l=1860; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=S58UGcJ32hdaoGadJXF8krRzdwVfAInj3uAAR44OkaOCLeNGS2bYVQmZsKBBhz7/H 5DrVy+AHmBvx5N5lAeMr8kqGtWcnHYfvBofQjbzDYW5nqJZjJIY0iJ9dY/VsLqq6ji e4X4TMWraep9d/GtS1l8So53BZrCNjivczRMz4FY= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 04 Sep 2012 08:49:44 +0200 id 00000000005DC048.000000005045A488.000015E8 Message-ID: <5045A487.1070802@tana.it> Date: Tue, 04 Sep 2012 08:49:43 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1346376279.88598.YahooMailClassic@web125403.mail.ne1.yahoo.com> <5041EC47.3010908@tana.it> <2807745.DgKN7pdKFO@scott-latitude-e6320> <50446E44.3070103@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 06:49:50 -0000 On Mon 03/Sep/2012 20:03:46 +0200 Scott Kitterman wrote: > Alessandro Vesely wrote: >> >> What I meant is, say: >> >> domain.example TXT "v=spf1 exists:{%h}._spf.domain.example -all" >> >> Dunno why anyone would do so. It is a non-trivial use of %h. >> Now, an abuser who knows no valid host name can avoid to "fail" >> like so: >> >> S: 220 some.server.example >> C: HELO some..funny.name..U..never.find..or..longer..stuff... >> S: 250 Ok. >> C: MAIL FROM: >> >> Now the verifier finds the SPF record and gets a malformed >> domain name. Instead of "fail" it gets "permerror", which is >> incorrect IMHO. > > The SPF record for both the Mail From and HELO domains are > published by the domain owner, so in order for the concerning > behavior you describe to occur, the domain owner would have had to > publish a record asking for it. There would be no invalid domain issues if %h were used in exp=. The SPF record shown above uses %h so as to affect the result, which is what I call non-trivial use. The question is: Is it possible to use %h in such a way? My claim is that if invalid domains MUST result in PermError, then there is _no good way_ to use %h. That is, such that authorized senders pass and attackers match -all. Thus, if we solve #22 by mandating PermError, we should state that %h is a sort of second-class macro. BTW, is it used? > PTR and the "p" macro are different because they involve name > attributes associated with the connecting IP address, which is > under control of the attacker or their ISP. Is this point related to invalid domains/PermError? > Given that there is a precise description of what to use for > localpart in HELO checks, I don't understand what's confusing? This is a different subject. I'll post a separate message on it. From vesely@tana.it Tue Sep 4 02:20:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1187621F85A3 for ; Tue, 4 Sep 2012 02:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.974 X-Spam-Level: X-Spam-Status: No, score=-3.974 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWE8JjOU3aDa for ; Tue, 4 Sep 2012 02:20:25 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5A31921F8554 for ; Tue, 4 Sep 2012 02:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346750424; bh=OlWbuSA9+1jOLoHSJHIAOfBY3ESLAtYddNeClexPAdE=; l=1464; h=Message-ID:Date:From:MIME-Version:To:Content-Transfer-Encoding; b=W01jps4nVj6NwU+W08AgXRAg/Zi1uCKPCr7IsLKKFiRtj0d4tLJELw3Dy1MI/2pFB K0gW/0yi0LZe6A8QLFGVXEon5rcfPNztSfyugUaVdrinGNzCQ83V5l4RhRyftCt9cW LUW4iZTDZFc0GNqOGxo6X5IvKF/A78O/3fMlBz74= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 04 Sep 2012 11:20:24 +0200 id 00000000005DC03F.000000005045C7D8.00003B42 Message-ID: <5045C7D7.9000909@tana.it> Date: Tue, 04 Sep 2012 11:20:23 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [spfbis] New Issue: Macro difficulties X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Sep 2012 09:20:26 -0000 Section 8.1 *Macro Definitions*: s = l = local-part of o = domain of d = i = p = the validated domain name of (deprecated) v = the string "in-addr" if is ipv4, or "ip6" if is ipv6 h = HELO/EHLO domain It would be handy to add a reference to 20 pages backward: Where , , and are defined in [Section 4.1]. Section 8.1 is three-page long, and locating the definition of a macro is difficult. Sub-sections or hanging lists might help. The "h" macro is missing a detailed description. This macro seems to be unique in that it keeps the same value irrespectively of the identity being checked, whereas the values of "s", "l", and "o" change as the identity changes. (In previous messages I thought "o" behaved like "h", sorry.) Macro "h" is not exemplified in Section 8.2. (A few cases for %{h} and %{H} exist in the test suite, though.) The last two paragraphs in Section 8.1 are notes that actually do classify "s", "l", "o", or "h" as second-class macros, as far as cacheability is concerned. With respect to issue #22, "s", "l", and "h" allow to inject invalid domains that can trigger PermError on otherwise correct SPF records. We should add yet another note to state this point --and warn either the publisher or the developer, depending on how we solve catch #22, e.g. any record that uses "s", "l", or "h" isn't really correct ;-) From johnl@iecc.com Tue Sep 4 03:45:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9742721F85E6 for ; Tue, 4 Sep 2012 03:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWLnHOd3sJFB for ; Tue, 4 Sep 2012 03:45:04 -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 7CD1E21F8574 for ; Tue, 4 Sep 2012 03:45:03 -0700 (PDT) Received: (qmail 83418 invoked from network); 4 Sep 2012 10:45:01 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 4 Sep 2012 10:45:01 -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:vbr-info; s=5045dbac.xn--9vv.k1208; i=johnl@user.iecc.com; bh=CReSbbrlTek35xggDzkzfJVUZaiLmeoCsDdRyJYf8A0=; b=nSiDU0eIrrMy5G5BFPXT6Pqe6c52CL2fLwMubxI+FwlLVrV0slxru0KePKDZKwX4CjP7gX9citvFagIISzSxI4QZFJEttuhfFG6J0TDqdI9cURNJnMWbMiUQj9xI0Br7D9RVUBGX5FV7HMUay0ddxIQBddkggINcjkT8ZASQLfA= 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:vbr-info; s=5045dbac.xn--9vv.k1208; olt=johnl@user.iecc.com; bh=CReSbbrlTek35xggDzkzfJVUZaiLmeoCsDdRyJYf8A0=; b=FDqPJffN+fxsVOOmPKu1nxzIG3i4U7QBJWxyHwjyYc8WQNBtcSnLFYwX1TYCQbJlpnZ2Y3N9J9mkQQWvEA5xAsje4VGcFgqcggCsDCKD439yizaezfJu2FSE1rVKLVRFV4Oy6qFrAFWGdgBwxyXKg2wCtQhf9gA9KOex8lX/qeo= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 4 Sep 2012 10:44:38 -0000 Message-ID: <20120904104438.63980.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1381988.MgFA4MVS4M@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: spf2@kitterman.com Subject: Re: [spfbis] Proposed Section 7 update X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Sep 2012 10:45:05 -0000 >What kludge? A-R has optional fields and room for comments, so I don't see >anything kludgy about suggesting a way to fill them out. Haven't we been through this already? The point of a standard is to let people write software that interoperates. When RFC 5451 says something is a comment, that means that software that implements 5451 doesn't interpret it. Trying to hide stuff in an uninterpreted field is a kludge. Updating 5451 to add more fields to report the stuff that's in Received-SPF is a reasonable idea, but this is neither the place nor the method to do it. Editorial nit: sec 7.2 says SPF-Received where it should say Received-SPF. R's, John From agthisell@yahoo.com Tue Sep 4 07:58:18 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE1421F8468 for ; Tue, 4 Sep 2012 07:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvJX+srLA9bY for ; Tue, 4 Sep 2012 07:58:17 -0700 (PDT) Received: from nm13.bullet.mail.ne1.yahoo.com (nm13.bullet.mail.ne1.yahoo.com [98.138.90.76]) by ietfa.amsl.com (Postfix) with SMTP id 77C3921F844E for ; Tue, 4 Sep 2012 07:58:17 -0700 (PDT) Received: from [98.138.90.49] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 04 Sep 2012 14:58:11 -0000 Received: from [98.138.89.234] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 04 Sep 2012 14:58:11 -0000 Received: from [127.0.0.1] by omp1049.mail.ne1.yahoo.com with NNFMP; 04 Sep 2012 14:58:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 746647.60265.bm@omp1049.mail.ne1.yahoo.com Received: (qmail 10803 invoked by uid 60001); 4 Sep 2012 14:58:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346770691; bh=gaaff4lYeGpI9K6ErhGIYO/N/SfQV92hhg6qiQvg17Q=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=lkmKMiKjguet4PZXosHFzjJPTsVwq58ZetkCDNeT8E2vqiYztw1jQz7DGG+o2tFsHpzQdoNeyZzN/qOzPNmGgqGvZXpfmgGZTV4IMyyxrDFageqJeG/U8yoTv0wWlDPaL/8XWrGfj7ZWH8ctBGMuENd3ctvJYQP2OchUGC95YuA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=wgIRkWqhAsqp7TPMCWFsAd8SRojgoZwmzaGjrqQphkhDUcRva7EUWc6ykRzoiCe/iY+uAK4m+Aw6rnyw9+mT5mJ3+vieaxlqf7NHod115wurZxciCtUHxhtxYr1r2lBzT9zDpMPm44KKqu/+t1LqA9I2BaL+CHLeeBwBKIP8u4w=; X-YMail-OSG: sfzMngQVM1mOJdqZP9DujrvBaM29ajoJRZ4ZjnkpNQklFeM JV4ym0W0nvWR.Db0jekl3EyAqSwn9CgUcJiYW9OM6HH8ATG_BT3Q3tOOFCDj dI7gk9jXUfNkLl2geVXMJpbvF.5BcdapI4502WRdA6TAYB3bPXMa7h2dRprr UnPTD5wTEkvSTS1Y331aB0XTR.4D8ulAs2g_BxiAceolO5x0RC9Z_LUDDKpZ GUCtxr7xSUM37JRZeDFBqlPt3arME7O76QvPk4qyCr.7Hl44Q04g1dKQhpiq 8uijdF8dDbk6z1UANohL579ToYUweYkuBC34cG80mVHgA8bHVrkk58uMWiaO OvN8rks9ZgiN9rUCYCaPGjko4cBpS_yseCB6N334f7BrIlHjssdomSNsrWKy tQHOfx1DgdoB5lPUPBuD5lApwFPxOaBEYNHC.ZbPwDfUp.aMjVo8FRxgSX6y 9eehIcshuD2xVBDDb4gS6A7qXvZxBjOV_IZHhzX9V8j5.hw96CiiSmNbd5Cp 0H3OZGuLGhKl9IR2Vx5qVArkPFVxay_FmmmQgA9C5um3SMO9lEvZ0c6TeWux HCvemwJvm0oc59CntIYcHUWNVD18vzyM_9neqM5zt3ndfmbuouKr1qHBn3c2 LrpbcXJ5lRA4VuVdzzg9s Received: from [71.61.133.134] by web125406.mail.ne1.yahoo.com via HTTP; Tue, 04 Sep 2012 07:58:11 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346770691.72124.YahooMailClassic@web125406.mail.ne1.yahoo.com> Date: Tue, 4 Sep 2012 07:58:11 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion, X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 14:58:18 -0000 > My claim is that if invalid domains MUST result in > PermError, then there is _no good way_ to use %h. That is, such that > authorized senders pass and attackers match -all. It is important to remember that even if the WG charter allowed it, we are not creating a new protocol and arguments based on "this makes more sense to do" get outweighed by "this is what is actually being done". Indeed, it is my opinion that even before MARID really got started, the deployment of SPF was so large that major changes couldn't be done. Some history on this permerror stuff. First, SPF was developed outside of the IETF and largely done based on documents that wouldn't even pass as I-Ds. In order to understand the implementations of SPF in the real world, we need to look past the quality of these documents and accept them as what was used to develop off of. Before MARID, permerror was called "unknown" (and temperror was "error"). This wasn't a bad name for what Meng Weng Wong had envisioned for SPF. He viewed an SPF pass as being the most important thing (see, for example, http://openspf.org/whitepaper.pdf ) In both that document, and his first I-D ( http://tools.ietf.org/html/draft-mengwong-spf-00 ), he envisioned extending SPF via unknown mechanisms. So, something like this is was used an example of a valid SPF record: v=spf1 a mx ptr domainkeys:_dk.%{d} -all When an implementation hit the mechanism "domainkeys" and it didn't know what to do with it, the implementation returned "unknown" and plopped the mechanism into the Received-SPF header for later processing. It didn't matter that the SPF evaluation didn't hit the -all at the end. You could get an SPF pass via the initial mechanisms, and domainkeys would help you get further if you knew what to do with it. In early drafts (pre IETF involvement), there were conflicting sentences about what to do with invalid domain names. Some places said they should trigger "unknown" (e.g. permerror), some places didn't. Some implementations did it one way, others did it the other way. OK back to today, where we are trying to decide what should be done with invalid domain names and whether they should cause a permerror or not. RFC 4408 documented this mess by having one sentence in the permerror definition that said: Be aware that if the domain owner uses macros (Section 8), it is possible that this result is due to the checked identities having an unexpected format. No where does it actually say that an implementation must generate a permerror, just that in the real world, this can happen. So, we can't use logic to argue what RFC 4408bis "should" do, we need to go out and find out what the situation is in the real world. How many implementations trigger permerror when the get an invalid domain and how many just don't match? If almost all do one thing, maybe we can shift the standard a bit to bless that behavior. For that matter, what do implementations actually define as an invalid domain name? Is "localhost" an invalid domain name? What about 1.2.3.4? Do implementations trigger permerror on only a subset of invalid domain names? Note that for SPF records, section 4.3 already takes care of this kind of thing. In 4408bis section 2.1 (the HELO identity), there is a new sentence that duplicates the requirements in section 4.3. So, again, I am no longer able to easily do much work (e.g., it would take me a month or two), so I can't answer the question "what do actual implementations do?" If someone else can do the work, that would be great, if not, then I think the best that this WG can do is add some clarifying text about what we know used to be the situation. From barryleiba.mailing.lists@gmail.com Tue Sep 4 11:04:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD2D21F865D for ; Tue, 4 Sep 2012 11:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.188 X-Spam-Level: X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_84=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwA+6gPDjwwu for ; Tue, 4 Sep 2012 11:04:35 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BBFBE21F851E for ; Tue, 4 Sep 2012 11:04:34 -0700 (PDT) Received: by lahm15 with SMTP id m15so5374272lah.31 for ; Tue, 04 Sep 2012 11:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WhCniwTd1B2htKh5dQ3gb9UkGg1ehn8+bVXAJTfJ4pM=; b=orJFIbAuMl1FMctVirjW69aBKPaPnjaleD9lSbepjqjiVBx+U9YoQMyH6zJ8+85G7x aC3PRn0M7y+Ks7ngr/9BOJiBhr0BP5VIDu5c/fPZIqgC3d+56+bQjzPhHwxkZxBA/SRi /V/1kH29nfHeueMQaSTGqoq9UxGCFXd88AQ+/a2X2Kt9v9oYhsuKl32H7EEzzDyuNgVk JKg0srwP7W2CEKQg8bfmx3fRM71N45xRxCeJdI6bXjU8oe9up7ZQfkjI0Xq0ka47nQIB clOzC/0u3s06a0frgYAXTI1Zhlv71DLFe0uY1WVZsY1SOHVq7b44p9I9tjbrYMGGwer8 0WDA== MIME-Version: 1.0 Received: by 10.152.108.206 with SMTP id hm14mr2382875lab.53.1346781871678; Tue, 04 Sep 2012 11:04:31 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Tue, 4 Sep 2012 11:04:31 -0700 (PDT) In-Reply-To: <50450D03.5080202@isdg.net> References: <50450D03.5080202@isdg.net> Date: Tue, 4 Sep 2012 14:04:31 -0400 X-Google-Sender-Auth: n34B1mo0ErJeBSPeGKlORR75_6E Message-ID: From: Barry Leiba To: Hector Santos Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Possible ABNF nit with Received-SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Sep 2012 18:04:36 -0000 > In 4408 section 7 (7.1 for BIS), there is: > > key = "client-ip" / "envelope-from" / "helo" / > "problem" / "receiver" / "identity" / > mechanism / name > > identity = "mailfrom" ; for the "MAIL FROM" identity > / "helo" ; for the "HELO" identity > / name ; other identities > > Isn't the keys for identity redundant for the regular set of possible keys? > > "mailfrom" same as "envelope-from" for key > "helo" same as "helo" for key > "name same as "name" for key No. The "key" production specifies what goes on the *left* side of the "=" sign, such as envelope-from= and helo=example.com whereas the "identity" production is what goes on the *right* side of the "=" sign when the *key* is "identity": identity=mailfrom or identity=helo I think it would be a good idea to change the name of the "identity" production to "identity-val", or some such, to avoid that confusion. But I think there *is* a bug in the ABNF for "key": shouldn't "mechanism" be in quotes? I think what's meant is to have something like this: mechanism=MX Right? That needs "mechanism" to be in quotes in the "key" production. Barry From agthisell@yahoo.com Tue Sep 4 11:38:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E2721F8694 for ; Tue, 4 Sep 2012 11:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in5FPJMp2AzC for ; Tue, 4 Sep 2012 11:38:36 -0700 (PDT) Received: from nm25-vm1.bullet.mail.ne1.yahoo.com (nm25-vm1.bullet.mail.ne1.yahoo.com [98.138.91.42]) by ietfa.amsl.com (Postfix) with SMTP id 1EFA321F8697 for ; Tue, 4 Sep 2012 11:38:36 -0700 (PDT) Received: from [98.138.90.48] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 04 Sep 2012 18:38:23 -0000 Received: from [98.138.89.251] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 04 Sep 2012 18:38:23 -0000 Received: from [127.0.0.1] by omp1043.mail.ne1.yahoo.com with NNFMP; 04 Sep 2012 18:38:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 651236.8971.bm@omp1043.mail.ne1.yahoo.com Received: (qmail 44798 invoked by uid 60001); 4 Sep 2012 18:38:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346783903; bh=nAGJ8H5f/khXXkUZgEPEE28ySRPzz0Mr0aoBHb/AjEE=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=tC7NXV8V25m6rbtR5UpwykcOdT316J9qjUm2hhnTUgKU6d/nwJ/pm1jt/muxQ4WmKn/k/sfo0CDVdc1MiAhsx8NOdmE+2cDbK/haSHnRVYu/jSznj3HpcgcJEwNff3Fkp1GiyzC2zGwFQUGqcELPcVlslPXtnla2+Er9X0rgyXg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=kKfJnhbbNoUHAL8S9IQP1ojFtUA+PkEMtlrZTz0rI0tS9pTSRhZ4G0PAW9lvzyMwbMDD0erULVeh1XQBwq9bDP1B9FHBOck/3zh4ox5Fjgtp90I/aMW7uxZyH+JsRX6swRV0qnLt3rpSs6kylXVoj89iVQs4/WbNLBl+dZ0wxfo=; X-YMail-OSG: MR1nM30VM1maOYXKSZ2EEJutVozQkJ2gMgKKI9XqJ_cv5Tb ZhUVYadMKz_.fgx.6UYaB..xKvDdRVZEpKNy_E6AUZ.oheoxDn9KYQyDyVcQ Ti0Cy1GASXyiqdvxIXi4ojFTlC5EIYSIGLp4twZRlL2iDZxYpE9pHwswc9pe 8ZLwk_VlAhklDqsVJHwg76Jlp2xhXgIhha.z7LgP_jnD7mYToxpdptZsFQNz SiEBE1sM6QlI4soeWWGPPzJEMqYUpOOZ8gXcf4td4xDLHZH4el81Of5VcVTw vUiJf.8oFT_Go_bx4.08Rz2ic1OQ5_R38qiMHhSUF0LWz9oI2bijuhZT5l7E Bh0oRCPhNCnoyd96DlqiVHpCssrbL5cmCKkY9bMlDv5Sp53msYGfOb4VjNya TABqTaY_Cd2AvEjza4XWuWuX3IQSPIsVSHxOG.gJhNRTqSLr_fNA7iPs1Wo_ L3LyvsWRgPRoWxK3nCESQV_JjDVmUexu4QCFJ89Mhzz12EeimcZBl0brNuRj pQI4rxANRiyWZ8FC_hRA- Received: from [71.61.133.134] by web125405.mail.ne1.yahoo.com via HTTP; Tue, 04 Sep 2012 11:38:23 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346783903.38995.YahooMailClassic@web125405.mail.ne1.yahoo.com> Date: Tue, 4 Sep 2012 11:38:23 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] Possible ABNF nit with Received-SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Sep 2012 18:38:37 -0000 > No. The "key" production specifies what goes on the *left* side of > the "=" sign, Agreed, that matches what I posted yesterday... > I think it would be a good idea to change the name of the "identity" > production to "identity-val", or some such, to avoid that confusion. +1 > But I think there *is* a bug in the ABNF for "key": shouldn't > "mechanism" be in quotes? I think what's meant is to have something > like this: > > mechanism=MX > > Right? That needs "mechanism" to be in quotes in the "key" production. No. As I explained in my post earlier today, that was intended to support unknown mechanisms. So, if you had an SPF record from draft-mengwong-spf-00: v=spf1 a mx ptr domainkeys:_dk.%{d} -all The Received-SPF header would look like: Received-SPF: unknown domainkeys=_dk.example.com Actually, my memory is hazy, I don't remember the exact format. I seen to recall the Received-SPF header field as being one of the least well thought out/standardized parts of SPF. From superuser@gmail.com Tue Sep 4 11:46:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEF721F869D for ; Tue, 4 Sep 2012 11:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tjd6HIC7FPkx for ; Tue, 4 Sep 2012 11:46:42 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFD021F854F for ; Tue, 4 Sep 2012 11:46:42 -0700 (PDT) Received: by lahm15 with SMTP id m15so5404869lah.31 for ; Tue, 04 Sep 2012 11:46:41 -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=JrOYG12jq3JIbNpaI/ljjtgNbVXA2Fdf1/960c+ICIs=; b=Ie8U8cxivLVq5Ak/QJp+9aCQ81NkzmkOpaMMoPofP10AQiZjKxbda5PQnR2AI1QKHO 8CojQT3K+G9tzeh3LA3L/3T7kPP6XxlZWKt6Glevry4t9PlFNTkTc4gfsg9aSPtvEGFo +tws8Y9pNAG7T1bBkgODATyOIEkToiP2xk6QcGrRbe3FnNEMEx2vtOXeFaQ8phvi3YBr rpFVsPse+i/TPlCd7LTmZVLbcycxT3vUdhlr4/bmsM8ticca/jBzsVsaQ02PBkaOWdqZ 2bJikPsPpt+I4WA+3sqyXf8YNrY7GwF38Jv0RA5t0ITgUBlzkivRuhq1WKTsd0Lvucgs x0Qg== MIME-Version: 1.0 Received: by 10.152.148.199 with SMTP id tu7mr17527862lab.37.1346784401267; Tue, 04 Sep 2012 11:46:41 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Tue, 4 Sep 2012 11:46:41 -0700 (PDT) In-Reply-To: <3097973.E0hN90lcdm@scott-latitude-e6320> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <6.2.5.6.2.20120901110019.093bcda0@resistor.net> <50434E48.8060200@tana.it> <3097973.E0hN90lcdm@scott-latitude-e6320> Date: Tue, 4 Sep 2012 11:46:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] SPF split and rechartering, facet of Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Sep 2012 18:46:43 -0000 On Sun, Sep 2, 2012 at 10:46 PM, Scott Kitterman wrote: > I am against individuals submitting I-D's that duplicate work that the WG is > chartered to do. We can't remove section 9 and be compliant with the charter, > so we need to make a decision about this and get rechartered, if needed, > before doing anything. I don't agree with this interpretation (as I said separately), but I've been wrong before. -MSK From superuser@gmail.com Tue Sep 4 11:52:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEF921F8468 for ; Tue, 4 Sep 2012 11:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu+8NHvaLKir for ; Tue, 4 Sep 2012 11:52:31 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 787BA21F8445 for ; Tue, 4 Sep 2012 11:52:30 -0700 (PDT) Received: by lahm15 with SMTP id m15so5409202lah.31 for ; Tue, 04 Sep 2012 11:52:29 -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=255AiYVx0WOLC4P3k+Sg3iEEviNDvIFkMpv694f6//Q=; b=HTmPKR75SxY2KWYSeZ2Z2NgnVaWKRqNPLEGchyfMuwgWcThsR9OL8wS/UFBWnW4Pot Z38byePsAbMrBSKQzeq1zq5nJAavQCG2NbE8MiwaTUc3x8n19a5uYqkV1+U1PR4M8/P0 ce3tJYBWekgztJvk7wurVVfITi2byncNtw9BadBYZXxSs3a9PH7ZkIhahDpy5iN8iEaX Tx4WF9y24Q1bcPQ6eqveic4TOeQsrrdobYW5MW+F2XvHKmFMceoiooz0uw+/5Mb8LlyD N2AEQQoD57aoDlY2FvP7sCDge4PhwmK3PR27nR7iv4WhvGGCww1oK/GYu7kT0S4/KopJ WItA== MIME-Version: 1.0 Received: by 10.112.9.133 with SMTP id z5mr6941011lba.69.1346784748946; Tue, 04 Sep 2012 11:52:28 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Tue, 4 Sep 2012 11:52:28 -0700 (PDT) In-Reply-To: <50449DA1.6070206@isdg.net> References: <2385202.ToyOPapQOP@scott-latitude-e6320> <504234EC.8000505@tana.it> <50447333.60102@tana.it> <50449DA1.6070206@isdg.net> Date: Tue, 4 Sep 2012 11:52:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, "spf2@kitterman.com >> Scott Kitterman" , Alessandro Vesely Subject: Re: [spfbis] Suggestion: Remove A-R from 4408BIS X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 18:52:31 -0000 On Mon, Sep 3, 2012 at 5:08 AM, Hector Santos wrote: > It seems there is too drama regarding A-R and trying to add it. It > drastically alter scope of SPF with ACCEPT+MARK mode of receiver behavior, > it created new security issues and conflicts of major opinion almost surely > to raise WGLC issues. Since Received-SPF does effectively the same thing, adding references to A-R is neither an alteration in scope nor "drastic". On the contrary, it would be prudent for the IESG to ask why we're ignoring a message annotation that's already a proposed standard specifically geared toward this kind of work. Failing to at least acknowledge the existence of A-R would be suspect if I were the one evaluating it. > SUGGESTION: Remove A-R from 4408BIS and all related changes due to it and > if we someone believes it is still useful for SPF, then write a I-D for it, > perhaps with a title > > Reporting SPF with Authentication-Results > > and this I-D can go into extensive concepts of not only how to write it, but > perhaps also how to combine it with other A-R marking for receiver > evaluations, etc. RFC5451 already did all of that. -1 to this suggestion. -MSK From hsantos@isdg.net Tue Sep 4 12:23:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4D521F853F for ; Tue, 4 Sep 2012 12:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.535 X-Spam-Level: X-Spam-Status: No, score=-100.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_84=0.6, J_CHICKENPOX_92=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHHm71U1Np1M for ; Tue, 4 Sep 2012 12:23:00 -0700 (PDT) Received: from pop3.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E0BC221F852E for ; Tue, 4 Sep 2012 12:22:59 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3465; t=1346786572; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=vkzIJGtGh2pos9uVq8o9/YCYER8=; b=fG0lQoagF6AYyBMLFN1K alUKN/tk3MNPzOTrVua0qsRHWH/wbb56fBFs31mvTYVXonDnABjqGLhqE7jYmUP9 szwid4puT/P53J3VMprw6VoR9cDUGoa8uAxuEliW2HdgflNYARjUjRqUDmfyMvd2 CuqUQO3XdOYB/uwDyKFA99w= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 04 Sep 2012 15:22:52 -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 2808356871.3645.2824; Tue, 04 Sep 2012 15:22:51 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3465; t=1346786361; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=CJJ1zBS 5ERQiiR89W+hZYl5NuApUkzlPOql+4gDKfj8=; b=wXDchsxNHR5P3dnUb4VTZFP IFQXLAHqyOQq0WcycvzIErh0PEOvXZ7s3NrHxrw7itkFxnpOHzgYaSgqQFu5KYKG PSHG13eflONdVJhIVvAlzuDg5y07Tkhc9GUcLQxxk9CXTcMZsUuP3KDeYNM4BhFk 8ftQssLJjLe9mCpKbk70= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 04 Sep 2012 15:19:21 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3407159114.9.3456; Tue, 04 Sep 2012 15:19:20 -0400 Message-ID: <504654EA.2000502@isdg.net> Date: Tue, 04 Sep 2012 15:22:18 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <50450D03.5080202@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Possible ABNF nit with Received-SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Sep 2012 19:23:01 -0000 Barry Leiba wrote: >> In 4408 section 7 (7.1 for BIS), there is: >> >> key = "client-ip" / "envelope-from" / "helo" / >> "problem" / "receiver" / "identity" / >> mechanism / name >> >> identity = "mailfrom" ; for the "MAIL FROM" identity >> / "helo" ; for the "HELO" identity >> / name ; other identities >> >> Isn't the keys for identity redundant for the regular set of possible keys? >> >> "mailfrom" same as "envelope-from" for key >> "helo" same as "helo" for key >> "name same as "name" for key > > No. The "key" production specifies what goes on the *left* side of > the "=" sign, such as > > envelope-from= > > and > > helo=example.com > > whereas the "identity" production is what goes on the *right* side of > the "=" sign when the *key* is "identity": > > identity=mailfrom > > or > > identity=helo > > > I think it would be a good idea to change the name of the "identity" > production to "identity-val", or some such, to avoid that confusion. +1 or perhaps this suggestion based on the intent of this identity= key field as currently described: identity the identity that was checked; see the ABNF rule which I presume is to provide a tracing data point of what identity caused the Received-SPF: result value. A possible better reading may be to use "result-identity": key = "client-ip" / "envelope-from" / "helo" / "problem" / "receiver" / "result-identity" / mechanism / name result-identity = identity identity = "mailfrom" ; for the "MAIL FROM" identity / "helo" ; for the "HELO" identity / name ; other identities Part of the confusion I had besides not catching key value "identity" was double quoted, was related to the section 7.1 example and also reading section 7.2: Received-SPF: fail (mybox.example.org: domain of myname@example.com does not designate 192.0.2.1 as permitted sender) identity=mailfrom; client-ip=192.0.2.1; envelope-from="myname@example.com"; I was getting the impression that in general these keys are inputs: envelope-from= helo= client-ip= and identity= key would indicate which identity failed among envelope-from or helo. So with the example not having helo=, it implies envelope-from was the only identity checked. Having identity=mailfrom is redundant, this is somewhat confirmed with section 7.2 where it says: The reason SHOULD include a key-value-list with keys provinding [TYPO] information normally included in a Received-SPF header field that is not already part of the Authentication-Results header field. That is, at least "client-ip", "helo", and, if the "MAIL FROM" identity was checked, "envelope-from". So it seems to say that using identity= may be redundant depending on what Inputs are provided. Does it make sense to trace this with without helo= key added? Received-SPF: fail (mybox.example.org: domain of myname@example.com does not designate 192.0.2.1 as permitted sender) identity=helo; client-ip=192.0.2.1; envelope-from="myname@example.com"; Also, how does one write the trace when both identities are checked? > But I think there *is* a bug in the ABNF for "key": shouldn't > "mechanism" be in quotes? I think what's meant is to have something > like this: > > mechanism=MX > > Right? That needs "mechanism" to be in quotes in the "key" production. I think so. So there was a possibility of typos! -- HLS From spf2@kitterman.com Tue Sep 4 15:35:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A95D21E8092 for ; Tue, 4 Sep 2012 15:35:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 818bZzMH2Vxm for ; Tue, 4 Sep 2012 15:35:22 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 851A621E805A for ; Tue, 4 Sep 2012 15:35:22 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6C70A20E40E3; Tue, 4 Sep 2012 18:35:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346798121; bh=+nnmOW+mDFiHzTcQnsLC6G4fnLCEMK87H1tFRYiPueE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=a+CmENCmb1X7/9x2ywtSqZtgOmKCfNH9Kzm2WMf22DUhwwUegOI1IWU49DnFLWiDQ i/w5kk6gniLJ3MvmP2jfXO5ysXZ6u/EyysUgfTTIuhOMerMnOyBnLSEZROYXKM91dz NwV5LI+crstRbt4ERKEmRjWtiX5JHkPjXb0BL2xI= Received: from scott-latitude-e6320.localnet (218.sub-70-192-197.myvzw.com [70.192.197.218]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 36C7620E40BD; Tue, 4 Sep 2012 18:35:20 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 04 Sep 2012 18:35:19 -0400 Message-ID: <3702218.la6RzIWcEe@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <5045C7D7.9000909@tana.it> References: <5045C7D7.9000909@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] New Issue: Macro difficulties X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 04 Sep 2012 22:35:23 -0000 On Tuesday, September 04, 2012 11:20:23 AM Alessandro Vesely wrote: > Section 8.1 *Macro Definitions*: > > s = > l = local-part of > o = domain of > d = > i = > p = the validated domain name of (deprecated) > v = the string "in-addr" if is ipv4, or "ip6" if is ipv6 > h = HELO/EHLO domain > > It would be handy to add a reference to 20 pages backward: > > Where , , and are defined in [Section 4.1]. > > Section 8.1 is three-page long, and locating the definition of a macro > is difficult. Sub-sections or hanging lists might help. > > The "h" macro is missing a detailed description. This macro seems to > be unique in that it keeps the same value irrespectively of the > identity being checked, whereas the values of "s", "l", and "o" change > as the identity changes. (In previous messages I thought "o" behaved > like "h", sorry.) > > Macro "h" is not exemplified in Section 8.2. (A few cases for %{h} > and %{H} exist in the test suite, though.) > > The last two paragraphs in Section 8.1 are notes that actually do > classify "s", "l", "o", or "h" as second-class macros, as far as > cacheability is concerned. > > With respect to issue #22, "s", "l", and "h" allow to inject invalid > domains that can trigger PermError on otherwise correct SPF records. > We should add yet another note to state this point --and warn either > the publisher or the developer, depending on how we solve catch #22, > e.g. any record that uses "s", "l", or "h" isn't really correct ;-) I think this concern would be easiest to deal with if you provided a diff for the intended text. Scott K From barryleiba.mailing.lists@gmail.com Tue Sep 4 19:52:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8B021F84B8 for ; Tue, 4 Sep 2012 19:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzDhfWPaUwd0 for ; Tue, 4 Sep 2012 19:52:21 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D8F7B21F849C for ; Tue, 4 Sep 2012 19:52:20 -0700 (PDT) Received: by lahm15 with SMTP id m15so14371lah.31 for ; Tue, 04 Sep 2012 19:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ellmZ1/Hx8U72SEo/zAwjnBhxaLPj4PN32kn867ZvLo=; b=ohSFyozEnKp+ZiThjk/sUXJIXim9iAykdgAesB7eFP+fwD/Dn+VeTBjPehae0/cV3Q 8WFletETuiUxnJe8VclDA4o/aTnAVWXGkxJ5Y0LKsJ00xGJx++Yrqi1lFSPfdUW5Bdpd Yg6qY2Hpw/0S5uFO6RGOgJn2u9SQyW/XkzWGjaZOO9CBfxqWXfdzd3RUT6CTmVIrQIq/ e8WFa1iHUwU8CH4DbbiPOsp60uhIzpiVpWT6dubGwYVTg/tWVSJ0TYfECnwhbYcBLC/o Dv48R8YjriaOAU4NiNxkL0YZ6vgtsyQgPIvgR/Wt2SG+KIh4cqNJZIa7yU9cqtxqw3LG PLEQ== MIME-Version: 1.0 Received: by 10.112.31.197 with SMTP id c5mr7179096lbi.50.1346813539817; Tue, 04 Sep 2012 19:52:19 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Tue, 4 Sep 2012 19:52:19 -0700 (PDT) In-Reply-To: <1346783903.38995.YahooMailClassic@web125405.mail.ne1.yahoo.com> References: <1346783903.38995.YahooMailClassic@web125405.mail.ne1.yahoo.com> Date: Tue, 4 Sep 2012 22:52:19 -0400 X-Google-Sender-Auth: rViAgHebhDxhVcABcBB82sz7lR8 Message-ID: From: Barry Leiba To: Arthur Thisell Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Possible ABNF nit with Received-SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Sep 2012 02:52:21 -0000 > Agreed, that matches what I posted yesterday... ... >> But I think there *is* a bug in the ABNF for "key": shouldn't >> "mechanism" be in quotes? I think what's meant is to have something >> like this: >> >> mechanism=MX >> >> Right? That needs "mechanism" to be in quotes in the "key" production. > > No. As I explained in my post earlier today, I don't appear to be seeing these mystery posts. I only see one message from you in this discussion thread -- the one I'm responding to. Hm. > that was intended to support unknown mechanisms. So, if you had an SPF > record from draft-mengwong-spf-00: > > v=spf1 a mx ptr domainkeys:_dk.%{d} -all > > The Received-SPF header would look like: > > Received-SPF: unknown domainkeys=_dk.example.com If that's the case, the text needs work to make it clear, because it's decidedly not. The text below the grammar lists key names and the meanings of the values. "mechanism" is listed as a key name in that text. So there's a problem somewhere that needs to be cleared up. Barry From sm@resistor.net Tue Sep 4 22:06:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C0A11E80DE for ; Tue, 4 Sep 2012 22:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpHxNp4VKU0G for ; Tue, 4 Sep 2012 22:06: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 CC6A221F85AC for ; Tue, 4 Sep 2012 22:06:24 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8556F96028406 for ; Tue, 4 Sep 2012 22:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346821579; bh=qwIAzijrxzq1BdbjUgtZWGOUnLQeOsPmjrOVk5xhe2w=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=WlJfVPqWNEHNm8me1y0AYhgwCcQVEHH7vS7H9FCwHxJy3G6nHWTXduMRl7ene9JrC uXL/wuRakeHoYseB6NW3WBEZ2/cw+/NPJ8q0JGLtlJ/b4pzT0tdtgtiKVXbPLKh+XD 3scZyIQoT6HbSXy8Hjbse8+IxvRuRHWIF4Z1BNHI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1346821579; i=@resistor.net; bh=qwIAzijrxzq1BdbjUgtZWGOUnLQeOsPmjrOVk5xhe2w=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=uYYBVhqs8OtYr7xJ0g7H3R0zcqO+rl5KtOpgHJGMPV3ZEDUksjK6Ou1G3vS1r1l2K KT82ye9KUHlW7dkwCWPAtj1HaD0exC9GuI8wksymA0Qb6AnLtmyrLpUVsvbFYFZHMd cfjS0sqGRKWu+Ox33kLFNWaZqoFXPYDg+uN4fzWw= Message-Id: <6.2.5.6.2.20120904220320.09c05740@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 04 Sep 2012 22:05:48 -0700 To: spfbis@ietf.org From: SM In-Reply-To: <1346783903.38995.YahooMailClassic@web125405.mail.ne1.yahoo .com> References: <1346783903.38995.YahooMailClassic@web125405.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Possible ABNF nit with Received-SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Sep 2012 05:06:35 -0000 At 11:38 04-09-2012, Arthur Thisell wrote: >No. As I explained in my post earlier today, that was intended to >support unknown mechanisms. So, if you had an SPF record from >draft-mengwong-spf-00: There was a message on another thread at http://www.ietf.org/mail-archive/web/spfbis/current/msg02601.html and one of this thread at http://www.ietf.org/mail-archive/web/spfbis/current/msg02603.html I gather that the unknown mechanism discussion was from the first message. Regards, -sm From vesely@tana.it Wed Sep 5 02:18:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6670421F8622 for ; Wed, 5 Sep 2012 02:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.533 X-Spam-Level: X-Spam-Status: No, score=-4.533 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdWVJ3+-BXJc for ; Wed, 5 Sep 2012 02:18:25 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A820921F8621 for ; Wed, 5 Sep 2012 02:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346836704; bh=xZgGnQTrbIrCnFKiNKZekHKiAZhQLwY6+yhweIBbd4o=; l=478; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ewUWZgiTbQmIcp62XKjjc4I5yTgSWuGsSvZVFZslUhqEVqot1Y8j2Row21SQWTT/D 0I7fn4xInqKQamkEsIs7URvirMzdgaGRn8eRvnQUtOzc+S0Ns0nBf7y0ofq8sFIbZU ygdzrBIKmuFL3+LzJ0rHVk+APFCgOMgD/X0XmBJs= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 05 Sep 2012 11:18:24 +0200 id 00000000005DC035.00000000504718E0.000004E4 Message-ID: <504718E0.8000102@tana.it> Date: Wed, 05 Sep 2012 11:18:24 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <50450D03.5080202@isdg.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Possible ABNF nit with Received-SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Sep 2012 09:18:26 -0000 On Tue 04/Sep/2012 20:04:31 +0200 Barry Leiba wrote: > > I think it would be a good idea to change the name of the "identity" > production to "identity-val", or some such, to avoid that confusion. IMHO, the gain in clarification that we could possibly achieve by such change is certainly less than the added confusion that any changes in production rules inevitably produce. I'd limit them to necessary error corrections, if at all possible. -1 to this suggestion. From vesely@tana.it Wed Sep 5 03:53:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5158F21F8627 for ; Wed, 5 Sep 2012 03:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.57 X-Spam-Level: X-Spam-Status: No, score=-4.57 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0FhlYUsTKcC for ; Wed, 5 Sep 2012 03:53:30 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 64F8621F85F0 for ; Wed, 5 Sep 2012 03:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1346842407; bh=gvHph22lo8fqCEDv1ib2czcMjscRl6daN4dzmJ9sNoY=; l=1971; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=kEnQabEugGeC9QS8QOPsj01ncy/LiQzXI7qnvTmIqTaHOi0N+FME97omug0WF73wW RZFFjMKy8dnEE3khS7eQSiNQhN+iZ45FNyiWa14nQvmC7lKS/FKal1gqJjjArATgQw AlJ05N4bPPRoWS8GibTQr+iXvpCwQHacV5uWl6tw= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 05 Sep 2012 12:53:27 +0200 id 00000000005DC03F.0000000050472F27.00001CE9 Message-ID: <50472F27.4080907@tana.it> Date: Wed, 05 Sep 2012 12:53:27 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1346770691.72124.YahooMailClassic@web125406.mail.ne1.yahoo.com> In-Reply-To: <1346770691.72124.YahooMailClassic@web125406.mail.ne1.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion, X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 10:53:31 -0000 On Tue 04/Sep/2012 16:58:11 +0200 Arthur Thisell wrote: > > RFC 4408 documented this mess by having one sentence in the > permerror definition that said: > > Be aware that if the domain owner uses macros > (Section 8), it is possible that this result is due to the checked > identities having an unexpected format. > > No where does it actually say that an implementation must generate > a permerror, just that in the real world, this can happen. > > So, we can't use logic to argue what RFC 4408bis "should" do, we > need to go out and find out what the situation is in the real > world. How many implementations trigger permerror when the get an > invalid domain and how many just don't match? It is very impractical to test implementations running on a remote host, because they won't necessarily let the client know the evaluation result. It is possible to examine source code, or test locally. But then let me recall that there is a test suite provided by OpenSPF.org that has various cases already prepared. The relevant test cases are invalid-domain-empty-label, invalid-domain-long, and invalid-domain-long-via-macro, for which the testsuite indicates permerror or fail as valid results. Unfortunately, running the testsuite only reports whether the test was successful, possibly along with the amount of time it took to complete it. I tested Courier-MTA, and it returns a non-compliant "unknown" result for those three cases. I'll ask on spf-discuss, it will hopefully take less than a month or two... > If almost all do one thing, maybe we can shift the standard a bit > to bless that behavior. One thing that changed since RFC 4408 is the possibility to get a report whenever SPF evaluation results in *error. The usefulness of that is that it will report real errors, such as DNS servers hiccups or an occasional syntax error slipping in. Blessing permerror would taint such streams with spurious attack reports. From agthisell@yahoo.com Wed Sep 5 04:00:41 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F2021F861E for ; Wed, 5 Sep 2012 04:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1extBoXPpZ1 for ; Wed, 5 Sep 2012 04:00:40 -0700 (PDT) Received: from nm22-vm3.bullet.mail.ne1.yahoo.com (nm22-vm3.bullet.mail.ne1.yahoo.com [98.138.91.152]) by ietfa.amsl.com (Postfix) with SMTP id 4BB2B21F84F3 for ; Wed, 5 Sep 2012 04:00:40 -0700 (PDT) Received: from [98.138.90.53] by nm22.bullet.mail.ne1.yahoo.com with NNFMP; 05 Sep 2012 11:00:29 -0000 Received: from [98.138.89.244] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 05 Sep 2012 11:00:29 -0000 Received: from [127.0.0.1] by omp1058.mail.ne1.yahoo.com with NNFMP; 05 Sep 2012 11:00:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 724676.23405.bm@omp1058.mail.ne1.yahoo.com Received: (qmail 1519 invoked by uid 60001); 5 Sep 2012 11:00:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346842829; bh=GF9HzaZ0t63+Bw0IYGb22V61+/D3xDNlFV9K+CMdMho=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=FHarrWSzwXIp9d+r56K2HQ7V71slRpE8224uaCvYof7HrDLv7lHQVx+3S9klKSMZ4tOYHK2p+/XVtmKgkjeiE3uUPRvuCCtC3DI7XsM7C2kWCYUz79KjZ9uzhhj5Y+o8FM4GHC/Ay7Aiuw7PcTxkGkmXhRGxIeEU+YzAPqZHMO0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=gvEzB9nNB2JfaTtMtufyXgnD7Tf+OvU/lMkUBNqW+ZEo72EdoNQ8nA0Hg8SqD7leNXA4qdV7O6lIRADh415Y0FHdpAO76NGoO2L0bOSFhHP1jwlMNhFZSMMzS4njZ81I/nL7nlI7GFfM2NsMQGDmxJlIpp5900bc4PNClQmW2NU=; X-YMail-OSG: 9BOwjwIVM1kb.D69QhS_vUobmxeR6aleGxP6BdYhQLKR6Bu fmPHgSkwe.0jd152YBMkCk7OHQe.4m8rApFcl6x8go5VIKbMTP1RsOr3bmXM pIMWr2fWAZvigIcD4SBFCRxzVcJHiROq3.SPov8g0LYN2UwWuzvLZk1QBwVy k_vKL0tnnh3DlsyASM4RbqjTp4xEA56E6yGRaYZFjgp8FVMJBAE9s8F9FeeX oCcnmA7F3bGNTe1dl9YuYv8hrCfkNNAc.XEMTOu3HZre3pkpkdKYCf7WNfMo VI96A9MSHSk1Fc5NoNk36Uib.3hS0olD0K8fjS61eJx.O7BAlRB1HjoEQvJG n9Y6vmSCpv3Pm2dEHAv7shHbNo9CZhMOQZuSp_cir90FZ6PG11b5RNaj3G_4 SiLuqz0QCNJD9xEVy.S5Oxvlp.wf4grvdpZVXL53kZysh9AV0BHqeGAUv8Vw 5s.ZGahRnf51IA8Pmo5qPQQxLtL_Zq7u02.3YNjYpYAyIxlVgA0IPPn8IIPJ 05mR94w-- Received: from [71.61.133.134] by web125403.mail.ne1.yahoo.com via HTTP; Wed, 05 Sep 2012 04:00:29 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346842829.84355.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Wed, 5 Sep 2012 04:00:29 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] Received-SPF in the real world X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Sep 2012 11:00:41 -0000 Has anyone collected information on how Received-SPF is actually being used? Things like the mechanism production rule was most important back when SPF used to support unknown mechanisms. I'm not sure I've ever seen it used in practice. Could it just be removed as being unused? Yahoo creates a Received-SPF header field that doesn't follow RFC 4408 at all and I can't make sense of it. E.g.: Received-SPF: pass (domain of ietf.org designates 64.170.98.30 as permitted sender) dCBhbGwgdGhlIGluZGl2aWR1YWwgbWVzc2FnZSBhdHRhY2htZW50cyB5b3Ug d2lsbCBuZWVkIHRvIHVwZGF0ZSB5b3VyIGRpZ2VzdCBvcHRpb25zIGluIHlv dXIgbGlzdCBzdWJzY3JpcHRpb24uIFRvIGRvIHNvLCBnbyB0byBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwZmJpcyBDbGljayB0 aGUgJ1Vuc3Vic2NyaWJlIG9yIGVkaXQgb3B0aW9ucycgYnV0dAEwAQEBAQN0 ZXh0L3BsYWluAwMxAgN0ZXh0L3BsYWluAwMxAgNtdWx0aXBhcnQvZGlnZXN0 AwM3AgNtZXNzYWdlL3JmYzgyMgMDMwIDbWVzc2FnZS9yZmM4MjIDAzQCA3Rl eHQvcGxhaW4DAzE- I'm not even sure how you could collect a good cross section of Received-SPF examples. Looking at individual implementations might be a good start, From superuser@gmail.com Wed Sep 5 06:51:13 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA5721F8604 for ; Wed, 5 Sep 2012 06:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.105 X-Spam-Level: X-Spam-Status: No, score=-3.105 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mX-z7gWMvWK for ; Wed, 5 Sep 2012 06:51:12 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4C20921F85EF for ; Wed, 5 Sep 2012 06:51:11 -0700 (PDT) Received: by lahm15 with SMTP id m15so412303lah.31 for ; Wed, 05 Sep 2012 06:51:10 -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=2dHOk3A9Ij4SNDPsihZhZEZG8tFp4k5RI6FDX+nuQrk=; b=GwjL7CotVBHjf7E6qDSMPR4PeOIEEbXakrUs77VZordZo98F7+jucFwRSd+c+70TKf tytICvBsKPatSNKfEEjTvUTKYfj7e3LxppJW/tQNlLiJY/gTFkBI7Z+ED7CY7UdUxqC9 71b8EEcD+82kTGUCOAJhXBWfku+9gwsQbLe73prADCNOmeL/QHnTzHx/nrGdjFPTEijv LMv3HrFq/x1jnM4Ye7YRvt3wCfscInm7r6doIHeYXpP6qa4Gv8rSjFGQ5lGREJ7siWgp /JohWEVo/225tGYz7S5az/ZW7JNn+i7n8h4vORgvI+k0RmDvb1ymLLThGpV5TyOre1vA cKhA== MIME-Version: 1.0 Received: by 10.112.9.133 with SMTP id z5mr7841458lba.69.1346853070222; Wed, 05 Sep 2012 06:51:10 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Wed, 5 Sep 2012 06:51:10 -0700 (PDT) In-Reply-To: <1346842829.84355.YahooMailClassic@web125403.mail.ne1.yahoo.com> References: <1346842829.84355.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Wed, 5 Sep 2012 06:51:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: Arthur Thisell Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Received-SPF in the real world X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Sep 2012 13:51:13 -0000 On Wed, Sep 5, 2012 at 4:00 AM, Arthur Thisell wrote: > Has anyone collected information on how Received-SPF is actually being used? I have the same question. Does any production software actually consume the things Received-SPF supports that Authentication-Results does not? -MSK From spf2@kitterman.com Wed Sep 5 07:04:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDCB21F8599 for ; Wed, 5 Sep 2012 07:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMbU-xyKLXVB for ; Wed, 5 Sep 2012 07:04:15 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5784E21F8596 for ; Wed, 5 Sep 2012 07:04:15 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5219D20E40E8; Wed, 5 Sep 2012 10:04:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346853854; bh=BrP7QOjtoYvgmyyEHuUAdABvUTFI4Ipq+b4W6oubXMo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=X1npKq1W3iz1HEJhxT2J6CkaJi04AU2GXbtuVcmYzyEdAKpXcUwDjEOK6mNtO4h6F fmWgQrIRv1IWKuzC0IoB4qFzZs5cBJmL3C5ou4h9wcxqpyymez5PgQNkHd6fqro3MS HhOEJMqfv98SqBBOqkmQHWTIOx3mGb3BlfSchHdg= 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 25CFB20E409A; Wed, 5 Sep 2012 10:04:13 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 05 Sep 2012 10:04:13 -0400 Message-ID: <11613033.KFrpIoC23t@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <1346842829.84355.YahooMailClassic@web125403.mail.ne1.yahoo.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] Received-SPF in the real world X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Sep 2012 14:04:16 -0000 On Wednesday, September 05, 2012 06:51:10 AM Murray S. Kucherawy wrote: > On Wed, Sep 5, 2012 at 4:00 AM, Arthur Thisell wrote: > > Has anyone collected information on how Received-SPF is actually being > > used? > I have the same question. Does any production software actually > consume the things Received-SPF supports that Authentication-Results > does not? I don't think that's a question that can be answered. I do believe that while A-R support for spamassassin is in it's development trunk, it has not been released yet spamassassin will either consume Received-SPF from trusted relays or do it's own SPF check based on information from the Received header field. Scott K From SRS0=ZbkZS=HE==stuart@gathman.org Wed Sep 5 11:21:41 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A11821F863F for ; Wed, 5 Sep 2012 11:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_39=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NF8fYpw5zPsK for ; Wed, 5 Sep 2012 11:21:40 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 28BFD21F8543 for ; Wed, 5 Sep 2012 11:21:39 -0700 (PDT) Authentication-Results: mail.bmsi.com; auth=pass (PLAIN sslbits=256) smtp.auth=stuart Received: from sdg.bmsi.com (sdg.bmsi.com [192.168.9.34] (may be forged)) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q85ILTeX030505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Sep 2012 14:21:37 -0400 Message-ID: <50479829.5050707@gathman.org> Date: Wed, 05 Sep 2012 14:21:29 -0400 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1346842829.84355.YahooMailClassic@web125403.mail.ne1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Received-SPF in the real world X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Sep 2012 18:24:43 -0000 On 09/05/2012 09:51 AM, Murray S. Kucherawy expounded in part: > On Wed, Sep 5, 2012 at 4:00 AM, Arthur Thisell wrote: >> Has anyone collected information on how Received-SPF is actually being used? > I have the same question. Does any production software actually > consume the things Received-SPF supports that Authentication-Results > does not? > My python milter production software on a dozen MTAs consumes Received-SPF. It is very important for a main MTA getting mail forwarded from an MX (the MX has to check SPF, of course). All the fields are used, plus a few x-* fields I added (like x-bestguess). The mechanism field in particular is *very* useful in diagnostic messages for 5xx SMTP responses and DSNs - although that mainly comes up with PermError and Pass. The mechanism is usually "-all" for Fail. Ironically, ietf.org has provided an example of the utility of problem/mechanism. Here are the results from the email quoted above: Authentication-Results: mail.bmsi.com; iprev=pass policy.iprev=2001:1890:126c::1:1e (mail.ietf.org); spf=permerror (SPF Permanent Error: Invalid IP6 address: ip6:2001:1890:126c:::0/56) smtp.helo=mail.ietf.org smtp.mailfrom=spfbis-bounces@ietf.org; dkim=pass (Good signature.) header.d=ietf.org Received-SPF: PermError (mail.bmsi.com: permanent error in processing domain of ietf.org: Invalid IP6 address) client-ip=2001:1890:126c::1:1e; envelope-from="spfbis-bounces@ietf.org"; helo=mail.ietf.org; receiver=mail.bmsi.com; problem="ip6:2001:1890:126c:::0/56"; x-helo-spf=pass; identity=mailfrom ietf.org has published an invalid SPF record! Too many colons in an IP6 mechanism. That said, I seem to recall authres providing for user defined fields also - so I plan on using those when transitioning. BTW, speaking of diagnostics, what has come up many times is wishing that mechanism provided a "stack trace" - i.e. what mechanism at each include level. This can usually be resolved by rerunning the query manually with IP, MFROM, HELO however. From agthisell@yahoo.com Wed Sep 5 12:00:07 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCD921F86D5 for ; Wed, 5 Sep 2012 12:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=0.812, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haRR9d4ITUpz for ; Wed, 5 Sep 2012 12:00:06 -0700 (PDT) Received: from nm25-vm4.bullet.mail.ne1.yahoo.com (nm25-vm4.bullet.mail.ne1.yahoo.com [98.138.91.185]) by ietfa.amsl.com (Postfix) with SMTP id 138C221F86D9 for ; Wed, 5 Sep 2012 12:00:05 -0700 (PDT) Received: from [98.138.90.51] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 05 Sep 2012 19:00:02 -0000 Received: from [98.138.226.165] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 05 Sep 2012 19:00:02 -0000 Received: from [127.0.0.1] by omp1066.mail.ne1.yahoo.com with NNFMP; 05 Sep 2012 19:00:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 910421.86148.bm@omp1066.mail.ne1.yahoo.com Received: (qmail 6919 invoked by uid 60001); 5 Sep 2012 19:00:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346871602; bh=QfPqs1VPmC2NwxzpOa3XT82DtnBZQqVbGY4ZgIrXaN4=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=Vmlzdxq/RQEeQ96wHhXn7OlsCVr367ZXlpLi+zUF01dHt2wah6Y5xZWjTRH2SBoix6jYBK1WYot7X6YOjGmhcG6nMkvZtMfLspyBtwwyrXvjgRYTsp9F2P3FDD1kVfQ/pBD/qbYorXLDKI7LaMw9bR3qUdkbNIbffLttD0W/xEU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=adCWvv2H9WvKn+11daDHLXjWMPKMyuDdkzubTuyvOeBGDn9U2ui0HWef/QieZJAcrlsC0hXi1uFodYo/TBe1xSSP8WJKyXFDz0AKu32rmRLii20MapiDfBt9RGLU1k/8CXhUIzc2qzHy0468AaO3wVDrEX8Bg33u4uCbugoglLs=; X-YMail-OSG: aQ6k.lYVM1m1QTZKVH4.OpjC4UNR6LfuW3w.C_pJqK3UnsC Vkh_dWv6I6ztK8UMfeYWdAhyJfe8VeMyMa5lr9u2Y06cEhpNLA6WtxA_Nk8B cFPZGwCEd1Lw5ct9RhYvxowsPMxUzv6FO_s6fAw.dVyurG117eoLpTzaSvt4 9F9H5IUcQ_TA8t3n2OV63urMEko4sQrsXf_130Z9rX5HvAlTY1Y1xL50M0rN 8WinXbUA7WTzjKD3UWOYbIoXVVuOqAtyIjPl4rJLAn9G3SgHbtd9wZ_Th_Md mfYEyoDMFEbLUYtC.dQ5qqOBKGXFT2nEd0hI_7wMLF4R5jw32w.zaIhy2xLa uSRb61AdjDStzpt74tDzLFi4.6mK6LJueTT4l5gLUk7SIBryFcJLBx880Zm0 lATvNSDi7mel6i1LvqlvpYa623_3sqN6STvo3DwS_WP3i4y0KdbAG6zR9puo 762LF1zchL18Pr4UxiMU- Received: from [71.61.133.134] by web125403.mail.ne1.yahoo.com via HTTP; Wed, 05 Sep 2012 12:00:02 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346871602.97437.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Wed, 5 Sep 2012 12:00:02 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] Possible ABNF nit with Received-SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Sep 2012 19:00:07 -0000 two things... First, we could probably just get rid of the mechanism keyword on the Received-SPF ABNF. I doubt it is used, and even if it is, things would still be valid since the ABNF allows arbitrary keyword-value pairs. This was only really important when Meng Weng Wong was trying to turn Sender Protect From into a Sender Policy Framework. Second, I thought that maybe we could reduce confusion by instead of listing all the possible keywords, and then matching those keywords up with valid values, we could match up the keywords and values in the ABNF. I'm not sure if the result is a success though, there is some duplicate ABNF and it still seems confusing, but maybe it's a start. From: key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) key = "client-ip" / "envelope-from" / "helo" / "problem" / "receiver" / "identity" / mechanism / name identity = "mailfrom" ; for the "MAIL FROM" identity / "helo" ; for the "HELO" identity / name ; other identities client-ip the IP address of the SMTP client envelope-from the envelope sender mailbox helo the host name given in the HELO or EHLO command mechanism the mechanism that matched (if no mechanisms matched, substitute the word "default") problem if an error was returned, details about the error receiver the host name of the SPF verifier identity the identity that was checked; see the ABNF rule To: key-value-pair = "client-ip" [CFWS] "=" key-value-pair =/ "envelope-from" [CFWS] "=" key-value-pair =/ "helo" [CFWS] "=" key-value-pair =/ "identity" [CFWS] "=" ("mailfrom" / "helo" / name) key-value-pair =/ "problem" [CFWS] "=" key-value-pair =/ "receiver" [CFWS] "=" key-value-pair =/ name [CFWS] "=" ( dot-atom / quoted-string ) From spf2@kitterman.com Wed Sep 5 12:04:06 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B1221F86AD for ; Wed, 5 Sep 2012 12:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TI3ByBmqXHn for ; Wed, 5 Sep 2012 12:04:05 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDE021F86CE for ; Wed, 5 Sep 2012 12:04:05 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 87D0120E40E8; Wed, 5 Sep 2012 15:04:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346871844; bh=kFVvn2liiNrecCKmo1yty95Ulkox5J1BkWgT1Qk3lc0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jszWozStOcFKgFqXDIhPqyPWhZb+4cuMvqvgle7YPR3MQi9NliV9zaKAjHVsNtbAP 58bR8i/Qmkm/5fFlbz4nOU1DIIhzT1BM6/LlEuYafW3JeW8oF84gt3/1pnzslmkS3P xU7lCXsrjgOKrIcIq8xwcMQRYS4P3ZqW+Ly+JDIQ= 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 589FE20E409A; Wed, 5 Sep 2012 15:04:03 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 05 Sep 2012 15:04:03 -0400 Message-ID: <2407126.m4gSSPmzuo@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <1346871602.97437.YahooMailClassic@web125403.mail.ne1.yahoo.com> References: <1346871602.97437.YahooMailClassic@web125403.mail.ne1.yahoo.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] Possible ABNF nit with Received-SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Sep 2012 19:04:06 -0000 On Wednesday, September 05, 2012 12:00:02 PM Arthur Thisell wrote: ... > First, we could probably just get rid of the mechanism keyword on the > Received-SPF ABNF. I doubt it is used, and even if it is, things would > still be valid since the ABNF allows arbitrary keyword-value pairs. This > was only really important when Meng Weng Wong was trying to turn Sender > Protect From into a Sender Policy Framework. ... It is used. It's useful for forensics, which is one of the main purposed of Received-SPF. Scott K From sm@resistor.net Wed Sep 5 12:08:32 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7114821F86E3 for ; Wed, 5 Sep 2012 12:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYy41Hm3DYfG for ; Wed, 5 Sep 2012 12:08:31 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7688321F86CF for ; Wed, 5 Sep 2012 12:08:31 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q85J8D2C014215; Wed, 5 Sep 2012 12:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346872100; bh=cSH/T6ExQyghstuk21l5usRLDN6NGkry/TBoeiGnhSg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=laf2y9s7qL+IfD4FKXWPdYODkmq3zHEMCPQo3wFvFLlC0wzboLOtKBGc908MO1sa8 fyM2GcdBaL18UUSRnW1ageYUvXBTx0DJ6uxz/R5+WI/yW7g2ZhO/sKkmmbPx62M7/E TjMkWPznrqqoU/fTmxEytr1fHM6IB1XibgBgEjgc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1346872100; i=@resistor.net; bh=cSH/T6ExQyghstuk21l5usRLDN6NGkry/TBoeiGnhSg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=V/ZNiLrZo0m65IPgGNGQgoO2Yk9p8WdmQSinvulea0HkgU5h8DjmX/PBT5vz3TNsM +bFddA47s+XKme7/6So8VOHMwSv1ZQ/7/P6c4rV1hKGOACgf2ieri4xDCzarSW2iXj nr5ciGOUn9Un46Uvj5UFBmWh+uUIr/JE4rpoo/Uo= Message-Id: <6.2.5.6.2.20120905120433.096b6618@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 05 Sep 2012 12:08:13 -0700 To: Stuart D Gathman From: SM In-Reply-To: <50479829.5050707@gathman.org> References: <1346842829.84355.YahooMailClassic@web125403.mail.ne1.yahoo.com> <50479829.5050707@gathman.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Received-SPF in the real world X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Sep 2012 19:08:32 -0000 Hi Stuart, At 11:21 05-09-2012, Stuart D Gathman wrote: >ietf.org has published an invalid SPF record! Too many colons in an >IP6 mechanism. The problem was fixed a few minutes ago. Regards, -sm From agthisell@yahoo.com Wed Sep 5 12:12:38 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2367B21F8594 for ; Wed, 5 Sep 2012 12:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.69 X-Spam-Level: X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[AWL=-0.691, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0Np9sxL8Tve for ; Wed, 5 Sep 2012 12:12:37 -0700 (PDT) Received: from nm11-vm3.bullet.mail.ne1.yahoo.com (nm11-vm3.bullet.mail.ne1.yahoo.com [98.138.91.141]) by ietfa.amsl.com (Postfix) with SMTP id 7ECD121F8551 for ; Wed, 5 Sep 2012 12:12:37 -0700 (PDT) Received: from [98.138.90.55] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 05 Sep 2012 19:12:26 -0000 Received: from [98.138.89.244] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 05 Sep 2012 19:12:26 -0000 Received: from [127.0.0.1] by omp1058.mail.ne1.yahoo.com with NNFMP; 05 Sep 2012 19:12:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 248542.63030.bm@omp1058.mail.ne1.yahoo.com Received: (qmail 12797 invoked by uid 60001); 5 Sep 2012 19:12:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1346872346; bh=+DhLUBTK5Dn+Je/HaaBr6xCNFjNQ5uirPjQ+yVTti8w=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=QfpeiUJFbLYUfk/phx5oxoeMv7vr49esF5DL/6ztTqYY/6J9O3PDVXqfRvrAhh35YA44WUEIfX70icAL68XBdCnoOYKWZivdVlE2kjJHAYTragx8fiWl9uUXe5G/I070L/t/OuWtuGU4q49O6lgof+EGusEX94cryRKK8qAkDpI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=FqlnrI3LDV7VKCSY1DbtSzYXEMdweOwE1zHpnVvGw3sa0PJPM5n+XQI/b8nZZd5JUBSEJDqvw1d4YzQI+ptYX2DcpxLBudo6yy4JiTyzagtmDtFBBoRmjOhTClzmrCaDgE4eokz5rXN8ygbz0Wn/jxksQcymt1rP5XTuNmR3hMc=; X-YMail-OSG: ckWxC_8VM1lrzsqP67K7r55xa9XX6Q9ah7PvtEysd.DYv1I YcKBdabuDPoDsHiE9z3z0z.lXnpsUB9cgYLsIgu2zXvcK53fUbM69yUX2ed0 Dg1jNyQF6HAcmqsipKRpcVWrqRJXUTZQ3oDPfdK8Ru8OHGuIhofGnh40SjRQ HRnvyU_BUZ4o5HspB50ul_VUnVleChn6qs0hhT.L89YPjmvoM1gPNYNXZVDJ vzPDg6tuVoZDrmu3V1GffXL9X70vubdC5H1p1acUM.DIAWic6pNilNJkCR.Y EkkaoBO5e8mjIPMyYkKm85gngAK5p0A7U8FenPpwZMu6T75XIFGpM5BKTuPz q2oP8cjW2wx_HFB4inNpOLfAFcAokP2Uww1zbjAMXdgrTVa0A2ybJNKiBz5U xN3XU8x5MQBGFxenXekU8b0hw69iPJIutCZX5GkPCZJVPPs._nrOrvnvIjoU 5a.Cm3hTxpwJn.0WBWjQ- Received: from [71.61.133.134] by web125405.mail.ne1.yahoo.com via HTTP; Wed, 05 Sep 2012 12:12:25 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1346872345.12776.YahooMailClassic@web125405.mail.ne1.yahoo.com> Date: Wed, 5 Sep 2012 12:12:25 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] Received-SPF in the real world X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Sep 2012 19:12:38 -0000 > I don't think that's a question that can be answered. I do believe that while > A-R support for spamassassin {...} Speaking of SA... I thought they had a large spam/ham corpus that they used to tune the weights on their rule sets, but all I could find was ones from 2004 or so. They may have taken it private to increase the privacy of the emails and/or to prevent spammers from abusing it. If they have a corpus, it might give us some useful data on the Received-SPF header, but I doubt they will give it out easily. I thought about contacting them, but I doubt I would get far, just claiming I'm participating in some IETF WG... From dhc@dcrocker.net Wed Sep 5 12:33:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE09A21F86B1 for ; Wed, 5 Sep 2012 12:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wpx8G56XeSxU for ; Wed, 5 Sep 2012 12:33:20 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 34B8921F86AD for ; Wed, 5 Sep 2012 12:33:20 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q85JXJOF019750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 5 Sep 2012 12:33:19 -0700 Message-ID: <5047A8FB.9010806@dcrocker.net> Date: Wed, 05 Sep 2012 12:33:15 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 05 Sep 2012 12:33:20 -0700 (PDT) Subject: [spfbis] ISSUE: Section 9.2 is badly broken X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 19:33:20 -0000 Section 9 declares that it is non-normative. Also it bases its discussion on RFC 5598. 1. Section 9.2.1 Mailing Lists It contains normative language. It attempts to specify host activities about mailing lists. All of the content of 9.2.1 is entirely out of scope for SPF. So the entire section should be removed from the document. 2. Section 9.2.2 Forwarding Services and Aliases The term "forwarding service" is equated with "alias". It is explained as: "Forwarding services take mail that is received at a mailbox and direct it to some external mailbox." That describes many types of mechanisms, not just aliasing mechanisms. In fact, the term "forwarding service" does not exist in RFC 5598. Further, the term "forwarding" is used in multiple contexts in RFC 5598. The most relevant use is in the section discussing mailing lists and aliases: "A Mediator forwards a message..." That is, the usage is for the broader concept of /all/ mediators, not just aliasing mechanisms (which are an instance of mediators.) I suggest the term "forwarding service" be dropped. 3. Section 9.2.2 Forwarding Services and Aliases The introductory paragraph summarizes the concept and cites RFC1123 and RFC5321. With respect to mailing lists and aliases, RFC 5321 updates RFC 1123. The reference to RFC 1123 should therefore be dropped. However the general RFC5321 Section 3.9, Mailing Lists and Aliases, is also rather problematic, with normative requirements that do not match industry practice and some terminology that also differs from common usage. So reference to RFC5321 concerning mailing lists and aliases unfortunately invites confusion. Since the draft's discussion is non-normative and since the draft is already liberally drawing from RFC 5598, I suggest that all reference and background to Mailing Lists and Aliases be based on RFC 5598 (which is also considerably more detailed on these topics than RFC 5321...) In contrast, the draft's discussion of SPF issues in the presence of mediators: "[RFC1123] and [RFC5321] describe this action as an "alias" rather than a "mail list"." appears useful, although it appears to cover both mailing list and aliasing issues, not just aliasing, as constrained by the section containing the discussion. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Wed Sep 5 12:43:54 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB12321F86B2 for ; Wed, 5 Sep 2012 12:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.27 X-Spam-Level: X-Spam-Status: No, score=-3.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7GY-bvQxhMp for ; Wed, 5 Sep 2012 12:43:53 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B20321F86AF for ; Wed, 5 Sep 2012 12:43:53 -0700 (PDT) Received: by lahm15 with SMTP id m15so675722lah.31 for ; Wed, 05 Sep 2012 12:43:52 -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=g2fgMDr2f6fO/n1sje9iLhASZhPtROt1AT3uJDVThEE=; b=NJu4cjGn0C0oTofuC0Dw0OBuAbsgA+MPTjEp3Q+nE7CyqTp8XFXFez12zbQ0cI+HTx zZWRb8Z0G/FFC37lEZ0Z48RLQ16kU7vx937CS4wJWpEBkRbnI0VP+Sz+h6dLMmQrh8ic 1uAD0d2AR9QEft8lLc9J2o3BrfYb1jWKpHMEVD3ponQ6mcFLwnn+HqzRioGHJPOB6Y29 NnqjPS/n9K6hz2giycg3/anEQnT9c51h3V4BZc8yCcc4JcqZvXt9jlloUkN7yX4DCCkZ 0buzb5+4qSVqjwfwXwmMEq/RkVjkgx78gg1GsaSJm5Bb2SgdAnL1XeT4SImyuRPpoool 1GHA== MIME-Version: 1.0 Received: by 10.112.30.34 with SMTP id p2mr24454lbh.85.1346874232291; Wed, 05 Sep 2012 12:43:52 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Wed, 5 Sep 2012 12:43:52 -0700 (PDT) In-Reply-To: <6354353.tSmACd1r1W@scott-latitude-e6320> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <4094761.6jIeQ51N6G@scott-latitude-e6320> <6354353.tSmACd1r1W@scott-latitude-e6320> Date: Wed, 5 Sep 2012 12:43:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Sep 2012 19:43:54 -0000 On Sun, Sep 2, 2012 at 10:52 PM, Scott Kitterman wrote: >> Here's a monkey wrench for that logic: Section 9, as it is explicitly >> non-normative, doesn't actually specify anything. Thus, rewriting, >> extending, removing, or repositioning it is not a change to "the SPF >> specification". > > Then I guess removing all the security considerations wouldn't be a change to > the SPF specification either? Every RFC has to have security considerations, or it can't be published. And SPF has plenty to discuss in that area. So, no. My point is that there's so much explanatory and pedagogical text either in RFC4408bis or being proposed for addition to it that creating a parallel deployment guide to include all the non-critical discussion would de-bulk the core in a useful way, and some of that was also present in RFC4408. That's why I suggested it. This was a successful tactic for other protocols that now comprise multiple documents. Perhaps SPF would benefit from such a division of output. The idea is not to hide or remove material, only to arrange its presentation differently. Anyway, it's a suggestion for the chairs to consider. It's their call. It will require a re-charter, but I suspect that request would meet with little AD resistance should they decide to do it. -MSK From spf2@kitterman.com Wed Sep 5 13:16:11 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15CE21F86AD for ; Wed, 5 Sep 2012 13:16: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SP7I4QnTd-8l for ; Wed, 5 Sep 2012 13:16:10 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 402ED21F8643 for ; Wed, 5 Sep 2012 13:16:09 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 493F620E40E8; Wed, 5 Sep 2012 16:16:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346876169; bh=3gBwxFv76bYHuMfXWLBPKVTlspGhi7FTbnLV8UedD9U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=OG4sNE8e5PqIEaUjYosR/i2s0Rbc7Cqsn+9carZVazeDXj7AKF1nuTsXvxbcLXQpa Tyw77F0r/axDKCMdXFEEn/1Ot82TH0/57vW9UWrn6mUQvQDqeV+uZtMCuEyODV9/cA QMKZaZsyOMgVnra6okXa704FkL1cYLQ3ISRd2tu8= 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 2405F20E409A; Wed, 5 Sep 2012 16:16:08 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 05 Sep 2012 16:16:08 -0400 Message-ID: <3785358.KpgcBP5aSr@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <6354353.tSmACd1r1W@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Sep 2012 20:16:11 -0000 On Wednesday, September 05, 2012 12:43:52 PM Murray S. Kucherawy wrote: > On Sun, Sep 2, 2012 at 10:52 PM, Scott Kitterman wrote: > >> Here's a monkey wrench for that logic: Section 9, as it is explicitly > >> non-normative, doesn't actually specify anything. Thus, rewriting, > >> extending, removing, or repositioning it is not a change to "the SPF > >> specification". > > > > Then I guess removing all the security considerations wouldn't be a change > > to the SPF specification either? > > Every RFC has to have security considerations, or it can't be > published. And SPF has plenty to discuss in that area. So, no. > > My point is that there's so much explanatory and pedagogical text > either in RFC4408bis or being proposed for addition to it that > creating a parallel deployment guide to include all the non-critical > discussion would de-bulk the core in a useful way, and some of that > was also present in RFC4408. That's why I suggested it. This was a > successful tactic for other protocols that now comprise multiple > documents. Perhaps SPF would benefit from such a division of output. > > The idea is not to hide or remove material, only to arrange its > presentation differently. > > Anyway, it's a suggestion for the chairs to consider. It's their > call. It will require a re-charter, but I suspect that request would > meet with little AD resistance should they decide to do it. If we conclude a split is appropriate (I'd still rather finish the current issues and then decide) and recharter to include the split document, I've no objection to that. My objection is the idea (which was one of several being thrown around) to drop Section 9 without rechartering and then make 4408bis dependent on a draft no one is chartered to right. My point in this particular case is that "non-normative, doesn't actually specify anything" does not inherently equate to "can be removed". Scott K From sm@elandsys.com Wed Sep 5 14:10:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE69021F8587 for ; Wed, 5 Sep 2012 14:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNgmvGgKmgyU for ; Wed, 5 Sep 2012 14:10:22 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D1F21F857A for ; Wed, 5 Sep 2012 14:10:22 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.246]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q85LA4PV027501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Sep 2012 14:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346879416; bh=dMLIJ2ycMU67g8z5mm/aweF0IHz97xz5IXZdHAzD1yI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OmkBCuij0IHdTjE5Xb3kOAYuu3r/1C43C+aTbO65vWLUokLnRvfM0T9RPE4fwIZot 54i49DTwJeybmlK2G7X5g+jKnNId0GYKCMHIvmH5NYfpxQuWnc/TY3DbmxYjV3o9o+ KzQOZsR6zds56e9pd2xZitx1ckOzqKCLhH9uDxMQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346879416; i=@elandsys.com; bh=dMLIJ2ycMU67g8z5mm/aweF0IHz97xz5IXZdHAzD1yI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=u2x5/BxozT/LHNd6ppiNFzlVpyzLUNujw++cFLiT1m0BM9s69mr23knJ7P2zW67fN Pw7e81D0uoi7puBr+BGkDV9usdV3sHYwMzR0PyRqHofmGkneyEUpe6IA0WALotTw+H WFLdQh7m/IuFr4bs9JlTj+mkCtSUPG9HVqslWUd8= Message-Id: <6.2.5.6.2.20120905140732.0b351ac0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 05 Sep 2012 14:09:26 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <3785358.KpgcBP5aSr@scott-latitude-e6320> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <6354353.tSmACd1r1W@scott-latitude-e6320> <3785358.KpgcBP5aSr@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Sep 2012 21:10:22 -0000 Hi Scott, It looks like there are a lot of issues for Section 9. Are you planning to do a major rework of the section, or should we open issues for all of them? Regards, S. Moonesamy SPFBIS WG co-chair From superuser@gmail.com Wed Sep 5 14:12:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0276521F86C9 for ; Wed, 5 Sep 2012 14:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.317 X-Spam-Level: X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CU5W3btQYk2l for ; Wed, 5 Sep 2012 14:12:02 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E98321F857A for ; Wed, 5 Sep 2012 14:12:01 -0700 (PDT) Received: by lahm15 with SMTP id m15so730803lah.31 for ; Wed, 05 Sep 2012 14:12: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=bRi5LcnvRbqll60jN7Z0A6WfpUuwg1abBBB2CZG6lpE=; b=ATkpT059NzYaTeVF4XvSpK5SgZ6Hlc3j5bfKGEqFwwaDBFI8rClCI8kPMyFHwzExUs V6MQWAt4FeRltKcBvDunHMUKZOVulI/A/b3+G0+mkg6L2l79+D/Q4I9a5HpJ5ToZENPp B1GLAB88NORxUjAYViInSV/aAbi7PmjIxxihjA60eM3wWyE4RIE089tr+lUER7snlU1S wwyjciL68xfjQYNIknd/4aM9WDVhvJAJEc9iyYiPPLsMFKKGzc7NZqpc7yMq0HgQWPjd F16b2EUgUeVGao0qLnbBUgSoyWfCNktjcnsLiSSy1tIIaMDJdVEUFto/QjoXg/9ZxD1T WsUw== MIME-Version: 1.0 Received: by 10.112.9.133 with SMTP id z5mr98092lba.69.1346879520824; Wed, 05 Sep 2012 14:12:00 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Wed, 5 Sep 2012 14:12:00 -0700 (PDT) In-Reply-To: <3785358.KpgcBP5aSr@scott-latitude-e6320> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <6354353.tSmACd1r1W@scott-latitude-e6320> <3785358.KpgcBP5aSr@scott-latitude-e6320> Date: Wed, 5 Sep 2012 14:12:00 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Sep 2012 21:12:03 -0000 On Wed, Sep 5, 2012 at 1:16 PM, Scott Kitterman wrote: > My point in this particular case is that "non-normative, doesn't actually > specify anything" does not inherently equate to "can be removed". I wasn't applying that statement to all sections. Obviously a protocol document needs non-normative stuff to enable people to make sense of it, and Security Considerations and other required sections are critical. I think this is a continuation of the discussion about what's core and what isn't. For example, if we agree that SMTP is primarily a signaling mechanism between the apparent sending ADMD and a receiver, then the protocol is effectively done once check_spf() is able to return a result. Anything that happens after that is technically not part of SPF, and that's the kind of stuff that could be trimmed from a core document. -MSK From spf2@kitterman.com Wed Sep 5 14:15:11 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BD921F86A0 for ; Wed, 5 Sep 2012 14:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Af1uB2J3cjld for ; Wed, 5 Sep 2012 14:15:10 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D9B9021F8685 for ; Wed, 5 Sep 2012 14:15:10 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 58DF820E40E8; Wed, 5 Sep 2012 17:15:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346879710; bh=QKeJv3k3vEE2AkYPP8idRy4NGNFYitCxvSxtvGpT/dw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=i0pmMgx+tKHzgrAIlB1neuWNVxRnCozvf0mQJWVEvVL2WHKlnXD2Pze1amUAHFJFh Dw9sTJDE2ivQrWqLN8Ve5jV1fctGEgsSvo3quPIdwEvpmJLCyfhRDPki9r+POW3SHG ZRx4E5xxo9xwHw6RSfz5gPoBr5Anv2nN3pimquKM= 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 31A5520E409A; Wed, 5 Sep 2012 17:15:09 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 05 Sep 2012 17:15:09 -0400 Message-ID: <15135477.27lt15B5q7@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <3785358.KpgcBP5aSr@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Sep 2012 21:15:11 -0000 On Wednesday, September 05, 2012 02:12:00 PM Murray S. Kucherawy wrote: > On Wed, Sep 5, 2012 at 1:16 PM, Scott Kitterman wrote: > > My point in this particular case is that "non-normative, doesn't actually > > specify anything" does not inherently equate to "can be removed". > > I wasn't applying that statement to all sections. Obviously a > protocol document needs non-normative stuff to enable people to make > sense of it, and Security Considerations and other required sections > are critical. > > I think this is a continuation of the discussion about what's core and > what isn't. For example, if we agree that SMTP is primarily a > signaling mechanism between the apparent sending ADMD and a receiver, > then the protocol is effectively done once check_spf() is able to > return a result. Anything that happens after that is technically not > part of SPF, and that's the kind of stuff that could be trimmed from a > core document. Perhaps. I agree it's likely we'll want to split, but I'd prefer we deal with the question of how to arrange the collected work until after we finish working through the issues and see what we have to deal with. Scott K From spf2@kitterman.com Wed Sep 5 14:16:50 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1F421F86F1 for ; Wed, 5 Sep 2012 14:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdwo2bVT2vik for ; Wed, 5 Sep 2012 14:16:50 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6639721F86E8 for ; Wed, 5 Sep 2012 14:16:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BB63420E40E8; Wed, 5 Sep 2012 17:16:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346879803; bh=Th+z7KuMnMeyKjdCsIw/p2rUWJ1JMDQO7ajI941PLAg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=oHaxF9ZDlRQ810zuo21WYzWmnag4MR3wcezyiQiDi/aw/4o35Z5GrXIjenAUjb1al 6aCwAaf2P51A0lyqP2YZ2rTR+XCs5Lh87ilJ3BXbwVN4vqiG0Wjgb6X9IUVFBiorq8 BP0p7IH68ZwLaGESppcujwmcmKDDGCsRxRFT5mrA= 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 AA0B720E409A; Wed, 5 Sep 2012 17:16:43 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 05 Sep 2012 17:16:43 -0400 Message-ID: <1433326.JAlz6WYfAq@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120905140732.0b351ac0@resistor.net> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <3785358.KpgcBP5aSr@scott-latitude-e6320> <6.2.5.6.2.20120905140732.0b351ac0@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 05 Sep 2012 21:16:50 -0000 On Wednesday, September 05, 2012 02:09:26 PM S Moonesamy wrote: > Hi Scott, > > It looks like there are a lot of issues for Section 9. Are you > planning to do a major rework of the section, or should we open > issues for all of them? I think opening issues is useful. I've taken a first pass at it, but no doubt it needs more work. In terms of what I'm planning, I'm still planning on waiting to hear back from you/Andrew on the reorganization you directed before I do more on the document. Scott K From dhc@dcrocker.net Wed Sep 5 14:30:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804BE21F86F5 for ; Wed, 5 Sep 2012 14:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWYYrlrQS2bx for ; Wed, 5 Sep 2012 14:30:19 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id BDBB821F86EB for ; Wed, 5 Sep 2012 14:30:19 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q85LUIfB021917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Sep 2012 14:30:19 -0700 Message-ID: <5047C467.8000306@dcrocker.net> Date: Wed, 05 Sep 2012 14:30:15 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Scott Kitterman References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <3785358.KpgcBP5aSr@scott-latitude-e6320> <15135477.27lt15B5q7@scott-latitude-e6320> In-Reply-To: <15135477.27lt15B5q7@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 05 Sep 2012 14:30:19 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 21:30:20 -0000 On 9/5/2012 2:15 PM, Scott Kitterman wrote: > Perhaps. I agree it's likely we'll want to split, but I'd prefer we deal with > the question of how to arrange the collected work until after we finish working > through the issues and see what we have to deal with. That's probably ok. If we are lucky, it's only the difference between form and substance. The form matters, but not as much as the substance. The one issue that could change this is when the form creates confusion. It's possible that some set of issues become much easier to deal with, if we separate things out. This is merely a classic divide and conquer approach, but done right it often creates much better discipline and clarity in thinking about a topic. However I'm not expressing a preference for this, yet. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Wed Sep 5 17:29:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA7921F8704 for ; Wed, 5 Sep 2012 17:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3laVL3D+NCU for ; Wed, 5 Sep 2012 17:29:17 -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 10C3721F8703 for ; Wed, 5 Sep 2012 17:29:17 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.246]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q860T1qf009277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Sep 2012 17:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346891354; bh=8xG9Fj1d2KXKaRQsAKTMEegHLqfg9saE59qLqd4CLg4=; h=Date:To:From:Subject:Cc; b=oHSuGAUthUDwdUorgF0Y7vS4WYdxxb8NoKSuN+jLZAmxg204fkmYD4K1vVJPiXl+G yK2AtPFLDAxy6Phhukq86nFj+wVN0/2blISYRVgaQ0Lf742x9XRguwrVb2HWbfUI2f gZYMO6OldonqL0nJKZCMYy5RNZJwmtgm4qzx8zDg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346891354; i=@elandsys.com; bh=8xG9Fj1d2KXKaRQsAKTMEegHLqfg9saE59qLqd4CLg4=; h=Date:To:From:Subject:Cc; b=Hjz/s1ruyyJTOtn+xDVI3+09huC2E23EkGNuTDj963FYpAiPQzoziPmLQPUTqnUYq NP8vqz1rjLMrNwWObzvaxwn0kEPwoSGJestkXc//xGD+pGM8CLsQBUGjcUUyjyjPXt x7SjArncKvavPfGXuQQuQ5ZqGMxpSgHjEkpswUfM= Message-Id: <6.2.5.6.2.20120905172524.0ad7be00@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 05 Sep 2012 17:27:54 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] Fwd: NomCom 2012-2013: Call for Nomination and Feedback X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Sep 2012 00:29:18 -0000 Hello, I am forwarding this message from NomCom. Regards, S. Moonesamy >This is a reminder that the 2012-2013 Nominating Committee (NomCom) >is seeking nominations from now until September 24, 2012 . > >Additionally, this is an announcement that the NomCom is seeking >feedback on individuals who have accepted nominations for IETF >leadership positions. As we are following the advice of RFC 5680, the list >of individuals who have agreed to be considered for various positions can >be found on the NomCom Community Feedback Tool: > >https://www.ietf.org/group/nomcom/2012/input > >Within the coming weeks, we will be updating the list of individuals we >are considering for each position as more individuals accept nominations. >All feedback provided to the NomCom about these individuals is kept >strictly confidential (as per RFC 3777). Your honest >feedback is very important to the NomCom process. > >The open positions being considered by this year's NomCom can be found >at the end of this email or on the NomCom 2012-2013 website: > >https://www.ietf.org/group/nomcom/2012/ > >Nominations may be made by selecting the Nominate link at the top of >the NomCom 2012-2013 website or by visiting the following URL: > >https://www.ietf.org/group/nomcom/2012/nominate > >Note that nominations made using the web tool require an ietf.org (i.e., >datatracker) account. You can create an ietf.org account by visiting the >following URL: > >https://datatracker.ietf.org/accounts/create/ > >Nominations may also be made by email to nomcom12@ietf.org. >If you do so, 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 wish to nominate someone via email >for more than one position, please use separate emails to do so. > >Self nomination is welcome. > >NomCom 2012-2013 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 publicly listed. > >With the exception of publicly listing willing nominees, the >confidentiality requirements of RFC 3777 remain in effect. All >feedback and 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 September 24, 2012. > >The NomCom appoints individuals to fill the open slots on the >IAOC, the IAB, and the IESG. This year, the NomCom willing be filling the >positions currently held by the following individuals, whose terms expire >in March 2013: > >IAOC: >-------- >Dave Crocker > >IAB: >-------- >Alissa Cooper >Joel Halpern >David Kessens >Danny McPherson >Jon Peterson >Dave Thaler > >IESG: >-------- >Russ Housley (IETF Chair) >Pete Resnick (Applications Area) >Ralph Droms (Internet Area) >Ronald Bonica (Operations and Management Area) >Robert Sparks (Real-Time Applications and Infrastructure Area) >Adrian Farrel (Routing Area) >Stephen Farrell (Security Area) >Wesley Eddy (Transport Area) > >In addition to nominations, the Nominating Committee is actively >seeking community input on the jobs that need to be filled. We have >received the job descriptions from the IAB, IESG, and IAOC and they can >be found at: > >https://www.ietf.org/group/nomcom/2012/iaoc-requirements >https://www.ietf.org/group/nomcom/2012/iab-requirements >https://www.ietf.org/group/nomcom/2012/chair-requirements >https://www.ietf.org/group/nomcom/2012/iesg-requirements > >However, we also need the community's views and input on the jobs >within each organization. If you have ideas on job responsibilities >(more, less, different), please let us know. Please send suggestions >and feedback to nomcom12@ietf.org. > >Thank you for your help in identifying qualified nominees, and in providing >feedback about individuals we are considering for IETF leadership positions. > >Matt Lepinski >nomcom-chair@ietf.org From W.Doust@racingvictoria.net.au Wed Sep 5 20:07:09 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0379621F855F for ; Wed, 5 Sep 2012 20:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdlZAFiKq4qT for ; Wed, 5 Sep 2012 20:07:08 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC6321F855D for ; Wed, 5 Sep 2012 20:07:07 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v7, 1, 0, 4874) id ; Thu, 06 Sep 2012 13:07:04 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Sep 2012 13:06:16 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF010D4B3C@XCHANGE.rvl.internal> In-Reply-To: <1346842829.84355.YahooMailClassic@web125403.mail.ne1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] Received-SPF in the real world Thread-Index: Ac2LVbOm6jDxHWN6QOu4rYG3slcR0QAheyPg References: <1346842829.84355.YahooMailClassic@web125403.mail.ne1.yahoo.com> From: "Wayne Doust" To: "Arthur Thisell" , Subject: Re: [spfbis] Received-SPF in the real world X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Sep 2012 03:07:09 -0000 While not a standard commercial implementation, I use Received-SPF for scoring purposes, particularly for whitelisted addresses by bypass SPF blocking. I imagine that this is most useful in second-line defence (eg: hold SoftFails for later release). Regards, Wayne Doust From hsantos@isdg.net Thu Sep 6 01:04:38 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB4A21F854A for ; Thu, 6 Sep 2012 01:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.135 X-Spam-Level: X-Spam-Status: No, score=-101.135 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGfHM01d0luN for ; Thu, 6 Sep 2012 01:04:37 -0700 (PDT) Received: from news.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 416AF21F8522 for ; Thu, 6 Sep 2012 01:04:36 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1955; t=1346918670; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=i8JPGECsnrllCPNd9bkL78YQWMg=; b=S9y7plZX0Ezt5e5zbdv8 saoRMJNGUW5u6/7Sm0WRusLu05Gctx0Z4dducekxpXa1lrthmmWbxEFO6+ykV7p+ mW1VhFhOQNJvM1YK03ApjPGc+dfodh3vTKjkLlYkRxHOQk5Rof3VBRX5MRunrmjJ 2tDJE/SXBaOKoq9e/Cl8eOk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 06 Sep 2012 04:04:30 -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 2940453401.132.2968; Thu, 06 Sep 2012 04:04:29 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1955; t=1346918456; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=LuUKm93 gDA16wqQwpMnf/AZ+Wi0GG1x/CUTtAvb60x4=; b=dDih9K7jq62rwyiP98Jyt3Y U7ciOCLGjf0ici4owvtTCE6ZzUQw28pSQjz+mIXQQ1SL6Z3PEFKa/SdPgnvZn7BA fq4ex/oGQzD0cc76URqv4Y6DFU+rEAruk8WKGZZvAc0PdUIr4uIMUEJL6Ebv6fbZ J9rUaLJhvfny95dCNt4k= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 06 Sep 2012 04:00:56 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3539254661.9.7952; Thu, 06 Sep 2012 04:00:55 -0400 Message-ID: <504858F9.7070605@isdg.net> Date: Thu, 06 Sep 2012 04:04:09 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Arthur Thisell References: <1346842829.84355.YahooMailClassic@web125403.mail.ne1.yahoo.com> In-Reply-To: <1346842829.84355.YahooMailClassic@web125403.mail.ne1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] Received-SPF in the real world X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Sep 2012 08:04:38 -0000 Received-SPF is meant to for local consumption only. It can not be trusted outside the internal processing. IMO, keep in mind most people (end users) don't care about headers, only what the MUA displays and unless you request it (click a few things, if possible) you can't even see the headers. That said, we have several server-side only (p-code) scripting rules that reads the Received-SPF, more importantly we do not have information on 3rd party developers scripts, but we can't rule out their existence. Generally, if one make a presumption that someone isn't used and then you pull it, that is generally when you find out otherwise. -- HLS Arthur Thisell wrote: > Has anyone collected information on how Received-SPF is actually being used? > > Things like the mechanism production rule was most important back when SPF used to support unknown mechanisms. I'm not sure I've ever seen it used in practice. Could it just be removed as being unused? > > Yahoo creates a Received-SPF header field that doesn't follow RFC 4408 at all and I can't make sense of it. E.g.: > > Received-SPF: pass (domain of ietf.org designates 64.170.98.30 as permitted sender) > dCBhbGwgdGhlIGluZGl2aWR1YWwgbWVzc2FnZSBhdHRhY2htZW50cyB5b3Ug > d2lsbCBuZWVkIHRvIHVwZGF0ZSB5b3VyIGRpZ2VzdCBvcHRpb25zIGluIHlv > dXIgbGlzdCBzdWJzY3JpcHRpb24uIFRvIGRvIHNvLCBnbyB0byBodHRwczov > L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwZmJpcyBDbGljayB0 > aGUgJ1Vuc3Vic2NyaWJlIG9yIGVkaXQgb3B0aW9ucycgYnV0dAEwAQEBAQN0 > ZXh0L3BsYWluAwMxAgN0ZXh0L3BsYWluAwMxAgNtdWx0aXBhcnQvZGlnZXN0 > AwM3AgNtZXNzYWdlL3JmYzgyMgMDMwIDbWVzc2FnZS9yZmM4MjIDAzQCA3Rl > eHQvcGxhaW4DAzE- > > I'm not even sure how you could collect a good cross section of Received-SPF examples. Looking at individual implementations might be a good start, > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > From sm@elandsys.com Thu Sep 6 01:31:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BEB21F8567 for ; Thu, 6 Sep 2012 01:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNdZl5b6D6YL for ; Thu, 6 Sep 2012 01:31: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 8884921F856F for ; Thu, 6 Sep 2012 01:31:39 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.246]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q868VRJm024519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Sep 2012 01:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346920298; bh=k1Tuz7r9sw/KKuWjLxw/p3iTYWHsVGmVnVehMJWh6ts=; h=Date:To:From:Subject:Cc; b=AWnOUfL/+NfY/gNSgG5S3+g4xgf5NupnWpfpSfCny6WY7lpkJY/2OcmXA5F1ssX1j 9kFFa8nfsDS4IsSN2C6/YKH0X94kWvCJgineekpczQ3MLqUGZxKsxo58VAIQzyfLgw nNjGUAyBbr2S/sfCke0R64cki/yyddh0hzUYuxhA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346920298; i=@elandsys.com; bh=k1Tuz7r9sw/KKuWjLxw/p3iTYWHsVGmVnVehMJWh6ts=; h=Date:To:From:Subject:Cc; b=qgTSno5YJvI2kdkoFLkPE9gt9zsvUcj62sj2nYosGBmINRRPZNROtr+DMt05hzC9M EcuUIelTS311WaGmtHQu9Yxof6l8557NhlZm9GEKqbZnRu1Bc7LL2gnbh+GSx29siZ Xk/6d/+RVVZAdgkuTU+nHQxTBc75EihTCSiqfous= Message-Id: <6.2.5.6.2.20120906011230.0aa08ed8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 06 Sep 2012 01:17:12 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [spfbis] draft-ietf-spfbis-4408bis issue list X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Sep 2012 08:31:40 -0000 Hello, I updated the issue list [1] for draft-ietf-spfbis-4408bis. Please let me know if I missed any of the issues you raised or if it was filed incorrectly. Regards, S. Moonesamy 1. http://trac.tools.ietf.org/wg/spfbis/trac/report/1 From hsantos@isdg.net Thu Sep 6 02:07:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC4721F8468 for ; Thu, 6 Sep 2012 02:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.567 X-Spam-Level: X-Spam-Status: No, score=-101.567 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDtLzujsEzhM for ; Thu, 6 Sep 2012 02:07:44 -0700 (PDT) Received: from winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D896F21F8441 for ; Thu, 6 Sep 2012 02:07:43 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2710; t=1346922455; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=UpFtfVzd7dUrrMjHz3RiLxz5R0U=; b=wtNZm+1HYlcod1fDkJ9i 100SiV9XGIh6wORX/3MgXn8YZIiXsZuoLkEox9WGqyNQGV0J5urgJa/HjTJ8zmo/ 39j8yDQIVP11LMl1ancO1Tv0ZE0jspaDcAWoB9Ar6MyESfzp3jmbCXbtGg0LMxqB n/YN5O3SSCqHn38OsGYjKd8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 06 Sep 2012 05:07:35 -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 2944238593.132.5028; Thu, 06 Sep 2012 05:07:34 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2710; t=1346922239; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=3NX5PsB pN3jDUFAXOKZOj6JODLnzVJR1mq7HIw4rpw0=; b=Be3h/shPJ3E6GPympI1DL1R oAOsp0iipLyK6IaTqoeraxUemKtCth95AATSeQ+w5wHOmMDfGaQ4oGBr3pyHaXfS ErcCmOA5E3US0jYVlSX2lS426svKYJpHSDdxUqZTg6mvM4WIJguuBt4QnmnXT+cl zx7QikawqFSkw4rBFghQ= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 06 Sep 2012 05:03:59 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3543037880.9.6324; Thu, 06 Sep 2012 05:03:59 -0400 Message-ID: <504867D1.2050207@isdg.net> Date: Thu, 06 Sep 2012 05:07:29 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <2385202.ToyOPapQOP@scott-latitude-e6320> <504234EC.8000505@tana.it> <50447333.60102@tana.it> <50449DA1.6070206@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, "spf2@kitterman.com >> Scott Kitterman" , Alessandro Vesely Subject: Re: [spfbis] Suggestion: Remove A-R from 4408BIS X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 09:07:44 -0000 Murray S. Kucherawy wrote: > On Mon, Sep 3, 2012 at 5:08 AM, Hector Santos wrote: >> It seems there is too drama regarding A-R and trying to add it. It >> drastically alter scope of SPF with ACCEPT+MARK mode of receiver behavior, >> it created new security issues and conflicts of major opinion almost surely >> to raise WGLC issues. > > Since Received-SPF does effectively the same thing, adding references > to A-R is neither an alteration in scope nor "drastic". > > On the contrary, it would be prudent for the IESG to ask why we're > ignoring a message annotation that's already a proposed standard > specifically geared toward this kind of work. Failing to at least > acknowledge the existence of A-R would be suspect if I were the one > evaluating it. Thats all possible. But it does drastically alter the scope of SPF when A-R is considered. I can verify because we are going thru it now with the SPFBIS updating code reviews and I have new reservations about it until it can be completely be scoped out. Its not would not be PnP (plug and play) update I should note I fundamentally agree with you, and thus why I supported the A-R consideration but only as a migration with local processing semantics. I will always support single sourcing concepts such as this especially when similar applications are begun. In this case, DKIM/ADSP was officially added/completed into the production code and released few years ago. But SPF is a 5321 technology, not a payload technology like DKIM/ADSP. So one of the first thing you need to internally consider is the integration such as SPF now being the first time the A-R is added and now changes to the DKIM/ADSP code has to be done to make sure it aggregates it (i.e. append/prepend concepts with other transaction mail protocol stuff going on). Also, and extremely important IMO is issue #33. Products not currently designed around mark-on-fail and perhaps now wish to update with SPFBIS and now with the synergism behind DKIM/ADSP, add support for delayed reporting/rejections/filtering with Mark-On-Fail are in for a rude surprise - its not going to be very easy to do this. So as I stated, there new emphasis to add A-R does bring with it a new scope of considerations, such as issue 33 and just getting the integration right with other things. It is easily now because Received-SPF only has one specific purpose and applicability. No other method or technology deals with it. IMO, its not that simple of a replacement and I believe the IESG will take this engineering implementation issues into account. Its not a PnP suggestion to replace Received-SPF with A-R. -- HLS From superuser@gmail.com Thu Sep 6 07:13:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9551521F8661 for ; Thu, 6 Sep 2012 07:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02Xd+w88Pqwy for ; Thu, 6 Sep 2012 07:13:34 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEF121F8646 for ; Thu, 6 Sep 2012 07:13:34 -0700 (PDT) Received: by lbky2 with SMTP id y2so1334504lbk.31 for ; Thu, 06 Sep 2012 07:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CGLyUqgVGXnRa77a4078+ojEPHbDGhlw0ZVbanzZx2o=; b=CEqZeREmEcSbm2SP/6RuVystEBVX28L1Tp+oO0ytprGnz3yaIlf1oOa7fbtVkoqlHL M3HANt+dwfBzlB6ZQYFouGTOCTDzHR360SpiDVXCHZNPi5fmilNKhTcj4TYxKMnuFnZU hsddhSX/qMZPuZ75pqMcHBFsKSnnl2IUvKLoZ1rF+2KyYQ7MCCDsL7AKDSVn56KrC30V pIgR1uwI/1GEo9u1ajfcMi8Es4UC1LPrn40I1y7k0s5MOYYPTZ1ZSYc9iHqaECJND6+q 62jC4QTtgUldg8rtOXC41KyAjFHq4V/jq8MOSTU0bTU5ayip/8gGqZMPJwo0h/mGKWi+ LPNQ== MIME-Version: 1.0 Received: by 10.152.46.203 with SMTP id x11mr2016271lam.46.1346940813098; Thu, 06 Sep 2012 07:13:33 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Thu, 6 Sep 2012 07:13:32 -0700 (PDT) In-Reply-To: <504867D1.2050207@isdg.net> References: <2385202.ToyOPapQOP@scott-latitude-e6320> <504234EC.8000505@tana.it> <50447333.60102@tana.it> <50449DA1.6070206@isdg.net> <504867D1.2050207@isdg.net> Date: Thu, 6 Sep 2012 07:13:32 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, "spf2@kitterman.com >> Scott Kitterman" , Alessandro Vesely Subject: Re: [spfbis] Suggestion: Remove A-R from 4408BIS X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:13:35 -0000 On Thu, Sep 6, 2012 at 2:07 AM, Hector Santos wrote: > IMO, its not that simple of a replacement and I believe the IESG will take > this engineering implementation issues into account. Its not a PnP > suggestion to replace Received-SPF with A-R. There is nothing in the new Section 7 text that proposes replacing Received-SPF with A-R. A-R is being presented as an alternative. Implementers can use one or the other, or both, or neither, or something else entirely. The new Section 7 only says it's RECOMMENDED that you not choose the "neither" option, which is what it said all along. That means you, as someone who prefers Received-SPF, don't need to change a thing. -MSK From spf2@kitterman.com Thu Sep 6 07:16:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F7621F867C for ; Thu, 6 Sep 2012 07:16: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CefJzCqFQmEX for ; Thu, 6 Sep 2012 07:16:39 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 45CB521F8670 for ; Thu, 6 Sep 2012 07:16:39 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C744C20E4104; Thu, 6 Sep 2012 10:16:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346940998; bh=28dmvziu2eF5ptntrUb+3MP37OfS/3e2V2VccofJaA8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PCO3wQqVkG5t4la2lrHBMWwP8iKw7z1X+RLj51Sq0oVyjiL9e82MlDCmRQJhcRgth cDmew8nkg6VNssnDBDU7dBaZBJilqVDniBf7VNs8vYtkZqApr2KFOtcXPPbUaK2kbv pTyTUoJN/uvi2NAiLp45yMtBEXQficxoTzF35mnE= 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 A6D6120E40E8; Thu, 6 Sep 2012 10:16:38 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 06 Sep 2012 10:16:37 -0400 Message-ID: <1407990.TkgnLIfQPv@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <504867D1.2050207@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Suggestion: Remove A-R from 4408BIS X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:16:40 -0000 On Thursday, September 06, 2012 07:13:32 AM Murray S. Kucherawy wrote: > On Thu, Sep 6, 2012 at 2:07 AM, Hector Santos wrote: > > IMO, its not that simple of a replacement and I believe the IESG will take > > this engineering implementation issues into account. Its not a PnP > > suggestion to replace Received-SPF with A-R. > > There is nothing in the new Section 7 text that proposes replacing > Received-SPF with A-R. A-R is being presented as an alternative. > Implementers can use one or the other, or both, or neither, or > something else entirely. The new Section 7 only says it's RECOMMENDED > that you not choose the "neither" option, which is what it said all > along. That means you, as someone who prefers Received-SPF, don't > need to change a thing. That's correct. Also, since RFC 5451 exists and documents reporting SPF results in A-R, no matter what we do in 4408bis, it's there and implementers have to decide how to deal with it, if at all. Scott K From sm@elandsys.com Thu Sep 6 09:15:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C77921F86AA for ; Thu, 6 Sep 2012 09:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6okSi7XlnJ5 for ; Thu, 6 Sep 2012 09:15:46 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC5521F866D for ; Thu, 6 Sep 2012 09:15:46 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.124]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q86GFXH4026260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Sep 2012 09:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346948145; bh=Ms16Ub8u1NZbkMECb7BSNi69pcOBRxZ5gTTZaOaJFHw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=trQ23zuqCrmsLFYnFd4rsdOQ+XFnCy4DIGIHMhGD23yj9VwK01T2V/zjpb17kO8ij F0tiq1JO8lGY4aSf+1sUHiU507Q68cR1opoNBda10keL8ReTESSmvVOdr29p8rlLsX 214o2q9FpfQExaAIqY4kcUBGsuQZnBKWpvbpTWTQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346948145; i=@elandsys.com; bh=Ms16Ub8u1NZbkMECb7BSNi69pcOBRxZ5gTTZaOaJFHw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QWVbM1I4ul1qcN2/kadsO9FkTKRHTPDHDcm2BQm2cRVejFDolfSQsKPFYoMezANYP 17QTWPsVOyWR9X09XCct3eC9NXQ6X1XXNVY4YekFQe+MNVll/YDO3ylVq5o2p1OIb4 u/Ist5hLHPOP0x1PzA5VURdEWBnQQkFFOJvyrinM= Message-Id: <6.2.5.6.2.20120906091220.09fcf7a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 06 Sep 2012 09:14:37 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <1433326.JAlz6WYfAq@scott-latitude-e6320> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <3785358.KpgcBP5aSr@scott-latitude-e6320> <6.2.5.6.2.20120905140732.0b351ac0@resistor.net> <1433326.JAlz6WYfAq@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Sep 2012 16:15:47 -0000 Hi Scott, At 14:16 05-09-2012, Scott Kitterman wrote: >I think opening issues is useful. I've taken a first pass at it, >but no doubt >it needs more work. In terms of what I'm planning, I'm still planning on >waiting to hear back from you/Andrew on the reorganization you >directed before >I do more on the document. Given the way the discussion developed, we came to a different conclusion about Section 9, so we're not sure about moving it now. Could you please suggest a plan on how to rework Section 9? It would help Andrew and me, and the WG, to have a better view of the work? Thanks S. Moonesamy SPFBIS WG co-chair From hsantos@isdg.net Thu Sep 6 09:32:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A798521F84FE for ; Thu, 6 Sep 2012 09:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.579 X-Spam-Level: X-Spam-Status: No, score=-101.579 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duL2Iyfa3g60 for ; Thu, 6 Sep 2012 09:32:41 -0700 (PDT) Received: from pop3.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 04DA421F8498 for ; Thu, 6 Sep 2012 09:32:34 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2667; t=1346949150; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=5aP/+RrEo3LuuJyiSaZckU6oEpU=; b=qLYK5uSgdvnjoAxR4On8 Wd7MbrhhAHznYQtpKqgu5YdDD8yl2MKsmjQzjOcrvwA2iz9yLk9/qGHyh39XA7pl rLwzAMqegmGkh6nYtnV9AF/uYefGLRejEjXJyFifHeDtVlMKguWoSixzSJwh2yfr TQGWDz9VfQBL4OzQ+1n4YyM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 06 Sep 2012 12:32:30 -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 2970934109.132.3368; Thu, 06 Sep 2012 12:32:30 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2667; t=1346948935; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=3E1Qc+M Ovs0J5i9hv0IpW9Z8tutRYLz5RN1CurrAdFE=; b=1o6xPmyqOm3JXl30mZwBfG5 xpaD5gEA9ELujyIiASczyNnurViegly6UVr26srMmUrRd89d2wlVY82zdYgmqW99 AGet01khsbnE+Ucok+QfYJIboW6lileHOCD+hCUUTtwXeMuW1lkflKdUgy9DEi1d 5BZTXIm8uye+aIcmkFQc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Thu, 06 Sep 2012 12:28:55 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3569733614.9.5952; Thu, 06 Sep 2012 12:28:54 -0400 Message-ID: <5048D01B.6050108@isdg.net> Date: Thu, 06 Sep 2012 12:32:27 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <2385202.ToyOPapQOP@scott-latitude-e6320> <504234EC.8000505@tana.it> <50447333.60102@tana.it> <50449DA1.6070206@isdg.net> <504867D1.2050207@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Suggestion: Remove A-R from 4408BIS X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 16:32:44 -0000 Murray S. Kucherawy wrote: > On Thu, Sep 6, 2012 at 2:07 AM, Hector Santos wrote: >> IMO, its not that simple of a replacement and I believe the IESG will take >> this engineering implementation issues into account. Its not a PnP >> suggestion to replace Received-SPF with A-R. > > There is nothing in the new Section 7 text that proposes replacing > Received-SPF with A-R. A-R is being presented as an alternative. > Implementers can use one or the other, or both, or neither, or > something else entirely. The new Section 7 only says it's RECOMMENDED > that you not choose the "neither" option, which is what it said all > along. That means you, as someone who prefers Received-SPF, don't > need to change a thing. I have no issues with A-R support. As I had stated, from a SE standpoint, single sourcing is a very strong SE premise with us. We are a systems, apps level tools developer as well and its not just site deployment. SPF is part an of API for stock components and for operator and ISV programmability. I am pointing out what are some implementation issues which IMV are underestimated, however I believe as long the entire scope is reviewed then we can not minimize the impact of this SPFBIS "new enhancement" feature, help promote its usage and also provide equal weight to providing Mark-On-Fail operations rather than Reject-On-Failure. I am not convince that Reject-On-Fail is not a high mode of operation. It all depends on the site - does it serve the public user market or is it a private user enterprise? There are a few little things here and I should probably offer text to illustrate the implementation points. To outline some of the insights: - Adding both Received-SPF and A-R for maximum consumer support. - Disable Receiver-SPF by default with option to enable again. - Combining meta A-R SPF results with any current or pending meta A-R headers generation for a final single prepending to the stored message. - the main point is to avoid the propensity to create multiple A-R for the same hop. - Add/Change examples using "fail" results to others like softfail, etc to help illustrate and show where A-R can have an benefit with augmented aggregated A-R factors in an advanced MFA (Mail Filtering Agent). - Using "Fail" results for examples should include engineering insights the A-R result made not be possible to exist since the transaction can (and may) be rejected outright per section 2.5.4. - Insights towards the issue #33 security note when A-R fail results are recorded. The above is off the top of my head. -- HLS From spf2@kitterman.com Thu Sep 6 14:19:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1703221F86B5 for ; Thu, 6 Sep 2012 14:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzbRoZWyPHkJ for ; Thu, 6 Sep 2012 14:19:21 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4D35721F867C for ; Thu, 6 Sep 2012 14:19:21 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 530F320E4104; Thu, 6 Sep 2012 17:19:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346966360; bh=a01OYn1a65myCdc4sOj7/vV1JIbJV+3cTUwCBU7MsTA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=R0lu1oqJ09lvqWuGr4it13pV7DNB9jW9iuH7zENCJC+EXdllibGYP69CZO5Ls3YYp SW+9RpL9Yne+AOD42jSGWczHq1Y9DCVCDjHtxJ5o4e419kKHXDFtte6qMAPpMSZxy+ F69KjRhF4iwGZggBFwszKWJd6LbmaqJAai2u/nQg= 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 27F0A20E40E8; Thu, 6 Sep 2012 17:19:19 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 06 Sep 2012 17:19:19 -0400 Message-ID: <3279288.pgox3YqAvs@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120906091220.09fcf7a8@resistor.net> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <1433326.JAlz6WYfAq@scott-latitude-e6320> <6.2.5.6.2.20120906091220.09fcf7a8@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 06 Sep 2012 21:19:22 -0000 On Thursday, September 06, 2012 09:14:37 AM S Moonesamy wrote: > Hi Scott, > > At 14:16 05-09-2012, Scott Kitterman wrote: > >I think opening issues is useful. I've taken a first pass at it, > >but no doubt > >it needs more work. In terms of what I'm planning, I'm still planning on > >waiting to hear back from you/Andrew on the reorganization you > >directed before > >I do more on the document. > > Given the way the discussion developed, we came to a different > conclusion about Section 9, so we're not sure about moving it now. > > Could you please suggest a plan on how to rework Section 9? It would > help Andrew and me, and the WG, to have a better view of the work? Certainly. Tomorrow I'll try to put something together and wrap up the pending changes I have into a -07 draft for people. Scott K From sm@elandsys.com Thu Sep 6 16:10:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCC721E803D for ; Thu, 6 Sep 2012 16:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpkUXdxIQ+wR for ; Thu, 6 Sep 2012 16:10: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 0026E21E803A for ; Thu, 6 Sep 2012 16:10:36 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.124]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q86NAC2n012785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Sep 2012 16:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346973026; bh=DiSwYxCi3Z6oUqjahh6jCz275OMV+sXafuymybuxBKw=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=UkXtiYRlBWWol7cGaGWhEL6ZookencbXpj2jyZP0GbkUeT468Zsu0w8J26daBHFOa J50GhPgvbREhPinhw8ZSw/1ejmpOtGkrjAGyiIkVrCDLeSsA6Rb57WHY9uMMnSNDKI d1q6kHWSedp1SXA/kRBOBOtSNhDIt5Z6XvlQYM84= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346973026; i=@elandsys.com; bh=DiSwYxCi3Z6oUqjahh6jCz275OMV+sXafuymybuxBKw=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=DMloubF0jPtPRbm0BpxjtWWfEdX8Km8lxb6toE6fiBGJYGtdNEdbrTq+Fnlg165t4 q62cga9Of5k55HDc8SQ0JLsg/GgXHzGIpGuizgDYr4aBKjkVqTs7W6BHjW3H75ubX+ 4WNePis0LFMI0atgG6Qbi9KzlnicA9cCnnKfSRtw= Message-Id: <6.2.5.6.2.20120906152441.0aba38d0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 06 Sep 2012 15:45:09 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.0155a74c9ddcd749a44b179ced1fc4fc@tools.ietf.org> References: <064.0155a74c9ddcd749a44b179ced1fc4fc@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #51: Remove A-R from 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 23:10:37 -0000 At 00:59 06-09-2012, spfbis issue tracker wrote: >#51: Remove A-R from 4408bis > > Message posted by Hector Santos on 3 Sept 2012: > > SUGGESTION: Remove A-R from 4408BIS and all related changes due to it and > if we someone believes it is still useful for SPF, then write a I-D for > it, perhaps with a title > > Reporting SPF with Authentication-Results > > and this I-D can go into extensive concepts of not only how to write it, > but perhaps also how to combine it with other A-R marking for receiver > evaluations, etc. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02593.html This issue (#51) is related to Issue #10. I suggest reading Section 2.4.2 RFC 5451 as it may be relevant to the above suggestion. Feel free to comment, as usual, on this thread. The comments which have already been posted on the the other threads about this topic will also be taken into account. Regards, S. Moonesamy From sm@elandsys.com Thu Sep 6 16:10:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1305721E804E for ; Thu, 6 Sep 2012 16:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enXJ06gThp4H for ; Thu, 6 Sep 2012 16:10:47 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5125721E804D for ; Thu, 6 Sep 2012 16:10:47 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.124]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q86NAC2p012785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Sep 2012 16:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1346973038; bh=ZYZcXfmleI3wE/7xYOKvZ9VbEjH7ofSO5EBrZQPNs4o=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=YJqG493aRzx+BsgJYwkdXXJ5wGVBCqRPsK22JTuBe1kaH6CqfNNlvYFKpI2QxhrAo lgsd3JRiBtw3MJhKuCIUr67yeU1EqGtRPza+VGq6qiavxF0wdg9gHI2hof2R7UQQ2F Qzrr1+n8lwVAkm3wD0Xbm1lGltpg455t6e0drhXA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1346973038; i=@elandsys.com; bh=ZYZcXfmleI3wE/7xYOKvZ9VbEjH7ofSO5EBrZQPNs4o=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=yFCNVhRkOjdNSphg9RYO6S9fI7g9xWjao31wjtgu1k4RSSP/rnc/xZIfYVy4hQXuS brVj21TOZMIIhGRADYBKR6QY35VqONwB1DP2Hoq/3rUmXs8IZzhEEwK37CdIGQRU0Y tq7hIAHHzzjbJ3waGHJUbrC8JFOBw6ZbOIu7WSOM= Message-Id: <6.2.5.6.2.20120906154516.0aba3a18@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 06 Sep 2012 15:53:16 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.27d993b3cb7210e6425eb39657584b46@tools.ietf.org> References: <064.27d993b3cb7210e6425eb39657584b46@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #57: x-* fields in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 23:10:48 -0000 At 01:11 06-09-2012, spfbis issue tracker wrote: >#57: x-* fields in 4408bis > > Message posted by Stuart Gathman on 5 Sept 2012: > > My python milter production software on a dozen MTAs consumes Received- > SPF. It is very important for a main MTA getting mail forwarded from an MX > (the MX has to check SPF, of course). All the fields are used, plus a few > x-* fields I added (like x-bestguess). > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02615.html x-* fields was not raised as an issue. There is BCP 178 which deprecates the "X-" convention for newly defined parameters in application protocols, including new parameters for established protocols. Are any other implementations using "x-"? Regards, S. Moonesamy From spf2@kitterman.com Thu Sep 6 16:19:33 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C883B21F86B3 for ; Thu, 6 Sep 2012 16:19:33 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkE1BXs1LdtH for ; Thu, 6 Sep 2012 16:19:33 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2E55A21F86B0 for ; Thu, 6 Sep 2012 16:19:33 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 2876FD04061; Thu, 6 Sep 2012 18:19:32 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1346973572; bh=rVJ5EJQmfHCjBpocMG+4R0HusWEC1jAPrOMRtDCceUw=; h=References:In-Reply-To:Subject:From:Date:To:From; b=ir9jqwcehdPPxc3J+ll+2ThgBK+bTUe4BcihFMEYcU++x0s12Ak0qfSGSuQu4qcty VfOcdv47F3QfnbNBtcJrMOAzitoW8HuiBksIw/RnOtbCpYZa4oYM458QttKUTT7IMW cWWlhGhV6YeER/SnxDc+c9EOeXnG2IkcDTkY9Z0s= Received: from [IPV6:2600:1003:b009:c01e:3b89:f0da:500f:a108] (unknown [IPv6:2600:1003:b009:c01e:3b89:f0da:500f:a108]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 974EED04005; Thu, 6 Sep 2012 18:19:31 -0500 (CDT) References: <064.27d993b3cb7210e6425eb39657584b46@tools.ietf.org> <6.2.5.6.2.20120906154516.0aba3a18@elandnews.com> User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20120906154516.0aba3a18@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 06 Sep 2012 19:19:29 -0400 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #57: x-* fields in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 23:19:33 -0000 S Moonesamy wrote: >At 01:11 06-09-2012, spfbis issue tracker wrote: >>#57: x-* fields in 4408bis >> >> Message posted by Stuart Gathman on 5 Sept 2012: >> >> My python milter production software on a dozen MTAs consumes >Received- >> SPF. It is very important for a main MTA getting mail forwarded from >an MX >> (the MX has to check SPF, of course). All the fields are used, plus >a few >> x-* fields I added (like x-bestguess). >> >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02615.html > >x-* fields was not raised as an issue. There is BCP 178 which >deprecates the "X-" convention for newly defined parameters in >application protocols, including new parameters for established >protocols. Are any other implementations using "x-"? I removed the "X dash" before the initial working group draft based on based on that BCP. Since they are by definition non-standard, I don't think it's got any interoperability implications. Scott K From vesely@tana.it Fri Sep 7 00:48:32 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0AD21F871E for ; Fri, 7 Sep 2012 00:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.613 X-Spam-Level: X-Spam-Status: No, score=-4.613 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDTg9XlNnbw4 for ; Fri, 7 Sep 2012 00:48:31 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9A321F871D for ; Fri, 7 Sep 2012 00:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347004109; bh=I7pO96Oo5u32LAH+2QpQQ8XgNFGKd0Gf//z1wtNmoL0=; l=1460; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=e1pCD3etMjGIQY4gvP9pgfoIjiWGL2Y0jri3f7lA2et01wyruJHW4/O4+vwbb4YHF 7pjM57Wxf+SjrqxFQDR04OqR1+vJe1+StbiHrUQqNyWuuJ8cEjAB7HpeLkWQIXpnQn 7NoXw5UKPUOeYopq3foZYktSHo5D5DSLvTg2+PIY= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 07 Sep 2012 09:48:29 +0200 id 00000000005DC035.000000005049A6CD.00000EA7 Message-ID: <5049A6CC.4000209@tana.it> Date: Fri, 07 Sep 2012 09:48:28 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <2385202.ToyOPapQOP@scott-latitude-e6320> <504234EC.8000505@tana.it> <50447333.60102@tana.it> <50449DA1.6070206@isdg.net> <504867D1.2050207@isdg.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #51: Suggestion: Remove A-R from 4408BIS X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 07:48:32 -0000 On Thu 06/Sep/2012 16:13:32 +0200 Murray S. Kucherawy wrote: > > There is nothing in the new Section 7 text that proposes replacing > Received-SPF with A-R. A-R is being presented as an alternative. > Implementers can use one or the other, or both, or neither, or > something else entirely. +1, that is a clean, plain view. It supports all the implementation points that Hector illustrated. > The new Section 7 only says it's RECOMMENDED that you not choose > the "neither" option, which is what it said all along. That means > you, as someone who prefers Received-SPF, don't need to change a > thing. RFC 5451, Section 2.4.2 in particular, fully describes how to use A-R fields for SPF. Hence, issue #51 can be closed. The only one reason why 4408bis needs to mention A-R at all is the above normative point. That is, an implementation that sets A-R only can be said to follow that 4408bis recommendation. I propose the following clarification attempt, if it can be useful for -07: Implementations are expected to add either any of these header fields or both depending on the requirements of the downstream message processors that they support. Such choice could possibly depend also on the result itself, because reporting "none" is somewhat less interesting than reporting "pass" or "fail". Note that errors, as well as the negative results can also be reported to the publishing domain, according to [RFC6652]. From vesely@tana.it Fri Sep 7 00:59:12 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9914221F8703 for ; Fri, 7 Sep 2012 00:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.626 X-Spam-Level: X-Spam-Status: No, score=-4.626 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jrb5g7kLcQHI for ; Fri, 7 Sep 2012 00:59:12 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E0AFC21F86FC for ; Fri, 7 Sep 2012 00:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347004750; bh=wpFsflha+YnSEIO9+C1ecA0bYY8+LnaZ3wW9mUintew=; l=549; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Ye8B8AOgyWfEvKr65+8rp59Xq6Az8VLQFX8EiueEarIAbeJrsras+pyJBU0HZiRl+ 7XH65M2V17gQplwkOyZv2ezDTU4BCS/9w5jrf2ETNVus3Ii6KD6CQbmNwZqq47qAzl o3Ep72Aght1bjxfvv4NX87xA+Gh6sdmHXz+WNwP4= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 07 Sep 2012 09:59:10 +0200 id 00000000005DC035.000000005049A94E.00001138 Message-ID: <5049A94E.1000406@tana.it> Date: Fri, 07 Sep 2012 09:59:10 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1346770691.72124.YahooMailClassic@web125406.mail.ne1.yahoo.com> <50472F27.4080907@tana.it> In-Reply-To: <50472F27.4080907@tana.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion, X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 07:59:12 -0000 On Wed 05/Sep/2012 12:53:27 +0200 I wrote: > On Tue 04/Sep/2012 16:58:11 +0200 Arthur Thisell wrote: >> >> How many implementations trigger permerror when the get an >> invalid domain and how many just don't match? > > I tested Courier-MTA, and it returns a non-compliant "unknown" > result for those three cases. I'll ask on spf-discuss, it will > hopefully take less than a month or two... I got two responses, one for each possibility. Unless Scott has already written something to tackle this issue, I propose to leave it for -08. From sm@elandsys.com Fri Sep 7 03:33:56 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E4C21F879B for ; Fri, 7 Sep 2012 03:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6EXCpLEjIgf for ; Fri, 7 Sep 2012 03:33:55 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F79821F8798 for ; Fri, 7 Sep 2012 03:33:48 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.124]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q87AXZd4010750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Sep 2012 03:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347014027; bh=D0/1ZqYqPbrlgKIyUQoYLxE37qpuY7hCNfu4K3mC/rE=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=t91x01Cp89rmjjGjd5qG0uoQTJb+n93skNDh2q3m56Rp4EC0nhh/AwMZ5f1WPNIJc IBskTPaiwybJ/ErJ38glAYT+6v/6VGT/1v0ODaZPbRtjSYDjQouEEwAhrVHWgWXCn2 OwPxw1vYvOlJbPE0T308s3uNKWAtLCR2CLrpCrfA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347014027; i=@elandsys.com; bh=D0/1ZqYqPbrlgKIyUQoYLxE37qpuY7hCNfu4K3mC/rE=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=y8sO+KxIUK/xCZoFztdyFhl8rTxLj4QUA8nStCOl39XJkhvqBgZDaHg6aB1p+vdtj qc/NDkbB8qTM1DXGe8wKrXLlIpXF1yp9rNl1q/VlWEO6bY02p3nil590JZDhIVolIp ogAFkE6KTkRcD2/A3+pSZiHchU6F9FIooFBvb9T4= Message-Id: <6.2.5.6.2.20120907023043.0aad3700@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 07 Sep 2012 03:32:23 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <6.2.5.6.2.20120826203640.0c6400e8@resistor.net> References: <20120824173829.13742.qmail@joyce.lan> <5037E028.7090007@Commerco.Net> <503818B2.4020102@isdg.net> <6.2.5.6.2.20120826203640.0c6400e8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 10:33:56 -0000 Hello, I'll comment as an individual. The example of the security issue at http://www.ietf.org/mail-archive/web/spfbis/current/msg02246.html shows a Received-SPF: header field with a SPF result of "fail". It was mentioned that "its recommended it (the message) should not be part of the normal pop3 mail pick up". The outcome is similar to rejecting the message. A message was posted at http://www.ietf.org/mail-archive/web/spfbis/current/msg02331.html about the question of rejecting a message on SPF Fail. I read another message ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02370.html ) about marking a message on SPF Fail. In my individual opinion, this issue is about not delivering a message that fails SPF evaluation to the intended mailbox. It can be argued that such a message might contain hostile content. Is that attack even in scope for the protocol? Regards, S. Moonesamy From spf2@kitterman.com Fri Sep 7 06:17:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E47A21F8491 for ; Fri, 7 Sep 2012 06:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4KxYSpjRfUD for ; Fri, 7 Sep 2012 06:17:45 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 76FE321F85E7 for ; Fri, 7 Sep 2012 06:17:45 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E0AD720E40E8; Fri, 7 Sep 2012 09:17:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347023863; bh=MjSVctEqj/nHXbersxlkvT7SNP5LxW6ptZ2tTvLUeFM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Iaf130qtcBq13pb/cUA7o/TwQg3tesfEAvgG1iwZubroYFrJq5a6mgkpQL0jgsu8F 2BHH2J9/NpA+rzjf6QWP8nO6HX1siOIiW/1uNK9cQooEjuwtvJDFLVSlgB95gdLq8e R3DJSf4jCs9FGHVHtL17DMjay7ZCsG871a0542Eo= 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 AD0C620E40CF; Fri, 7 Sep 2012 09:17:43 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 07 Sep 2012 09:17:42 -0400 Message-ID: <3120108.JgnBUtWjyy@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120907023043.0aad3700@resistor.net> References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120826203640.0c6400e8@resistor.net> <6.2.5.6.2.20120907023043.0aad3700@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 13:17:46 -0000 On Friday, September 07, 2012 03:32:23 AM S Moonesamy wrote: > Hello, > > I'll comment as an individual. The example of the security issue at > http://www.ietf.org/mail-archive/web/spfbis/current/msg02246.html > shows a Received-SPF: header field with a SPF result of "fail". It > was mentioned that "its recommended it (the message) should not be > part of the normal pop3 mail pick up". The outcome is similar to > rejecting the message. > > A message was posted at > http://www.ietf.org/mail-archive/web/spfbis/current/msg02331.html > about the question of rejecting a message on SPF Fail. I read > another message ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02370.html ) > about marking a message on SPF Fail. In my individual opinion, this > issue is about not delivering a message that fails SPF evaluation to > the intended mailbox. It can be argued that such a message might > contain hostile content. Is that attack even in scope for the protocol? I think it is, but only barely. It is probably worth mentioning that if you deliver messages that were not authorized by the domain owner, some of them may be malicious. That doesn't make it unreasonable to do so as there are also quite legitimate ways messages can end up coming from not authorized sources. It's a trade off that designers of receiving systems have to make, so while I think we could mention it, I don't think it's in the scope of the protocol to solve it. Scott K From spf2@kitterman.com Fri Sep 7 06:19:07 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B1821E8051 for ; Fri, 7 Sep 2012 06:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1EfmjWt4TgB for ; Fri, 7 Sep 2012 06:19:07 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3185A21E804D for ; Fri, 7 Sep 2012 06:19:07 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BB65520E40E8; Fri, 7 Sep 2012 09:19:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347023946; bh=CjBsynRF29bdedxE+e2kVvlp9dO+2RUkt89ZPb1PEa8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=AI9izubdyHG/6+rzrAoJG8uOCTy2RUOtBDrG+Uz4qqAHOcSXKLgBa0ciCNxt9R74M VT6cTgoH4VI6p808n9jUJZEobDdHVlx2pSmTgtf8i8SXUFf/JDjyoHYjV1J8FhVKss xewrmfSbRcmCTt/BfQRlY2LMl4gTgCJN+mAD4FY8= 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 ABAE620E40CF; Fri, 7 Sep 2012 09:19:06 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 07 Sep 2012 09:19:06 -0400 Message-ID: <7244062.y5BSsrTJgr@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <5049A94E.1000406@tana.it> References: <1346770691.72124.YahooMailClassic@web125406.mail.ne1.yahoo.com> <50472F27.4080907@tana.it> <5049A94E.1000406@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion, X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 13:19:07 -0000 On Friday, September 07, 2012 09:59:10 AM Alessandro Vesely wrote: > On Wed 05/Sep/2012 12:53:27 +0200 I wrote: > > On Tue 04/Sep/2012 16:58:11 +0200 Arthur Thisell wrote: > >> How many implementations trigger permerror when the get an > >> invalid domain and how many just don't match? > > > > I tested Courier-MTA, and it returns a non-compliant "unknown" > > result for those three cases. I'll ask on spf-discuss, it will > > hopefully take less than a month or two... > > I got two responses, one for each possibility. Unless Scott has > already written something to tackle this issue, I propose to leave it > for -08. I don't think we've reached a consensus on this. BTW, unknown is the pre- MARID equivalent of permerror, so you should put courier-mta in that camp. Scott K From dotzero@gmail.com Fri Sep 7 06:36:50 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D2721E8051 for ; Fri, 7 Sep 2012 06:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qM6sN5X1mCIk for ; Fri, 7 Sep 2012 06:36:49 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B24B21E8050 for ; Fri, 7 Sep 2012 06:36:49 -0700 (PDT) Received: by ieak13 with SMTP id k13so5589084iea.31 for ; Fri, 07 Sep 2012 06:36:49 -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=rkY4KwILGOhG+geFr6Vb4tt5ydX6qyZ4gliT9e1DGmU=; b=H8/KU5bvuU7YulSIBhZ9Q8SNaqcz38DrKxzjsl9lGgAruz4YoG/eKzDGIgiEeKf26R cz0+JT7eYWuwc0p6Z644GKxLAUyur9JCr1yuNXGVNfNQD6zhbDlsp+HjhnixzBrMGzMV c0QcccuvgmWXxZIfHuAUsJEc1P+SOHRCi29JPVDospMlTMwm45RaKwR1p+J9bGJXe4ww WyP+yRCwR2VaujagkyfB0TyMWrowlspVmSm4FqPNjWn7ih6ZIgN857tGoETXcHmytSsV WyIZsAmF2eAVxhmrv/uI9Xs3I6HEqPpJDFX9gTHIl8We4vAQEsrRN47Ks39m0cr1r4XJ gojA== MIME-Version: 1.0 Received: by 10.50.194.167 with SMTP id hx7mr8824432igc.24.1347025009040; Fri, 07 Sep 2012 06:36:49 -0700 (PDT) Received: by 10.64.36.200 with HTTP; Fri, 7 Sep 2012 06:36:48 -0700 (PDT) In-Reply-To: <3120108.JgnBUtWjyy@scott-latitude-e6320> References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120826203640.0c6400e8@resistor.net> <6.2.5.6.2.20120907023043.0aad3700@resistor.net> <3120108.JgnBUtWjyy@scott-latitude-e6320> Date: Fri, 7 Sep 2012 09:36:48 -0400 Message-ID: From: Dotzero To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 13:36:50 -0000 On Fri, Sep 7, 2012 at 9:17 AM, Scott Kitterman wrote: > On Friday, September 07, 2012 03:32:23 AM S Moonesamy wrote: >> Hello, >> >> I'll comment as an individual. The example of the security issue at >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02246.html >> shows a Received-SPF: header field with a SPF result of "fail". It >> was mentioned that "its recommended it (the message) should not be >> part of the normal pop3 mail pick up". The outcome is similar to >> rejecting the message. >> >> A message was posted at >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02331.html >> about the question of rejecting a message on SPF Fail. I read >> another message ( >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02370.html ) >> about marking a message on SPF Fail. In my individual opinion, this >> issue is about not delivering a message that fails SPF evaluation to >> the intended mailbox. It can be argued that such a message might >> contain hostile content. Is that attack even in scope for the protocol? > > I think it is, but only barely. It is probably worth mentioning that if you > deliver messages that were not authorized by the domain owner, some of them > may be malicious. That doesn't make it unreasonable to do so as there are > also quite legitimate ways messages can end up coming from not authorized > sources. It's a trade off that designers of receiving systems have to make, so > while I think we could mention it, I don't think it's in the scope of the > protocol to solve it. > > Scott K +1 I go with the folks that have previously indicated that SPF is an MTA to MTA protocol. 4408 provided two things a receiver could do on fail (reject or mark). That was the extent of telling receivers what to do. We should be very careful about introducing new meanings in the bis document. Mike From johnl@iecc.com Fri Sep 7 09:29:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D0D21E8043 for ; Fri, 7 Sep 2012 09:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MK6E4oejOvRQ for ; Fri, 7 Sep 2012 09:29:26 -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 AD5B921E8034 for ; Fri, 7 Sep 2012 09:29:25 -0700 (PDT) Received: (qmail 1629 invoked from network); 7 Sep 2012 16:29:25 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Sep 2012 16:29:25 -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:vbr-info; s=504a20b4.xn--i8sz2z.k1208; i=johnl@user.iecc.com; bh=vhPxmYkADwmWpxUeGtNwYvHS50oNolsYgtybnvW4ltE=; b=LbwAp3PMd7185ujWxntkTxZdVM8MNa+GBoMaIJNvzRXu2z+KWKi5MsBDsB7oCkPiMTA9ehBqzzUOSYDD8Xoe34BMYYvIMvkZlbdc08OVVkIiW4eQlCHi518TPX8rmVGZ2EyxmqF78AVGPkDGByuMkjFiavt5o2OAlFlQ4EwvKpU= 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:vbr-info; s=504a20b4.xn--i8sz2z.k1208; olt=johnl@user.iecc.com; bh=vhPxmYkADwmWpxUeGtNwYvHS50oNolsYgtybnvW4ltE=; b=h/elMTb0LgLsytIyQfAzzIZhf6ksU93dveX11s8XfyWTmwzNlKmnQTxi/m9ZEClB781wQ+4dkVpUCWO8lPRLIiZSDKj2WTikbmpOcMgwf9UxNRXeZ30EFHclU7LD6g7vw/XfhT1ULKkM6Cep/Ru5o0cdmsH+wpXonS59XlpWZJE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 7 Sep 2012 16:28:14 -0000 Message-ID: <20120907162814.65119.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <6.2.5.6.2.20120906152441.0aba38d0@elandnews.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: sm+ietf@elandsys.com Subject: Re: [spfbis] #51: Remove A-R from 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 16:29:27 -0000 >> SUGGESTION: Remove A-R from 4408BIS No, it works fine. We may want to do an update to 5451 to add more fields to 5451, but that's a separate issue and not one we can or should address here. R's, John From internet-drafts@ietf.org Fri Sep 7 11:36:15 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5192821E80AE; Fri, 7 Sep 2012 11:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAQTT7Mf7JhD; Fri, 7 Sep 2012 11:36:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D892421E80B7; Fri, 7 Sep 2012 11:36:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120907183614.16385.67352.idtracker@ietfa.amsl.com> Date: Fri, 07 Sep 2012 11:36:14 -0700 Cc: spfbis@ietf.org Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-07.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 18:36:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SPF Update Working Group of the IETF. Title : Sender Policy Framework (SPF) for Authorizing Use of Dom= ains in Email, Version 1 Author(s) : Scott Kitterman Filename : draft-ietf-spfbis-4408bis-07.txt Pages : 66 Date : 2012-09-07 Abstract: Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby an ADMD can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization. This document obsoletes RFC4408. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spfbis-4408bis-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From vesely@tana.it Fri Sep 7 11:36:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB0521E80D3 for ; Fri, 7 Sep 2012 11:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.636 X-Spam-Level: X-Spam-Status: No, score=-4.636 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+Q0Za5X9Lh5 for ; Fri, 7 Sep 2012 11:36:48 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id BF75C21E80D2 for ; Fri, 7 Sep 2012 11:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347043006; bh=tKNB0T0JjqBOq2jWTW32Hf3BJOoYdGiziBk126ZeVls=; l=484; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=UTw9pLdqYt0a0PKODHXz+kNarCNkuUWHxJAqjJhl+g0Uu99hIWPO6f+zQzfV2MsfG Xx5M/3mnmVzeHsV8aylewsX41Lmn5YkDEjsCbGbg5zMiuX8BtWm2lbYvdcy8mRx3V6 /PGbwSnp2HlTwBXWUrhXoVSCjq0ZHXjWV7WHBi3k= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 07 Sep 2012 20:36:46 +0200 id 00000000005DC039.00000000504A3EBE.00003039 Message-ID: <504A3EBD.70808@tana.it> Date: Fri, 07 Sep 2012 20:36:45 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1346770691.72124.YahooMailClassic@web125406.mail.ne1.yahoo.com> <50472F27.4080907@tana.it> <5049A94E.1000406@tana.it> <7244062.y5BSsrTJgr@scott-latitude-e6320> In-Reply-To: <7244062.y5BSsrTJgr@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion, X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 18:36:49 -0000 On Fri 07/Sep/2012 15:19:06 +0200 Scott Kitterman wrote: > On Friday, September 07, 2012 09:59:10 AM I wrote: > >> Unless Scott has already written something to tackle this issue, >> I propose to leave it for -08. > > I don't think we've reached a consensus on this. So do I. However, I reckon you have accumulated quite some local changes, so I think it's better to get -07 out and checked. Perhaps, it will be easier to make our mind up about catch #22 at that point... From hsantos@isdg.net Fri Sep 7 11:37:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB2521E80D5 for ; Fri, 7 Sep 2012 11:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.589 X-Spam-Level: X-Spam-Status: No, score=-101.589 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81PuVhzimBbM for ; Fri, 7 Sep 2012 11:37:41 -0700 (PDT) Received: from mail.catinthebox.net (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9424721E80D0 for ; Fri, 7 Sep 2012 11:37:40 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1453; t=1347043058; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=GuZSIJEJWFylVSRAmpvd/DWmfbE=; b=lReVr0UiU0zFahYTtjvu HVUp80ERhlK8JZL6CXNYVwIEDKcUzViwkXN+dlsEIYWJ1j4cbcUJ5xIucPS+Q+Hs N86B9dBHE/iCpWiUemKkQqdmceZkrF2CJzH7TOw2Jm29i8d7dyvw6JJVdwCUUh9F JXtqbPR8syJtFuQmUsa9Sdk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 07 Sep 2012 14:37:38 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3064840034.1051.2712; Fri, 07 Sep 2012 14:37:37 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1453; t=1347042838; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=7JRuWZ5 mjD57qf9U1nIG8/KTM9kedX5lfq+7k5s9lsk=; b=v24i3wMx4QYbeGoNraQCaen /fyaEAlEjgYyaozHhRDT0ECMYnmpFC+JoV/618QEQiEayw/2BOk4YbTRAGVB6hYS i5Dts2OQ+FhhBtGHQGQTKHk+rMuhSWkTFtl2E+xPfwwtcNpw4tYniqPL2SEnFWFY I0ewlbR21z2FBdmfRz48= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 07 Sep 2012 14:33:58 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3663635880.9.360; Fri, 07 Sep 2012 14:33:57 -0400 Message-ID: <504A3EF9.5050206@isdg.net> Date: Fri, 07 Sep 2012 14:37:45 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <20120907162814.65119.qmail@joyce.lan> In-Reply-To: <20120907162814.65119.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #51: Remove A-R from 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 18:37:44 -0000 John Levine wrote: >>> SUGGESTION: Remove A-R from 4408BIS > > No, it works fine. We may want to do an update to 5451 to add more > fields to 5451, but that's a separate issue and not one we can or > should address here. I don't think its a separate issue because one major reason to consider it is to work towards to the automation of MFA (Mail Filtering Agents) or "message evaluators". I agree it would be fine if BIS had one simple sentence: "Add Received-SPF and if you like, think about A-R [RFC5451] support." and then cross fingers that its updated to include the SPF tracing required with no kludges as its seems to be been done now using comments to get the ip recorded. My point is that there is should be some standard track, registered field names idea of what the A-R fields are going to be that would allow for a PnP (Plug and Play) replacement of Recieved-SPF. Right now, its not ready for automated MFA consumers unless we all standardized around a current implementator format. Who do we choose? I am going through this dilemma right now with looking at A-R support and its all deja-vu again when A-R also did not have all the information necessary for ADSP (to cover all possible scenarios) and we did what was necessary to do that did not quite match RFC5451. Same will happen with A-R. Is it ready or not for SPF support? YES, it can be for Human Reporting. NO for Automated MFAs. -- HLS From spf2@kitterman.com Fri Sep 7 11:38:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2601421E80D0 for ; Fri, 7 Sep 2012 11:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuspZYLca0Or for ; Fri, 7 Sep 2012 11:38:20 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 673FD21E808F for ; Fri, 7 Sep 2012 11:38:20 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8CAA920E40E8; Fri, 7 Sep 2012 14:38:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347043099; bh=Kg7SVouNBZDlvcCXPg3k0mOILWF5MzVmqsJDD9IKKfQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=NNQuB5GgpKv2YD/jj1WdIU/IrHLb64H1cEW8VIf3bXw6m25pL1cLNS2aRo24PlMtU j8JgWBVwaDBa7NwwRjqCMPdC+ZOFjkssG4Q9kq4yMEg4vXpmk3KVLBFXIBzNq9e/mY 2nNWzG6NTWZmeu9GZB0OUgUt5A5b4gLBlwi3Hfo4= 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 6671020E40CF; Fri, 7 Sep 2012 14:38:19 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 07 Sep 2012 14:38:18 -0400 Message-ID: <2539182.kL1LVZzZlH@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-30-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <504A3EBD.70808@tana.it> References: <1346770691.72124.YahooMailClassic@web125406.mail.ne1.yahoo.com> <7244062.y5BSsrTJgr@scott-latitude-e6320> <504A3EBD.70808@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #22: RFC 4408: Section 2.5.7 PermError on invalid domains after macro expansion, X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 18:38:21 -0000 On Friday, September 07, 2012 08:36:45 PM Alessandro Vesely wrote: > On Fri 07/Sep/2012 15:19:06 +0200 Scott Kitterman wrote: > > On Friday, September 07, 2012 09:59:10 AM I wrote: > >> Unless Scott has already written something to tackle this issue, > >> I propose to leave it for -08. > > > > I don't think we've reached a consensus on this. > > So do I. However, I reckon you have accumulated quite some local > changes, so I think it's better to get -07 out and checked. Perhaps, > it will be easier to make our mind up about catch #22 at that point... Interesting timing for your suggestion. Scott K From spf2@kitterman.com Fri Sep 7 11:39:59 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4217921E80C0 for ; Fri, 7 Sep 2012 11:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYKS2+vmZgDw for ; Fri, 7 Sep 2012 11:39:58 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B9F8221F84B9 for ; Fri, 7 Sep 2012 11:39:58 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4FFB120E40E8; Fri, 7 Sep 2012 14:39:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347043198; bh=EyDi84aaVKMUbl1T59TwYIhd/mT//tfMBW3gBQFz9Jg=; h=From:To:Subject:Date:From; b=qGc48QpLAzpkaXqDN/ig+Xvki5FcbnOk2OA0QwIkkjt6J6FnSTV/X9htnB0y5f3uK sfnsoO6gb5e+qXapV4MzrTqJwfUv6jYLGK/FMGhOEDvmz1EvQAhlonio8iRf6J++pO 0bven5SuJTzfjwzLqoSEYPwnaqIFwAqSwLo6sldc= 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 2486F20E40CF; Fri, 7 Sep 2012 14:39:58 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 07 Sep 2012 14:39:57 -0400 Message-ID: <2774071.JaK7SANm63@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-30-generic-pae; KDE/4.8.4; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-07.txt X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 18:39:59 -0000 This does not address all the comments people have made over the last week, but I thought that with the cumulative change already in the hopper, it was better to hit send than wait until I had time to finish going through things (probably not today). Scott K ---------- Forwarded Message ---------- Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-07.txt Date: Friday, September 07, 2012, 11:36:14 AM From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: spfbis@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SPF Update Working Group of the IETF. Title : Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 Author(s) : Scott Kitterman Filename : draft-ietf-spfbis-4408bis-07.txt Pages : 66 Date : 2012-09-07 Abstract: Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby an ADMD can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization. This document obsoletes RFC4408. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-spfbis-4408bis-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ----------------------------------------- From sm@elandsys.com Fri Sep 7 12:17:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1530A21E80C0 for ; Fri, 7 Sep 2012 12:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzHpM6oX-SrU for ; Fri, 7 Sep 2012 12:17:43 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFE421E808F for ; Fri, 7 Sep 2012 12:17:43 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.66]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q87JHVRN010291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Sep 2012 12:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347045462; bh=DETJHltkC7fQKXi9h+AtEXvylCracVU0Vzae2yfHf70=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=SrfLr/PG8OfRprv6uppeuXawBTPw8B3M4YV7RKnder3mgSyZELnis4Zuh5D18SdFV czgf3m6pfD5izwihBhpidEWPGdi7wuC8JZJG3GEo+mmKdEqS0ya4Uf3bTCKdNJZIJz 6IDuBOlFatvW+NC4mxcLrNtUFg3P1xD/XpwBl7yg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347045462; i=@elandsys.com; bh=DETJHltkC7fQKXi9h+AtEXvylCracVU0Vzae2yfHf70=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=RP0fqXWidpV0vf5V+LJZiWbqMTtLAZfaP0HKDy9Jl55DR6no3jlISShTAuEiAI8+t ODa/xzCssI1GvHL9cdDc1plggMtgC20t62tC/QE9BiHgmxYoaX48mLgtlYNz5Ceafg xdM7UuoeKGLu/kMAmXa/YbdLBcKH6PiD9ra42Mhs= Message-Id: <6.2.5.6.2.20120907114928.0ae86e48@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 07 Sep 2012 12:12:32 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <504A3EF9.5050206@isdg.net> References: <20120907162814.65119.qmail@joyce.lan> <504A3EF9.5050206@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #51: Remove A-R from 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 19:17:44 -0000 At 11:37 07-09-2012, Hector Santos wrote: >My point is that there is should be some standard track, registered >field names idea of what the A-R fields are going to be that would >allow for a PnP (Plug and Play) replacement of Recieved-SPF. Right >now, its not ready for automated MFA consumers unless we all >standardized around a current implementator format. Who do we choose? Any work on RFC 5451 is not within the scope of SPFBIS in my individual opinion. Alessandro Vesely proposed some text ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02641.html ) and suggested closing Issue #51. I'll suggest the following as a way for the draft to progress towards WGLC. I'll close this issue. The WG can discussion about the text for Section 7 on the thread about that section. Regards, S. Moonesamy From superuser@gmail.com Fri Sep 7 13:03:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789BB21E808F for ; Fri, 7 Sep 2012 13:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvNyvvLo0TYw for ; Fri, 7 Sep 2012 13:03:45 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B4A8E21E805F for ; Fri, 7 Sep 2012 13:03:44 -0700 (PDT) Received: by lbky2 with SMTP id y2so71861lbk.31 for ; Fri, 07 Sep 2012 13:03:43 -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=5jQVOpagFD50Vdi3pbrTdM9ZUGGlKkDz4IbifY7jpTc=; b=byTixce6oj4hC8OEva7soeGadokRMGxGM0sbWR2GBjDGQe78s54t0z/zL6IMywondl nXMh65mHY+RW2xD1sBaHqPIHeYL0EJ21KRiSS9dGgBktrCceBs8D0ffrj0WvGOn+lyVU /WaHUbgJmOaR0aJvtH73+8FZyBiL6zWZ8wIOpZfnd3xBrXEA7EbOxI2GLv5YZ1LfFrxB eD6Q7WA1Ub+Ht0bHnkMXZ1pLKqm9NgzijtjV4/qt3BpQ4Ki3VCnRkWjr9GOKeEt1ryxN JF/pQdU5KzSQm3/zoaSm2ID3821dFM9PKzRM7Dae8ru9U7XggJkG69HEGEI3mgUZx2c1 WgzQ== MIME-Version: 1.0 Received: by 10.112.88.73 with SMTP id be9mr2548368lbb.72.1347048223603; Fri, 07 Sep 2012 13:03:43 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Fri, 7 Sep 2012 13:03:43 -0700 (PDT) In-Reply-To: <3120108.JgnBUtWjyy@scott-latitude-e6320> References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120826203640.0c6400e8@resistor.net> <6.2.5.6.2.20120907023043.0aad3700@resistor.net> <3120108.JgnBUtWjyy@scott-latitude-e6320> Date: Fri, 7 Sep 2012 13:03:43 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 20:03:45 -0000 On Fri, Sep 7, 2012 at 6:17 AM, Scott Kitterman wrote: > I think it is, but only barely. It is probably worth mentioning that if you > deliver messages that were not authorized by the domain owner, some of them > may be malicious. That doesn't make it unreasonable to do so as there are > also quite legitimate ways messages can end up coming from not authorized > sources. It's a trade off that designers of receiving systems have to make, so > while I think we could mention it, I don't think it's in the scope of the > protocol to solve it. I agree. I'm not even sure what one could say; legitimate messages can arrive without SPF authorization, and illegitimate messages can arrive with SPF authorization. The logical reduction of that is "Some mail is bad", or more usefully, "You might receive bad mail irrespective of authorization." We might say simply that and be done with it. -MSK From spf2@kitterman.com Fri Sep 7 13:18:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FE821F8653 for ; Fri, 7 Sep 2012 13:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cER-3iafCHNh for ; Fri, 7 Sep 2012 13:18:39 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 05D7721F864D for ; Fri, 7 Sep 2012 13:18:39 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7B19720E40E8; Fri, 7 Sep 2012 16:18:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347049118; bh=+htTiVhHGIxTxRrsppaImBdPkjA9b+BZi2tnUFZLOWQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WaFSVzTNTw16EUXhFA7Tb++3PUoYeiUn4dIPqOnVerMA2dow21AATYOQ8alyGLRXr uCxG6BLzYmKsJpKKzF+McQix/uwJMn1M7ZwYrEjNl/geQok8Dr30Ib/BSUu2NS+Dv9 GS2n7Kv2KktsYcf07iwwAB20IOUtIvQf+kU11UL4= 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 4BC2C20E40CF; Fri, 7 Sep 2012 16:18:37 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 07 Sep 2012 16:18:37 -0400 Message-ID: <1663351.5sAq1NzcAL@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-30-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120906091220.09fcf7a8@resistor.net> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <1433326.JAlz6WYfAq@scott-latitude-e6320> <6.2.5.6.2.20120906091220.09fcf7a8@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 20:18:40 -0000 On Thursday, September 06, 2012 09:14:37 AM S Moonesamy wrote: > Hi Scott, > > At 14:16 05-09-2012, Scott Kitterman wrote: > >I think opening issues is useful. I've taken a first pass at it, > >but no doubt > >it needs more work. In terms of what I'm planning, I'm still planning on > >waiting to hear back from you/Andrew on the reorganization you > >directed before > >I do more on the document. > > Given the way the discussion developed, we came to a different > conclusion about Section 9, so we're not sure about moving it now. > > Could you please suggest a plan on how to rework Section 9? It would > help Andrew and me, and the WG, to have a better view of the work? I see three possible fates for Section 9: 1. Keep it in 4408bis. This is the most direct logical extension of RFC 4408 and in keeping with what I view as the spirit of our charter (minimal diff to get out of experimental and onto the standards track). It is certainly consistent with the charter. It does however bring a fair amount of "How to" type of text into a standards track RFC that is better suited to a BCP. This may make IETF last call and IESG approval harder and risks getting directed to rework it later. 2. Remove all of Section 9 and move it to a new document. As it stands, this would require a normative reference from 4408bis to the new document. This new document would be outside our WG charter. I do not think it would be appropriate to make our chartered deliverable dependent of work no one is chartered to do, so I believe this would require rechartering to add the new deliverable. This would result in two documents that supersede RFC 4408 which I think complicates things for document readers, but may be easier to get approved (I still find the DKIM documents confusing and between the original splits and the updates find myself looking through several of them to find the correct version of what I'm looking for). 3. Split out some/most of Section 9 into a new document, but leave enough information in 44408bis (either in Section 9 or in other parts of the document) that the reference to the new draft for the split can reasonably be informational. In this case, we should still recharter, but it retains enough information in one document (4408bis) for most implementers to develop code to support the protocol. The split draft then is mostly deployment advice that's for a different audience and clearly BCP material. Regardless of which choice the WG coalesces around, the choices are about arrangement of the text, not particularly about the text itself. As has been mentioned, I took an initial pass at recasting some of the text in modern email arch terms, but it needs more work (and there's at least one issue open about this). I would prefer to work on getting the text ~right independent of where the text lives, so while we can discuss where it ends up, let's continue to focus on content for now. Once the content is ~done, where it goes will be easy enough to figure out I suspect. Scott K From sm@elandsys.com Fri Sep 7 13:53:06 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2FE21E80AF for ; Fri, 7 Sep 2012 13:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMs6WIv3HrT4 for ; Fri, 7 Sep 2012 13:53:05 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDE521F8535 for ; Fri, 7 Sep 2012 13:53:05 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.66]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q87Kqqt0025238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Sep 2012 13:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347051184; bh=8gmQr/1ozICHCxA9kwNKq1I4+f/wHHZjx7wzMV+Xnt8=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=RWqXn1nF5pbVqOnqoepyNa+gTkb1Lu3TITSNT6Ru8Qmxx4lq+VrMqGFCECAqeyL4C HQDXwUKdSUGgodJKdFOJfi3IFSZrjHOPnHo1UymbDmbp6XQO4DOM+LmKMwlhVb7Khe 8JqWNRxky4WD09AZK3FbJhQ1re3hPPH5CfkbpF5k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347051184; i=@elandsys.com; bh=8gmQr/1ozICHCxA9kwNKq1I4+f/wHHZjx7wzMV+Xnt8=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=A2fubv1pe8JG5ljyLC24QS2Wpwe0hlnEZN2K0p8KIYs4WYABZgLVNGqgtSrycu3/B v5+K3xE+HJsSxJtcVOieDGrHnhz3QaYbfud8y91ApJnqlM6zO7DTdcLq9fR1ciWnPu DyXI89Xi/CZjeeKxDgOc5He7lfkdwB4jUR2+SP+E= Message-Id: <6.2.5.6.2.20120907133424.0922c9c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 07 Sep 2012 13:52:39 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120826203640.0c6400e8@resistor.net> <6.2.5.6.2.20120907023043.0aad3700@resistor.net> <3120108.JgnBUtWjyy@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 20:53:06 -0000 At 13:03 07-09-2012, Murray S. Kucherawy wrote: >arrive with SPF authorization. The logical reduction of that is "Some >mail is bad", or more usefully, "You might receive bad mail >irrespective of authorization." We might say simply that and be done >with it. The above idea is worth exploring. It would help to put this issue to rest. The WG could adopt the idea as a way forward if there is agreement. Regards, S. Moonesamy From spf2@kitterman.com Fri Sep 7 14:05:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A226221F8672 for ; Fri, 7 Sep 2012 14:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dH51wISBSKiy for ; Fri, 7 Sep 2012 14:05:37 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EFF1A21F8679 for ; Fri, 7 Sep 2012 14:05:36 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2233720E40E8; Fri, 7 Sep 2012 17:05:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347051936; bh=xI8L0YvovFPTNGYra91s2xWYfTm5NoXokZ1Vz935fBU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=F6Slw2FIo8akdcg6qnDGRgUFgZp2zPpRK1Tw+B/wFU4wExHthhcZ4fgKiohLF93bf jXO4sGcmML0czLSv3jhRihvu4Cn2OMwqovMHMBm/Wvr/Hg+I0c260Hx4XW3R1fabex 6SzkonccrGgfqhdDwaAIt1VU+7mTfH0jb3+M3bSs= 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 F11B920E40CF; Fri, 7 Sep 2012 17:05:35 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 07 Sep 2012 17:05:35 -0400 Message-ID: <2154218.4qxcVGrrDH@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-30-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120907133424.0922c9c8@resistor.net> References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120907133424.0922c9c8@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 21:05:37 -0000 On Friday, September 07, 2012 01:52:39 PM S Moonesamy wrote: > At 13:03 07-09-2012, Murray S. Kucherawy wrote: > >arrive with SPF authorization. The logical reduction of that is "Some > >mail is bad", or more usefully, "You might receive bad mail > >irrespective of authorization." We might say simply that and be done > >with it. > > The above idea is worth exploring. It would help to put this issue > to rest. The WG could adopt the idea as a way forward if there is > agreement. I'm fine with it, but .... There is a subtlety that while the above is true, there is definitely a differentiation of risk between the two. For "bad" domains, authorized or not, the mail is likely to be "bad". For "good" domains, not authorized mail is substantially more likely to be "bad" than authorized domains. Unfortunately I no longer have access to the data set I used to establish this to my satisfaction (and it was private in any case), so I can't prove the assertion. I think that if we can get some flavor of differentiation in there, it will be sufficient, but I'm not sure how to do it without opening Pandora's box. Scott K From sm@elandsys.com Fri Sep 7 15:01:13 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57BE21E80BC for ; Fri, 7 Sep 2012 15:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0I3uzAiI+4rz for ; Fri, 7 Sep 2012 15:01:13 -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 2871D21E80AF for ; Fri, 7 Sep 2012 15:01:12 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.66]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q87M0w71000964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2012 15:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347055271; bh=AeNnJSarnIRB+kgOu10936e1BQKC1rILwP25+yaqxz4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=atTV6768/rrGV4TAZBdo5eRXc5Vs2n3rw1lcL5teT/hdhE8WAlX9Ny1FyNGcDUfPN /4pz3sphFnwGdFJY1pOs5MKBV/r8YnntfIBw6DIzBBR3RqVweFh5CR2Zst9/y+b6mM QsLFxRSwlt13N2A3vzOwQ/zN64jTICBtDGtAH/kk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347055271; i=@elandsys.com; bh=AeNnJSarnIRB+kgOu10936e1BQKC1rILwP25+yaqxz4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=TxzPaEwo7lA54iDPpaRT2cmnsqWeL3nF8jPr2gAz8Wa0Dx1Yuj4Zj38DUAn7s3lnN 1JZ0riU841zzq19TnTzBYiGWiKMtOAlj+9KB0DwdouWG2WiZKVbM8uA8STqj4oiJM7 Njj0kDVlvNAmlLRkUkoZg+eOpqaSifWBhELB4Cb0= Message-Id: <6.2.5.6.2.20120907143113.092316a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 07 Sep 2012 15:00:23 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <1663351.5sAq1NzcAL@scott-latitude-e6320> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <1433326.JAlz6WYfAq@scott-latitude-e6320> <6.2.5.6.2.20120906091220.09fcf7a8@resistor.net> <1663351.5sAq1NzcAL@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 22:01:13 -0000 Hi Scott, I'll comment as an individual to explore the alternatives. I haven't discussed the matter with Andrew yet. Some of the decisions would be up to the Area Director. At 13:18 07-09-2012, Scott Kitterman wrote: >I see three possible fates for Section 9: > >1. Keep it in 4408bis. This is the most direct logical extension >of RFC 4408 >and in keeping with what I view as the spirit of our charter (minimal diff to [snip] >may make IETF last call and IESG approval harder and risks getting >directed to >rework it later. Yes. >2. Remove all of Section 9 and move it to a new document. As it >stands, this >would require a normative reference from 4408bis to the new document. This There is a mention in Section 9 of RFC 4408 that the section is non-normative. Why would there have to be a normative reference? >new document would be outside our WG charter. I do not think it would be >appropriate to make our chartered deliverable dependent of work no one is >chartered to do, so I believe this would require rechartering to add the new >deliverable. This would result in two documents that supersede RFC >4408 which Rechartering would be up to the Area Director. By the way, there can only be one document that obsoletes RFC 4408. >I think complicates things for document readers, but may be easier to get >approved (I still find the DKIM documents confusing and between the original >splits and the updates find myself looking through several of them >to find the >correct version of what I'm looking for). Ok. >3. Split out some/most of Section 9 into a new document, but leave enough >information in 44408bis (either in Section 9 or in other parts of the >document) that the reference to the new draft for the split can reasonably be >informational. In this case, we should still recharter, but it >retains enough >information in one document (4408bis) for most implementers to >develop code to >support the protocol. The split draft then is mostly deployment >advice that's >for a different audience and clearly BCP material. If I understood correctly, the question is about what deployment advice to have (which parts to keep) in draft-ietf-spfbis-4408bis. Could you please suggest which parts are important for implementers to develop code to support the protocol? >Regardless of which choice the WG coalesces around, the choices are about >arrangement of the text, not particularly about the text itself. As has been >mentioned, I took an initial pass at recasting some of the text in modern >email arch terms, but it needs more work (and there's at least one issue open >about this). I would prefer to work on getting the text ~right >independent of >where the text lives, so while we can discuss where it ends up, >let's continue >to focus on content for now. Once the content is ~done, where it >goes will be >easy enough to figure out I suspect. Thanks for explaining this. Regards, S. Moonesamy (speaking for myself) From hsantos@isdg.net Fri Sep 7 15:09:53 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE9D21E80CB for ; Fri, 7 Sep 2012 15:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.336 X-Spam-Level: X-Spam-Status: No, score=-101.336 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_46=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZp8S+ya4Ttb for ; Fri, 7 Sep 2012 15:09:52 -0700 (PDT) Received: from groups.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 18F9621E80AF for ; Fri, 7 Sep 2012 15:09:51 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1871; t=1347055788; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=eT5HskNumEUYK81xg6OPaVyFRi8=; b=VFmAfzdHPixNX+lH4DCZ K9E4dmRwFU3bxZJdR1SCpsGQb8ypVJG4RUYk4aIoMEXvOKlEeaI3LBSlolkMElXL RD+UNc1kCu3kQFWLi102ekUN9mHe+WaKQP9Eq/qSVUWShVMaEmXs7OhVeXQUH/5/ h4F/OMEBpwVA4z3mB3c7ZGU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 07 Sep 2012 18:09:48 -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 3077570386.1051.4800; Fri, 07 Sep 2012 18:09:48 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1871; t=1347055569; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=R7xI6pQ oBmsvMO2myzSlTN93QrRIev+DzmdFpyJ7iYA=; b=E7a8wmZb0qoJBOivsK+Mghz Uvfd7C/Xxtq9voTMO/ybs6zTVMRhVUWpjS0pWAjBwetmg5Nz639oGkOCQpm9oQIl 0xX/6WRi/UfqmJ6F447xg9ZnC6zhdMxSG8f3kkbWGt6Ql6gyeGYO2akT2HW1Bpw1 nF1fzNoiQBUzQ+VPReiQ= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 07 Sep 2012 18:06:09 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3676367864.9.6852; Fri, 07 Sep 2012 18:06:09 -0400 Message-ID: <504A70B9.9050404@isdg.net> Date: Fri, 07 Sep 2012 18:10:01 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dotzero References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120826203640.0c6400e8@resistor.net> <6.2.5.6.2.20120907023043.0aad3700@resistor.net> <3120108.JgnBUtWjyy@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, "spfbis-chairs@tools.ietf.org" , Scott Kitterman Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 22:09:53 -0000 Dotzero wrote: > 4408 provided two things a receiver could do on fail > (reject or mark). That was the extent of telling receivers what to do. > We should be very careful about introducing new meanings in the bis > document. There is no new meaning. Issue #33 is basically stating mark-on-fail MUST|SHOULD be semantically equivalent to a REJECT-ON-FAIL from a security and functional standpoint. It would be an obvious security leak otherwise. Also consider the following: Issue #33 also provides non-normative insight for backend operators to take precautions. This was carefully worded with the hope of providing a compromise and also targeted at two audiences: 1) Early SPF 2003 adopters who used original 2003 SPF specifications with RFC2119 normative languages for a REJECT-ON-FAIL [1][2][3] Fail (-): the message does not meet a domain's definition of legitimacy. MTAs MAY reject the message using a permanent failure reply code. (Code 550 is RECOMMENDED. See [RFC2821] section 7.1.) The MARID production with RFC4408 only relaxed it to appears the IETF adoption process among the mail community who typically have concerns with strong languages towards mail rejection concepts. Early adopters would not be changing their operations. Some may have added logic to mark-on-fail, but it would incomprehensible to believe they would just accept and mark it without separating the mail. 2) New developers working off 4408bis with stronger A-R reporting emphasis having no rejection features. They MUST be made aware of their security issues in this higher focus Mark-on-Fail mode of operation. [1] http://tools.ietf.org/html/draft-mengwong-spf-00 [2] http://tools.ietf.org/html/draft-mengwong-spf-01 [3] http://www.openspf.org/svn/project/specs/drafts/draft-mengwong-spf.02.9.4.txt -- HLS From hsantos@isdg.net Fri Sep 7 15:30:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E456C21F8513 for ; Fri, 7 Sep 2012 15:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.602 X-Spam-Level: X-Spam-Status: No, score=-101.602 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7ZVTWicPSgp for ; Fri, 7 Sep 2012 15:30:52 -0700 (PDT) Received: from groups.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 02EEB21F8505 for ; Fri, 7 Sep 2012 15:30:51 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3178; t=1347057048; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Rco60jE0+VnSTzu5/hIkscWDIqs=; b=XOb+r5VlUuXDRb91KChc jYZ1WHHmaAeesexQ4ceLx+MikIU21KVdihHt/dgQqVs7FT+81wJ17jaRrbT/U3Aa zuhVhv9okyCKnupDHadhU4Uh0Uwrd1gDEHQU79QW4qhxTf3lkALuBXfsKEvP2U73 i4jx5EYr9atrLHtyyK9OeTw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 07 Sep 2012 18:30:48 -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 3078830749.1051.3272; Fri, 07 Sep 2012 18:30:48 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3178; t=1347056829; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=gU+l2la okn2R6y5CMUQ5x2ScjAQns90N1qjfnHspSrg=; b=aXiWSLE/1UiflqnSe4CGBbL 0MKC62BChsdOHpmHCKEo1U0hLmmX/u+mlodq0pUbK4GzMAFO4iZ7RV7XVku/1e+y 0ZL5d8NxZaNoaOAjENpDRkPBJNIPssf8/95+5MgDYvbiSonSIfzOJ8ntuUALJ6HS D/Puh0qUCmrDMVPp8DK4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 07 Sep 2012 18:27:09 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3677627567.9.2068; Fri, 07 Sep 2012 18:27:08 -0400 Message-ID: <504A75A5.9020005@isdg.net> Date: Fri, 07 Sep 2012 18:31:01 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120826203640.0c6400e8@resistor.net> <6.2.5.6.2.20120907023043.0aad3700@resistor.net> <3120108.JgnBUtWjyy@scott-latitude-e6320> <6.2.5.6.2.20120907133424.0922c9c8@resistor.net> In-Reply-To: <6.2.5.6.2.20120907133424.0922c9c8@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 22:30:53 -0000 Please take into account that there were many early pre-4408 early adopters that following the RFC2119-like compliancy language such as the one in section 3 [1] -------------------- 3. SPF Record Evaluation An SPF client evaluates an SPF record and produces one of seven results: None: The domain does not publish SPF data. Neutral (?): The SPF client MUST proceed as if a domain did not publish SPF data. This result occurs if the domain explicitly specifies a "?" value, or if processing "falls off the end" of the SPF record. Pass (+): the message meets the publishing domain's definition of legitimacy. MTAs proceed to apply local policy and MAY accept or reject the message accordingly. Fail (-): the message does not meet a domain's definition of legitimacy. MTAs MAY reject the message using a permanent failure reply code. (Code 550 is RECOMMENDED. See [RFC2821] section 7.1.) Softfail (~): the message does not meet a domain's strict definition of legitimacy, but the domain cannot confidently state that the message is a forgery. MTAs SHOULD accept the message but MAY subject it to a higher transaction cost, deeper scrutiny, or an unfavourable score. There are two error conditions, one temporary and one permanent. Error: indicates an error during lookup; an MTA SHOULD reject the message using a transient failure code, such as 450. Unknown: indicates incomplete processing: an MTA MUST proceed as if a domain did not publish SPF data. When SPF-aware SMTP receivers accept a message, they SHOULD prepend a Received-SPF header. See section 6. SPF clients MUST use the algorithm described in this section or its functional equivalent. If an SPF client encounters a syntax error in an SPF record, it must terminate processing and return a result of "unknown". -------------------- Please keep in mind that RFC4408 did not really alter much for early adopters, sure, they fine tune many of the features, added new limits, etc, but RFC4408 was really meant to be compatible with the existing early adoption and the work in 4408BIS "SHOULD NOT" dismiss the original spirit and intent of what the -ALL policy provided domains and receivers - a deterministic, powerful, near zero false positive method of SPOOF protection. Lets not promote the concept that SPF receivers SHOULD NOT give the domain publishers the benefit of all doubt when it comes to the -ALL policy. [1] http://tools.ietf.org/html/draft-mengwong-spf-01 Moonesamy wrote: > At 13:03 07-09-2012, Murray S. Kucherawy wrote: >> arrive with SPF authorization. The logical reduction of that is "Some >> mail is bad", or more usefully, "You might receive bad mail >> irrespective of authorization." We might say simply that and be done >> with it. > > The above idea is worth exploring. It would help to put this issue to > rest. The WG could adopt the idea as a way forward if there is agreement. > > Regards, > S. Moonesamy > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From superuser@gmail.com Fri Sep 7 15:36:33 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E28B21F85A3 for ; Fri, 7 Sep 2012 15:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QupauQSbkqL5 for ; Fri, 7 Sep 2012 15:36:32 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F13FD21F8599 for ; Fri, 7 Sep 2012 15:36:31 -0700 (PDT) Received: by lbky2 with SMTP id y2so138551lbk.31 for ; Fri, 07 Sep 2012 15:36:29 -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=GWf7TKrOT2ElzgSPScGQhYjLXkQDUQnOogtmFbm5tMc=; b=DFHlZlGaczDkHwk54qT8XkY3Ya2uLuopLbXp3sX4I47PiWmqeVWs0qMeDVzY8zUyZo WauCFFqtFPQSdlLpaBq/EfjsXDgcp6kEDoqbT3IFdUz0BE3le7z1p12Fru51OFcGwTBY RBENutLOw/zkvjvgrv2LtQXKkAuDkgcbLzx570WFQYZClDSMVACW+lhn09Z4G3jRvejd FsqXgRcYuqR3imIGD6qno86hUXm8/FfF01xqbk3JZIIGj6xfQF7GtHivAIz9fMXeF6Cb jE2q5QbiPbMk72kmK5d9GFhi1Qkem0Jed/sQ2eW9xnm0wAfvsr0wVtlBxFj9r20Yjfwv XdOQ== MIME-Version: 1.0 Received: by 10.112.30.34 with SMTP id p2mr2633611lbh.85.1347057389346; Fri, 07 Sep 2012 15:36:29 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Fri, 7 Sep 2012 15:36:29 -0700 (PDT) In-Reply-To: <2154218.4qxcVGrrDH@scott-latitude-e6320> References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120907133424.0922c9c8@resistor.net> <2154218.4qxcVGrrDH@scott-latitude-e6320> Date: Fri, 7 Sep 2012 15:36:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 22:36:33 -0000 On Fri, Sep 7, 2012 at 2:05 PM, Scott Kitterman wrote: > I'm fine with it, but .... There is a subtlety that while the above is true, > there is definitely a differentiation of risk between the two. For "bad" > domains, authorized or not, the mail is likely to be "bad". For "good" > domains, not authorized mail is substantially more likely to be "bad" than > authorized domains. Unfortunately I no longer have access to the data set I > used to establish this to my satisfaction (and it was private in any case), so > I can't prove the assertion. > > I think that if we can get some flavor of differentiation in there, it will be > sufficient, but I'm not sure how to do it without opening Pandora's box. The problem I think is that SPF doesn't have a self-contained notion of what's good and what's bad. That ties to reputation in some form, whether it's a local whitelist, a DNSBL, or a full-blown reputation service of some kind. If we can make that clear, then the kind of thing you're talking about is a bit more reachable from here. I don't know where this might land, but in the interest of being brief: Operators that choose to deliver mail for which SPF produces a "fail" result need to understand that they are admitting content that is explicitly not authorized by the purported sender. While there are known failure modes that can be considered "false negatives"
, the choice to admit those messages can expose end users to harm. This is especially true for domains belonging to known good actors that are typically well-behaved; unauthorized mail from those sources might well be subjected to much higher skepticism and content analysis. SPF does not, however, include the capacity for identifying good actors from bad ones; this is the purview of reputation systems in their various forms, and is out of scope for this specification. ? -MSK From superuser@gmail.com Fri Sep 7 15:43:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B1B21F85B8 for ; Fri, 7 Sep 2012 15:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1HS3xDPxq4Y for ; Fri, 7 Sep 2012 15:43:50 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 68BFF21F85B4 for ; Fri, 7 Sep 2012 15:43:49 -0700 (PDT) Received: by lbky2 with SMTP id y2so141052lbk.31 for ; Fri, 07 Sep 2012 15:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i+tVx9+MZcCOCLwIA6QFmZNrKgswAQhBcimTZ7n3BPo=; b=IFEJyYspKG2p6o1xn4jCeX+jNMPyvS0TL09UZMuZNt1OWOAq2Wwfeoz1M1foReGS2v +dfPqZ2hDtg6E33az7rjZCzbwkknmCsEJ8XmlTK44K3DpT3nbuDxhbKfVlOHN78E2eMO VEcwSp15URcgOnqbSuPYAcfdM9dXP+kPAQxDgcE2TTeiOR2ftchpX2U3Ta7JnFfxqt6E nMpPnmPXeEMt06FiZhsnJTeoshPNSjqL1avD3bU4IuESLofLwhwLNv0Fwpt8d7/9mluH u7zCDNQJBY13wfTRk7vEg4s+JqZ+dDMYxctxEPWwN2eIN61OurhzG7nmjfSVHxS9Puu3 FuZw== MIME-Version: 1.0 Received: by 10.152.102.137 with SMTP id fo9mr6526031lab.35.1347057828538; Fri, 07 Sep 2012 15:43:48 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Fri, 7 Sep 2012 15:43:48 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120907143113.092316a8@resistor.net> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <1433326.JAlz6WYfAq@scott-latitude-e6320> <6.2.5.6.2.20120906091220.09fcf7a8@resistor.net> <1663351.5sAq1NzcAL@scott-latitude-e6320> <6.2.5.6.2.20120907143113.092316a8@resistor.net> Date: Fri, 7 Sep 2012 15:43:48 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 22:43:53 -0000 On Fri, Sep 7, 2012 at 3:00 PM, S Moonesamy wrote: > Rechartering would be up to the Area Director. By the way, there can only > be one document that obsoletes RFC 4408. I don't think this requires a rechartering, but only a change in milestones, since ultimately the aggregate output is the same. But really that's between the AD and the co-chairs. >> Regardless of which choice the WG coalesces around, the choices are about >> arrangement of the text, not particularly about the text itself. As has >> been >> mentioned, I took an initial pass at recasting some of the text in modern >> email arch terms, but it needs more work (and there's at least one issue >> open >> about this). I would prefer to work on getting the text ~right >> independent of >> where the text lives, so while we can discuss where it ends up, let's >> continue >> to focus on content for now. Once the content is ~done, where it goes >> will be >> easy enough to figure out I suspect. > > Thanks for explaining this. +1. I'm hoping to do a higher-level pass over -07 very soon, more focused on the arrangement of the material and IETF procedural questions rather than techincal stuff. I'll do that ASAP. -MSK From spf2@kitterman.com Fri Sep 7 15:48:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A9221F85EF for ; Fri, 7 Sep 2012 15:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElZgxXWyFBAr for ; Fri, 7 Sep 2012 15:48:51 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 28B5121F85E6 for ; Fri, 7 Sep 2012 15:48:50 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1788220E40E8; Fri, 7 Sep 2012 18:48:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347058130; bh=iBnftKK7WWNoqUG6EjMST6CDUt9ndaAwqPG9UvCbJ5E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=h4pqEGkqUdEv3eYDKr0qB3ecBstw9ufqu0suov3InzqzQDBgnJa0ohpiN5hCgwbAw UHtCjRgnA19QpeK5H88+Xy6X6/Nn11f/HHwiPLGEZf4IHf17seyk04OoYoIQ2kt298 2IAOcJ+mGiu3j/ozQ4sMosIo17OXltj8fG7NcNyc= Received: from scott-latitude-e6320.localnet (126.sub-70-192-196.myvzw.com [70.192.196.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id CE64920E40CF; Fri, 7 Sep 2012 18:48:49 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 07 Sep 2012 18:48:48 -0400 Message-ID: <2899277.pkbUc12ucI@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-30-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120907143113.092316a8@resistor.net> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <1663351.5sAq1NzcAL@scott-latitude-e6320> <6.2.5.6.2.20120907143113.092316a8@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 22:48:52 -0000 On Friday, September 07, 2012 03:00:23 PM S Moonesamy wrote: > Hi Scott, > > I'll comment as an individual to explore the alternatives. I haven't > discussed the matter with Andrew yet. Some of the decisions would be > up to the Area Director. > > At 13:18 07-09-2012, Scott Kitterman wrote: > >I see three possible fates for Section 9: > > > >1. Keep it in 4408bis. This is the most direct logical extension > >of RFC 4408 > >and in keeping with what I view as the spirit of our charter (minimal diff > >to > [snip] > > >may make IETF last call and IESG approval harder and risks getting > >directed to > >rework it later. > > Yes. > > >2. Remove all of Section 9 and move it to a new document. As it > >stands, this > >would require a normative reference from 4408bis to the new document. This > > There is a mention in Section 9 of RFC 4408 that the section is > non-normative. Why would there have to be a normative reference? As we've recently discussed, just because text is non-normative, that does not equate to it being removable in the spec. The example that most immediately comes to mind is that in the definition of fail, we say receiver actions based on fail are a matter of local policy. The only place we currently define what we mean by local policy is in section 9. While there is no normative guidance in Section 9 that affect RFC 2119 type implementation decisions, I don't think it's possible for implementers to properly execute SPF without some understanding of at least some of the text in Section 9. > >new document would be outside our WG charter. I do not think it would be > >appropriate to make our chartered deliverable dependent of work no one is > >chartered to do, so I believe this would require rechartering to add the > >new deliverable. This would result in two documents that supersede RFC > >4408 which > > Rechartering would be up to the Area Director. By the way, there can > only be one document that obsoletes RFC 4408. OK. Since if we do split, 4408bis would reference the new document in some manner, I think that's not an issue. > >I think complicates things for document readers, but may be easier to get > >approved (I still find the DKIM documents confusing and between the > >original splits and the updates find myself looking through several of > >them to find the > >correct version of what I'm looking for). > > Ok. > > >3. Split out some/most of Section 9 into a new document, but leave enough > >information in 44408bis (either in Section 9 or in other parts of the > >document) that the reference to the new draft for the split can reasonably > >be informational. In this case, we should still recharter, but it > >retains enough > >information in one document (4408bis) for most implementers to > >develop code to > >support the protocol. The split draft then is mostly deployment > >advice that's > >for a different audience and clearly BCP material. > > If I understood correctly, the question is about what deployment > advice to have (which parts to keep) in > draft-ietf-spfbis-4408bis. Could you please suggest which parts are > important for implementers to develop code to support the protocol? See above for one example. I haven't done a complete analysis. I think it can wait until we're doing working through the issues. > >Regardless of which choice the WG coalesces around, the choices are about > >arrangement of the text, not particularly about the text itself. As has > >been mentioned, I took an initial pass at recasting some of the text in > >modern email arch terms, but it needs more work (and there's at least one > >issue open about this). I would prefer to work on getting the text ~right > >independent of > >where the text lives, so while we can discuss where it ends up, > >let's continue > >to focus on content for now. Once the content is ~done, where it > >goes will be > >easy enough to figure out I suspect. > > Thanks for explaining this. You're welcome. Scott K From spf2@kitterman.com Fri Sep 7 15:50:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A6921F85EF for ; Fri, 7 Sep 2012 15:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKsUk+Vq1XaM for ; Fri, 7 Sep 2012 15:50:46 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 165FC21F85E6 for ; Fri, 7 Sep 2012 15:50:45 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7900420E40E8; Fri, 7 Sep 2012 18:50:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347058244; bh=bhmbytM0/uSxrfvLun8zA1xZ0ElYk7HvAkLlVi5WqG4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LHQRHxpRWso2AHahHoAZg8t+82eAu13b/qDKMQASylWfiPtgFObYzrevJOWSrqAUi jN5blHWazs3XTKvDasgzOd3t3dOVeZivD1JCW7B2KSnBZo2f2U6Xh8fg1Ss61iH6+H gGbf5T49+I/Z4QWCYd/nDghszwvg9/laPfit51d0= Received: from scott-latitude-e6320.localnet (126.sub-70-192-196.myvzw.com [70.192.196.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4AA2920E40CF; Fri, 7 Sep 2012 18:50:43 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 07 Sep 2012 18:50:42 -0400 Message-ID: <31329313.WyRFAVA2nW@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-30-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <20120824173829.13742.qmail@joyce.lan> <2154218.4qxcVGrrDH@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 22:50:47 -0000 On Friday, September 07, 2012 03:36:29 PM Murray S. Kucherawy wrote: > On Fri, Sep 7, 2012 at 2:05 PM, Scott Kitterman wrote: > > I'm fine with it, but .... There is a subtlety that while the above is > > true, there is definitely a differentiation of risk between the two. For > > "bad" domains, authorized or not, the mail is likely to be "bad". For > > "good" domains, not authorized mail is substantially more likely to be > > "bad" than authorized domains. Unfortunately I no longer have access to > > the data set I used to establish this to my satisfaction (and it was > > private in any case), so I can't prove the assertion. > > > > I think that if we can get some flavor of differentiation in there, it > > will be sufficient, but I'm not sure how to do it without opening > > Pandora's box. > The problem I think is that SPF doesn't have a self-contained notion > of what's good and what's bad. That ties to reputation in some form, > whether it's a local whitelist, a DNSBL, or a full-blown reputation > service of some kind. If we can make that clear, then the kind of > thing you're talking about is a bit more reachable from here. > > I don't know where this might land, but in the interest of being brief: > > Operators that choose to deliver mail for which SPF produces a "fail" > result need to understand that they are admitting content that is > explicitly not authorized by the purported sender. While there are > known failure modes that can be considered "false negatives"
references here>, the choice to admit those messages can expose end > users to harm. This is especially true for domains belonging to known > good actors that are typically well-behaved; unauthorized mail from > those sources might well be subjected to much higher skepticism and > content analysis. > > SPF does not, however, include the capacity for identifying good > actors from bad ones; this is the purview of reputation systems in > their various forms, and is out of scope for this specification. Seems like a reasonable basis for discussion. Unless someone has better ideas, I'll add that in and close the issue. Scott K From sm@elandsys.com Fri Sep 7 16:22:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B9B21E8047 for ; Fri, 7 Sep 2012 16:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjjKkruYhjNS for ; Fri, 7 Sep 2012 16:22:17 -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 B20CC21E8044 for ; Fri, 7 Sep 2012 16:22:13 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.66]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q87NM02N000535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2012 16:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347060132; bh=HTcUHEhkaUIrMtw8B7t2ArbKilwzNtM39ccDaLxIBf4=; h=Date:To:From:Subject:Cc; b=vt2wefcxOf3FcHNBuUWvzmM9xOnq0vjZAzZIVVImIKbkklukv+R8vGzUK7NqvbEii zzf1yN3h5hpZyvvxfTqIvvnN42wTcxk5UJFh6Am/75Ml/o3YZ9gBeaj2+5p0ktrBMG xzHCsnq9IqlUqOJQ9xjtMwphNKUS1mMX6YYat1oE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347060132; i=@elandsys.com; bh=HTcUHEhkaUIrMtw8B7t2ArbKilwzNtM39ccDaLxIBf4=; h=Date:To:From:Subject:Cc; b=IupRusA90NTC5kyWVKOQGfajjmLPXiwdHdo4rpQxLQPBu6aVk4EPMElDVcjNsFCk9 z9utRI6ZsgAPDeWRkcffB1tM3bnC0QjiIe57zL5CmPHfyCTT5SfKfBq2yJ2vdBzNnD xl71vdI0a+zUre9BhkeXoi/z1ECt9LO2hLP8GQNA= Message-Id: <6.2.5.6.2.20120907150642.0aad3d58@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 07 Sep 2012 15:20:49 -0700 To: Scott Kitterman From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: [spfbis] Extensions to SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 23:22:17 -0000 Hi Scott, Section 1.1 of draft-ietf-spfbis-4408bis-07 has the following sentence: "This updated specification is intended to clarify identified ambiguities in [RFC4408], resolve techincal issues identified in post-RFC 4408 deplyment experience, and document widely deployed extensions to SPF that have been developed since [RFC4408] was published." The SPFBIS charter mentions that specifically out-of-scope for the working group: * Extensions to the SPF protocols. Discussion of extensions to the SPF protocols or removal of existing features shall only be discussed after completion of current charter items in anticipation of rechartering the working group. In the sentence from draft-ietf-spfbis-4408bis-07, there is "document widely deployed extensions to SPF that have been developed since [RFC4408] was published". That does not seem in line with what is in in the charter. Regards, S. Moonesamy From sm@elandsys.com Fri Sep 7 16:22:19 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B0A21E80E3 for ; Fri, 7 Sep 2012 16:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yh-jDBzTLWqL for ; Fri, 7 Sep 2012 16:22:19 -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 1471B21E80E2 for ; Fri, 7 Sep 2012 16:22:19 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.66]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q87NM02P000535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2012 16:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347060137; bh=ZB5hnKmxjWlbK4YfNKYsrcom997k+i1tYeLCYOixEEE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Q1CRsBTnBHrIalWjX9CsHeAmnXN+LS9ZZF6sr1hRC0uOXgcOhuRfl5OyBVlWk3A8a a9kIG94qsIp5w+ynlfKxAJjg8CHJC8DdsWkRHe+Rd9hTEyskODHJuMcgJ+lJec0LE8 p02fjhIsPqpsa8HkWxjCUvAs5xJoBK5g5cu586xM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347060137; i=@elandsys.com; bh=ZB5hnKmxjWlbK4YfNKYsrcom997k+i1tYeLCYOixEEE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=nMRD600NBX9uRH58x70OT+UbhUhTPJ/2nozMBPfai1JI1oI9p5CeQCRHaFh5Qh9jF vP+eLgnmludJXNNoKxQ2N7RycRojxEB0AIVrjUSbsDq1mH/WbrgFTLPAbAkqGLS47i qTcKDcNQWu8moaeEuWczSmvbEfRrXWGzlLboAAAc= Message-Id: <6.2.5.6.2.20120907152506.0a4f1978@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 07 Sep 2012 16:18:54 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <504A70B9.9050404@isdg.net> References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120826203640.0c6400e8@resistor.net> <6.2.5.6.2.20120907023043.0aad3700@resistor.net> <3120108.JgnBUtWjyy@scott-latitude-e6320> <504A70B9.9050404@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 23:22:20 -0000 Hi Hector, At 15:10 07-09-2012, Hector Santos wrote: > 1) Early SPF 2003 adopters who used original 2003 SPF > specifications with RFC2119 normative > languages for a REJECT-ON-FAIL [1][2][3] > > Fail (-): the message does not meet a domain's definition of > legitimacy. MTAs MAY reject the message using a permanent > failure reply code. (Code 550 is RECOMMENDED. See [RFC2821] > section 7.1.) > > The MARID production with RFC4408 only relaxed it to appears > the IETF adoption > process among the mail community who typically have concerns > with strong languages > towards mail rejection concepts. Early adopters would not be > changing their > operations. Some may have added logic to mark-on-fail, but it > would incomprehensible > to believe they would just accept and mark it without > separating the mail. According to the SPFBIS charter, draft-ietf-spfbis-4408bis is intended as a standards track document defining SPF, based on RFC 4408 and as amended above (the charter). There isn't any mention of any SPF drafts. The work is only on RFC 4408 instead of RFC 4408 and SPF drafts. It is not the purpose of this working group to convince or force anyone to change their operations. At 15:31 07-09-2012, Hector Santos wrote: >Please take into account that there were many early pre-4408 early >adopters that following the RFC2119-like compliancy language such as >the one in section 3 [1] That means ignoring the following messages: http://www.ietf.org/mail-archive/web/spfbis/current/msg02331.html http://www.ietf.org/mail-archive/web/spfbis/current/msg02370.html and what is in the SPFBIS charter. There isn't any mention of early pre-4408 in it. >Please keep in mind that RFC4408 did not really alter much for early >adopters, sure, they fine tune many of the features, added new >limits, etc, but RFC4408 was really meant to be compatible with the >existing early adoption and the work in 4408BIS "SHOULD NOT" dismiss >the original spirit and intent of what the -ALL policy provided >domains and receivers - a deterministic, powerful, near zero false >positive method of SPOOF protection. Lets not promote the concept >that SPF receivers SHOULD NOT give the domain publishers the benefit >of all doubt when it comes to the -ALL policy. The working group cannot change RFC 4408 if it is not compatible with existing early adoption. Whether RFC 4408 did not really alter much or what it was really meant to be does not alter the facts. RFC 4408 is the starting point for draft-ietf-spfbis-4408bis. I suggested a way to put the issue to rest ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02656.html ). It is useful to have other alternatives. Could you please suggest one which is in accordance with the SPFBIS charter? Thanks, S. Moonesamy SPFBIS WG co-chair From spf2@kitterman.com Fri Sep 7 16:33:32 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DBD21F858F for ; Fri, 7 Sep 2012 16:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-dv7k23pa0N for ; Fri, 7 Sep 2012 16:33:32 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1E44721F8581 for ; Fri, 7 Sep 2012 16:33:32 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 82E5720E40E8; Fri, 7 Sep 2012 19:33:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347060811; bh=DOkP+fpVbSMsysyCAdBIABPdRcl2ZPzitfUqkIke6iE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=TvA3GLiEZhVtw8dqrvZzzGqDQhUhUTKHuZVJ/+MZlVpJfV0rrpgfFrCJyA/Pxy1KO Eqsze4rOB6KTFOxPOA87Z+q0t3hFigbKu0PI+7vTPLNK+JzyBVOwWr1IRjnnH3Wq63 nhb13NK4pVJxKtOAe1rKxDtbm9u2lwP9xizRJhZY= Received: from scott-latitude-e6320.localnet (126.sub-70-192-196.myvzw.com [70.192.196.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3F52220E40CF; Fri, 7 Sep 2012 19:33:30 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 07 Sep 2012 19:33:29 -0400 Message-ID: <5010039.ki68fGPhdZ@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-30-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <6.2.5.6.2.20120907150642.0aad3d58@elandnews.com> References: <6.2.5.6.2.20120907150642.0aad3d58@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Extensions to SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 23:33:32 -0000 On Friday, September 07, 2012 03:20:49 PM S Moonesamy wrote: > Hi Scott, > > Section 1.1 of draft-ietf-spfbis-4408bis-07 has the following sentence: > > "This updated specification is intended to clarify identified > ambiguities in [RFC4408], resolve techincal issues identified > in post-RFC 4408 deplyment experience, and document widely > deployed extensions to SPF that have been developed since [RFC4408] > was published." > > The SPFBIS charter mentions that specifically out-of-scope for the > working group: > > * Extensions to the SPF protocols. > > Discussion of extensions to the SPF protocols or removal of > existing features shall only be discussed after completion of > current charter items in anticipation of rechartering the working > group. > > In the sentence from draft-ietf-spfbis-4408bis-07, there is "document > widely deployed extensions to SPF that have been developed since > [RFC4408] was published". That does not seem in line with what is in > in the charter. Elsewhere it says: > Changes to the SPF specification will be limited to the correction > of errors, removal of unused features, addition of any enhancements > that have already gained widespread support, and addition of > clarifying language. I'll confess that "document widely deployed extensions to SPF that have been developed since [RFC4408] was published." is not identical to "addition of any enhancements that have already gained widespread support", but I believe the meanings are similar enough. It's the charter basis for adding the information about RFC 5451 into 4408bis. Scott K From hsantos@isdg.net Fri Sep 7 16:39:41 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5845621F85B4 for ; Fri, 7 Sep 2012 16:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.753 X-Spam-Level: X-Spam-Status: No, score=-101.753 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCWKcAMopO3X for ; Fri, 7 Sep 2012 16:39:40 -0700 (PDT) Received: from dkim.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABBE21F85B1 for ; Fri, 7 Sep 2012 16:39:39 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2034; t=1347061175; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=N/v4zWZAQ2vzOWU1SUQUu7KD0zs=; b=JB6goU97hJ/Sr7DJD+hm vnwQFrDQWr8OwJeTQtfLSCazS/XjSlHrSvenZk1r60Q2evc9PjttyqZsuxZ4DPIG oPYEDxjeFQZ8HRHKXvgZvpAlNTrFmuZAwJ0CuohgX/FgpjJIUtXUIQl0ZVYPiis5 9ssaXzA1561v8jk//rTbLXg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 07 Sep 2012 19:39:35 -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 3082956008.1051.3444; Fri, 07 Sep 2012 19:39:33 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2034; t=1347060954; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=NWuOM8C Xg1ZYCqYrDNLy1NXDyEu504fcGUqkJH3d4N8=; b=GLynbwvdoWtYkHMCg1Jr2el FdYRGNqgC4/e/nrJnB5RF8RmweynBqYVM+GtdkWPwumKdTmJL32FGwuBCDdt2fvU Zx7xeEwCs+PRnw1kUZUP9m2A5LU4xkKGavKSp1DNr5FxhWxsr4dG4LYv64aWlrcY shrKbjXpTuTcE7Z+aDJk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 07 Sep 2012 19:35:54 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3681752411.9.6092; Fri, 07 Sep 2012 19:35:53 -0400 Message-ID: <504A8586.50909@isdg.net> Date: Fri, 07 Sep 2012 19:38:46 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120826203640.0c6400e8@resistor.net> <6.2.5.6.2.20120907023043.0aad3700@resistor.net> <3120108.JgnBUtWjyy@scott-latitude-e6320> <504A70B9.9050404@isdg.net> <6.2.5.6.2.20120907152506.0a4f1978@elandnews.com> In-Reply-To: <6.2.5.6.2.20120907152506.0a4f1978@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 23:39:41 -0000 S Moonesamy wrote: > Hi Hector, >> Please keep in mind that RFC4408 did not really alter much for early >> adopters, sure, they fine tune many of the features, added new limits, >> etc, but RFC4408 was really meant to be compatible with the existing >> early adoption and the work in 4408BIS "SHOULD NOT" dismiss the >> original spirit and intent of what the -ALL policy provided domains >> and receivers - a deterministic, powerful, near zero false positive >> method of SPOOF protection. Lets not promote the concept that SPF >> receivers SHOULD NOT give the domain publishers the benefit of all >> doubt when it comes to the -ALL policy. > > The working group cannot change RFC 4408 if it is not compatible with > existing early adoption. Whether RFC 4408 did not really alter much or > what it was really meant to be does not alter the facts. RFC 4408 is > the starting point for draft-ietf-spfbis-4408bis. > > I suggested a way to put the issue to rest ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02656.html ). It > is useful to have other alternatives. Could you please suggest one > which is in accordance with the SPFBIS charter? I'm lost because my original concerns are materializing and don't know what other simple compromise can be reached that was not proposed by issue #33. It has nothing to do with REPUTATION MODELING or doubting the protocol compliant of an SPF Domain publishing very strong unique exclusive authorization policies with -ALL directives. It has to do with a very simple premise: Mark-on-Fail MUST|SHOULD be semantically equivalent to Reject-On-Fail both on a security and functional basis, otherwise you have a security leak. Whats so hard about this? I don't know where all this has gone. We don't need a new thesis on the SPF Theory for -ALL policies. We know what it designed to do since 2003 and we also new where it faulted as well with unexpected relays at final destination MX sites. Anyway, I'm lost. Going swimming! :) -- HLS From superuser@gmail.com Fri Sep 7 16:46:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDADB21E8044 for ; Fri, 7 Sep 2012 16:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V92r6LBFjgfS for ; Fri, 7 Sep 2012 16:46:20 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 21FAE21F85E6 for ; Fri, 7 Sep 2012 16:46:19 -0700 (PDT) Received: by lbky2 with SMTP id y2so160472lbk.31 for ; Fri, 07 Sep 2012 16:46:18 -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=ezNLVI/AC6x9yEAXG+5SB0JxggusWLyPUhaiug8UQvg=; b=ttn25XEKF1tcGnFlksq2OA+domh/ypUzCU5ElhEXftK7PUHM4BuEzA0LNZmP3UqQ/j 9tQ2RVzXR+D8qp5sp54OYd08um4Xv+gck1VUZaKX9oXD1zD+J3NQQx/L7q0n1/khhFsM w4W9GkpI/25ffV/hyKmUwbjrfGULHmBLwiJz5h3co/ymjk4X2RU9f9vqRt7/b7EmC29n Xha9m42YvioeI5MAPav4nZ7s79h4tHkTFzwNCcGm+byY+VidL+Iywrhs1MYaaGkbeFJh 4Rz80wYIfUavu6EAsx9Z9eu9PwghQrpq5ZsV6fpnMAwFSQCajPf5RS0AaiF8Q1VNfrRf qCNg== MIME-Version: 1.0 Received: by 10.152.105.206 with SMTP id go14mr222718lab.37.1347061578631; Fri, 07 Sep 2012 16:46:18 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Fri, 7 Sep 2012 16:46:18 -0700 (PDT) In-Reply-To: <5010039.ki68fGPhdZ@scott-latitude-e6320> References: <6.2.5.6.2.20120907150642.0aad3d58@elandnews.com> <5010039.ki68fGPhdZ@scott-latitude-e6320> Date: Fri, 7 Sep 2012 16:46:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Extensions to SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 23:46:21 -0000 On Fri, Sep 7, 2012 at 4:33 PM, Scott Kitterman wrote: >> The SPFBIS charter mentions that specifically out-of-scope for the >> working group: >> >> * Extensions to the SPF protocols. >> >> Discussion of extensions to the SPF protocols or removal of >> existing features shall only be discussed after completion of >> current charter items in anticipation of rechartering the working >> group. When I wrote that, I meant changes to the SPF protocol itself. That is, it precludes the idea of adding a mechanism to say "evaluate From: instead of MAIL FROM". It wasn't aimed at A-R use. I also think use of A-R is not part of SPF itself, but rather falls into the nebulous "local policy" discussion. -MSK From superuser@gmail.com Fri Sep 7 16:54:28 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3C621F86A4 for ; Fri, 7 Sep 2012 16:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRrW4IHxw6rY for ; Fri, 7 Sep 2012 16:54:28 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB2B21F8698 for ; Fri, 7 Sep 2012 16:54:27 -0700 (PDT) Received: by lahm15 with SMTP id m15so73342lah.31 for ; Fri, 07 Sep 2012 16:54:26 -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=pxeU7vGTiSDuJPk1nh9j2OTu5fcCk0YJ5mEWC29HERM=; b=D53GVjLYwSLIU83ssWp4M4zHM8vCMn/0es9aCQqOllBLjGVpns+G0Wa4zgmwolqj5B KDmE9OE7M79N98UjiYFnhasCj66ql+D1X2ZqZR6GcQchR+XhtojmNxwuHKMh/ePQnY7L bf1tHYtBHWJ3ksklMRHM3sOVR2lHFpJJrghoTiHpJ/cg2sUs57ufvebzwBPeuji+nZ3y jZm8GrxCAkHVEsowjkC4rs9dHjMoivNlT0WEIF6FAVxLb7hTFaeln+3O8ddZacBmfagf cBt3qL5tqwz6qkckY1hn5oSVNCuaO/Nw85UomHzUc5Z0+V0oQDgy8c2R34cfG1QxynPf PmOw== MIME-Version: 1.0 Received: by 10.152.122.9 with SMTP id lo9mr6614284lab.41.1347062066381; Fri, 07 Sep 2012 16:54:26 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Fri, 7 Sep 2012 16:54:26 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20120907150642.0aad3d58@elandnews.com> <5010039.ki68fGPhdZ@scott-latitude-e6320> Date: Fri, 7 Sep 2012 16:54:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Extensions to SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 07 Sep 2012 23:54:29 -0000 On Fri, Sep 7, 2012 at 4:46 PM, Murray S. Kucherawy wrote: > On Fri, Sep 7, 2012 at 4:33 PM, Scott Kitterman wrote: >>> The SPFBIS charter mentions that specifically out-of-scope for the >>> working group: >>> >>> * Extensions to the SPF protocols. >>> >>> Discussion of extensions to the SPF protocols or removal of >>> existing features shall only be discussed after completion of >>> current charter items in anticipation of rechartering the working >>> group. > > When I wrote that, I meant changes to the SPF protocol itself. That > is, it precludes the idea of adding a mechanism to say "evaluate From: > instead of MAIL FROM". It wasn't aimed at A-R use. > > I also think use of A-R is not part of SPF itself, but rather falls > into the nebulous "local policy" discussion. By that, I mean A-R isn't an extension. In fact, I think the current draft introduces no extensions to SPF proper. That means we could drop the reference to extensions in Section 1, because it's saying this draft contains something that isn't there. -MSK From spf2@kitterman.com Fri Sep 7 17:01:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD8421E80CB for ; Fri, 7 Sep 2012 17:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccMsety11qKb for ; Fri, 7 Sep 2012 17:01:02 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 68C0A21E8047 for ; Fri, 7 Sep 2012 17:01:02 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9A51220E40E8; Fri, 7 Sep 2012 20:01:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347062461; bh=fEM2fI+ZazPVJlvcVsBpXgb/k9xY7g4rsYSzSptAOjI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fFc1TGx5SFMK7s+g+qxl/5aT2rEGnUP9VclC1KLMoZAV/Ayz48hjN5U9OoxMiAV5b wzhWEpzS++oVoQFTPt0eZOrD9Jd1vl+38b/zhce2JwHetQsUfIpu3h9pWGcAUMfHDh AygTuX1/Bw4gITGKM4rQLc3adiCCQ9Znr+GlHjKs= Received: from scott-latitude-e6320.localnet (126.sub-70-192-196.myvzw.com [70.192.196.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 63BFF20E40CF; Fri, 7 Sep 2012 20:01:00 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 07 Sep 2012 20:00:59 -0400 Message-ID: <7283796.EnZtEscRs5@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-30-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: References: <6.2.5.6.2.20120907150642.0aad3d58@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Extensions to SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 00:01:03 -0000 On Friday, September 07, 2012 04:54:26 PM Murray S. Kucherawy wrote: > On Fri, Sep 7, 2012 at 4:46 PM, Murray S. Kucherawy wrote: > > On Fri, Sep 7, 2012 at 4:33 PM, Scott Kitterman wrote: > >>> The SPFBIS charter mentions that specifically out-of-scope for the > >>> > >>> working group: > >>> * Extensions to the SPF protocols. > >>> > >>> Discussion of extensions to the SPF protocols or removal of > >>> existing features shall only be discussed after completion of > >>> current charter items in anticipation of rechartering the working > >>> group. > > > > When I wrote that, I meant changes to the SPF protocol itself. That > > is, it precludes the idea of adding a mechanism to say "evaluate From: > > instead of MAIL FROM". It wasn't aimed at A-R use. > > > > I also think use of A-R is not part of SPF itself, but rather falls > > into the nebulous "local policy" discussion. > > By that, I mean A-R isn't an extension. In fact, I think the current > draft introduces no extensions to SPF proper. That means we could > drop the reference to extensions in Section 1, because it's saying > this draft contains something that isn't there. I'm OK either way. Scott K From spf2@kitterman.com Fri Sep 7 17:04:56 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CB421E80E1 for ; Fri, 7 Sep 2012 17:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPP-1t7T3Kgf for ; Fri, 7 Sep 2012 17:04:55 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 98ED421E8047 for ; Fri, 7 Sep 2012 17:04:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2BFFF20E40E8; Fri, 7 Sep 2012 20:04:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347062673; bh=yr3ICPdIQqDJ0kuPAWCTTcyRZCowUKGFeazTdjTPSJk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WZgZ3RlsaQAgvqfqNsUXt1EWAroKKiS+oND/ieEmBYOolpe2tEhAFb3ega6hzcgRI pm9C23QF+5xqz1srDi2PmXCpSdVY1YiOMXzixNO+DnZF/X8Ia9cnDNLbn2fYS1Ihpc feMF5xcm5CF+O5tpCz+0w5/J2BWzbou8JW5OnYr4= Received: from scott-latitude-e6320.localnet (126.sub-70-192-196.myvzw.com [70.192.196.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E1A9820E40CF; Fri, 7 Sep 2012 20:04:32 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 07 Sep 2012 20:04:31 -0400 Message-ID: <1649153.4A3cWekutd@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-30-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <504A8586.50909@isdg.net> References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120907152506.0a4f1978@elandnews.com> <504A8586.50909@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 00:04:56 -0000 On Friday, September 07, 2012 07:38:46 PM Hector Santos wrote: > S Moonesamy wrote: > > Hi Hector, > > > >> Please keep in mind that RFC4408 did not really alter much for early > >> adopters, sure, they fine tune many of the features, added new limits, > >> etc, but RFC4408 was really meant to be compatible with the existing > >> early adoption and the work in 4408BIS "SHOULD NOT" dismiss the > >> original spirit and intent of what the -ALL policy provided domains > >> and receivers - a deterministic, powerful, near zero false positive > >> method of SPOOF protection. Lets not promote the concept that SPF > >> receivers SHOULD NOT give the domain publishers the benefit of all > >> doubt when it comes to the -ALL policy. > > > > The working group cannot change RFC 4408 if it is not compatible with > > existing early adoption. Whether RFC 4408 did not really alter much or > > what it was really meant to be does not alter the facts. RFC 4408 is > > the starting point for draft-ietf-spfbis-4408bis. > > > > I suggested a way to put the issue to rest ( > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02656.html ). It > > is useful to have other alternatives. Could you please suggest one > > which is in accordance with the SPFBIS charter? > > I'm lost because my original concerns are materializing and don't know > what other simple compromise can be reached that was not proposed by > issue #33. It has nothing to do with REPUTATION MODELING or doubting > the protocol compliant of an SPF Domain publishing very strong unique > exclusive authorization policies with -ALL directives. It has to do > with a very simple premise: > > Mark-on-Fail MUST|SHOULD be semantically equivalent to > Reject-On-Fail both > on a security and functional basis, otherwise you have a security > leak. > > Whats so hard about this? I don't know where all this has gone. We > don't need a new thesis on the SPF Theory for -ALL policies. We know > what it designed to do since 2003 and we also new where it faulted as > well with unexpected relays at final destination MX sites. > > Anyway, I'm lost. Going swimming! :) Hector, As far as anyone else can tell, we haven't changed anything. I think the proposed security consideration explains the issue to that implementers/deployers are alerted to deal with it, but the issue you are (I think) worried about is not new and explaining it is all we can do. Scott K From superuser@gmail.com Fri Sep 7 17:22:29 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072E721E80E1 for ; Fri, 7 Sep 2012 17:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eE-etd40q7eR for ; Fri, 7 Sep 2012 17:22:28 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4746C21E8047 for ; Fri, 7 Sep 2012 17:22:28 -0700 (PDT) Received: by lbky2 with SMTP id y2so170964lbk.31 for ; Fri, 07 Sep 2012 17:22:21 -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=MK/ak6n3mkSuvwNT4YWuoWI4EjfcpXxppatvm1HOfdI=; b=PtObbW2TXxY+dkOUQ4b+bHBxRamTT1KxZWwsjGYjrz8xi9EssrPLXoCAd7bIUbg2Ld tDbTdSgASdZuZqincTgIRE+fqzyJAjf8oIa5zBj0cxYXzKGEKQR2/eGgyca6eis+yu52 zuwOBcfgNo77g8B1FZm0D0UEvYOOxGHBO/ZsrmVQFnn5O7HUQ3vNRDlne6FUmY2Ies1f oQNasY8YfE1uxTjCz8Xso9QfYlk3UNIj8X44JACUlr8kAhw0U9T/dw7/r204Gl+yIfN7 bOxwh8PmsfdJ8nzf2LAA5vrtjKNA+TRq7HNSUSSEnoVq6dE4XHejIFlhahlabPec1jr5 jbuA== MIME-Version: 1.0 Received: by 10.152.102.137 with SMTP id fo9mr6676459lab.35.1347063741019; Fri, 07 Sep 2012 17:22:21 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Fri, 7 Sep 2012 17:22:20 -0700 (PDT) In-Reply-To: <1649153.4A3cWekutd@scott-latitude-e6320> References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120907152506.0a4f1978@elandnews.com> <504A8586.50909@isdg.net> <1649153.4A3cWekutd@scott-latitude-e6320> Date: Fri, 7 Sep 2012 17:22:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 00:22:29 -0000 On Fri, Sep 7, 2012 at 5:04 PM, Scott Kitterman wrote: > As far as anyone else can tell, we haven't changed anything. I think the > proposed security consideration explains the issue to that > implementers/deployers are alerted to deal with it, but the issue you are (I > think) worried about is not new and explaining it is all we can do. I proposed text to mention it, which could reasonably land in Security Considerations. We need people to review and comment on that proposal. -MSK From hsantos@isdg.net Fri Sep 7 18:38:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AB121F84D4 for ; Fri, 7 Sep 2012 18:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.084 X-Spam-Level: X-Spam-Status: No, score=-102.084 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuNb2qFzAC6V for ; Fri, 7 Sep 2012 18:38:21 -0700 (PDT) Received: from secure.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D9B8221F84D3 for ; Fri, 7 Sep 2012 18:38:20 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4857; t=1347068295; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Mj0YUm7n+LYMw3u9U3+fkrWifPE=; b=WdMwbtVxmcjKvg2a5kaQ 9WRwrErjHN1+HTXUvFXc/oHBM23+pw23kKIkToSQQrp3YhsdLplm9xPwVARBq6ED ONzJUKlt+qH4dwsAMNLyaRre0Mg0eSAHhu7QhK6f7x165v+Th5ok5uVZUiTBrp9j 1hhfAkU16Mv8hD3got3/EI4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 07 Sep 2012 21:38: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 3090076456.1051.4848; Fri, 07 Sep 2012 21:38:14 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4857; t=1347068073; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=PnwFyq3 8tIhWZyA0fx1jUPE+b5DXzAvf9pMf7fbbvwU=; b=keLxIY6y8NlwRJCrYHVoSEY YKdvdNDzMZf0BGgEMe+l7Jgyr3vEh54anxOlR6aY40zAWgV7Qul1NL0F2t9qYT8c YDme8h/kH2j30bHUNIAkEYuW45U0Zkx5f3Ewj8Trmf3A1I/GN0j05tiUCVmErQ79 9R/6mLDi9PvZhwzlf2Mg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Fri, 07 Sep 2012 21:34:33 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3688872067.9.7604; Fri, 07 Sep 2012 21:34:33 -0400 Message-ID: <504AA159.9060103@isdg.net> Date: Fri, 07 Sep 2012 21:37:29 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120826203640.0c6400e8@resistor.net> <6.2.5.6.2.20120907023043.0aad3700@resistor.net> <3120108.JgnBUtWjyy@scott-latitude-e6320> <504A70B9.9050404@isdg.net> <6.2.5.6.2.20120907152506.0a4f1978@elandnews.com> In-Reply-To: <6.2.5.6.2.20120907152506.0a4f1978@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 01:38:22 -0000 What is wrong with the original issue #33 proposed text? I think it covered all the key implementation points I believe to be realistic in practice without getting into the historical theory or any new mandates. It doesn't introduce any other "batteries required" concepts, non-existing protocols, layered process modeling framework changes, i.e. reputation frameworks that would not be persistent across all receivers. It provided the key problem statement and the key IETF standard mail protocols references for most common mail hosting operations that need to consider where their possible integration points are to deal with this. My point below was that -ALL was special, was always special since 2003 and never needed any other helper technology. The new proposed text [1] scott is considering begins to crack open the door to reputation modeling and this will now open up new concerns regarding the value of -ALL policies for DOMAIN. This can diminish the worth of the SPF protocol in a similar same way reputation revamped DKIM with its lost and deemphasis of a Policy-Based Security wrapper - DKIM original model and framework. ADSP and the informational DKIM deployment guide began to tell readers that it was ok for mail receivers to ignore strong ADSP policies and to depend on Reputation Modeling, Scoring and Heuristics systems - and unfortunately, it did not exist! I have no issue using additional methods for indeterminate SPF policies (anything but -ALL). I hope we can keep focus here on what SPF hard fail policy (-ALL) offered domains and receivers. It didn't need anything else to function. [1] http://www.ietf.org/mail-archive/web/spfbis/current/msg02661.html S Moonesamy wrote: > Hi Hector, > At 15:10 07-09-2012, Hector Santos wrote: >> 1) Early SPF 2003 adopters who used original 2003 SPF specifications >> with RFC2119 normative >> languages for a REJECT-ON-FAIL [1][2][3] >> >> Fail (-): the message does not meet a domain's definition of >> legitimacy. MTAs MAY reject the message using a permanent >> failure reply code. (Code 550 is RECOMMENDED. See [RFC2821] >> section 7.1.) >> >> The MARID production with RFC4408 only relaxed it to appears the >> IETF adoption >> process among the mail community who typically have concerns with >> strong languages >> towards mail rejection concepts. Early adopters would not be >> changing their >> operations. Some may have added logic to mark-on-fail, but it >> would incomprehensible >> to believe they would just accept and mark it without separating >> the mail. > > According to the SPFBIS charter, draft-ietf-spfbis-4408bis is intended > as a standards track document defining SPF, based on RFC 4408 and as > amended above (the charter). There isn't any mention of any SPF > drafts. The work is only on RFC 4408 instead of RFC 4408 and SPF > drafts. It is not the purpose of this working group to convince or > force anyone to change their operations. > > At 15:31 07-09-2012, Hector Santos wrote: >> Please take into account that there were many early pre-4408 early >> adopters that following the RFC2119-like compliancy language such as >> the one in section 3 [1] > > That means ignoring the following messages: > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02331.html > http://www.ietf.org/mail-archive/web/spfbis/current/msg02370.html > > and what is in the SPFBIS charter. There isn't any mention of early > pre-4408 in it. > >> Please keep in mind that RFC4408 did not really alter much for early >> adopters, sure, they fine tune many of the features, added new limits, >> etc, but RFC4408 was really meant to be compatible with the existing >> early adoption and the work in 4408BIS "SHOULD NOT" dismiss the >> original spirit and intent of what the -ALL policy provided domains >> and receivers - a deterministic, powerful, near zero false positive >> method of SPOOF protection. Lets not promote the concept that SPF >> receivers SHOULD NOT give the domain publishers the benefit of all >> doubt when it comes to the -ALL policy. > > The working group cannot change RFC 4408 if it is not compatible with > existing early adoption. Whether RFC 4408 did not really alter much or > what it was really meant to be does not alter the facts. RFC 4408 is > the starting point for draft-ietf-spfbis-4408bis. > > I suggested a way to put the issue to rest ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02656.html ). It > is useful to have other alternatives. Could you please suggest one > which is in accordance with the SPFBIS charter? > > Thanks, > S. Moonesamy > SPFBIS WG co-chair > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From sm@elandsys.com Fri Sep 7 19:23:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A4321E805A for ; Fri, 7 Sep 2012 19:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.599 X-Spam-Level: X-Spam-Status: No, score=-101.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, GB_NOSCRIP=2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sm7c56miwNHo for ; Fri, 7 Sep 2012 19:23:00 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E7A21E804C for ; Fri, 7 Sep 2012 19:23:00 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.66]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q882MlVK015670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2012 19:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347070979; bh=hjzP4x9bVBE8jUHYI9ZBEud0JJX8d3GU8dAEwzMkoFM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=H9nVVsYO8gPex04QWgY64gVVqzhBCZFN2WceiYGax8cSH4v4onocvSBFQ+71S0rfw Mb1Z5ka3TNA4wOaOgq3zjwZfecYKEUgGZ+sXehzoXkSZBlbtyeckDKHurbxe28Pdd1 4z/nlkIPkTSnHwCZ9zzdLANUGGn97xK+1IPSwJ/c= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347070979; i=@elandsys.com; bh=hjzP4x9bVBE8jUHYI9ZBEud0JJX8d3GU8dAEwzMkoFM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hCuphzCQlQu/P1z7T5jc6DGI0vDv5zmD4+031yIcsK3SG72di4IrgZQrb3ZQ2ZgKh 9qr8vor9BLYvF6MO0US2DudGcIj6HQBY6CH+imBui96QtLxpEMMA5H5QdUg+/f9Uaj KAkuEjLdSAtqn/B/S32xQDy569nsH/CYQm68VD8w= Message-Id: <6.2.5.6.2.20120907190137.09217c60@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 07 Sep 2012 19:22:33 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <504AA159.9060103@isdg.net> References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120826203640.0c6400e8@resistor.net> <6.2.5.6.2.20120907023043.0aad3700@resistor.net> <3120108.JgnBUtWjyy@scott-latitude-e6320> <504A70B9.9050404@isdg.net> <6.2.5.6.2.20120907152506.0a4f1978@elandnews.com> <504AA159.9060103@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 02:23:01 -0000 Hi Hector, At 18:37 07-09-2012, Hector Santos wrote: >What is wrong with the original issue #33 proposed text? I read the following comment ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02198.html ): "There's no prescription for rejection in 2.5.4. I think this gets into too much detail about internals of final delivery to the user." It's not a matter of "what is wrong" with text. If there is one paragraph which says the same thing as two paragraphs, it is better in my opinion to pick the one paragraph as long as there is agreement about it. >I think it covered all the key implementation points I believe to be >realistic in practice without getting into the historical theory or >any new mandates. It doesn't I might agree with you but if the group agrees on other text, that text takes precedence. >My point below was that -ALL was special, was always special since >2003 and never needed any other helper technology. The new proposed >text [1] scott is considering begins to Ok. Would you be ok with the following text: SPF does not, however, include the capacity for identifying good actors from bad ones; this is out of scope for this specification. Note that the above text still requires strong agreement for it to be included in the document. Regards, S. Moonesamy From vesely@tana.it Sat Sep 8 04:03:49 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42E221F8685 for ; Sat, 8 Sep 2012 04:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.345 X-Spam-Level: X-Spam-Status: No, score=-4.345 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFv7xo1VCPzg for ; Sat, 8 Sep 2012 04:03:49 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id B96B621F867F for ; Sat, 8 Sep 2012 04:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347102227; bh=N14toFVOgmgJquQBQtnpt7YR0e0ZdCBz8huGSLM/47A=; l=3894; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=kqXY5dBKQpZ4Crg0UQrqZgopCKFsXYOgmYji2GSnt5qmbsf8G8xP+Pg+aLTW7zW1O ptQJQNNdFyQmvBFIuC+MRRSduJF3Rkx0aRciDYyRIX0zCgHQWOAtnenM81f9GJvSSK j22wwtioHMWyxm1HKV221ry4WiV5sZc4KR/LxeEI= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 08 Sep 2012 13:03:47 +0200 id 00000000005DC03F.00000000504B2613.00000C9F Message-ID: <504B2612.3060606@tana.it> Date: Sat, 08 Sep 2012 13:03:46 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120907133424.0922c9c8@resistor.net> <2154218.4qxcVGrrDH@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 11:03:50 -0000 On Sat 08/Sep/2012 00:36:29 +0200 Murray S. Kucherawy wrote: > On Fri, Sep 7, 2012 at 2:05 PM, Scott Kitterman wrote: >> I'm fine with it, but .... There is a subtlety that while the above is true, >> there is definitely a differentiation of risk between the two. For "bad" >> domains, authorized or not, the mail is likely to be "bad". For "good" >> domains, not authorized mail is substantially more likely to be "bad" than >> authorized domains. I don't agree with the last sentence, unless "good" is intended to mean relaxed, broad authorizations. Mail can be forwarded without notice and without rewriting --so as to fool the smtp.mailfrom SPF check-- irrespectively of the domain's goodness. > The problem I think is that SPF doesn't have a self-contained notion > of what's good and what's bad. That ties to reputation in some form, > whether it's a local whitelist, a DNSBL, or a full-blown reputation > service of some kind. If we can make that clear, then the kind of > thing you're talking about is a bit more reachable from here. Possibly, but that's definitely at a different layer. IMHO, we should stick to the more basic notion of _registered domain_. If it is registered, people can find abuse reporting addresses, including reputation trackers', and complain as they like. It's someone else's job to make sure that's effective. Dealing with "bad" registered domains is not our job. SPF won't and can't do anything about it. > I don't know where this might land, but in the interest of being brief: > > Operators that choose to deliver mail for which SPF produces a "fail" > result need to understand that they are admitting content that is > explicitly not authorized by the purported sender. While there are > known failure modes that can be considered "false negatives"
references here>, the choice to admit those messages can expose end > users to harm. Yes, that's the essence of #33. > This is especially true for domains belonging to known good actors > that are typically well-behaved; unauthorized mail from those > sources might well be subjected to much higher skepticism and > content analysis. Again, I disagree with that sentence [see why]. False negatives need whitelisting, either on recipient's initiative, e.g. producing a sample message retrieved from the spam folder, or on sender's initiative after getting a bounce. That's mark vs reject. Abating false negatives is a distinct problem, unrelated to coping with them, albeit the abundance of false positives favors marking inasmuch as the latter allows to cope better. Tackling the abatement problem is what we need rechartering for. Correct? > SPF does not, however, include the capacity for identifying good > actors from bad ones; this is the purview of reputation systems in > their various forms, and is out of scope for this specification. Careful: I fully agree, assuming that "bad" is intended to mean the various shades of gray that upper layer protocols such as reputation systems will delineate. However, when "bad" means the blatantly illegal spamming committed by abusing others' domain names, that's exactly what we want SPF (and DKIM) to deal with. -- [see why]: That sentence misinterprets the statistical skew due to the fact that well-known domains are abused more often that others, while false negative ratios are distributed irrespectively of domain's behavior. Processing based on that can be easily gamed. For example, if I put a dot-forward to my new mailbox, paypal transactions and my mate's postcards will fail alike. The distribution of false negatives is related to the ease with which senders adopt my new address. Banks and mailing lists require me to take special action whereas (some) acquaintances and various kinds of spammers may do it spontaneously. From spf2@kitterman.com Sat Sep 8 06:35:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADB021F8584 for ; Sat, 8 Sep 2012 06:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-+KnEk8ZT7P for ; Sat, 8 Sep 2012 06:35:19 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C2F9021F857E for ; Sat, 8 Sep 2012 06:35:18 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 918A220E40CF; Sat, 8 Sep 2012 09:35:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347111317; bh=oFU5i8Mm0L7DJCI3jZQmpv8FwqrZQpMpTgRuJm0RIRA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=QlckuEnWaiQVWhH9b0R/CY66DrIuV0smerP+CJ8QiTRep1wsDGRJ4VURSnqKwjYBg vRj7HHd3+14+ySI5w8KKKSg8x7uZuIfacETZ5ke8YLGe5mKgXy1SLhD3PtZJOwWNlR cnz4BZynNcqELbqsEpIAZm/RcQSxCc3pIu+yqiQg= 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 6E16D20E4071; Sat, 8 Sep 2012 09:35:16 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 08 Sep 2012 09:35:16 -0400 Message-ID: <1902393.9yqKrzvbJL@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-30-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <504B2612.3060606@tana.it> References: <20120824173829.13742.qmail@joyce.lan> <504B2612.3060606@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 13:35:20 -0000 On Saturday, September 08, 2012 01:03:46 PM Alessandro Vesely wrote: > On Sat 08/Sep/2012 00:36:29 +0200 Murray S. Kucherawy wrote: > > On Fri, Sep 7, 2012 at 2:05 PM, Scott Kitterman wrote: > >> I'm fine with it, but .... There is a subtlety that while the above is > >> true, there is definitely a differentiation of risk between the two. > >> For "bad" domains, authorized or not, the mail is likely to be "bad". > >> For "good" domains, not authorized mail is substantially more likely to > >> be "bad" than authorized domains. > > I don't agree with the last sentence, unless "good" is intended to > mean relaxed, broad authorizations. Mail can be forwarded without > notice and without rewriting --so as to fool the smtp.mailfrom SPF > check-- irrespectively of the domain's goodness. I said more likely and you said it's not certain, so I don't see where the disagreement is? I agree it's not certain. > > The problem I think is that SPF doesn't have a self-contained notion > > of what's good and what's bad. That ties to reputation in some form, > > whether it's a local whitelist, a DNSBL, or a full-blown reputation > > service of some kind. If we can make that clear, then the kind of > > thing you're talking about is a bit more reachable from here. > > Possibly, but that's definitely at a different layer. IMHO, we should > stick to the more basic notion of _registered domain_. If it is > registered, people can find abuse reporting addresses, including > reputation trackers', and complain as they like. It's someone else's > job to make sure that's effective. Dealing with "bad" registered > domains is not our job. SPF won't and can't do anything about it. > > > I don't know where this might land, but in the interest of being brief: > > > > Operators that choose to deliver mail for which SPF produces a "fail" > > result need to understand that they are admitting content that is > > explicitly not authorized by the purported sender. While there are > > known failure modes that can be considered "false negatives"
> references here>, the choice to admit those messages can expose end > > users to harm. > > Yes, that's the essence of #33. > > > This is especially true for domains belonging to known good actors > > that are typically well-behaved; unauthorized mail from those > > sources might well be subjected to much higher skepticism and > > content analysis. > > Again, I disagree with that sentence [see why]. > > False negatives need whitelisting, either on recipient's initiative, > e.g. producing a sample message retrieved from the spam folder, or on > sender's initiative after getting a bounce. That's mark vs reject. > > Abating false negatives is a distinct problem, unrelated to coping > with them, albeit the abundance of false positives favors marking > inasmuch as the latter allows to cope better. Tackling the abatement > problem is what we need rechartering for. Correct? > > > SPF does not, however, include the capacity for identifying good > > actors from bad ones; this is the purview of reputation systems in > > their various forms, and is out of scope for this specification. > > Careful: I fully agree, assuming that "bad" is intended to mean the > various shades of gray that upper layer protocols such as reputation > systems will delineate. However, when "bad" means the blatantly > illegal spamming committed by abusing others' domain names, that's > exactly what we want SPF (and DKIM) to deal with. No. They don't. It is a fallacy to claim that SPF deals with the "good"/"bad" of anything at all. It deals with authorized/not authorized. For well behaved ("good") domains that are spoofed there is a significant correlation between "bad" mail and not authorized mail, but don't let that lead you into thinking one directly relates to the other. Scott K From hsantos@isdg.net Sat Sep 8 06:38:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF48021F85A7 for ; Sat, 8 Sep 2012 06:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.68 X-Spam-Level: X-Spam-Status: No, score=-100.68 tagged_above=-999 required=5 tests=[AWL=-1.003, BAYES_00=-2.599, GB_NOSCRIP=2, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FG+RjMe92sCF for ; Sat, 8 Sep 2012 06:38:20 -0700 (PDT) Received: from ftp.catinthebox.net (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B0C2721F8587 for ; Sat, 8 Sep 2012 06:38:19 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3257; t=1347111496; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=4+MiYeEYKL9ZU35Obd9LWDnFkJc=; b=SL06S9kal1fjmG9hO4To wpx7wSrumrZfQSkw6Y3dA8UA1YyJHGo8ETWX8FLQ++H5zGh+efaWWlu3NySnnCV5 UYyqK8fJ6ZaiWyf9Y/9cbJCoN3oDbfp40RqnFw501jQ15CeI8+3CzS63WGhVgc3V osPDRIWF9s9TzPeRv8fNerI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 08 Sep 2012 09:38:16 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3133277064.1962.5292; Sat, 08 Sep 2012 09:38:15 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3257; t=1347111277; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=SriGRxs NdCWi+NVQiIVjTjDwNg9oKPxcPTQJbokSC+0=; b=uTQBjGZPdL99Vg4TO/K/Tmm am5IaQ7BUs61wK4q+kcU79qM143PNIT4fx9PiASN8xRjheqFQc1giO/9bLG+hG6+ PB5K6wt7MxsAJ0nRiTckjyi8Br62Sqp5caYWcfFQYKX9dzwD3PKc3NuP2wPdkO0d g+MWNRta7/nEOPK5mn9s= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 08 Sep 2012 09:34:37 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3732074864.9.1524; Sat, 08 Sep 2012 09:34:36 -0400 Message-ID: <504B4A21.5010909@isdg.net> Date: Sat, 08 Sep 2012 09:37:37 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120826203640.0c6400e8@resistor.net> <6.2.5.6.2.20120907023043.0aad3700@resistor.net> <3120108.JgnBUtWjyy@scott-latitude-e6320> <504A70B9.9050404@isdg.net> <6.2.5.6.2.20120907152506.0a4f1978@elandnews.com> <504AA159.9060103@isdg.net> <6.2.5.6.2.20120907190137.09217c60@elandnews.com> In-Reply-To: <6.2.5.6.2.20120907190137.09217c60@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 13:38:21 -0000 S Moonesamy wrote: > Hi Hector, > At 18:37 07-09-2012, Hector Santos wrote: >> What is wrong with the original issue #33 proposed text? > > I read the following comment ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02198.html ): > > "There's no prescription for rejection in 2.5.4. > > I think this gets into too much detail about internals of final > delivery to the user." I believe maybe it was misread referring to the the final paragraph: Backends needs to take precautions of marking messages resulting from SPF -ALL failed transactions but were not rejected as prescribed in section 2.5.4. There is a RFC2119 "prescription" for SMTP level rejection when Reject-On-Fail is the active protocol in action. The the original issue #29, I believe, focused on defining the Marking behavior where there there was no "prescription" per se. Since that didn't have traction, I had no choice but to restate it as a security issue (#33). Now we need some level of semantics, insights, etc, to help mitigate the potential risk differences between the two type of receiver protocol behavior. > Would you be ok with the following text: > > SPF does not, however, include the capacity for identifying good > actors from bad ones; this is out of scope for this specification. > > Note that the above text still requires strong agreement for it to be > included in the document. I personally do no recommend any REPUTATION talk involved with the -ALL policy. Its 100% unrelated. We risk going down the same path ADSP did with DKIM arguing uselessly the merits of strong exclusive mail authoring domain policies. Besides, we can waste time argueing the above statement is not correct and/or depending on one's definition for "actor" or reputation modeling, SPF certainly does have the capacity of identifying good actors from bad ones. That is the whole point of -ALL. if a mail sender uses our domain from none our our IP addresses, then its a BAD ACTOR, I am telling you he is a BAD GUY, please REJECT this transaction. Thats a very strong deterministic capacity and falls under the ideas such as Query Dissemination methods. Its all part of process control and optimization theories. Its used in many ways, in many sciences and applications and conceptually, the faster your can filter your stream the better you can achieve, reach, zoom in on a higher quality in your result. So I have written many times, I believe before you can even get a reputation consideration, you must filter all the deterministic junk first. Anyway, we don't want to revisit the theory of SPF with reputation or worst leave it as such (with your text) that the SPF protocol is broken due to some subjective idea that reputation is required but unfortunately because its out of scope it can't be discussed and SPFBIS -ALL policies are now less optimal, non-effective for DOMAINS to use. I don't think that would be correct. My opinion is to set the facts straight. Operations can use reject or mark per 2.5.4 and they need to take precautions to perhaps separate the SPF failed marked mail which would be otherwise rejected and thus never reaching the user under a different mode. -- HLS From agthisell@yahoo.com Sat Sep 8 06:46:57 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D90821F856F for ; Sat, 8 Sep 2012 06:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.922 X-Spam-Level: X-Spam-Status: No, score=-0.922 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbfAXDVxcvqv for ; Sat, 8 Sep 2012 06:46:57 -0700 (PDT) Received: from nm22-vm0.bullet.mail.ne1.yahoo.com (nm22-vm0.bullet.mail.ne1.yahoo.com [98.138.91.60]) by ietfa.amsl.com (Postfix) with ESMTP id C285121F856C for ; Sat, 8 Sep 2012 06:46:56 -0700 (PDT) Received: from [98.138.90.54] by nm22.bullet.mail.ne1.yahoo.com with NNFMP; 08 Sep 2012 13:46:52 -0000 Received: from [98.138.89.164] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 08 Sep 2012 13:46:52 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 08 Sep 2012 13:46:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 749262.31017.bm@omp1020.mail.ne1.yahoo.com Received: (qmail 5908 invoked by uid 60001); 8 Sep 2012 13:46:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347112012; bh=Y/ZCGuGEFX3JlDckyliYTKBEnbzZwW/6MwoFuNop5Oc=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=cJWnDxJwrf4NccbUgGnI3zJFT83xe7L/S+VxvTv2pWoFqZmhFJI0Wh9IjG1pLZ9uvt95EfBJfMbCJ79j7SgCVgn1ikZQC4yaqGZWrgxDUyiouDrStoYWRauGad+ifvNVChukmTyRrD3X9SK1LgY5KOTKHFkDri7m/CSgLl+UZbQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=IRIAzpDK0/DB6CoccJmifMvOPDzpmNIsuM1yQd2os2c5HusRfMfXXHc+E0NjTXExz/sxkk76ScrEQjGinBVgiJn81zAVP+HqBv/l5yp6MYpGwP6ZjMDIYjSggyMBMVjuqls8pI2lE4WvMmz27leVjJJZWHtLjQsvFtR0gYMws/c=; X-YMail-OSG: DLSrsPYVM1njCi32lDsPUKvqHzWRus0uUp03_G7cRWGT_WQ v61LkqS6ID5B7FzSNiFFsee_HMwKmxxzENyP84qCsaX2EmFQGAczdyrmhWLb ErrR2iYhUADI4IFNVryyi6_tsU2DaV1SXjCYQx8E.bLXaQZVq0cxkmgR.fTi BMUZXO1hjTXzsU6LaYcEKx715Qvz76Gb6jMC8y6JWblWmsjG1wQFwoqwwTKV hzbvKSAf2NvJXCCP2ZTgPMUS0DefXHFxEALZ97QleIvUrupzMuDfkMaOqglp HGeBS5zFH5UhoQgluVXWxyPEjWKbVUTqHbq6kgCT2PS_Jz8czska12R7X6QZ .MMXlXqMORXUmTNkRu6_SO112hUiXDAFX_znTuoMeig6aJ3hAkbOaJjuOcBB 9TIwQnTzDheWH08DHcDkLDAt1.VMFmOLt3VZsE7S1M4Xn37fv6FXKbqENlNT _hX5Ae7BsZGpGe1.eDAI- Received: from [71.61.133.134] by web125403.mail.ne1.yahoo.com via HTTP; Sat, 08 Sep 2012 06:46:52 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347112012.2101.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Sat, 8 Sep 2012 06:46:52 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 13:46:57 -0000 > According to the SPFBIS charter, draft-ietf-spfbis-4408bis is intended as a > standards track document defining SPF, based on RFC 4408 and as amended > above (the charter). There isn't any mention of any SPF drafts. The work is > only on RFC 4408 instead of RFC 4408 and SPF drafts. It is not the purpose > of this working group to convince or force anyone to change their > operations. This almost scary wrong. Yes, this WG is using kitterman-4408bis as a base, as the charter calls for. No, other drafts aren't mentioned in the draft. But the only thing I can think of worse than not looking at earlier SPF drafts to give insight into how SPF should be updated is not looking at the real-world use of SPF. If you are going to constrain the WG to looking only at RFC4408, we are going to have serious problems. Just recently, someone mentioned that Courier-MTA returned "unknown" as an SPF result, which can only be understood by knowning earlier SPF drafts. RFC4408 was written by people, and people make mistakes. Some differences between RFC4408 and earlier SPF drafts are deliberate choices and some are mistakes, IMHO, when deciding what belongs in RFC4408bis, the most important thing is real-world usage, then RFC4408, then pre-marid SPF documents, then post made to various mailing lists, and last, marid drafts. The later two are pretty weak sources, but still useful. OK, that said, the earlier SPF drafts DID NOT have "a deterministic, powerful, near zero false positive method of SPOOF protection." It DID NOT require rejecting on SPF fail. There was *always* a debate about what SPF should do with SPF fail, even in 2003, and at best, the earlier drafts had contradictory language. Now, back to the charter. During the MARID WG, it was decided to not have any demands in the SPF draft to require SPF verifiers to handle SPF fail in any particular way. This group's charter says we are not supposed to rehash arguments from MARID. This discussion needs to be closed, not because insight was brought up from early SPF drafts, but because it brought up issues that were resolved in MARID. From agthisell@yahoo.com Sat Sep 8 07:34:50 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77F821F858F for ; Sat, 8 Sep 2012 07:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.614 X-Spam-Level: X-Spam-Status: No, score=-0.614 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANjr0aQ9Gs1o for ; Sat, 8 Sep 2012 07:34:49 -0700 (PDT) Received: from nm15-vm2.bullet.mail.ne1.yahoo.com (nm15-vm2.bullet.mail.ne1.yahoo.com [98.138.91.91]) by ietfa.amsl.com (Postfix) with SMTP id 7929921F8587 for ; Sat, 8 Sep 2012 07:34:46 -0700 (PDT) Received: from [98.138.90.49] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 08 Sep 2012 14:34:40 -0000 Received: from [98.138.89.161] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 08 Sep 2012 14:34:40 -0000 Received: from [127.0.0.1] by omp1017.mail.ne1.yahoo.com with NNFMP; 08 Sep 2012 14:34:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 816057.78052.bm@omp1017.mail.ne1.yahoo.com Received: (qmail 43219 invoked by uid 60001); 8 Sep 2012 14:34:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347114880; bh=gZhz3SjRkUfHYHw2jgJ4v/1f3GzPdeujOQumg7vVijI=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=weCaQg6OwEuXqTvDczWtYB9V4epAnvP2lRR06cjIcr/g4kor/Vc+QOxWeOeQypGOQiqsHAjNxflxRxKzK0ElzoHh7JldXIhcBDCoStbEX7yeq8G5vBo8yt5uT5yrsfPyH98yr5SHY+C6lnhCjsG9kjWonzNuqHgZt7r2iLo7kEU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=iR8EvEmCJqFEAMx8dvON0bBCf9HB7hC0W6FHlzhh7UWSdQw0leGLOnaNca2MHidQdu0V6dILBLs5Ft5AxEFf52rpITGE5pMOUvW1gFW49fusEXvuZslx/43aOOBukZBpbYAyKlEluP/NVP27M0uGvx/l4V/+xoJbAQiClWoG4FQ=; X-YMail-OSG: 0OaBbs0VM1ltuH5pSYdngMl8yFfuVFoKY5FIdowAM10CnZ1 eW_6yGXjqX_8skyjEBbYB61mADYEenAIcL2wcPY2ouvlTaGfxgto.4Fctdwh zUuIG9TwC_rgvSKDHldAXHtUZEwoSg2KxG8jfptaPx54rmsKYtVzrWefUu0k s94ivPqFMjqbS1hfgs9bfnt5MWaKMnL08BmFO2Fhll5ymidEWetU.1rAG4sY .iCOi5Iqa716ortZ9sA5dlUcOy.I0jVM2jB9dMzgoUs5Da4.JNLSwfFP6ic6 aS7gQr1V6SCnwrTFh0iF4OL03TXrj2ws659Yz_IaaXUXai4mXISz_4uRcmKP 5FmVRZ26P6Pkuf861XfLtMdJa9UXx9eNrA2ojAbtO7V5qJKeyVnazZvIR2R4 V5B8pZZ1EcJW5kg07Yj3j1hccEBmLJUq0du1LrxcEqzQPypReyN8qP_oP0ZU mL26oLn1ciodAJVbddoU- Received: from [71.61.133.134] by web125403.mail.ne1.yahoo.com via HTTP; Sat, 08 Sep 2012 07:34:40 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347114880.26715.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Sat, 8 Sep 2012 07:34:40 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 14:34:50 -0000 > I see three possible fates for Section 9: > > 1. Keep it in 4408bis. This is the most direct logical extension of RFC 4408 > and in keeping with what I view as the spirit of our charter (minimal diff to > get out of experimental and onto the standards track). It is certainly consistent with the charter. It does however bring a fair amount of "How to" > type of text into a standards track RFC that is better suited to a BCP. This > may make IETF last call and IESG approval harder and risks getting directed to > rework it later. I recently re-listened to IETF 83's SPFBIS session. I got the feeling that our ADs and the IESG would be much more forgiving of RFC4408bis not being up to current standards of quality if we made the absolute minimum number of changes and a response of "well, we left that part unchanged from RFC4408" would be accepted. In particular, Pete Resnick seemed leary about removing type 99 SPF records and said that we needed to document our justifications for making any change. That the deal with the IESG was that only minimal changes to RFC4408 would be made. If, however, we start rewriting large portions of RFC4408 to bring it up to scratch, I suspect the IESG will want to know why we didn't bring all of the document up to scratch. I'm not an expert at how to get an I-D turned into an RFC and I don't want to read too much into what Pete said one time on one subject, so I'm putting this out much more as a question than as a statement. Would we actually have an easier time if we made very few changes? From hsantos@isdg.net Sat Sep 8 07:36:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D69421F8596 for ; Sat, 8 Sep 2012 07:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.98 X-Spam-Level: X-Spam-Status: No, score=-100.98 tagged_above=-999 required=5 tests=[AWL=-0.503, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_47=0.6, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAx06TNlZNBN for ; Sat, 8 Sep 2012 07:35:58 -0700 (PDT) Received: from ftp.catinthebox.net (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 195B421F85D5 for ; Sat, 8 Sep 2012 07:35:54 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=6911; t=1347114951; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=fdIHLzKJJ9RVvHvmNKjB6pv7h8I=; b=fL0Tw3pTsW8jJVCm+7am ACxaNB7cjUpzaZG1idSHBYd5vUuMGCMTP9waj3wdryyea47+gf9lsRl4PX72jggD SYufFVE3xoPW8BkqTOEl2uPjbgYbApVXatASLNhWNfPvCyNAHAgpzLj415tarsuy 02dLzfF5oc4bfepYlj4Eyz8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 08 Sep 2012 10:35:51 -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 3136732392.1962.4588; Sat, 08 Sep 2012 10:35:50 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=6911; t=1347114733; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=NMEryeD zzl+wsLhjvlhlrc7x10tHwfYjdn9j5SXp6XM=; b=ElAWMFmzOj8LIbWLu7oDuL9 dtjCV3cr7HVf8eUpkthjsk4iqmNJK2Te3tWwGMdecto1Yq7eOb39mSrSD/0ZXhzw 4eqYNnACOXClRTZq4S9MTDupD2x7Z6MfAWv/vTzCmlxHsNF1bUCAfSIdNrDl0FsA W/K8SXAHKhjkx3RlTUJg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 08 Sep 2012 10:32:13 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3735531427.9.1724; Sat, 08 Sep 2012 10:32:12 -0400 Message-ID: <504B57A1.9050002@isdg.net> Date: Sat, 08 Sep 2012 10:35:13 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Arthur Thisell References: <1347112012.2101.YahooMailClassic@web125403.mail.ne1.yahoo.com> In-Reply-To: <1347112012.2101.YahooMailClassic@web125403.mail.ne1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 14:36:01 -0000 I strongly believe there is a serious underestimation of how much current implementations and deployments since 2003 support the original specification "MAY REJECT" with a reject-on-fail implementation and deployment despite if is optional or not. RFC4408 simply relaxed the semantics to make it non-normative to appease the IETF adoption process. It was already very hard to get any mail protocol to reject mail standardized and for good technical reason and with zero false positives. We had CAM-SPAM in the works and these things were very important once SORBIG hit the industry and showed how nasty the accept/bounce mail problem was. Anyway, take a look at all the available SPF APIs, open source and otherwise and see what they are using for -ALL policies results. I can see this off hand for Libspf2 for the EXIM ACL http://duncanthrax.net/exiscan-acl/exiscan-acl-spec.txt and it appears to me that it does not have a ACCEPT+MARK option at all. I can't say its customize for specific sites, the main point is I believe there is a serious underestimation and why ISSUE #33 is important to resolve. EXIM SPF support: You can now run SPF checks in incoming SMTP by using the "spf" ACL condition in either the MAIL, RCPT or DATA ACLs. When using it in the RCPT ACL, you can make the checks dependend on the RCPT address (or domain), so you can check SPF records only for certain target domains. This gives you the possibility to opt-out certain customers that do not want their mail to be subject to SPF checking. The spf condition takes a list of strings on its right-hand side. These strings describe the outcome of the SPF check for which the spf condition should succeed. Valid strings are: o pass The SPF check passed, the sending host is positively verified by SPF. o fail The SPF check failed, the sending host is NOT allowed to send mail for the domain in the envelope-from address. o softfail The SPF check failed, but the queried domain can't absolutely confirm that this is a forgery. o none The queried domain does not publish SPF records. o neutral The SPF check returned a "neutral" state. This means the queried domain has published a SPF record, but wants to allow outside servers to send mail under its domain as well. o err_perm This indicates a syntax error in the SPF record of the queried domain. This should be treated like "none". o err_temp This indicates a temporary error during all processing, including exim's SPF processing. You may defer messages when this occurs. You can prefix each string with an exclamation mark to invert is meaning, for example "!fail" will match all results but "fail". The string list is evaluated left-to-right, in a short-circuit fashion. When a string matches the outcome of the SPF check, the condition succeeds. If none of the listed strings matches the outcome of the SPF check, the condition fails. Here is a simple example to fail forgery attempts from domains that publish SPF records: /* ----------------- deny message = $sender_host_address is not allowed to send mail from $sender_address_domain spf = fail --------------------- */ You can also give special treatment to specific domains: /* ----------------- deny message = AOL sender, but not from AOL-approved relay. sender_domains = aol.com spf = fail:neutral --------------------- */ Explanation: AOL publishes SPF records, but is liberal and still allows non-approved relays to send mail from aol.com. This will result in a "neutral" state, while mail from genuine AOL servers will result in "pass". The example above takes this into account and treats "neutral" like "fail", but only for aol.com. Please note that this violates the SPF draft. When the spf condition has run, it sets up several expansion variables. $spf_header_comment This contains a human-readable string describing the outcome of the SPF check. You can add it to a custom header or use it for logging purposes. $spf_received This contains a complete SPF-Received: header that can be added to the message. Please note that according to the SPF draft, this header must be added at the top of the header list. Please see section 10 on how you can do this. $spf_result This contains the outcome of the SPF check in string form, one of pass, fail, softfail, none, neutral, err_perm or err_temp. $spf_smtp_comment This contains a string that can be used in a SMTP response to the calling party. Useful for "fail". Arthur Thisell wrote: >> According to the SPFBIS charter, draft-ietf-spfbis-4408bis is intended as a >> standards track document defining SPF, based on RFC 4408 and as amended >> above (the charter). There isn't any mention of any SPF drafts. The work is >> only on RFC 4408 instead of RFC 4408 and SPF drafts. It is not the purpose >> of this working group to convince or force anyone to change their >> operations. > > This almost scary wrong. Yes, this WG is using kitterman-4408bis as a base, as the charter calls for. No, other drafts aren't mentioned in the draft. But the only thing I can think of worse than not looking at earlier SPF drafts to give insight into how SPF should be updated is not looking at the real-world use of SPF. If you are going to constrain the WG to looking only at RFC4408, we are going to have serious problems. > > Just recently, someone mentioned that Courier-MTA returned "unknown" as an SPF result, which can only be understood by knowning earlier SPF drafts. RFC4408 was written by people, and people make mistakes. Some differences between RFC4408 and earlier SPF drafts are deliberate choices and some are mistakes, > > IMHO, when deciding what belongs in RFC4408bis, the most important thing is real-world usage, then RFC4408, then pre-marid SPF documents, then post made to various mailing lists, and last, marid drafts. The later two are pretty weak sources, but still useful. > > OK, that said, the earlier SPF drafts DID NOT have "a deterministic, powerful, near zero false positive method of SPOOF protection." It DID NOT require rejecting on SPF fail. There was *always* a debate about what SPF should do with SPF fail, even in 2003, and at best, the earlier drafts had contradictory language. > > Now, back to the charter. During the MARID WG, it was decided to not have any demands in the SPF draft to require SPF verifiers to handle SPF fail in any particular way. This group's charter says we are not supposed to rehash arguments from MARID. > > This discussion needs to be closed, not because insight was brought up from early SPF drafts, but because it brought up issues that were resolved in MARID. > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From agthisell@yahoo.com Sat Sep 8 08:21:56 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2611121F8535 for ; Sat, 8 Sep 2012 08:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[AWL=0.839, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhNOsnHS21rb for ; Sat, 8 Sep 2012 08:21:55 -0700 (PDT) Received: from nm32-vm7.bullet.mail.ne1.yahoo.com (nm32-vm7.bullet.mail.ne1.yahoo.com [98.138.229.55]) by ietfa.amsl.com (Postfix) with SMTP id C72BB21F8559 for ; Sat, 8 Sep 2012 08:21:54 -0700 (PDT) Received: from [98.138.90.54] by nm32.bullet.mail.ne1.yahoo.com with NNFMP; 08 Sep 2012 15:21:42 -0000 Received: from [98.138.89.251] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 08 Sep 2012 15:21:42 -0000 Received: from [127.0.0.1] by omp1043.mail.ne1.yahoo.com with NNFMP; 08 Sep 2012 15:21:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 785272.87491.bm@omp1043.mail.ne1.yahoo.com Received: (qmail 29240 invoked by uid 60001); 8 Sep 2012 15:21:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347117702; bh=7mBpNCVUBDxXmW2TVBZErDa7EQf4WZfpD0Qm7de6ZAM=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=JBPu+FCOaGz9TErmgEFOIGwhxwGj2rPWK46cMxGIRUtbBl0WJCrGvudNB2SXvOXyINkjFC2xUQ6io7AjJYC4FhEfQd2nbkrDamxEvmGQSpcIc5MxnfBWff+I3UyI5AXwHH/b8qwEYUVdpX3YBMJW8IWshcWJefRzyZXf3L+go/M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=cOFOqVVzdwGD4MJW5uR38jBQcfbGtyLdiUbR8q6+N1l8vgDIV5bj5ZpH1H4PhEesEFmsr2dw6kcao6mXIOR2uwb3LWdg4IsvHlLd3wLXLu2bvhClYnl+EAnGd9JcJcHqLDJY3sQK9A7/QRDBZPBZONCzjh6JBN9k4BFU8wcKlNg=; X-YMail-OSG: 8aAk1H0VM1kqeFiMQHAhmBJ5domsvk1w2D7pfmPoEbC2mhq togD55fvr4byBr9N3yR.HwKMfsnL31S3Nnf2njtg8Blx1g4u0KcB2wC6xwKJ PplrT4qf2FZ70s.gSzme3Hg.swAhJ3oWGquAR_S68matfmeDCspA64G0moGP XpnT.3SnSa3oKfyvnPjYWIAhsVwva2hw1dwUWkErLYCZgnUidEeHvsKuxy72 32zo5V2fkaAe0O.lu.W8wfkqroWaRKu.VNKjuIGSYsVQEfmor3Q3aQyTgXbN NTTEAH63pM24_y.fI3zmLOi1DaC3jmQdL4dOHpd.Hx.733pIMlZNpT9Lx5K3 o64kr3lGq5u257a7bc5PSOo5fktWdAqrawzFopv3BGPpTkUYWvJdr10IS4KT NyUwOrAzjfx3kko9SaNMnzFIomwUSQHsao_SbuRlJRqgM.aHDXSyQoOK.Ntm aiGyORY6hrU8mvbd1rJE- Received: from [71.61.133.134] by web125401.mail.ne1.yahoo.com via HTTP; Sat, 08 Sep 2012 08:21:42 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347117702.29062.YahooMailClassic@web125401.mail.ne1.yahoo.com> Date: Sat, 8 Sep 2012 08:21:42 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] remove section 9.1.1 DNS Resource Considerations X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 15:21:56 -0000 "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" - Donald Knuth I'm slow sometimes, but I've come to the conclusion that we should remove section 9.1.1 (DNS Resource Considerations) First, most of this information is duplicated from other parts of the draft. Section 4.6.4 (DNS Lookup Limits) contains the DNS limits, section 3 (SPF records) already says "ADMDs SHOULD also try to minimize the amount of other DNS information needed to evaluate a record." In particular, the table in section 9.1.1 can be easily misread as saying that you can have 10 a: mechanisms *and* 10 mx: mechanisms, *and* 10 include: mechanisms. While I initially liked the table, I now think it adds more confusion that clarity. Maybe the table can be redesigned, but no matter what, it should be in section 4.6.4. Second, SPF adoption isn't hampered so much by a few extra DNS queries as much as it is by people having out of date SPF records. Too many people try to get clever and turn an mx: mechanism into a series of ip4: mechanisms and then forget to update the SPF record when something changes. This section gives undue emphasis on efficiency over reliability. Third, this is basically a "how to" document that would be much better served by existing or new web pages/books. Last, if you really want to reduce the number of SPF queries, it would be much more effective to dust off that SPF record optimizer someone wrote long ago and try to get it put into the bind distribution. Make it easy to get it incorporated into godaddy's SPF support and get it running there. The SPF spec is not an effective place to promote this kind of thing. From agthisell@yahoo.com Sat Sep 8 08:29:09 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B0A21F8528 for ; Sat, 8 Sep 2012 08:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.658 X-Spam-Level: X-Spam-Status: No, score=-0.658 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6edkUY+2eCZc for ; Sat, 8 Sep 2012 08:29:08 -0700 (PDT) Received: from nm14-vm4.bullet.mail.ne1.yahoo.com (nm14-vm4.bullet.mail.ne1.yahoo.com [98.138.91.174]) by ietfa.amsl.com (Postfix) with SMTP id AEA7121F8526 for ; Sat, 8 Sep 2012 08:29:08 -0700 (PDT) Received: from [98.138.90.51] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 08 Sep 2012 15:29:04 -0000 Received: from [98.138.89.245] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 08 Sep 2012 15:29:04 -0000 Received: from [127.0.0.1] by omp1059.mail.ne1.yahoo.com with NNFMP; 08 Sep 2012 15:29:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 769867.67427.bm@omp1059.mail.ne1.yahoo.com Received: (qmail 34880 invoked by uid 60001); 8 Sep 2012 15:29:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347118144; bh=sQ6MPflgPJim/hWeyNI1HI97xegplYYZwN62opSezX8=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=DX3iUavMDmuON5a+22cgbnVm8jZTcLaJQcIRw3UtIAwVndbPI8RYifUZpZfwRIJ/mpuenI8cU+8K7kgnWcFmyLdGgoXxfJ5qEso9UO4HQzLqJ2MeNwkbaF3nkeHoUxrchHOAvnWtloiWB+X8aY9l7C3h4HlyzkyThALBJIwxSrY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=LB+K/S7abbPa/p2vB/T24+l70Jti4tGDh/mjP+c1UorzNRHW2KsHxV9W95O2wA/H0JCljhPXsHS59I2E0wRhtCGCsJk0UvO2kQMU72t0dL8Sedm5VdAKyxAmgEBiRk2m9o9hotTp7GMAOxgRq4RmALQXADwdGkE3XEUkudtjHCM=; X-YMail-OSG: aFCsmvQVM1nJDSIiMtgyW4uy8VflhZh0O2t3ohkoFG6.v5T Gy8g7BWqLymYdbcspOcVM1mfex4soDfQ2aC4_mtpOe20QJbOgr1BhXwM_jh4 cen85xamFlgIYhWHYryz9suQdpF7eawh6aUApAU27AEcDLniSoRZzUz1m3L5 ToBq6SHiVo4S4Bmh.Z75g_PEzTU30bsxmwkR2JqRTO1gjgUgHGNq2TJV5H7h yp5BAZ_p0KpoVWb9zir.fswXEx36nwXTtjDUNJd_2cDmAm8MyVW2zcp3e8OB CKgTX5lRIEkEcHSYXdGq1TtTeIe2_G3Ww1CEUAspXuTsfK8Dngt9dqJsXlth klL9_NbT1uZzXERhQTIbQFMs.ZbZmYuDHI0znSAcy4ohv30lPD3hX.vn3UWP 01N2IXzHNlLcVZnC2MZxvQsDspCPQsWR93tMpSpo_LKvCy8F2MdqRlXNcJuo WM1ev5DATF8XW.CoKdck- Received: from [71.61.133.134] by web125401.mail.ne1.yahoo.com via HTTP; Sat, 08 Sep 2012 08:29:04 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347118144.79009.YahooMailClassic@web125401.mail.ne1.yahoo.com> Date: Sat, 8 Sep 2012 08:29:04 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 15:29:09 -0000 > I strongly believe there is a serious underestimation of how much current > implementations and deployments since 2003 support the original > specification {...} This discussion needs to be closed, not because insight was brought up from real-world examples, but because it brought up issues that were resolved in MARID. From spf2@kitterman.com Sat Sep 8 08:32:42 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AE821F854F for ; Sat, 8 Sep 2012 08:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ptC3MahsuzJ for ; Sat, 8 Sep 2012 08:32:41 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E5F8121F8533 for ; Sat, 8 Sep 2012 08:32:40 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0015120E40CF; Sat, 8 Sep 2012 11:32:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347118360; bh=IzxjdD5DN4JpbWlzpD9Uku6jXrQnZout8rUsSUmagG0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=NTOx8i3SIgc7D1mDJjaKtjGBCHc6OTbNhf2wZG990eM1L+L2du8Dqv7riKNCg1AOH i4v0umciLX+aG1V8JgIvgS75mwYqS+Rmu8OmxUceC2u1/VUDoXQHWsTtom5drY+sGa AXoeymUTRLoGxvxqCzruuqZ3VtpPOpClDyGvlo9w= 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 C398F20E4071; Sat, 8 Sep 2012 11:32:39 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Sat, 08 Sep 2012 11:32:35 -0400 Message-ID: <6437246.69jf51CMRk@scott-latitude-e6320> User-Agent: KMail/4.8.4 (Linux/3.2.0-30-generic-pae; KDE/4.8.4; i686; ; ) In-Reply-To: <1347117702.29062.YahooMailClassic@web125401.mail.ne1.yahoo.com> References: <1347117702.29062.YahooMailClassic@web125401.mail.ne1.yahoo.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] remove section 9.1.1 DNS Resource Considerations X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 15:32:42 -0000 On Saturday, September 08, 2012 08:21:42 AM Arthur Thisell wrote: > "We should forget about small efficiencies, say about 97% of the time: > premature optimization is the root of all evil" - Donald Knuth > > I'm slow sometimes, but I've come to the conclusion that we should remove > section 9.1.1 (DNS Resource Considerations) > > First, most of this information is duplicated from other parts of the draft. > Section 4.6.4 (DNS Lookup Limits) contains the DNS limits, section 3 (SPF > records) already says "ADMDs SHOULD also try to minimize the amount of > other DNS information needed to evaluate a record." > > In particular, the table in section 9.1.1 can be easily misread as saying > that you can have 10 a: mechanisms *and* 10 mx: mechanisms, *and* 10 > include: mechanisms. While I initially liked the table, I now think it > adds more confusion that clarity. Maybe the table can be redesigned, but > no matter what, it should be in section 4.6.4. > > Second, SPF adoption isn't hampered so much by a few extra DNS queries as > much as it is by people having out of date SPF records. Too many people > try to get clever and turn an mx: mechanism into a series of ip4: > mechanisms and then forget to update the SPF record when something changes. > > This section gives undue emphasis on efficiency over reliability. > > Third, this is basically a "how to" document that would be much better > served by existing or new web pages/books. > > Last, if you really want to reduce the number of SPF queries, it would be > much more effective to dust off that SPF record optimizer someone wrote > long ago and try to get it put into the bind distribution. Make it easy to > get it incorporated into godaddy's SPF support and get it running there. > The SPF spec is not an effective place to promote this kind of thing. I have seen people have significant problems with figuring out how to count the lookups to find out of their records would generate permerror or not. Some of this text goes towards solving that problem as well. Do you think that would be worth preserving? Scott K From agthisell@yahoo.com Sat Sep 8 09:25:07 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8192D21F857E for ; Sat, 8 Sep 2012 09:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[AWL=-1.024, BAYES_20=-0.74, MISSING_SUBJECT=1.762] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwX7DueZf4ph for ; Sat, 8 Sep 2012 09:25:07 -0700 (PDT) Received: from nm15-vm4.bullet.mail.ne1.yahoo.com (nm15-vm4.bullet.mail.ne1.yahoo.com [98.138.91.175]) by ietfa.amsl.com (Postfix) with SMTP id E140921F856C for ; Sat, 8 Sep 2012 09:25:06 -0700 (PDT) Received: from [98.138.226.180] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 08 Sep 2012 16:24:56 -0000 Received: from [98.138.89.164] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 08 Sep 2012 16:24:56 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 08 Sep 2012 16:24:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 790345.26077.bm@omp1020.mail.ne1.yahoo.com Received: (qmail 22139 invoked by uid 60001); 8 Sep 2012 16:24:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347121496; bh=ndjJAQ19hsHTHV4TKSoPTyUerbR25pzOE+1CSfedpmM=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:To:MIME-Version:Content-Type; b=y8SmYH1he9SzgUm4wGJOzpp15LnMudhhLI8jsV//TpbjDE40lAw4W6/uKB2kFfumjDG68onmq0ox+k3Zxb0BbsGyaAMUdmVcFU1Qg19KGTc+6EhUnxxzL6unZP0oEn+19NBvUvhQZ48uvcgOIFNnPGWXgzAORPMmJ7xJMpiaMNs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:To:MIME-Version:Content-Type; b=sImxRidQrjLVv771Du5UxNy5r7689JsGhFNkKZ6CeLYsZO5iNigdXdo2lIKMtFbg8TUndjycDdffdjtnyid/pvr2JhrmrAo5Tw6KxdWVsZZST9B+geKnk+cura8bWOhrKUwgRQFeJknMBlRHYB6sWiYnlEqHdLWNlD9SYhN5PYM=; X-YMail-OSG: KJ4NXHYVM1l49kFvbpEN..9gjtcgGz8TmFugyDJlSMVnHW7 WGbjuSGu4ORI3SqFxDGmsIV7.ShwYc5n3rEucSbNwk6pz_xb6XF_M7WQxOVH 8cNQ6BcECHMMKpW7TvxMg_2VcI6FfUOsbqR3tfJgwHbP.e13mIxm6L8Yck6F OKKevHfpxI9i7l9uRtS3J5R3VgfD9FU2S_sopmhNcMztde10P_kgRdJ_EjGV WqolBNiJ12rjmHfi44MVMT1QLXMOT.5yf9DnQUaqNHNBtS1osaOYrrrcwZ3S POHetJD8fJqKr0WmFvVY3gZ9Z6Aa6sG9zBHbTszZrX4FtL.FcgUgvf3UHWRV RP5qROopBN4URl3h0eMRBwBlM3rf0tl3yMptawxiLclzi3dj0qGDz6Le0rvI hp4LhkWBnrj1r60Sdl.ecMfQlSvj348T1LrvJ6EW4_.LOsuA_JA0u_Xqxg4Y uYbVBCdgZjaHTaIVAJAk- Received: from [71.61.133.134] by web125403.mail.ne1.yahoo.com via HTTP; Sat, 08 Sep 2012 09:24:56 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347121496.18738.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Sat, 8 Sep 2012 09:24:56 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] (no subject) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 16:25:07 -0000 > I have seen people have significant problems with figuring out how to count the > lookups to find out of their records would generate permerror or not. Some of > this text goes towards solving that problem as well. Do you think that would > be worth preserving? Yes, I think so, but I'm not sure how to do it. As I said, maybe the table can be redesigned. I initially thought I could quickly give example changes to section 4.6.4, and that's when I really thought about the table and realized it was misleading. I'm glad the DNS limits were moved out of the security section, and I agree, it wasn't originally well written. I may take another stab at rewriting it after I get done with lunch and other exciting chores. ;-) From sm@elandsys.com Sat Sep 8 10:32:59 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B5421F854F for ; Sat, 8 Sep 2012 10:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDWLC5bLEl80 for ; Sat, 8 Sep 2012 10:32:58 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC16621F854D for ; Sat, 8 Sep 2012 10:32:58 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.249]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q88HWg82002846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Sep 2012 10:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347125574; bh=TcrkyGwWuhSEfDH2MWV9ZXoNL1PwXXByHpnClK7n1pU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JeDSh9j9iLsu/G8maDdnqqO3K5iqByEU7eIKscWqRDGE+IiXf1QMVd3sh8oQ9ICkX LlQ2HO7rqMcJUNrNCaeEgLN2MfEmBAwvp5S+X9n7AarMYpf9WBtjiS/vbTn0VL26sv phDPpUxxyb2nawoRo/77jNSTPaz5NrZDsG3sCd94= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347125574; i=@elandsys.com; bh=TcrkyGwWuhSEfDH2MWV9ZXoNL1PwXXByHpnClK7n1pU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=GFgfMy1A7bRE34xnl2ekpiOvbfuqnZAYVNqvL04+MUeO8FhPOg4jQMnL1h2g5cfkD SYzf9WPELy8nxfSDr4ZplrcxGniFNMI+2CpvqwGkJZcgNsjT8QtsDVrYGkbh5xdIt0 WKOcNWw5peUIPBtKKqZxn/zBMCoxJVG100awx/FY= Message-Id: <6.2.5.6.2.20120908095336.0a868640@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 08 Sep 2012 10:20:32 -0700 To: Arthur Thisell From: S Moonesamy In-Reply-To: <1347112012.2101.YahooMailClassic@web125403.mail.ne1.yahoo. com> References: <1347112012.2101.YahooMailClassic@web125403.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 17:32:59 -0000 Hi Arthur, At 06:46 08-09-2012, Arthur Thisell wrote: >charter calls for. No, other drafts aren't mentioned in the >draft. But the only thing I can think of worse than not looking at >earlier SPF drafts to give insight into how SPF should be updated is >not looking at the real-world use of SPF. If you are going to >constrain the WG to looking only at RFC4408, we are going to have >serious problems. There isn't any constraint to ignore operational input. Information about operational issues are taken into account as that is a good way to understand how people actually use a specification. >Just recently, someone mentioned that Courier-MTA returned "unknown" >as an SPF result, which can only be understood by knowning earlier >SPF drafts. RFC4408 was written by people, and people make >mistakes. Some differences between RFC4408 and earlier SPF Yes. >IMHO, when deciding what belongs in RFC4408bis, the most important >thing is real-world usage, then RFC4408, then pre-marid SPF >documents, then post made to various mailing lists, and last, marid >drafts. The later two are pretty weak sources, but still useful. I would prefer not to get into arguments based on pre-marid SPF documents or marid drafts. >OK, that said, the earlier SPF drafts DID NOT have "a deterministic, >powerful, near zero false positive method of SPOOF protection." It >DID NOT require rejecting on SPF fail. There was *always* a debate >about what SPF should do with SPF fail, even in 2003, and at best, >the earlier drafts had contradictory language. It is mentioned in the SPFBIS Charter that: * Revisiting past technical arguments where consensus was reached in the MARID working group, except where review is reasonably warranted based on operational experience. That is the idea I wanted to convey. >Now, back to the charter. During the MARID WG, it was decided to >not have any demands in the SPF draft to require SPF verifiers to >handle SPF fail in any particular way. This group's charter says >we are not supposed to rehash arguments from MARID. Yes. >This discussion needs to be closed, not because insight was brought >up from early SPF drafts, but because it brought up issues that were >resolved in MARID. This discussion has been going on for a while. It has been argued that there is a security issue. If someone raises a security issue, it is better not to close it without assessing whether there is an actual issue and what is the impact on the protocol. There is a rough summary of the discussion at http://www.ietf.org/mail-archive/web/spfbis/current/msg02378.html up to the date of that message. It would be most welcome if someone suggested a way to resolve the issue. Regards, S. Moonesamy (speaking for myself) From sm@elandsys.com Sat Sep 8 10:46:49 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1428121F8567 for ; Sat, 8 Sep 2012 10:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3P-3q0P9Ghs6 for ; Sat, 8 Sep 2012 10:46:48 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 846D321F8559 for ; Sat, 8 Sep 2012 10:46:48 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.249]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q88HkZXb008100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Sep 2012 10:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347126407; bh=EfMTEZSZn/qvGxF2WWMSNM5xCJpY4svItBWPGiqOSEQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=DBefcX/V/YoZ0LXsivoqXxxZLcdPgPY/KobvJQlh0Nft6xROzoTj9QnwdI6MBPKSw YGtHNyEWgKnvsSnZbIqke4EeLrYzB0oBVhJdRygjxnqyFxT5OJ2m7TH0QBtrLeJHx3 eHiX67rcW2BsCOogYV25NJmsEFUzyiqRb03dp46g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347126407; i=@elandsys.com; bh=EfMTEZSZn/qvGxF2WWMSNM5xCJpY4svItBWPGiqOSEQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ny/QBjnka7ikn2e74H7vmVL6AIxcdaTeMfCrtzknM9AI2xDrdmdPQKrrCPiKw9wnY PwUmrNY419sQ+YwN4WafmaqWC8/rxiDfy0mUdgbGqYCQC7LK1GJp12uGblh8hciwXH g4AxYcuMTWHOCnahnPZtJX/T/w1+cN/ASs2SCJ38= Message-Id: <6.2.5.6.2.20120908103252.0a8683b0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 08 Sep 2012 10:38:14 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <504B4A21.5010909@isdg.net> References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120826203640.0c6400e8@resistor.net> <6.2.5.6.2.20120907023043.0aad3700@resistor.net> <3120108.JgnBUtWjyy@scott-latitude-e6320> <504A70B9.9050404@isdg.net> <6.2.5.6.2.20120907152506.0a4f1978@elandnews.com> <504AA159.9060103@isdg.net> <6.2.5.6.2.20120907190137.09217c60@elandnews.com> <504B4A21.5010909@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 17:46:49 -0000 Hi Hector, At 06:37 08-09-2012, Hector Santos wrote: >There is a RFC2119 "prescription" for SMTP level rejection when >Reject-On-Fail is the active protocol in action. The the original >issue #29, I believe, focused on defining With all due respect, I have to point out that there isn't any RFC 2119 key words about that in RFC 4408. > the Marking behavior where there there was no "prescription" per > se. Since that didn't have traction, I had no choice but to > restate it as a security issue (#33). Now we need some level of > semantics, insights, etc, to help mitigate the potential risk > differences between the two type of receiver protocol behavior. I mentioned previously that I would be concerned if a security consideration is used to promote a particular behavior instead of addressing an attack. Regards, S. Moonesamy From hsantos@isdg.net Sat Sep 8 18:30:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58ADA21F84EA for ; Sat, 8 Sep 2012 18:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.695 X-Spam-Level: X-Spam-Status: No, score=-101.695 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHqkPjoWcLC0 for ; Sat, 8 Sep 2012 18:30:46 -0700 (PDT) Received: from dkim.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8967D21F84E6 for ; Sat, 8 Sep 2012 18:30:45 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1613; t=1347154237; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=0doKpKRO1d7SsIfudNby1zDmgr8=; b=Rj9Fu8vC4sGCmR6R4Zvm 4OMPYpummOAouulSgGxHNae5h5rvQkyspfzYTsaFGQyl28QC5x6Hh0jy6eSW/vEs /g+Eeye2QEqqqQakhgX2Oo8cSXRc58wr8l/gwBhnkkrAgd2zAxmGRmwIN/efWdSh Cd/GkShZPFM/GCQNvPco0AA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 08 Sep 2012 21:30:37 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3176017703.1962.5108; Sat, 08 Sep 2012 21:30:36 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1613; t=1347154014; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ETm473q XNG5RlBZhpm2wINw3t8M/8Qp0W+M8EylJR7I=; b=llV5Ivf8kMKbF5YT6nrkrGq Jw5AZZEWUKZ4PRiOVG1Bf3Ml9OXBh1kPRRRHBASa/sNPUECG2qDRqqc58yIhcTRX T4GNHKaEwMzQJElJ7unUUXLw6+uXckv8e8785ZVjWJZMpRPH7RUcjuUzQqTrbvjL FO16M5y2TUo0LS1/wTik= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 08 Sep 2012 21:26:54 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3774812192.9.4912; Sat, 08 Sep 2012 21:26:53 -0400 Message-ID: <504BF14B.1010904@isdg.net> Date: Sat, 08 Sep 2012 21:30:51 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <1347118144.79009.YahooMailClassic@web125401.mail.ne1.yahoo.com> In-Reply-To: <1347118144.79009.YahooMailClassic@web125401.mail.ne1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 01:30:47 -0000 Arthur Thisell wrote: >> I strongly believe there is a serious underestimation of how much current >> implementations and deployments since 2003 support the original >> specification {...} > > This discussion needs to be closed, not because insight was brought up from real-world examples, but because it brought up issues that were resolved in MARID. The actual complete relevant statement was: > I strongly believe there is a serious underestimation of how much current implementations and deployments since 2003 support the original specification "MAY REJECT" with a reject-on-fail implementation and deployment despite if is optional or not. RFC4408 simply relaxed the semantics to make it non-normative to appease the IETF adoption process. What was resolved and what are we referring to about 4408 resolved in MARID? My point is that I believe the security issue #33 can possibly be even more prevalent when many early adopters and established implementations begin to consider and update their existing code with 4408BIS and will find out it will not be so simple to just ACCEPT+MARK SPF FAILED messages. There is a lot of considerations to be made, and namely what ISSUE #33 is describing. Any reference to original specs is a operational realistic fact that there could be a high degree of implementators that still work with the original specs. We are one of them. Is there a suggestion here that most systems do a ACCEPT+MARK and stream separation for SPF failures and therefore, we are the exception to the rule and this issue #33 is in fact a non-issue? -- HLS From superuser@gmail.com Sat Sep 8 23:08:38 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5783F21E8037 for ; Sat, 8 Sep 2012 23:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q093rEuXkOSx for ; Sat, 8 Sep 2012 23:08:37 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA5E21E8034 for ; Sat, 8 Sep 2012 23:08:37 -0700 (PDT) Received: by lbky2 with SMTP id y2so614339lbk.31 for ; Sat, 08 Sep 2012 23:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CwADD0cPvVIqzGlZcRRw9cXCMeQ/4wGwrJnF2TalHbY=; b=bs85utKcqF77SU5hYKNKEwUHV0OaS3bH879PCuXrtBbrjpX1Uxk6cxBIcnbGDskaAs feGMjekpfAl/gw24ajSjKvn0b3TIxqCo7veoBwdA9qBWf9Br3pebgo5DiPi9ndhqZAsy 8MJch3uYWIVuPYqnLrDKBKbpsfYg7t24X4+CvaiE9jXyjcHb5aFjt9aSgtI7J3hWD2br 7oGeCNyanqBc+5QCRvH4ldjCuVDLx90KHF1GcF9se+DURj93cSM22khB0fkfqIvfr06X 8Ks2xnWHP4Ctl0VaevdNmHzwUmCgXuCrxqAhtMrRi8eUMiQP8S2IPpB7DvKXVp96RYMc ILvA== MIME-Version: 1.0 Received: by 10.152.46.203 with SMTP id x11mr9083508lam.46.1347170916386; Sat, 08 Sep 2012 23:08:36 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Sat, 8 Sep 2012 23:08:36 -0700 (PDT) In-Reply-To: <1347112012.2101.YahooMailClassic@web125403.mail.ne1.yahoo.com> References: <1347112012.2101.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Sat, 8 Sep 2012 23:08:36 -0700 Message-ID: From: "Murray S. Kucherawy" To: Arthur Thisell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 06:08:38 -0000 On Sat, Sep 8, 2012 at 6:46 AM, Arthur Thisell wrote: > This almost scary wrong. Yes, this WG is using kitterman-4408bis as a b= ase, as the charter calls for. No, other drafts aren't mentioned in the dr= aft. But the only thing I can think of worse than not looking at earlier = SPF drafts to give insight into how SPF should be updated is not looking at= the real-world use of SPF. If you are going to constrain the WG to looki= ng only at RFC4408, we are going to have serious problems. I think the use of pre-RFC drafts of SPF to make claims of the form "SPF was always about..." also fails to accept current realities. SPF evolved beyond some of those earlier ideas, and unless we can show such evolution was harmful, we shouldn't hold up older drafts as evidence that the earlier ideas were right. > OK, that said, the earlier SPF drafts DID NOT have "a deterministic, powe= rful, near zero false positive method of SPOOF protection." It DID NOT req= uire rejecting on SPF fail. There was *always* a debate about what SPF sh= ould do with SPF fail, even in 2003, and at best, the earlier drafts had co= ntradictory language. That's what I'm talking about, primarily. > Now, back to the charter. During the MARID WG, it was decided to not hav= e any demands in the SPF draft to require SPF verifiers to handle SPF fail = in any particular way. This group's charter says we are not supposed to r= ehash arguments from MARID. > > This discussion needs to be closed, not because insight was brought up fr= om early SPF drafts, but because it brought up issues that were resolved in= MARID. +1 -MSK From superuser@gmail.com Sat Sep 8 23:26:13 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58C421F8493 for ; Sat, 8 Sep 2012 23:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRaM5yOmPnkK for ; Sat, 8 Sep 2012 23:26:13 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8333E21F8489 for ; Sat, 8 Sep 2012 23:26:12 -0700 (PDT) Received: by lahm15 with SMTP id m15so528105lah.31 for ; Sat, 08 Sep 2012 23:26:11 -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=hO9hNaQvxnZDbenmosDjGtq+3IecwRKXXUVNBsaTK9M=; b=LkGc3x88D9VOxKpVNtfigRbjnr2VJfQyY282MOn8KII7FWhG0aIrnjE5yDz+bEPmDZ uIbLNT4ENlROcKBbg302FuPJ5IJcZyh9wfacXUcMdjmT95tElvztWtAW3yUgnmIbIOKk BG3H7PCZTRv1v7y0ku7MlcySlMPTYQochgouSZsNYBZ17HcalMVcp970MP4EjiuHjH0V A2jQ+oUspHsVGMpjU1Mb6sWk217uCn3LW9ML+Nzj7ydhUu31/2B8pW73dV1bKodELlVG FuwCCQq8Ecda/nOnKQ8e78YbQnu7HWPP3d3TaiBBcG/B5S0ONoFZQfM9lg9p03IorBCQ 2ffg== MIME-Version: 1.0 Received: by 10.152.122.9 with SMTP id lo9mr9269727lab.41.1347171970857; Sat, 08 Sep 2012 23:26:10 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Sat, 8 Sep 2012 23:26:10 -0700 (PDT) In-Reply-To: <504B2612.3060606@tana.it> References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120907133424.0922c9c8@resistor.net> <2154218.4qxcVGrrDH@scott-latitude-e6320> <504B2612.3060606@tana.it> Date: Sat, 8 Sep 2012 23:26:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 06:26:13 -0000 On Sat, Sep 8, 2012 at 4:03 AM, Alessandro Vesely wrote: >> The problem I think is that SPF doesn't have a self-contained notion >> of what's good and what's bad. That ties to reputation in some form, >> whether it's a local whitelist, a DNSBL, or a full-blown reputation >> service of some kind. If we can make that clear, then the kind of >> thing you're talking about is a bit more reachable from here. > > Possibly, but that's definitely at a different layer. IMHO, we should > stick to the more basic notion of _registered domain_. That is far from a "basic notion", given it is impossible to determine from the DNS. If you're talking about tying SPF to WHOIS, that's definitely not within scope here. (Andrew has a draft he presented to APPSAWG about being able to identify the registered domain from within the DNS, but it's far from being a complete and deployed idea.) > Dealing with "bad" registered > domains is not our job. SPF won't and can't do anything about it. That part I agree with. >> I don't know where this might land, but in the interest of being brief: >> >> Operators that choose to deliver mail for which SPF produces a "fail" >> result need to understand that they are admitting content that is >> explicitly not authorized by the purported sender. While there are >> known failure modes that can be considered "false negatives"
> references here>, the choice to admit those messages can expose end >> users to harm. > > Yes, that's the essence of #33. > >> This is especially true for domains belonging to known good actors >> that are typically well-behaved; unauthorized mail from those >> sources might well be subjected to much higher skepticism and >> content analysis. > > Again, I disagree with that sentence [see why]. > > False negatives need whitelisting, either on recipient's initiative, > e.g. producing a sample message retrieved from the spam folder, or on > sender's initiative after getting a bounce. That's mark vs reject. Whitelisting is a subset of reputation, and is a concept not in scope for SPF (and please, let's not try to make it so). > Abating false negatives is a distinct problem, unrelated to coping > with them, albeit the abundance of false positives favors marking > inasmuch as the latter allows to cope better. Tackling the abatement > problem is what we need rechartering for. Correct? In a normative sense, I believe so. In an informative sense, I believe we are chartered to do that (as a "clarification"), although we can't continue to pack things into the document under the guise of clarifications when they have one foot in scope and one foot out. We need to resist that kind of bloat. >> SPF does not, however, include the capacity for identifying good >> actors from bad ones; this is the purview of reputation systems in >> their various forms, and is out of scope for this specification. > > Careful: I fully agree, assuming that "bad" is intended to mean the > various shades of gray that upper layer protocols such as reputation > systems will delineate. However, when "bad" means the blatantly > illegal spamming committed by abusing others' domain names, that's > exactly what we want SPF (and DKIM) to deal with. Without the use of some kind of system that assigns value to names, even as simple as a whitelist, how could one write software to detect the kind of abuse your last sentence describes? SPF and DKIM can't identify those cases alone. > -- > [see why]: That sentence misinterprets the statistical skew due to > the fact that well-known domains are abused more often that others, > while false negative ratios are distributed irrespectively of domain's > behavior. Processing based on that can be easily gamed. > > For example, if I put a dot-forward to my new mailbox, paypal > transactions and my mate's postcards will fail alike. The > distribution of false negatives is related to the ease with which > senders adopt my new address. Banks and mailing lists require me to > take special action whereas (some) acquaintances and various kinds of > spammers may do it spontaneously. This is a specific case of the more general problem, for which text already exists in the document. If we intend to call out every fail reason and expound on it with examples and references to statistics, we're never going to be finished. We need to set some boundaries here. -MSK From hsantos@isdg.net Sun Sep 9 01:14:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2D421F84EC for ; Sun, 9 Sep 2012 01:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.02 X-Spam-Level: X-Spam-Status: No, score=-102.02 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TORWowyrBJ4Q for ; Sun, 9 Sep 2012 01:14:16 -0700 (PDT) Received: from mail.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 82DBC21F8504 for ; Sun, 9 Sep 2012 01:14:14 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2520; t=1347178443; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=OdDN6iUQd49F4/2AwWnJW/E4ALc=; b=qT0Vv5wPOiTF+B4Fs9Ax 5ClmeaSRFEll9HCthpdxEZGbj3OsqiYHIcnh/bx4kCxWEyH3s6GiazFojiqGUZQH R3EyIleAwcx4kH5rPF1Qj+ZZOK9tE21Ae8oEsY3v/zaHMe5iKLk6fE5NFTC3SLdC SXey/OITnoc5ixjUJnBski0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 09 Sep 2012 04:14:03 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3200223192.2921.3052; Sun, 09 Sep 2012 04:14:02 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2520; t=1347178221; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=bpy2eFy m32C3ULhdqrL3D+KHdu+8ydGZhkHgc+WozYk=; b=WICISpdLET1c8CkXIlq7xfC giQZybvN6HN8gN4kvh6GiCELY8YlrtnHTSFx6lX47ikdJ7Q5RQffYOn8rkJKml9T A034HLekhXtCHympgCDwHb/y0nNDL+rcUa5/iNILGLNlC+k+P/Ki31XlzaeJMYet 8XPGLe4jMjCppxp03Ats= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 09 Sep 2012 04:10:21 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3799019270.9.7872; Sun, 09 Sep 2012 04:10:20 -0400 Message-ID: <504C5010.80006@isdg.net> Date: Sun, 09 Sep 2012 04:15:12 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <1347112012.2101.YahooMailClassic@web125403.mail.ne1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 08:14:17 -0000 Murray S. Kucherawy wrote: > On Sat, Sep 8, 2012 at 6:46 AM, Arthur Thisell wrote: >> This almost scary wrong. Yes, this WG is using kitterman-4408bis as a base, as the charter calls for. No, other drafts aren't mentioned in the draft. But the only thing I can think of worse than not looking at earlier SPF drafts to give insight into how SPF should be updated is not looking at the real-world use of SPF. If you are going to constrain the WG to looking only at RFC4408, we are going to have serious problems. > > I think the use of pre-RFC drafts of SPF to make claims of the form > "SPF was always about..." also fails to accept current realities. In fact, if read carefully, the thread is exactly showing how the current realities perhaps makes issue #33 more relevant. < SPF evolved beyond some of those earlier ideas, and unless we can show > such evolution was harmful, we shouldn't hold up older drafts as > evidence that the earlier ideas were right. The semantics did not change - only relaxed RFC2119 wise. MAY REJECT --> "can mark or reject outright" RFC4408 was by design 100% (or nearly) compatible with the early adopter establishment - it was a prerequisite. In any case, this thread has turned to something that was never meant to be - not surprising, but lets try not to add more to it than issue #33 states and proposes as a non-normative security precautionary note which I believe does match current realities. No mandate of what you need to do no - just be aware of. As you eluded to, there was perhaps no harm when updating to RFC4408 was done. It was mostly fine tuning (off the top of my head - the limits added). The old spec reference was made only to show perhaps the maturity of early adopters most likely did not change from the standpoint of how the relevant issue of how a SPF -ALL policy is modeled by various implementations. I also suggested that maybe looking at all the published APIs and open source to see what is the OUT OF THE BOX default logic. I am speculating that if indeed a good many followed RFC4408 which is semantically UNCHANGED from early specs with an "MAY REJECT" and no definition toward MARKING, then maybe any new emphasis for MARKING may be be a barrier for some (due to what is described in issue #33). I already stated we can't support this option without a critical change to our code. I could be the only system out there with a REJECT-ON-FAIL behavior. I doubt it though. -- HLS From vesely@tana.it Sun Sep 9 04:21:11 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A1421F84EE for ; Sun, 9 Sep 2012 04:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.624 X-Spam-Level: X-Spam-Status: No, score=-4.624 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlhC72ThqUXW for ; Sun, 9 Sep 2012 04:21:10 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3348021F84DC for ; Sun, 9 Sep 2012 04:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347189665; bh=3X+siwgoJfRvEWqKy28KkbmIn7PTKsc6uO778f1KYL4=; l=527; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Om39zfPuPwTsYZ8GY7rQTTme8sWELTDHGXtUB9tymvHVrhzie7ZzUbcQmS1+XhGJ8 k1gxOtm8nT9sNet1L8tITP6fqaMOsLvTd0mVJrDbN5ziolfj4Qj3/bKRA7gGRBNF0Q tsShwHH/jlLpVDXxF6/IKJGy2atmx1Ow+Dlfwtdc= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 09 Sep 2012 13:21:05 +0200 id 00000000005DC03F.00000000504C7BA1.00004B71 Message-ID: <504C7BA0.8000003@tana.it> Date: Sun, 09 Sep 2012 13:21:04 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120907150642.0aad3d58@elandnews.com> <5010039.ki68fGPhdZ@scott-latitude-e6320> In-Reply-To: <5010039.ki68fGPhdZ@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Extensions to SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 11:21:11 -0000 On Sat 08/Sep/2012 01:33:29 +0200 Scott Kitterman wrote: > > I'll confess that "document widely deployed extensions to SPF that > have been developed since [RFC4408] was published." is not > identical to "addition of any enhancements that have already gained > widespread support", but I believe the meanings are similar > enough. I thought an "SPF extension" was a change associated with the introduction of a new modifier. We have a registry for those. Are we going to document SPF extensibility in that sense? From vesely@tana.it Sun Sep 9 04:21:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A24F21F84EA for ; Sun, 9 Sep 2012 04:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.332 X-Spam-Level: X-Spam-Status: No, score=-4.332 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncL7db4lmc6e for ; Sun, 9 Sep 2012 04:21:26 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id CE9D321F84DC for ; Sun, 9 Sep 2012 04:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347189685; bh=SLE2ivR9eL7vhMVvIKtxD1Ga99fUhOBrAMAF8gdooFk=; l=1716; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=dRmFomwMq/nFrOgNrSdeyufR+SHqlM08yowm/VExg0m/PnvCIo2C5BZRzeaKmAxRe YPIuZ9V3NxrM6Xs+b/poBdksSkL/HdmHTpGVot4z43/DKaCA9Z/nNsqOZbqGbE6IJm 0sTJ4KqfLqmTpsNe8HPONIi3ldvdb4y7bM/ZgzNg= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 09 Sep 2012 13:21:25 +0200 id 00000000005DC03F.00000000504C7BB5.00004BA8 Message-ID: <504C7BB5.8050901@tana.it> Date: Sun, 09 Sep 2012 13:21:25 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120824173829.13742.qmail@joyce.lan> <504B2612.3060606@tana.it> <1902393.9yqKrzvbJL@scott-latitude-e6320> In-Reply-To: <1902393.9yqKrzvbJL@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 11:21:26 -0000 On Sat 08/Sep/2012 15:35:16 +0200 Scott Kitterman wrote: > On Saturday, September 08, 2012 01:03:46 PM Alessandro Vesely wrote: >> On Sat 08/Sep/2012 00:36:29 +0200 Murray S. Kucherawy wrote: >>> On Fri, Sep 7, 2012 at 2:05 PM, Scott Kitterman wrote: >>> >>>> For "good" domains, not authorized mail is substantially more >>>> likely to be "bad" than authorized domains. >> >> I don't agree with the last sentence, unless "good" is intended to >> mean relaxed, broad authorizations. Mail can be forwarded without >> notice and without rewriting --so as to fool the smtp.mailfrom SPF >> check-- irrespectively of the domain's goodness. > > I said more likely and you said it's not certain, so I don't see > where the disagreement is? In glimpsing some kind of cause-effect relationship with goodness. >>> SPF does not, however, include the capacity for identifying good >>> actors from bad ones; this is the purview of reputation systems in >>> their various forms, and is out of scope for this specification. >> >> Careful: I fully agree, assuming that "bad" is intended to mean the >> various shades of gray that upper layer protocols such as reputation >> systems will delineate. However, when "bad" means the blatantly >> illegal spamming committed by abusing others' domain names, that's >> exactly what we want SPF (and DKIM) to deal with. > > No. They don't. It is a fallacy to claim that SPF deals with the > "good"/"bad" of anything at all. It deals with authorized/not > authorized. I considered them synonyms, good ~= authorized, and bad ~= not authorized. Indeed, I was pointing out that the term "bad" is ambiguous and we need to be careful :-/ From vesely@tana.it Sun Sep 9 04:21:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B270221F84E6 for ; Sun, 9 Sep 2012 04:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.616 X-Spam-Level: X-Spam-Status: No, score=-4.616 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wSHKIyd9LHF for ; Sun, 9 Sep 2012 04:21:46 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9076621F84DC for ; Sun, 9 Sep 2012 04:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347189705; bh=RWlNjgJGGjVp12kma7CTd3TJgUAupV1oBO6pxsPKhu0=; l=4671; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ehWTYGWZJ6eieP7zB8qsthmLARi+tMQxA2IwM+OqNol3z6B2HYo68eThbIn8ybP86 OIBWRvmZes1N29+KoGW4jsAVtRyr76cm93a1Kz2yj48HNOf404+QCeeB+Eoh0hYyou 2CWjGUwpebNcnHlIrXTM2beT7tO3gkct6izP6oZo= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 09 Sep 2012 13:21:45 +0200 id 00000000005DC03F.00000000504C7BC9.00004BC4 Message-ID: <504C7BC8.6060204@tana.it> Date: Sun, 09 Sep 2012 13:21:44 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120907133424.0922c9c8@resistor.net> <2154218.4qxcVGrrDH@scott-latitude-e6320> <504B2612.3060606@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 11:21:46 -0000 On Sun 09/Sep/2012 08:26:10 +0200 Murray S. Kucherawy wrote: > >>> The problem I think is that SPF doesn't have a self-contained notion >>> of what's good and what's bad. That ties to reputation in some form, >>> whether it's a local whitelist, a DNSBL, or a full-blown reputation >>> service of some kind. If we can make that clear, then the kind of >>> thing you're talking about is a bit more reachable from here. >> >> Possibly, but that's definitely at a different layer. IMHO, we should >> stick to the more basic notion of _registered domain_. > > That is far from a "basic notion", given it is impossible to determine > from the DNS. I assume you mean one cannot determine the associated ADMD. Levels are also fuzzy, e.g. paypal.com vs co.uk. However, if you are able to look it up on the DNS, it must belong to some registered domain, unless the DNS server in use plays funny tricks. In addition, everybody means the same thing when they talk about a "registered domain". Compared to terms like "good", "bad", and "reputation", it is astoundingly well defined. > If you're talking about tying SPF to WHOIS, that's definitely not > within scope here. Agreed. > (Andrew has a draft he presented to APPSAWG about being able to > identify the registered domain from within the DNS, but it's far from > being a complete and deployed idea.) Weirds is also promising. >> False negatives need whitelisting, either on recipient's initiative, >> e.g. producing a sample message retrieved from the spam folder, or on >> sender's initiative after getting a bounce. That's mark vs reject. > > Whitelisting is a subset of reputation, and is a concept not in scope > for SPF (and please, let's not try to make it so). The point here is to characterize the difference between mark and reject. I agree that whitelisting is not the only means, but it is a well known and widely used workaround. >> Abating false negatives is a distinct problem, unrelated to coping >> with them, albeit the abundance of false positives favors marking >> inasmuch as the latter allows to cope better. Tackling the abatement >> problem is what we need rechartering for. Correct? > > In a normative sense, I believe so. In an informative sense, I > believe we are chartered to do that (as a "clarification"), although > we can't continue to pack things into the document under the guise of > clarifications when they have one foot in scope and one foot out. We > need to resist that kind of bloat. Definitely. Normative language forces a clear specification, while the so-called clarifications, even if they are substantially correct, tend to leave too much rope to different interpretations and gauging of their applicability. That way, they might well turn out to actually obfuscate a point. IMHO, without updating the charter, we cannot significantly better the current state of affairs. >>> SPF does not, however, include the capacity for identifying good >>> actors from bad ones; this is the purview of reputation systems in >>> their various forms, and is out of scope for this specification. >> >> Careful: I fully agree, assuming that "bad" is intended to mean the >> various shades of gray that upper layer protocols such as reputation >> systems will delineate. However, when "bad" means the blatantly >> illegal spamming committed by abusing others' domain names, that's >> exactly what we want SPF (and DKIM) to deal with. > > Without the use of some kind of system that assigns value to names, > even as simple as a whitelist, how could one write software to detect > the kind of abuse your last sentence describes? Results from DNS imply a domain is registered. Using them, software can address the basic sense of "bad". It can combine the results of different identities, for example. > SPF and DKIM can't identify those cases alone. Modulo false negatives, they can. DKIM would need a new, robust canonicalization, and SPF a revised use of HELO identities. Which fruit is hanging lower? >> For example, if I put a dot-forward to my new mailbox [...] > > This is a specific case of the more general problem, for which text > already exists in the document. If we intend to call out every fail > reason and expound on it with examples and references to statistics, > we're never going to be finished. We need to set some boundaries > here. IMHO, we need to consider fewer fail reasons, but more effectively. The current spec suggests many possible behaviors to be operated by both SMTP servers and clients. It doesn't say who to blame for a false negative, though. From vesely@tana.it Sun Sep 9 04:43:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A637D21F84FA for ; Sun, 9 Sep 2012 04:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.623 X-Spam-Level: X-Spam-Status: No, score=-4.623 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KjBOKUZDYFG for ; Sun, 9 Sep 2012 04:43:22 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E009121F84F8 for ; Sun, 9 Sep 2012 04:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347191000; bh=0Iq/ExZ9Un1tKFuDXnBg7dOOWtAV3/jnxEHgXlAs1XE=; l=341; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=P4cIaaJLfaMP25pTXQsRCvpmx3tOWbMEEFf3hBuTBn2LpMUUSnHxDkxEugBzdMv1i nwftAPSiHY/lejfYhOCk+dXPhEtK+lcivfz3oxnf47fJwwMS9fenUZ70x1l4ZksVL7 gJB4lZenyak8yZpGWhov1mVmVqGYjO97udlHZRiE= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 09 Sep 2012 13:43:20 +0200 id 00000000005DC046.00000000504C80D8.00005051 Message-ID: <504C80D7.1080800@tana.it> Date: Sun, 09 Sep 2012 13:43:19 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1347117702.29062.YahooMailClassic@web125401.mail.ne1.yahoo.com> In-Reply-To: <1347117702.29062.YahooMailClassic@web125401.mail.ne1.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] remove section 9.1.1 DNS Resource Considerations X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 11:43:22 -0000 On Sat 08/Sep/2012 17:21:42 +0200 Arthur Thisell wrote: > > In particular, the table in section 9.1.1 can be easily misread as > saying that you can have 10 a: mechanisms *and* 10 mx: mechanisms, Perhaps that fixes it: OLD Section 4.6.4 specifies the limits receivers have to use. NEW Limits are specified in Section 4.6.4. From barryleiba.mailing.lists@gmail.com Sun Sep 9 07:19:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5122521F847B for ; Sun, 9 Sep 2012 07:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.942 X-Spam-Level: X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+KVG6WGPbzw for ; Sun, 9 Sep 2012 07:19:45 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F15B21F846B for ; Sun, 9 Sep 2012 07:19:45 -0700 (PDT) Received: by lahm15 with SMTP id m15so647572lah.31 for ; Sun, 09 Sep 2012 07:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=os8Bl3bTS6ZEFqen5fFYHvqWUzSVtzVxc8/KljX7keU=; b=MiZPGEIp6G1Flre9WuJPzKSel+FEbHg8vYetByZWwQiGvjKrnqp0k1e2SCo+lPfvnh cUVJuysfe7slXdMK8XMsdbDwatPK6s4Ih5fvEvtIsgjD9XVfL+OeKJitD32IPpulUNBj Iff0AE31Jfv3HZcljuGinQrQy7QVzp18m7MkzCX/LPBrIjCyQTbVo9kk136jdnAaG+9/ vX3rymhy5UQWfO/x53TCygIvl9Sz6eMIYi6AJNLivBqADtPg5p6C7XejyPeDToZNNI0X 5U6bxICHlsICNdLeCGyGmu86jr4bMQn6KUGRVFgQ+HSVC38bFxeq+yl/NizcTkFD831b f7zA== MIME-Version: 1.0 Received: by 10.112.51.228 with SMTP id n4mr4010968lbo.55.1347200383837; Sun, 09 Sep 2012 07:19:43 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Sun, 9 Sep 2012 07:19:43 -0700 (PDT) In-Reply-To: <1663351.5sAq1NzcAL@scott-latitude-e6320> References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <1433326.JAlz6WYfAq@scott-latitude-e6320> <6.2.5.6.2.20120906091220.09fcf7a8@resistor.net> <1663351.5sAq1NzcAL@scott-latitude-e6320> Date: Sun, 9 Sep 2012 10:19:43 -0400 X-Google-Sender-Auth: ONGkneKur5ZrqgXy8olL_Amk8RU Message-ID: From: Barry Leiba To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 14:19:46 -0000 Comment only on the charter issue here, from the irresponsible AD; the chairs should discuss this with the responsible AD, regardless of where the WG ultimately decides to go with it, to get a sense of how he sees the charter in this regard. > 2. Remove all of Section 9 and move it to a new document. As it stands, this > would require a normative reference from 4408bis to the new document. This > new document would be outside our WG charter. I do not think it would be > appropriate to make our chartered deliverable dependent of work no one is > chartered to do, so I believe this would require rechartering to add the new > deliverable. This would result in two documents that supersede RFC 4408 The charter says this: Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language. It does not say that changes to the *document* will be so limited, but that changes to the *specification* will be. I believe that it's a question of working-group management to decide whether a specification lies entirely in one document or is split among two or more. I do *not* think a rechartering is needed if the working group decides that the best way to publish the specification is in two documents, as long as the intent of the above charter text is met. I think such a split *can be* within the current charter if it's done right. Partly for that reason and partly because of where the tendrils of the specification lie, I *do* think that the documents would all have to normatively reference each other. And, of course, the milestones would need to be changed, which the chairs can do in consultation with the responsible AD. *If* this path is chosen, I would say that it should be the main protocol specification document that officially does the "Obsoletes 4408". But, yes, the SPF specification would now be in a set of documents, and Scott is right that that can cause some amount of confusion. But a number of important specs have done that: MIME, notably, many years ago; HTTP more recently, splitting RFC 2616 into seven parts for the "bis" work. I'm not addressing whether or not it's a good idea to do such a split here, but only what my opinion of the split is as a process matter. Barry, kibitzing AD From spf2@kitterman.com Sun Sep 9 08:54:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118D521F8513 for ; Sun, 9 Sep 2012 08:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXri+d2tuYkC for ; Sun, 9 Sep 2012 08:54:42 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 776EE21F84F8 for ; Sun, 9 Sep 2012 08:54:42 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id B12F2D04087; Sun, 9 Sep 2012 10:54:40 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347206080; bh=xMJ5z5nEqBYIykN9DIOPRQ1Jhzx62Em7YgEJijrWB6k=; h=In-Reply-To:References:Subject:From:Date:To:From; b=D2O1f9WL23AXXTN4TEycGNqerzyKeK+DcNoxSwYmjwu4YbaR3HiNT/7l9wzwGYiit eIBzRVojv7+qlfUK0aG5971io0bTEtqg8md3rEoqtG5xtx8fz+kgqOKNa/yIXTcwrG 2kp3OeNECS5J/PV/JM0HM6wqe0GcAaDMMgGvMka8= Received: from [192.168.111.104] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 22D79D04085; Sun, 9 Sep 2012 10:54:39 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <504C7BA0.8000003@tana.it> References: <6.2.5.6.2.20120907150642.0aad3d58@elandnews.com> <5010039.ki68fGPhdZ@scott-latitude-e6320> <504C7BA0.8000003@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 09 Sep 2012 11:54:38 -0400 To: spfbis@ietf.org Message-ID: <8feeeec2-5e54-470e-9bb8-45b80f11339d@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Extensions to SPF X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 15:54:43 -0000 Alessandro Vesely wrote: >On Sat 08/Sep/2012 01:33:29 +0200 Scott Kitterman wrote: >> >> I'll confess that "document widely deployed extensions to SPF that >> have been developed since [RFC4408] was published." is not >> identical to "addition of any enhancements that have already gained >> widespread support", but I believe the meanings are similar >> enough. > >I thought an "SPF extension" was a change associated with the >introduction of a new modifier. We have a registry for those. > >Are we going to document SPF extensibility in that sense? No. That's already documented in a standards track RFC. 4408bis needs to update the registry (recently discussed, but not in -07), but the basic registry doesn't need redocumenting. Scott K From spf2@kitterman.com Sun Sep 9 08:59:53 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C95221F8539 for ; Sun, 9 Sep 2012 08:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwrJPkLsgAZ9 for ; Sun, 9 Sep 2012 08:59:52 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF7B21F8530 for ; Sun, 9 Sep 2012 08:59:52 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id B0367D04087; Sun, 9 Sep 2012 10:59:51 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347206391; bh=vQUMRQ6DCyoYOHbQ8ACM+unBab2H9EBwOWYeQcQyymg=; h=In-Reply-To:References:Subject:From:Date:To:From; b=AmfQ3Xo/iEdfMnVnK8pewLFul3f9JvEgeGYrBLsuA3ZljGTMRw6Oi49hMud8uGJHZ PUzyADPptD3eaquEGlu/ZAhSq8QaaeZ7J31eSgPwy/tI5I5jOxBOw7VuVo5E4cszvd 4sYUUa5BcGvBkXyUQEZSg2lic/A5GktvhcTNV3KM= Received: from [192.168.111.104] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 7330DD04085; Sun, 9 Sep 2012 10:59:51 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <504C7BB5.8050901@tana.it> References: <20120824173829.13742.qmail@joyce.lan> <504B2612.3060606@tana.it> <1902393.9yqKrzvbJL@scott-latitude-e6320> <504C7BB5.8050901@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 09 Sep 2012 11:59:49 -0400 To: spfbis@ietf.org Message-ID: <0aae36bd-9537-41fa-9a96-e572da1b4f70@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 15:59:53 -0000 Alessandro Vesely wrote: >On Sat 08/Sep/2012 15:35:16 +0200 Scott Kitterman wrote: >> On Saturday, September 08, 2012 01:03:46 PM Alessandro Vesely wrote: >>> On Sat 08/Sep/2012 00:36:29 +0200 Murray S. Kucherawy wrote: >>>> On Fri, Sep 7, 2012 at 2:05 PM, Scott Kitterman > wrote: >>>> >>>>> For "good" domains, not authorized mail is substantially more >>>>> likely to be "bad" than authorized domains. >>> >>> I don't agree with the last sentence, unless "good" is intended to >>> mean relaxed, broad authorizations. Mail can be forwarded without >>> notice and without rewriting --so as to fool the smtp.mailfrom SPF >>> check-- irrespectively of the domain's goodness. >> >> I said more likely and you said it's not certain, so I don't see >> where the disagreement is? > >In glimpsing some kind of cause-effect relationship with goodness. This isn't about cause and effect, it's about statistics. >>>> SPF does not, however, include the capacity for identifying good >>>> actors from bad ones; this is the purview of reputation systems in >>>> their various forms, and is out of scope for this specification. >>> >>> Careful: I fully agree, assuming that "bad" is intended to mean the >>> various shades of gray that upper layer protocols such as reputation >>> systems will delineate. However, when "bad" means the blatantly >>> illegal spamming committed by abusing others' domain names, that's >>> exactly what we want SPF (and DKIM) to deal with. >> >> No. They don't. It is a fallacy to claim that SPF deals with the >> "good"/"bad" of anything at all. It deals with authorized/not >> authorized. > >I considered them synonyms, good ~= authorized, and bad ~= not >authorized. Indeed, I was pointing out that the term "bad" is >ambiguous and we need to be careful :-/ They aren't entirely unrelated in some cases, but one does need to be careful as they are different concepts. Scott K From superuser@gmail.com Sun Sep 9 09:44:07 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF6F21F8539 for ; Sun, 9 Sep 2012 09:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPfOPDiP3m0A for ; Sun, 9 Sep 2012 09:44:06 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 851B921F849C for ; Sun, 9 Sep 2012 09:44:06 -0700 (PDT) Received: by lahm15 with SMTP id m15so692296lah.31 for ; Sun, 09 Sep 2012 09:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zDal2ij3pbLgNNWZTL02f2xmqpV47vxf1BdWNgEVsCo=; b=rW2zUCcek6EJAiXUaMhCzu34WH1y6VM1LknFDGJLkjpYTzVkOGnx4iCiaXQnQCx8WV T4MNhn+WqIXiqD2WY0V6p/onwzd/nkJx4iwDU1VFI40OIpAsL7XXrU6EaerfaWQ/bZx7 1dAXIkWD5yaXBwP10JH7Jd0Bvh5cJiK2xe9BLt93gkKRk+UMJ++SrHPre6q9Cyzp7Fq5 xyxGism1MHeItOrzdhUBYJD8WFqmHDhRR0v07ZnIw0E7TBOl8icpVcN4vjP3OpP6Xusz s6I2VLHtij275TD01Ee472qTdwXdhLQWdby04vsxtYMkptuM4nGZm3yqH4MCNu2M1zyf Ap6A== MIME-Version: 1.0 Received: by 10.112.88.73 with SMTP id be9mr4128681lbb.72.1347209045474; Sun, 09 Sep 2012 09:44:05 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Sun, 9 Sep 2012 09:44:05 -0700 (PDT) In-Reply-To: <504C80D7.1080800@tana.it> References: <1347117702.29062.YahooMailClassic@web125401.mail.ne1.yahoo.com> <504C80D7.1080800@tana.it> Date: Sun, 9 Sep 2012 09:44:05 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] remove section 9.1.1 DNS Resource Considerations X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 16:44:07 -0000 On Sun, Sep 9, 2012 at 4:43 AM, Alessandro Vesely wrote: > Perhaps that fixes it: > > OLD > Section 4.6.4 specifies the limits receivers have to use. > > NEW > Limits are specified in Section 4.6.4. Those are synonymous to me, other than the fact that the burden is not clearly on receivers. Is that the intent? -MSK From superuser@gmail.com Sun Sep 9 09:56:53 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DE421F8552 for ; Sun, 9 Sep 2012 09:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqKH1w91g+mr for ; Sun, 9 Sep 2012 09:56:52 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C78F421F8546 for ; Sun, 9 Sep 2012 09:56:51 -0700 (PDT) Received: by lbky2 with SMTP id y2so786102lbk.31 for ; Sun, 09 Sep 2012 09:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ASF4RQyUuQzcFA5eSBDEmCkLOg0UX90iixom8scIuWM=; b=XlEDTEtcVqGsb5lIY85m17u41WZ3bgBTkJpMXneh2mM9l3776zFkI5eeiBC+2UW79P bqXbtpA4uw9A2KvgjHYwRWfId3R4ItNhNm+p++3Xs3qyT5t1o8fgCY6EbMOyQ2cUuR5A fbkUB+z6lZCoMBDjDF7HV/1xkajH/a4KjMT0gRtv1CAGS7T+7xQ1aO+IUhT30J2Mdx/v 1ijeSfRZJg8X0ePHIlxhvyNCVz95/RhzFryoGJU7YBuYrLgeWCHso5I+euF+EjWIsDnY wLeByhrZSxSB2aZ7SxrjhPVQeVbscz1V4V3tZpiF4dLo/NcqA1aeI3JxxC0L4al+qrpy AWKA== MIME-Version: 1.0 Received: by 10.112.9.133 with SMTP id z5mr4130254lba.69.1347209810634; Sun, 09 Sep 2012 09:56:50 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Sun, 9 Sep 2012 09:56:50 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <1433326.JAlz6WYfAq@scott-latitude-e6320> <6.2.5.6.2.20120906091220.09fcf7a8@resistor.net> <1663351.5sAq1NzcAL@scott-latitude-e6320> Date: Sun, 9 Sep 2012 09:56:50 -0700 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 16:56:53 -0000 On Sun, Sep 9, 2012 at 7:19 AM, Barry Leiba wrote: > I'm not addressing whether or not it's a good idea to do such a split > here, but only what my opinion of the split is as a process matter. All of that is my understanding as well. My vision of a split (which still rises only to the level of "something worth considering") involves putting all the protocol-specific stuff in one document, which is itself 4408bis, and then all the deployment guidance in another. In essence, all of the normative stuff is in one document along with only critical informative stuff, and everything else goes in the other. I'm not sure about the mandatory normative references stuff; I suggest the informational doesn't need to be a normative reference of the proposed standard merely because the charter said they have to be produced together, but I do agree they need to come out pretty much simultaneously. Barry listed a few examples of specifications that are multi-document. A couple of others include the DNS core (1034 and 1035) and more recently DKIM (core, threats document, deployment advice, overview, ADSP, and use of DKIM with mailing lists). I have it on my to-do list to produce, hopefully this weekend, an outline-level overview of what I have in mind for the WG to consider, and I'm happy to help do the work of the split rather than saddling Scott with all of it. -MSK From dhc@dcrocker.net Sun Sep 9 10:04:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D33721F8550 for ; Sun, 9 Sep 2012 10:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id On1JRGxS00jT for ; Sun, 9 Sep 2012 10:04:46 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 90DF521F8534 for ; Sun, 9 Sep 2012 10:04:46 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q89H4hef028844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 9 Sep 2012 10:04:44 -0700 Message-ID: <504CCC1D.1060301@dcrocker.net> Date: Sun, 09 Sep 2012 10:04:29 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <1347117702.29062.YahooMailClassic@web125401.mail.ne1.yahoo.com> <504C80D7.1080800@tana.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 09 Sep 2012 10:04:44 -0700 (PDT) Cc: spfbis@ietf.org, Alessandro Vesely Subject: Re: [spfbis] remove section 9.1.1 DNS Resource Considerations X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 17:04:47 -0000 On 9/9/2012 9:44 AM, Murray S. Kucherawy wrote: > On Sun, Sep 9, 2012 at 4:43 AM, Alessandro Vesely wrote: >> Perhaps that fixes it: >> >> OLD >> Section 4.6.4 specifies the limits receivers have to use. >> >> NEW >> Limits are specified in Section 4.6.4. > > Those are synonymous to me, other than the fact that the burden is not > clearly on receivers. Is that the intent? The old language is pseudo-normative. Not formally normative, but semantically very much reads as normative. The proposed text is cleaner, IMO. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Sun Sep 9 10:08:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA8D21F8460 for ; Sun, 9 Sep 2012 10:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kPrReMOHsJl for ; Sun, 9 Sep 2012 10:08:27 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 101A421F845E for ; Sun, 9 Sep 2012 10:08:26 -0700 (PDT) Received: by lahm15 with SMTP id m15so699658lah.31 for ; Sun, 09 Sep 2012 10:08:26 -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=eIjmN5Qpzl5uaYYtL9Us/stslH87SecK5HO2tCUqohY=; b=fLEklT4PwihNgDiAO6J7+uI5oz4dbCv+h0Zno3wpL/stwfs6VNAFrYcXjzN4uPzoUe XVKSfjfV74QhOIrqsiOUc5evhUvSrrIBUl2SyTPqpD74keziLt27eHrNyrqj11oUohbV aZcQ+3tZMXXh8iOYjLDn6fz04V4cP3p5J58rBmoUiSp2ChpkQ0uyeKYllFXNsuQNE0SE aCCDMjvQvXFqbPXq0R0OTudGpJg6PisggHbkcY+RkOKo1SRqgzFKZkvjNkUNZjFredRw Np0Z/FACqrZ0EFPbb2ujoAAkVDVGJOrk6MXJ21XcLzc50WCOc4myS1psj9WzVV++uYfG kn3A== MIME-Version: 1.0 Received: by 10.152.122.9 with SMTP id lo9mr10384599lab.41.1347210505977; Sun, 09 Sep 2012 10:08:25 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Sun, 9 Sep 2012 10:08:25 -0700 (PDT) In-Reply-To: <504C7BC8.6060204@tana.it> References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120907133424.0922c9c8@resistor.net> <2154218.4qxcVGrrDH@scott-latitude-e6320> <504B2612.3060606@tana.it> <504C7BC8.6060204@tana.it> Date: Sun, 9 Sep 2012 10:08:25 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 17:08:28 -0000 On Sun, Sep 9, 2012 at 4:21 AM, Alessandro Vesely wrote: > In addition, everybody means the same thing when they talk about a > "registered domain". Compared to terms like "good", "bad", and > "reputation", it is astoundingly well defined. For humans, not for software. > The point here is to characterize the difference between mark and > reject. More than what's already in the document? Really, I think we've beaten this one to death. We could define "mark" and "reject" in Section 1 somewhere if it would make people happy, but really I don't find that necessary. > I agree that whitelisting is not the only means, but it is a > well known and widely used workaround. It's still a notion not in SPF's scope. SPF itself doesn't (and shouldn't) talk about how to decide what a good domain is. >> In a normative sense, I believe so. In an informative sense, I >> believe we are chartered to do that (as a "clarification"), although >> we can't continue to pack things into the document under the guise of >> clarifications when they have one foot in scope and one foot out. We >> need to resist that kind of bloat. > > Definitely. Normative language forces a clear specification, while > the so-called clarifications, even if they are substantially correct, > tend to leave too much rope to different interpretations and gauging > of their applicability. That way, they might well turn out to > actually obfuscate a point. OK, since you agree, then let's go one step further: All of the stuff we're talking about here amounts to more clarification text that we don't actually need. > IMHO, without updating the charter, we cannot significantly better the > current state of affairs. Hooray! >> Without the use of some kind of system that assigns value to names, >> even as simple as a whitelist, how could one write software to detect >> the kind of abuse your last sentence describes? > > Results from DNS imply a domain is registered. Using them, software > can address the basic sense of "bad". It can combine the results of > different identities, for example. Those exceed the scopes of the protocols themselves and extend into the realm of either deployment guides or even applicability statements. They're bloat for the core protocols. >> SPF and DKIM can't identify those cases alone. > > Modulo false negatives, they can. DKIM would need a new, robust > canonicalization, and SPF a revised use of HELO identities. Which > fruit is hanging lower? This isn't the right venue to discuss such a DKIM extension, though you can suggest it on ietf-dkim if so inclined. But (and I cringe asking this) what are you suggesting with respect to HELO? >>> For example, if I put a dot-forward to my new mailbox [...] >> >> This is a specific case of the more general problem, for which text >> already exists in the document. If we intend to call out every fail >> reason and expound on it with examples and references to statistics, >> we're never going to be finished. We need to set some boundaries >> here. > > IMHO, we need to consider fewer fail reasons, but more effectively. > > The current spec suggests many possible behaviors to be operated by > both SMTP servers and clients. It doesn't say who to blame for a > false negative, though. I think the use of "blame" here is a hornet's nest. Explaining the causes of "false" negatives (false for humans, not for the protocol) is fine, but pointing fingers about what's "broken" will only get us into trouble. -MSK From dhc@dcrocker.net Sun Sep 9 10:17:07 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529B321F8545 for ; Sun, 9 Sep 2012 10:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOiXeHnrCcgN for ; Sun, 9 Sep 2012 10:17:06 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id BCE6721F8523 for ; Sun, 9 Sep 2012 10:17:06 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q89HH2Xo028990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 9 Sep 2012 10:17:02 -0700 Message-ID: <504CCF00.3080305@dcrocker.net> Date: Sun, 09 Sep 2012 10:16:48 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <1433326.JAlz6WYfAq@scott-latitude-e6320> <6.2.5.6.2.20120906091220.09fcf7a8@resistor.net> <1663351.5sAq1NzcAL@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 09 Sep 2012 10:17:02 -0700 (PDT) Cc: spfbis@ietf.org, Barry Leiba , Scott Kitterman Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 17:17:07 -0000 On 9/9/2012 9:56 AM, Murray S. Kucherawy wrote: > and I'm happy to help do the work of the split rather than saddling > Scott with all of it. me too. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Sun Sep 9 10:20:42 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A518F21F853B for ; Sun, 9 Sep 2012 10:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHxYVIonlGW2 for ; Sun, 9 Sep 2012 10:20:42 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0590321F852B for ; Sun, 9 Sep 2012 10:20:42 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q89HKd0u029054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 9 Sep 2012 10:20:40 -0700 Message-ID: <504CCFDA.9060800@dcrocker.net> Date: Sun, 09 Sep 2012 10:20:26 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Barry Leiba References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <1433326.JAlz6WYfAq@scott-latitude-e6320> <6.2.5.6.2.20120906091220.09fcf7a8@resistor.net> <1663351.5sAq1NzcAL@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 09 Sep 2012 10:20:40 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 17:20:42 -0000 On 9/9/2012 7:19 AM, Barry Leiba wrote: > Partly for that reason and partly because of where the tendrils of the > specification lie, I *do* think that the documents would all have to > normatively reference each other. That depends entirely on the nature of the document divisions that are done. My usual view is that documents that need to normatively refer to each other have probably done a poor split. Some more hierarchical, with normative pointers in one direction, should be greatly preferred. An example of the reason for this is that mutual normative reference is likely to cause problems when one of the documents is revised. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Sun Sep 9 10:34:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC0A21F84B2 for ; Sun, 9 Sep 2012 10:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqOEk0GVzl-I for ; Sun, 9 Sep 2012 10:34:31 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0913221F84A1 for ; Sun, 9 Sep 2012 10:34:31 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 2F4FDD04087; Sun, 9 Sep 2012 12:34:30 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347212070; bh=NjGYW653ZeM0NYwT/8Cmrtlew13lxqIiBaUmUYMqpWo=; h=In-Reply-To:References:Subject:From:Date:To:From; b=QZWNEL1irFaZuL/UT7eLAlonAiC5hYB35BCYiehrveUrbFXQOM41ILIEe2OhTN388 mUpfA+iDsSLBW0fxacOfdlRBjGUkxLVCjkCT7/pZ5W/rvdqv8c3tsfd0X0VQYB0E8I yh4fhv8pu8Lg2qglOoJY2OQPKb46/eS4MN7YEKjU= Received: from [192.168.111.104] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id C7843D04005; Sun, 9 Sep 2012 12:34:29 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <20120824173829.13742.qmail@joyce.lan> <6.2.5.6.2.20120907133424.0922c9c8@resistor.net> <2154218.4qxcVGrrDH@scott-latitude-e6320> <504B2612.3060606@tana.it> <504C7BC8.6060204@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 09 Sep 2012 13:34:26 -0400 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 17:34:31 -0000 "Murray S. Kucherawy" wrote: >On Sun, Sep 9, 2012 at 4:21 AM, Alessandro Vesely >wrote: .... >> Modulo false negatives, they can. DKIM would need a new, robust >> canonicalization, and SPF a revised use of HELO identities. Which >> fruit is hanging lower? > >This isn't the right venue to discuss such a DKIM extension, though >you can suggest it on ietf-dkim if so inclined. But (and I cringe >asking this) what are you suggesting with respect to HELO? ... Let me suggest that whatever it is, there is a 100% chance it's out of our current scope so it should either be discussed elsewhere or here after the chartered work is done. Here, at this time, it's a distraction. Scott K From agthisell@yahoo.com Sun Sep 9 11:37:15 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AF121F8559 for ; Sun, 9 Sep 2012 11:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=0.889, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0pdHBKFKjwc for ; Sun, 9 Sep 2012 11:37:15 -0700 (PDT) Received: from nm20-vm3.bullet.mail.ne1.yahoo.com (nm20-vm3.bullet.mail.ne1.yahoo.com [98.138.91.150]) by ietfa.amsl.com (Postfix) with SMTP id DCBE521F8557 for ; Sun, 9 Sep 2012 11:37:14 -0700 (PDT) Received: from [98.138.226.178] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 09 Sep 2012 18:37:06 -0000 Received: from [98.138.226.160] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 09 Sep 2012 18:37:06 -0000 Received: from [127.0.0.1] by omp1061.mail.ne1.yahoo.com with NNFMP; 09 Sep 2012 18:37:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 762896.79439.bm@omp1061.mail.ne1.yahoo.com Received: (qmail 62184 invoked by uid 60001); 9 Sep 2012 18:37:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347215826; bh=kDXi0pElNW7F6CrTsFMCHrsZAgA+tvNSC3ltUkcCBmA=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=CLerBGW/bcRB+5We/TVnQN41yne+Vc7F8JJt+Q4WSZCiJKunNJEQNHRDqtpGKjLtF5ZFt/V2PgSgStw7fTt9I0uthoVp6M7gxKg68shuClyW0rDyR5fs5XZMHVb2dZh7mQWRivhAzuxkHpSOQL93y8o3D/5X82cV8RGJhOvUR0I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=Hysgnu6UhEhir2/riAsETry5X8mxbg63wialQe0iJiVB1aF0HaSc1a0dCCzFBUFti1ToBTGQPq0knkW2J9Fjvrm6cmAZrh4QnpI+mP+4z93tnxJSedFiw5j76Sbb++4av2DOI0J7iVl/hpeOz+eITIsid1dXJYGJZNpZr0wUCJ4=; X-YMail-OSG: fsPR3vsVM1lMP8EM7BEhBcNdcpd2Z.A37.ReO.tOd9lF52d BLhJD0wDTX9FYTFnZ6ukuaZAkt09OLtC1E4yfQx5gIpJoRctZs7YhUli_NGc .aOnL.5Eh27pfvX_5G_FV8erDI6ymA9nn4kwV8L0BAMw1H9rQT6iV0CJrCde YtMVYUOvgJV12AbILCeRwFPPyTZnF8R1bMHc4HZH9Ri.D4_nqB1m4_fQjQ3u g.C8tPWu7LuN4mwNWptpYwG5OdRDbIBEeWRx4rOIRYOCMbWRgh6gbSvBulDh rujwe9Zx.EoANIUKuuUKQgZTSojVQwc.KGwwC9vLTdhx1LzUMlWcw9RF4iDy 2pGUQnTZP4xGBIhd0eox0CPJEvqftP_TgN4RuAskIbLcc_iNjJq_kU7T_4Z_ WZKSGqAX_MUFE5_z74SraHwP16gAZ0rXVv3XkllkBMnZVpVTUlIqlOJfyI8f mHgDssrzjwrbQgMYlHDI- Received: from [71.61.133.134] by web125104.mail.ne1.yahoo.com via HTTP; Sun, 09 Sep 2012 11:37:06 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347215826.42594.YahooMailClassic@web125104.mail.ne1.yahoo.com> Date: Sun, 9 Sep 2012 11:37:06 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] remove section 9.1.1 DNS Resource Considerations X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 18:37:15 -0000 >> In particular, the table in section 9.1.1 can be easily misread as >> saying that you can have 10 a: mechanisms *and* 10 mx: mechanisms, > > Perhaps that fixes it: > > OLD > Section 4.6.4 specifies the limits receivers have to use. I don't see how this fixes the problems with the table at all. The most serious problem with the table is the "limits" column implies that each type of mechanism has its own limit instead of one limit for all of them. The other problem with the table is that implies that the "cost" column is somehow related to the "limits" column, which it doesn't. But, even if you fixed the table, it doesn't fix the problem that the draft is made worse by having even section 9.1.1. It promotes fragile efficiency, which isn't a major problem, over SPF records being kept accurate, which is a problem. From sm@elandsys.com Sun Sep 9 12:20:24 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADAE21F847F for ; Sun, 9 Sep 2012 12:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBoAGTxiiq3s for ; Sun, 9 Sep 2012 12:20:23 -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 B7C6221F8444 for ; Sun, 9 Sep 2012 12:20:23 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.14]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q89JK1UL015406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 9 Sep 2012 12:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347218421; bh=2q3y7eiB2wuSWMFg1sEr3VyGo+xs0D5FkvmAoelpYQI=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=dPLkCPSTLrlgCBNBHsARbem8+nqamdYAV6oOyFrymNoU/vgB8C1yUKrjN86lewt/+ j7dOpOf4BZ0dsSALxufqz8PdKa+fqro6DM+Rd1V+SRw+/FKTlCRkHMW2pwFwosxweQ +dRerSgKvV9a617Rf2MYZBNq1m/SfUUgGfCj1KpI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347218421; i=@elandsys.com; bh=2q3y7eiB2wuSWMFg1sEr3VyGo+xs0D5FkvmAoelpYQI=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=wa3bLdj4AN+9t8yKn+hYVqjtcEeDHVysCmT9ydl0BJZPBn/ymF8WOJLYjrdW95sjd qonHj8I/tiHW5ezLtnXoOAo2nyKAkaIoZGXLxGWqrWrYUn8Em7/l26m9iNuVD+90rR ti2hw4zKVLr9a5g/jBa4bhYyAdZctdivh4gw7be8= Message-Id: <6.2.5.6.2.20120909115704.06eb7470@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 09 Sep 2012 12:09:45 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <504C5010.80006@isdg.net> References: <1347112012.2101.YahooMailClassic@web125403.mail.ne1.yahoo.com> <504C5010.80006@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 19:20:24 -0000 At 01:15 09-09-2012, Hector Santos wrote: >The semantics did not change - only relaxed RFC2119 wise. > > MAY REJECT --> "can mark or reject outright" There is the following sentence in RFC 4408: "The checking software can choose to mark the mail based on this or to reject the mail outright." It does not contain any RFC 2119 key word. >I already stated we can't support this option without a critical >change to our code. I could be the only system out there with a >REJECT-ON-FAIL behavior. I doubt it though. There isn't any normative text in Section 2.5.4 of RFC 4408 which prohibits the rejection of messages. Regards, S. Moonesamy (speaking for myself) From barryleiba.mailing.lists@gmail.com Sun Sep 9 14:18:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D78D21F85AC for ; Sun, 9 Sep 2012 14:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.94 X-Spam-Level: X-Spam-Status: No, score=-102.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2ytx7bNVk0V for ; Sun, 9 Sep 2012 14:18:37 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B5EB721F85A7 for ; Sun, 9 Sep 2012 14:18:36 -0700 (PDT) Received: by lbky2 with SMTP id y2so860658lbk.31 for ; Sun, 09 Sep 2012 14:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=T+6CDCUJua54rajA67gY00IoGhOQo/NO2aG0AtDyWM0=; b=dlRUjpd2OkNDvt3aBxRs/TXc/l7JwXpS18eHxDjZiYR0RwWIt2kEGMYp3snIsuJEEA 8sJZEdVRO0f+G5cN3n/VzdwCwYyLNeNwtJSr8GF7o5Zvxw3b4YFzmfPlwt4x3sxqiTt9 XHGfVEnO4Z00b7nTmQ/IdV1o5QxtZIWFExU53KCizZjfSokgbMeOcTcSqkMODUwmui2x DoFSak8PeigQlAcQev4pw8EQZUQk10nvGfzTbGUJM5BIDWktoB8ly4rfVOLv4L/ktnhy 1VFlNSvvGRg425zg4OZEBKPAlhgUwsF/1wLeMJ4MH3ri6U+hp+cfg2cP5iVoAoEQepWY 8DWQ== MIME-Version: 1.0 Received: by 10.152.104.44 with SMTP id gb12mr7470230lab.29.1347225515709; Sun, 09 Sep 2012 14:18:35 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Sun, 9 Sep 2012 14:18:35 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120909115704.06eb7470@resistor.net> References: <1347112012.2101.YahooMailClassic@web125403.mail.ne1.yahoo.com> <504C5010.80006@isdg.net> <6.2.5.6.2.20120909115704.06eb7470@resistor.net> Date: Sun, 9 Sep 2012 17:18:35 -0400 X-Google-Sender-Auth: 1j_6gIpjN6V2AVbAtMLbmHxZnkI Message-ID: From: Barry Leiba To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 21:18:37 -0000 > There is the following sentence in RFC 4408: > > "The checking software can choose to mark the mail based on this > or to reject the mail outright." > > It does not contain any RFC 2119 key word. Nevertheless, what often causes confusion with sentences like that is that it's not always clear whether there are other alternatives to the ones mentioned in the sentence. In other words, which of the following does the quoted sentence mean?: 1. The checking software can choose between the following two: (a) mark the mail based on this or (b) reject the mail outright. 2. The checking software can choose (a) to mark the mail based on this, (b) to reject the mail outright, or (c) to do something else that we're not specifying here. I've seen many comments related to that sort of confusion in IESG evaluation of various documents, and it's usually a good idea to re-word the sentence to clarify what's meant, so no one has to guess. I believe that in this case, the intent was (2), but that some people quite understandably read it as (1). Barry From sm@elandsys.com Sun Sep 9 14:55:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C1621F858F for ; Sun, 9 Sep 2012 14:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37YkpJc2FNtT for ; Sun, 9 Sep 2012 14:55:36 -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 E5E1121F8575 for ; Sun, 9 Sep 2012 14:55:36 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.14]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q89LtHEs028823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Sep 2012 14:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347227731; bh=1sE6ejjgEgWQvV2b3pwOQCAhwVfDTtvCOZ84/a9yljU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FBoX1onRSv34egtWmc8iSBduG6CDF7GI1w8Aqx/Zl5dEiU/Qqmsc4pKTUuZzLD3uP E9xIaV/9VWY/I01o+Q97mmzoK/xw2SD/B6+/pUF2ZlzuZ10SjO5oPGAYQf4d2Zp1K5 fbI5lqsnMVPqht7WMEy+JpEY/AECKdl6UG4j0Dz4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347227731; i=@elandsys.com; bh=1sE6ejjgEgWQvV2b3pwOQCAhwVfDTtvCOZ84/a9yljU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=UTJ59vxe1AHJEVOFql0eHRXetGQXXu7j9Zk/yHqmVTkT93AW9VGCCZPjWmOHOWl/F Lnvb+TYKHcn9gHRbtLxmbhHsGwacMvEc2MogR3of7WtFdxFqJ3OhEw2eMPVyjcD84K Q6ptpJx7AZVC8tjHOHYwEp/T1x8JGE9VxyuAfsTk= Message-Id: <6.2.5.6.2.20120909142354.06cb7098@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 09 Sep 2012 14:52:45 -0700 To: Barry Leiba From: S Moonesamy In-Reply-To: References: <1347112012.2101.YahooMailClassic@web125403.mail.ne1.yahoo.com> <504C5010.80006@isdg.net> <6.2.5.6.2.20120909115704.06eb7470@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 21:55:37 -0000 Hi Barry, At 14:18 09-09-2012, Barry Leiba wrote: >Nevertheless, what often causes confusion with sentences like that is >that it's not always clear whether there are other alternatives to the >ones mentioned in the sentence. In other words, which of the >following does the quoted sentence mean?: > >1. The checking software can choose between the following two: (a) >mark the mail based on this or (b) reject the mail outright. > >2. The checking software can choose (a) to mark the mail based on >this, (b) to reject the mail outright, or (c) to do something else >that we're not specifying here. The sentence could be clarified as it can be read as (1). I read it as (2) is not ruled out. Another possible issue is the meaning of "mark". Regards, S. Moonesamy From WebMaster@Commerco.Net Sun Sep 9 15:11:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC9321F855B for ; Sun, 9 Sep 2012 15:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.129 X-Spam-Level: X-Spam-Status: No, score=-0.129 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4m+6f-WS6TWQ for ; Sun, 9 Sep 2012 15:11:44 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 29E8321F8539 for ; Sun, 9 Sep 2012 15:11:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=HGdc/m0OGDWkAjSLNskwf+9JI3f10iYEnC5zRdgJ92x95vfQncwI3JzhAyRZXPwu2bufpjVRvqxxPvOzOI8uvAxGRBCIK82WYl7SVXSYSBwTDkYKNnYkOQ7xME9JocdpcULb42JUZT+7walnOsLP0nPXfrNnxD0O72FaMWWC6ic= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]); Sun, 09 Sep 2012 22:11:40 +0000 Message-ID: <504D1416.8040400@Commerco.Net> Date: Sun, 09 Sep 2012 16:11:34 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: spfbis@ietf.org, S Moonesamy References: <1347112012.2101.YahooMailClassic@web125403.mail.ne1.yahoo.com> <504C5010.80006@isdg.net> <6.2.5.6.2.20120909115704.06eb7470@resistor.net> <6.2.5.6.2.20120909142354.06cb7098@elandnews.com> In-Reply-To: <6.2.5.6.2.20120909142354.06cb7098@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 22:11:45 -0000 SM, On 9/9/2012 3:52 PM, S Moonesamy wrote: > Hi Barry, > At 14:18 09-09-2012, Barry Leiba wrote: >> Nevertheless, what often causes confusion with sentences like that is >> that it's not always clear whether there are other alternatives to the >> ones mentioned in the sentence. In other words, which of the >> following does the quoted sentence mean?: >> >> 1. The checking software can choose between the following two: (a) >> mark the mail based on this or (b) reject the mail outright. >> >> 2. The checking software can choose (a) to mark the mail based on >> this, (b) to reject the mail outright, or (c) to do something else >> that we're not specifying here. > > The sentence could be clarified as it can be read as (1). I read it as > (2) is not ruled out. Another possible issue is the meaning of "mark". > > Regards, > S. Moonesamy How about this: 1. The checking software can choose between the following two: (a) reject the mail outright or (b) process the mail based on local policy. When you think about it, b is exactly what an SPF unaware MTA is really doing. Best, Alan M. From agthisell@yahoo.com Sun Sep 9 15:34:59 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2CB21F8593 for ; Sun, 9 Sep 2012 15:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=0.808, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gn9QSzOyBO2u for ; Sun, 9 Sep 2012 15:34:59 -0700 (PDT) Received: from nm13-vm3.bullet.mail.ne1.yahoo.com (nm13-vm3.bullet.mail.ne1.yahoo.com [98.138.91.143]) by ietfa.amsl.com (Postfix) with SMTP id 0702B21F8592 for ; Sun, 9 Sep 2012 15:34:58 -0700 (PDT) Received: from [98.138.90.52] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 09 Sep 2012 22:34:49 -0000 Received: from [98.138.86.157] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 09 Sep 2012 22:34:49 -0000 Received: from [127.0.0.1] by omp1015.mail.ne1.yahoo.com with NNFMP; 09 Sep 2012 22:34:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 457372.61366.bm@omp1015.mail.ne1.yahoo.com Received: (qmail 64968 invoked by uid 60001); 9 Sep 2012 22:34:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347230089; bh=1zpIcydQd6mlpioCYUTDrckBDLc/o5cAtIfGVVT35Ow=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=uf46dilNgggHAoRGd2km99WpXeqd5UeRtMno5c5Mq4Rv6iHzNOXNaRA47C4dwj7OvCjvtIYvvtzY84Zy7Y0Z8Dui23t11Xy/UNTKELMXl5nuYPSr/tuIu/xyi/LxUHVNBmGH9YmD17jKLL/inAwSRytg6nh2X8ARWKHrg+LwFI4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=tFiCUqWAoHn5NetXXKxa/aeKMc51AUf0+KT4ACgThCqQw6QlkCG5odUuJTMBl6RwF4ZJZEyMexfnUI4SwKIjl7X6jTS72mLLrdNhOswIhYpweXvsy8YFa7eZloRVwzM8Lk4BRkr3vPa+BAzmovUv/C2Efc4tA2IqhSmAu1IRgb4=; X-YMail-OSG: 7UyE9dIVM1mEvjTrOISpKmAP67BHhVmbkGvQoiE2i0srb60 hV.KvPYCBqzft5t7Sv09ljGaZnk0WAYEFS2o5mj5UvXEX9PBJkbrLVyNgnoU BGMefSDsZJVNS3RlV3Gwg4Oxr1sAkzGqicCQvZq3lHjfoEmZPk7Lm8GmWe7X KWAf2oOdlv3hjqTzZVIYSQY1BRnX96tLayTeBcd9GPNhKBf1F3hrEwhvPjHe dlyYC8uLRMrIi3G.vzCusGh2rczXqm3I0V5gUg30bhuj4cPkJpgsg.Bxf40m CSCZRbrqjb3zBqGgrrlirzlKwvLZTI3RrAp2kJs8UiRItK4BV103PtW9mvLM viUyry_l9G4FWasLjWCq1xfmWdvAhl0.5DZz07NcbSFfWmb9.4puiO473aHN S6RbLCJagzyot89Hs4f.L5aPjKInOltHnAAT0QhUxrWUBUuZWkQ1kd593dDf nC82W0c_gCZABokr_duM- Received: from [71.61.133.134] by web125101.mail.ne1.yahoo.com via HTTP; Sun, 09 Sep 2012 15:34:49 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347230089.42767.YahooMailClassic@web125101.mail.ne1.yahoo.com> Date: Sun, 9 Sep 2012 15:34:49 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 22:34:59 -0000 > Nevertheless, what often causes confusion with sentences like that is > that it's not always clear whether there are other alternatives to the > ones mentioned in the sentence. In other words, which of the > following does the quoted sentence mean?: I agree, it could be made clearer. Maybe to make Hector happy, we can use the language directly out of draft-mengwong-spf-01: MTAs, MDAs, and MUAs may choose to accept, classify, discard, or reject messages based on the result of an SPF test. OK, even that is somewhat ambiguous since it could be argued that only certain SPF results can use certain actions. *shrug* I don't think we can write anything that would be absolutely clear to absolutely everyone, especially people who want to see something that isn't there. Maybe a longer quote out of draft-spf-mengwong-spf-01 would be better: SMTP receivers may query sender domains using these mechanisms and decide the validity of a given SMTP transaction while that transaction is ongoing, even before any message data is passed. Alternatively, SPF tests can be performed after SMTP time by an MDA or MUA. MTAs, MDAs, and MUAs may choose to accept, classify, discard, or reject messages based on the result of an SPF test. From superuser@gmail.com Sun Sep 9 15:45:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DDA21F853B for ; Sun, 9 Sep 2012 15:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1PW6qmQBZ18 for ; Sun, 9 Sep 2012 15:45:16 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 232DB21F8534 for ; Sun, 9 Sep 2012 15:45:15 -0700 (PDT) Received: by lahm15 with SMTP id m15so793139lah.31 for ; Sun, 09 Sep 2012 15:45:15 -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=aMhryO4JsGpfAoxOPnIFlX1SfzemKb7YtgMQ4ZyfmZQ=; b=PqoRRnR6BpDd9vNkR4+e2F/Ev57n1bebXUK3NKUsEBvxReBVS41hPkWg64Gu21lf7F M2a7riSP7P8ZLzZxFmOFDyEKapM0AgnowNqiNek9R1VYViZ+NZaKEO1kWZp4BqN9WJgE WiRl7mvuByHRsLK1rUHcYCrZkt2RZJK5Re1qbBshwakVT0VE9TaMuVhnPmK16h+0/l9E KGr8jioJYweLjLrCRS830xmitdcE6qF0q5y3Dmm9xkxc8s+VaK4Be1eL5ojIMa5s68uc HeMLtcBw+Ddv70y6CHx+dyEQ/W9M9BEzxwUfCpCa7AScVxRLcPjc529o0QwkWJc76Td8 h2pA== MIME-Version: 1.0 Received: by 10.152.103.244 with SMTP id fz20mr10878532lab.54.1347230715010; Sun, 09 Sep 2012 15:45:15 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Sun, 9 Sep 2012 15:45:14 -0700 (PDT) In-Reply-To: <504D1416.8040400@Commerco.Net> References: <1347112012.2101.YahooMailClassic@web125403.mail.ne1.yahoo.com> <504C5010.80006@isdg.net> <6.2.5.6.2.20120909115704.06eb7470@resistor.net> <6.2.5.6.2.20120909142354.06cb7098@elandnews.com> <504D1416.8040400@Commerco.Net> Date: Sun, 9 Sep 2012 15:45:14 -0700 Message-ID: From: "Murray S. Kucherawy" To: Commerco WebMaster Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, S Moonesamy Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 22:45:17 -0000 On Sun, Sep 9, 2012 at 3:11 PM, Commerco WebMaster wrote: > 1. The checking software can choose between the following two: (a) > reject the mail outright or (b) process the mail based on local policy. > > When you think about it, b is exactly what an SPF unaware MTA is really > doing. (I presume we're talking about something to go in Section 1 or so, or maybe the top of 2.5, to set context.) Note that rejection can also be the result of local policy. I'd prefer something like: The result of the check_host() function (see Section 4) is typically used as input to an operator's final handling decision for the message under evaluation. For sites that choose to be very strict, this can involve SMTP rejection of a message for which check_host() returns a "fail" result. An operator might also use the result as a factor in a more complex handling decision process before choosing to accept or reject the message. More commonly, operators tend simply to "mark" the message by affixing a header field (see Section 7) that relays details of the SPF evaluation to other handling agents such as MUAs and downstream filters, and then accept it. Due to the variance of needs from one operator to the next, this document establishes no specific handling requirement. -MSK From superuser@gmail.com Sun Sep 9 15:47:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159EC21F8448 for ; Sun, 9 Sep 2012 15:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.52 X-Spam-Level: X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDAHvljA5jyy for ; Sun, 9 Sep 2012 15:47:30 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C35C21F8446 for ; Sun, 9 Sep 2012 15:47:30 -0700 (PDT) Received: by lbky2 with SMTP id y2so882943lbk.31 for ; Sun, 09 Sep 2012 15:47:26 -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=ipi4lqdXNtkDZyhnY+Rygfi6anJaJuG0yP0kSmPmZFg=; b=DJet1wRA53eiBFfBJV8kDMEffK/mpgIbIuM1zGINhhwOQuTcpHKlbmotsWjNnJrhqe p+Ng+bhzmNfvSv3HTHuB2FMaqVFB2VrpeibkTHIJkPWcmoKOWrpiPLNRCGQbjqT7jZR3 skc/Zp90f7jWnub3CCoeyG0H7L6WQ5dRh/kzTBXMjeJ/X7abc+rHbU3pFj5hSybfqsHN D7+JsYTxNV+xJMLWTj0AAG6NUWOmNmt9PCIoZ0kBGx+py3aYSJU3aI+ayYvZIF7Hk8a3 O6PZa67Q4L8kDiMRKKTdEe2wqb0/uPa+lwluTHcZhz17TGUffOaeAu8QwvVynf3YQJro y3HA== MIME-Version: 1.0 Received: by 10.112.9.133 with SMTP id z5mr4312733lba.69.1347230845998; Sun, 09 Sep 2012 15:47:25 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Sun, 9 Sep 2012 15:47:25 -0700 (PDT) In-Reply-To: <1347230089.42767.YahooMailClassic@web125101.mail.ne1.yahoo.com> References: <1347230089.42767.YahooMailClassic@web125101.mail.ne1.yahoo.com> Date: Sun, 9 Sep 2012 15:47:25 -0700 Message-ID: From: "Murray S. Kucherawy" To: Arthur Thisell Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 22:47:31 -0000 On Sun, Sep 9, 2012 at 3:34 PM, Arthur Thisell wrote: > Maybe a longer quote out of draft-spf-mengwong-spf-01 would be better: > > SMTP receivers may query > sender domains using these mechanisms and decide the validity of a > given SMTP transaction while that transaction is ongoing, even before > any message data is passed. Alternatively, SPF tests can be > performed after SMTP time by an MDA or MUA. MTAs, MDAs, and MUAs may > choose to accept, classify, discard, or reject messages based on the > result of an SPF test. I'm not a fan of encouraging message authentication work being done in MUAs. We wrote a big appendix to RFC5451 on this topic after that huge debate during its development. -MSK From sm@elandsys.com Sun Sep 9 16:32:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1883D21F844B for ; Sun, 9 Sep 2012 16:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKWFduHFe7eX for ; Sun, 9 Sep 2012 16:32:36 -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 5E1DC21F8444 for ; Sun, 9 Sep 2012 16:32:36 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.14]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q89NWEKn029639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Sep 2012 16:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347233549; bh=V9cCwLU0hTCfiTO5IXF0JWUs9JAEwyRyddQTCj1rc0E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uaEcxyFVoq5/T42cLwPC9sTJ+M/fwr+c+TrB6OBg5infkWoUZjUA9UOsnUT1dPAXL l4OVycfBB+4UI3SMZvgEHPEYzOltBFlv76EBfBdHgxdSOtKgNPeb5aHnK/5Sk2bS5I psQ5UM3Podgt8FJS7rtfUPe5d02YFO5k5zxwpehs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347233549; i=@elandsys.com; bh=V9cCwLU0hTCfiTO5IXF0JWUs9JAEwyRyddQTCj1rc0E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PZHBzFfqaWehpYQe/yy4Ct499Hjk3PtRneuhfaVZJnvuoi2wTiCBwFJGMsmKQAjh2 79m2O8na9/6Jos5B0UXd8Z/8Vd/3jDHjyaDZtyV3IQNgMWfKmQEzGKkxWV+rtwkE5s 5GWwURd6z8NKWpY/E3/W2/FGSsG1fJw/qextI74s= Message-Id: <6.2.5.6.2.20120909152315.06cb63c8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 09 Sep 2012 16:14:43 -0700 To: Commerco WebMaster , "Murray S. Kucherawy" , Arthur Thisell From: S Moonesamy In-Reply-To: <504D1416.8040400@Commerco.Net> References: <1347112012.2101.YahooMailClassic@web125403.mail.ne1.yahoo.com> <504C5010.80006@isdg.net> <6.2.5.6.2.20120909115704.06eb7470@resistor.net> <6.2.5.6.2.20120909142354.06cb7098@elandnews.com> <504D1416.8040400@Commerco.Net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 23:32:37 -0000 At 15:11 09-09-2012, Commerco WebMaster wrote: >How about this: > >1. The checking software can choose between the following two: (a) >reject the mail outright or (b) process the mail based on local policy. The suggested text is a step forward. The problem with the above text is that "reject" may be interpreted as not part of local policy. An alternative would be reword the text as an example. >When you think about it, b is exactly what an SPF unaware MTA is really doing. Yes. Another way to look at the issue is to see what implementations are doing and take it from there. At 15:45 09-09-2012, Murray S. Kucherawy wrote: >(I presume we're talking about something to go in Section 1 or so, or >maybe the top of 2.5, to set context.) It's about Section 2.5.4. That doesn't mean that the text has to go in that part of the draft. >The result of the check_host() function (see Section 4) is typically >used as input to an operator's final handling decision for the message >under evaluation. For sites that choose to be very strict, this can >involve SMTP rejection of a message for which check_host() returns a >"fail" result. An operator might also use the result as a factor in a >more complex handling decision process before choosing to accept or >reject the message. More commonly, operators tend simply to "mark" >the message by affixing a header field (see Section 7) that relays >details of the SPF evaluation to other handling agents such as MUAs >and downstream filters, and then accept it. Due to the variance of >needs from one operator to the next, this document establishes no >specific handling requirement. I would drop "very strict" because it is debatable. The idea of having "mark" as adding a header field is interesting. There is the following text in Section 4.2 of RFC 4408: "Based on the result, the action to be taken is determined by the local policies of the receiver." The above text, or a variation of it could be fitted in there. One issue is that Section 2.5 is titled "interpreting the results". Here's what Section 2.5.4 says about SPF "fail": 'A "Fail" result is an explicit statement that the client is not authorized to use the domain in the given identity.' There seems to be agreement about the text. It is the tie-in to specific actions which may be the issue. At 15:34 09-09-2012, Arthur Thisell wrote: > MTAs, MDAs, and MUAs may > choose to accept, classify, discard, or reject messages based on the > result of an SPF test. For example, an action such as accepting, classifying, discarding, or rejecting a message may be taken based on the result of a SPF evaluation. Regards, S. Moonesamy From hsantos@isdg.net Sun Sep 9 17:13:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E3621F85F9 for ; Sun, 9 Sep 2012 17:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.304 X-Spam-Level: X-Spam-Status: No, score=-101.304 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJAXB-hKQHkW for ; Sun, 9 Sep 2012 17:13:42 -0700 (PDT) Received: from mail.catinthebox.net (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 830E721F85F7 for ; Sun, 9 Sep 2012 17:13:42 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4326; t=1347236019; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=uIFQbYBuxjqQd6iWnumDIdRhLzE=; b=SkGoZv02d/HThFsXARtW TYTHHaAe9qrVi2Ri83u6P1mRYhxqYFUHgWh53eIlH4qhcW5X9bDAmsPv3eKWMVuk 9LUoxH0jkBwymrMTJHV3nzCPJK4eRc0l6JetxEgcN0HP8bwZBsgkUqNOBS8D4RXT 1VUQ+KVtBryKIGVVWE0DT4M= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 09 Sep 2012 20:13:39 -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 3257798856.2921.4916; Sun, 09 Sep 2012 20:13:38 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4326; t=1347235796; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=VtMNaXQ j+bP49iuBCk6HfMffUSH3LcJ25D2Q5Rvrdes=; b=emrgYIeBfcppMu5elSns5ch XI9s8+CnsiROC7shQ/pPIbbs3bdXBrAAs+NGu9j2QwFaX0M4OyCyieaw5qqkbJQ3 yYS5/KzF7Ce2FMrphoQvjdc281AQwm/WfwwjqC05OhDCFOLlWQhRVnv9E7Pqco5w MufhzRFH92vhrWyUu0iw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 09 Sep 2012 20:09:56 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3856593739.9.5388; Sun, 09 Sep 2012 20:09:54 -0400 Message-ID: <504D30D6.4030901@isdg.net> Date: Sun, 09 Sep 2012 20:14:14 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Barry Leiba References: <1347112012.2101.YahooMailClassic@web125403.mail.ne1.yahoo.com> <504C5010.80006@isdg.net> <6.2.5.6.2.20120909115704.06eb7470@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] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 00:13:43 -0000 Although I have stated basically the same you have here in this or adjunct thread, where the open-ended statement can basically mean anything, this is not all what my real concern is. Obviously, local policy rules here like its always is else where, but we are talking about protocol logic, and whether its 1, 2 or 3 options: 1) Reject 2) Mark (presumption: Add Received-SPF and now A-R in 4408BIS) 3) Other undefined This section 2.5.4, in my technical opinion MUST BE applied with what 4408 section 2.3 states about the intent of -ALL (SPF fail) policy for domains: 2.3. Publishing Authorization .. If domain owners choose to publish SPF records, it is RECOMMENDED that they end in "-all", or redirect to other records that do, so that a definitive determination of authorization can be made. Domain holders may publish SPF records that explicitly authorize no hosts if mail should never originate using that domain. .. and if you look at 4408BIS version, it is revised in my view with even stronger semantics regarding negative/positive determinations or as I may label it as mail classification lingo: SPF results can be used to make both positive (source is authorized) and negative (source is not authorized) determinations. If domain owners choose to publish SPF records and want to support receivers making negative authorization determinations, then they MUST publish records that end in "-all", or redirect to other records that do, otherwise, no definitive determination of authorization can be made. Potential issues and mitigations associated with negative determinations are discussed in Section 9. The irony as I stated is that in the name of not trying to have any compliancy language with the idea of "deterministic rejection" ideas, with 4408bis, it actually added more strength in 2.3. I don't care what mode is chosen - its about the protocol logic that can be extracted from the functional specification into a technical specification. The logic added by an developer to get the local operators the local policy options. Regardless of what option is selected, IMTO, each "SHOULD" satisfy the intent of 2.3, and if not, then we have issue #33. Finally, my reference to MARID and pre-MARID with early adopters is the new emphasis in 4408BIS. If there is a single "big new feature" for SPF developers, it is the idea of adding A-R support and in addition, speaking for myself, realizing in this WG that there are some ESPs that do an ACCEPT+MARK and follow 100% the security precautions in issue #33. We want to offer the same optional feature offering in 2.5.4. of using ACCEPT+MARK instead of just REJECT. For us to do this, it will be a major change to make sure our GATEWAY can now move "Received-SPF: fail" or "Authentication-Result: spf=fail" marked messages into spam folders. Its not doing that now and if we don't we have a SPF security leak for the -ALL domains that are no longer rejected. Thanks Barry Leiba wrote: >> There is the following sentence in RFC 4408: >> >> "The checking software can choose to mark the mail based on this >> or to reject the mail outright." >> >> It does not contain any RFC 2119 key word. > > Nevertheless, what often causes confusion with sentences like that is > that it's not always clear whether there are other alternatives to the > ones mentioned in the sentence. In other words, which of the > following does the quoted sentence mean?: > > 1. The checking software can choose between the following two: (a) > mark the mail based on this or (b) reject the mail outright. > > 2. The checking software can choose (a) to mark the mail based on > this, (b) to reject the mail outright, or (c) to do something else > that we're not specifying here. > > I've seen many comments related to that sort of confusion in IESG > evaluation of various documents, and it's usually a good idea to > re-word the sentence to clarify what's meant, so no one has to guess. > I believe that in this case, the intent was (2), but that some people > quite understandably read it as (1). > > Barry > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From johnl@iecc.com Sun Sep 9 17:48:13 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9785C21F856D for ; Sun, 9 Sep 2012 17:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuoDlIyGCCrH for ; Sun, 9 Sep 2012 17:48:12 -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 629F121F8568 for ; Sun, 9 Sep 2012 17:48:12 -0700 (PDT) Received: (qmail 59988 invoked from network); 10 Sep 2012 00:48:11 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Sep 2012 00:48:11 -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:vbr-info; s=504d38cb.xn--hew.k1208; i=johnl@user.iecc.com; bh=zEcW0qf7AYuL09m94Q2XgeAJR2YfvF8YlHbKjvuOz8U=; b=i/CsYW9V7w0iilD9PvV8p6/v58f5WpAhWd2cgjUPKC+P83B21JZV0imGL0lqLNoV9iDNQfiLiAMeW4wfrW2OhNq/uZOYNXv5K+OZKhvqU4x9re3GVBqyF6nKEHM5pBA06WnB+sLwQNiaroXISu3Fcv1cpAeLrVr4OFajbwuFhdE= 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:vbr-info; s=504d38cb.xn--hew.k1208; olt=johnl@user.iecc.com; bh=zEcW0qf7AYuL09m94Q2XgeAJR2YfvF8YlHbKjvuOz8U=; b=UXnxJzCKleEEh9pALql13TzRAVqiNVwBIpTC5QLoYbNjKIFX2mBdYEZqO+eN8SMzVaRcmuzOU8DMOEx4R5CVv//1GzrCOfU1TZC+AHo1kdYQNjGyDQZCTA1SX3eYYi8R4YuKOxX1c7eRuAVU8mi1E4QPO5a1y/0oJ+yTKOBLfe4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 10 Sep 2012 00:47:49 -0000 Message-ID: <20120910004749.44123.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <504D1416.8040400@Commerco.Net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: WebMaster@Commerco.Net Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 00:48:13 -0000 >How about this: > >1. The checking software can choose between the following two: (a) >reject the mail outright or (b) process the mail based on local policy. The checking software can process the mail based on local policy. If it rejects, that's local policy, too. I really think that we need to prune out the advice that implies that recipients are required to do anything specific with SPF results. R's, John From sm@elandsys.com Sun Sep 9 18:46:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C462B21F8569 for ; Sun, 9 Sep 2012 18:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbJjwM5M7T2P for ; Sun, 9 Sep 2012 18:46:08 -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 37BF021F8523 for ; Sun, 9 Sep 2012 18:46:08 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.14]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8A1jtbU026387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 9 Sep 2012 18:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347241566; bh=QW/hRnpy4+Z92IA6OB0xT5v+LkZDuneLbEHKyCFKr5M=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=wj0UFGrJKPb09FxE8jFf6u6q1keiA9er5yPLgd0AEGgEK7ESHHUwyoaXHvHAok2WU kOnIAkO67XG0SCg7w9l65K8K6gI0LjdwMLoF4YA2023ar4nvXQz7JK3SJ4ejKNMKKw orJD/TUCQVFii9X9LbHC7axs/CMdjM9rIKZhDZww= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347241566; i=@elandsys.com; bh=QW/hRnpy4+Z92IA6OB0xT5v+LkZDuneLbEHKyCFKr5M=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=EGLBn1+PmCLx59jLOzbJJioLZIBKbH1osLp7b2qid6ytNfQOccD6fQS/HTURsH+o8 lX45klZhZYRDuQnBHQrq/pjpbz+jUJ0bJSXE9dZYd9Kelmi5qzny9bWPZBNE7TEWR8 9OeA9hRGgTso4zPBSaUOV7QU2H2NZJG/HQt/iCwo= Message-Id: <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 09 Sep 2012 18:45:04 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 01:46:09 -0000 At 18:32 09-09-2012, spfbis issue tracker wrote: >#58: Local policy in 4408bis > > Message posted by John Levine on 9 Sept 2012: > > The checking software can process the mail based on local policy. > > If it rejects, that's local policy, too. I really think that we need to > prune out the advice that implies that recipients are required to do > anything specific with SPF results. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02716.html I opened a ticket for local policy. I suggest moving the "local policy" discussion to this thread. Please comment on the above so that it can be determined whether it is an acceptable path from which to proceed. Regards, S. Moonesamy From vesely@tana.it Mon Sep 10 01:36:42 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDED921F8567 for ; Mon, 10 Sep 2012 01:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.629 X-Spam-Level: X-Spam-Status: No, score=-4.629 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5E0vQJt-y+rE for ; Mon, 10 Sep 2012 01:36:42 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id F11BC21F855F for ; Mon, 10 Sep 2012 01:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347266199; bh=clZ6Dk7EN0Adn0RpM8J88oa/7aaFH7D9Ji4JJabCyaE=; l=1915; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=VuEnWCHdGvZTuVTpcV1UqPjh5xgNv3NahazAh2X0Cu1BRXppm2ktAdMPgkfCe4zTY O87mIV34Dy+wU1/SjOodPXfvEkwmoiz96nCGkgblDD8CtmcGbfrjiAgSI5fT+KqCPR kMl7ufD4wgRKZy4nbEcowtagt7Nbtg4VI9sziM+Y= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 10 Sep 2012 10:36:39 +0200 id 00000000005DC03F.00000000504DA697.00006197 Message-ID: <504DA696.5070401@tana.it> Date: Mon, 10 Sep 2012 10:36:38 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1347215826.42594.YahooMailClassic@web125104.mail.ne1.yahoo.com> In-Reply-To: <1347215826.42594.YahooMailClassic@web125104.mail.ne1.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] remove section 9.1.1 DNS Resource Considerations X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 08:36:42 -0000 On Sun 09/Sep/2012 20:37:06 +0200 Arthur Thisell wrote: >>> In particular, the table in section 9.1.1 can be easily misread as >>> saying that you can have 10 a: mechanisms *and* 10 mx: mechanisms, >> >> Perhaps that fixes it: >> >> OLD >> Section 4.6.4 specifies the limits receivers have to use. > > I don't see how this fixes the problems with the table at all. Because it defines the table's header. If you like it better: NEWER Costs are the number of DNS queries required to carry out the test. Limits are specified in Section 4.6.4. > The most serious problem with the table is the "limits" column > implies that each type of mechanism has its own limit instead of > one limit for all of them. That's a specification quibble that issue #24 didn't change. Anyway, 9.1.1 is explicative, not normative. > The other problem with the table is that implies that the "cost" > column is somehow related to the "limits" column, which it > doesn't. The relationship is that limits are there in order to prevent excessive costs, including DoS. > But, even if you fixed the table, it doesn't fix the problem that > the draft is made worse by having even section 9.1.1. That sounds like "even if we fix the spec, the problem is that we'll still have SPF around..." :-/ > It promotes fragile efficiency, which isn't a major problem, over > SPF records being kept accurate, which is a problem. The question of how efficiency implies fragility is fascinating, but before we go on quoting Darwin or Knuth, let's recall it's OT. I agree maintenance of SPF records is a problem. To knowledgeably update SPF records, admins need to understand the tradeoffs between maintainability and efficiency, rather than wonder about whether they might dare removing that "mx" that the wizard certainly had good reasons to put there. That's the knowledge 9.1.1 tries to provide. From vesely@tana.it Mon Sep 10 02:14:04 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41F521F853B for ; Mon, 10 Sep 2012 02:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.635 X-Spam-Level: X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRBocE-40EpI for ; Mon, 10 Sep 2012 02:14:04 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E4D3121F84FA for ; Mon, 10 Sep 2012 02:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347268442; bh=govyIARNVajkhHsqkms47C52WCD8lLxBn2jg7xxc59Q=; l=697; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ZjUSmIZsj7vMuUWjBx2a97NCvEPVqivb8Jk6UJrj8Te/Cmvm3ZPM3nHU397dzVwH1 HwotjRSJ1qoTi4zFsILq16p+beN0L1Bt3voTUSVR37GmKNyKxw7S469KPICEDaQyD4 80HGXKmz/t4vHhWvXTz9kUynyc6BrpznKM39gm2w= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 10 Sep 2012 11:14:02 +0200 id 00000000005DC033.00000000504DAF5A.00006A82 Message-ID: <504DAF59.5030901@tana.it> Date: Mon, 10 Sep 2012 11:14:01 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <6.2.5.6.2.20120831151809.06207550@elandnews.com> <1433326.JAlz6WYfAq@scott-latitude-e6320> <6.2.5.6.2.20120906091220.09fcf7a8@resistor.net> <1663351.5sAq1NzcAL@scott-latitude-e6320> <504CCFDA.9060800@dcrocker.net> In-Reply-To: <504CCFDA.9060800@dcrocker.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 09:14:04 -0000 On Sun 09/Sep/2012 19:20:26 +0200 Dave Crocker wrote: > On 9/9/2012 7:19 AM, Barry Leiba wrote: >> Partly for that reason and partly because of where the tendrils of the >> specification lie, I *do* think that the documents would all have to >> normatively reference each other. > > That depends entirely on the nature of the document divisions that are > done. > > My usual view is that documents that need to normatively refer to each > other have probably done a poor split. Some more hierarchical, with > normative pointers in one direction, should be greatly preferred. +1, that's how RFC 2026 seems to suggest an AS (split Section 9) should refer to a TS (polished 4408bis). From vesely@tana.it Mon Sep 10 02:15:57 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600ED21F858F for ; Mon, 10 Sep 2012 02:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.64 X-Spam-Level: X-Spam-Status: No, score=-4.64 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TIZe0wLP0T7 for ; Mon, 10 Sep 2012 02:15:56 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7340B21F8581 for ; Mon, 10 Sep 2012 02:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347268555; bh=JPtLZ4f0z1IahUw8UkbcQCVlm4k7/FNkqOvVJOUyb/A=; l=997; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ATanXXAkzQz9zyvRfXYx9sJFsz46Sdy2/i50HFXAlIUnQP5quFJ9OBWClLgEPfJ4Q zY0DxFjfVGmqIGI7gQ5LJZMlbmiufgvG/4zY71e5Tud1ZEH3Pxq8HNFwzG+4+xE0Cm Y9n1bTUAoO5gJmbp8h1qvZXkXEHSr8YdTHHbTRoY= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 10 Sep 2012 11:15:55 +0200 id 00000000005DC048.00000000504DAFCB.00006B03 Message-ID: <504DAFCB.9010207@tana.it> Date: Mon, 10 Sep 2012 11:15:55 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> In-Reply-To: <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 09:15:57 -0000 On Mon 10/Sep/2012 03:45:04 +0200 S Moonesamy wrote: > At 18:32 09-09-2012, spfbis issue tracker wrote: >> #58: Local policy in 4408bis >> >> Message posted by John Levine on 9 Sept 2012: >> >> The checking software can process the mail based on local policy. >> >> If it rejects, that's local policy, too. I really think that we >> need to prune out the advice that implies that recipients are >> required to do anything specific with SPF results. >> >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02716.html > > I opened a ticket for local policy. I suggest moving the "local > policy" discussion to this thread. Please comment on the above so > that it can be determined whether it is an acceptable path from > which to proceed. That seems to be consistent with Murray's vision of a split, as given in http://www.ietf.org/mail-archive/web/spfbis/current/msg02700.html Does this thread/issue include considerations about the contents of the revised charter? From sm@elandsys.com Mon Sep 10 03:12:13 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0A321F864D for ; Mon, 10 Sep 2012 03:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2B8Hts61aXTO for ; Mon, 10 Sep 2012 03:12:12 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6692521F864A for ; Mon, 10 Sep 2012 03:12:12 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.14]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8AABu0n018729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2012 03:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347271930; bh=VbthGUzpUegDDAgkaTXocNVfgBSclSRMhgDs6WOkAw0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PkpPP6tlS+x75QoDMUWkryK+ugFlA+vHfkLAIdh8RGiqCgPL83r5uDeMN4giLUCqq hO2HY+0ITp+AiBOI5M6ub11nfZQgcwqAqwF6yQWRUgu8iHTiCY5t/81lvSdZgAWFys 45VXpw3+5BpXvkTkhlosNlKp8u8Ka9LXtL+5ZDsg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347271930; i=@elandsys.com; bh=VbthGUzpUegDDAgkaTXocNVfgBSclSRMhgDs6WOkAw0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=AiHBNpNzHof1oSYFBZYywfik4QmY/FbqZZ5/MdOznla47LZenFUMJGd/IMg24brEh Tsfg527T//WjpBvcYuVX+q5WnQSULGeZNqeQT/bVkzTblcsPsGuX3CY+Yxx/ZbUeV9 wYvfdvOwd5kmDKTaQn4w2+CwoQlzaVKq2O9LcigU= Message-Id: <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 10 Sep 2012 03:11:40 -0700 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <504DAFCB.9010207@tana.it> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 10:12:13 -0000 Hi Alessandro, At 02:15 10-09-2012, Alessandro Vesely wrote: >That seems to be consistent with Murray's vision of a split, as given >in http://www.ietf.org/mail-archive/web/spfbis/current/msg02700.html > >Does this thread/issue include considerations about the contents of >the revised charter? Sorry for not provide context. Barry Leiba responded to a comment I made about a sentence in Section 2.5.4 ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02708.html ). Text was suggested in the messages at: http://www.ietf.org/mail-archive/web/spfbis/current/msg02710.html http://www.ietf.org/mail-archive/web/spfbis/current/msg02711.html http://www.ietf.org/mail-archive/web/spfbis/current/msg02712.html and there was a comment from John Levine ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02716.html ). This is not directly related to a revised charter or any split. I cannot tell whether there is agreement or not about whether a message rejection or any other action following a SPF evaluation is a matter of local policy. This thread is to get a sense of views about that. As a possibly bad example, is the action taken after a SPF evaluation an operator decision or is it up to the implementation? Regards, S. Moonesamy From hsantos@isdg.net Mon Sep 10 04:53:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAAE21F84EF for ; Mon, 10 Sep 2012 04:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.049 X-Spam-Level: X-Spam-Status: No, score=-102.049 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+lhzg-IqUOl for ; Mon, 10 Sep 2012 04:53:20 -0700 (PDT) Received: from pop3.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id ED8F121F84EC for ; Mon, 10 Sep 2012 04:53:19 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4330; t=1347277995; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=46ac1PUy8E3MZs8E8Xbef9SkAwI=; b=O1uc8hjPipUMv6V5EwT6 lkcj3wQRrgsUI+MC2tu8T9xg9mlRr2mVQzImH6ZvI8yA0dUz5q8Z36QxFKW+y74J arCROTR9A+Eh+om7CSZfpLVikPAhsgANBJYz/LrIIqykb3m8ihy1cjp0upzH5EDK fX2hJQCefi/UzOX5aFfUQDk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 10 Sep 2012 07:53: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 opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3299774435.3855.3360; Mon, 10 Sep 2012 07:53:14 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4330; t=1347277770; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=wJNvdmv CP0ZvzVmb/ygpDA86Dt6AZdFfhm9Dz43LMc0=; b=0M+SEbUW/LZdGl/2dhcAZKm rXnMdcgBVJ7NyXeJg0ETUh57BpfterjMaSTVNa6/YZAMA0iAhfIc91+87GbYf3yL 85lz3L2Po2NvtGEU69hnV4FzRprjXE2+8ZHvqZ34Mn5EJsYQZdqGHi7SjZqGYCw3 AZXQQ8NIeC/VrrYKtk1g= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 10 Sep 2012 07:49:30 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3898567739.9.2096; Mon, 10 Sep 2012 07:49:28 -0400 Message-ID: <504DD4B5.8060506@isdg.net> Date: Mon, 10 Sep 2012 07:53:25 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> In-Reply-To: <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 11:53:21 -0000 S Moonesamy wrote: > Hi Alessandro, > At 02:15 10-09-2012, Alessandro Vesely wrote: >> That seems to be consistent with Murray's vision of a split, as given >> in http://www.ietf.org/mail-archive/web/spfbis/current/msg02700.html >> >> Does this thread/issue include considerations about the contents of >> the revised charter? > > Sorry for not provide context. Barry Leiba responded to a comment I > made about a sentence in Section 2.5.4 ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02708.html ). > Text was suggested in the messages at: > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02710.html > http://www.ietf.org/mail-archive/web/spfbis/current/msg02711.html > http://www.ietf.org/mail-archive/web/spfbis/current/msg02712.html > > and there was a comment from John Levine ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02716.html ). > > This is not directly related to a revised charter or any split. I > cannot tell whether there is agreement or not about whether a message > rejection or any other action following a SPF evaluation is a matter of > local policy. This thread is to get a sense of views about that. > > As a possibly bad example, is the action taken after a SPF evaluation an > operator decision or is it up to the implementation? > From Issue #29, it evolved to #33 and now #58 regarding local policy (LP). Fascinating! LP was never in question. Generally, a protocol spec describes what options to make available to Local Operators! As I stated a few times, I believe we can resolve this in section 2.5.4 by defining what MARK means. (Issue #29). This was the original points and proposal stated back in April, 2012 http://www.ietf.org/mail-archive/web/spfbis/current/msg01408.html http://www.ietf.org/mail-archive/web/spfbis/current/msg01486.html ------------------ The following is update "starter text" for proposing 2.5.4 text changes. I personally don't care if the RFC2119 language is removed as long as the basic ideas and insights are cited. NEW: 2.5.4. Fail A "Fail" result is an explicit domain policy violation statement that the client is not authorized to use the domain in the given identity. When the result is a "Fail", the checking software MUST offer local receiver SPF deployments the option to choose between marking and classifying (MARK-ON-FAIL) the message having failed the domain SPF policy or rejecting the mail outright (REJECT-ON-FAIL). When the REJECT-ON-FAIL option is used, the SMTP server MUST reject the mail during the SMTP transaction and it SHOULD issue a permanent rejection reply code of 550 and for servers supporting extended reply code [RFC3463], use a policy based rejection description subject sub-code of 5.7.1. The following are some examples of REJECT-ON-FAIL server responses: 550 SPF MAIL FROM check failed: 550-5.7.1 SPF MAIL FROM check failed: 550-5.7.1 The domain example.com explains: 550 5.7.1 Please see http://www.example.com/mailpolicy.html When the MARK-ON-FAIL option is used, it server SHOULD report this failure by adding a Receiver-SPF header to the received message. See Section 7. The REJECT-ON-FAIL should be regarded a System Level local policy for global filtering for all users, where the MARK-ON-FAIL should be regarded as a User Level Policy framework where good vs bad mail is separated for the user. Since the receiver option to either mark or reject should provide the same negative failure outcome of the message to the user, the receiver applying the the MARK-ON-FAIL option SHOULD also separate the message in appropriate user in-box folders, i.e. Junk E-MAIL. The primary reason for this is related to the type of MUA being used by the user. If an online MUA is used, then the backend host can control the display of separate folders. If an offline MUA is used with POP3 mail pickup, the backend POP3 server SHOULD NOT combine the failed separated mail with the normal mail pickup. If the MUA is using IMAP [RFCxxxx], then this will continue with a safer separating of folder displays for users. Overall, the local site SPF deployment of MARK-ON-FAIL SHOULD be aware of how it users are accessing the mail. --------------- -- HLS From superuser@gmail.com Mon Sep 10 07:06:10 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE8C21F86FA for ; Mon, 10 Sep 2012 07:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIdmJoXJAN9p for ; Mon, 10 Sep 2012 07:06:09 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D45921F86F3 for ; Mon, 10 Sep 2012 07:06:09 -0700 (PDT) Received: by lbky2 with SMTP id y2so1331813lbk.31 for ; Mon, 10 Sep 2012 07:06:08 -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=zFR9KexjEY8ruW0TfFNNFpa0mHDzhTwJqsES9hEBynU=; b=Cz7ADQhRsx+ONIfh1Pv5dVhgVap+pc8YjWlk8+bHfHFc/yRapMNW85+5aBV7FftxXz 2py8xI+bJa6Yb9i3UP10qxRKFWZwMmriRjIYAO+CnbWrdz3GhflujmOkR3l46D+/IKdm KZUCB+rirpX2qymsSylTYLlRAQ36EnrZolnsfcNznLnRit7eY8fcoBbV8UJtwgTx+VfF 0LfDII6en/pzGYg7Hs/jesfPWZn2sJL1q0ngoC8fKYqnoCOgbSCeTz+KxEmSLas+bQUA 88qkOeacV7n6Saw2ostdU/NeS9FUe0eAziQ36P7OOLUgmdWRvP6M7SIPSpRVPak6Ua1J PHYQ== MIME-Version: 1.0 Received: by 10.152.46.203 with SMTP id x11mr12523181lam.46.1347285967946; Mon, 10 Sep 2012 07:06:07 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Mon, 10 Sep 2012 07:06:07 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> Date: Mon, 10 Sep 2012 07:06:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, Alessandro Vesely Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:06:10 -0000 On Mon, Sep 10, 2012 at 3:11 AM, S Moonesamy wrote: > This is not directly related to a revised charter or any split. I cannot > tell whether there is agreement or not about whether a message rejection or > any other action following a SPF evaluation is a matter of local policy. > This thread is to get a sense of views about that. Indeed, I think we're still getting ahead of ourselves. There's no rechartering on the table that I've seen, only something of the form "If we want to do this, here's the way." The first half of that hasn't resolved yet. Also, there's a difference between a charter change and a milestone update, and it's not clear we even need the former for the proposal before us. > As a possibly bad example, is the action taken after a SPF evaluation an > operator decision or is it up to the implementation? I'm not sure there's a difference. Either way, I don't much like the idea of a protocol specification telling people what options their implementations have to have. I certainly can't think of an example of another protocol specification that does so. At best, the material needs to be presented so that such things are inferred by the reader, not stated by the editor(s). Put another way, the stuff we're haggling about here does not affect SPF interoperability one bit, so it's out of place in a protocol document. In my view, proper protocol specifications are like man pages (for those of us that are UNIX people): present general context, specify inputs and options, specify outputs, then specify mechanism, and give the consumer just enough information to be able to make basic use of it. There's nothing in that idea about how it has to be exposed to end users. SPF is no different. -MSK From ajs@anvilwalrusden.com Mon Sep 10 07:28:41 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCD221F8514 for ; Mon, 10 Sep 2012 07:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qnh0vWrF0Fy9 for ; Mon, 10 Sep 2012 07:28:40 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id AA42D21F86AB for ; Mon, 10 Sep 2012 07:28:40 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id AB2518A031 for ; Mon, 10 Sep 2012 14:28:39 +0000 (UTC) Date: Mon, 10 Sep 2012 10:28:38 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120910142837.GB84264@mx1.yitter.info> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:28:41 -0000 No hat. On Mon, Sep 10, 2012 at 07:06:07AM -0700, Murray S. Kucherawy wrote: > I'm not sure there's a difference. Either way, I don't much like the > idea of a protocol specification telling people what options their > implementations have to have. Another way of saying that is that, if something is required, then it's not OPTIONAL, but REQUIRED. Certainly, protocol specifications tell people what required elements their implementations have. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From superuser@gmail.com Mon Sep 10 07:45:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8C221F865D for ; Mon, 10 Sep 2012 07:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.526 X-Spam-Level: X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gt5Aocfyt42B for ; Mon, 10 Sep 2012 07:45:01 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC44221F8600 for ; Mon, 10 Sep 2012 07:45:00 -0700 (PDT) Received: by lahm15 with SMTP id m15so1276907lah.31 for ; Mon, 10 Sep 2012 07:44:59 -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=0gC/d6UGHNoXn/wBL9d3nu8N6fT7O5Tzu/svKlCeeU8=; b=Eqo7cUwBZYfLRiB3BDETXcheVB3IpdKSUY/9BBG64IRziz5nmaw1QNhihaQybGJW9I TBB8ErBIhzTyfAtmAgEj3dUavZ6EwdNIVpqq0qdwwOoiM/OYUH5D6++KZnqHDptcM0aN zYJBJUtJeTkKI8R0mGxgCLQwmlwZzXPa0aSWgTrf2U8BMFUUwVI7jwyVnyTppav6pXjn o4/pjANA1XJqBHC3KP8flbLh1sblupe8cL/LXaO47kJa4qhhiRNmRvQSrEIea48ADxbg zOR9pg0sb7x3ZcToHs3MOlinYYVMCBGXZZhvuDO0OYJhzNnJengvsAT7oCrBsrcBNgV/ s7dQ== MIME-Version: 1.0 Received: by 10.152.122.9 with SMTP id lo9mr12837654lab.41.1347288299754; Mon, 10 Sep 2012 07:44:59 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Mon, 10 Sep 2012 07:44:59 -0700 (PDT) In-Reply-To: <20120910142837.GB84264@mx1.yitter.info> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <20120910142837.GB84264@mx1.yitter.info> Date: Mon, 10 Sep 2012 07:44:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:45:01 -0000 On Mon, Sep 10, 2012 at 7:28 AM, Andrew Sullivan wrote: > Another way of saying that is that, if something is required, then > it's not OPTIONAL, but REQUIRED. Certainly, protocol specifications > tell people what required elements their implementations have. Right, I think. The point I'm getting at is this: If we agree with the premise "What an operator does with SPF results is a matter of local policy", then also saying "You MUST provide a configuration knob for reject globally vs. mark per-user" (or anything of the sort) exceeds that premise. We can't say "It's local policy" (meaning "It's completely up to the operator") and then say "Here are your local policy choices." We ought to say: "If you choose to reject, here's how we think you might best do so. If you choose to mark, here's how we think you might best do so. Those are the most common handling options. Or, you could do something else altogether if that's appropriate for your environment." -MSK From hsantos@isdg.net Mon Sep 10 07:53:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F08421F858F for ; Mon, 10 Sep 2012 07:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.085 X-Spam-Level: X-Spam-Status: No, score=-102.085 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvnXr4dfTyde for ; Mon, 10 Sep 2012 07:53:46 -0700 (PDT) Received: from listserv.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id DEB6B21F8546 for ; Mon, 10 Sep 2012 07:53:45 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2013; t=1347288821; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=PQBKxk4x9cf6L1Y/lI+p+Os6RdI=; b=SVoa1lu2SBNW6CDUU75b Zk2BcLjWCsESOTiUC1FPpzFIsf94NiE72+a4fc8FOzmHrqp5PEuu9cFPdIaVLlis q3CkQyv9hPgrdOTqN60DqbBLo8cYo88VnWX2upWvWDmhp7ngF8WRr8XKV9HITBDe AsJMAyC1kLJa44f9l+onr0g= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 10 Sep 2012 10:53:41 -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 3310599672.3855.1064; Mon, 10 Sep 2012 10:53:40 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2013; t=1347288595; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2rAytMH m4u6FDYZp9lfBdMcRceacYExqJjhOihS3UEw=; b=n7JM9P4ZE28LMaIsYHpTLFn NZAnR998Rcfh9UU4TrSh9qRi64If5hVFt1/LkpOnrmti+Adtfvf23Kwv9z1tgjv7 ZhhGB3gP3emfzsS8giViGk6YY7kmdC99N7qCISLqi+CxowTu5/TT9zdfoOYMS9sg RLB2A/bF3gHNFzZbsjVQ= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 10 Sep 2012 10:49:55 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3909394036.9.2896; Mon, 10 Sep 2012 10:49:55 -0400 Message-ID: <504DFF14.2040509@isdg.net> Date: Mon, 10 Sep 2012 10:54:12 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andrew Sullivan References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <20120910142837.GB84264@mx1.yitter.info> In-Reply-To: <20120910142837.GB84264@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:53:47 -0000 I hope this is just a matter of semantics but I don't think the industry would of gotten very far with such questionable views on protocol engineering, client/server software designs, etc. There is some common sense that needs to be expected and overall, what it means to be SPF "ready", "supportive", "compliant", etc. I've always felt this was an example of a yet another philosophy issue between developers and administrators. I've seen it under various SDOs, including the IETF, FSTN, etc. At the end of the day, we have automation, we have software with knobs and switches. Traditionally, a technical specification is extracted from the functional specification. IMO, whats going on here is quite normal - we are finding the "bugs" in the functional specs. In this case, the SPF compliant receiver must be programmed to do and offer administrator local policy configurations for: reject accept, mark, accept, not mark The question is if there is a common functionality in the form of "mail separation" that is inherently provided with rejection also part of the accept w/o marking of a SPF failed message? Its not a matter of local policy per se, its a matter of defining what the programmer will offer the operators in order to satisfy their needs in Local Policy. Personally, I don't know where all this is going but its not what I expected when it simply started with issue #29 requesting that we define what MARKING meant. Andrew Sullivan wrote: > No hat. > > On Mon, Sep 10, 2012 at 07:06:07AM -0700, Murray S. Kucherawy wrote: > >> I'm not sure there's a difference. Either way, I don't much like the >> idea of a protocol specification telling people what options their >> implementations have to have. > > Another way of saying that is that, if something is required, then > it's not OPTIONAL, but REQUIRED. Certainly, protocol specifications > tell people what required elements their implementations have. > > Best, > > A > > -- HLS From ajs@anvilwalrusden.com Mon Sep 10 08:19:41 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739BF21F869F for ; Mon, 10 Sep 2012 08:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.608 X-Spam-Level: X-Spam-Status: No, score=-0.608 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P60Wt7ers2rs for ; Mon, 10 Sep 2012 08:19:41 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0476121F8692 for ; Mon, 10 Sep 2012 08:19:40 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 055948A031 for ; Mon, 10 Sep 2012 15:19:39 +0000 (UTC) Date: Mon, 10 Sep 2012 11:19:38 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120910151938.GE84264@mx1.yitter.info> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <20120910142837.GB84264@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 15:19:41 -0000 No hat. On Mon, Sep 10, 2012 at 07:44:59AM -0700, Murray S. Kucherawy wrote: > vs. mark per-user" (or anything of the sort) exceeds that premise. We > can't say "It's local policy" (meaning "It's completely up to the > operator") and then say "Here are your local policy choices." I think by that you mean that one can say, "Here's the local policy menu," but we can't say, "Here's what you have to do under your local policy," right? I think we are allowed to do the first (though I don't think we should in this case), but not the latter. > We ought to say: "If you choose to reject, here's how we think you > might best do so. If you choose to mark, here's how we think you > might best do so. Those are the most common handling options. Or, > you could do something else altogether if that's appropriate for your > environment." +1 A -- Andrew Sullivan ajs@anvilwalrusden.com From SRS0=gXkeC=HJ==stuart@gathman.org Mon Sep 10 08:54:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784CD21F86F6 for ; Mon, 10 Sep 2012 08:54:20 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oljIfRWChfzl for ; Mon, 10 Sep 2012 08:54:19 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5217A21F8705 for ; Mon, 10 Sep 2012 08:54:19 -0700 (PDT) Authentication-Results: mail.bmsi.com; auth=pass (PLAIN sslbits=256) smtp.auth=stuart Received: from sdg.bmsi.com (sdg.bmsi.com [192.168.9.34] (may be forged)) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q8AFsGWO017491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Sep 2012 11:54:16 -0400 Message-ID: <504E0D28.5050501@gathman.org> Date: Mon, 10 Sep 2012 11:54:16 -0400 From: Stuart D Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> In-Reply-To: <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 15:55:13 -0000 On 09/10/2012 06:11 AM, S Moonesamy expounded in part: > > > and there was a comment from John Levine ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02716.html ). > > This is not directly related to a revised charter or any split. I > cannot tell whether there is agreement or not about whether a message > rejection or any other action following a SPF evaluation is a matter > of local policy. This thread is to get a sense of views about that. > > As a possibly bad example, is the action taken after a SPF evaluation > an operator decision or is it up to the implementation? For SPF Fail, publishers of SPF don't really care what the receiver *does* with the failing email (maybe they accept it, and use it to train a spam filter, then throw in the bit bucket). Instead, spf4408bis should say what NOT to do for an SPF fail. For a given domain 'example.com': You SHOULD NOT apply any reputation from emails with SPF Fail "from" example.com to emails with SPF Pass from example.com. (In general, reputation for each domain:spfresult pair should be tracked separately.) You MUST NOT send a DSN or other MAIL FROM <> response to an alleged return path with SPF Fail "from" example.com. The last one is truly a protocol issue. Receivers can still justify sending a DSN by pretending that they didn't actually check SPF, but we should make it clear that sending a DSN for an SPF FAIL result is a protocol violation. Beyond that, spf4408bis can only suggest possible applications for SPF results in receiver policy. What they choose to do does not directly affect email protocol. From ajs@anvilwalrusden.com Mon Sep 10 10:29:12 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8EE21E8045 for ; Mon, 10 Sep 2012 10:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.646 X-Spam-Level: X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_50=0.001, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TfjwPJTmpQR for ; Mon, 10 Sep 2012 10:29:11 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id CCA7421E8041 for ; Mon, 10 Sep 2012 10:29:11 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 73FDF8A031 for ; Mon, 10 Sep 2012 17:29:10 +0000 (UTC) Date: Mon, 10 Sep 2012 13:29:08 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120910172907.GL84264@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] Meeting at IETF 85 (Atlanta) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 17:29:12 -0000 Dear colleagues, SM and I have requested a 1.5 hour slot at the Atlanta meeting. I anticipate that that will be more than enough for us to hammer out any outstanding issues by that time, and if appropriate to discuss whether there is reason to propose a new charter to the IESG (or whether we should shut down). If you have agenda items you'd like to add for that meeting, please don't hesitate to raise them now. At the same time, please do not stop the productive on-list work; if we're successful enough, of course, we can all get back 1.5 hours of IETF week time (by cancelling the SPFBIS session). Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From superuser@gmail.com Mon Sep 10 11:18:30 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D4421E8053 for ; Mon, 10 Sep 2012 11:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynM8c8+xSW0L for ; Mon, 10 Sep 2012 11:18:30 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A0EC321E8050 for ; Mon, 10 Sep 2012 11:18:29 -0700 (PDT) Received: by lbky2 with SMTP id y2so1532616lbk.31 for ; Mon, 10 Sep 2012 11:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kQWAz3/6VbyrweKoABWZGKbNsexgw53XbH6DaNqUL9c=; b=YYBV2c3ZOGhNk1QKVCZvg8U2wCpw8TYlMRqqRYJlr5+7Iw9R5U5dfDspYVJ5mlNHIi C9vxLeSn/KAku7yVgiqaho6QVnIOeqDdTjObmjqHgCbc3lrhcgvYP4R6bFOAP5K9udp0 /XH2+gScwsSFlz/JJy36JLzE0r4QFeA7EFWm+Aw+5uBxabEOqb5ZRH/CDePgt4FkwPeF 4FI04DzMTv6fAQK3BJ0ukJ1gH35uOfsfTWFmFBFyIh4tyltrIbXAi7mP8iOhwu1aXESb PggO+VPJhWeomirLvik1DjO36XvLIIh/yk7EQ2DJPGi9uyNnBflD7Zk9/4LpcTnYWehb GX5A== MIME-Version: 1.0 Received: by 10.152.125.116 with SMTP id mp20mr13388892lab.19.1347301108614; Mon, 10 Sep 2012 11:18:28 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Mon, 10 Sep 2012 11:18:28 -0700 (PDT) In-Reply-To: <20120910151938.GE84264@mx1.yitter.info> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <20120910142837.GB84264@mx1.yitter.info> <20120910151938.GE84264@mx1.yitter.info> Date: Mon, 10 Sep 2012 11:18:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 18:18:30 -0000 On Mon, Sep 10, 2012 at 8:19 AM, Andrew Sullivan wrote: > I think by that you mean that one can say, "Here's the local policy > menu," but we can't say, "Here's what you have to do under your local > policy," right? I think we are allowed to do the first (though I > don't think we should in this case), but not the latter. I think we're agreeing, but I'm not certain. My issue with "the local policy menu" is that it's a closed set. I perceive that as "implementers have no choices but this list we put before them", and I think that's wrong-headed, at least in the context of what a receiver does with content when we can't possibly know what the receiver's constraints are, in terms of both technical and human factors. -MSK From superuser@gmail.com Mon Sep 10 11:20:55 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88A921E8049 for ; Mon, 10 Sep 2012 11:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcB+xy-KjXVr for ; Mon, 10 Sep 2012 11:20:55 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED2CB21E8053 for ; Mon, 10 Sep 2012 11:20:54 -0700 (PDT) Received: by lahm15 with SMTP id m15so1450302lah.31 for ; Mon, 10 Sep 2012 11:20:53 -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=4mhEDe6OoOIof2cY2sQTanBFrisxxZlrJhrvmgXgQ4Y=; b=t5ycavGncAZSTffII5uzf8JWK+i3HIgJ+ETap+nwhSK4A3UsA+MPcZqN/eb4Ib+Bzz kSmpBsS7vOKBwiJFsZp0tjrBIgGJUgAmtE0LmiUqYBUBXITaGuSvVoa6IXt5vhSdMjJF WqSMVu6cq/eciFGmivSoEKLQ6jplx/FVvJqwdHSAS6dSxFzSp7gAtKzldyaZmFmDl9J7 gCsTQ/1GLamHXNPCNkrFOL9YD7sKzztsKYsvRcQhJ6ZBVO2uU3wmsUhhmMGT3KL6HC7L M82FYQU0iBXzTIGt0aYcovd3e+Hqhv4mTEslf9mwbIXf4I0yKob0GKeEaixqZg1L/2X2 RXbw== MIME-Version: 1.0 Received: by 10.152.46.203 with SMTP id x11mr13155363lam.46.1347301253784; Mon, 10 Sep 2012 11:20:53 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Mon, 10 Sep 2012 11:20:53 -0700 (PDT) In-Reply-To: <504E0D28.5050501@gathman.org> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <504E0D28.5050501@gathman.org> Date: Mon, 10 Sep 2012 11:20:53 -0700 Message-ID: From: "Murray S. Kucherawy" To: Stuart D Gathman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 18:20:56 -0000 On Mon, Sep 10, 2012 at 8:54 AM, Stuart D Gathman wrote: > For SPF Fail, publishers of SPF don't really care what the receiver *does* > with the failing email (maybe they accept it, and use it to train a spam > filter, then throw in the bit bucket). I think that's ideally correct, but not actually correct. Some publishers want very badly to control or at least influence strongly what the receiver does with the failing email. The debate appears to be about whether a protocol document should really do that. > Beyond that, spf4408bis can only suggest possible applications for SPF > results in receiver policy. What they choose to do does not directly affect > email protocol. +1. -MSK From ajs@anvilwalrusden.com Mon Sep 10 11:37:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A8F21E8050 for ; Mon, 10 Sep 2012 11:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.468 X-Spam-Level: X-Spam-Status: No, score=-0.468 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3VBGXgpFV-S for ; Mon, 10 Sep 2012 11:37:21 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id B4DE921E8049 for ; Mon, 10 Sep 2012 11:37:21 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 8A37A8A031 for ; Mon, 10 Sep 2012 18:37:20 +0000 (UTC) Date: Mon, 10 Sep 2012 14:37:18 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120910183718.GN84264@mx1.yitter.info> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <20120910142837.GB84264@mx1.yitter.info> <20120910151938.GE84264@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 18:37:22 -0000 No hat On Mon, Sep 10, 2012 at 11:18:28AM -0700, Murray S. Kucherawy wrote: > > My issue with "the local policy menu" is that it's a closed set. I > perceive that as "implementers have no choices but this list we put > before them", and I think that's wrong-headed, at least in the context > of what a receiver does with content when we can't possibly know what > the receiver's constraints are, in terms of both technical and human > factors. Right. What I was saying is that there are cases where, for protocol purposes, you actually do have a closed set, and we have no trouble with that. "Here are your protocol-permitted options, but you can do anything at all inside these rules." IDNA is like this, for instance: zone operation is a local matter, and in principle you could put anything at all in your zone; but IDNA limits your choices for the purposes of interoperation with anyone else. SPF, actually, is _also_ like this: by overloading the TXT RRTYPE and giving it semantics at the owner name, we are effectively restricting what everyone (even people not implementing SPF, please note) may put in their TXT records. This is the sense in which it is ok, in my opinion, to provide a local policy menu. In the particular case we are talking about, such restrictions don't apply because there is fundamentally no interoperation problem: local mail policies are _by definition_ local only. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From WebMaster@Commerco.Net Mon Sep 10 11:38:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542D021F864A for ; Mon, 10 Sep 2012 11:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.059 X-Spam-Level: X-Spam-Status: No, score=-1.059 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5-PruSVI9xs for ; Mon, 10 Sep 2012 11:38:36 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 171F821F8645 for ; Mon, 10 Sep 2012 11:38:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=cKWHthYrOnlcae13djgHCuGVod3++Z9TzUJEJnvi/hHFDcmcmy5WcFyfno/9+hT/hCOD2/Ih4yHWhzY6w4cJuZqv4KvKhrWIeKz7EPt37AZ9oJFJRvXumCmQnR9bd5cyDL/pf2TEuzcN5ypPyRf6fV63ANWSX02OMITw+BUNnz8= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]); Mon, 10 Sep 2012 18:38:33 +0000 Message-ID: <504E33A1.5030403@Commerco.Net> Date: Mon, 10 Sep 2012 12:38:25 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: spfbis@ietf.org, stuart@gathman.org References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <504E0D28.5050501@gathman.org> In-Reply-To: <504E0D28.5050501@gathman.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 18:38:37 -0000 On 9/10/2012 9:54 AM, Stuart D Gathman wrote: > On 09/10/2012 06:11 AM, S Moonesamy expounded in part: >> >> >> and there was a comment from John Levine ( >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02716.html ). >> >> This is not directly related to a revised charter or any split. I >> cannot tell whether there is agreement or not about whether a message >> rejection or any other action following a SPF evaluation is a matter >> of local policy. This thread is to get a sense of views about that. >> >> As a possibly bad example, is the action taken after a SPF evaluation >> an operator decision or is it up to the implementation? > For SPF Fail, publishers of SPF don't really care what the receiver > *does* with the failing email (maybe they accept it, and use it to train > a spam filter, then throw in the bit bucket). > > Instead, spf4408bis should say what NOT to do for an SPF fail. > > For a given domain 'example.com': > > You SHOULD NOT apply any reputation from emails with SPF Fail "from" > example.com to emails with SPF Pass from example.com. (In general, > reputation for each domain:spfresult pair should be tracked separately.) > > You MUST NOT send a DSN or other MAIL FROM <> response to an alleged > return path with SPF Fail "from" example.com. > > The last one is truly a protocol issue. Receivers can still justify > sending a DSN by pretending that they didn't actually check SPF, but we > should make it clear that sending a DSN for an SPF FAIL result is a > protocol violation. > > Beyond that, spf4408bis can only suggest possible applications for SPF > results in receiver policy. What they choose to do does not directly > affect email protocol. +1 Alan M. From superuser@gmail.com Mon Sep 10 11:54:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203AC21E8086 for ; Mon, 10 Sep 2012 11:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy6ceRUHaADp for ; Mon, 10 Sep 2012 11:54:47 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4221021E808B for ; Mon, 10 Sep 2012 11:54:47 -0700 (PDT) Received: by lbky2 with SMTP id y2so1559276lbk.31 for ; Mon, 10 Sep 2012 11:54:46 -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=wGAdmxKG76jWyH2ukVGD6ZN34rX4MoLw/ZH/WZGmlAE=; b=BtJCkOUov/3rbtGy4VnDbEt/z/Nr72RsGYuI8nkf+t4hqUeol2fPWQyFpRIkyv5+qE ammu5pKhNbZibRiGHEDRBqccXPgyUJvvuZnPZKhh5AjT4vZiaT2s7KJtJyEgK9jApzgd mBycCa8iWU5SwKkQqG1X0RMbbHrhas+12gu0Y9gVLhWZSeWeQ9/mweQgK7TEkBYv+eeD r7rHxC2KjWJJMYYYkPhEd7Dfy885XqmV3eY4mBg7+/UgF9ATRhsQcuN7gRC9HuNItqIl ufA0hosl/OtShQh9TXtDSHBYrBySv/aEfL9+9mNSdSyO72y+dSvPeEuY6W5Xtks4DzKw 3ojA== MIME-Version: 1.0 Received: by 10.112.30.34 with SMTP id p2mr5306622lbh.85.1347303286090; Mon, 10 Sep 2012 11:54:46 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Mon, 10 Sep 2012 11:54:45 -0700 (PDT) In-Reply-To: <20120910183718.GN84264@mx1.yitter.info> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <20120910142837.GB84264@mx1.yitter.info> <20120910151938.GE84264@mx1.yitter.info> <20120910183718.GN84264@mx1.yitter.info> Date: Mon, 10 Sep 2012 11:54:45 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 18:54:48 -0000 On Mon, Sep 10, 2012 at 11:37 AM, Andrew Sullivan wrote: > Right. What I was saying is that there are cases where, for protocol > purposes, you actually do have a closed set, and we have no trouble > with that. "Here are your protocol-permitted options, but you can do > anything at all inside these rules." IDNA is like this, for instance: > zone operation is a local matter, and in principle you could put > anything at all in your zone; but IDNA limits your choices for the > purposes of interoperation with anyone else. SPF, actually, is _also_ > like this: by overloading the TXT RRTYPE and giving it semantics at > the owner name, we are effectively restricting what everyone (even > people not implementing SPF, please note) may put in their TXT > records. This is the sense in which it is ok, in my opinion, to > provide a local policy menu. That brings up two points: 1) Just to complete this thread, are you saying we do present a menu to publishers, since there's a closed set of mechanisms and modifiers defined here? With that I totally agree. Just not at all to the receiver side. 2) On a related note, I reviewed the IESG evaluation record for RFC4408, and I note that there was an ABSTAIN position recorded for an AD who considered SPF an abuse of the DNS. Is there anything we could or should do to prepare for that kind of thing happening again as we go for Proposed Standard? > In the particular case we are talking about, such restrictions don't > apply because there is fundamentally no interoperation problem: local > mail policies are _by definition_ local only. Whew! -MSK From sm@elandsys.com Mon Sep 10 12:17:10 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EF021E8095 for ; Mon, 10 Sep 2012 12:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clGdQhmBS-43 for ; Mon, 10 Sep 2012 12:17:10 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0205A21E808E for ; Mon, 10 Sep 2012 12:17:09 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.134]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8AJGjM1015510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2012 12:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347304616; bh=722apqu15zN9JUtRkshRSIfzAcaJ9L/Ow1PDcbxB+7c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1IVEOMA7ncVGwGTqXDm4asgc6VDowm5cp9iGGlDLWLI9wuD8V/kd6zX7ycEGMxvsQ BDCi93todOe0ysxuMSDG8ACceyKcv3URNrgdYHI0pXi30rFJlRTVH+9V/hSg9bV46j Y795kDMC2fxGWsVAI7JgrfyLE3hGFoAsqhUUF3ro= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347304616; i=@elandsys.com; bh=722apqu15zN9JUtRkshRSIfzAcaJ9L/Ow1PDcbxB+7c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=zU4qA7wk2O9i2pKpHknyd7vYaBoGw0zfOcGq7PG1nyFYqWmktet0MqDtfefsxrA/9 T1ScXKFqoNjZMa3st6mTYtTgbIz32VZTjIUbQoLt3/ssbJ/lMhQ7iCbpBJhiSHvKmc vxt7EjkAxx7GzQ7Ylk8JPbFhPhCwlSuO4u6RiwsM= Message-Id: <6.2.5.6.2.20120910115746.0a15d0c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 10 Sep 2012 12:15:11 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <20120910142837.GB84264@mx1.yitter.info> <20120910151938.GE84264@mx1.yitter.info> <20120910183718.GN84264@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 19:17:11 -0000 Hi Murray, At 11:54 10-09-2012, Murray S. Kucherawy wrote: >2) On a related note, I reviewed the IESG evaluation record for >RFC4408, and I note that there was an ABSTAIN position recorded for an >AD who considered SPF an abuse of the DNS. Is there anything we could >or should do to prepare for that kind of thing happening again as we >go for Proposed Standard? There is not much that can be done to prevent that from happening. It would make matters easier if the draft is up to par with other Proposed Standards. Regards, S. Moonesamy (speaking for myself) From ajs@anvilwalrusden.com Mon Sep 10 12:33:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B1D11E8091 for ; Mon, 10 Sep 2012 12:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6srvUm81T3D for ; Mon, 10 Sep 2012 12:33:26 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id C0C1F11E808E for ; Mon, 10 Sep 2012 12:33:26 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 86F358A031 for ; Mon, 10 Sep 2012 19:33:25 +0000 (UTC) Date: Mon, 10 Sep 2012 15:33:23 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120910193323.GQ84264@mx1.yitter.info> References: <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <20120910142837.GB84264@mx1.yitter.info> <20120910151938.GE84264@mx1.yitter.info> <20120910183718.GN84264@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 19:33:27 -0000 No hat. On Mon, Sep 10, 2012 at 11:54:45AM -0700, Murray S. Kucherawy wrote: > > 2) On a related note, I reviewed the IESG evaluation record for > RFC4408, and I note that there was an ABSTAIN position recorded for an > AD who considered SPF an abuse of the DNS. Is there anything we could > or should do to prepare for that kind of thing happening again as we > go for Proposed Standard? No, and I personally hope that someone on the IESG takes such a position, because I also think it's an abuse of the DNS to specify semantics for a TXT record. (The parking lot is, in vast chunks of North America, the most significant architectural feature for miles. Just because that's the way the world is doesn't mean I have to like it. Same thing here.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@iecc.com Mon Sep 10 12:53:55 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5433611E8091 for ; Mon, 10 Sep 2012 12:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cv6Umstlmemk for ; Mon, 10 Sep 2012 12:53:54 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE8C11E808E for ; Mon, 10 Sep 2012 12:53:54 -0700 (PDT) Received: (qmail 25913 invoked from network); 10 Sep 2012 19:53:53 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Sep 2012 19:53:53 -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:vbr-info; s=504e4551.xn--btvx9d.k1208; i=johnl@user.iecc.com; bh=YXrBwD2/UVmwOC8zqFa3qLgxYw+xdo1rePkMjg45k78=; b=HIhw156j5HtmJABsk8Bb/WseNz7OY2sAqIuRMEdYifUqKpjhf2lVBOitoJOA1yJ7GoWKcYoKKpDc7RrmNPsnciCanLAplebJem65A6v7BJws0j44rz4L9K87IrAPkvTe4XgEvTTYJLGepPKUljpE1CRykeartPnBASGPsjRRmck= 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:vbr-info; s=504e4551.xn--btvx9d.k1208; olt=johnl@user.iecc.com; bh=YXrBwD2/UVmwOC8zqFa3qLgxYw+xdo1rePkMjg45k78=; b=gMfKQrOc2pwCtagAs3H7A4x1z21FaJSTmlUfLucdM4XwJyKdmyIH8QKgUtMiqWpPT4kKQXBlBx/TIGSHQy9fY9JIglf3LjLjEix2EklWxfzA5RVDuZ08FeZycKeseDZsPyDywpIuNCZl/467qVoHFrYRQ9O3ASc+BtEPatA7I/A= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 10 Sep 2012 19:53:31 -0000 Message-ID: <20120910195331.96746.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: superuser@gmail.com Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 19:53:55 -0000 >We ought to say: "If you choose to reject, here's how we think you >might best do so. If you choose to mark, here's how we think you >might best do so. Those are the most common handling options. Actually, we don't even know that. A lot of receivers just stir the SPF results into the secret sauce, logging the result only in a custom header (spamassassin) or an opaque cookie. By volume of mail received, that may well be more common than marking with a header and certainly more common than reject on SPF fail. Again, I think that we should just take out advice about receiver policy. It has nothing to do with making SPF interoperate, it's speculative, and the current advice has little to do with what systems really do. R's, John PS: On the other hand, we really do need to nail down the formula for the lookup limit, since that does affect interoperability. From johnl@iecc.com Mon Sep 10 12:55:20 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7C111E809A for ; Mon, 10 Sep 2012 12:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eMuWXxHHKlf for ; Mon, 10 Sep 2012 12:55:20 -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 35F1411E8099 for ; Mon, 10 Sep 2012 12:55:20 -0700 (PDT) Received: (qmail 26203 invoked from network); 10 Sep 2012 19:55:19 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Sep 2012 19:55:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=504e45a7.xn--hew.k1208; i=johnl@user.iecc.com; bh=eyMCigpsJHSJYJ5W1c+an70qI2LptggxCno78VBZMk8=; b=dqGUYS6/aURQhZE4CR29GsWWP9LXxgzQGpANG+HF+ww4TT0modKxOwCiXQRbIVgSXFz+LOFQOnVfSF9LSYCUbDs1+hNIARQJwFwEJgHZsZuas8VLJiM3f5m9WgNBRty1Cf4gRdWHEyTDj7nC+eBeDMARKZesfkYeQBuMBqETqKc= 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:vbr-info; s=504e45a7.xn--hew.k1208; olt=johnl@user.iecc.com; bh=eyMCigpsJHSJYJ5W1c+an70qI2LptggxCno78VBZMk8=; b=kKS3zAhzQtNRgTkJJxcKH3lKn/+5983pIH169jl0iziHChjqEW1JJSU93wRdHxrjwGw5baju/067t4VjcWy+cEzwOWJCKBwejq0AHk2CHdCq4coqvxptHZQs72Qh/uc/OzFu3JDUNR/xHx9iXl6SKA294iucKVAneQR5j4hGgcY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 10 Sep 2012 19:54:57 -0000 Message-ID: <20120910195457.97169.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <504E0D28.5050501@gathman.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: stuart@gathman.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 19:55:21 -0000 >You SHOULD NOT apply any reputation from emails with SPF Fail "from" >example.com to emails with SPF Pass from example.com. (In general, >reputation for each domain:spfresult pair should be tracked separately.) Receiver policy. Out of scope. Not our job. >You MUST NOT send a DSN or other MAIL FROM <> response to an alleged >return path with SPF Fail "from" example.com. Receiver policy. Out of scope. Not our job. R's, John From hsantos@isdg.net Mon Sep 10 14:37:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F46A11E8091 for ; Mon, 10 Sep 2012 14:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.686 X-Spam-Level: X-Spam-Status: No, score=-101.686 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+NxQrPslVo8 for ; Mon, 10 Sep 2012 14:37:04 -0700 (PDT) Received: from mail.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id AE74321F8513 for ; Mon, 10 Sep 2012 14:37:04 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=687; t=1347313016; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=a01iF14o2Ck/Ppascjt6LHgzNuE=; b=LPig2NmTVQrVc6YanWZ4 BQ7GwijOSkqYTgb+WknCjqMr95DP2SlDRA5cplp0chcuSmlNHFVuQFXewRxuhwhR EZM/wKmsfmP//LOXolTmEYl0q6+EBwZwD8jMI1l4E2pSRCUBFj2dtJoXPopYfla6 tAeTRp9loBJ36f9YxKzrtWU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 10 Sep 2012 17:36:56 -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 3334795037.3855.5504; Mon, 10 Sep 2012 17:36:55 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=687; t=1347312790; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=qNExZNB wVwZYP8SuZBLPCHu6OBFSL2ve7mltk1QJqXI=; b=X1Rcg4Q5jFi278GSs5705hx AyDrhoEdiQpLUHVkJsi3vy8mMxJCvWiAJYpFr0YceW/ZgkG+rTf+RxDetF71qE7i rUhb924EJ6blf3goDVYAOorlQrX4YeC9QRoNDKSDfxOGHHGV7zfz7LCeT9Fkbyia 8RPkzgLYVLgLs2lubzBQ= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 10 Sep 2012 17:33:10 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3933589224.9.220; Mon, 10 Sep 2012 17:33:10 -0400 Message-ID: <504E5D97.30805@isdg.net> Date: Mon, 10 Sep 2012 17:37:27 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <20120910195457.97169.qmail@joyce.lan> In-Reply-To: <20120910195457.97169.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 21:37:05 -0000 John Levine wrote: >> You SHOULD NOT apply any reputation from emails with SPF Fail "from" >> example.com to emails with SPF Pass from example.com. (In general, >> reputation for each domain:spfresult pair should be tracked separately.) > > Receiver policy. Out of scope. Not our job. > >> You MUST NOT send a DSN or other MAIL FROM <> response to an alleged >> return path with SPF Fail "from" example.com. > > Receiver policy. Out of scope. Not our job. So what is the minimum SPF receiver policy for "Behavior?" Is there any recommendation? Even a claim of "out of scope" brings some minimum level of advice for handling: Always accept and mark? -- HLS From hsantos@isdg.net Mon Sep 10 17:59:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FFF21F8707 for ; Mon, 10 Sep 2012 17:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.5 X-Spam-Level: X-Spam-Status: No, score=-101.5 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4UQlrZzAMVE for ; Mon, 10 Sep 2012 17:59:45 -0700 (PDT) Received: from pop3.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2F00F21F8701 for ; Mon, 10 Sep 2012 17:59:44 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3330; t=1347325182; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=60ubU+K5X4DiMcCy3SQdyY7gyPE=; b=V/oN+Tro0Ic0OfeC7KH+ xXN0bJ3oWY9tkCShc9jZ5Ag4QjrstrwYKZ910q42CYj1elimlxrDsM97v8u7xfKJ TxT7cm0+paZgt9MumXP47PXESfPzXNupWpE3h9WEL1zl8idlh2Fbzyu1REkSu+bq iGqK8lyOaf41Mud9fzFkJGg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 10 Sep 2012 20:59:42 -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 3346960322.3855.3772; Mon, 10 Sep 2012 20:59:41 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3330; t=1347324955; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=sst59xh 0xIrofur5YS/0TvSK4YUFfCtoBd37IGQaEQg=; b=WKV/dc/W16S3lmj3MbtBzqP /rYC52+A+fcisYX4Zy5rNSvi6YQ96t8v4NN9c1HqWjXu4exTY8Ie3EsEgctuq7j1 MYRDVvLcMnjnv98gy5MZhhTQwTBimvpRO70fzHyfxEpI543T/Vt2apOD6DyFmL2b M2NDqpewx1HTEjE9T1l0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 10 Sep 2012 20:55:55 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3945753208.9.5508; Mon, 10 Sep 2012 20:55:54 -0400 Message-ID: <504E8D37.2080908@isdg.net> Date: Mon, 10 Sep 2012 21:00:39 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andrew Sullivan References: <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <20120910142837.GB84264@mx1.yitter.info> <20120910151938.GE84264@mx1.yitter.info> <20120910183718.GN84264@mx1.yitter.info> <20120910193323.GQ84264@mx1.yitter.info> In-Reply-To: <20120910193323.GQ84264@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 00:59:46 -0000 Andrew Sullivan wrote: > No hat. > > On Mon, Sep 10, 2012 at 11:54:45AM -0700, Murray S. Kucherawy wrote: >> 2) On a related note, I reviewed the IESG evaluation record for >> RFC4408, and I note that there was an ABSTAIN position recorded for an >> AD who considered SPF an abuse of the DNS. Is there anything we could >> or should do to prepare for that kind of thing happening again as we >> go for Proposed Standard? > > No, and I personally hope that someone on the IESG takes such a > position, because I also think it's an abuse of the DNS to specify > semantics for a TXT record. (The parking lot is, in vast chunks of > North America, the most significant architectural feature for miles. > Just because that's the way the world is doesn't mean I have to like > it. Same thing here.) +1. I'm was always a SPF supporter and also a critic of its obvious high processing waste, especially in the known, expected short term any theoretical DNS based policy will be until critical mass is reached. But to me, more importantly only seeing a high payoff, a RETURN with the -ALL exclusive operations DOMAIN mail sender policy. We DO NOT have possibility of a high return in any of the SPF policies EXCEPT -ALL policies. For all policies except -ALL, itt would be 100% pure waste and to reduce the waste, we needed more augmented methods which I deemed: "Batteries Required" Thats the key different in implementation and deployment of SPF receiver practices. SPF -ALL needs nothing else [1]. The other policies do perhaps and there is no concrete solution that any one can write about. Maybe they could but it will see need "Batteries" and worst, everyone will need to use the same "Batteries" [2]. I just hope we can remain focus and not get too lost again with the theory of SPF. Sure, it would of been nice if uppercase were used but I don't think will alter the protocol anyway. It won't change anything. For SPF fail, Receivers MUST offer one of two options at a minimum to local policy operators: - SMTP reject the transaction - SMTP accept and add Receiver-SPF trace header. If the failed message is accepted, it is HIGHLY RECOMMENDED the accepted message is distinguishable from the rest of the targeted user's normal collection of new mail, i.e. "Junk Email, Spam Mail" folders to allow the user to determine it is a suspicious message. I don't think the above language changes anything. Current systems may in fact be already compliant with A) Rejection and/or B) Accept and Separation. If not, like us where we reject only currently, then they now will learn doing (B) will take extra work. Either they support it, update their code or stay with the status quo and just reject the mail. Nothing changes, but 4408BIS is improved as a official standard with the security Tees crossed and Eyes dotted. -- HLS [1] We know of its #1 flaw with expected relays at the MX final destination hop used by mail senders. [2] Same arguments were made in MARID which did not allow CSV/DNA and DomainKeys as well to get traction - reputation was needed and people were looking for something that did not require some future business to be available. SPF did not need a tertiary business plan of Trust Vendors/Reputation Market brokers. From hsantos@isdg.net Mon Sep 10 18:14:55 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA17F21F8714 for ; Mon, 10 Sep 2012 18:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.681 X-Spam-Level: X-Spam-Status: No, score=-101.681 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7-ppa4ehY8C for ; Mon, 10 Sep 2012 18:14:55 -0700 (PDT) Received: from pop3.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E68BC21F870E for ; Mon, 10 Sep 2012 18:14:54 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2477; t=1347326087; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=RkpkDQAU6ElUxawRCRGreU+fylg=; b=drv2OIoasdlcEOkKB/JP /4FKV2mnT9N/1ONiPR10UeEcGHWpDnmdsD+jb7U4jUGaVqonGwyoGYLe66/aKAWC LuSeMp1QU4lA69YjPcMwM2HGo2d8pDOUuUUXYLkU5B4ltp0OgjRPfloEHIvhxgVh 46DWxQl00aVbMKu2tLJUnYY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 10 Sep 2012 21:14:47 -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 3347865690.3855.5228; Mon, 10 Sep 2012 21:14:46 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2477; t=1347325864; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=NIqrIZ0 P7iyRfp2ftu0phYqUoIHoV9y4BOA7ygjycSI=; b=UIcHBETZre1vuM2MVl44Eo1 BBhWf8SlHAliDco9TsrtwTL8EYCFzX3sar+NJ1pvx1+41fNNTvLkMiawMBYml4CP E+Cuv94gMk76tKr2+jK8dLvgalD1wHdGGHTdczkyheOgwDecCGLlic8T618uXnmg R3zqCcodMRkZ/1o5gaIQ= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 10 Sep 2012 21:11:04 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3946662224.9.5008; Mon, 10 Sep 2012 21:11:03 -0400 Message-ID: <504E90C7.7040509@isdg.net> Date: Mon, 10 Sep 2012 21:15:51 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Stuart D Gathman References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <504E0D28.5050501@gathman.org> In-Reply-To: <504E0D28.5050501@gathman.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 01:14:55 -0000 Interesting approach. I guess I see it easier with: See Section 2.3 The domain has declared this transaction as authorized. By using -ALL, per Section 2.3, the domain copyrighted and responsible owner is exposing legal permission for you to reject and throw it away with Full Force! If you do accept this message, it is highly advise that you color code, negative classify (See section 2.3) this message with "Unauthorized Domain" notifications and classification, whatever UI ergonomics best serves your Mail Service and overall reduces all harm to the user. See Section 2.3 Stuart D Gathman wrote: > On 09/10/2012 06:11 AM, S Moonesamy expounded in part: >> >> >> and there was a comment from John Levine ( >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02716.html ). >> >> This is not directly related to a revised charter or any split. I >> cannot tell whether there is agreement or not about whether a message >> rejection or any other action following a SPF evaluation is a matter >> of local policy. This thread is to get a sense of views about that. >> >> As a possibly bad example, is the action taken after a SPF evaluation >> an operator decision or is it up to the implementation? > For SPF Fail, publishers of SPF don't really care what the receiver > *does* with the failing email (maybe they accept it, and use it to train > a spam filter, then throw in the bit bucket). > > Instead, spf4408bis should say what NOT to do for an SPF fail. > > For a given domain 'example.com': > > You SHOULD NOT apply any reputation from emails with SPF Fail "from" > example.com to emails with SPF Pass from example.com. (In general, > reputation for each domain:spfresult pair should be tracked separately.) > > You MUST NOT send a DSN or other MAIL FROM <> response to an alleged > return path with SPF Fail "from" example.com. > > The last one is truly a protocol issue. Receivers can still justify > sending a DSN by pretending that they didn't actually check SPF, but we > should make it clear that sending a DSN for an SPF FAIL result is a > protocol violation. > > Beyond that, spf4408bis can only suggest possible applications for SPF > results in receiver policy. What they choose to do does not directly > affect email protocol. > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From hsantos@isdg.net Mon Sep 10 19:05:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CEA21F866D for ; Mon, 10 Sep 2012 19:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.815 X-Spam-Level: X-Spam-Status: No, score=-101.815 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZfROZQejOZr for ; Mon, 10 Sep 2012 19:05:35 -0700 (PDT) Received: from ntbbs.santronics.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4169521F865F for ; Mon, 10 Sep 2012 19:05:34 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2100; t=1347329121; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=VXkNcEItixl3n5aRh61wEgduw4E=; b=C6u4p3kA+CD5637UVPy0 CHtzYE6yzq2U3QeD9PJomZj3y3lc6zQiLzJicekqCRVJiufWhWhRhs3zzmLywm/x I4iUAGftE4+gy2RQ08X/MjyWDvkt1xigaVo5Qu7p/1QjRhUo/6HVDDzSFvXIRUC2 JWnROru5goGhr1cpCgPWM5Y= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 10 Sep 2012 22:05: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 3350900799.3855.3088; Mon, 10 Sep 2012 22:05:21 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2100; t=1347328900; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Ohy0BUp kp1ohNdkDvGmDo6HPlC2ZdhAYfVoCrswkef4=; b=XGp9ii0Awlp2lsMiO8W0Jtk JC8XqYXxO84NXzuM99fK8hCTa7xdno1SBusinCRbxTqz20chgmV5NOWtdcGGS3gN nFBs+T/rL5Aj705S5Yh78nSLV+kE3EPpz2NGFIZZNvD16MZ8x8wFQThx02bJhW6J D/9C1gEiONtGsJov60XA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Mon, 10 Sep 2012 22:01:40 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3949698083.9.5524; Mon, 10 Sep 2012 22:01:39 -0400 Message-ID: <504E9CA9.4060701@isdg.net> Date: Mon, 10 Sep 2012 22:06:33 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> In-Reply-To: <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 02:05:36 -0000 So what is the goal of these issue I wonder? Are we trying to negate the idea that REJECTION is possible? Are we trying to discourage the idea of REJECTION? RFC4408 is peppered with Receiver Protocol Instructions, Insights information, Receiver "Local Policy" insights and concepts. Over 26 instances of the usages for the term "Reject." Over 29 instances of the usages for the term "Authorization" and authorization checks, where its performs, how its performed, etc, etc. It just really odd that we are arguing what SPF was and still is. It doesn't matter of X number of sites does ACCEPT and MARK operations, REJECTION is very much part of protocol and ALL SOFTWARE are coded to support it. The issue is whether current support for ACCEPT+MARK transactions are secured for the user? Is it? Do all the BIG BOYS and all the SMTP vendors with SPF support and open source SPF APIs all have programmable options to: ACCEPT+MARK+SEPARATE the mail? Is this the standard practice and anything else (like rejection) SHOULD NOT be part of the SPF 9+ year old framework and philosophy? I am just really lost on where we are going with all this. S Moonesamy wrote: > At 18:32 09-09-2012, spfbis issue tracker wrote: >> #58: Local policy in 4408bis >> >> Message posted by John Levine on 9 Sept 2012: >> >> The checking software can process the mail based on local policy. >> >> If it rejects, that's local policy, too. I really think that we need to >> prune out the advice that implies that recipients are required to do >> anything specific with SPF results. >> >> http://www.ietf.org/mail-archive/web/spfbis/current/msg02716.html > > I opened a ticket for local policy. I suggest moving the "local policy" > discussion to this thread. Please comment on the above so that it can > be determined whether it is an acceptable path from which to proceed. > > Regards, > S. Moonesamy > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From W.Doust@racingvictoria.net.au Mon Sep 10 19:53:50 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1E221F86F0 for ; Mon, 10 Sep 2012 19:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4EgxXgvdHi6 for ; Mon, 10 Sep 2012 19:53:49 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 4A54721F86EB for ; Mon, 10 Sep 2012 19:53:48 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v7, 1, 0, 4874) id ; Tue, 11 Sep 2012 12:53:46 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD8FC8.9ECB3E4C" Date: Tue, 11 Sep 2012 12:53:14 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185197@XCHANGE.rvl.internal> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secetion 4.6.4 DNS Lookup Limits Thread-Index: Ac2PyJZhkvjz7bz4RnCG7/ilLMFX0w== From: "Wayne Doust" To: Subject: [spfbis] Secetion 4.6.4 DNS Lookup Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 11 Sep 2012 02:53:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD8FC8.9ECB3E4C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I suggest adding the following (or similar) text to this section at an appropriate location: =20 "MTAs (or other processors) MUST apply the DNS lookup limit sequentially as the record is=20 evaluated and not prematurely issue a permerror based on potential lookups. For example,=20 an SPF record containing a potential 11 DNS queries should not permerror unless the evaluation does not satisfy any of the prior mechanisms that require less than or equal to 10 DNS queries." =20 =20 ------_=_NextPart_001_01CD8FC8.9ECB3E4C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I suggest = adding the following (or similar) text to this section at an appropriate = location:

 

“MTAs (or other processors) MUST apply the DNS = lookup limit sequentially as the record is

evaluated and not prematurely issue a permerror based = on potential lookups. For example,

an SPF record containing a potential 11 DNS queries = should not permerror unless the evaluation

does not satisfy any of the prior mechanisms that = require less than or equal to 10 DNS queries.”

 

 

------_=_NextPart_001_01CD8FC8.9ECB3E4C-- From sm@elandsys.com Tue Sep 11 00:49:28 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F6721F86FD for ; Tue, 11 Sep 2012 00:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLj-kzXR5m5r for ; Tue, 11 Sep 2012 00:49:27 -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 CD76621F8700 for ; Tue, 11 Sep 2012 00:49:27 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.134]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8B7nCph012514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Sep 2012 00:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347349765; bh=AlF1xSsY1WNKbRN1ngv64iVl7gR9EUFw3lW7XX2ddtQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jFPv0lXO8reWqklxGca4hnCbvnKhBEwmnYTS9QNF5jFGdIxY3mBwsX4jSAE2ZDxl8 sACnZz6R5f2fOomlfUk4kMFvBIS465y2+kge6cPhWLdx9WUtqULCFb6rFtSfJBTPyi py7f2KsR1uwrPXn4hlYoE6X4sDXyaaoZw5uqoe5I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347349765; i=@elandsys.com; bh=AlF1xSsY1WNKbRN1ngv64iVl7gR9EUFw3lW7XX2ddtQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Z+41aexhjz5iqz5sRkulh/dm8qoLpJyQmr8QvuCBUQnTVTBChfrQg0YkeFhx8JM25 ayLbVb8pwPrWOVHlV906w6qJIWvUDIbsthgEyfDbgvgUlUP6hsLBS89POhyyZ/I8vn 8uWAeBSAc9DNjDoG1D/NrmDrvdfKz1rbrRDUy8bE= Message-Id: <6.2.5.6.2.20120910231140.09679ce0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 11 Sep 2012 00:39:28 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <20120910004749.44123.qmail@joyce.lan> References: <504D1416.8040400@Commerco.Net> <20120910004749.44123.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis-chairs@tools.ietf.org, Scott Kitterman Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 11 Sep 2012 07:49:28 -0000 Hello, I haven't discussed this issue with Andrew yet. I don't see agreement on Issue #33 ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02195.html ). Murray Kucherawy suggested some text where it is argued that the attack on SPF is outside the scope of the specification ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02661.html ). I don't see agreement on the text which Murray proposed. During the discussion, Barry Leiba raised an interesting point about a sentence in Section 2.5.4 ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02708.html ). I reopened Issue #29 based on that ( http://trac.tools.ietf.org/wg/spfbis/trac/ticket/29#comment:5 ). There has been a lot of discussion about rejecting or "marking" a message based on a SPF result of "fail". Section 1 of RFC 4408 mentions the following: "An additional benefit to mail receivers is that after the use of an identity is verified, local policy decisions about the mail can be made based on the sender's domain, rather than the host's IP address. This is advantageous because reputation of domain names is likely to be more accurate than reputation of host IP addresses. Furthermore, if a claimed identity fails verification, local policy can take stronger action against such E-Mail, such as rejecting it." Section 4.2 of RFC 4408 mentions that: "Based on the result, the action to be taken is determined by the local policies of the receiver." I opened Issue #58 to find out whether there is agreement or not about whether a message rejection or any other action following a SPF evaluation is a matter of local policy. My opinion is that an action based on the result of a SPF evaluation is up to the local policy of the receiver. The receiver may take stronger action such as rejecting a message. My recommendation is not to add any text about Issue #33 to the draft unless there is strong agreement on the mailing list for the proposed change. I also recommend reverting the following text in Section 2.3 of draft-ietf-spfbis-4408bis-07: "SPF results can be used to make both positive (source is authorized) and negative (source is not authorized) determinations. If domain owners choose to publish SPF records and want to support receivers making negative authorization determinations, then they MUST publish records that end in "-all", or redirect to other records that do, otherwise, no definitive determination of authorization can be made. Potential issues and mitigations associated with negative determinations are discussed in Section 9." to: "If domain owners choose to publish SPF records, it is RECOMMENDED that they end in "-all", or redirect to other records that do, so that a definitive determination of authorization can be made." and not including any change in Section 2.3 unless there is strong agreement on the mailing list for the proposed change. I will close Issue #33 in the tracker unless there is an explanation about whether the attack (see issue #33) is out of scope and what countermeasures can be applied to defend against it. I suggest basing the explanation on text which is in RFC 4408 only as it is my understanding that existing SPF implementations use that specification. Regards, S. Moonesamy SPF WG co-chair From sm@elandsys.com Tue Sep 11 01:37:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33ADF21F87B3 for ; Tue, 11 Sep 2012 01:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-N7F0ExxtSs for ; Tue, 11 Sep 2012 01:37:00 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E93F21F8778 for ; Tue, 11 Sep 2012 01:37:00 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.134]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8B8alXc008637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Sep 2012 01:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347352619; bh=zN6L9LL1kcs28b4sPsLhGHiWg/RncS2UnwX/LSIS3vw=; h=Date:To:From:Subject:Cc; b=0SZP2MTxz5/SnnWgxSniBKwxJ+oFsEMkSesiynIivgNQy6gRDPuFxCWZP6GYgRjBo I8W/bnFgQYVJnNfWv6ORSncenUH7+zOQAR8FZJ2f46ISc4CMyB2E6E64EkFFNlg4uL 193Kx1tfCdIECpohNBVtezLqoMF/dNtG42U6qbPU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347352619; i=@elandsys.com; bh=zN6L9LL1kcs28b4sPsLhGHiWg/RncS2UnwX/LSIS3vw=; h=Date:To:From:Subject:Cc; b=ukUxOmMZ37iP20k32WrrbAsjfGLgQVxG6VyQwKSh5wXeeEuWz1RJsSo3qHSsBJhWi TL8nN8JK8jLYMLsPCcjNLPNilfSyhOeoTXYlru9hKO4Gie2SHxivPR3a4NwhpwFvIE y3tv+tJy+a5pFM9psEnyzsmcZvrMuMrRQHARUWOA= Message-Id: <6.2.5.6.2.20120911013244.09617218@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 11 Sep 2012 01:35:49 -0700 To: Scott Kitterman From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: [spfbis] Changes to draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 08:37:01 -0000 Hi Scott, It would help if the WG can see which text in draft-ietf-spfbis-4408bis has agreement. I suggest that for those things where you are suggesting text that the WG hasn't agreed to yet, mark it as such in the document to distinguish it from the text that is in your opinion solid. Thanks, S. Moonesamy SPFBIS WG co-chair From sm@resistor.net Tue Sep 11 03:33:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E4621F87BA for ; Tue, 11 Sep 2012 03:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTdWegELBTHB for ; Tue, 11 Sep 2012 03:33:43 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2646121F87AF for ; Tue, 11 Sep 2012 03:33:43 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8BAXVfO014460; Tue, 11 Sep 2012 03:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347359616; bh=92rV/IFsG0cshQO4KS4YJPYOCjxmEw7K+HKYuIUL1BE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cdATZl4KrrokS65w5RV5kXBQswPOsf1Mwn+NK6trtH5h0ql/shMuE8N1hUM2jJaq0 WC5LEHEL44a8AXXlJxk7Zpb12sX2Wa/4NUYBwxOmSXI/oWGhbsXBMxRjYR4lsS7DCV 4RWu9N7KUravlJgMiojfMO+Xhlyoa1gpD/3GOGPY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1347359616; i=@resistor.net; bh=92rV/IFsG0cshQO4KS4YJPYOCjxmEw7K+HKYuIUL1BE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=I2vBuvm434EY5r0HxxZYgg/SdMCsam2NoxwRtOx8eb64USzw2/UtXA6MHNT2R+zNc 4FOQOXD42Ix4XL2CnHEZwWtUnfYBqJdO9pON5A5YGW9z6HpPn2/rNShYf4yauZKA0b aVfhSvJzZpgPX1VjeeRrFuOUwV0X/CWnRQp/ZTuw= Message-Id: <6.2.5.6.2.20120911021549.092d4610@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 11 Sep 2012 03:32:20 -0700 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: [spfbis] draft-ietf-spfbis-4408bis document quality (was: #58: Local policy in 4408bis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 10:33:43 -0000 Hi Murray, At 07:06 10-09-2012, Murray S. Kucherawy wrote: >In my view, proper protocol specifications are like man pages (for >those of us that are UNIX people): present general context, specify >inputs and options, specify outputs, then specify mechanism, and give >the consumer just enough information to be able to make basic use of I'll comment on the document quality of draft-ietf-spfbis-4408bis. The layout is, in most parts, similar to the RFC 4408 layout. One possible explanation for why that RFC is lengthy is because the author of the draft did not have time to make it shorter when the draft was submitted. The draft-ietf-spfbis-4408bis-07 starts with an introduction of the protocol. It then discusses protocol status and experimental history and introduces the terminology which is to be used throughout the document. That is followed by a discussion of the operation. The protocol part, if it can describe as that, is about publishing authorization and checking authorization. The document then explains how the (SPF) result is to be interpreted. The DNS record is then introduced and there is some discussion about DNS. The document then explains the check_host() function and its arguments. It then explains the result and processing. The mechanisms are introduced, followed by modifiers. There is a discussion of DNS limits and domain specification. Mechanisms are then defined, followed by modifier. The draft then explains how to record the result. Macros are defined after that. The document then attempts to outline the major implications that adoption of the specification will have on various entities involved in Internet email. It discusses about sending domains, then DNS resource considerations and mediators. That is followed by a discussion about policy. The document ends with a discussion of security considerations. I noticed during section-wise reviews that some topics are discussed in several parts of the document. That can be a layout issue which affects document clarity. I found it difficult to identify the requirements for interpretability, i.e. what must be done for the protocol to work, what must be done unless you have a very good reason not to do so and what is optional. There is excessive usage of RFC 2119 key words. Most of that can be traced back to RFC 4408. I mentioned "checking software" previously as a nit. The terminology used isn't consistent throughout the document. It can be argued that any or all of the above is ok. I may be asked whether I have personally reviewed the document that the WG considers as ready for publication and, in particular, do I believe it is ready for forwarding to the IESG. I would say no and point out that it is the consensus of SPFBIS. Regards, -sm From john@jlc.net Tue Sep 11 03:59:57 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83AF21F876F for ; Tue, 11 Sep 2012 03:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NXqurGahVxc for ; Tue, 11 Sep 2012 03:59:57 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 429A921F8751 for ; Tue, 11 Sep 2012 03:59:57 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id BAC7533C26; Tue, 11 Sep 2012 06:59:56 -0400 (EDT) Date: Tue, 11 Sep 2012 06:59:56 -0400 From: John Leslie To: John Levine Message-ID: <20120911105956.GI79075@verdi> References: <504E0D28.5050501@gathman.org> <20120910195457.97169.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120910195457.97169.qmail@joyce.lan> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org, stuart@gathman.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 10:59:57 -0000 John Levine wrote: > [Stuart D Gathman wrote:] > >> You MUST NOT send a DSN or other MAIL FROM <> response to an alleged >> return path with SPF Fail "from" example.com. > > Receiver policy. Out of scope. Not our job. While "receiver policy" is indeed not our job, this is an example of a unmistakeable _sender_ policy: "I didn't send this!" I wouldn't write this as a MUST NOT, of course; but it feels as if it deserves a SHOULD NOT... -- John Leslie From johnl@taugh.com Tue Sep 11 06:21:10 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D5921F8807 for ; Tue, 11 Sep 2012 06:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_UNSUB22=0.948] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lb6WPKn7YthS for ; Tue, 11 Sep 2012 06:21:10 -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 2F4AE21F85E6 for ; Tue, 11 Sep 2012 06:21:08 -0700 (PDT) Received: (qmail 25373 invoked from network); 11 Sep 2012 13:21:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=631c.504f3ac2.k1209; bh=HkL/RDelVCHF/LyC+nB54RFZr0+Mc5lkThTKpjaNQ4k=; b=rzQ28dkuipxhNcIWZe8ZJgvk/Ltdz8KGRshvUdC7JEe07t4902aaHktBpocHffqsOqkHjoSgmhyKGPjRacBnI1gotyhd1OIg5TvKrA66nx/80r73mKR6Nb42PJM+LMDY5ijdA5hD4DbrwCN03OGgLwV+b3WjCdTTMVXldsa9Gas= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=631c.504f3ac2.k1209; bh=HkL/RDelVCHF/LyC+nB54RFZr0+Mc5lkThTKpjaNQ4k=; b=TLIDMhGwArMuk7JXo1ciBa5cFQ4mWTkOYUo4Dy5QrOJZIskC1tzqdjga8bbSjh0ZTRXjLTusx5qXsK2H9ReyqBzzPyq9L/enfW8CvhKjdAfrput1Gq9XDj4yypPaWM7W7T/tndzVdvakxfaXboGlzugnLpD0KdLRoytXaH/0m6A= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 11 Sep 2012 13:20:44 -0000 Date: 11 Sep 2012 09:21:05 -0400 Message-ID: From: "John R Levine" To: "John Leslie" In-Reply-To: <20120911105956.GI79075@verdi> References: <504E0D28.5050501@gathman.org> <20120910195457.97169.qmail@joyce.lan> <20120911105956.GI79075@verdi> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 13:21:10 -0000 >>> You MUST NOT send a DSN or other MAIL FROM <> response to an alleged >>> return path with SPF Fail "from" example.com. >> >> Receiver policy. Out of scope. Not our job. > > While "receiver policy" is indeed not our job, this is an example > of a unmistakeable _sender_ policy: "I didn't send this!" No, it's saying that I shouldn't send a bounce because you say the message is bogus. That's your policy statement, not mine. It may well be a good idea not to bounce on SPF failure, but that's not for you, or the SPF spec to say. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From dhc@dcrocker.net Tue Sep 11 08:08:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D6121F8817 for ; Tue, 11 Sep 2012 08:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bquGM+SerJL9 for ; Tue, 11 Sep 2012 08:08:34 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A701E21F8815 for ; Tue, 11 Sep 2012 08:08:34 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8BF8VS0012902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Sep 2012 08:08:32 -0700 Message-ID: <504F53EF.5040501@dcrocker.net> Date: Tue, 11 Sep 2012 08:08:31 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: SM References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <6.2.5.6.2.20120911021549.092d4610@elandnews.com> In-Reply-To: <6.2.5.6.2.20120911021549.092d4610@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 11 Sep 2012 08:08:32 -0700 (PDT) Cc: spfbis@ietf.org, "Murray S. Kucherawy" Subject: Re: [spfbis] draft-ietf-spfbis-4408bis document quality X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 15:08:35 -0000 On 9/11/2012 3:32 AM, SM wrote: > I may be asked > whether I have personally reviewed the document that the WG considers as > ready for publication and, in particular, do I believe it is ready for > forwarding to the IESG. I would say no and point out that it is the > consensus of SPFBIS. SM, Please clarify your last sentence. Perhaps it is the 'and' that confused me. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From john@jlc.net Tue Sep 11 08:25:32 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DEC21F8819 for ; Tue, 11 Sep 2012 08:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8mfq6ZZGjdR for ; Tue, 11 Sep 2012 08:25:32 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 04BFA21F8812 for ; Tue, 11 Sep 2012 08:25:31 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8007233C29; Tue, 11 Sep 2012 11:25:31 -0400 (EDT) Date: Tue, 11 Sep 2012 11:25:31 -0400 From: John Leslie To: John R Levine Message-ID: <20120911152531.GJ79075@verdi> References: <504E0D28.5050501@gathman.org> <20120910195457.97169.qmail@joyce.lan> <20120911105956.GI79075@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 15:25:32 -0000 John R Levine wrote: > >>>>You MUST NOT send a DSN or other MAIL FROM <> response to an alleged >>>>return path with SPF Fail "from" example.com. >>> >>>Receiver policy. Out of scope. Not our job. >> >> While "receiver policy" is indeed not our job, this is an example >> of a unmistakeable _sender_ policy: "I didn't send this!" > > No, it's saying that I shouldn't send a bounce because you say the message > is bogus. That's your policy statement, not mine. You can write better than this, John: I know you can. ("I" and "you" are ambiguous, for anyone having trouble with the English grammar...) > It may well be a good idea not to bounce on SPF failure, but that's not > for you, or the SPF spec to say. (Note that John Levine snipped the part where I distinguished MUST from SHOULD.) In brief, this deserves a "Straw Man Alert!" John Levine is responding to something I didn't say. In my experience as an ISP, "blowback" DSNs are quite useless (that being when _I_ get the DSN because a spammer forged the MAIL-FROM). If the sender policy is a clear "I didn't send this" (as I claim, but John Levine seems to dispute), it's essentially no step at all to "I don't want blowback DSNs". There is, after all, nothing useful the domain receiving such DSNs can do; and they either cost support time or force you to ignore pretty-much all DSNs. (If I were interested in learning when spammers forge my domain, I wouldn't advertise -ALL.) That is why I said it feels like it deserves a SHOULD NOT. SPF holds great promise of informing decisions of whether to reject at SMTP time or accept in hopes the email might prove useful after all. IMHO, an SMTP-time reject is more useful to honest senders. Obviously, YMMV... -- John Leslie From johnl@iecc.com Tue Sep 11 09:08:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D75521F8703 for ; Tue, 11 Sep 2012 09:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlnp0OBDdKew for ; Tue, 11 Sep 2012 09:08:47 -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 0F86721F86F9 for ; Tue, 11 Sep 2012 09:08:46 -0700 (PDT) Received: (qmail 66789 invoked from network); 11 Sep 2012 16:08:44 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 11 Sep 2012 16:08:44 -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:vbr-info; s=504f620c.xn--30v786c.k1208; i=johnl@user.iecc.com; bh=3VfVS3hBjj2xZPvNJciHZ3xf9WK8PVo4TjeBFn6Ij0A=; b=hO9AB5EeVudqvaG4iudE95Jsr+Oo3039RTK+cyV570vVDpcL8bJ7lSJcFA5s0hH2yIbxVovftNrwtwMYOpCSz5RNUyG7W53snuUiRrAkKFhOlucC7l2EBu6sfcZiPzGPNcFZp3ZprhF23c2t8hgwDYSxUXn4jugxZjJBuXTjhIQ= 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:vbr-info; s=504f620c.xn--30v786c.k1208; olt=johnl@user.iecc.com; bh=3VfVS3hBjj2xZPvNJciHZ3xf9WK8PVo4TjeBFn6Ij0A=; b=mPhd/4VmvqOjCCkA3BwtVKYqWuz5Fqxk/58bk0TyEn/7duFEjrOdCWRzg96VSqKY47SjroUMB/uP4iQQ7ZyjiTkCvm6DM2S/P+QHpJZk0Pn43CgRDTC2LBWnv/Kj4ZhTSMs4p7VGv58upuaRZNMTLwwiHnfARGAnwGFeTLc5Wjw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 11 Sep 2012 16:08:20 -0000 Message-ID: <20120911160820.55698.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <20120911152531.GJ79075@verdi> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: john@jlc.net Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 16:08:48 -0000 My goodness, you worked hard to misread what I said. >> It may well be a good idea not to bounce on SPF failure, but that's not >> for you, or the SPF spec to say. > > (Note that John Levine snipped the part where I distinguished MUST >from SHOULD.) Sure, since neither one belongs in the SPF spec. > If the sender policy is a clear "I didn't send this" (as I claim, >but John Levine seems to dispute), it's essentially no step at all to >"I don't want blowback DSNs". Gee, did we just drop through a wormhole into 2003 or something? Despite a great deal of wishful thinking, such as evidenced in the paragraph above, SPF failures don't always mean that a message is spam, nor that the putative sender didn't send it. It's strongly correlated, but as we all know, there is plenty of legitimate mail that SPF can't describe. Nobody wants blowback DSNs, but you, tne SPF publisher, don't get to tell me what I do with my mail, nor can you perfectly predict what will be blowback and what won't. As has been noted about a million times before, there are perfectly plausible forwarder scenarios in which sending the DSN is the right thing to do. You have no idea how my mail system is set up, and it is pure hubris to assert that you know enough to dictate my behavior. R's, John PS: If you were planning to reply along the lines that even if the SPF is wrong, I should follow it anyway, please don't. From sm@resistor.net Tue Sep 11 09:15:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F4221F8678 for ; Tue, 11 Sep 2012 09:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta72etPeF1VN for ; Tue, 11 Sep 2012 09:15:04 -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 A1F8821F8535 for ; Tue, 11 Sep 2012 09:15:04 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8BGErGH029518; Tue, 11 Sep 2012 09:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347380100; bh=LmUelGM9uDZO21h1DZxI7s0s6JIcdvwMk65lecg3NQw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3xgU4NZupiVJOBG2Wv/KUc1WJ2UAD2W2iUn4JXJEuTNltPA4UIovLAP1pjkDfpZdV JHcvqKh/U4xve/v3puFuKPMz/HS/0i6zK2USqN3BEDBk0ek3jg9F2nKXIORxfQKP+Y ta4JF+qhDEtv1+eFdypzSgrN3Kh1guv3w4UsYJCA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1347380100; i=@resistor.net; bh=LmUelGM9uDZO21h1DZxI7s0s6JIcdvwMk65lecg3NQw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=13HDpJOs8jXXZKUiN2CLxBzhT0n9UAAhDU/ttzj/6ASQEGttIjNeAzAkgKBnkeCc6 vyVjvQl4TpC4ItboVvwhyUibZpK8O4iy68xEL6niXCD+eze8qLAji+aiiCfcj7X6KA ArxhWRuuZJeXdAD58Iz6Q50q3lLOJcYYK+Bchfsc= Message-Id: <6.2.5.6.2.20120911081725.0a063ea8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 11 Sep 2012 09:12:18 -0700 To: dcrocker@bbiw.net From: SM In-Reply-To: <504F53EF.5040501@dcrocker.net> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <6.2.5.6.2.20120911021549.092d4610@elandnews.com> <504F53EF.5040501@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] draft-ietf-spfbis-4408bis document quality X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 11 Sep 2012 16:15:05 -0000 Hi Dave, At 08:08 11-09-2012, Dave Crocker wrote: >Please clarify your last sentence. Perhaps it is the 'and' that confused me. If I perform an individual review of a draft and my conclusion is that it needs more work, I say so. If WG consensus says otherwise, I am fine with that. Regards, -sm From dhc@dcrocker.net Tue Sep 11 09:22:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A2E21F8605 for ; Tue, 11 Sep 2012 09:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yd-V7ClFNUTS for ; Tue, 11 Sep 2012 09:22:31 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E2C5021F84EC for ; Tue, 11 Sep 2012 09:22:30 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8BGMRGF013962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Sep 2012 09:22:28 -0700 Message-ID: <504F6542.6030102@dcrocker.net> Date: Tue, 11 Sep 2012 09:22:26 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: SM References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <6.2.5.6.2.20120911021549.092d4610@elandnews.com> <504F53EF.5040501@dcrocker.net> <6.2.5.6.2.20120911081725.0a063ea8@resistor.net> In-Reply-To: <6.2.5.6.2.20120911081725.0a063ea8@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 11 Sep 2012 09:22:28 -0700 (PDT) Cc: spfbis@ietf.org, dcrocker@bbiw.net Subject: Re: [spfbis] draft-ietf-spfbis-4408bis document quality X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 16:22:35 -0000 On 9/11/2012 9:12 AM, SM wrote: > Hi Dave, > At 08:08 11-09-2012, Dave Crocker wrote: >> Please clarify your last sentence. Perhaps it is the 'and' that >> confused me. > > If I perform an individual review of a draft and my conclusion is that > it needs more work, I say so. If WG consensus says otherwise, I am fine > with that. ack. tnx. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From john@jlc.net Tue Sep 11 09:34:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8F621F873C for ; Tue, 11 Sep 2012 09:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ce9toIaipAI for ; Tue, 11 Sep 2012 09:34:01 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCDD21F8738 for ; Tue, 11 Sep 2012 09:34:01 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9D8DC33C27; Tue, 11 Sep 2012 12:34:00 -0400 (EDT) Date: Tue, 11 Sep 2012 12:34:00 -0400 From: John Leslie To: John Levine Message-ID: <20120911163400.GK79075@verdi> References: <20120911152531.GJ79075@verdi> <20120911160820.55698.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120911160820.55698.qmail@joyce.lan> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 16:34:01 -0000 John Levine wrote: > > My goodness, you worked hard to misread what I said. No harder, certainly, than you did to _ignore_ what I said. :^( > Nobody wants blowback DSNs, but you, tne SPF publisher, don't get to > tell me what I do with my mail, nor can you perfectly predict what > will be blowback and what won't. I assert that the SPF publisher has better information about this than the SMTP receiver. YMMV, obviously. > You have no idea how my mail system is set up, and it is pure hubris > to assert that you know enough to dictate my behavior. There's that straw-man, again... :^( (It's really time for the ad-hominem stuff to stop: I don't intend to respond to any further ad-hominem posts.) -- John Leslie From johnl@taugh.com Tue Sep 11 10:03:54 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564CA21F87BF for ; Tue, 11 Sep 2012 10:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8cq4BPRdVHL for ; Tue, 11 Sep 2012 10:03:53 -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 7504021F87AB for ; Tue, 11 Sep 2012 10:03:53 -0700 (PDT) Received: (qmail 79243 invoked from network); 11 Sep 2012 17:03:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=1358a.504f6ef7.k1209; bh=9OlZ7JNfuo2HEp7TNFH+pU268NvrIzbNfDISGAao9OI=; b=mUI22oRgI1qzRGAchR90z8mxrwlVQqqx0Sem1+ZZhQK1tqjflaqyvC4KKcg0YMfiob3sa1eoomvmNhIba65G4G15nzT7f8GwQS3ZI1/WSBDhPwvHR+/J68pUZ8qn98Mf1oPVet1yoz2FCqEUe/QCavKLVJzBD0HyHBxwXBQn+NQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=1358a.504f6ef7.k1209; bh=9OlZ7JNfuo2HEp7TNFH+pU268NvrIzbNfDISGAao9OI=; b=z7ADJ0SJ9atpnlO/mxVPT6/x6rBp95g35AiZNWhoq7fbFXrq2X+lfXws4upXTbaZFzh1UWPazUanVUQuFfyDJTB+EFMJGzuADjdVa/8fdKOgKbvywxD2BJeUAsBtcH/3ILsnF2TciI2U1u2BX7QBSMRumWbexgZjBWgdnWTHDBo= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 11 Sep 2012 17:03:29 -0000 Date: 11 Sep 2012 13:03:50 -0400 Message-ID: From: "John R Levine" To: spfbis@ietf.org In-Reply-To: <20120911163400.GK79075@verdi> References: <20120911152531.GJ79075@verdi> <20120911160820.55698.qmail@joyce.lan> <20120911163400.GK79075@verdi> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 17:03:54 -0000 >> Nobody wants blowback DSNs, but you, tne SPF publisher, don't get to >> tell me what I do with my mail, nor can you perfectly predict what >> will be blowback and what won't. > > I assert that the SPF publisher has better information about this > than the SMTP receiver. Wow, we really have fallen through a wormhole back to 2003. Time to go look for some duct tape. R's, John From superuser@gmail.com Tue Sep 11 10:45:57 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0381C21F87EC for ; Tue, 11 Sep 2012 10:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vN+buRUX3F1C for ; Tue, 11 Sep 2012 10:45:56 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4AF21F87E2 for ; Tue, 11 Sep 2012 10:45:56 -0700 (PDT) Received: by lahm15 with SMTP id m15so569745lah.31 for ; Tue, 11 Sep 2012 10:45:55 -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=94NPKAo7rq9mXGZJaxrLyuJCLw/r4RPyqgcCFXk80b0=; b=mTlT9j/6UCdQ1LzSktX7hP8LSQCc5GcPh3X3GwjWsFaZ/wx1lwRrEewAILFwcDM99d aromveM3bw+u2oV2AOeKN1RktT/ujAthIHAzlxTUEMJm/kY20xmRf+2vf0TXU0CZFw+e mRrMadbj6iKxmt2EsH/qSUTrkJY+heABm6NZoqrlaXqEi5NIaX5vgXVkPfF4OgG0EkQw 5kBMBLdNsnOCuL+pqIVH75CdKg6/b314qL64SV0w2Kx59GhuEoKfaYgHtODiADBXOxCV 81gehcZd4JpMJ9xlKALmbQ9kodu4ve797AcuXx0yAhxFcC76Vs67vshHHpPWwTHb62IG GKhA== MIME-Version: 1.0 Received: by 10.112.51.228 with SMTP id n4mr6490639lbo.55.1347385555119; Tue, 11 Sep 2012 10:45:55 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Tue, 11 Sep 2012 10:45:54 -0700 (PDT) In-Reply-To: <20120911163400.GK79075@verdi> References: <20120911152531.GJ79075@verdi> <20120911160820.55698.qmail@joyce.lan> <20120911163400.GK79075@verdi> Date: Tue, 11 Sep 2012 10:45:54 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Leslie Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, John Levine Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 17:45:57 -0000 On Tue, Sep 11, 2012 at 9:34 AM, John Leslie wrote: > I assert that the SPF publisher has better information about this > than the SMTP receiver. I assert that history has shown us that this is simply not the case. I've come to realize that message authentication work often blurs the lines between "the way it is" and "the way it ought to be". We as a community cling tenaciously and furiously to the latter as we fight the gravity of the former. >> You have no idea how my mail system is set up, and it is pure hubris >> to assert that you know enough to dictate my behavior. > > (It's really time for the ad-hominem stuff to stop: I don't intend > to respond to any further ad-hominem posts.) This whole exchange is on the ugly side, but John's post wasn't ad hominem. -MSK From superuser@gmail.com Tue Sep 11 10:48:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425DC21F84FC for ; Tue, 11 Sep 2012 10:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vP5P+qg+JZu2 for ; Tue, 11 Sep 2012 10:48:42 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB1821F84F6 for ; Tue, 11 Sep 2012 10:48:42 -0700 (PDT) Received: by lbky2 with SMTP id y2so623960lbk.31 for ; Tue, 11 Sep 2012 10:48:41 -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=ATc1zzZWHwgBargJHqtzlePioHZmy+dAfv0zykd2Gn4=; b=ipPCDhH5Lckxany2ZtbiqrPLu5bkRBHbJe4Lqpz9wJCyFv/xdIUDzz3ywdeeYq2ZEC rhj8rbuGp+HjLob0rfjnbvip8YCPOffyXl5+1EpsC+wHamCY1wOi7eLhIJ3VlLnCWgVo ub96qY/sdTwtZKuoIOm6t8fVknKVceb89z+PlfbP1NXGMv+2VtVCEtoOJQ/Vy9B2R+0o LmzmWLzWe702woyY8A+knzcwzw4u26g8XGYs6uS0Lb6dBXytFbCR2Xdx6Fz6J+Qcn8x7 1w3coEQnEwTvrjdhbu/lM5lN7+ekBY0AWt+gHdm2LU//2jFpAloafjMijTJtQ5VpappU VaLA== MIME-Version: 1.0 Received: by 10.152.104.145 with SMTP id ge17mr2716287lab.34.1347385721367; Tue, 11 Sep 2012 10:48:41 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Tue, 11 Sep 2012 10:48:41 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120911021549.092d4610@elandnews.com> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <6.2.5.6.2.20120911021549.092d4610@elandnews.com> Date: Tue, 11 Sep 2012 10:48:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: SM Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] draft-ietf-spfbis-4408bis document quality (was: #58: Local policy in 4408bis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 17:48:43 -0000 On Tue, Sep 11, 2012 at 3:32 AM, SM wrote: > I noticed during section-wise reviews that some topics are discussed in > several parts of the document. That can be a layout issue which affects > document clarity. I found it difficult to identify the requirements for > interpretability, i.e. what must be done for the protocol to work, what must I think you meant interoperability there. > It can be argued that any or all of the above is ok. I may be asked whether > I have personally reviewed the document that the WG considers as ready for > publication and, in particular, do I believe it is ready for forwarding to > the IESG. I would say no and point out that it is the consensus of SPFBIS. There's no "may" here. That's part of the PROTO writeup the shepherd (probably you or Andrew) needs to prepare before the document can go to the IESG. That is, you will indeed be asked that. -MSK From john@jlc.net Tue Sep 11 11:03:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D88921F854A for ; Tue, 11 Sep 2012 11:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 569h50kmH9it for ; Tue, 11 Sep 2012 11:03:42 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C45F021F8527 for ; Tue, 11 Sep 2012 11:03:42 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 0186E33C27; Tue, 11 Sep 2012 14:03:37 -0400 (EDT) Date: Tue, 11 Sep 2012 14:03:36 -0400 From: John Leslie To: "Murray S. Kucherawy" Message-ID: <20120911180336.GM79075@verdi> References: <20120911152531.GJ79075@verdi> <20120911160820.55698.qmail@joyce.lan> <20120911163400.GK79075@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 18:03:43 -0000 Murray S. Kucherawy wrote: > On Tue, Sep 11, 2012 at 9:34 AM, John Leslie wrote: > >> I assert that the SPF publisher has better information about this >> than the SMTP receiver. > > I assert that history has shown us that this is simply not the case. Aha! The basis for a good discussion... Do you mean that SMTP receivers have better information (about what will be blowback), or that neither has any useful information? -- John Leslie From sm@resistor.net Tue Sep 11 11:22:25 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D717321F8692 for ; Tue, 11 Sep 2012 11:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ig7b2QsLgTOw for ; Tue, 11 Sep 2012 11:22:25 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2275621F8682 for ; Tue, 11 Sep 2012 11:22:24 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8BIMHGx021020; Tue, 11 Sep 2012 11:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347387744; bh=0WAI/5LJMXV2j92HoWEzeERLJ3B2pa0XSr68oNEUjIA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Hs9k7IB/0wVuvYV3YeEAzZD4jRRS2F88ZZRZSD6FUCpUAliAu+Fet6Q1xKHG20xFF rMZR8NtI1bChDfgM9YFTBJrOl9D7dJ3SqRmAMXQ7lwt9jxmYBu8ykq3F+F7o4O4OwR F3kOc/4kSQFlBkoGBZPOkhjLxkPQZ+lNDF1XHDN0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1347387744; i=@resistor.net; bh=0WAI/5LJMXV2j92HoWEzeERLJ3B2pa0XSr68oNEUjIA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=WWbKW6sBrORypT4r4QYQhjGqjQSN6F8b7psWwVzP+Pv3kOVZembOq/ZZGhtndpX9u KRqh8UvB/n1KQEys6R1EEC7YTO+8Q6hgPHIPV6CtlIJHbuLWetxnfFdoUXfwjcpJXi KYdg5AnzQ8OSnJCmVzUDxRDfxWym9dt7MuMpE0tc= Message-Id: <6.2.5.6.2.20120911104926.0a064280@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 11 Sep 2012 11:22:06 -0700 To: "Wayne Doust" From: SM In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185197@XCHANGE.rvl.inter nal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185197@XCHANGE.rvl.internal> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Secetion 4.6.4 DNS Lookup Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 11 Sep 2012 18:22:26 -0000 Hi Wayne, At 19:53 10-09-2012, Wayne Doust wrote: >I suggest adding the following (or similar) text to this section at >an appropriate location: > >"MTAs (or other processors) MUST apply the DNS lookup limit >sequentially as the record is >evaluated and not prematurely issue a permerror based on potential >lookups. For example, >an SPF record containing a potential 11 DNS queries should not >permerror unless the evaluation >does not satisfy any of the prior mechanisms that require less than >or equal to 10 DNS queries." The text adds one more requirement (MUST) to the specification. The question I would ask is why is this change necessary and what is the impact on RFC 4408 implementations. Before proceeding with such a change a person might check whether there is already already text in the document about that. There is, for example, the following text in the draft: 'When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, there MUST be a limit of no more than 10 MX or PTR RRs looked up and checked. If more than 10 "mx" or "ptr" records are returned for this further lookup, a permerror MUST be returned. This limit is per mechanism or macro in the record and in addition to the lookup limits above.' and: 'Minimizing the DNS resources required for SPF lookups can be done by choosing directives that require less DNS information and by placing lower-cost mechanisms earlier in the SPF record. +----------+--------+-----------------+ | term | cost | limit | +----------+--------+-----------------+ | ip4/ip6 | 0 | - | | a | 1 | 10 | | include | 1 | 10 | | redirect | 1 | 10 | | exists | 1 | 10 | | mx | 1 + N* | 10 and N* <= 10 | | ptr/%{p} | 1 + N* | 10 and N* <= 10 | | all | 0 | - | +----------+--------+-----------------+ * N is the number of RRs found during each term evaluation' The quoted text, and with the proposed text, can lead to different interpretations. Regards, -sm From superuser@gmail.com Tue Sep 11 11:37:10 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E4721F862A for ; Tue, 11 Sep 2012 11:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8MSO3QO6wZQ for ; Tue, 11 Sep 2012 11:37:10 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D09A121F860F for ; Tue, 11 Sep 2012 11:37:09 -0700 (PDT) Received: by lahm15 with SMTP id m15so603031lah.31 for ; Tue, 11 Sep 2012 11:37:08 -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=uYIythLfgN2UeRs/k47BnpE2l1l10zYNjL/RKFfCWNg=; b=iOOUgSAKGrZKWfGw2z2RQfvVfya63uPNCpoxuZpGUjlCQLiiC+3LGYUA5UX1YgnsEv qQdOfcp9SbKNxCnaEb0ahuJp1phAAJdNQhZvPkl3H1hx6wegl0pT/wJsoDpGWPHrr0cu QBRe2Vf8a8IYUPIs2s4ld2AdaXf10ht9ij/FT55owtNPYnDMm4L/PV2jSmDyQRm3rxsI XOY3lZ/zrayFaNXEKMKRi5ixol0j/AV5SXhNuywiwNX8Lr9VbDPcqOnF87GHoCuUznfp FXFK84gor+3WZpGVqBeprak8OE7EoSghhh+ADZDE5vdjmi0krNxIgeC9rqH2WdYmy4yX W+Ew== MIME-Version: 1.0 Received: by 10.152.104.145 with SMTP id ge17mr2859303lab.34.1347388628858; Tue, 11 Sep 2012 11:37:08 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Tue, 11 Sep 2012 11:37:08 -0700 (PDT) In-Reply-To: <20120911180336.GM79075@verdi> References: <20120911152531.GJ79075@verdi> <20120911160820.55698.qmail@joyce.lan> <20120911163400.GK79075@verdi> <20120911180336.GM79075@verdi> Date: Tue, 11 Sep 2012 11:37:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Leslie Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 18:37:11 -0000 On Tue, Sep 11, 2012 at 11:03 AM, John Leslie wrote: >>> I assert that the SPF publisher has better information about this >>> than the SMTP receiver. >> >> I assert that history has shown us that this is simply not the case. > > Do you mean that SMTP receivers have better information (about what > will be blowback), or that neither has any useful information? I mean the receiver is the one who gets to see by which paths mail arrives. Consider that there are two sets of mail paths, namely (a) those that the domain owner thinks it's using, and (b) those by which mail actually arrives. Those who claim the senders know better and should be able to assert receiver policy appear to operate under the impression that (a) is absolute or that the two sets are equal, when in reality we've seen that (b) is nearly always a proper superset of (a). The place in the resulting Venn diagram where the two do not overlap is false negative territory, and it's potentially very painful for receivers. The very same thing came up in DKIM policy, which tried at first to have a strong policy component, but we quickly learned that this approximately impossible to achieve with sufficient reliability as to be actionable. Although people characterize this as "watering down" of DKIM policy, it is merely acceptance of the reality that receiver policy cannot be expressed with universal normative language. Better still, ADSP showed us that trying to force receiver-side policy can cause collateral damage to uninvolved third parties. I've yet to encounter a system anywhere in my career, from personal machines to large corporate server clusters, where any of the policy mechanisms coupled with message authentication schemes -- and that includes SPF and ADSP -- are used in an absolute fashion. So from where I sit, if there's no industry demand for universal normative receiver policy after all these years, we should stop trying to write one, let alone the fact that it's not a protocol's business to do so. We really need to stop trying to go there. -MSK From sm@resistor.net Tue Sep 11 11:37:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1EA21F84D6 for ; Tue, 11 Sep 2012 11:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4x2hamjaqae for ; Tue, 11 Sep 2012 11:37:43 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0FB21F84D1 for ; Tue, 11 Sep 2012 11:37:42 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8BIbWlV025252; Tue, 11 Sep 2012 11:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347388658; bh=eYdBDkQPyaVCvhhXinDHxxXGpQAyg2T8MoPNcGGQ1Rc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3r5V1zADfj4j5SU7Vgc5ndc+VSzzjCni+2M2f5rZpxkLXj9dBnwRVJcMeCFXqhFgH q4hg/VbvbjqxlCi8kDyggKghzvdcpLh6irvrjdNlJHvCc0e6Tt81ZzRfy97aJa1NvZ n0hbFsQWPVqGAPMnH0NYl5Lnk25eUREn5Catb2ZM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1347388658; i=@resistor.net; bh=eYdBDkQPyaVCvhhXinDHxxXGpQAyg2T8MoPNcGGQ1Rc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=lw72EgWEE1gwxnL/IaxGr8fk2lrcj/R58SfGdFjqE0MyXnhvUMR522Z95yScy0xtl crni2hAFYepRGFR+llsktKCQSnPO4vxo9gzwS83Jg2ZwuV4cLOCzdEVKr4iwBhujY2 LVADVpV0svtl33ey9G8S0B07JvomszJOGP0IBNsA= Message-Id: <6.2.5.6.2.20120911112628.0a6d5110@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 11 Sep 2012 11:33:20 -0700 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <6.2.5.6.2.20120909183855.06e8e800@elandnews.com> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <6.2.5.6.2.20120911021549.092d4610@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] draft-ietf-spfbis-4408bis document quality (was: #58: Local policy in 4408bis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 18:37:45 -0000 Hi Murray, At 10:48 11-09-2012, Murray S. Kucherawy wrote: >I think you meant interoperability there. Yes. >There's no "may" here. That's part of the PROTO writeup the shepherd :-) Regards, -sm From superuser@gmail.com Tue Sep 11 11:41:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817A621F8533 for ; Tue, 11 Sep 2012 11:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ttwm6TngUJl for ; Tue, 11 Sep 2012 11:41:34 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 83C3A21F8530 for ; Tue, 11 Sep 2012 11:41:34 -0700 (PDT) Received: by lbky2 with SMTP id y2so659187lbk.31 for ; Tue, 11 Sep 2012 11:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j401f+Qsv627wNCn/jN2fz1wZCIFxEgz0BkACYe8FOs=; b=at3V3Zp2OKuxxhs3KalCYBM+aXxWHmHm3FZq0QXViHv7NpyknkwsGUXPbmToLibUZm cb1nYIfqyWH7OZn64NV9sfUQN17wDhsR30rPlqI4szdxkZtx6FjACcy3dysRg61mh5Jh JsJMSTfkaIwjexFBW7F8j14Si5uWf59NwXOHYoLBvhbTC/jRi1oBaBzxYx+APXIEYVeX GWN1xR1wGifi4MkSxJSaS5vlCYo2a/SJ+W3ORj1umBun23WwSyTfp90XnIglQRkv8RrN oAHeDP+BBCnwhUK+emxCiHYWc4SpsHEeIfjEYa7LB8y2zZTcDiB31MVWT6wx01R50q6R a6rg== MIME-Version: 1.0 Received: by 10.152.122.9 with SMTP id lo9mr16678863lab.41.1347388893187; Tue, 11 Sep 2012 11:41:33 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Tue, 11 Sep 2012 11:41:32 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120910231140.09679ce0@resistor.net> References: <504D1416.8040400@Commerco.Net> <20120910004749.44123.qmail@joyce.lan> <6.2.5.6.2.20120910231140.09679ce0@resistor.net> Date: Tue, 11 Sep 2012 11:41:32 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Scott Kitterman Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 11 Sep 2012 18:41:35 -0000 On Tue, Sep 11, 2012 at 12:39 AM, S Moonesamy wrote: > I haven't discussed this issue with Andrew yet. I don't see agreement on > Issue #33 ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02195.html ). > Murray Kucherawy suggested some text where it is argued that the attack on > SPF is outside the scope of the specification ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02661.html ). I > don't see agreement on the text which Murray proposed. During the > discussion, Barry Leiba raised an interesting point about a sentence in > Section 2.5.4 ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02708.html ). I > reopened Issue #29 based on that ( > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/29#comment:5 ). >[...] Someday when we have searchable archives I will be able to provide links like you do, but I'm apparently less patient than you are at finding them with the current system. Some time ago Scott pointed out that the RFC that lays out guidance for Security Considerations sections specifically calls out message injection attacks as something that needs to be documented. The description it uses seemed to point almost directly at this issue. I think that compels us to say something about it, and not close it unaddressed. I'd like to hear more comments about the text I proposed, which I recall at least Scott liked. -MSK From agthisell@yahoo.com Tue Sep 11 12:53:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CB021F8703 for ; Tue, 11 Sep 2012 12:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[AWL=0.741, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TRNWtns6JBd for ; Tue, 11 Sep 2012 12:53:04 -0700 (PDT) Received: from nm35-vm1.bullet.mail.ne1.yahoo.com (nm35-vm1.bullet.mail.ne1.yahoo.com [98.138.229.97]) by ietfa.amsl.com (Postfix) with SMTP id D63C921F8688 for ; Tue, 11 Sep 2012 12:53:02 -0700 (PDT) Received: from [98.138.90.56] by nm35.bullet.mail.ne1.yahoo.com with NNFMP; 11 Sep 2012 19:52:58 -0000 Received: from [98.138.88.238] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 11 Sep 2012 19:52:58 -0000 Received: from [127.0.0.1] by omp1038.mail.ne1.yahoo.com with NNFMP; 11 Sep 2012 19:52:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 156322.47516.bm@omp1038.mail.ne1.yahoo.com Received: (qmail 97221 invoked by uid 60001); 11 Sep 2012 19:52:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347393178; bh=BEiteks3YNQ6YM9JOm8+9zElsHOfezGKKKC4Xk+jKHo=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=FVBSyA7jQtE4pp2wK/rxsNw3XKsk4vxpBwyx0y1Shayqq7AW60umacg715iY2z3Ffdnp/lGrSgUZNBI1daGfnO7U9M63CvBHZC8c+/1jx2oVNwNSN6AjVVlY00/+J00kngyP99xB49SJFKE0jeoxt2N+ZfptY2tg98XgnQctRLo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=QN0Rj0K8WS5KvUfP12hSbNJ3ShQx7gJesjX49cmyJ4rD046sIZVmkWY4mrWagBBqP93soMXsGyGfScx69swzBXbmB7NwbkRcBNPWikC2OuhRNNFEucqivbw4GzOpi8RqsdSrR0rOsdngcDtgeB/31ANLfngSCQeBfUBcbfxYEHA=; X-YMail-OSG: zLrILxEVM1mI4gO_5gUYiyEzfajL11CgWso8r9IDBpRlOv6 dqJ7GQe4vuOewgYLuYdnpiC1EI2vQr946IvKoo55Ibm6_6T6qOVRAHHOH7YY vRhitLJfkrxZ.Y.6b8L9Jjo824b3g6wDsylVDmMDXGH09zpD34p2pNey86MN .F1Pn0WnrnXE9O9bLvCRiRg_re3oaZRQLhU52IfJPYLtMDl7HWGOHR32MZ1z Z0aUEPPGM2eY_4DZjiZj.rydEZkjMuVVd4YyJUtJYJTJwWRca2htG0OELyW4 k.kzIEEeNPbZ4EiLm77kjto4eeF5vPi42dtRCOa8GwowLJmnBnIg.L6E6RGx 00l8G_key.Wa7wxtKmD9YkRYUzbywxCRdzWtXfNJSxfkJ_FVJdI2Le0pf1CU wb8aznFu35Xb.8Jm4q4ldndy3hzhzRTABmVJESqxGbIfEVMUNMGRj8GOcVtM F9kry5uxZGskva4u4uIU- Received: from [71.61.133.134] by web125104.mail.ne1.yahoo.com via HTTP; Tue, 11 Sep 2012 12:52:57 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347393177.77277.YahooMailClassic@web125104.mail.ne1.yahoo.com> Date: Tue, 11 Sep 2012 12:52:57 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] Secetion 4.6.4 DNS Lookup Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 11 Sep 2012 19:53:06 -0000 > The question I would ask is why is this change necessary and what is the > impact on RFC 4408 implementations. Yes, I think you have the right approach. However, you then went on to give these examples: > 'When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, > there MUST be a limit {...} That is new text to RFC 4408bis and it is wrong. The spirit is right, but the new text breaks both ptr: and %{p}. > 'Minimizing the DNS resources required for SPF lookups can be done by > {...} {table snipped} That is new text to RFC 4408bis and it is wrong. Now, apparently non-normative sections of an RFC can contradict normative sections, but you can't really use non-normative sections to say how normative sections should be. Let's try this from RFC 4408: > Implementations MAY choose to parse the entire record first and > return "PermError" if the record is not syntactically well formed. > However, in all cases, any syntax errors anywhere in the record MUST > be detected. Now, it can be debated whether too many mechanism is a syntax error or not, but the spirit is that errors that can be detected early, must be detected early. Basically, the XML model of strict checking rather than the tag soup model of HTML. From sm@elandsys.com Tue Sep 11 14:14:38 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C671F21F855F for ; Tue, 11 Sep 2012 14:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgZGU+cUAeis for ; Tue, 11 Sep 2012 14:14:38 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3C421F8682 for ; Tue, 11 Sep 2012 14:14:37 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.179]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8BLEFSC002383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Sep 2012 14:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347398069; bh=hWZ0VCJJJYnYn9agNcfAsd8cRUdq0BUkYvcO3UlNQWQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=SXrRjeB2o3iVW/+YEXBKDlYatb4Wi9blnzz7XslJmzQgmWm9eL54Qvf3B2yQXttnW QfmdwppCMGZ4NyFZADKTYl0yUfpiXKQClGixxSulFANvloK2tXzKeyO9XmkIw2Hu1j gtsgsiu//f46cqFUR6XNKCJYb5EUMZdE1UvnXS1E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347398069; i=@elandsys.com; bh=hWZ0VCJJJYnYn9agNcfAsd8cRUdq0BUkYvcO3UlNQWQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=x9P+vuahTMoEZ8C1mctAZ1D68Fh9ZoJH+icIohmiOQJ5gy8S8Sc9WnKJOju7m/dha w130dW590b/cHiof17fCWLUhVuM0sqzyyO8RPCq7iiMcX+JgFsoIbelU5lm22A2OU0 /kO5BeoINaEYrlgX9VDZYB2pnt3ejP/0TKWbb35Y= Message-Id: <6.2.5.6.2.20120911124231.0a011a88@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 11 Sep 2012 13:46:13 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <504D1416.8040400@Commerco.Net> <20120910004749.44123.qmail@joyce.lan> <6.2.5.6.2.20120910231140.09679ce0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 11 Sep 2012 21:14:38 -0000 Hi Murray, At 11:41 11-09-2012, Murray S. Kucherawy wrote: >Someday when we have searchable archives I will be able to provide >links like you do, but I'm apparently less patient than you are at >finding them with the current system. It's a hit and miss affair with search engines. I read the messages locally to identify what to look for. It can be quite tedious. >Some time ago Scott pointed out that the RFC that lays out guidance >for Security Considerations sections specifically calls out message >injection attacks as something that needs to be documented. The >description it uses seemed to point almost directly at this issue. I >think that compels us to say something about it, and not close it >unaddressed. I would not describe it as a message injection attack as that line of argument may create more issues than it solves. I wrote draft-moonesamy-mail-security-00 (expired) to document some arguments about mail content. It was in response to a review where the reviewer asked the following question: "Presumably you mean to say that binary attachments that are ideal for delivering malware are supported irrespective of the use of this feature, right?" That is somewhat along the lines of what your text argues about. I would keep it in mind for the Security Considerations section. Regards, S. Moonesamy From spf2@kitterman.com Tue Sep 11 14:44:57 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D867621E8042 for ; Tue, 11 Sep 2012 14:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gc2t8SjJA-1a for ; Tue, 11 Sep 2012 14:44:57 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 393DD21E803F for ; Tue, 11 Sep 2012 14:44:57 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4567220E4106; Tue, 11 Sep 2012 17:44:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347399896; bh=tI81HB/Xle/bsTr68F3BidLwT14G1kIsnutBX+4BED0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fxcoXMDMzCekZyJ3hk10d5c3lFXCa61++JNRhn87R4ftCbYWcsyalxfQGxxHtAHoX ChlkTplGps6CULk85nZ/hzePryNNWvEgHcUyfedNkfsRQzFpVZzyjNW3utTrHSIubp /P2mbHy+3vexfc/ZDBOaJYLIjaEVRoPk8upLtwKA= Received: from scott-latitude-e6320.localnet (93.sub-70-192-198.myvzw.com [70.192.198.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0399A20E4085; Tue, 11 Sep 2012 17:44:55 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 11 Sep 2012 17:44:51 -0400 Message-ID: <1700698.tMxCIrnJSm@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <1347393177.77277.YahooMailClassic@web125104.mail.ne1.yahoo.com> References: <1347393177.77277.YahooMailClassic@web125104.mail.ne1.yahoo.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] Secetion 4.6.4 DNS Lookup Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 11 Sep 2012 21:44:58 -0000 On Tuesday, September 11, 2012 12:52:57 PM Arthur Thisell wrote: > Let's try this from RFC 4408: > > Implementations MAY choose to parse the entire record first and > > return "PermError" if the record is not syntactically well formed. > > However, in all cases, any syntax errors anywhere in the record MUST > > be detected. > > Now, it can be debated whether too many mechanism is a syntax error or not, > but the spirit is that errors that can be detected early, must be detected > early. Basically, the XML model of strict checking rather than the tag > soup model of HTML. My initial thought for the start of this message was to quote this section as well. Right to left parsing with errors only if the error condition is triggered is a recipe for what appears to be random failures when a record works some times and not others. In any case prohibiting total record error detection and requiring left to right processing would be a substantiative change to the protocol. I don't think it would be a good one either. Scott K From spf2@kitterman.com Tue Sep 11 14:48:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F0121E803F for ; Tue, 11 Sep 2012 14:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJfBAUwkFKOt for ; Tue, 11 Sep 2012 14:48:51 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BA55421E803C for ; Tue, 11 Sep 2012 14:48:51 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4855920E4106; Tue, 11 Sep 2012 17:48:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347400131; bh=xWx5K3V7F2F+TuGfs4kBubkSStAGJAiy8yyN57wzcnY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VXSdQBAhLm12dF9o3mGo27RG9n48sHQs24gSuQSZuhC3U25HfC4JOHCS56f7BLd6P w5E3AS0HFIhq7plH44Dp2RRl/f/7Y7NLm3nWKSjUy3+WSXCSO+4taOqH7IOZjSUKZI lMcLLO/KFRHvWvxPos/CIpjNtSew631GV4KyK6j8= Received: from scott-latitude-e6320.localnet (93.sub-70-192-198.myvzw.com [70.192.198.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0FDF120E4085; Tue, 11 Sep 2012 17:48:50 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Date: Tue, 11 Sep 2012 17:48:49 -0400 Message-ID: <2057829.z8Dp9SVqJf@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20120911013244.09617218@elandnews.com> References: <6.2.5.6.2.20120911013244.09617218@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: S Moonesamy Subject: Re: [spfbis] Changes to draft-ietf-spfbis-4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 21:48:52 -0000 On Tuesday, September 11, 2012 01:35:49 AM S Moonesamy wrote: > Hi Scott, > > It would help if the WG can see which text in > draft-ietf-spfbis-4408bis has agreement. I suggest that for those > things where you are suggesting text that the WG hasn't agreed to > yet, mark it as such in the document to distinguish it from the text > that is in your opinion solid. It's a bit difficult to know since we've only had one person reporting doing a thorough scrub of the entire document. A first order approximation would be anything that is unchanged between -06 and -07 for which there is not an open issue. Scott K From superuser@gmail.com Tue Sep 11 15:02:51 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E693421E8044 for ; Tue, 11 Sep 2012 15:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4p8GiW9JKZU for ; Tue, 11 Sep 2012 15:02:51 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E47221E8042 for ; Tue, 11 Sep 2012 15:02:50 -0700 (PDT) Received: by lbky2 with SMTP id y2so775491lbk.31 for ; Tue, 11 Sep 2012 15:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wpu9rRRHS72VhdopxhEHzkEThUmnCpNBnaLfCAAifX8=; b=hI4QvGJPvhbQXX5ofiAynziA/N7tARbaHORgRzINHZpfyHnvIeRBart8swlVr98cmQ 9ISRPiyJ+9z0ApDWp9UUtmQWEp6ZpqPtwB2/ldzCFntvN0M1qyJp8LMFxb+6J35PYe4V 0HG5ioRV7z88AyDA74mzg1baK/bxyp5ssJnjXy9UxP2xVSsziPC9h97VwKt/+UdrQq0b hua8Tvd4SYFuSEyXaztZ9poazaM1UM/9SAguchmQDCu/opsW52XwCR8xC0vtboRONzk0 KSqiMbMb+EbPgZL2Y1nzWAJnvAD/43VzVeCj71bKeVcz2Rb0BuSisIrSJJu9BGdGEeSS jYxA== MIME-Version: 1.0 Received: by 10.152.104.145 with SMTP id ge17mr3339471lab.34.1347400970061; Tue, 11 Sep 2012 15:02:50 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Tue, 11 Sep 2012 15:02:49 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120911124231.0a011a88@elandnews.com> References: <504D1416.8040400@Commerco.Net> <20120910004749.44123.qmail@joyce.lan> <6.2.5.6.2.20120910231140.09679ce0@resistor.net> <6.2.5.6.2.20120911124231.0a011a88@elandnews.com> Date: Tue, 11 Sep 2012 15:02:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 11 Sep 2012 22:02:52 -0000 On Tue, Sep 11, 2012 at 1:46 PM, S Moonesamy wrote: > That is somewhat along the lines of what your text argues about. I would > keep it in mind for the Security Considerations section. I think the proposed text takes this into account. It specifically calls out that there are cases where the feature can admit bad stuff, or block good stuff. One's mileage may vary, caveat emptor, etc. That's basically it. -MSK From spf2@kitterman.com Tue Sep 11 15:03:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02AAB21E8043 for ; Tue, 11 Sep 2012 15:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMuf9pZbY87p for ; Tue, 11 Sep 2012 15:03:00 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 26D5021E8042 for ; Tue, 11 Sep 2012 15:03:00 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9965720E4106; Tue, 11 Sep 2012 18:02:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347400979; bh=rQ2N6BIcmXhT3lFOnpIhc9aArpkQlC5WxAPsrAGecIw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=AolYWn53hecjJDs8TQYigQN66DoNjoUI0BDbwkHXZDkVsYK6Xka1YQ6AWi37C7RdH ukUtv4rbg2jGwVg0mJnuqerrPwa1KU+FA7vhpNBeoo1QLQcGa5fjPX/B49pXlp9q5o +QoPPP+fafbBbjwPskmUsIgUI+9FZLQwXGSZ71/I= Received: from scott-latitude-e6320.localnet (93.sub-70-192-198.myvzw.com [70.192.198.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 55F7D20E4085; Tue, 11 Sep 2012 18:02:58 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 11 Sep 2012 18:02:57 -0400 Message-ID: <17975455.mDjxCEe1hM@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: References: <20120911152531.GJ79075@verdi> <20120911180336.GM79075@verdi> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 22:03:01 -0000 On Tuesday, September 11, 2012 11:37:08 AM Murray S. Kucherawy wrote: > On Tue, Sep 11, 2012 at 11:03 AM, John Leslie wrote: > >>> I assert that the SPF publisher has better information about this > >>> than the SMTP receiver. > >> > >> I assert that history has shown us that this is simply not the case. > >> > > Do you mean that SMTP receivers have better information (about what > > > > will be blowback), or that neither has any useful information? > > I mean the receiver is the one who gets to see by which paths mail > arrives. Consider that there are two sets of mail paths, namely (a) > those that the domain owner thinks it's using, and (b) those by which > mail actually arrives. Those who claim the senders know better and > should be able to assert receiver policy appear to operate under the > impression that (a) is absolute or that the two sets are equal, when > in reality we've seen that (b) is nearly always a proper superset of > (a). The place in the resulting Venn diagram where the two do not > overlap is false negative territory, and it's potentially very painful > for receivers. > > The very same thing came up in DKIM policy, which tried at first to > have a strong policy component, but we quickly learned that this > approximately impossible to achieve with sufficient reliability as to > be actionable. Although people characterize this as "watering down" > of DKIM policy, it is merely acceptance of the reality that receiver > policy cannot be expressed with universal normative language. Better > still, ADSP showed us that trying to force receiver-side policy can > cause collateral damage to uninvolved third parties. > > I've yet to encounter a system anywhere in my career, from personal > machines to large corporate server clusters, where any of the policy > mechanisms coupled with message authentication schemes -- and that > includes SPF and ADSP -- are used in an absolute fashion. So from > where I sit, if there's no industry demand for universal normative > receiver policy after all these years, we should stop trying to write > one, let alone the fact that it's not a protocol's business to do so. > > We really need to stop trying to go there. Things are a bit different now though. We have RFC 6652 that gives domain owners a way to express an interest in feedback about these kinds of messages. It does use MUST NOT on sending auth failure arfs if they are not requested. I realize that's not exactly the same situation, but it's similar. We probably can't, but it'd be nice to wrap this up into something that said SHOULD NOT bounce for non-pass SPF results and use auth failure arfs instead if they have been requested. Part of the purported benefit of SPF is that it allows you to take actions based on a name based identifier for SPF pass. I think the flip side of that, that one shouldn't do so for non-SPF pass is equally reasonable. Scott K From johnl@iecc.com Tue Sep 11 15:03:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBC421E8043 for ; Tue, 11 Sep 2012 15:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17SL9E0LkzW0 for ; Tue, 11 Sep 2012 15:03:43 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 6642D21E8042 for ; Tue, 11 Sep 2012 15:03:43 -0700 (PDT) Received: (qmail 41250 invoked from network); 11 Sep 2012 22:03:42 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 11 Sep 2012 22:03:42 -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:vbr-info; s=504fb53e.xn--30v786c.k1208; i=johnl@user.iecc.com; bh=syKDG6uSE7AfMsUCfNmeFXODpEqz9q4EJXEa+VIBuUs=; b=KavgCe7dIPuasucQ/KOnNsMvMN+U81QrA4Lj+l9vSUrmmDfwnQplwlxNgF8N98orX8fSQrd2e6BfypB3QHU7ItfL/1FcBDWDgEeUPoiojv2DozITHiAdYBgodRI27wECCZtK790cNI+uU8hDXP617lCA1stqyIcekas0zggYA/U= 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:vbr-info; s=504fb53e.xn--30v786c.k1208; olt=johnl@user.iecc.com; bh=syKDG6uSE7AfMsUCfNmeFXODpEqz9q4EJXEa+VIBuUs=; b=ctzGks+4hbfYiJmtKdg9oY4X8NUQrHPzQmLNKfv0WTcF7htEfjmlYa2FKbrFC26/bxyd/2Ow2NCZfzwPeqZeh9emf3eb5SUF5JcDhkxZIjR3hV8fupm9aM2GqtiAlxy4Ib1iO1jCgodUM5R1ntYUeVw3orocejrysgRigeFXAnE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 11 Sep 2012 22:03:19 -0000 Message-ID: <20120911220319.16164.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <20120911180336.GM79075@verdi> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: john@jlc.net Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 22:03:44 -0000 > Do you mean that SMTP receivers have better information (about what >will be blowback), or that neither has any useful information? The former, of course, since many receivers have a pretty good idea of who's forwarding mail to them, and how good a job of inbound filtering they do. For example, the DMARC reports that Google sends identify the forwarders in impressive detail. Really, this is all stuff that has been covered at length in prior SPF arguments. It's hard to see any value in rehashing it yet again. If you want to do so, it would be very helpful to refer to the previous arguments and explain why this time is different. R's, John From spf2@kitterman.com Tue Sep 11 15:04:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F13421E8043 for ; Tue, 11 Sep 2012 15:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZrGxXls1xPr for ; Tue, 11 Sep 2012 15:04:01 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E0B4C21E8042 for ; Tue, 11 Sep 2012 15:04:00 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4B16120E4106; Tue, 11 Sep 2012 18:04:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347401040; bh=G752PCrIQwq1HWogXjVdDJcAHGC7DBDCFc9IA2qGj4I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VbDNB8OBbejmmByAX7u7aar3boGWOsIEAty7FV+UJFD3NIVGq24Lpj/lqyUFmjkaA Ux5ZO8PNt/leT0FO/m5LQvD9D9/Um0614XXBMZ0S6L/nahf2JNYl3OSFoEOzNQ2EQ3 QwW2IE/J1fhY395nbqK0fRWLRFKir5m2wUs9etxI= Received: from scott-latitude-e6320.localnet (93.sub-70-192-198.myvzw.com [70.192.198.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 263D820E4085; Tue, 11 Sep 2012 18:04:00 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 11 Sep 2012 18:03:58 -0400 Message-ID: <1404934.FFaeq4aLpl@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: References: <504D1416.8040400@Commerco.Net> <6.2.5.6.2.20120910231140.09679ce0@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 11 Sep 2012 22:04:01 -0000 On Tuesday, September 11, 2012 11:41:32 AM Murray S. Kucherawy wrote: > On Tue, Sep 11, 2012 at 12:39 AM, S Moonesamy wrote: > > I haven't discussed this issue with Andrew yet. I don't see agreement on > > Issue #33 ( > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02195.html ). > > Murray Kucherawy suggested some text where it is argued that the attack on > > SPF is outside the scope of the specification ( > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02661.html ). I > > don't see agreement on the text which Murray proposed. During the > > discussion, Barry Leiba raised an interesting point about a sentence in > > Section 2.5.4 ( > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02708.html ). I > > reopened Issue #29 based on that ( > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/29#comment:5 ). > > > >[...] > > Someday when we have searchable archives I will be able to provide > links like you do, but I'm apparently less patient than you are at > finding them with the current system. > > Some time ago Scott pointed out that the RFC that lays out guidance > for Security Considerations sections specifically calls out message > injection attacks as something that needs to be documented. The > description it uses seemed to point almost directly at this issue. I > think that compels us to say something about it, and not close it > unaddressed. > > I'd like to hear more comments about the text I proposed, which I > recall at least Scott liked. It's my recollection that I did as well. Scott K From superuser@gmail.com Tue Sep 11 15:12:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DDA21E804A for ; Tue, 11 Sep 2012 15:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4pbMIAlVKGj for ; Tue, 11 Sep 2012 15:12:03 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D062921E8049 for ; Tue, 11 Sep 2012 15:12:02 -0700 (PDT) Received: by lbky2 with SMTP id y2so779640lbk.31 for ; Tue, 11 Sep 2012 15:12: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=dw73Z6ZCGPmVwPWRMQgsqDUORWG6aCT3evICeNvSWvY=; b=y7m13xQkWIHksXOKZFn2eMobWektax4T+M1SFHym27t1G3WvWv0J+6t6QYXMDkwDIh BBl9fKKfWpwThlE5thlJGMxllzeqee1vNRE4pshkPQPUCVZk1SGDEJBNf4oXEEZsfQ7I mEPiYkaDAbyObG+OzNJ8PgQsrHug6PBS/MGqxUD1yFVetAzsoW+CZMWUDv8FGJ0iJA6z eyihGujVkz2k4yciDDMUKFjfkzk2kb+IGgwbx7NQp5PmlxnrqatWfbjHgwqjyaXDj3y8 sOHomr7MJWrXygZfFXcNwU8JP6fD/TN9Khh6fTYhYDP1xoFpSE1NFI9q9hWiOWEEsFdJ R3lA== MIME-Version: 1.0 Received: by 10.112.84.101 with SMTP id x5mr6662849lby.28.1347401521548; Tue, 11 Sep 2012 15:12:01 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Tue, 11 Sep 2012 15:12:01 -0700 (PDT) In-Reply-To: <17975455.mDjxCEe1hM@scott-latitude-e6320> References: <20120911152531.GJ79075@verdi> <20120911180336.GM79075@verdi> <17975455.mDjxCEe1hM@scott-latitude-e6320> Date: Tue, 11 Sep 2012 15:12:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 22:12:03 -0000 On Tue, Sep 11, 2012 at 3:02 PM, Scott Kitterman wrote: > We probably can't, but it'd be nice to wrap this up into something that said > SHOULD NOT bounce for non-pass SPF results and use auth failure arfs instead > if they have been requested. If some set of implementations already have that provision in them, I think it fits in the charter to document as a deployed enhancement. -MSK From spf2@kitterman.com Tue Sep 11 15:12:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B2621F85A8 for ; Tue, 11 Sep 2012 15:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xtTCqSska0E for ; Tue, 11 Sep 2012 15:12:44 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 38DEF21F85A7 for ; Tue, 11 Sep 2012 15:12:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id A80A320E4106; Tue, 11 Sep 2012 18:12:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347401563; bh=A3uleVhaAmwSDzJw8Y9shRXuq7uHp9mk3gfs/XpInzg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=AvJdUyxolAlQ+sCv5JR5XxE6hSNk3GzwnO4m1tY8H/0nIrL87maQz5bVl3gAh8OJA dc3Ez1up0kQaAcg+M/RD2KWTvtugx2YI+7RcZJ0IIGSAnR+T74dsKt9iwL3HSxUq8N xSEP0A6ndzbZv4RyDoc53pcozGbltnzGhx6SXrMQ= Received: from scott-latitude-e6320.localnet (93.sub-70-192-198.myvzw.com [70.192.198.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 693CD20E4085; Tue, 11 Sep 2012 18:12:43 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 11 Sep 2012 18:12:41 -0400 Message-ID: <1899872.sSQ7Nx3y1k@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20120910231140.09679ce0@resistor.net> References: <504D1416.8040400@Commerco.Net> <20120910004749.44123.qmail@joyce.lan> <6.2.5.6.2.20120910231140.09679ce0@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 11 Sep 2012 22:12:45 -0000 On Tuesday, September 11, 2012 12:39:28 AM S Moonesamy wrote: > Hello, > > I haven't discussed this issue with Andrew yet. I don't see > agreement on Issue #33 ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02195.html > ). Murray Kucherawy suggested some text where it is argued that the > attack on SPF is outside the scope of the specification ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02661.html > ). I don't see agreement on the text which Murray proposed. During > the discussion, Barry Leiba raised an interesting point about a > sentence in Section 2.5.4 ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02708.html > ). I reopened Issue #29 based on that ( > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/29#comment:5 ). > > There has been a lot of discussion about rejecting or "marking" a > message based on a SPF result of "fail". Section 1 of RFC 4408 > mentions the following: > > "An additional benefit to mail receivers is that after the use of an > identity is verified, local policy decisions about the mail can be > made based on the sender's domain, rather than the host's IP address. > This is advantageous because reputation of domain names is likely to > be more accurate than reputation of host IP addresses. Furthermore, > if a claimed identity fails verification, local policy can take > stronger action against such E-Mail, such as rejecting it." > > Section 4.2 of RFC 4408 mentions that: > > "Based on the result, the action to be taken is determined by the > local policies of the receiver." > > I opened Issue #58 to find out whether there is agreement or not > about whether a message rejection or any other action following a SPF > evaluation is a matter of local policy. My opinion is that an action > based on the result of a SPF evaluation is up to the local policy of > the receiver. The receiver may take stronger action such as > rejecting a message. > > My recommendation is not to add any text about Issue #33 to the draft > unless there is strong agreement on the mailing list for the proposed > change. I also recommend reverting the following text in Section 2.3 > of draft-ietf-spfbis-4408bis-07: > > "SPF results can be used to make both positive (source is authorized) > and negative (source is not authorized) determinations. If domain > owners choose to publish SPF records and want to support receivers > making negative authorization determinations, then they MUST publish > records that end in "-all", or redirect to other records that do, > otherwise, no definitive determination of authorization can be made. > Potential issues and mitigations associated with negative > determinations are discussed in Section 9." > > to: > > "If domain owners choose to publish SPF records, it is RECOMMENDED > that they end in "-all", or redirect to other records that do, so > that a definitive determination of authorization can be made." > > and not including any change in Section 2.3 unless there is strong > agreement on the mailing list for the proposed change. > > I will close Issue #33 in the tracker unless there is an explanation > about whether the attack (see issue #33) is out of scope and what > countermeasures can be applied to defend against it. I suggest > basing the explanation on text which is in RFC 4408 only as it is my > understanding that existing SPF implementations use that specification. I don't understand why you want to revert the Section 2.3 changes? Those changes were not primarily made in response to issue #33. They were made because of comments that in RFC 4408 the specification RECOMMENDS something without a rationale for the recommendation. Given the lack of rationale, it's hard to know what might be an exceptional case for not following the recommendation. The change is also made because of operational experience gained since RFC 4408 was published. At the time RFC 4408 was published, it was envisioned that there would be a transition to a paradigm where most organizations published -all SPF records. This didn't happen. The revised text gives some guidance on the implications of not following the recommendation. Since it is common for large entities to ignore it, I think that is important. That's more true now than I would have envisioned when RFC 4408 was being developed. Scott K From john@jlc.net Tue Sep 11 16:08:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B5621F852C for ; Tue, 11 Sep 2012 16:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HOjLFWlfnec for ; Tue, 11 Sep 2012 16:08:22 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 20A1D21F852B for ; Tue, 11 Sep 2012 16:08:22 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id EBAE733C2C; Tue, 11 Sep 2012 19:08:21 -0400 (EDT) Date: Tue, 11 Sep 2012 19:08:21 -0400 From: John Leslie To: "Murray S. Kucherawy" Message-ID: <20120911230821.GN79075@verdi> References: <20120911152531.GJ79075@verdi> <20120911160820.55698.qmail@joyce.lan> <20120911163400.GK79075@verdi> <20120911180336.GM79075@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 23:08:23 -0000 Murray S. Kucherawy wrote: > On Tue, Sep 11, 2012 at 11:03 AM, John Leslie wrote: > >> Do you mean that SMTP receivers have better information (about what >> will be blowback), or that neither has any useful information? > > I mean the receiver is the one who gets to see by which paths mail > arrives. I'm not clear what that has to do with the perception of blowback. (Perception, alas, is as close as we can get to "reality".) > Consider that there are two sets of mail paths, namely > (a) those that the domain owner thinks it's using, and > (b) those by which mail actually arrives. We are pretty safe assuming that senders won't consider (a) blowback. ISTM that senders know better than receviers whether (b) is "blowback". > Those who claim the senders know better and should be able to assert > receiver policy appear to operate under the impression that (a) is > absolute or that the two sets are equal, when in reality we've seen > that (b) is nearly always a proper superset of (a). There seems to be a failure to communicate. :^( Clearly, the sender _cannot_ control what a receiver does with an email. It is most unfortunate that SPF was sold to some senders as a way to control what the receiver does. I hope that 4408bis will make the reality clear. But the sender _can_ control what it considers to be blowback. The sender _can_ apply disincentives to MTAs which send what it considers to be blowback. (Yes, I have been the victim of this.) > The place in the resulting Venn diagram where the two do not overlap > is false negative territory, and it's potentially very painful for > receivers. Indeed, receivers often find they must deliver email which has received an SPF hard-fail. I hope that 4408bis will make that clear. But if they're not going to deliver it, an SMTP-time reject is much more helpful than blowback (which often goes to a domain which had no role whatsoever in the email in question, and thus there is nothing useful for them to do about it). I am _only_ trying to suggest that in SPF hard-fail cases, the SMTP-time reject is far more appropriate than a later DSN. An SMTP-time reject is most likely to go to a sending MTA best able to deal with the problem (especially if that MTA is a forwarder). A later DSN would bypass the forwarder and reach someone unable to rectify the situation. Obviously, there will be cases where neither an SMTP-time reject nor a later DSN will happen. My claim is only that the sender has better information on whether a later DSN is better or worse than no error response as all. > I've yet to encounter a system anywhere in my career, from personal > machines to large corporate server clusters, where any of the policy > mechanisms coupled with message authentication schemes -- and that > includes SPF and ADSP -- are used in an absolute fashion. They do exist -- but this is not what I'm talking about. > So from where I sit, if there's no industry demand for universal > normative receiver policy after all these years, we should stop > trying to write one, let alone the fact that it's not a protocol's > business to do so. You're pretty darn far off-base if you think I want SPF to demand normative receiver policy... What I want is for SPF records to _mean_ something. It is not I that want SPF to be a blindly-applied algorithm. IMHO, no blindly-applied algorithm can be helpful to folks trying to find the best SPF policy to advertise. Further, any blindly-applied algorithm that doesn't give specific feedback on the result from the receiver running it to the "sender" advertising it cannot help educate those who advertise SPF records. (I expect to end up in-the-rough here -- that would be easier if someone gave me the impression they were considering what I actually say...) -- John Leslie From sm@elandsys.com Tue Sep 11 16:17:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65D821F8599 for ; Tue, 11 Sep 2012 16:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3AslYJbXZ+F for ; Tue, 11 Sep 2012 16:17:35 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6549521F858F for ; Tue, 11 Sep 2012 16:17:33 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.179]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8BNHJx3017508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Sep 2012 16:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347405452; bh=nNEzwM8eC/zIbMAxa25c+qHv1CbSBvplHXdN1aDh+1w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oCRKTwgfu6Mb4f2p/lf2gemrjynfSeW2thoTQz47HJfqcCRfbmoQF7xIaDoNBZw2d lKW2huQoHRi+tgVBDP1uOUfDInHdkMWXnac4h6j94onndMnSlwOS0fSHoMwGvAnEfy C0XhQCJMhjx7yrz4JvFMu8CS4Uo45n42jvR/C3Bw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347405452; i=@elandsys.com; bh=nNEzwM8eC/zIbMAxa25c+qHv1CbSBvplHXdN1aDh+1w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=sBfu0jvmlnxPVDjSlnHAWhT+UJI4p2vGJxwaxEYxRAETbIeEYKZx0Z5MbwkUnKRJH +Xo8C8+La8Q+qewUVw29rullap+ouYOeJLN5uBfXyFhbACLBuxl9RdAzwvu/HZBnUq 45JhYAX7CqbtZi1jYTvEWsBjuNMWj8XlWVhOSiUM= Message-Id: <6.2.5.6.2.20120911152657.09c43f90@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 11 Sep 2012 16:12:10 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <1899872.sSQ7Nx3y1k@scott-latitude-e6320> References: <504D1416.8040400@Commerco.Net> <20120910004749.44123.qmail@joyce.lan> <6.2.5.6.2.20120910231140.09679ce0@resistor.net> <1899872.sSQ7Nx3y1k@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 11 Sep 2012 23:17:35 -0000 Hi Scott, At 15:12 11-09-2012, Scott Kitterman wrote: >I don't understand why you want to revert the Section 2.3 changes? > >Those changes were not primarily made in response to issue #33. They were >made because of comments that in RFC 4408 the specification RECOMMENDS >something without a rationale for the recommendation. Given the lack of >rationale, it's hard to know what might be an exceptional case for not >following the recommendation. If there isn't a rationale for a (RFC 2119) RECOMMENDS, it is better not to replace that with a (RFC 2119) MUST unless the change has strong agreement. I don't see that in the mailing list discussions. Even though those changes were not made primarily in response to Issue #33, it has an impact on the issue ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02715.html ). That makes it very difficult to figure out a path forward to resolve issues. I'll open a new issue based on the message you posted about the change to Section 2.3. Regards, S. Moonesamy SPFBIS WG co-chair From W.Doust@racingvictoria.net.au Tue Sep 11 17:57:30 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30B821F84D1 for ; Tue, 11 Sep 2012 17:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.058 X-Spam-Level: X-Spam-Status: No, score=-1.058 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7SkYi2Oqth5 for ; Tue, 11 Sep 2012 17:57:30 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 10B4821F84CF for ; Tue, 11 Sep 2012 17:57:29 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v7, 1, 0, 4874) id ; Wed, 12 Sep 2012 10:57:27 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Sep 2012 10:57:08 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185203@XCHANGE.rvl.internal> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] Secetion 4.6.4 DNS Lookup Limits Thread-Index: Ac2QZrQ7Qd9NDPMiTlqHjdsB/fPySQAFgfvw From: "Wayne Doust" To: Subject: [spfbis] FW: Secetion 4.6.4 DNS Lookup Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 00:57:30 -0000 > My initial thought for the start of this message was to quote this section as well. Right to left parsing with errors only if the error condition is triggered is a recipe for what appears to be random failures when a record works some times and not others. > In any case prohibiting total record error detection and requiring left to right processing would be a substantiative change to the protocol. I don't think it would be a good one either. ------ Personally, I think the spec should mandate one way or the other. Otherwise we have a situation where the actual result will depend upon the implementation - leaving no consistency. A publisher can say their SPF record is okay because they tested it with a validator, but find it Permerrors (possibly leading to rejection) elsewhere according to the method implemented. At least one implementer checks the complete record first. Admittedly, this is usually (but not always) related to a mistake in the spf record. Despite this, a consistent result should be returned across the board. For a classic example of this, look at the spf record for Hilton.com. This record contains two "-all" entries. Scanning sequentially through the record will always work as processing stops at the first "-all", however pre-scanning will always result in a permerror. I'm actually not committed to either method, however I think it should be consistent. Testing Hilton.com against SK's validator will pass the record whilst some in-the-wild implementations do not. Regards, Wayne From superuser@gmail.com Tue Sep 11 18:03:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C9721F852B for ; Tue, 11 Sep 2012 18:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYH8x19r81yJ for ; Tue, 11 Sep 2012 18:03:16 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE67421F8527 for ; Tue, 11 Sep 2012 18:03:15 -0700 (PDT) Received: by lahm15 with SMTP id m15so792270lah.31 for ; Tue, 11 Sep 2012 18:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=03I/qCZ1gaMiqf4LDey666ezFl72YQKv9bkVHBO+3cY=; b=S/KqJGWBUOWc9lM46fJapvb/Tf1MOer+6YNHmc1S3eGcanDA5EMhrUgQy1YMHyTqHv hJw6MEszTbg2pUCQ9LILJkWeLsT9K5REOnjv6hfgEZSBlnyPeWD/30y6lMceSHcZom/B 6B8682YtdV07aE4m2Qhibuyvqz/oBR+K7I0ayJZi7E2Cybhgj1TkX0JkZUvlp/wnuAXu fkcbNHcnIrGE8wOd5NYyY/EH+d8PGhLxw2KZXMxNDFOwOWDuVNzxCC9Rn0lMc7FUIRxI n6HXhNILyrxz5tKBJoVrU+Y66BdO3cbA+QaEbbu/xuDF/cQ3lrQvu8ekbwuXVGQXhMfE 9foQ== MIME-Version: 1.0 Received: by 10.112.31.233 with SMTP id d9mr6847937lbi.116.1347411794638; Tue, 11 Sep 2012 18:03:14 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Tue, 11 Sep 2012 18:03:14 -0700 (PDT) In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185203@XCHANGE.rvl.internal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185203@XCHANGE.rvl.internal> Date: Tue, 11 Sep 2012 18:03:14 -0700 Message-ID: From: "Murray S. Kucherawy" To: Wayne Doust Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] FW: Secetion 4.6.4 DNS Lookup Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 01:03:16 -0000 On Tue, Sep 11, 2012 at 5:57 PM, Wayne Doust wrote: > Admittedly, this is usually (but not always) related to a mistake in the > spf record. Despite this, a consistent result should be returned across > the board. For a classic example of this, look at the spf record for > Hilton.com. This record contains two "-all" entries. Scanning > sequentially through the record will always work as processing stops at > the first "-all", however pre-scanning will always result in a > permerror. Why is a double "-all" a permerror? There's nothing in RFC4408 that forbids it. It's like putting "exit" in a shell script or "return" in a C function before you reach the end; there's nothing syntactically wrong with it, but it renders part of the whole thing dead. Settling on "to pre-scan or not to pre-scan" won't solve this problem. It's a bad implementation. -MSK From johnl@iecc.com Tue Sep 11 18:10:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29B621F85A2 for ; Tue, 11 Sep 2012 18:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWyDt3xOI5Fg for ; Tue, 11 Sep 2012 18:10:48 -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 E745121F85A1 for ; Tue, 11 Sep 2012 18:10:47 -0700 (PDT) Received: (qmail 73230 invoked from network); 12 Sep 2012 01:10:46 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Sep 2012 01:10:46 -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:vbr-info; s=504fe116.xn--9vv.k1208; i=johnl@user.iecc.com; bh=TVtV0sbZjNJfw3B0/7dxG+Zi6lX70qpa9s2pAGNLE+M=; b=j3rrTHeHLpltrAzvv2Y9YPJ52Cam0syod9Tn8/5xOaXJVx/FPa01BX8uCRJQx7Bpy3IOuyYxYKiw6dqQB/nIkRfhbkQA+LglsPDQLsJUlnmNMIm2RM337Kug2RiK9UsJcF8DIA5B2ZBZWAexL1oJxuL0I9gmAw5FDhM98La8eZ4= 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:vbr-info; s=504fe116.xn--9vv.k1208; olt=johnl@user.iecc.com; bh=TVtV0sbZjNJfw3B0/7dxG+Zi6lX70qpa9s2pAGNLE+M=; b=jdf7/c46pOYsbLbzM105cndW3MKLFYLXn7pW6DppJG1maT6Qb1Ogh45ZtJ26mohKD6ppAK3JViELtGsokVOwh0xzcpgj1DOkyGENMgFJQMwgKJdf7SEf0QNPBWoRZTUM2MeYvhHbKt/1C/OsedwWFX2Psyjd/gE55MbFHaT2tMU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 12 Sep 2012 01:10:24 -0000 Message-ID: <20120912011024.20846.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <17975455.mDjxCEe1hM@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: spf2@kitterman.com Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 01:10:49 -0000 >Part of the purported benefit of SPF is that it allows you to take actions >based on a name based identifier for SPF pass. I think the flip side of that, >that one shouldn't do so for non-SPF pass is equally reasonable. No, they're not at all symmetrical. If SPF passes, you can be reasonably confident that the message was sent by the domain that passed. If it fails, you don't know whether the message is bogus, or it's a real message that arrived via a path that SPF can't describe. Murray probably has his fingerprints on more mail than all of the rest of us put together, so I would take his comments to heart. Large mail systems don't treat SPF fail as anything more than optional advice. No matter what we put in 4408bis, that will still be true, and I don't see any point in writing a standard that we know people won't implement. R's, John From spf2@kitterman.com Tue Sep 11 19:40:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA3221E8043 for ; Tue, 11 Sep 2012 19:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYBoOuMhmwsC for ; Tue, 11 Sep 2012 19:40:21 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 55D7321E8042 for ; Tue, 11 Sep 2012 19:40:21 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6B76D20E411E; Tue, 11 Sep 2012 22:40:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347417620; bh=0q5TD1QXTBZxeYHSbe/1CeU6p/YLV/xi2UD0lan9mGs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=I9epeX5FzzOusDlqq0gnpuA0oRuIc4Mfi12Xk1GTM7/uTGwDbkneBb5Rg0qeCq5By R0bupshNoPHb89rcy1UtmR1JbMH+pBNnwF8TIGaRnx0xMK1FsX/mlZtyqeibX2GcHF ch0UpbRdacGENDN9qVspaYoL6DFeSpmhPMt7jKUE= 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 352FB20E4106; Tue, 11 Sep 2012 22:40:19 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 11 Sep 2012 22:40:19 -0400 Message-ID: <1469933.kpSdRM44Gj@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <20120912011024.20846.qmail@joyce.lan> References: <20120912011024.20846.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 02:40:22 -0000 On Wednesday, September 12, 2012 01:10:24 AM John Levine wrote: > >Part of the purported benefit of SPF is that it allows you to take actions > >based on a name based identifier for SPF pass. I think the flip side of > >that, that one shouldn't do so for non-SPF pass is equally reasonable. > > No, they're not at all symmetrical. If SPF passes, you can be > reasonably confident that the message was sent by the domain that > passed. If it fails, you don't know whether the message is bogus, or > it's a real message that arrived via a path that SPF can't describe. > > Murray probably has his fingerprints on more mail than all of the rest > of us put together, so I would take his comments to heart. Large mail > systems don't treat SPF fail as anything more than optional advice. > No matter what we put in 4408bis, that will still be true, and I don't > see any point in writing a standard that we know people won't > implement. I'm fine with not saying MUST NOT for that reason. OTOH, SHOULD NOT stamps it a generally a bad idea (which I think is reasonable), but says go ahead if you think you know better. I believe that's consistent with what you say you want. While there are no RFC police, I have, on more than one occasion told people where had implemented $BAD_IDEA to get read some section of some RFC to learn about why it was a bad idea and they've taken it to heart. Scott K From spf2@kitterman.com Tue Sep 11 19:44:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D8921E8037 for ; Tue, 11 Sep 2012 19:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSSUQ9b0TjSz for ; Tue, 11 Sep 2012 19:44:21 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1232521F8491 for ; Tue, 11 Sep 2012 19:44:21 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9099520E411E; Tue, 11 Sep 2012 22:44:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347417859; bh=QvpiKCPfooLflVPD+QclfVYG3OKTZOwtmO6+2MrWoes=; h=From:To:Subject:Date:In-Reply-To:References:From; b=T/ZlOFFt6QIVL4trYqtaQJQAa+pQ+9r8/u3bFk0WQxGRKJ634F13comqxP9GwEi2X g/+f7dA6on5PMIdl1/I6Rq+I1AZXWHwUmZLAoCRgSUnjbRXhuvGlU9qfdgU7de2CA6 kWLReHGh6e3FebTlkeJLED3/N2IOlv/B8zjUYrgs= 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 6130A20E4106; Tue, 11 Sep 2012 22:44:19 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 11 Sep 2012 22:44:18 -0400 Message-ID: <3256899.EWU23EEGvy@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185203@XCHANGE.rvl.internal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185203@XCHANGE.rvl.internal> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] FW: Secetion 4.6.4 DNS Lookup Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 02:44:21 -0000 On Wednesday, September 12, 2012 10:57:08 AM Wayne Doust wrote: ... > Personally, I think the spec should mandate one way or the other. > Otherwise we have a situation where the actual result will depend upon > the implementation - leaving no consistency. A publisher can say their > SPF record is okay because they tested it with a validator, but find it > Permerrors (possibly leading to rejection) elsewhere according to the > method implemented. At least one implementer checks the complete record > first. ... You're solving the wrong problem here. Since RFC 4408 says that no matter how you do it, errors must be detected in all cases, you have consistency. The problem is that virtually no SPF record validators include processing limits in what they validate. Mine does, but the reason I set it up in 2006 was because none of the ones that existed at the time did. I don't have any firm recollection of any appearing either (but I may be wrong as it's not something I pay a lot of attention to). The problem is incomplete validation caused by validators that don't check all aspects of validity. Fixing the spec, won't fix that. Scott K From spf2@kitterman.com Tue Sep 11 19:48:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5D021F84C4 for ; Tue, 11 Sep 2012 19:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zb8D7iy8og5U for ; Tue, 11 Sep 2012 19:48:45 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C914A21F8493 for ; Tue, 11 Sep 2012 19:48:45 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4755420E411E; Tue, 11 Sep 2012 22:48:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347418125; bh=gqoOmh8JW37hacIZNdyRkb7E7ePSmiQiqqX2laJ/2IE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bFzSAGmgP8GscE1YHm3Ckj9oTZ5tlG5u7mvtamtgUVEQ/j4YMJBmqgI3I2Q/0Ase0 h5+rS46NVlzX/3NT+9RoDpKY+F2YriyBxl0qgat3kS9e44sdL+va4FvrpEf1NfVDGV vwNFQqcmUYZ0Rbfb07o3lXrWEan/JtPIeccW1J/g= 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 17DD420E4106; Tue, 11 Sep 2012 22:48:44 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 11 Sep 2012 22:48:44 -0400 Message-ID: <4328756.kpDc5cV0um@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: References: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185203@XCHANGE.rvl.internal> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] FW: Secetion 4.6.4 DNS Lookup Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 02:48:46 -0000 On Tuesday, September 11, 2012 06:03:14 PM Murray S. Kucherawy wrote: > On Tue, Sep 11, 2012 at 5:57 PM, Wayne Doust > > wrote: > > Admittedly, this is usually (but not always) related to a mistake in the > > spf record. Despite this, a consistent result should be returned across > > the board. For a classic example of this, look at the spf record for > > Hilton.com. This record contains two "-all" entries. Scanning > > sequentially through the record will always work as processing stops at > > the first "-all", however pre-scanning will always result in a > > permerror. > > Why is a double "-all" a permerror? There's nothing in RFC4408 that > forbids it. It's like putting "exit" in a shell script or "return" in > a C function before you reach the end; there's nothing syntactically > wrong with it, but it renders part of the whole thing dead. > > Settling on "to pre-scan or not to pre-scan" won't solve this problem. > It's a bad implementation. There are lots of ways to write dumb records that are syntactically valid. One common one is to use the MX mechanism and then put the hostname of the MX host when what's wanted is either A and the hostname of the MX host or MX and the domain that the record is for. We can't design a spec that precludes syntactically valid, but operationally incorrect records. Tools to support SPF record validation however, can, and should, provide useful advice when they encounter something that is clearly not useful (mine gives a warning on the empty MX lookup problem I described above, but not double ALL (I confess to having never seen that one before)). Scott K From spf2@kitterman.com Tue Sep 11 19:56:25 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E4221E804B for ; Tue, 11 Sep 2012 19:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVhF76IvbM7E for ; Tue, 11 Sep 2012 19:56:24 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 238AC21F851B for ; Tue, 11 Sep 2012 19:56:24 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9959520E411E; Tue, 11 Sep 2012 22:56:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347418583; bh=9OdgvmR6JHqR+HcjEsTzuw3ny/gDD8XBsRrKqypZGp8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cQ/Qtk+53zHf63LB5njr8L0UNUbEYJaSSyR9wwPpP3/lBaiqMrxs/njCDKvPVKiK4 CtHXSPbZ2FrMcBZzzwXcaBEg7nJ48vXQ4MB3XBkDWZM0z1YrSTLfLg8wzicLNc43La OmFxmT/eDbDvy8gJpHWQgSJqXWswe1dFIrDvLyug= 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 7377E20E4106; Tue, 11 Sep 2012 22:56:23 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 11 Sep 2012 22:56:22 -0400 Message-ID: <1546504.1r6gpORNoX@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20120911152657.09c43f90@resistor.net> References: <504D1416.8040400@Commerco.Net> <1899872.sSQ7Nx3y1k@scott-latitude-e6320> <6.2.5.6.2.20120911152657.09c43f90@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 02:56:25 -0000 On Tuesday, September 11, 2012 04:12:10 PM S Moonesamy wrote: > Hi Scott, > > At 15:12 11-09-2012, Scott Kitterman wrote: > >I don't understand why you want to revert the Section 2.3 changes? > > > >Those changes were not primarily made in response to issue #33. They were > >made because of comments that in RFC 4408 the specification RECOMMENDS > >something without a rationale for the recommendation. Given the lack of > >rationale, it's hard to know what might be an exceptional case for not > >following the recommendation. > > If there isn't a rationale for a (RFC 2119) RECOMMENDS, it is better > not to replace that with a (RFC 2119) MUST unless the change has > strong agreement. I don't see that in the mailing list discussions. > > Even though those changes were not made primarily in response to > Issue #33, it has an impact on the issue ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02715.html > ). That makes it very difficult to figure out a path forward to > resolve issues. > > I'll open a new issue based on the message you posted about the > change to Section 2.3. I think it's unrelated. This is a change in description, not an increase in requirements. RFC 4408 says a -all records are RECOMMENDED 4408bis currently says if senders ... "want to support receivers making negative authorization determinations, then they MUST publish records that end in -all". The statement in 4408bis has always been true even if it was not explicitly stated that way. 4408 assumed that senders would generally want to support "making negative authorization determination" and based on that assumed general goal made a general recommendation. In the intervening time we've learned that there are quite a few senders that aren't particularly worried about this and so now I've proposed it say "If you want X then you MUST Y" instead of "Y is RECOMMENDED". There is no new requirement here and the proposed language better fits the current operational environment than reverting to what was in RFC 4408. Scott K From W.Doust@racingvictoria.net.au Tue Sep 11 20:34:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47D721E804B for ; Tue, 11 Sep 2012 20:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.337 X-Spam-Level: X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLL5iPh-PN36 for ; Tue, 11 Sep 2012 20:34:37 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 2329621E8048 for ; Tue, 11 Sep 2012 20:34:36 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v7, 1, 0, 4874) id ; Wed, 12 Sep 2012 13:34:35 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Sep 2012 13:34:12 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185225@XCHANGE.rvl.internal> In-Reply-To: <3256899.EWU23EEGvy@scott-latitude-e6320> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] FW: Secetion 4.6.4 DNS Lookup Limits Thread-Index: Ac2QkIZDxgk/Na3aQ+qJ6kE9P4Ls/QAAIYhg References: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185203@XCHANGE.rvl.internal> <3256899.EWU23EEGvy@scott-latitude-e6320> From: "Wayne Doust" To: "Scott Kitterman" , Subject: Re: [spfbis] FW: Secetion 4.6.4 DNS Lookup Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 03:34:37 -0000 > You're solving the wrong problem here. Since RFC 4408 says that no matter how you do it, errors must be detected in all cases, you have consistency. I think it is ambiguous. In-the-wild implementations seem to support that notion. Should the entire record be scanned first or not? My personal opinion is that it shouldn't. I'm more concerned that the spec should mandate the circumstances under which permerror results are generated. In the case of "v=3Dspf1 a mx include:example.com -all". If I publish = this record because occasionally an example is sent from example.com with my MAIL FROM: domain. And example.com decides to go from 8 to 10 DNS lookups after publication of the SPF record, will I permerror on every single email? Or only on the those from example.com (or those that should be trapped by -all)? Evaluating from L to R will give a pass for most email. Pre-evaluating will report permerror. > The problem is incomplete validation caused by validators that don't check all aspects of validity. Fixing the spec, won't fix that. Very True. However, consistency in response is what I'm talking about. Regards, Wayne From sm@elandsys.com Tue Sep 11 20:48:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C0C21E804C for ; Tue, 11 Sep 2012 20:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXVDaghgC0Ir for ; Tue, 11 Sep 2012 20:48:15 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E202221E8048 for ; Tue, 11 Sep 2012 20:48:15 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.236.143]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8C3lqc2018761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Sep 2012 20:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347421694; bh=Fb7LM6qcECQ98hQmuvl/wR9qQxQn80UceuwdB5HbjNk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=FypL1kAbZj6IqIlKMUtyIUOBZxHQ/ufSwNIh2BeVCUkvxO3ES9fX1/CtaWSzx+ph1 eJ8M6H3CmWfh2TAkr6wuVJILjHB3X9Mh+LerJdKFtZZC+61T6Bzve0E+patreJMAyW LJ76nC/JGdB4RPyET4KBHWhCwPO41k+uRKFiQ094= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347421694; i=@elandsys.com; bh=Fb7LM6qcECQ98hQmuvl/wR9qQxQn80UceuwdB5HbjNk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rPmCh6IUzN5pjNLXigsx53RJlP/rCHK+istaQdh/ptDetx6u4YBynBvaTSl9dC8N4 4TfJV7xoVb0Y3eL2hlp4U8mGEcdrvmAsOJlHwblhgkx1ybpXV17+C3COP1l9ZWTqk8 PLQJi5Kp4Xus53PUEgeReqmyQbvZv1/64LiW3Ah4= Message-Id: <6.2.5.6.2.20120911203351.09453fe0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 11 Sep 2012 20:45:55 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <1546504.1r6gpORNoX@scott-latitude-e6320> References: <504D1416.8040400@Commerco.Net> <1899872.sSQ7Nx3y1k@scott-latitude-e6320> <6.2.5.6.2.20120911152657.09c43f90@resistor.net> <1546504.1r6gpORNoX@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 03:48:17 -0000 Hi Scott, At 19:56 11-09-2012, Scott Kitterman wrote: >I think it's unrelated. The change you proposed is being tracked as Issue #60. >This is a change in description, not an increase in requirements. > >RFC 4408 says a -all records are RECOMMENDED > >4408bis currently says if senders ... "want to support receivers making >negative authorization determinations, then they MUST publish >records that end >in -all". > >The statement in 4408bis has always been true even if it was not explicitly >stated that way. > >4408 assumed that senders would generally want to support "making negative >authorization determination" and based on that assumed general goal made a >general recommendation. In the intervening time we've learned that there are >quite a few senders that aren't particularly worried about this and so now >I've proposed it say "If you want X then you MUST Y" instead of "Y is >RECOMMENDED". > >There is no new requirement here and the proposed language better fits the >current operational environment than reverting to what was in RFC 4408. From RFC 2119: 'MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.' My reading of that RFC is that "MUST" and "RECOMMENDED" are not the same. I do not see strong agreement for the text change. Regards, S. Moonesamy SPFBIS WG co-chair From ajs@anvilwalrusden.com Tue Sep 11 21:00:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CC521F859C for ; Tue, 11 Sep 2012 21:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efbJmWdklsBj for ; Tue, 11 Sep 2012 21:00:26 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id EF12021F8540 for ; Tue, 11 Sep 2012 21:00:25 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id F1BBB8A031 for ; Wed, 12 Sep 2012 04:00:23 +0000 (UTC) Date: Wed, 12 Sep 2012 00:00:21 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120912040021.GQ86424@mx1.yitter.info> References: <504D1416.8040400@Commerco.Net> <1899872.sSQ7Nx3y1k@scott-latitude-e6320> <6.2.5.6.2.20120911152657.09c43f90@resistor.net> <1546504.1r6gpORNoX@scott-latitude-e6320> <6.2.5.6.2.20120911203351.09453fe0@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20120911203351.09453fe0@resistor.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 04:00:26 -0000 No hat. On Tue, Sep 11, 2012 at 08:45:55PM -0700, S Moonesamy wrote: > [Scott said]: > > > >RFC 4408 says a -all records are RECOMMENDED > > > >4408bis currently says if senders ... "want to support receivers making > >negative authorization determinations, then they MUST publish > >records that end > >in -all". > > My reading of that RFC is that "MUST" and "RECOMMENDED" are not the > same. I do not see strong agreement for the text change. It seems that these two mails talk past each other. Scott's point, as I read him, is that the 4408 text just says "you probably want to use these records", and the new proposed text says "if you want to achieve something, then you MUST do some other thing". Now, there are two questions here, both relevant to the WG. First, is this really a clarification? That is, does the new proposed text expans on or otherwise clarify what the old text said implicitly, as Scott argues it does? Second, is the new text both true and a correct use of the RFC 2119 keyword? It seems to me that in the new proposed text, it isn't a 2119 MUST at all. It's really just stating an entailment. It could be as correctly phrased as "if senders ... 'want to support receivers making negative authorization determinations, it is necessary for them to publish records that end in -all'". If I understand correctly, this is a fact about how the protocol works, and not actually a normative requirement for interoperation. What have I missed? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Tue Sep 11 21:53:37 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336A421F865E for ; Tue, 11 Sep 2012 21:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBeZ2S1MKayU for ; Tue, 11 Sep 2012 21:53:36 -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 359CA21F865C for ; Tue, 11 Sep 2012 21:53:35 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.159]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8C4rKRV019046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Sep 2012 21:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347425614; bh=pTCtq7QeUkqUbm8Eu0I76oyQdMO/OnicqNitTWN1dzU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=crJ+rA/WeLy89LP8qUrlIjDnUk2sRz8g3b5MzId/6xloxgISKgnl/2Q6U4tImt6Gz qhiZhFWNzVRCcqhY21mx4e3/E4Honil7ucl/AxI3veSFwDzMwYIcsTCQ8LGdcXw2Qe fpZXUb6aEQv+zk0DbBWmmNWSQycXnehauF2JqEcA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347425614; i=@elandsys.com; bh=pTCtq7QeUkqUbm8Eu0I76oyQdMO/OnicqNitTWN1dzU=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=T7M/IscuOSebKxujbAgITMYrpIoovQ8gVygOGQGAscNeJw462IIRa/YTCXO5rJkjE G96FrmlgRyBpU1JH361oRVjQ+QTkQrYe/a6lQJo9FBmrsKDKIGyBWx57Tpo0iVVy9h JKPHENuehveU9U0jCfMzXISHVXqWw0R7rgyyLKRU= Message-Id: <6.2.5.6.2.20120911214905.09388488@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 11 Sep 2012 21:53:06 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <064.8a6275919aba4fa5f4f9c983ff6041f6@tools.ietf.org> References: <064.8a6275919aba4fa5f4f9c983ff6041f6@tools.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #60: Section 2.3 - Publishing Authorization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 04:53:37 -0000 At 16:16 11-09-2012, spfbis issue tracker wrote: >#60: Section 2.3 - Publishing Authorization > > Message posted by Scott Kitterman on 11 Sept 2012: > > I don't understand why you want to revert the Section 2.3 changes? > > Those changes were not primarily made in response to issue #33. They were > made because of comments that in RFC 4408 the specification RECOMMENDS > something without a rationale for the recommendation. Given the lack of > rationale, it's hard to know what might be an exceptional case for not > following the recommendation. > > The change is also made because of operational experience gained since RFC > 4408 was published. At the time RFC 4408 was published, it was envisioned > that there would be a transition to a paradigm where most organizations > published -all SPF records. This didn't happen. The revised text gives > some guidance on the implications of not following the recommendation. > Since it is > common for large entities to ignore it, I think that is important. That's > more true now than I would have envisioned when RFC 4408 was being > developed. > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02772.html I am including the message from Andrew Sullivan below. At 21:00 11-09-2012, Andrew Sullivan wrote: >It seems that these two mails talk past each other. Scott's point, as >I read him, is that the 4408 text just says "you probably want to use >these records", and the new proposed text says "if you want to achieve >something, then you MUST do some other thing". Here's a pointer to the message from Scott Kitterman http://www.ietf.org/mail-archive/web/spfbis/current/msg02781.html >Now, there are two questions here, both relevant to the WG. > >First, is this really a clarification? That is, does the new proposed >text expans on or otherwise clarify what the old text said implicitly, >as Scott argues it does? > >Second, is the new text both true and a correct use of the RFC 2119 >keyword? It seems to me that in the new proposed text, it isn't a >2119 MUST at all. It's really just stating an entailment. It could >be as correctly phrased as "if senders ... 'want to support receivers >making negative authorization determinations, it is necessary for them >to publish records that end in -all'". If I understand correctly, >this is a fact about how the protocol works, and not actually a >normative requirement for interoperation. What have I missed? Regards, S. Moonesamy From sm@resistor.net Tue Sep 11 22:27:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405A921F84EA for ; Tue, 11 Sep 2012 22:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBxFakHf8si9 for ; Tue, 11 Sep 2012 22:27:07 -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 4C7F821F84E6 for ; Tue, 11 Sep 2012 22:27:07 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8C5QxiY026590; Tue, 11 Sep 2012 22:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347427626; bh=PPHhBnREooDEf36Dfcic6fPlMBUlg09/h6nxLB90riw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=b9/lNJZqiYMFcQChjt9Sg4fkQbla3zZ7g4ENBkUsT3LKQOOON8r4NmaBsrG9qgWJF 8RpmZ3hLEcTOrUQsHXZ9SbVRRpMP9kTpzCfVj5o9RT0QuPwL7eTU9SrU+AI+vi4oTv Q+jBlTUCasVTSv4yQOHrSRPiXe/QJq3TibW/xaDU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1347427626; i=@resistor.net; bh=PPHhBnREooDEf36Dfcic6fPlMBUlg09/h6nxLB90riw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tkB2C3zhSKYppDa+3YY2xFIG3fHCNqckR5hQDJ1W/GP85i0c5HcqFPmtxvsxK3x/o 4Hp+D24hxce0/YTDvmwOY8aGz6YrwI7BDhJ+1lUrovBojAPYniGLuah4GUrcwDfBoM teb4D8NnhNWPdhZba3Futsxtdfxb7V+9nly3saxU= Message-Id: <6.2.5.6.2.20120911220609.0928b910@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 11 Sep 2012 22:26:54 -0700 To: Wayne Doust From: SM In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185225@XCHANGE.rvl.inter nal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185203@XCHANGE.rvl.internal> <3256899.EWU23EEGvy@scott-latitude-e6320> <0D2A0D5F64179F4F9556D3DEDE39F9AF01185225@XCHANGE.rvl.internal> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] FW: Secetion 4.6.4 DNS Lookup Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 05:27:08 -0000 At 20:34 11-09-2012, Wayne Doust wrote: >Evaluating from L to R will give a pass for most email. Pre-evaluating >will report permerror. From Section 4.6.2 of RFC 4408: "Each mechanism is considered in turn from left to right. If there are no more mechanisms, the result is specified in Section 4.7." From Section 5.1: 'The "all" mechanism is a test that always matches. It is used as the rightmost mechanism in a record to provide an explicit default. For example: v=spf1 a mx -all Mechanisms after "all" will never be tested. Any "redirect" modifier (Section 6.1) has no effect when there is an "all" mechanism.' The SPF record for hilton.com is below: "v=spf1 include:imx.hilton.com a:ctg1.hilton.com a:ctg2.hilton.com a:ctg3.hilton.com a:ctg4.hilton.com a:ctg5.hilton.com a:ctg6.hilton.com include:spf.messagelabs.com -all" " mx:hiltonint.com ip4:62.95.91.206 ip4:62.95.91.207 a:mail.hiltonres.com a:mail2.hiltonres.com ip4:192.251.124.90 -all" The syntax seems correct. Regards, -sm From W.Doust@racingvictoria.net.au Tue Sep 11 22:39:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60B721F8540 for ; Tue, 11 Sep 2012 22:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWqu+mSVK+96 for ; Tue, 11 Sep 2012 22:39:47 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id ECAF221F853F for ; Tue, 11 Sep 2012 22:39:46 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v7, 1, 0, 4874) id ; Wed, 12 Sep 2012 15:39:38 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Sep 2012 15:38:52 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185240@XCHANGE.rvl.internal> In-Reply-To: <6.2.5.6.2.20120911220609.0928b910@resistor.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] FW: Secetion 4.6.4 DNS Lookup Limits Thread-Index: Ac2Qp0MwagsQrW23TIqyPkX9eNvLQwAAL1VQ References: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185203@XCHANGE.rvl.internal> <3256899.EWU23EEGvy@scott-latitude-e6320> <0D2A0D5F64179F4F9556D3DEDE39F9AF01185225@XCHANGE.rvl.internal> <6.2.5.6.2.20120911220609.0928b910@resistor.net> From: "Wayne Doust" To: "SM" Cc: spfbis@ietf.org Subject: Re: [spfbis] FW: Secetion 4.6.4 DNS Lookup Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 05:39:48 -0000 "v=3Dspf1 include:imx.hilton.com a:ctg1.hilton.com a:ctg2.hilton.com a:ctg3.hilton.com a:ctg4.hilton.com a:ctg5.hilton.com a:ctg6.hilton.com include:spf.messagelabs.com -all" "=20 mx:hiltonint.com ip4:62.95.91.206 ip4:62.95.91.207 a:mail.hiltonres.com a:mail2.hiltonres.com ip4:192.251.124.90 -all" > The syntax seems correct. The syntax is correct. Evaluating from L-R will always terminate in the first "-all", so the record will always be valid. Pre-evaluating however, will exceed the DNS lookup limit: include:imx.hilton.com 1 a:ctg1.hilton.com 1 / 2 a:ctg2.hilton.com 1 / 3 a:ctg3.hilton.com 1 / 4 a:ctg4.hilton.com 1 / 5 a:ctg5.hilton.com 1 / 6 a:ctg6.hilton.com 1 / 7 include:spf.messagelabs.com 2 / 9 -all 0 mx:hiltonint.com 1 / 10 ip4:62.95.91.206 0 ip4:62.95.91.207 0 a:mail.hiltonres.com 1 / 11 - permerror a:mail2.hiltonres.com 1 ip4:192.251.124.90 0 -all 0 From superuser@gmail.com Tue Sep 11 22:55:06 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE9A21F8628 for ; Tue, 11 Sep 2012 22:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UnfG9K7kajF for ; Tue, 11 Sep 2012 22:55:04 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E92021F8646 for ; Tue, 11 Sep 2012 22:54:57 -0700 (PDT) Received: by lbky2 with SMTP id y2so963227lbk.31 for ; Tue, 11 Sep 2012 22:54:46 -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=YnJvsRMhJU58a+11YDAyK8T4gVlQHB496Ol1xNut3yM=; b=QrWpJ508fOq0djCtCXgdy5cLA+tB44sy53/zXfXIR6S5NhIVGXtfvv4DPtUN/JEGZM 2WrbcwWkocfUGyVMdhv17iv4ZVn6dk0RDGjEJYp1zxKDdgX5IAlPzCLI675qpgLklxZf KecrJur9saiM0+fUw3SpTb8iHx0l0FsphquuGDNJT3XXLAUYTDraOxRAX+UYeqNuywnY 0L7aQbAe5hJo1V7IlZJhP0JM2nhduB+xxBB68tJlP73uO40vtrDKS4HqzQ31hgURf5b+ z+iA7DS2QaV2cgQlqERNWXPZ/jB7v/J1WM5wgT8iUYm5t/UntjVp+bEoTCGobpkaj2Le 9eQw== MIME-Version: 1.0 Received: by 10.112.88.73 with SMTP id be9mr7027916lbb.72.1347429286483; Tue, 11 Sep 2012 22:54:46 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Tue, 11 Sep 2012 22:54:46 -0700 (PDT) In-Reply-To: <1469933.kpSdRM44Gj@scott-latitude-e6320> References: <20120912011024.20846.qmail@joyce.lan> <1469933.kpSdRM44Gj@scott-latitude-e6320> Date: Tue, 11 Sep 2012 22:54:46 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 05:55:06 -0000 On Tue, Sep 11, 2012 at 7:40 PM, Scott Kitterman wrote: > I'm fine with not saying MUST NOT for that reason. OTOH, SHOULD NOT stamps it > a generally a bad idea (which I think is reasonable), but says go ahead if you > think you know better. I believe that's consistent with what you say you > want. The debate, then, is about whether RFC2119 language can be used to describe an operational practice (in this case, local policy) that isn't part of the protocol proper. I believe the answer is "no". Perhaps one of the co-chairs or an AD should weigh in on that point. To be specific: The protocol itself works if the receiver generates the result that the sender's published policy intended to provide. The normative terms are available to be used such that implementers will write something that works properly. That's interoperability. What the receiver does with the message afterwards doesn't change the fact that check_host() did precisely what it was supposed to do. The protocol, at that point, is done. No MUSTard we put on what happens after that has anything at all to do with interoperability of the protocol itself, and thus I'd say is inappropriate for a protocol document (but not necessarily for an applicability statement, which this is not). Now, that's all true if we agree that SPF is a protocol between the sending ADMD and the receiving MTA. Since there are people who want this MUSTard there, they must have something else in mind. Hector, I believe, claimed that SPF is more of a protocol between the sending ADMD and the MUA. I don't think that's right because the output of check_host() is not used anywhere as a signal to the MUA, since MUAs can't reject messages; the best they could do is apply an annotation (another kind of "mark") or simply decline to show the message. But we -- correctly, I believe -- shy away from making assertions about what MUAs should do. So what's left? At best, one could claim it's a protocol between the sending ADMD and the LDA. I don't think LDAs typically do rejection or "marking", though, and even if they did, the rejection would need to be in lockstep with SMTP, otherwise there's backscatter. So I don't really know what to do with this line of thinking. -MSK From W.Doust@racingvictoria.net.au Tue Sep 11 23:02:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5ECF21E8064 for ; Tue, 11 Sep 2012 23:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yYVo0+zq4H7 for ; Tue, 11 Sep 2012 23:02:03 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0355A21E8063 for ; Tue, 11 Sep 2012 23:02:02 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v7, 1, 0, 4874) id ; Wed, 12 Sep 2012 16:02:01 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Sep 2012 16:01:00 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF0118524A@XCHANGE.rvl.internal> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] FW: Secetion 4.6.4 DNS Lookup Limits Thread-Index: Ac2QqH6xCjceALKUTBKnnJ3W81bKJQAAlVkg References: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185203@XCHANGE.rvl.internal><0D2A0D5F64179F4F9556D3DEDE39F9AF0118522F@XCHANGE.rvl.internal> From: "Wayne Doust" To: "Murray S. Kucherawy" , Subject: Re: [spfbis] FW: Secetion 4.6.4 DNS Lookup Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 06:02:03 -0000 > Off the top of my head I don't see anything syntactically wrong with the third and fifth ones. They should get processed and then fail of their own accord. Third one has whitespace where it shouldn't be. You're right about the 5th one. I'll have to look closer at why it threw a permerror. Back on topic: The point of the proposed text is to make it clear to implementers that whilst pre-processing for syntax errors may be valid, pre-processing for DNS lookups is definitely not valid.=20 Agree / Disagree ? The example I have given is a real (if bizarre) one. However this could more commonly occur with include: statements. Regards, Wayne From superuser@gmail.com Tue Sep 11 23:06:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B59421E8063 for ; Tue, 11 Sep 2012 23:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+shJLA9emaj for ; Tue, 11 Sep 2012 23:06:04 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B84821E8056 for ; Tue, 11 Sep 2012 23:06:04 -0700 (PDT) Received: by lbky2 with SMTP id y2so968751lbk.31 for ; Tue, 11 Sep 2012 23:06:03 -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=6kAP8CNoy3fPGoXCno4c0CdisVTqdSOoqIrph9dIOZ4=; b=iUfx2dV7CNU7ws1ZgXGAIjW99hYRW8evTZBiQO/+GBcnukhxtEH5zZeX489pvhBNj7 skIQWgb7KS0S3phP4d+5hDzkGZEAHomuu63M8wQ1n66e5SqyMG1kZLeb3htBIiI9q+ss 8LJ4ABxPRCP7CCstMBSj/Hm17fi3uY0RW4toBcdZI8fP6Srz2Zcz9zdi8r2f2f624nwE 1MdaUZCmTlPga+FM1wHBJ2suC/DJrn+4AEMu5jMEt0QJaSAITOo9VqEDzNAQreTolLfm DLDEc5tpYPrv9sYpjZvrLHhQfnRSdrX1whSc8wIrkrq72LK5tEhR4bxTtFiqBiPKId28 bPWg== MIME-Version: 1.0 Received: by 10.152.104.145 with SMTP id ge17mr4109041lab.34.1347429963250; Tue, 11 Sep 2012 23:06:03 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Tue, 11 Sep 2012 23:06:02 -0700 (PDT) In-Reply-To: <20120912040021.GQ86424@mx1.yitter.info> References: <504D1416.8040400@Commerco.Net> <1899872.sSQ7Nx3y1k@scott-latitude-e6320> <6.2.5.6.2.20120911152657.09c43f90@resistor.net> <1546504.1r6gpORNoX@scott-latitude-e6320> <6.2.5.6.2.20120911203351.09453fe0@resistor.net> <20120912040021.GQ86424@mx1.yitter.info> Date: Tue, 11 Sep 2012 23:06:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 06:06:05 -0000 On Tue, Sep 11, 2012 at 9:00 PM, Andrew Sullivan wrote: > First, is this really a clarification? That is, does the new proposed > text expans on or otherwise clarify what the old text said implicitly, > as Scott argues it does? I think this is moot given my answer to the second: > Second, is the new text both true and a correct use of the RFC 2119 > keyword? It seems to me that in the new proposed text, it isn't a > 2119 MUST at all. It's really just stating an entailment. It could > be as correctly phrased as "if senders ... 'want to support receivers > making negative authorization determinations, it is necessary for them > to publish records that end in -all'". If I understand correctly, > this is a fact about how the protocol works, and not actually a > normative requirement for interoperation. What have I missed? My understanding is that your proposed wording here is more appropriate for a protocol document (a "technical specification" in RFC2026 terms), but the MUST might be appropriate in an applicability statement. Since RFC4408bis is the former and not the latter, I'm inclined to go with the non-2119 version. I don't know if it's possible to have one document be both of those things at the same time, but I don't think I've ever seen one. For those unfamiliar: An applicability statement is a proposed standard document that explains how to use a protocol to achieve a particular goal that wasn't described in the protocol itself, such as a novel application or innovation. RFC2119 language is use a bit differently there, to mean "To achieve your goal, you have to take these steps to make the protocol afford you this additional capability." A recent example is RFC6647, which is an applicability statement about how to apply SMTP to achieve what's commonly known as "greylisting". -MSK From superuser@gmail.com Tue Sep 11 23:10:41 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E38B21F8535 for ; Tue, 11 Sep 2012 23:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiPUVnqFeSJX for ; Tue, 11 Sep 2012 23:10:40 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E57521F852D for ; Tue, 11 Sep 2012 23:10:40 -0700 (PDT) Received: by lbky2 with SMTP id y2so970948lbk.31 for ; Tue, 11 Sep 2012 23:10:39 -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=/pbe1jaG7reEnUaQRztT3GYYNOIrWtw0nRR92XpMk8E=; b=k1oyzmmalOOz4EjsxvLFZb58RVcvrQdKpaTyWRPEkW22bnELxowjLO41+BEiGGQL/p PZgPFWU8xrNWdCW3oZwLuUS2ewnPs/U0Mz7iAQLm9pIPXEYTB0GCSPk9ubivx49FYeM1 O/SSqR5Wmz3sf3Mf8sNTta/UIawC14ClwLn6g3FHJQ0UsXf35//O3rePUPlPQdj2NVCZ p6LYdZGdgwQXavOkx0Q7Gt83vabss+wFZvMGI4JtQLHZLemTQXvsn1sau1EiszfI122I PYAiRl0ComKTHbDDO6O0/uj3vkHb2y+0DktRnJhtg3tcFUXLp/Zw9/GF7DXssuNv9a/o 6O7Q== MIME-Version: 1.0 Received: by 10.112.31.233 with SMTP id d9mr7033447lbi.116.1347430239207; Tue, 11 Sep 2012 23:10:39 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Tue, 11 Sep 2012 23:10:39 -0700 (PDT) In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF0118524A@XCHANGE.rvl.internal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185203@XCHANGE.rvl.internal> <0D2A0D5F64179F4F9556D3DEDE39F9AF0118522F@XCHANGE.rvl.internal> <0D2A0D5F64179F4F9556D3DEDE39F9AF0118524A@XCHANGE.rvl.internal> Date: Tue, 11 Sep 2012 23:10:39 -0700 Message-ID: From: "Murray S. Kucherawy" To: Wayne Doust Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] FW: Secetion 4.6.4 DNS Lookup Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 06:10:41 -0000 On Tue, Sep 11, 2012 at 11:01 PM, Wayne Doust wrote: > The point of the proposed text is to make it clear to implementers that > whilst pre-processing for syntax errors may be valid, pre-processing for > DNS lookups is definitely not valid. I think I agree. To be precise, returning "permerror" based solely on the fact that the SPF policy might (or even will) exceed the DNS lookup counts is probably not valid. I might have 30 mechanisms listed, but if on evaluation it never gets past the fifth one, what's the harm? -MSK From superuser@gmail.com Wed Sep 12 00:56:15 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6211521F864D for ; Wed, 12 Sep 2012 00:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDfetOsiTLzf for ; Wed, 12 Sep 2012 00:56:15 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9607421F8518 for ; Wed, 12 Sep 2012 00:56:14 -0700 (PDT) Received: by lahm15 with SMTP id m15so975569lah.31 for ; Wed, 12 Sep 2012 00:56:13 -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=fB+5t9H+TZl+USfCkGC1EhYR1HKDttxl4oTmDQFIjto=; b=Jf1PSRBFCbqBSO1PVs8qKUicioSjkNEPPxxpQqoVr3uxPrdgHZMbqGz6V42ihs1eUq 0PULrcLN+Yh9MIrc6o1jx6zQ3pqIh0SDU3Bphnm+X8v1dHGddd1mPUyoBdZgR0+MPB07 NzcOQWw0q+dukfARHW8bqiUX+MIO+tExEWFwAKu1RdAxaMboekMGm3qgEXPP4I1Gzbxr Ekwqfp5Z0FNKPpqPUjTLodlUUq54djRZd9LwcowhtS/WiqNs+wiNfKMluNzYg5kT6rwB qvlNOMmMwI/jjLo9IsaIVc6BNGmydfw7XxdVSxg4pV51xPixGIfQhapW1qiH5xF+LaqJ 3GoA== MIME-Version: 1.0 Received: by 10.112.88.73 with SMTP id be9mr7124737lbb.72.1347436573531; Wed, 12 Sep 2012 00:56:13 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Wed, 12 Sep 2012 00:56:13 -0700 (PDT) In-Reply-To: <20120911230821.GN79075@verdi> References: <20120911152531.GJ79075@verdi> <20120911160820.55698.qmail@joyce.lan> <20120911163400.GK79075@verdi> <20120911180336.GM79075@verdi> <20120911230821.GN79075@verdi> Date: Wed, 12 Sep 2012 00:56:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Leslie Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 07:56:15 -0000 On Tue, Sep 11, 2012 at 4:08 PM, John Leslie wrote: > I'm not clear what that has to do with the perception of blowback. > (Perception, alas, is as close as we can get to "reality".) Nothing, because I don't think that's what this thread was originally about. I went back through it and I couldn't find the point where that subject came in. Maybe that's why the other John was also arguing policy issues. I think it's probably quite appropriate to point out to people that generating a DSN for something for which SPF failed is a questionable practice. I don't know about doing so normatively though, because it has nothing to do with the definition of SPF as a protocol; it's operational advice, which deserves non-normative treatment in a protocol document. (...which in turn means this seems to be more material for an operations guide than I'd originally thought.) > You're pretty darn far off-base if you think I want SPF to > demand normative receiver policy... But that's what this thread was about. And the Subject: hasn't changed since it was. No wonder you think we're confused. -MSK From sm@resistor.net Wed Sep 12 01:52:10 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4162B21F860F for ; Wed, 12 Sep 2012 01:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VaXDeCYJR6T for ; Wed, 12 Sep 2012 01:52:09 -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 64A5B21F860B for ; Wed, 12 Sep 2012 01:52:09 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8C8q3fv008864 for ; Wed, 12 Sep 2012 01:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347439927; bh=R7wUsf5nMdt5wl0kWkT7jcMFWHw3TMypzucBi3j2K3A=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=GqYEmAbnJYk2d6NhCf+i0/S0ZP3GsC2deGb9xRSwiK3sdckpchqyLrw/KEjZws98U 39kh3G4FashPsC147HH5zvOwIUKZJdFfhTJmn2LBAAaUM02jwuJfcThYNkOQHZeEhR Vg3Q5ga7hbLY11mMKyUNgCh6/FLxZ+yVqmgeAu4c= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1347439927; i=@resistor.net; bh=R7wUsf5nMdt5wl0kWkT7jcMFWHw3TMypzucBi3j2K3A=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=HPnnI2hIidbqO+NoybQ2KpCn5YnMZUCIz74nxSwbw4Xx061BXf6I+G3aQxnyjKzt2 UcKeimD8K0sNr4YjyRog8oLXfYFYTCuO0Joa3lzOkgZsgWpB23ZQX5uxJMg9xcqs1M 9rliNdh2aPQZJiSBcDy4Nkq4hFEmibl5epbl3AP8= Message-Id: <6.2.5.6.2.20120912010054.06c813d8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 12 Sep 2012 01:51:56 -0700 To: spfbis@ietf.org From: SM In-Reply-To: References: <20120912011024.20846.qmail@joyce.lan> <1469933.kpSdRM44Gj@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 08:52:10 -0000 At 22:54 11-09-2012, Murray S. Kucherawy wrote: >The debate, then, is about whether RFC2119 language can be used to >describe an operational practice (in this case, local policy) that >isn't part of the protocol proper. I believe the answer is "no". RFC 2119 language is about interoperability. It is generally not used to describe an operational practice in a protocol document. >To be specific: The protocol itself works if the receiver generates >the result that the sender's published policy intended to provide. >The normative terms are available to be used such that implementers >will write something that works properly. That's interoperability. >What the receiver does with the message afterwards doesn't change the >fact that check_host() did precisely what it was supposed to do. The That's what the specification says in my opinion. There is the problem definition, i.e. what problem the protocol seeks to solve. This is from the Introduction section: "Although this feature is desirable in some circumstances, it is a major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam). Furthermore, many domain name holders are understandably concerned about the ease with which other entities may make use of their domain names, often with malicious intent." That can be read as SPF attempts to: (a) reduce spam (b) restrict the usage of domain names in email to domain name holders Item (a) generates controversies. Item (b) works in some cases and does not work well with forwarding. "It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea." Regards, -sm From vesely@tana.it Wed Sep 12 01:59:52 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9202B21F861F for ; Wed, 12 Sep 2012 01:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.644 X-Spam-Level: X-Spam-Status: No, score=-4.644 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IttRqItlWS8f for ; Wed, 12 Sep 2012 01:59:51 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7467221F861A for ; Wed, 12 Sep 2012 01:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347440388; bh=4WdfcL1pJuBnjdaP+i2dnNF4zg9IMriOfBTlT3ATEto=; l=497; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=MO+4U5tr9Q1sQLrHJxJfQaWiCTwNLcemno+LiVc2aF3u8sJDEYSwops/y9cYQKP6H GBoZjr7rjz0APPNJGJQfWjI5aKrx2EBJ0NYMjtOwaXF/FJ69/T5RPuWPAJ8/vshq/e XpkRtSVveel3JR0qw1myTUzH0/gEg53xr6ntsuOI= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 12 Sep 2012 10:59:48 +0200 id 00000000005DC048.0000000050504F04.00000DF8 Message-ID: <50504F03.4060509@tana.it> Date: Wed, 12 Sep 2012 10:59:47 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <20120911152531.GJ79075@verdi> <20120911160820.55698.qmail@joyce.lan> <20120911163400.GK79075@verdi> <20120911180336.GM79075@verdi> <20120911230821.GN79075@verdi> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 08:59:52 -0000 On Wed 12/Sep/2012 09:56:13 +0200 Murray S. Kucherawy wrote: > > I think it's probably quite appropriate to point out to people that > generating a DSN for something for which SPF failed is a questionable > practice. Yet, non-rewriting forwarders do so in order to let any DSN go to the right recipient. In RFC 5598's wording: The benefit of retaining the original MailFrom value is to ensure that an Actor related to the originating ADMD knows there has been a delivery problem. From superuser@gmail.com Wed Sep 12 02:37:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C96221F84EE for ; Wed, 12 Sep 2012 02:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-0bWisG167E for ; Wed, 12 Sep 2012 02:37:39 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id ABA0121F84EF for ; Wed, 12 Sep 2012 02:37:38 -0700 (PDT) Received: by lbky2 with SMTP id y2so1097240lbk.31 for ; Wed, 12 Sep 2012 02:37:34 -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=vYmlBoNaDbCymdfOLjXnim2Vg04CpvWEqwrRm1Xkkj0=; b=IuolPf+P2Ns2yTp7Cz5jbU9DuLQEO+QjiZ0EQ15fzTBNoenLZNwTkHYi8g3wWELOwt c7SvImdjXqmXdPfW+MrmQhRrNf4Fl7GOe35/RGBBP0epNQecK7BXoJpRlZOOHHi3d9Tu Q8uGjziWW6hTQ+tL38cNrPh0VGqIOVVUCa4qMu1PTg0eYMZNk/l5Tb+lKN5OtdzrYuA7 fk+zFqCjC30dEQgxV+vRQzXTH/dKnk7MbTMu5O3ySe9G+WMLfmlXRWGX5hj88Zjo9+hJ nYWM4vw9jizltgnQdiFzzPDESrdM6zf5jNKfFgtaj9Eky08B/I6alVcwh5YMJAkMZMtF ddVQ== MIME-Version: 1.0 Received: by 10.112.84.101 with SMTP id x5mr7136010lby.28.1347442653987; Wed, 12 Sep 2012 02:37:33 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Wed, 12 Sep 2012 02:37:33 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120912010054.06c813d8@resistor.net> References: <20120912011024.20846.qmail@joyce.lan> <1469933.kpSdRM44Gj@scott-latitude-e6320> <6.2.5.6.2.20120912010054.06c813d8@resistor.net> Date: Wed, 12 Sep 2012 02:37:33 -0700 Message-ID: From: "Murray S. Kucherawy" To: SM Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 09:37:39 -0000 On Wed, Sep 12, 2012 at 1:51 AM, SM wrote: >> The debate, then, is about whether RFC2119 language can be used to >> describe an operational practice (in this case, local policy) that >> isn't part of the protocol proper. I believe the answer is "no". > > RFC 2119 language is about interoperability. It is generally not used to > describe an operational practice in a protocol document. I think if we can all agree on that, then the required edits become pretty obvious. -MSK From superuser@gmail.com Wed Sep 12 02:43:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B09C21F860E for ; Wed, 12 Sep 2012 02:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjBityJwJOiG for ; Wed, 12 Sep 2012 02:43:00 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC5121F85ED for ; Wed, 12 Sep 2012 02:42:59 -0700 (PDT) Received: by lahm15 with SMTP id m15so1044545lah.31 for ; Wed, 12 Sep 2012 02:42:59 -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=qtJvXLHoaDB7qF0EYFK8CG9ULgk+LG21ccQmpq1rDnQ=; b=vPoPVIQ+DGuZG3dBTN3MPFJqYyXx7nM302Xrh67U6v3HRDgiB4MH+MSZ0NPzd4RIYT /Jr4rIsfzPImkQhE8gjIti2aSWPJzsGEqZSPCz2OXSuSTJfTpiZEJAGmjuC+6TRy8+tb y6q6KQsAhtw7Dw4aKfB2MGiRegnZYDpLGm2eh+fK/8s3gsFjQaLgcnelLi3KFBBj0Rz/ ylwjRZUk7V07L+pUw5TP3InBiqkS3yXgohIGzO5etAS/W9QhLS/yBrCQyNnmTCukkOUm K+p2XwdDN7ux3uDZCK0//X9K019WrojQkuydq89v/cM1UyXotpXKmxglcKCP9tBDClcw eLDQ== MIME-Version: 1.0 Received: by 10.152.46.203 with SMTP id x11mr18127554lam.46.1347442979087; Wed, 12 Sep 2012 02:42:59 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Wed, 12 Sep 2012 02:42:58 -0700 (PDT) In-Reply-To: <50504F03.4060509@tana.it> References: <20120911152531.GJ79075@verdi> <20120911160820.55698.qmail@joyce.lan> <20120911163400.GK79075@verdi> <20120911180336.GM79075@verdi> <20120911230821.GN79075@verdi> <50504F03.4060509@tana.it> Date: Wed, 12 Sep 2012 02:42:58 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 09:43:01 -0000 On Wed, Sep 12, 2012 at 1:59 AM, Alessandro Vesely wrote: >> I think it's probably quite appropriate to point out to people that >> generating a DSN for something for which SPF failed is a questionable >> practice. > > Yet, non-rewriting forwarders do so in order to let any DSN go to the > right recipient. In RFC 5598's wording: > > The benefit of retaining the original MailFrom value is to > ensure that an Actor related to the originating ADMD knows > there has been a delivery problem. But non-rewriting forwarders aren't the ones generating DSNs, so I'm not sure what point you're trying to make. Someone who receives mail that passed through a non-rewriting forwarder will probably get an SPF "fail". That might be legitimate forwarded mail, it might be fraudulent mail, it might be something else. In only one of those cases is it clear that a DSN would be backscatter and ought to be avoided. Reliably identifying that case requires heuristics. We can't normatively specify such things; the best we can do is call out the condition and give advice (though possibly not in the core protocol document). -MSK From agthisell@yahoo.com Wed Sep 12 05:10:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36ED21F85F4 for ; Wed, 12 Sep 2012 05:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06NARN8s0rbp for ; Wed, 12 Sep 2012 05:10:41 -0700 (PDT) Received: from nm35.bullet.mail.ne1.yahoo.com (nm35.bullet.mail.ne1.yahoo.com [98.138.229.28]) by ietfa.amsl.com (Postfix) with SMTP id 7974621F8564 for ; Wed, 12 Sep 2012 05:10:41 -0700 (PDT) Received: from [98.138.90.51] by nm35.bullet.mail.ne1.yahoo.com with NNFMP; 12 Sep 2012 12:10:38 -0000 Received: from [98.138.226.169] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 12 Sep 2012 12:10:38 -0000 Received: from [127.0.0.1] by omp1070.mail.ne1.yahoo.com with NNFMP; 12 Sep 2012 12:10:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 343833.64422.bm@omp1070.mail.ne1.yahoo.com Received: (qmail 51716 invoked by uid 60001); 12 Sep 2012 12:10:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347451838; bh=goEfVVU4rwSX5Ls2KbZ3zTo4LZrulkjg3o35zOSHgHY=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=xeTgq1Yx5gcFFUaejFCT+VTkQHK+1yMnzdRAK9HsKDNy9YR4xX5rk38fZ9uboeHCICJR+Sf4JDZ4hbEeIqQqAfrhKMUtZy1MzvrOZXJYToHuSwDzbrKzd81iW4WPBbKX/TjFeQozbgKBQT4MKuyNELExSKzspbmm34IhJjtTV68= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=HPCnJWax/6aYD0oo2pfJwGRJyk/OKxLU162lo6Oc3Vt9YN8x+LV/9U0E3YTpeKse0GKndzWlIiwnLtSqVjKw+ll3y2BfDXPqw7zD6flBRfW4qY3Zj9BMovLY+wll46/wPAD/BAM/7YDCOmy/CCC7jO2HTiNqFROAGtLXDrQtAAo=; X-YMail-OSG: mhHFWKQVM1n.riu0G1XB4C7dEe6HKSXzNEe_Facum7rRCrB cJeDB4B19Oyra4lSFyGbEST_NKwDZ26JOVEebG4WndE2Vgw9Mm4r3kxjLjc4 gQeRQVmZbO5j8GHwBnrTKxaQkIt2KHbt6OBN7WRF_2eeDyz.wlk3032h5dZP fpMLxY5kx1rZJQLyvLX6csQaRru.R__E4bmjOtObv5j3bqruULtF6TWOkzeo .1BVnJ4_OEiPUO6.8psV.obNNh7klYVNpvlyhRPxeM754VWWXUhne0XiS0bo ao.nWPJ16SMkAwaOjZFKie6x02QbkqReY0c7xcXGRTuCONo9LaDi0bfpOM9P 5S_4PRb3maMO2UV5Q61lUn0d_oW3oRPVXQFLpooUZdqZY86.9hn_b6eBObIi GVjNODpgu.nVfD4L673jXuNsXoCosmMoQ3KCmYvNToQuDsMzi5Mimb_SkXG8 WV8dFeNmrQDdzsZ.PG61GYlrAdy3lJUMEWuiAYoYqF47ZodCNTszJ11Xo76p aBc0I9269Uq0- Received: from [71.61.133.134] by web125106.mail.ne1.yahoo.com via HTTP; Wed, 12 Sep 2012 05:10:38 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347451838.27732.YahooMailClassic@web125106.mail.ne1.yahoo.com> Date: Wed, 12 Sep 2012 05:10:38 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] FW: Secetion 4.6.4 DNS Lookup Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 12:10:48 -0000 > To be precise, returning "permerror" based solely on the fact that the > SPF policy might (or even will) exceed the DNS lookup counts is > probably not valid. I might have 30 mechanisms listed, but if on > evaluation it never gets past the fifth one, what's the harm? The harm in having too many mechanisms, even if they never get evaluated, is basically the same as having syntax errors, even if they never get evaluated. Many script-type languages (unix shell scripts, JCL, etc.) don't detect syntax errors until they encounter them. Most other computer languages will complain. In the case of hilton.com, I could see the gut feel being that the extra mechanisms should be ignored, but in other cases, I could see the gut feel being that you should give consistent results, rather than authorized results sometimes getting permerror a small percentage of the time. In particular, is really common to hit the "end" of an SPF record. Having all unauthorized mail evaluated to permerror is not what people will expect. I suspect that in the wild, there are, indeed, implementations that do it both ways. From agthisell@yahoo.com Wed Sep 12 05:37:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4202521F860D for ; Wed, 12 Sep 2012 05:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJhZlVRPdY0P for ; Wed, 12 Sep 2012 05:37:04 -0700 (PDT) Received: from nm9-vm4.bullet.mail.ne1.yahoo.com (nm9-vm4.bullet.mail.ne1.yahoo.com [98.138.91.169]) by ietfa.amsl.com (Postfix) with SMTP id 959BF21F85F4 for ; Wed, 12 Sep 2012 05:37:04 -0700 (PDT) Received: from [98.138.90.55] by nm9.bullet.mail.ne1.yahoo.com with NNFMP; 12 Sep 2012 12:37:01 -0000 Received: from [98.138.89.254] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 12 Sep 2012 12:37:01 -0000 Received: from [127.0.0.1] by omp1046.mail.ne1.yahoo.com with NNFMP; 12 Sep 2012 12:37:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 502369.63306.bm@omp1046.mail.ne1.yahoo.com Received: (qmail 63071 invoked by uid 60001); 12 Sep 2012 12:37:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347453421; bh=SQIh5xSb2O2KL3LkAJTMH119CYjG960CfPCx1zmNOxE=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=1KSujNEJYCFIK+yGBe6n6+N9BBaSDYlUYIgVjX7qpQBPOAxgaR6ypiIp4IJBzejC0ywOcfp5dWNF3Yu2MEdZGr7ceRUNPZxXwbnbmWQ9iP/d8m2uwGqJhYt/rmYIXKgKcsdnEH/4BDchLu/hqS6Gxr8cxoOAgb+elFDn/Q8Ssrg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=JAngXN/9AAo8AtxJnQlHLe4hlW+Ows6HvtXsALWXdtkJS0wlUhtGm9SfrdpC/iD4XD0Iq4Idhfwsl0IgAfLN5NigHD9ok0HwK42iOPdgLNHpb3MNNBwU6F7JXepUPvNyprU/4RUag/8ef6+cFjzijldNo8XVT3tpk8Qaq+BsyHI=; X-YMail-OSG: juVeLFQVM1k_lL2fraeMn835.cCsl9AhMX3YYymILImV5F2 Yi2XGnOCKGyM.kYWOUJefs0pDPo68a1IIlmgoCnajkeW52Ndh_NaSuRGvqLW vyKJuFYWluONAwUfGI8jRTGyLIa0MD4K0n_pu7WY6nEdRLVV_0TdKtS_nfjf Q_4.cTY2EOqOeKvlMS_2dQ91jV9cCD.gCtScmxPIRMJj0EmlHfIEy38gb_Nt TfzjfKpCvIJVfnLoh.41dJakjCQ8AX63VQNGHMdZpyH32W4Ai.toBBcwkZGv olNyd1.ZanmBXXchiuiLH.2wlzR3EmoQOldVAFRqhVgUrRnFl1fvcsMLrKzH oIldgADjSx2Zx_lpGaeXdsu3fVdu56BkEvD4f05rhz7lS3s6CPmwSwsjId2E 8VozgGElgJ0Cox9RxD2hOyHmcB0BkcLH3nSj4CrhbYmmmJQhZmdPWtF1oG1o cMyFNYVVqMrKZ5FHlBdk- Received: from [71.61.133.134] by web125102.mail.ne1.yahoo.com via HTTP; Wed, 12 Sep 2012 05:37:01 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347453421.62526.YahooMailClassic@web125102.mail.ne1.yahoo.com> Date: Wed, 12 Sep 2012 05:37:01 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] > Re: FW: Secetion 4.6.4 DNS Lookup Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 12:37:05 -0000 > To be precise, returning "permerror" based solely on the fact that the > SPF policy might (or even will) exceed the DNS lookup counts is > probably not valid. I might have 30 mechanisms listed, but if on > evaluation it never gets past the fifth one, what's the harm? Sorry for the double post, I hit send too soon. Limiting the amount of work that an SPF record generates is really important for DoS attack prevention. However, you want that restriction to be as easy to understand as possible. You want people to be able to accurately do it by hand. Sure, you could add a rule that mechanisms after -all don't count against the process limits, but then if someone scanning by hand just looks at the "important mechanisms" and misses the -all, they would count the ones after the -all. RFC 4408 tries to strike a balance between DoS potential and complexity of the rules. For example, the ptr: mechanism is really a cost per SPF evaluation, rather than a cost per mechanism evaluation. You are looking up PTR records based on the IP address which never changes, so you could have 1000 ptr: mechanisms without a DoS potential. However, trying to explain why ptr: do DNS lookups by they don't count would make the mechanism limit rules a lot more confusing. So, RFC takes the easy route of saying ptr: mechanisms count just like a:/mx:, while %{p} is free, even if neither is really true. I would like to keep the process limits as simple as practical. I feel that it is already to complex/long, but I'm not sure that it can be improved much, especially with the constraints of the charter. From ajs@anvilwalrusden.com Wed Sep 12 06:10:33 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E02F21F859C for ; Wed, 12 Sep 2012 06:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.637 X-Spam-Level: X-Spam-Status: No, score=-0.637 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3X51LSPK2DMe for ; Wed, 12 Sep 2012 06:10:32 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 88C9421F8532 for ; Wed, 12 Sep 2012 06:10:32 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 7B4C48A031 for ; Wed, 12 Sep 2012 13:10:30 +0000 (UTC) Date: Wed, 12 Sep 2012 09:10:31 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120912131030.GB87637@mx1.yitter.info> References: <20120912011024.20846.qmail@joyce.lan> <1469933.kpSdRM44Gj@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1469933.kpSdRM44Gj@scott-latitude-e6320> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 13:10:33 -0000 No hat. Well, maybe a 2119 weenie hat on. On Tue, Sep 11, 2012 at 10:40:19PM -0400, Scott Kitterman wrote: > OTOH, SHOULD NOT stamps it > a generally a bad idea (which I think is reasonable), but says go ahead if you > think you know better. SHOULD NOT is an interoperability word that says that you'd better have a pretty good reason not to do this thing. Many of us argue that any SHOULD NOT which does not say what happens if you violate the condition is a misuse of SHOULD NOT. Most importantly, SHOULD NOT is not some sort of expression of what the consensus in good ideas or taste is. So it's not just that it's a "generally bad idea". It needs to have some interoperation consequence. > While there are no RFC police, I have, on more than one occasion told people > where had implemented $BAD_IDEA to get read some section of some RFC to learn > about why it was a bad idea and they've taken it to heart. Yes, there's nothing wrong with explaining why something is a bad idea. (That need not be couched in SHOULD NOT, of course.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From agthisell@yahoo.com Wed Sep 12 06:50:51 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706BA21F85ED for ; Wed, 12 Sep 2012 06:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.706 X-Spam-Level: X-Spam-Status: No, score=-0.706 tagged_above=-999 required=5 tests=[AWL=-0.707, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4ADbnrXzVaG for ; Wed, 12 Sep 2012 06:50:50 -0700 (PDT) Received: from nm10.bullet.mail.ne1.yahoo.com (nm10.bullet.mail.ne1.yahoo.com [98.138.90.73]) by ietfa.amsl.com (Postfix) with SMTP id 714B321F85A4 for ; Wed, 12 Sep 2012 06:50:50 -0700 (PDT) Received: from [98.138.90.54] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 12 Sep 2012 13:50:47 -0000 Received: from [98.138.226.163] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 12 Sep 2012 13:50:47 -0000 Received: from [127.0.0.1] by omp1064.mail.ne1.yahoo.com with NNFMP; 12 Sep 2012 13:50:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 239068.10523.bm@omp1064.mail.ne1.yahoo.com Received: (qmail 56190 invoked by uid 60001); 12 Sep 2012 13:50:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347457847; bh=sup4IoWx4DdaGbv5u46hzFyNx/TFAw4y5rPCPe839e4=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=SopTkRnhPg63rb0uI+12M5Yc3BUQ5cHskEDcsaX4kEJkFJkQhlFf0vrWd08gG+Dc89Uprk7ylY0oLXoGKGtVaaMKKYNkju780wEcHv7bwB521b38JnNFdo0xJLApifYwj+9082dlI+937D/zm2jp2N8gXRp+6l1sviH41xbJiBE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=AeYzDjb1shPOYhde5ZHha/+ikwzeizr2Q26l+Wt6CPcGFZKTplMBC5K1WsfQDi1OQ+vBjzw5l66gsZCHlYOanIDMoDuLcrvO44Bd90LVzhITvnQGBDQhqcp5H9sHWdoN57pCYew97+/AkoG05st1nmtDgGsiRH6sUyL0wST7wdM=; X-YMail-OSG: vUKympUVM1nXEMaQcFKGtVrdw494Aei.ZTwN7LPXPFGmTfI evJK411o_6chp5Xcf7rcUfn3vY_rZtJEDX5fn6340nRBQtXUcdLuy8pVxJF. Si8URxRqm.zuBLXRttkjlLtb8DoWItsXHUxTYq4A8yPBR54UhS.8.XwKQ.w1 9XZcgLqq8HErJl_qRiqKhvtGTXq6dRU5CxI0weuhZ1AI.PbdAPvzVY8od1PU oFWiCNb2RHpV9GXOWLlP9GIJ05Ologmbd2JhZJwt_iTSqNiyS7eDARVu0JF0 .OsrkKkPjuDJETQoV3vHRTZFHGDY1Ydy__fZWvwTLrnH8ScT2E_sPawLQJ_W p_aqDJ6slDEPLbDxUyJVBOfwcWxtzoKVWase4dBiQIIa.ShikT0p2PWUK.lK gRU__6bNUytkP1nBjXeHBzHKX.pIL_i5EpS5fy4Y2GFzjpWjgsKQJQGkyfOu gOThmSw9.FRnZz5JlaHc- Received: from [71.61.133.134] by web125103.mail.ne1.yahoo.com via HTTP; Wed, 12 Sep 2012 06:50:47 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347457847.27386.YahooMailClassic@web125103.mail.ne1.yahoo.com> Date: Wed, 12 Sep 2012 06:50:47 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 13:50:51 -0000 My two cents... First, I don't think we should try to dictate local policy in an RFC. Even if the IESG thought it was ok to do, I don't think it is very effective. Second, historically, Meng Weng Wong felt that we could and *should* try to dictate local policy, and the drafts he wrote in 2003 reflected that. Even the ones from 2004 pre-marid had some of that language left over. Third, during marid, it was resolved that drafts shouldn't have local policy. We are repeating arguments that conflict with our charter. Fourth, while we can't tell people what to do with email they receive, it might be productive to turn the argument around to what senders expect with their sender policies. So, we can't say "you MUST reject on SPF fail", but we could say "the sender accepts that any mail that is rejected due to an SPF fail is their problem to resolve." Now that particular example would change the semantics of SPF fail and thus violate our charter. We could add a modifer called yesreallywewantrejectonfail=true, but that again would violate our charter. Still, language along those lines might help the draft. Last, sometimes senders can know that it is ok to reject all email that fails. For example an SPF record that says "v=spf1 -all" is very safe for host that don't send email. Also, there are ways for senders largely solver the forwarding problem from their end (e.g. using ses/batv, an exist: mechanism and a custom DNS server), and any false positives are acceptable to them. Or the marketing department may want peoples "real" email address and not "hide" behind throw-away forwarding services. *shrug* People are going to do what they want anyway. And, they will try to shift blame for all problems onto someone else anyway. Human nature. From hsantos@isdg.net Wed Sep 12 08:22:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0868C21F8613 for ; Wed, 12 Sep 2012 08:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.38 X-Spam-Level: X-Spam-Status: No, score=-101.38 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ElUn119MGkn for ; Wed, 12 Sep 2012 08:21:59 -0700 (PDT) Received: from secure.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAB821F861F for ; Wed, 12 Sep 2012 08:21:57 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4098; t=1347463309; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=honva2ZkXI7d7iYkatVHUme7/Ng=; b=Jsy3orP4yEviyl1OGmeL H93qRI5ebJdaHf82/wla/SpAumDBc7I2gB9GOs2Udbzl3acN8agOg2otYAHlXKFc Rs2JkpwJpBYoYthXKJXfMNHGvoKMWE7//LXTN/LceKcgYREXYfmRwbqa4SrwRcpg wOmNzMaVRe1o4yA5hlu/jzc= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 11:21:49 -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 3485087211.6316.3640; Wed, 12 Sep 2012 11:21:49 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4098; t=1347463085; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2Wld/Ce UlmxCuWNze9zKGZEsxMOQLRGcK73YAoOwuDc=; b=LjxuIKAxwa+ZpIGsukW//Uc muYiM5eaKhzC+N5lmbkjTJJM7CH1J+1aYs6PJfCqHOFvDvqg78ZnoY9lM1ttSIWF pP+m/XiM2VofpEc3h5YYM7c1nq3shZmFzV7ZLU2CDZ7XQx17fq6wQpLsLBudA11r QwBhWMRj2TOBx0NNVNpA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 11:18:05 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4083883036.9.3692; Wed, 12 Sep 2012 11:18:04 -0400 Message-ID: <5050A8B3.5070301@isdg.net> Date: Wed, 12 Sep 2012 11:22:27 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: <1347457847.27386.YahooMailClassic@web125103.mail.ne1.yahoo.com> In-Reply-To: <1347457847.27386.YahooMailClassic@web125103.mail.ne1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 15:22:00 -0000 Look, just because there are some here that wishes to dismiss what SPF was during MARID, continued to carried the same mindset over the years are they developed other protocols and when it didn't pan out, come back to SPF to re-created the same opposition once again, does mean its going to change anything. Just like the definition of insanity. I don't believe I will be off base that SPF was from the very beginning an PROTOCOL for REJECTION of DETECTABLE SPOOFS using the LMAP assertion of DOMAIN::IP. SPF is not the only protocol. We had early predecessors in RMX, DMP, CEP all with the same REJECTION semantics. Keep in MIND that AVOIDING the IETF was the BY DESIGN - so we can do these types of new pseudo standards that would NEVER pass IETF review. It only came because Microsoft jumped into the game with its XML version. As a result, we had FOUR PRODUCTIONS FROM MARID: RFC4405 RFC4406 RFC4407 RFC4408 And it is SURREAL that we can once again DISPUTE the spirit and intent again of what SPF was design for to offer and do not only for the DOMAIN but the HIGHLY ABUSED receiver who has just as much a major interest in SPF than domains publishing and exposing their outbound mail practices. I reject the notion that SPFBIS is being used to water down this 9+ year protocols with "RFC2119" related semantics or lack their of. I don't like the way this WG direction has taken and its ashame that we will be repeating history just like it happen with ADSP. Taken away ADSP, DKIM was watered down to a near zero payoff protocol. Take away the highest benefit SPF has with -ALL policy and I can almost you assure you, the MISSION will be accomplish of destroy this protocol as well and in fact, watering down all the domain disclaimers they have out with -ALL policies. I will even go as far for the legal people who can understand this, RECEIVER can put themselves at RISK for MAL-PRACTICE for simple things like not accepting FAILED mail knowing full well what the DOMAIN owner intent and expectation was with a SPF SPOOF DETECTED failed messages. Arthur Thisell wrote: > My two cents... > > First, I don't think we should try to dictate local policy in an RFC. Even if the IESG thought it was ok to do, I don't think it is very effective. > > Second, historically, Meng Weng Wong felt that we could and *should* try to dictate local policy, and the drafts he wrote in 2003 reflected that. Even the ones from 2004 pre-marid had some of that language left over. > > Third, during marid, it was resolved that drafts shouldn't have local policy. We are repeating arguments that conflict with our charter. > > Fourth, while we can't tell people what to do with email they receive, it might be productive to turn the argument around to what senders expect with their sender policies. So, we can't say "you MUST reject on SPF fail", but we could say "the sender accepts that any mail that is rejected due to an SPF fail is their problem to resolve." Now that particular example would change the semantics of SPF fail and thus violate our charter. We could add a modifer called yesreallywewantrejectonfail=true, but that again would violate our charter. Still, language along those lines might help the draft. > > Last, sometimes senders can know that it is ok to reject all email that fails. For example an SPF record that says "v=spf1 -all" is very safe for host that don't send email. Also, there are ways for senders largely solver the forwarding problem from their end (e.g. using ses/batv, an exist: mechanism and a custom DNS server), and any false positives are acceptable to them. Or the marketing department may want peoples "real" email address and not "hide" behind throw-away forwarding services. > > *shrug* > > People are going to do what they want anyway. And, they will try to shift blame for all problems onto someone else anyway. Human nature. > > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From hsantos@isdg.net Wed Sep 12 09:30:15 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C9D21F8688 for ; Wed, 12 Sep 2012 09:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.78 X-Spam-Level: X-Spam-Status: No, score=-100.78 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34nWu1FiVYW4 for ; Wed, 12 Sep 2012 09:30:14 -0700 (PDT) Received: from mail.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A927221F861F for ; Wed, 12 Sep 2012 09:30:13 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=7631; t=1347467405; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=3rioDjpUQ9AgH5ecfcM8S+i9y/w=; b=uW9WOuBC37n2sRVKhOc6 2+eDUZQ4a5CadckFGi5R9lbOjdYrsQxQOnT1a2lXH07GSEIFNpBUEiwvpUrrmVRM hx4ZSNdriMtY9zM01o2Db//uZ6fBsB8dYAG029IvPUpYjridy7cSw1JpscOVwzPr La8j4LWimahd/upWxGhdF7I= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 12:30:05 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3489182331.6316.5936; Wed, 12 Sep 2012 12:30:04 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=7631; t=1347467176; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=xZhP/4h 1G4bxZ5l+rFG1YU4RiWUzSqPjEEhpoZIAYBk=; b=oA1iFVPG6uYfOL5ufCEroP/ v4biEPqqVShghcodFRSAAL2NtvEDVVmrXVWpGqJhg7Ze61x156LeeG3/ngU5eDG7 b37klAk7b6A7J0yDj3oZbYtrim7Cipu7UdfgKN3uUx8X9SQQu/GX1ezUpcbONzMU RawK3pQTaUYffLCPs++E= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 12:26:16 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4087974255.9.4112; Wed, 12 Sep 2012 12:26:15 -0400 Message-ID: <5050B8AF.2040702@isdg.net> Date: Wed, 12 Sep 2012 12:30:39 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andrew Sullivan References: <504D1416.8040400@Commerco.Net> <1899872.sSQ7Nx3y1k@scott-latitude-e6320> <6.2.5.6.2.20120911152657.09c43f90@resistor.net> <1546504.1r6gpORNoX@scott-latitude-e6320> <6.2.5.6.2.20120911203351.09453fe0@resistor.net> <20120912040021.GQ86424@mx1.yitter.info> In-Reply-To: <20120912040021.GQ86424@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 16:30:15 -0000 Andrew Sullivan wrote: > No hat. > > On Tue, Sep 11, 2012 at 08:45:55PM -0700, S Moonesamy wrote: > >> [Scott said]: >>> RFC 4408 says a -all records are RECOMMENDED >>> >>> 4408bis currently says if senders ... "want to support receivers making >>> negative authorization determinations, then they MUST publish >>> records that end >>> in -all". >> My reading of that RFC is that "MUST" and "RECOMMENDED" are not the >> same. I do not see strong agreement for the text change. > > It seems that these two mails talk past each other. Scott's point, as > I read him, is that the 4408 text just says "you probably want to use > these records", and the new proposed text says "if you want to achieve > something, then you MUST do some other thing". > > Now, there are two questions here, both relevant to the WG. > > First, is this really a clarification? That is, does the new proposed > text expans on or otherwise clarify what the old text said implicitly, > as Scott argues it does? > > Second, is the new text both true and a correct use of the RFC 2119 > keyword? It seems to me that in the new proposed text, it isn't a > 2119 MUST at all. It's really just stating an entailment. It could > be as correctly phrased as "if senders ... 'want to support receivers > making negative authorization determinations, it is necessary for them > to publish records that end in -all'". If I understand correctly, > this is a fact about how the protocol works, and not actually a > normative requirement for interoperation. What have I missed? > > Best, Nothing if I read you right. This is all very easy. In MARID, there were four productions: rfc4405 - SMTP Extension SUBMITTER protocol (SPF Extension?) rfc4406 - Sender ID: Authenticating E-Mail (SPF Extension?) rfc4407 - PRA Algorithm for RFC4406 (SPF Extension?) rfc4408 - SPF v1.0 "Base Protocol" Prior to MARID, we had LMAP related based protocols: http://tools.ietf.org/html/draft-irtf-asrg-lmap-discussion-01 which RMX, DMP, CEP and eventually SPF and SENDERID were all pattens of. LMAP tried to be a baseline protocol for who these DOMAIN::IP assertion based protocols. Keep in that LMAP was not a protocol but a Philosophy and looking at section 1.2: 1.3. Interpretation of LMAP Data Recipient MTAs are free to interpret LMAP data as they wish. Possibilities range from rejecting email with a 550 error code to using LMAP data as one input to a multi-criterion filter. Domains may also optionally use LMAP data to whitelist or give higher passing values for email in their filters. NOTE, it starts with the OBVIOUS of all things mail related - you are in the control, the local operator/policy decides, but what is includes as the possible design options is the #1 idea with the highest protection value; REJECTION. E-mail from LMAP domains that do not publish LMAP data should NOT be rejected since there is no requirement that domains do so, and many will not, either for policy reasons or from lack of resources. E- mail from non-LMAP domains should be treated as e-mail is treated currently. All local policy decisions remain with the recipient's MTA. Readers are reminded that recipients have the right to refuse any communication from anyone, for any reason. So as you see, this is all NATURAL. Whats going on here is we are using this idea of LOCAL POLICY to mandate that its actually a BAD IDEA to rejection. Now. Is that wrong? No, but from from a software developer standpoint, he need to decide what are the switches, knobs, and default values for operators to use and do so with the ability of adhering with their company mail policies and services. My point we should just spell out all the options and describe accepting fail mail can have some [some] consequences the backend needs to make sure its part of SPF integration and usage. I personally see this as an ethical engineering issue because not to do so, needs to be explained in terms of what benefits are gained by not separating mail over the harm that is possible. If is not done, then IMO, its poor protocol engineering (even mal-practice in the sense that we knew of the problem, but decided not to do anything about it). It just seems to be that we have a battle of two camps that really as preexisted since MARID (SPF, SENDERID), DKEYS, CVS and DKIM, - Those that do not like SMTP level rejection ideas, in principal, and lean towards the "Let User Decide" philosophy. I have seen this more with those who are in DMA, ESP, Bulk Mailer software market. - Those who believe strong SMTP compliancy, transaction (online) level rejections when possible IFF (if and only if) there is a very high degree of confidence, zero-false positive and a DOMAIN publicized policy of authorization using protocols 100% designed to address the email SPOOFING problem. Remember, CAN-SPAM, my overall summarize of this LAW: It gives SPAMMERS the "god given" natural law capitalistic right to do business with user-vendor contracts as long as they follow all the EMAIL STANDARD rules properly, and you read CAN-SPAM, it indicated that it left that responsibility to the IETF to define what at the email standards for the spammers to follow and be compliant We distribute this stock/optional SMTP 220 welcome response: 220-************** WARNING: FOR AUTHORIZED USE ONLY! ********************** 220-* THIS SYSTEM DO NOT AUTHORIZE THE USE OF ITS PROPRIETARY COMPUTERS * 220-* AND COMPUTER NETWORKS TO ACCEPT, TRANSMIT, OR DISTRIBUTE UNSOLICITED * 220-* BULK E-MAIL SENT FROM THE INTERNET. THIS SYSTEM WILL RESTRICT ACCESS * 220-* TO CAN-SPAM (US S. 877) COMPLIANT CLIENTS ONLY. * 220 ************************************************************************ So as long as the anonymous sender is: - 100% Compliant with SMTP - including CBV (Callback Verification for 5321.MailFrom) - Is not restricted per SPF -ALL policies My strong long time mail system engineering opinion (covers 3 decades over several mail networks) is that a TRANSPORT software has no business in making decisions for local operation as it to relates to contain (the payload). But at the network level, the MTA IMO has some strong client/server protocol negotiations they can follow in the state machine. We tried add more rule to the above: - Is not restricted per DKIM+ADSP DISCARD policies but we screwed up the purpose and confidence in using DKIM with a strong domain policy security wrapper such as ADSP=DISCARD that we were left with just recording it with A-R and this my friends, is that I am overall worry about can happen with SPF. This series of recent threads if purely SPF theory that was long settled and my opinion, the management of the WG need to begin to steer the group in the right direction and remain focus. I must admit I am baffled by what goals are being sort. I accept the idea that accepting+marking is a viable idea for SPF - but only in my engineering opinion that it is separated from the user in some implementation own way, i.e. issue #33. I believe if we can update 2.5.4 to describe what "mark" meant, then I believe we could then avoid highlighting it as a security issue (issue #33), making it appear better for IESG review. But maybe the cat is out of the bag. Perhaps can state the current practice this include accept+mark PLUS separate among those implementations that already support accept+mark. Otherwise, the other current practice is to reject outright. -- HLS From spf2@kitterman.com Wed Sep 12 10:07:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EE021F8438 for ; Wed, 12 Sep 2012 10:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6pRZWpmh70R for ; Wed, 12 Sep 2012 10:07:26 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5334C21F86B0 for ; Wed, 12 Sep 2012 10:07:26 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 7831720E4166; Wed, 12 Sep 2012 13:07:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347469645; bh=h6np9sL+3z++EWFoSxs5KSqRlttLXZe7ECZFLSU6CzU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iBcQb1abn7psuRMRVPWz3xIHQbGp3h5piZfh9cdJZq7JbFnp2k+VyqIX3v4VqeLXg n44iG614v7qQza2r3r8qUi0YUM+9syoXyj7XWpMutTHber4XZnnDn8eBAzEEHtaco3 3+vg+YujQ3KMO2FIt1Fq4Zo1AI4Smbsp3UCAhJjM= Received: from scott-latitude-e6320.localnet (11.sub-70-192-195.myvzw.com [70.192.195.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2273420E4129; Wed, 12 Sep 2012 13:07:24 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 12 Sep 2012 13:07:23 -0400 Message-ID: <1365712.qfFrkuPjNn@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: References: <504D1416.8040400@Commerco.Net> <20120912040021.GQ86424@mx1.yitter.info> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 17:07:27 -0000 On Tuesday, September 11, 2012 11:06:02 PM Murray S. Kucherawy wrote: > On Tue, Sep 11, 2012 at 9:00 PM, Andrew Sullivan wrote: > > First, is this really a clarification? That is, does the new proposed > > text expans on or otherwise clarify what the old text said implicitly, > > as Scott argues it does? > > I think this is moot given my answer to the second: > > Second, is the new text both true and a correct use of the RFC 2119 > > keyword? It seems to me that in the new proposed text, it isn't a > > 2119 MUST at all. It's really just stating an entailment. It could > > be as correctly phrased as "if senders ... 'want to support receivers > > making negative authorization determinations, it is necessary for them > > to publish records that end in -all'". If I understand correctly, > > this is a fact about how the protocol works, and not actually a > > normative requirement for interoperation. What have I missed? > > My understanding is that your proposed wording here is more > appropriate for a protocol document (a "technical specification" in > RFC2026 terms), but the MUST might be appropriate in an applicability > statement. Since RFC4408bis is the former and not the latter, I'm > inclined to go with the non-2119 version. > > I don't know if it's possible to have one document be both of those > things at the same time, but I don't think I've ever seen one. > > For those unfamiliar: An applicability statement is a proposed > standard document that explains how to use a protocol to achieve a > particular goal that wasn't described in the protocol itself, such as > a novel application or innovation. RFC2119 language is use a bit > differently there, to mean "To achieve your goal, you have to take > these steps to make the protocol afford you this additional > capability." A recent example is RFC6647, which is an applicability > statement about how to apply SMTP to achieve what's commonly known as > "greylisting". I confess to some confusion about how these different types of documents are supposed to work, so I probably got it wrong. If I understand your message correctly, a protocol document should only use 2119 words for protocol elements. An applicability statement should use 2119 words about how to use a technology to achieve a specific goal for the cases of things that are not described in the protocol document. >From that, I draw the conclusion that one can say "If you want X you MUST Y using Z protocol" in a that is NOT the document that defines Z, but you can't use the same MUST in the document that defines protocol Z? That may be correct, but it seems completely counter intuitive. Is that correct? Scott K From spf2@kitterman.com Wed Sep 12 10:12:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7121A21F8564 for ; Wed, 12 Sep 2012 10:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Sk6zUaoixso for ; Wed, 12 Sep 2012 10:12:57 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA1C21F84E6 for ; Wed, 12 Sep 2012 10:12:57 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0BC7820E4166; Wed, 12 Sep 2012 13:12:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347469977; bh=2WYTKvGaKfAylXG8dK0N289nHNYlVdBFmiSAcvG9FDw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=D4FjGbrUWHRyoPnjQXpJEm3yeF+wN/OeGkXOg3zeRG6mfN7obCwziBlQf69qVUnkW 42kuvYJDuxbJzha0UixbTMEpXYWvbs8vtEfCcvCaOl6olZ5kWyQWKlL1/co/2D3XDH /b6sFtPnlxAcqNsIEmv1xQbccJn9COStiZt3tpI0= Received: from scott-latitude-e6320.localnet (11.sub-70-192-195.myvzw.com [70.192.195.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 993BD20E4129; Wed, 12 Sep 2012 13:12:56 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 12 Sep 2012 13:12:54 -0400 Message-ID: <1924128.DNM6QYPug7@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20120911214905.09388488@elandnews.com> References: <064.8a6275919aba4fa5f4f9c983ff6041f6@tools.ietf.org> <6.2.5.6.2.20120911214905.09388488@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #60: Section 2.3 - Publishing Authorization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 17:12:58 -0000 On Tuesday, September 11, 2012 09:53:06 PM S Moonesamy wrote: > At 16:16 11-09-2012, spfbis issue tracker wrote: > >#60: Section 2.3 - Publishing Authorization > > > > Message posted by Scott Kitterman on 11 Sept 2012: > > > > I don't understand why you want to revert the Section 2.3 changes? > > > > Those changes were not primarily made in response to issue #33. They > > were > > made because of comments that in RFC 4408 the specification RECOMMENDS > > something without a rationale for the recommendation. Given the lack of > > rationale, it's hard to know what might be an exceptional case for not > > following the recommendation. > > > > The change is also made because of operational experience gained since > > RFC > > 4408 was published. At the time RFC 4408 was published, it was > > envisioned > > that there would be a transition to a paradigm where most organizations > > published -all SPF records. This didn't happen. The revised text gives > > some guidance on the implications of not following the recommendation. > > Since it is > > common for large entities to ignore it, I think that is important. > > That's > > more true now than I would have envisioned when RFC 4408 was being > > developed. > > > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02772.html > > I am including the message from Andrew Sullivan below. > > At 21:00 11-09-2012, Andrew Sullivan wrote: > >It seems that these two mails talk past each other. Scott's point, as > >I read him, is that the 4408 text just says "you probably want to use > >these records", and the new proposed text says "if you want to achieve > >something, then you MUST do some other thing". > > Here's a pointer to the message from Scott Kitterman > http://www.ietf.org/mail-archive/web/spfbis/current/msg02781.html > > >Now, there are two questions here, both relevant to the WG. > > > >First, is this really a clarification? That is, does the new proposed > >text expans on or otherwise clarify what the old text said implicitly, > >as Scott argues it does? > > > >Second, is the new text both true and a correct use of the RFC 2119 > >keyword? It seems to me that in the new proposed text, it isn't a > >2119 MUST at all. It's really just stating an entailment. It could > >be as correctly phrased as "if senders ... 'want to support receivers > >making negative authorization determinations, it is necessary for them > >to publish records that end in -all'". If I understand correctly, > >this is a fact about how the protocol works, and not actually a > >normative requirement for interoperation. What have I missed? Andrew's understanding of my intent is largely correct. Part of what was implicit in RFC 4408 was an assumption that SPF record publishers would have as a goal to allow receivers to (as I put it) make negative authorization determinations. Since then (and if you look at the paucity of non-financial institution/high value phishing target domains with -all SPF records it's pretty clear this is the case) the operational use evolved differently. Some senders have this goal and some don't. So my goal wasn't 100% clarification, it was also to update the recommendation to match operational lessons learned since RFC 4408 was written. I believe such non-protocol impacting changes are well within our scope. I sent a separate message regarding the use of MUST, so if you want to talk about point, 2 above, I think it would be better to reply to that one. Scott K From spf2@kitterman.com Wed Sep 12 10:23:56 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28DE21F858F for ; Wed, 12 Sep 2012 10:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trsBgR5ZpP76 for ; Wed, 12 Sep 2012 10:23:54 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9D621F8587 for ; Wed, 12 Sep 2012 10:23:53 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id F242520E4166; Wed, 12 Sep 2012 13:23:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347470633; bh=+DvElWjz5IYIMDmDiQYlJ7m4iSG8oPtzlIbvEJCUXz4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cM9oKtjCFW2sTFlfC4pPkcTq8GyArOoy4tD6zZ9165hfXeniuASNpqpwUtz5XZVJU Rm3D0ia2xs2q8fat+MgmTBu/5OBimeC/SpDGsKd8Zytt7sPUqtM5NZB06G5TRAZTar zDIPHWuDP0Jyg/ki4m8Xf3MrS+57moCd9tredlUE= Received: from scott-latitude-e6320.localnet (11.sub-70-192-195.myvzw.com [70.192.195.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id AA53F20E4129; Wed, 12 Sep 2012 13:23:52 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 12 Sep 2012 13:23:47 -0400 Message-ID: <2021259.9RpgTNt1nV@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF0118524A@XCHANGE.rvl.internal> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185203@XCHANGE.rvl.internal> <0D2A0D5F64179F4F9556D3DEDE39F9AF0118524A@XCHANGE.rvl.internal> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] FW: Secetion 4.6.4 DNS Lookup Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 17:23:57 -0000 On Wednesday, September 12, 2012 04:01:00 PM Wayne Doust wrote: > > Off the top of my head I don't see anything syntactically wrong with > > the third and fifth ones. They should get processed and then fail of > their own accord. > > Third one has whitespace where it shouldn't be. You're right about the > 5th one. I'll have to look closer at why it threw a permerror. > > Back on topic: > > The point of the proposed text is to make it clear to implementers that > whilst pre-processing for syntax errors may be valid, pre-processing for > DNS lookups is definitely not valid. > > Agree / Disagree ? > > The example I have given is a real (if bizarre) one. However this could > more commonly occur with include: statements. In the double "all" case, it's not an error, because terms to the right of the all don't get processed (except "exp"), so there's no case where the extra lookups can get triggered. While I think consistency demands raising an error if there are too many lookups in a record, I agree it should not be required to follow includes: to find out if there are too many (it would be distinctly odd to do a DNS lookup as part of the protocol meant to minimize DNS lookups). Fundamentally a record that causes a permerror has an error and I think that it should be detected. As a matter of efficiency and limiting impacts to DNS, I don't take it as far as following include:. I think that the current language is fine. Even in the Wayne's case once the implementor read RFC 4408 and decided they should do what RFC 4408 said, rather than trying to be smarter than RFC 4408, they got to a consistent result. The problem here was not that the spec was vague, but that the implementer didn't like/agree with what it said. Those kinds of problems we'll never solve. Scott K From superuser@gmail.com Wed Sep 12 10:38:33 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D63A21F846A for ; Wed, 12 Sep 2012 10:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLspTHa3iPO5 for ; Wed, 12 Sep 2012 10:38:33 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A3ADD21F844B for ; Wed, 12 Sep 2012 10:38:32 -0700 (PDT) Received: by lahm15 with SMTP id m15so1397856lah.31 for ; Wed, 12 Sep 2012 10:38: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=nLAgE4NA09bIWAWjAohvDKAlA/ViIaqgtYm2QMmhHXE=; b=HbQKtHpgZZJhvWdS0cDZVXrcz89KsUNbZrlhSAGGrzTJG0dPpIMVwo5SDQY6oN6Vtc 34OAbLKj8JoDyvolQut49NU7neawSflCVRyn3WtQbBvCwwoYFWlHgYtkS3CB8K/oKqnJ BBxncR6mSnjcevEo1tEa15kOgr268YlCQuzmyfBqQUY8d+vqM3F5VgKTsSsxdFqquhkH 4FDHo6eYTVlmFWs5xDHi8vA9kFGiXuz3wyxGNHhaH0j5D0QhLlX3/JmvakfbNW/n0TWL LyVNpXIwjC8XLrollFbkMCNKN/luJ4owBoDXK3pa2WzYXmIjOX8J28UDNlrT80Ixeu7P OPSQ== MIME-Version: 1.0 Received: by 10.112.30.34 with SMTP id p2mr7749186lbh.85.1347471511401; Wed, 12 Sep 2012 10:38:31 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Wed, 12 Sep 2012 10:38:31 -0700 (PDT) In-Reply-To: <1365712.qfFrkuPjNn@scott-latitude-e6320> References: <504D1416.8040400@Commerco.Net> <20120912040021.GQ86424@mx1.yitter.info> <1365712.qfFrkuPjNn@scott-latitude-e6320> Date: Wed, 12 Sep 2012 10:38:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 17:38:33 -0000 On Wed, Sep 12, 2012 at 10:07 AM, Scott Kitterman wrote: > I confess to some confusion about how these different types of documents are > supposed to work, so I probably got it wrong. > > If I understand your message correctly, a protocol document should only use > 2119 words for protocol elements. An applicability statement should use 2119 > words about how to use a technology to achieve a specific goal for the cases of > things that are not described in the protocol document. > > From that, I draw the conclusion that one can say "If you want X you MUST Y > using Z protocol" in a that is NOT the document that defines Z, but you can't > use the same MUST in the document that defines protocol Z? > > That may be correct, but it seems completely counter intuitive. > > Is that correct? The short answer is "yes". See: http://tools.ietf.org/html/rfc2026#section-3.2 However, RFC2026 doesn't explain the appropriate use of RFC2119 language in an AS (obviously; note the order of the numbers). I base that part of what I said on precedent (e.g., RFC6647). Anyone with more grey in the beard than me want to clarify? -MSK From hsantos@isdg.net Wed Sep 12 10:44:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B090421F8697 for ; Wed, 12 Sep 2012 10:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.773 X-Spam-Level: X-Spam-Status: No, score=-101.773 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGhhGwaA1ehv for ; Wed, 12 Sep 2012 10:44:22 -0700 (PDT) Received: from groups.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B8B3221F8687 for ; Wed, 12 Sep 2012 10:44:21 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3576; t=1347471850; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=8TFM7KDDzBZCbH5kYrVGUYPbVzk=; b=GgsjIjjmj/hKGyZrxs/s Uf9NcJwKav7AyuWNyc5X38ccaomk4/HzKhAlBqc0vmzeaBwZW7JqixKkRCiezEfL fiP8KZQg63YWe9bCUPA0Mi5JH5jFveYJtxJOENa5y309/ov4ic2wyZXq8OBsLlSu v3W+u9hmnNEHqHhFljGF0jc= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 13: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 opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3493627548.6316.5492; Wed, 12 Sep 2012 13:44:09 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3576; t=1347471625; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=rFYlOOZ /ESk7K/3tChnI4Y4KKsb0/dY/wsVgwS6EVdk=; b=y0tAJraLLvVCao5xJlCmg05 6BHh2VDrze2lwq7nFz95OwS66Mn8uQpajZVKwdGcT7GlrJqLWuhwZ6kBgYtVKI6e w82Hd6GRVw1uYo1jwme722eBr/EqIe/vlt+lsTIp23wSGL/rQtnhpvu1z/Wgxx+E eHdegF+Ccw3zzxuJ8tNk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 13:40:25 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4092423474.9.3356; Wed, 12 Sep 2012 13:40:24 -0400 Message-ID: <5050CA17.1070602@isdg.net> Date: Wed, 12 Sep 2012 13:44:55 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <504D1416.8040400@Commerco.Net> <20120912040021.GQ86424@mx1.yitter.info> <1365712.qfFrkuPjNn@scott-latitude-e6320> In-Reply-To: <1365712.qfFrkuPjNn@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #33: Marked Failed Mail Exposure X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 17:44:22 -0000 Scott Kitterman wrote: >> capability." A recent example is RFC6647, which is an applicability >> statement about how to apply SMTP to achieve what's commonly known as >> "greylisting". > > I confess to some confusion about how these different types of documents are > supposed to work, so I probably got it wrong. > > If I understand your message correctly, a protocol document should only use > 2119 words for protocol elements. An applicability statement should use 2119 > words about how to use a technology to achieve a specific goal for the cases of > things that are not described in the protocol document. Keep in my that RFC6647 is not a document that is agreed upon by all, only by those that happen to be part of the review/WG. Thats fine, but there are many issues with it and in my view, missed out on some real current practices. So I don't think its a good idea to begin judging this document with others that do not represent wide spread of engineering writing experiences and technical writing styles. >From that, I draw the conclusion that one can say "If you want X you MUST Y > using Z protocol" in a that is NOT the document that defines Z, but you can't > use the same MUST in the document that defines protocol Z? > > That may be correct, but it seems completely counter intuitive. > > Is that correct? Scott, you have functional specs (what we want) and the technical specs (how its done). The beauty of the RFC format (and sometimes its curse), is it is often a MERGE of the two disciplines. Some can do it better than others, but it takes real experience of BOTH to do cater properly to all the proper audiences. If people what to argue "2119" language, that is only to be able to throw the book on people, and yes, does help the designer with "IF TO ADD, NOT ADD" decisions to make. But lets not play down the intelligence of people: CAN MARK OR REJECT is pretty clear to ANY software developer as far as what an API can offer and also pretty to the operators to run. It could of been written: SOFTWARE MUST provide two options: - REJECT - ACCEPT + MARK Instead, the above (the way 4408 has it) allows it be read: SOFTWARE should provide one of two options or both: - REJECT - ACCEPT + MARK We naturally, without thinking much about, only did a REJECT option because that was the fundamental idea that the entire SPF era along with SUBMITTER, PRA, SENDERID was dealing with (for the -ALL policy). Without a doubt, for an ESP that was service free email accounts, like GMAIL, YAHOO and others, of course, they has user-based concepts and foremost they did great jobs in presenting frontends with SPAM folders. The question is for the ACCEPT+MARK implementators: Did a SPF -ALL fail become one of the RULES to move the failed message to the ESP SPAM folder? According to my gmail testing, using a facebookmail.com spoof transaction, it did move the mail into my gmail account spam folder. The question for SPFBIS is really two options: 1) Do you present the ACCEPT+MARK PLUS SEPARATION as a recommended insight in section 2.5.4 (ISSUE #29) 2) Do you say nothing in 2.5.4 and present as a precautionary security note (ISSUE #33). It has nothing to with with LOCAL POLICY. It is the SPF specification that MUST cover the entire scope, and when it comes to security related things, it is a no brainer. You don't need 5321 to tell you about it or any other document - security is security. Either we see it or we don't. -- HLS From spf2@kitterman.com Wed Sep 12 10:57:02 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13DD21F85AD for ; Wed, 12 Sep 2012 10:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JP9Qit9jPQEB for ; Wed, 12 Sep 2012 10:57:02 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 020E521F85B8 for ; Wed, 12 Sep 2012 10:57:01 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E2A1520E4166; Wed, 12 Sep 2012 13:56:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347472618; bh=lfudlYG0h3+OHeuSVg/mNYxk6K+SgCFvFOmHsROCTM8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VzyP3htPI20xXDU8C8qUxL96h2UlQR687m3R5Nf4+yas7EoCFV/OQqdtOKrA+051E GAFNF+aCinDPtA8SQGZUEBvxGuxw8ag9ElsiEhP8eLhdx4S0qeKQ84uR4086J6/kVG jASZ9LJ5A0M4TdfvywRYcBd3ZGUMi8Mx0zIUMb3Q= Received: from scott-latitude-e6320.localnet (11.sub-70-192-195.myvzw.com [70.192.195.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 304C720E4129; Wed, 12 Sep 2012 13:56:57 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 12 Sep 2012 13:56:55 -0400 Message-ID: <1724450.r6cHBnbWLS@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: References: <20120912011024.20846.qmail@joyce.lan> <1469933.kpSdRM44Gj@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 17:57:03 -0000 On Tuesday, September 11, 2012 10:54:46 PM Murray S. Kucherawy wrote: > On Tue, Sep 11, 2012 at 7:40 PM, Scott Kitterman wrote: > > I'm fine with not saying MUST NOT for that reason. OTOH, SHOULD NOT > > stamps it a generally a bad idea (which I think is reasonable), but says > > go ahead if you think you know better. I believe that's consistent with > > what you say you want. > > The debate, then, is about whether RFC2119 language can be used to > describe an operational practice (in this case, local policy) that > isn't part of the protocol proper. I believe the answer is "no". > Perhaps one of the co-chairs or an AD should weigh in on that point. > > To be specific: The protocol itself works if the receiver generates > the result that the sender's published policy intended to provide. > The normative terms are available to be used such that implementers > will write something that works properly. That's interoperability. > What the receiver does with the message afterwards doesn't change the > fact that check_host() did precisely what it was supposed to do. The > protocol, at that point, is done. No MUSTard we put on what happens > after that has anything at all to do with interoperability of the > protocol itself, and thus I'd say is inappropriate for a protocol > document (but not necessarily for an applicability statement, which > this is not). > > Now, that's all true if we agree that SPF is a protocol between the > sending ADMD and the receiving MTA. Since there are people who want > this MUSTard there, they must have something else in mind. > > Hector, I believe, claimed that SPF is more of a protocol between the > sending ADMD and the MUA. I don't think that's right because the > output of check_host() is not used anywhere as a signal to the MUA, > since MUAs can't reject messages; the best they could do is apply an > annotation (another kind of "mark") or simply decline to show the > message. But we -- correctly, I believe -- shy away from making > assertions about what MUAs should do. So what's left? At best, one > could claim it's a protocol between the sending ADMD and the LDA. I > don't think LDAs typically do rejection or "marking", though, and even > if they did, the rejection would need to be in lockstep with SMTP, > otherwise there's backscatter. So I don't really know what to do with > this line of thinking. >From my POV, this is similar to the issue #33 thread, only more so. One of primary drivers for development of SPF was to reduce "Joe job" bounces. In this case, the MUSTard in play goes to achieving one of the main goals of the protocol. It's not ancillary at all. I guess I'll wait to see if there's anyone more greybeard around. Scott K From spf2@kitterman.com Wed Sep 12 11:24:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74C421F871A for ; Wed, 12 Sep 2012 11:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5l4Nuk1mNSw for ; Wed, 12 Sep 2012 11:24:47 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 43A4121F8535 for ; Wed, 12 Sep 2012 11:24:47 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8EA2520E4166; Wed, 12 Sep 2012 14:24:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347474286; bh=3oy1wfMfOwxP2mtKw4Y+FK0zoU1oWdzz1rlI+c4Uogk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EzovG8YQ2ixMFmjtxpvaBiowum6eiETwNs0uWFvitwq5QVLQuGvIQH223U/EVfnes zZkHE0Z+v1YjgWpP/ekvFUMdg9hNuxlLAWkBS5mLatCmZEKJEp50Jix9pSoShpO0FV d5v3Btdt6gKpkRLvqtIZlHkxCnkf5vqA365np4xI= Received: from scott-latitude-e6320.localnet (11.sub-70-192-195.myvzw.com [70.192.195.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 5702420E4129; Wed, 12 Sep 2012 14:24:45 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 12 Sep 2012 14:24:44 -0400 Message-ID: <6815534.9ZX5Nr1ah6@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <5050A8B3.5070301@isdg.net> References: <1347457847.27386.YahooMailClassic@web125103.mail.ne1.yahoo.com> <5050A8B3.5070301@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 18:24:48 -0000 On Wednesday, September 12, 2012 11:22:27 AM Hector Santos wrote: .... > As a result, we had FOUR PRODUCTIONS FROM MARID: > > RFC4405 > RFC4406 > RFC4407 > RFC4408 ... This is factually incorrect. MARID was closed with no documents produced (and let's not redebate it anyway). Scott K From hsantos@isdg.net Wed Sep 12 11:34:10 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FC021F8697 for ; Wed, 12 Sep 2012 11:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.083 X-Spam-Level: X-Spam-Status: No, score=-102.083 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EalmxoEaLay for ; Wed, 12 Sep 2012 11:34:09 -0700 (PDT) Received: from groups.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C770C21F866C for ; Wed, 12 Sep 2012 11:33:55 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=124954; t=1347474831; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=z0W6yH6171G448dtHpP5YLkijj0=; b=iqCOFsvQzJBzpbAoMC3/ DNCD6os+ZreTF+SIWsh9xhv0I/leRInj1QwkWmFUmtHCz5hcux82N+gHkAh2pwtM ptAE+YcR8o/ViPvjLTikW8UmFkouy6HLQ459bqWg5i/8Y7ge8JmO99qrq3o9RjMJ uA1HZpe+oZuE3uzeaECqu9w= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 14:33:51 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3496607948.6316.12; Wed, 12 Sep 2012 14:33:50 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=124954; t=1347474602; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Qew/cUg 1UVSV2grmf8A2nNL/DVEpg5S6GPvNUS77fgg=; b=a+CMVpxJgg3lPjUxYN0lrgN xKTslnWBUDt4U5C5yuP184PnXymfRL6UNjvChhhht3uVqzehDwvz092Ltzxhmy0u K3bWRYkOw4nkvdufz5FvinRv93hNuwA7xKe3QB+VfsxL871Ca3GZpwb2nztMDtzp k3G26X5uB86lEJmGz7G4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 14:30:02 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4095400020.9.6908; Wed, 12 Sep 2012 14:30:01 -0400 Message-ID: <5050D5B8.3030802@isdg.net> Date: Wed, 12 Sep 2012 14:34:32 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20120912011024.20846.qmail@joyce.lan> <1469933.kpSdRM44Gj@scott-latitude-e6320> In-Reply-To: Content-Type: multipart/mixed; boundary="------------060008000407010802090504" Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 18:34:10 -0000 This is a multi-part message in MIME format. --------------060008000407010802090504 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Murray S. Kucherawy wrote: > On Tue, Sep 11, 2012 at 7:40 PM, Scott Kitterman wrote: >> I'm fine with not saying MUST NOT for that reason. OTOH, SHOULD NOT stamps it >> a generally a bad idea (which I think is reasonable), but says go ahead if you >> think you know better. I believe that's consistent with what you say you >> want. > > The debate, then, is about whether RFC2119 language can be used to > describe an operational practice (in this case, local policy) that > isn't part of the protocol proper. I believe the answer is "no". > Perhaps one of the co-chairs or an AD should weigh in on that point. > > To be specific: The protocol itself works if the receiver generates > the result that the sender's published policy intended to provide. > The normative terms are available to be used such that implementers > will write something that works properly. That's interoperability. > What the receiver does with the message afterwards doesn't change the > fact that check_host() did precisely what it was supposed to do. The > protocol, at that point, is done. No MUSTard we put on what happens > after that has anything at all to do with interoperability of the > protocol itself, and thus I'd say is inappropriate for a protocol > document (but not necessarily for an applicability statement, which > this is not). > > Now, that's all true if we agree that SPF is a protocol between the > sending ADMD and the receiving MTA. Since there are people who want > this MUSTard there, they must have something else in mind. > > Hector, I believe, claimed that SPF is more of a protocol between the > sending ADMD and the MUA. Sorry, I don't believe I have never provided any talk of such and would never do so. But to be specific: First, I said SPF is a MTA to MDA protocol. I think the information in RFC4408 and RFC5598 will back this model than anything else. Second, I said there are different kinds of MUAs - Thin Online MUA, your browser for example - Fatter Online MUA, RFC based Offline reader using IMAP as a protocol, older school enterprises use EXCHANGE like groupware conferences methods. This can be also Native Online MUA which means they are more proprietary (i.e. Wildcat Navigiator, AOL, Prodigy, CompuServ, CCMAIL, etc). - Pure OffLine MUA, using as a store and forward protocol such as POP3. and mixed ones. IMAP has multiple streams (folders). POP3 has ONE stream (one folder). With an Online MUA, one can say the ORIGINAL centralized mail system where there was no room (storage or hardware) for a client device to do any sort of work. It was purely online. In this case, a Backend can separate the display mail into folders, i.e, "NEW MAIL" vs "SPAM FOLDER" With a pure offline MUA, with you have POP3, I stated that the separation need to be in place so that the single stream "new mail" is no lumped with an separated spam folder. It is not unconceivable that a backend will collect all new mail from all the user's folders, not just the "new mail" bin, but this would be a case where it need to look at the MARKING to skip that one message from the total collection. The main reason for this separation for the POP3 access is because one the offline reader gets it, it will need its own set of filtering to address this SPF failed issue and I stated very clearly (like in other WG with related ideas) that we can not depend on the Offline MUA to resolve it. PS: We deal with all kinds of "MUA" and the following provides an illustration of the complexity and advanced framework for multiple devices. -- HLS --------------060008000407010802090504 Content-Type: image/jpeg; name="Wildcat! RPC XML Network 7.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Wildcat! RPC XML Network 7.jpg" /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR CALUAt0DASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDtPDeh2eo+G9PvLuW/kuJoVeRzqE43Mep4 fFav/CLaZ63/AP4Mbj/4umeDv+RO0n/r2X+VblfkWKzHGRrzSqytd/aff1O+MI2Whjf8Itpn rf8A/gxuP/i6P+EW0z1v/wDwY3H/AMXWzRXP/aWN/wCf0v8AwJ/5lckexjf8Itpnrf8A/gxu P/i6P+EW0z1v/wDwY3H/AMXWzRR/aWN/5/S/8Cf+Yckexjf8Itpnrf8A/gxuP/i6P+EW0z1v /wDwY3H/AMXWzRR/aWN/5/S/8Cf+Yckexjf8Itpnrf8A/gxuP/i6P+EW0z1v/wDwY3H/AMXW zRR/aWN/5/S/8Cf+Yckexjf8Itpnrf8A/gxuP/i6P+EW0z1v/wDwY3H/AMXWzRR/aWN/5/S/ 8Cf+Yckexjf8Itpnrf8A/gxuP/i6P+EW0z1v/wDwY3H/AMXWzRR/aWN/5/S/8Cf+Yckexjf8 Itpnrf8A/gxuP/i6P+EW0z1v/wDwY3H/AMXWzRR/aWN/5/S/8Cf+Yckexjf8Itpnrf8A/gxu P/i6P+EW0z1v/wDwY3H/AMXWzRR/aWN/5/S/8Cf+Yckexjf8Itpnrf8A/gxuP/i6P+EW0z1v /wDwY3H/AMXWzRR/aWN/5/S/8Cf+Yckexjf8Itpnrf8A/gxuP/i6P+EW0z1v/wDwY3H/AMXW zRR/aWN/5/S/8Cf+Yckexjf8Itpnrf8A/gxuP/i6P+EW0z1v/wDwY3H/AMXWzRR/aWN/5/S/ 8Cf+Yckexjf8Itpnrf8A/gxuP/i6P+EW0z1v/wDwY3H/AMXWzRR/aWN/5/S/8Cf+Yckexjf8 Itpnrf8A/gxuP/i6P+EW0z1v/wDwY3H/AMXWzRR/aWN/5/S/8Cf+Yckexjf8Itpnrf8A/gxu P/i6P+EW0z1v/wDwY3H/AMXWzRR/aWN/5/S/8Cf+Yckexjf8Itpnrf8A/gxuP/i6P+EW0z1v /wDwY3H/AMXWzRR/aWN/5/S/8Cf+Yckexjf8Itpnrf8A/gxuP/i6P+EW0z1v/wDwY3H/AMXW zRR/aWN/5/S/8Cf+Yckexjf8Itpnrf8A/gxuP/i6P+EW0z1v/wDwY3H/AMXWzVHWYLi60O/g tJXiuZLd1hkRirK+07SCPfFVHMcZKSTrSX/bz/zFyR7FT/hFtM9b/wD8GNx/8XR/wi2met// AODG4/8Ai68rPi/WNU+Ffh+zsNRuB4g1DUPsJn8wiTKsSSW69CmfY06bxfq2qfDPwza2mpXE eu3upCxllVyHO0kHJBz0MefrXs/VMzW9eXxOPxS6X9700ZnzQ7HqX/CLaZ63/wD4Mbj/AOLo /wCEW0z1v/8AwY3H/wAXXnlprurG3+KGdRuidPLizJlJ8jAl+76dB+VReCvHWoah4F1rTNVn mj1uz02W6t53Y75omjLK4PqMjn3HvUSoZmoSmq8nyuKfvS+0k777K6uO8Ox6R/wi2met/wD+ DG4/+Lo/4RbTPW//APBjcf8AxdeX614k1m3+HXg25l1S/trO8ONT1GAF5lH8PzdRnn8vwrd8 DvcTeJfN0fxt/b2iNCfPgvpma5jYZwVBAIGdvJwOe/FKpSx9OjKrLES05usvsu2+yb6JgnBu 1js/+EW0z1v/APwY3H/xdH/CLaZ63/8A4Mbj/wCLrxbRNZbU73V/7b+ImpaQ0F48cEQnOGTJ 9fTpW/4t1C50b4YWd1pHi6+vxPqiqNRMxD7CrArn0BWtp4XHwqxpPEyu2l9u2qvvsJSha9j0 r/hFtM9b/wD8GNx/8XR/wi2met//AODG4/8Ai68n13UbzwvPptxoXxBudevpLpI/7PeZZxIh znhSccgD8eK67T9T1LR/jHfaLfXtxPp+qW32mxSVywjYcsq56Dh+PpWNSnj4w544iTVm1rJN 8tr6P1v8mNOO1jqv+EW0z1v/APwY3H/xdH/CLaZ63/8A4Mbj/wCLrzu613V9V1Lx7q1pqdzD puk2clraxxTEJ5wXmQY4yCp/76FYHh7UrXUNCtbvVfipqdjfSKTLb+eTsOSB+mD+NaRw2YOH PLES0tdLnbTav0v0FeHY9j/4RbTPW/8A/Bjcf/F0f8Itpnrf/wDgxuP/AIuvO/Gt5ew+KPCW kR+KrzT7G4siJ75Z/L37V4kYk4ycDr61FpOq3+k/EnSNI0vxfP4ks7xH+2JJIJRCACQ24ZA9 fw9xURo4+VJVFiZXcXK157K/XZbdR3je1j0n/hFtM9b/AP8ABjcf/F0f8Itpnrf/APgxuP8A 4utmivH/ALSxv/P6X/gT/wAzTkj2Mb/hFtM9b/8A8GNx/wDF0f8ACLaZ63//AIMbj/4utmij +0sb/wA/pf8AgT/zDkj2Mb/hFtM9b/8A8GNx/wDF0f8ACLaZ63//AIMbj/4utmij+0sb/wA/ pf8AgT/zDkj2Mb/hFtM9b/8A8GNx/wDF0f8ACLaZ63//AIMbj/4utmij+0sb/wA/pf8AgT/z Dkj2Mb/hFtM9b/8A8GNx/wDF0f8ACLaZ63//AIMbj/4utmij+0sb/wA/pf8AgT/zDkj2Mb/h FtM9b/8A8GNx/wDF0f8ACLaZ63//AIMbj/4utmij+0sb/wA/pf8AgT/zDkj2Mb/hFtM9b/8A 8GNx/wDF0f8ACLaZ63//AIMbj/4utmij+0sb/wA/pf8AgT/zDkj2Mb/hFtM9b/8A8GNx/wDF 0f8ACLaZ63//AIMbj/4utmij+0sb/wA/pf8AgT/zDkj2Mb/hFtM9b/8A8GNx/wDF0f8ACLaZ 63//AIMbj/4utmij+0sb/wA/pf8AgT/zDkj2Mb/hFtM9b/8A8GNx/wDF0f8ACLaZ63//AIMb j/4utmij+0sb/wA/pf8AgT/zDkj2Mb/hFtM9b/8A8GNx/wDF0f8ACLaZ63//AIMbj/4utmij +0sb/wA/pf8AgT/zDkj2Mb/hFtM9b/8A8GNx/wDF0f8ACLaZ63//AIMbj/4utmij+0sb/wA/ pf8AgT/zDkj2Mb/hFtM9b/8A8GNx/wDF0f8ACLaZ63//AIMbj/4utmij+0sb/wA/pf8AgT/z Dkj2Mb/hFtM9b/8A8GNx/wDF0f8ACLaZ63//AIMbj/4utmij+0sb/wA/pf8AgT/zDkj2Mb/h FtM9b/8A8GNx/wDF0f8ACLaZ63//AIMbj/4utmij+0sb/wA/pf8AgT/zDkj2Mb/hFtM9b/8A 8GNx/wDF0f8ACLaZ63//AIMbj/4utmij+0sb/wA/pf8AgT/zDkj2Mb/hFtM9b/8A8GNx/wDF 0f8ACLaZ63//AIMbj/4utmij+0sb/wA/pf8AgT/zDkj2Mb/hFtM9b/8A8GNx/wDF1g+MNLi0 bQlvtNutQtrtLu2CSi+mfbumQH5WYqeCeCCK7euW+IX/ACKZ/wCv20/9Hx11YLMcY8TTTqya uvtPv6kyhGz0N7wl4tTXIzZ3gSHVIly6Lwsy/wB9Pb1HVSe4IJ6ivB/nWSOaGV4Z4m3xSxnD I3qP8OhBIOQa9X8G+IpPEejyy3ESpdWs5tpyn3HYKrbl9AQ447HI56n9Hy3MPrMeSfxL8fM4 5wsdDRRRXqEBRRRQBw3g7/kTtJ/69l/lW5WH4O/5E7Sf+vZf5VuV+LYz/eKn+J/mejHZBRRR XMUFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU1JEcEo6s BwSDmkWWN0LrIrKOpByBTswH0UxZonICyoSwyAGHNKkiSAlHVgDjKnNFmA6iml1VlUsAzdAT yadSAKKKKACimtIiFQzqpY4AJxmlJABJOAOpNMDxnwr4L1az+LVybm0nj0Owubm8s2dT5bNK Ao2noTjH/fNO0jwbq1t8ZX820mOgWt1PqFvIUIiEkqrwp6ZB28f7Jr2RXV1DIwZT0IORS17M 87rylJtLWHL/AMH11f3mXs0eSWug6ssPxRDadcg6gz/ZMxn9/wAS/c9eo6etVvEfgjVLn4c6 BqOmW80Wvafp6200CqfMlidNroR6jJ49Ca9koqY5zWjNTilo0/W0VGz8mkP2atY8rhTxdoPg fwu9jpr3ltbw+XqmkvCvmupPYEZzyeB7ds1R0fRrrWPiZpetaZ4TufDVjZRsbl5ohD55II2h Bx3xkfj2r2Kiks2klO0EpS5lfXaV91eztfRv9A9n5nhHhiC88O3etLqfw9v9WNzevLDKbNWC rk9Cw79a2/GVvfeJ/h3aQ6f4TvNPMWrJmw+z4bYFYl9qjG0lsV65RWk85cq0a/s1zJp7u2it tewlT0tc8t8UeE7rwr4lsPFvg/Sw5VvKvtOtYx+8Q/xKoHB7HHsfWrvxM0vU76w0TxJoFnPL qum3CyxxCI+YY3HIK9eCFyPc16HvXfs3DfjO3POKdXPHNKqnTqSV5QurvrF9H97XoPkWqPNt K8L3mlfBK+0028r6peWc000QUl2lkU/Lj1A2jHqK5zwvcyaN4bstO1D4X397dQKRJcNYoS/z EjkrnoQPwr2yitI5tJqaqQvzS5t2tfk9g9ntY8u1vR7jxD498GX0ugTDTRaP9phmg3JBlThH GMAg4osdAv8AwB8Qw2jadNc+G9X4mSGIubN89eOQuT+RPpXp4kQuUDqXHVc8igOhcoGXcOSu eRU/2pU5FS5fc5XG2tt20/VN6MORbjqKKK8o0CikJABJOAOpNQ297aXZYW11DMV6+XIGx+VO zauBPRRRSAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigArlviF/yKZ/6/bT/ANHx11Nct8Qv+RTP/X7af+j4668D/vVP/EvzJl8LOOru /hX/AMgrW/8AsKt/6IhrhK7v4V/8grW/+wq3/oiGvvci/wB4l6fqjlqbHeUUUV9UYBRRRQBw 3g7/AJE7Sf8Ar2X+VblYfg7/AJE7Sf8Ar2X+Vblfi2M/3ip/if5nox2QUUUVzFBRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeGT6ofBknxJ0kfKZStxaIOn 7/5Tj6B1/wC+ao6dc3HgPwr408OXUhFwLOGeFW7GZVR8fQuB+Fdr40+G934l8faVrMD262CC Jb6NnZXkCOTwACDxgdulP8ffDm88V+LNJ1K1mhjtUCRX6sxVnjWTcMAD5jgnqewr7Klj8HJQ jUkvfSlLylDlsvnyv/wI53GWtjO8OW9noPjLwbokmlxtfDRTJ9saRw8RPmM6Bc7fvFuozz9K yvBXiv8A4RH4YX15HbfarufW5Le2g3YDSMq4z7cH/wCt1rv9Q8MX918VNJ8SRtB9htLJ7eQF jvLHfjAxjHzDvXKW/wALtX/4QCfSZLm0i1SLVTqNpICWjzgABjjI79vSsI4rCVor28vi5HLV 7802/Raq9u4+WS2/rYp6zdeIZ/id4Ij8RWFnbXCSyMj2kpdHBA455BGOeT1Fb3/Cd+J9abUr 3wtodpeaVp8xgJmlYS3LL97ywOOhHX/61Nk8MeMdd8X+Hde1r+yrdNOdt9tbuxIB6tk5ySe3 YDrUMHhPxt4aOqaT4ZuNM/srULh5oridmWa0LjB6DBwAMdenalOeEnCEZcnNGNrXfKvek313 tbr3t0D3kdDr/iHxJawafJpmk2VvHPD5txcardCOO3bGfLIByW689P1xwfiXx5revfCvUrqC GK0mtr37FezWtwduMrgxkdQ27B56c5roNe8GeIp/EWk6oBp2vpbWItpYdTOxfN5zLtCkc56Y z/OqK/DXXj4F8TaHJLp4uNQvheW7RFgh+ZSVIx8v3eOtLCfUKSpzk4tqUX1/m1vd30WuqXpu EuZ3JPE8Wq3d78O7nUrWKC6TVArxwOXUDKlTnH91M/nXoHij/kUtZ/68Z/8A0W1YTab4ovoP DMl9aaP59ndebeDc58tR8oMZ7ttLZzxk10utWcmoaFqNlCVEtxbSRIWOBuZSBn25rzMRWi3R jde63s9Pib+7sWlueU+GvGF54Y+H/gi1stOS9k1OWaHyzJsORKcAHoM7u9dLpvjDxM3ibUfD epaTp66mlibyzME7eU/OArEjPU9eOh4rMtfh5rUOl+BbZntPM0K8ea7xIcFTKGGzjk4HfFdN /wAI3ff8LT/4SXdD9h/sv7Jt3Hfv37umMYx7134qrgZSnJKLb53fXfnfL16r70TFS0+Rwngr xpqeg/DzUda1aAXdstw/kyGctNcTs+NpyOAPX0FdNonjvVv+Ei0/SfENppsf9poxtZbC4MgR wMmOQHocfh9e2HZfDbxBP4L1PwpqL6dHbrObmwukLMzS7s/MMcLjI6Z571teG/C+vR67aXeq aT4b0+2tEwwsbVGkuJMcOG2goO/BrTFvAT9rP3W25delly2+e+nk7IUedWRF4R8c+KfFk5uL fQrRdMt55IbmXzTvYquQEBIGeg54+YdOTVW6+I3iTR9QsTrOmaRBbXV0sDWcV5vvIQxIDMM4 PTt+lbPg3wfqmg+CNV0a4uIYry7luHimgYkJvQBWzgHIIzXHp8NPEp8P2WnJp3h+2msbpJzd qzGa82sTlm28DnofQdKUFl069RNRUE7LfbXW9+/l9yuHv2R1upeMdevfFN/oPhPTbK5k02NW u57yVlXcwyEXHf6n16YrmvFviPxXdnwfINJbTpLi9j32k05XzJ1fIRsfwcKcnkZrd1Dw14o0 PxjqWveFBptxHqqILm3vSylHXowI6jr+fSodY8HeLbjQdBmOpW2p65pd+LxvP+SN/RAQAcDA 68nmpw8sHTlTlHktZbt813F3v0S5v0t1B8zuEOpyf8LPuoBodqNfXQxMZxO5zJhf3WM7du7j OM1JJ8TnPgCy1u3sY5NVursWK2O84E27BX16c/iKv6d4X1hfiV/wk98bQRSaUltKkLtkTfKW wCPu5BxzWZZfDW4tviY2sGaE6Ek730NruOVuXUAnbjAGeRz2FZ82Bk17Vp8sYvd6tJ3hv1dv QfvdCTVPHutPr99pGh2mlSSaZGpu5r24MaySEZ2R9Oeo5rrPCfiODxX4cttXgjaLzcrJExyY 3U4K/wCe1cTrHgTVrTxXquraPpuh6nb6oAzRalGC1vLjl1JU5BOSR3z7V3PhnSp9G0C2s7o2 jXSgtM1pbrDGWJ7KoA9BnHOK5sdHBrDRdG19Ouu3vXXr6eV0VHmvqeP+JtR1PQPjLrPiKwRp bbT0tvt0Knl4HjVT+RwfY4Pat3S9esI/iv4n15JhLYLocdyHQ/eQLGePeurs/Clwvj3xHq14 sEmm6paxW6x7iWYBArBhjGDz3rlfDnwluNI1bxFBcXMUmj6hZSWlsd5aVFZgVyCAOPr1Fems Zg6lLlqOzVOMdOq9269YtP7/ACI5ZJ6dyWz+KOrRjTdU1bT9Mh0TUJhEogui9xAGztZ17jjs B/ivhPVPEtz8WfEcF1DC9vGYknVrgkW0e1inljvuPJHvUWjeA/EdqNO0y40zwxHa2bjzdRFq ss1zGDwu1l4bHf2/PesPDviDSvifqmr24sZNH1URmdnZhLHsTACjpnP4YrOtLBQjVjSUbuLt q+klbrva/W7srre4ubS5L8UtJ1XWfBj22kxPO6zpJPbxuVaeIZ3IPXnBx7V5/wCH5PB58a6O trY6p4S1eCUq1tKrFLkkj5CzHIBwRyBnNeo+NdA1LX9IiTR9Tk0/ULadZ4ZA7BHI/hcDqPwP SuTu/C/jPxjqmkf8JOuk2Vhp1wLgmzLNJKwxwM9Aceo9cHArPLsTTjhPZzqKK96+rTV1/Lqp p+l13Q5p810h2pfEnWHv9YbRLDTJNP0h2jmN3dbJbhl5fywOOPfP9Ksax8SrlR4Z/sDTI71t djcxLLIUKOMAA+wYnP0NZtz8Ptb0zVtYGj6Z4evrTU5zPFPqEQaSyZvvYBU5AzwPbpW7N4Kv 28Q+DrwNYmDR0mF15cYhDO68FI1GAN3PanJZbHlaSas+r19x/FrvzW7fcHvkmleLtai8XWnh 7xJp9pazXdm1xFJbOWUupOU5PoCfyrKf4pXC+H77V002J4n1L+z9KUybftB5+ds9B06e9a/x H8IXvinS7STSJ47fVbOUtDK7FRsYbXXIB7Y/KqeufDf7X8P9J0Owkt1vdKaOaF51zHI4zvDf 7LEk9PSsqLy6ahOoknJpNa2Vr3fo/dX3jfPqkSaB451CXxDJoOvW+nJevbG5tpdPnMkUgGdy nPIYYJ/yMx+BPGfiXxk1vfNo1nbaOS8c03nEyFwDjaPTlRyPWpPDnhnWk1ea/wBR0vw9pcIg aKK20+2UuXIwXMm0EDBIwD/9fU+Hnhy78K+DbXSb4wG5jeRnMJJU7nJHJA7YqMU8HCnNwjFy fKt20rqV2tfTurhHmbVzqaKKK8I1CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAK5b4hf8imf+v20/8AR8ddTXLfEL/kUz/1+2n/AKPjrrwP+9U/8S/MmXws 46u7+Ff/ACCtb/7Crf8AoiGuEru/hX/yCtb/AOwq3/oiGvvci/3iXp+qOWpsd5RRRX1RgFFF FAHlvhPW76PwnpaR+GNWnQW67ZUktQrDHUBpgfzANbP9vaj/ANClrP8A39s//j9Hg7/kTtJ/ 69l/lW5X45i6sFiJ+4t3/N39T0IrRamH/b2o/wDQpaz/AN/bP/4/R/b2o/8AQpaz/wB/bP8A +P1uVBJfWkInMt1Agt1DTFpAPKBGct6DHrWCqRe1Nf8Ak3+Y7eZlf29qP/Qpaz/39s//AI/R /b2o/wDQpaz/AN/bP/4/WpLf2dvv867gj2R+a2+QDamcbjnoPeqjeI9DW1S6bWdOFu7FFlN0 mxmHUA5wTVp821Jf+Tf5h8yt/b2o/wDQpaz/AN/bP/4/R/b2o/8AQpaz/wB/bP8A+P1qWWoW WpQGexu7e6hDbTJBIHXPpkHrzViodSMXZ01/5N/mFvMw/wC3tR/6FLWf+/tn/wDH6gn8VXVt NawzeFtZWS6lMMI8y0O9wjORxPx8qMefT1xXR1h69/yGPDH/AGE3/wDSS5rSlOnOVnTWzf2u ib7g7rqH9vaj/wBClrP/AH9s/wD4/R/b2o/9ClrP/f2z/wDj9blRtPCk6QNKgmkUskZYbmAx kgdwMjP1FZqrF7U1/wCTf5hbzMf+3tR/6FLWf+/tn/8AH6P7e1H/AKFLWf8Av7Z//H6tXPiL RLOXyrrWNPgk5+SW6RTwSDwT6gj6g1ZtdRsb4sLO8t7goqswhlV8KwypOD0I5HrVt2XM6St/ 29/mHzMz+3tR/wChS1n/AL+2f/x+j+3tR/6FLWf+/tn/APH61La+s70ZtbuCcbQ/7qQN8pJA PHbKsPqp9KsVDqRTs6a/8m/zC3mc1f8Ai240yze7vPC+sxwIVDNvtDgswUcCfPUirP8Ab2o/ 9ClrP/f2z/8Aj9QeO/8AkT7v/rrB/wCjkro61lKmqUZ8iu219rol5+Ya3tcw/wC3tR/6FLWf +/tn/wDH6P7e1H/oUtZ/7+2f/wAfrcqhHrekzXrWUWqWT3auUMC3CFwwzkbc5yMHj2rOM1K9 qSdv8X+YfMpf29qP/Qpaz/39s/8A4/R/b2o/9ClrP/f2z/8Aj9agv7NreO4W7gMEp2xyCQbX PoDnB6GobLWtK1OQx2Gp2d26jcVgnWQgcc4B9x+dPm0b9ktP8X+YfMo/29qP/Qpaz/39s/8A 4/R/b2o/9ClrP/f2z/8Aj9blFR7aH/Ptf+Tf/JDt5nN2PjGLULCC8g0XWTDPGJEP2UHKkZHR sVY/4SX/AKgms/8AgL/9em+CP+RE0D/sHw/+gCt6ta7owqygobNrcSu0Yf8Awkv/AFBNZ/8A AX/69H/CS/8AUE1n/wABf/r1syzRQRGWaRI4x1Z2AA7dTSS3EELBZZo42KlgHYDIHU/Qd6zU qb2h+LDXuY//AAkv/UE1n/wF/wDr0f8ACS/9QTWf/AX/AOvWxBPDcwrNbypLE4yrxsGVvoRU lDnTWjh+LCz7mH/wkv8A1BNZ/wDAX/69UP8AhY3hyO4mtru4ubS6hbbJBNaybl4B/hBHf1rq 68e1a1Fx4n15lfy547/McgGSp8mLg+oPcf8A1jXdgaGHxMpRmmrK+j80uqZMm4ncf8LG8K/9 BJ//AAEm/wDiKP8AhY3hX/oJP/4CTf8AxFcLa3RmLRSp5dzH99M5GOzA9wfX+tWa7XlmFTs1 L71/8iTzyOx/4WN4V/6CT/8AgJN/8RR/wsbwr/0En/8AASb/AOIrjqKn+zcL/e+9f/IhzyOx /wCFjeFf+gk//gJN/wDEUf8ACxvCv/QSf/wEm/8AiK46ij+zcL/e+9f/ACIc8jsf+FjeFf8A oJP/AOAk3/xFH/CxvCv/AEEn/wDASb/4iuOoo/s3C/3vvX/yIc8jsf8AhY3hX/oJP/4CTf8A xFH/AAsbwr/0En/8BJv/AIiuOoo/s3C/3vvX/wAiHPI7H/hY3hX/AKCT/wDgJN/8RR/wsbwr /wBBJ/8AwEm/+IrjqKP7Nwv9771/8iHPI7H/AIWN4V/6CT/+Ak3/AMRR/wALG8K/9BJ//ASb /wCIrjqKP7Nwv9771/8AIhzyOx/4WN4V/wCgk/8A4CTf/EUf8LG8K/8AQSf/AMBJv/iK46ij +zcL/e+9f/IhzyOx/wCFjeFf+gk//gJN/wDEUf8ACxvCv/QSf/wEm/8AiK46ij+zcL/e+9f/ ACIc8jsf+FjeFf8AoJP/AOAk3/xFH/CxvCv/AEEn/wDASb/4iuOoo/s3C/3vvX/yIc8jsf8A hY3hX/oJP/4CTf8AxFH/AAsbwr/0En/8BJv/AIiuOoo/s3C/3vvX/wAiHPI7H/hY3hX/AKCT /wDgJN/8RR/wsbwr/wBBJ/8AwEm/+IrjqKP7Nwv9771/8iHPI7H/AIWN4V/6CT/+Ak3/AMRR /wALG8K/9BJ//ASb/wCIrjqKP7Nwv9771/8AIhzyOx/4WN4V/wCgk/8A4CTf/EUf8LG8K/8A QSf/AMBJv/iK46ij+zcL/e+9f/IhzyOx/wCFjeFf+gk//gJN/wDEUf8ACxvCv/QSf/wEm/8A iK46ij+zcL/e+9f/ACIc8jsf+FjeFf8AoJP/AOAk3/xFH/CxvCv/AEEn/wDASb/4iuOoo/s3 C/3vvX/yIc8jsf8AhY3hX/oJP/4CTf8AxFH/AAsbwr/0En/8BJv/AIiuOoo/s3C/3vvX/wAi HPI7H/hY3hX/AKCT/wDgJN/8RR/wsbwr/wBBJ/8AwEm/+IrjqKP7Nwv9771/8iHPI7H/AIWN 4V/6CT/+Ak3/AMRR/wALG8K/9BJ//ASb/wCIrjqKP7Nwv9771/8AIhzyOx/4WN4V/wCgk/8A 4CTf/EUf8LG8K/8AQSf/AMBJv/iK46ij+zcL/e+9f/IhzyOx/wCFjeFf+gk//gJN/wDEUf8A CxvCv/QSf/wEm/8AiK46ij+zcL/e+9f/ACIc8jsf+FjeFf8AoJP/AOAk3/xFH/CxvCv/AEEn /wDASb/4iuOoo/s3C/3vvX/yIc8jsf8AhY3hX/oJP/4CTf8AxFH/AAsbwr/0En/8BJv/AIiu Ooo/s3C/3vvX/wAiHPI7H/hY3hX/AKCT/wDgJN/8RR/wsbwr/wBBJ/8AwEm/+IrjqKP7Nwv9 771/8iHPI7H/AIWN4V/6CT/+Ak3/AMRR/wALG8K/9BJ//ASb/wCIrjqKP7Nwv9771/8AIhzy Ox/4WN4V/wCgk/8A4CTf/EUf8LG8K/8AQSf/AMBJv/iK46ij+zcL/e+9f/IhzyOx/wCFjeFf +gk//gJN/wDEVgeMfGmgatoAtLK+aSZru2fBt5EGFmRmJLKAAACeTWbSMoZSrAEEYIPetKWC w1KpGpFSunfdf/Iicm1YWu7+Ff8AyCtb/wCwq3/oiGvNFY6WwRyTYk4Vz/yx9j/s+h7fTp6X 8K/+QVrf/YVb/wBEQ19LkkbYh9rfqjGpsd5RRRX1BiFFFFAHDeDv+RO0n/r2X+VblYfg7/kT tJ/69l/lW5X4tjP94qf4n+Z6MdkFcpr2nT3PiW0gS2eWy1JES8kCZWMQOZFDH/b3FfeuroqK NZ0pcy/rt9zs/kNq559baZfrBDdXtpPIun30FtJGImZpreBHVZAuMt+8ffx2XIzWxqbjVPD/ AIlex0u4Qz2LxpK8LI90/lMAAhAbjIAOOc4HSuporonjXKSk1qvu3T/T+tBcpFbArawggghF BB7cVLRRXE3d3KCsPXv+Qx4Y/wCwm/8A6SXNblYevf8AIY8Mf9hN/wD0kua2w/xv0l/6SyXs blc5rdhe3ninR3tLm4tFjtroPcQxK4XJhwp3KQM4Pvwa6OippVXSlzLz/FWG1c4X+zL9NGso HiuJ5o/EXnO7RYZk+0MfMIAAAI5yBjmi+stTtfE+qahY20++9mWy8xEPyq8EW2b3VHU5/wB4 13VFdSx8k2+Va3/Fp/oTynBeGNvhq5nhubHUIoDbiOHyrGaUYW5ujj5FOPldDz2YV3tFFYYm v7ebqNavcaVlY5zx3/yJ93/11g/9HJXR1znjv/kT7v8A66wf+jkro6cv92h/il+UQ6hXG6Vo OoXYnF5crDZJrE12lu1piQlbhnQhy3QkA8LyD15rsqKilXlSi1Hrb8BtXPN9O0PV4fCugiW4 v28u4UvYtboBEMtycLvwPc962vC+g3407w9dapdqWsbNBDbra+U8bNEFKuSxJwMjGByMnpXX UV01cwqVFJWSu29l1v5ee+5KgkFFFFcBZg+CP+RE0D/sHw/+gCt6sHwR/wAiJoH/AGD4f/QB W9XRiv48/V/mTHZFbULKHUtOubG4BMNxE0T464Ixx71xNzDqOraPe3V/bXC3FtHFYD90WO4S oZ51THzrwpx0YRkdDXf0U6GJdHZX1T/z+/qDVznvCMTxWmoEs0qSXrSRzmEwiYFEO4J2Gcrx 125710NFFZVantJufcaVgrya8/5GjxB/1/f+0Y69Zrya8/5GfxB/1/f+0Y69PKfin6fqiKnQ qz2f22+0yFZWgklvYYBMgG5FdwrYzx0PQ8dK9A/4Van/AEMWo/8AfqH/AOIriYP+Q1ov/YTt f/Rq17tX3uT0KVXDt1Ip69V6HLUbT0PP/wDhVqf9DFqP/fqH/wCIo/4Van/Qxaj/AN+of/iK 9Aor1fqWG/59r7kZ8z7nn/8Awq1P+hi1H/v1D/8AEUf8KtT/AKGLUf8Av1D/APEV6BRR9Sw3 /Ptfcg5n3PP/APhVqf8AQxaj/wB+of8A4ij/AIVan/Qxaj/36h/+Ir0Cij6lhv8An2vuQcz7 nn//AAq1P+hi1H/v1D/8RR/wq1P+hi1H/v1D/wDEV6BWbqmu6do+xbu4xNJ/qreNTJLL/uou WP1xgd8UnhMLFXcI29EPml3OR/4Van/Qxaj/AN+of/iKP+FWp/0MWo/9+of/AIitOW+17WOE /wCJLZn/AHZLpx+qR/8Aj59waiisNR0s+ZpGqTnu9tqEj3Ech7ncx3oT6g477TXg1c4yanVV Kyfmo3S+f+VzRU6jVyj/AMKtT/oYtR/79Q//ABFH/CrU/wChi1H/AL9Q/wDxFb9r4ttllS21 mBtKuWIVTMwaCQ+iS9DnsG2sf7tdDXtUqGCrQU6cYtPqkjNuS0Z5/wD8KtT/AKGLUf8Av1D/ APEUf8KtT/oYtR/79Q//ABFegUVr9Sw3/Ptfchcz7nn/APwq1P8AoYtR/wC/UP8A8RR/wq1P +hi1H/v1D/8AEV6BRR9Sw3/Ptfcg5n3PP/8AhVqf9DFqP/fqH/4ij/hVqf8AQxaj/wB+of8A 4ivQKKPqWG/59r7kHM+55/8A8KtT/oYtR/79Q/8AxFH/AAq1P+hi1H/v1D/8RXoFFH1LDf8A Ptfcg5n3PP8A/hVqf9DFqP8A36h/+Io/4Van/Qxaj/36h/8AiK9Aoo+pYb/n2vuQcz7nn/8A wq1P+hi1H/v1D/8AEUf8KtT/AKGLUf8Av1D/APEV6BRR9Sw3/Ptfcg5n3PP/APhVqf8AQxaj /wB+of8A4ij/AIVan/Qxaj/36h/+Ir0Cij6lhv8An2vuQcz7nn//AAq1P+hi1H/v1D/8RR/w q1P+hi1H/v1D/wDEV6BRR9Sw3/Ptfcg5n3PP/wDhVqf9DFqP/fqH/wCIo/4Van/Qxaj/AN+o f/iK9Aoo+pYb/n2vuQcz7nn/APwq1P8AoYtR/wC/UP8A8RR/wq1P+hi1H/v1D/8AEV6BRR9S w3/Ptfcg5n3PP/8AhVqf9DFqP/fqH/4ij/hVqf8AQxaj/wB+of8A4ivQKKPqWG/59r7kHM+5 5/8A8KtT/oYtR/79Q/8AxFH/AAq1P+hi1H/v1D/8RXoFFH1LDf8APtfcg5n3PP8A/hVqf9DF qP8A36h/+Io/4Van/Qxaj/36h/8AiK9Aoo+pYb/n2vuQcz7nn/8Awq1P+hi1H/v1D/8AEUf8 KtT/AKGLUf8Av1D/APEV0+peJ7DT7lrOIS32oAZ+x2gDuuem85Cxj3cgVkSprOs/8hG7+wWp /wCXOwkIdh/tzcN+CBcerCvNx+JyzAr98o37JJv7v8y4xnLYyI/hzZTXMttF4ru3nhx5sSrA WTPTI25Gfep/+FWp/wBDFqP/AH6h/wDiKvN4b0jyYo4bJLZocmKW2zFJGT1IdcHJ788981NF qOu6RxMv9s2Y/iULHdIPccJJ+Gw+xNeZgs7yrES5KlNQfmlb7+nz+8uVKa2dzL/4Van/AEMW o/8AfqH/AOIo/wCFWp/0MWo/9+of/iK7DS9c07WVf7Fch5I+JYXUpLEfR0bDL+IrQr6RYPCt XUI/cjLml3PP/wDhVqf9DFqP/fqH/wCIo/4Van/Qxaj/AN+of/iK9Aop/UsN/wA+19yFzPue f/8ACrU/6GLUf+/UP/xFH/CrU/6GLUf+/UP/AMRXoFFH1LDf8+19yDmfc8//AOFWp/0MWo/9 +of/AIij/hVqf9DFqP8A36h/+Ir0Cij6lhv+fa+5BzPuef8A/CrU/wChi1H/AL9Q/wDxFH/C rU/6GLUf+/UP/wARXoFFH1LDf8+19yDmfc8+b4WRspVvEOoEEYIMMPP/AI5XReEfClt4P0qa wtbq4uVmnM7PPjOSqrgYAAACDFb9FaU6FKk7wil6IG29wooorUQUUUUAeL6rY+K/B9xFpsev yLpp+Wxl+yRMCo52MSv3wPzAyO4FT+2PFX/QyP8A+AcP/wATXtOo6daatYS2V7CJbeUYZTx9 CD1BB5BHINeQ67oV/wCHL3yJorm7tW5guYYGkLD0cIDtYfkeo7gfMZllKjJ1aNNNPdcqb/I2 hU6NlT+2PFX/AEMj/wDgHD/8TR/bHir/AKGR/wDwDh/+Jqt5z/8APlqP/gDN/wDE0ec//Plq P/gDN/8AE15H1Kp/z5X/AIAv8jTmXcs/2x4q/wChkf8A8A4f/iaP7Y8Vf9DI/wD4Bw//ABNV vOf/AJ8tR/8AAGb/AOJo85/+fLUf/AGb/wCJo+pVP+fK/wDAF/kHMu5Z/tjxV/0Mj/8AgHD/ APE0f2x4q/6GR/8AwDh/+Jqt5z/8+Wo/+AM3/wATR5z/APPlqP8A4Azf/E0fUqn/AD5X/gC/ yDmXcs/2x4q/6GR//AOH/wCJqlqN74quPs1wmvmS4s5TPArWsSjdsZDyF/uuw5yOak85/wDn y1H/AMAZv/iaPOf/AJ8tR/8AAGb/AOJqo4SrF3VH/wAkX+QuZdxbTxH4mvIfMj8Sygg7XRrK EMjDqpG3g1Y/tjxV/wBDI/8A4Bw//E1kXcVws322ysr8XIGHQ2MwWZR2PycH0Pb6VbiuXkiV zp+poWGSrWE2R7H5acsDPeNFf+AL/IObzLn9seKv+hkf/wAA4f8A4mj+2PFX/QyP/wCAcP8A 8TVbzn/58tR/8AZv/iaPOf8A58tR/wDAGb/4mo+pVP8Anyv/AABf5D5l3LP9seKv+hkf/wAA 4f8A4mj+2PFX/QyP/wCAcP8A8TVbzn/58tR/8AZv/iaPOf8A58tR/wDAGb/4mj6lU/58r/wB f5BzLuN1OfxHqunyWdz4idonKnH2OIcqwYdAD1Aos/EniucvDN4heK6i/wBZH9jhPHZlO3lT 2P4HBGKd5z/8+Wo/+AM3/wATVW8ha5COlrqMVzFkxSiwmO31BG3lT3H9QCNI4SbXJKjp/gWn 4feLm8zT/tjxV/0Mj/8AgHD/APE0f2x4q/6GR/8AwDh/+Jqha3dxLDmfTNRilBwyiymIz6g7 eQfzqbzn/wCfLUf/AABm/wDiah4Gonb2K/8AAF/kPmXcs/2x4q/6GR//AADh/wDiaP7Y8Vf9 DI//AIBw/wDxNVvOf/ny1H/wBm/+Jo85/wDny1H/AMAZv/iaX1Kp/wA+V/4Av8g5l3LP9seK v+hkf/wDh/8AiaP7Y8Vf9DI//gHD/wDE1W85/wDny1H/AMAZv/iaPOf/AJ8tR/8AAGb/AOJo +pVP+fK/8AX+Qcy7lfStb8T6VBBoy6xbxJbxCO2zZBhJGowOd3UDqPxrU/t/xb/0HLb/AMAF /wDiqzbqMXcPlyWWpddystjMGRh0IOzg1Fb3s8QMV/bXaOvCytaSIso9QCvB9RWk8FOV5ujr 19xffsJS8zX/ALf8W/8AQctv/ABf/iqP7f8AFv8A0HLb/wAAF/8Aiqzv7Qg9J/8Avw/+FH9o Qek//fh/8Kx+py/58r/wBf5D5vM0f7f8W/8AQctv/ABf/iqP7f8AFv8A0HLb/wAAF/8Aiqzv 7Qg9J/8Avw/+FH9oQek//fh/8KPqcv8Anyv/AABf5BzeZo/2/wCLf+g5bf8AgAv/AMVWOs11 bX9xPqU6zm9mEjXCx7AH2qoUjJxkKMH1444zP/aEHpP/AN+H/wAKa95ayxtHJHKyMMMrW7kE en3auGGqRvala/aNvyQcy7l2D/kNaL/2E7X/ANGrXu1fPGjyS/8ACSaLZxx3M8X9o27xyGF8 oFkUkOSOgHRvbnnk/Q9fUZPSlToNSXX/ACMKjuwooor1SAooooAKKKKAK2o2015p1xbW95LZ zSoVS4iVS0Z9QGBBrwu4tvEXhSe+t5dbvYtQCGR5mht5DcgdH8xoizj6nI6V77WF4u8P2fiH QbiC5BSWON2hnT78Tbeo9j0I6EVx47CLFUuR/irr5plRlyu5naBdTX3hzS7u4bfPPaRSyNgD LMgJOB7mtGsnwuMeEtFHpYwf+i1rWr8erpKrJLuz0FseVeLde1uPxZqdkmpyw6TBHErxR28L 7d6ZLNvjYlfX0/OpvC+ual4XmVlv7rUdNb79nJ5eEX1h2qoXHZR8p56HkQ63/wAj9rn+7b/+ i6yHzpJ3orvZMwBjRSzRMTgbQOSCT0HTPHHT7LA1pUIw9gknaOyXvaLfu/63OaSve59AWF/a 6nYxXtlMs1vKu5HXv7exB4IPIIxVmvF9A1zVvDd+ZoNE16azmYG5tRpNyN3bemY8Bx+TAYPY j2aNxJGrgMAwBAZSp/EHkV9ph6zrU1KUXF9mjnasx1FFFbiCiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooA8V8WfDXTPD88uoWlgjaVK5eTGc2zH19UPr278d Og+HCiPwn5S52R3lyiAnO1RK2BXpDosiMjqGRhhlYZBHoa4bwnaQWNhf2ttGI4ItTu0jQdFU TNgCvjuLMOoYb2ie8lp8mdFB62N6vM/idY/2jrejQFuEtrmVUbOxmDQjkfQmvTK8/wDHf/Iz 6P8A9eVz/wChw18hlMnHFRkuz/JnRU+E5DSrOytrxL6whNjqdseJEPzxN/IqefYg17R4U8Vx eIIDb3CpBqcK5lhB+Vx03pnqvt1U8HsT5DeWxci4hYR3MY+VuzD+63qP5da2tK8NeLNQsdO1 nT7Wzt3liS6tpRekOgZQRkeXjocEcg8ivusrxGIc3yJyj1V9vS5yzSPaKKp6U+oSaXbtqsME N8V/fJbuXjDeqkgHB6+2cc9auV9MYhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABXOeGfGVh4p 1HXLKzhnjfSLo2srSAAOQSMrg9MqevtXR15H8G/+Rq+If/YYb/0OWgD1yiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAOci8ZWEv j6fwgIZxew2gujKQPLIyPl65zhgenrXR15HZ/wDJzuof9gcfyjr1ygAooooAKKKKACiiigAq vf8A/IOuf+uT/wAjViq9/wD8g65/65P/ACNAHK+GP+RT0b/rxg/9AFatZXhkgeE9Gycf6DB/ 6AtagIOcHp1r8TxH8afq/wAz0lseV63/AMj9rn+7b/8Aouqd19yH/r5h/wDRq1c1v/kftc/3 bf8A9F1TuvuQ/wDXzD/6NWvrsF8dH0h+SOeXU9+ooor745QooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigArivD3+r1T/sK3n/o5q7WuB02/tdL0zWr2 9mWG2h1O8aSRugHnNXy/FsXLBRS35l+TN6HxHQ15/wCO/wDkZ9H/AOvK5/8AQ4a7JdZ09tTh 077SovJ4PtEUTAgvHnGRkc/TqPSuN8d/8jPo/wD15XP/AKHDXw+WwlHErmVtH+TOmfwmHJ/q 3+hr1zwV/wAiH4d/7Blt/wCilryOT/Vv9DXrngr/AJEPw7/2DLb/ANFLX32Qf8vPl+pyVehu 0UUV9EZBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABXj/wguIYPFXxCEs0cedYbG9gM/PLXsFe dap8EvBer6rd6jcW12s91K00gjuCF3Mckgdskk0Ad79vs/8An7g/7+Cj7fZ/8/cH/fwV5v8A 8KB8Df8APC+/8Cj/AIUf8KB8Df8APC+/8Cj/AIUAekfb7P8A5+4P+/go+32f/P3B/wB/BXm/ /CgfA3/PC+/8Cj/hR/woHwN/zwvv/Ao/4UAekfb7P/n7g/7+Cj7fZ/8AP3B/38Feb/8ACgfA 3/PC+/8AAo/4Uf8ACgfA3/PC+/8AAo/4UAekfb7P/n7g/wC/go+32f8Az9wf9/BXm/8AwoHw N/zwvv8AwKP+FH/CgfA3/PC+/wDAo/4UAekfb7P/AJ+4P+/go+32f/P3B/38Feb/APCgfA3/ ADwvv/Ao/wCFH/CgfA3/ADwvv/Ao/wCFAHpH2+z/AOfuD/v4KPt9n/z9wf8AfwV5v/woHwN/ zwvv/Ao/4Uf8KB8Df88L7/wKP+FAHpH2+z/5+4P+/go+32f/AD9wf9/BXm//AAoHwN/zwvv/ AAKP+FH/AAoHwN/zwvv/AAKP+FAHpH2+z/5+4P8Av4KPt9n/AM/cH/fwV5v/AMKB8Df88L7/ AMCj/hR/woHwN/zwvv8AwKP+FAHpH2+z/wCfuD/v4KPt9n/z9wf9/BXm/wDwoHwN/wA8L7/w KP8AhR/woHwN/wA8L7/wKP8AhQB6R9vs/wDn7g/7+Cj7fZ/8/cH/AH8Feb/8KB8Df88L7/wK P+FH/CgfA3/PC+/8Cj/hQB6R9vs/+fuD/v4KPt9n/wA/cH/fwV5v/wAKB8Df88L7/wACj/hR /wAKB8Df88L7/wACj/hQB6R9vs/+fuD/AL+Cj7fZ/wDP3B/38Feb/wDCgfA3/PC+/wDAo/4U f8KB8Df88L7/AMCj/hQB6R9vs/8An7g/7+Cj7fZ/8/cH/fwV5v8A8KB8Df8APC+/8Cj/AIUf 8KB8Df8APC+/8Cj/AIUAekfb7P8A5+4P+/go+32f/P3B/wB/BXm//CgfA3/PC+/8Cj/hR/wo HwN/zwvv/Ao/4UAekfb7P/n7g/7+Cj7fZ/8AP3B/38Feb/8ACgfA3/PC+/8AAo/4Uf8ACgfA 3/PC+/8AAo/4UAUdPkjl/ab1B43V1/sccqcjpHXr1cb4U+F/hnwZqkmo6Rbzi6eIw75Zi+FJ BOB+ArsqACiiigAooooAKKKKACq9/wD8g65/65P/ACNWKr3/APyDrn/rk/8AI0AeV6gjw+D/ AAlqpSKeDTkgnktpblYBIfJwpDMQu5SQQD1rV8L2t1NrWq63LpbaXDfpEFgaZZGlZd2ZW2kq CQVHB521ha3FGPBfhO8uJNHFrawxO8WqsRFIxg2gcK2SNxP4ZrZ8Dz3lvaDQ7y80q5bT7eJV axmeQhTnG/KgDgDGP8K/KsQpfVpSj3ae+3Nfvbe3Tqux3L4jmNb/AOR+1z/dt/8A0XVO6+5D /wBfMP8A6NWrmt/8j9rn+7b/APouqd19yH/r5h/9GrXr4L46PpD8kZy6nv1FFFffHKFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFeX3yWb+EfEX2+ 8azt01O6k+0Im8xstwWQ7f4vmC8d+leoV5Vqy2z+DPEP2ueeCIatO2+CMSPuF1lQqngksAOf WvneJP4FL/r5Hb5+ptR3foP8Mre+JL611y/1S2uY9PMsMUNvZvbsspG1zIJCWBx/Djvmqnjv /kZ9H/68rn/0OGoPBt3IdfaK21bVbvz5pZtRt57CKNbeTBT94wHysSgwqk569Kn8d/8AIz6P /wBeVz/6HDXx8YOGPUenK7aWsrPTZdb9Ndzf7Bhyf6t/oa9c8Ff8iH4d/wCwZbf+ilryOT/V v9DXrngr/kQ/Dv8A2DLb/wBFLX2GQf8ALz5fqc9XobtFFFfRGQUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABXCaK3iDWNIt9QfxNcwtOC/lx2sG1eTwMoT+dd3XHeDv+RR07/rm f/QjWVWTS0Ma0nFKxL/Z+vf9DXef+Alv/wDG6wm8W6p4a8ZSafql7JqemfY4ZncwIssJd5VL AIo3KPLGRjPcdMHtK8z8Xf8AI+3H/YLtf/RtxWUKkrmMKkr6s9dgniuYI54JUlhkUOkiNlWU 8ggjqKkryLw94pbwo7i5YtorEvMnU2x6mRf9nuy/iOchvXa6U7nVGSkrhRRRTKCiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKr3/wDy Drn/AK5P/I1Yqvf/APIOuf8Ark/8jQB5PqNtdy+GPBs1pdadDIkcUax3+/ZM8kHlqoCgkn5i av8Aw9tJ9JtLrRZX0ZjYbI5BYeZ5hkIyWl39SRjke47YFHUWltvCXhPUbTzlvLOCN4pBZvcR AGEKwkCfMoIP3h0IrR8F3i6xfahq0+q6dd30kcULwWKOggRdxG4P8+SWPJA6V+V13J4Wf8t3 068zt07N9etvXuXxHN63/wAj9rn+7b/+i6p3X3If+vmH/wBGrVzW/wDkftc/3bf/ANF1Tuvu Q/8AXzD/AOjVr1sF8dH0h+SM5dT36iiivvjlCiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACvKdXS3k8GeIVuTdBDq0+0WoUyl/tXyBd3GS20c+terV 5nPbpdeFvEMMltFco2pXeYpbjyFOLgnPmYO0jqD6gV87xK+WhSf9+P6m1Hd+hU0bTpfDfii1 s5tU1eVNSEtztmWAxSTkEurFFDBgMNnOD07VD47/AORn0f8A68rn/wBDhqj4M1HTbzxTHDO2 t3eqQxMI5Lm8jvLeAEfNtkjOASBjJGe1XvHf/Iz6P/15XP8A6HDXyCjKOOip78rvolfSWqt5 G/2TDk/1b/Q1654K/wCRD8O/9gy2/wDRS15HJ/q3+hr1zwV/yIfh3/sGW3/opa+vyD/l58v1 Oer0N2iiivojIKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArjvB3/Io6d/1zP8A 6Ea7GuO8Hf8AIo6d/wBcz/6Eaxr7I58R8KNyvM/F3/I+3H/YLtf/AEbcV6ZXmfi7/kfbj/sF 2v8A6NuKwhuc8Nzm/EH/ACLWq/8AXnN/6Aa+ha+evEH/ACLWq/8AXnN/6Aa+ha6aex10tgoo orQ1CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKr3//ACDrn/rk/wDI1Yqvf/8AIOuf+uT/AMjQB5NrVpLefD/w9FDPrcchtocJpcZf ePLXiQBl+X/gQrR8AafqdhDdrqHh6w0tTs8mWDAlnHOfMAZ+R/vHqa3vDH/Ip6N/14wf+gCt Wvx+vjZKE8NbS7/P+t7noKPU8q1v/kftc/3bf/0XVO6+5D/18w/+jVq5rf8AyP2uf7tv/wCi 6p3X3If+vmH/ANGrX0WC+Oj6Q/JGMup79RRRX3xyhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABXmk1h/afhnX7I6bHqXm6pdD7LLOYVf/AEgnlxyM dePTFel1xXh7/V6p/wBhW8/9HNXzHFU3TwkJrdTT/B9tTagryZg+E/DHiTRdQDXesxrpSqQm mRlpwvBxiV8MMZHHtVXx3/yM+j/9eVz/AOhw16BXn/jv/kZ9H/68rn/0OGvi8HiJ4jGKc7Xs 9lbo/vfm9TpkrRsYcn+rf6GvXPBX/Ih+Hf8AsGW3/opa8jk/1b/Q1654K/5EPw7/ANgy2/8A RS19zkH/AC8+X6nLV6G7RRRX0RkFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVx 3g7/AJFHTv8Armf/AEI12Ncd4O/5FHTv+uZ/9CNY19kc+I+FG5Xmfi7/AJH24/7Bdr/6NuK9 MrzPxd/yPtx/2C7X/wBG3FYQ3OeG5zfiD/kWtV/685v/AEA19C189eIP+Ra1X/rzm/8AQDX0 LXTT2OulsFFFFaGoUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABVe/8A+Qdc/wDXJ/5GrFV7/wD5B1z/ANcn/kaAOV8Mf8ino3/XjB/6 AK1ayvDH/Ip6N/14wf8AoArVr8TxH8afq/zPSWx5Vrf/ACP2uf7tv/6Lqndfch/6+Yf/AEat XNb/AOR+1z/dt/8A0XVO6+5D/wBfMP8A6NWvrsF8dH0h+SOeXU9+ooor745QooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArivD3+r1T/sK3n/o5q7W uK8Pf6vVP+wref8Ao5q+W4u/3GP+JfkzfD/EbFef+O/+Rn0f/ryuf/Q4a9Arz/x3/wAjPo// AF5XP/ocNfDZX/vK9Jfkzpn8Jhyf6t/oa9c8Ff8AIh+Hf+wZbf8Aopa8jk/1b/Q1654K/wCR D8O/9gy2/wDRS1+gZB/y8+X6nJV6G7RRRX0RkFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAVx3g7/kUdO/65n/0I12Ncd4O/wCRR07/AK5n/wBCNY19kc+I+FG5Xmfi7/kfbj/s F2v/AKNuK9MrzPxd/wAj7cf9gu1/9G3FYQ3OeG5zfiD/AJFrVf8Arzm/9ANfQtfPXiD/AJFr Vf8Arzm/9ANfQtdNPY66WwUUUVoahRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAVtQlu4NOuJrC1S7ukQtFbvL5QkYfw7sHGfXFedad8 SNU1/wA/Tl0XS7LUCHiazvdVljlU8g4H2bDY/wBkmvTq4vxx4Gg8QwtfWkETagoG+N8BbkDo Cezj+FvwPGCObFKs6T9g7S+/+vwHG19S1o9nJp+iWFlKytJb20cTFehKqAce3FXa8s0zxBrm jZSGZr63jYq9nfsRLERnKiTlgR0w4b6ir138QNQ1IyW2kWX2Bo8LLNe4d1JH8Eakgj0YnHsa /LK2V4h1Xs+72t6rf8/I7lNWIvFuj31hruo64bnSIrG5WIA3l28TBlXGABG24nsBz7Vya6nf SsjXmnC3tRcxbbhZSQQJFO4qyqyrweSB9O9av2YSXZvLqaW8vDx9ouG3OB6L2Uc9FAFTEBlK sAQRgg9693DTVBR5lzONtdVt8/Ld/cZS1PeKK8x8IeLzpDR6XqkpOnnC29y5/wCPf0Rz/c9D /D0PHT06vuMPiIYiCnBnM007MKKKK3EFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQB5LqniLxl4Z11rHXNRJsZCWtb+zsEcOvfcnXI7hdx74xzXSeGDaPpLS 2epx6ks88s8lwm0Au7FmGB93BPTrXUatpNnrenSWV7HvibkEHDIw6Mp7EeteM6xod14W1seZ cyWd1IcW+oW52C5A6Bh91mHdGB9RxXy/EOX1sRTupvl3tuk/z/rY2pTSZ6vXEePINLN1ZXd3 rT2V1DFJHFBDEJpJlYqThOvVBz09awLvxb4ldYrG4vLe1jf5ftttDiSQ9l+YlYyfXBz22nAq pBaQ27vIilpZDmSaRi8kh9WY5J/E18nhcvnQmqk5elvu6q34P5HRKd1YzBHrTzPMkwFsB8kF wiiST/eK8J7YLe/pXt/gS5huPA2ipFIGe2s4beZe8ciIqspHYgj+R6EV5VVnTNXu/D1+dQs2 UggC4gdsJMg7E9mHOG7fQkV9RluYRo1HGaSTtsYTjdaHt1FUdH1a11zSLbU7Jma2uE3oWGD6 EH8QRxx6ZFXq+sMAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACuO8Hf8ijp3/XM /wDoRrsa47wd/wAijp3/AFzP/oRrGvsjnxHwo3K8z8Xf8j7cf9gu1/8ARtxXpleZ+Lv+R9uP +wXa/wDo24rCG5zw3Ob8Qf8AItar/wBec3/oBr6Fr568Qf8AItar/wBec3/oBr6Frpp7HXS2 CiiitDUKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiqWpavp2jQJPqV7BaRO+xWmcKG bBOB6nAJ/CgC7RXP/wDCc+Fv+g9Y/wDf0Uf8Jz4W/wCg9Y/9/RSugOgorn/+E58Lf9B6x/7+ ij/hOfC3/Qesf+/oougOgorn/wDhOfC3/Qesf+/oo/4Tnwt/0HrH/v6KLoDoKK5//hOfC3/Q esf+/oo/4Tnwt/0HrH/v6KLoDoKK5/8A4Tnwt/0HrH/v6KP+E58Lf9B6x/7+ii6A6Ciuf/4T nwt/0HrH/v6KP+E58Lf9B6x/7+ii6A6Ciuf/AOE58Lf9B6x/7+ij/hOfC3/Qesf+/oougGa/ 4K0rX5WunElpfkAfa7Y7WOOgYHKuO3zA4HQivNfEHgzXtHYXPki7WIfJe2cZJx6SRctg/wCz uA65Fem/8Jz4W/6D1j/39FH/AAnPhb/oPWP/AH9FcuIwdGvrJa9+v9epSk0eO6fqEOoQF42X evDoGB2n69x6H/64q5Yw3er3LW2kWct9Kp2uY8COI/7ch+Vfpy3oDXaap/wrPWNSXULy7003 QPzvFcGLzh6SbSN44H3s9PTit228YeDrO2jtrXV9MggjG1IonVVUegA4FeZDI6aneUrx7F+0 djE0n4ZxsBL4huvtZP8Ay525KQD2Y8NJ+O0Hutd8iJHGscaqiKAFVRgADsBWD/wnPhb/AKD1 j/39FH/Cc+Fv+g9Y/wDf0V7NKlTox5aasjNtvc6Ciuf/AOE58Lf9B6x/7+ij/hOfC3/Qesf+ /orS6EdBRXP/APCc+Fv+g9Y/9/RR/wAJz4W/6D1j/wB/RRdAdBRXP/8ACc+Fv+g9Y/8Af0Uf 8Jz4W/6D1j/39FF0B0FFc/8A8Jz4W/6D1j/39FH/AAnPhb/oPWP/AH9FF0B0FFc//wAJz4W/ 6D1j/wB/RR/wnPhb/oPWP/f0UXQHQUVz/wDwnPhb/oPWP/f0Uf8ACc+Fv+g9Y/8Af0UXQHQU VFbXMF7axXVrNHNbyqHjljYMrqehBHUVLTAKKKp6lq+maNAs+qajaWMLtsWS6nWJS2M4BYjn g0AXKK5//hO/B/8A0Neh/wDgxh/+Ko/4Tvwf/wBDXof/AIMYf/iqAOgorn/+E78H/wDQ16H/ AODGH/4qj/hO/B//AENeh/8Agxh/+KoA6Ciuf/4Tvwf/ANDXof8A4MYf/iqP+E78H/8AQ16H /wCDGH/4qgDoKK5//hO/B/8A0Neh/wDgxh/+Ko/4Tvwf/wBDXof/AIMYf/iqAOgqG7tLa/tZ La8t4ri3kGHilQMrD3B4NYv/AAnfg/8A6GvQ/wDwYw//ABVH/Cd+D/8Aoa9D/wDBjD/8VQBz et/DCN4pDodyI0YENY3hLwt7K3LJ/wCPD0Arz+cX3h68XT9dtprTccQTT4KP/s+YPlY+hzn1 APX2T/hO/B//AENeh/8Agxh/+KqK58Y+B723a3u/Efh6eFsbo5b6FlOOeQWxXn4jLaFZPSz8 i1No810nStV8QkHSLPfbn/l8nJjg/wCAnGX/AOAgj1IrvdH+HOmWbJcaq51W6U5AmTbAh/2Y uR+LFiOxFaQ8deDwMDxVoQH/AGEYf/iqP+E78H/9DXof/gxh/wDiqrC5dQw+sVd92JzbOgAA GAMCiuf/AOE78H/9DXof/gxh/wDiqP8AhO/B/wD0Neh/+DGH/wCKruJOgorn/wDhO/B//Q16 H/4MYf8A4qj/AITvwf8A9DXof/gxh/8AiqAOgorn/wDhO/B//Q16H/4MYf8A4qj/AITvwf8A 9DXof/gxh/8AiqAOgorn/wDhO/B//Q16H/4MYf8A4qj/AITvwf8A9DXof/gxh/8AiqAOgorn /wDhO/B//Q16H/4MYf8A4qrNj4r8Oandpaaf4g0q7uXztht7yOR2wMnCgkngZoA16KKKACii igAooooAKKKKACuO8Hf8ijp3/XM/+hGuxrjvB3/Io6d/1zP/AKEaxr7I58R8KNyvM/F3/I+3 H/YLtf8A0bcV6ZXmfi7/AJH24/7Bdr/6NuKwhuc8Nzm/EH/Itar/ANec3/oBr6Fr568Qf8i1 qv8A15zf+gGvoWumnsddLYKKKK0NQooooAKKKKACiiigAooooAKKKKACiiigAooooAK5zxJ/ yHPC3/YQl/8ASWeujrnPEn/Ic8Lf9hCX/wBJZ6xxH8GXo/yGtzXooor5g2CiiigAooooAKKK KACobu6hsLKe8uX2QQRtLI2CdqqMk4HJ4HapqjnhjubeSCVd0ciFHHqCMGheYGXF4q0SbVNP 02O/VrzULYXVrFsbMkRBO4HGBwDweeKpS+PvDcdraXC3zzLdo0kKQ20juyK21nKBdwUEHkgC vMYvB3iu18LXepLaSnXdOuYrWxQHLyW0aNH8p9G81m/4DXVafo174G1q3vItIu9StG0a3sMW YVnhljJyMEj5WznPrXXKjSWzv8/6/q5N2dTJ438PRrZlb9p/tkBuLf7Nbyzb4wcFvkU4weDn oaafHPhz7JZ3KX7Sx3jSJAIraWR2aP742KpYEd8gVytz4b17WfEOkXJSbQJE0edHk09lKQSt IpVDkYIPUgenXvWbpnhXWZH8LW4t77Sbu0ur86hfQ7XLSMg/fAuGBEh45HHI7UKlStv+PqF2 d63jjw6NGTVV1EPbSTG3jCROZHlHWMR437uOmKv6Lr2m+ILV7jTbjzVjcxyoyMjxuOqsrAFT z3FcZe+E5vC95oerabBfawLO8ubi/UurXEzToFMoHyqSCo+UY46V1fhy8vtQhu7u80b+y1kn PkRyEedIgAAeQDhWPPGTxWU4QUbx/r5DK1l488OahLaR299Iftb+XbvJazRpK3orsgUnjGM0 1/H/AIajkZH1B0Vbg2zStazCIShtpUyFNvXjrXmfh3w7r0Ft4dt107xCt5aagk00V68f9nxx h23Mq5yG2nIxzuNXZPBmurpVzcOl9c2v9uTTXehmQKl1bmbcrJjB3dGwTg+1buhRTtzfiK7P RrrxnoFm0iTXrb47v7EyR28jt523fsAVSSdvPHFPt/F+gXWk3eqRalGLSzbbcO6shiPHDKwD AnIxxzniuAvNH1i01yXU10i8uIU8UfbgkCgu8P2bbuAJH8XHOKmvfDWt66+ua6mmSWz3F/Y3 Vtp1y6rJOlsMEPgkLuzwCf4Rmo9jT01/FBdnY2vjvw9dQ3sgvJIfsUBuZ1uLaSJhEP8AloFZ QWX3Gau6X4k03WJhFZG7ZinmBpLKaJSvHO50A7jvXBayPE/iNdfFvpupx6fNo9xEkN/bwRye e2NqRlfnK8HqcZI9q1PA0FxZXcUM0Hi7cbYRt/akiNbIRj7oDZB4wOOhpSpQUW76+o7nf0UU VzDCiiigAooooAKKKKACiiigDx/4e+IZ/DehaWCHm0uW1iaaFRlomKDMiD9WXv1HOQ3s9tcw 3ltFc20qSwSqHSRDlWB6EGvBfDv/ACLOlf8AXnD/AOgCuy8A6hcW3ihtHR/9BuLSa7MZ6JIk kS5X0DeYSR6gHgk5+hoVm5cjMmup6bXL+Kf+Q34a/wCvub/0nkrqK5fxT/yG/DX/AF9zf+k8 lZ5r/uNb/DL8mOn8SLdFFFfjp6AUUUUAFFFFABVWTUrOG+WyluY0uWiacRscEopALfQZFWq4 H4mabqk8emX2jW0lxdIZrJ0jUkiKeMqWOOgUhTXThKMa9ZU5u176+dtCZOyudVa+I9Hvbeyu LbUIJYr2RorZkbPmsM5A+m0/lUFl4v8AD+o6o2m2eq2812CR5ak/MR1CnoxHoCa4bTvCN/a+ LrzSLaGe30uyt7mewuyhCebPFHGRnp8p8w/jWn4bupYtL8P+HpPCl0LyyVUmmnt9sNqVUgyp IQQxJHG05OTyK9CrgcOouVOTlpfdKyd2m/kldaav0RKk+p0h8ZeHF1j+yTq9t9t3+V5e7jf/ AHN33d3tnNXjrWmrb385vIhFYMy3TZ4hIAYg/gQa8wjTXdM8I2Xh210W5fUra4YSxy6YJ7e5 JlyJfNJ2rgEnPXJ6CrusRX1jB420ddI1G5m1iRpLKWC3Lxv5kSpgsOFwQc57VcstouSUZfit UpJX2Vk07rf10Yudnoltq1hdy3EcF1G72yo8wBxsV13KT9RzTbLW9L1HSjqlpfwS2ADE3AcB FC9SSemMd686vNN121/4SexsrKfz9SGn2ENwIm8sDydsj7gD8qjcCexIqrL4Y8QWmk+IvDia bH5F5HDfW0dozvBuRlEkO91GGYIDjPr61Ky2g1/Etfl6rZqPM/lfT0dw532PQdP8Z+HdV+0/ YtVgmNtGZpQMghB1YAj5l9xkU7TvF+gaverZ2Gpw3Fw2cRpnPAye3pXPWOoanqnjrT5bfSrm LTI4ZBKb3SxC9r8gARJCcnLdQo6Y7Vp+EbO5tdV8UvcW8sST6q0kTOhAkXy0G4Z6jIPPtWNb C0KcZPW9k0rrq7Wfur19PvGpNnU0UUV5ZoFFFFABRRRQAVw3xGXc/h/DMjC9dldGKsrCFyCC OhBwc13NcR8RP9ZoH/X4/wD6JkrvyxtYqLXn+TIn8J0fg/xh/ahXS9UZV1JV/dyYwt0o7gdn A6r+I4yF7GvBnTeB8zKysGR0OGRhyCCOhB71634L1W61vwlY394ytcP5iOyjG4pIyZx6nbk4 4ya/Tsrx7xMHGfxL8TinGxvUUUV6pAUUUUAFFFFABXHeDv8AkUdO/wCuZ/8AQjXY1x3g7/kU dO/65n/0I1jX2Rz4j4UbleZ+Lv8Akfbj/sF2v/o24r0yvM/F3/I+3H/YLtf/AEbcVhDc54bn N+IP+Ra1X/rzm/8AQDX0LXz14g/5FrVf+vOb/wBANfQtdNPY66WwUUUVoahRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAVzniT/kOeFv+whL/AOks9dHXOeJP+Q54W/7CEv8A6Sz1jiP4 MvR/kNbmvRRRXzBsFFFFABRRRQAUUUUAFFFFABRRRQByFv49gn1qPQ/7PnXWPtjW8tozDMca gMZ93QoVKkdznFZsfxY06TQdZ1M6dcq2mXCweQWG6cs5QFT9Vf8A75NFr4L1638UL4sOoWp1 ma4ZLqDe32c2eAFiU7c7l2q2SOTnNYZ+Eupu9uWvrPYI7wTxhmw7u0zQN93+EzHP6ZrsUaHV 9v8Agk6nd6L4tg1rU4rGO1kjeTTINR3MwICy5wv1GK0rbVUutcv9Njj/AOPOOJpJM9WfcduP YKD/AMCFcdY+FvFGiaraX2mnR5imjWunSrczSr80Wcsu1DkHPGcfStCLSvFtpHLfWs+mDULn UGuLqBy3lSxeWI1UPt3AjYpHHc5rKUIX91jKzfEmOXS9GnstJea71YzeTby3KQqBE+1syNxk 8YHertx42kW00pLXQb6XV9SWRo9NmKwvGE++zluAucYPfIxWK3gTVrXwto+lLFo2rw2qS/ar O/TEbu7lw8cm0spXJHTkelJpvgTXdBt9FvtPvbOfVNPS4hkt53cQPDK28Rq+Cw2EDBIOe/YV o40enn+tv0/zFqXbz4nWemaVJc6lpd3a3VtfR2V5ZkqzwF1LBwRw6FQSCOtdFpXiK31bW9U0 63TIsEt388MCsqyoWUrj2FcsfAeqX1wdR1O4sZL651e2vbqJA3kiGFCgjXIyxwec4zV7wR4K uPCOr685uknsLtoRZLk74o0DYRuMYG4AcngdqmcaPK7b/wDDf8Eep2lFFFcwwooooAKKKKAC iiigAooooAKKKKAPDPDv/Is6V/15w/8AoArqfBP/ACUO3/7BV1/6Ntq5bw7/AMizpX/XnD/6 AK6nwT/yUO3/AOwVdf8Ao22r2qH8b7zN7Hq1cv4p/wCQ34a/6+5v/SeSuorl/FP/ACG/DX/X 3N/6TyVea/7jW/wy/JhT+JFuiiivx09AKKKKAM3Wdag0RbJ7iORku7uO0DJjCM5IBbJ6ZwPx rCPxE0sxayyW9y7aXcJbsg2ZnZ5DGDH83I3Kw5x0rU8X6NPr3he80+1eNLtgr27ydFkRgyn2 5UVyUXw6vob/AMKSpdRiKxRTqa7j+9dGMqlfX947de2K9XCU8FKlzVnaV/wWv4/CvMzk5X0O og8WWs2q2On/AGeUS3k1zCjB43UGHBYkqxxnPA6+oFTReK9IuNZi021u4blpIJZmlglR0jEZ QEMQeD84P4VykHgPVBd25kuII41uNUd5I3JZVuRhCOByOpqp/wAIBrV7ZxWlxHptiIdEl0oT W0jMZWJTa5G0YU7TxyeT61r9WwLf8S2j/OVn56W0QuaXY9Aj17R5bOW8j1awe1iIWSZblCiE 9AWzgVUl8XaFHf6ZZrqNvLJqTOts0UqsrFevOe5+UY6niucudA8R3elMo0zQ7OdZbfKW5Bkl SPO7940ZCn+78uVGeaq6L4L1rSdS0y7eO1mWDU7qeRGuWYrFMigEMU+YqQTjAzx07RHCYVRk 5T11srr+XTX1+Q+aXY7XRdct9b0KPVo0kggfzMrNgMuxmU5x/umsjT/GrajJazxaDqY0u7kE cF9sVgxPRigJZUP94jFaGk6J5Hhh9IukVFl89XWJywCyO54JA7N6fnXKQ+FfFIi0bTGmt4od LliA1CG9mVpoEYHaYQAu4gYJJNRSpYWUqibVr6Xey11Wur27+j6DctDoJPGtjH4bv9c+z3Bg srprV0wu5mWURkjnGMnNaWla3b6tdanBDHIjafdG2kLgYZgqtkYPT5q4668I69JZan4eiSwG kahqJvDeGZvMijaUSMmzby2RgHdiul8O6Lc6Vf6/PcNGUv8AUDcw7CSQhRF5yODlTRXo4WNK Tg9emvT3bfP4vMacrlPRPG665dW3kaNfrYXbukF6NjplM53hSTHnBxuHPtW5HrmkS/aPL1Sy f7MCZ9twh8oDqW5+X8a4Ww8FayviCzu3ttOsJoJmkutSspmVrxCCAvkgBVJyMkk9Miqlj8Ot Yi0S7sZ/s4nXS5rCGcXbMsrPjBK7BtXjJzkg9K3q4XAyleNTlWnn1eu/a3Z63aWxKlLseiwa 5pN00q2+qWUzRIXkEdwjFFHBJweAPWhdb0l7iG3XVLJp51DwxC4QtIp5BUZyQfUVyfiDwNdX +naTDpU8FjNHB9hvWQbRJbOoEgGBycqMZ9TVa58C3zeKZ5okhbTZrq2njYXLRmBYlVduwKck bflwwHUGsIYbCSV/aW0eno7fjv8AgPml2O5t9U067uXtra/tZp0BLxRTKzKAcHIByMHj61br nfCPh+TQbW/Fylv59zf3Fxvi5JR3JUE4BzjFdFXDXjThUcabul1LV7ahRRRWIwriPiJ/rNA/ 6/H/APRMldvXEfET/WaB/wBfj/8AomSu7Lf95j8/yZE/hOcr0v4a/wDIg6f/ANdLj/0fJXml el/DX/kQdP8A+ulx/wCj5K++yH45+iOWrsdZRRRX0xiFFFFABRRRQAV5xp+tHQvAGl3Yt45y 37vZJdRwDksc7pCB26da9Hrx/VYI7j4W6Sknh241396pW2t5HRo2+fEmVBPH9ayq9DGsr2NT w9rVx4g8Zm7MMNvbxae0RjTUYbgljIpztjY44yMkVleLv+R9uP8AsF2v/o24qP4XWGoWWpXf 2yxu7RDCfLjn0tYgo3Lx5/DuevBHv2qTxd/yPtx/2C7X/wBG3FZfaMLWlZHN+IP+Ra1X/rzm /wDQDX0LXz14g/5FrVf+vOb/ANANfQtbU9jopbBRRRWhqFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABXI+O746ONE1h7S5ubWyvmecW6BmRWgljBIJAxudRnPeuupskaSxtHIivG4Ksr DIYHqCKmcVOLi+oHnv8Aws/T/wDoB67/AOA8f/xyj/hZ+n/9APXf/AeP/wCOVn+JvDL+HJDc 2wZ9Ic4BPJtSf4T/ALHoe3Q9jWNXi1MNGm7NGidzqf8AhZ+n/wDQD13/AMB4/wD45R/ws/T/ APoB67/4Dx//AByuWoqPZU+w7s6n/hZ+n/8AQD13/wAB4/8A45R/ws/T/wDoB67/AOA8f/xy uWoo9lT7BdnU/wDCz9P/AOgHrv8A4Dx//HKP+Fn6f/0A9d/8B4//AI5XLUUeyp9guzqf+Fn6 f/0A9d/8B4//AI5R/wALP0//AKAeu/8AgPH/APHK5aij2VPsF2dT/wALP0//AKAeu/8AgPH/ APHKP+Fn6f8A9APXf/AeP/45XLUUeyp9guzqf+Fn6f8A9APXf/AeP/45R/ws/T/+gHrv/gPH /wDHK5aij2VPsF2dT/ws/T/+gHrv/gPH/wDHKP8AhZ+n/wDQD13/AMB4/wD45XLUUeyp9guz qf8AhZ+n/wDQD13/AMB4/wD45R/ws/T/APoB67/4Dx//AByuWoo9lT7BdnU/8LP0/wD6Aeu/ +A8f/wAco/4Wfp//AEA9d/8AAeP/AOOVy1FHsqfYLs6n/hZ+n/8AQD13/wAB4/8A45R/ws/T /wDoB67/AOA8f/xyuWoo9lT7BdnU/wDCz9P/AOgHrv8A4Dx//HKP+Fn6f/0A9d/8B4//AI5X LUUeyp9guzqf+Fn6f/0A9d/8B4//AI5R/wALP0//AKAeu/8AgPH/APHK5aij2VPsF2dT/wAL P0//AKAeu/8AgPH/APHKP+Fn6f8A9APXf/AeP/45XLUUeyp9guzqf+Fn6f8A9APXf/AeP/45 R/ws/T/+gHrv/gPH/wDHK5aij2VPsF2dT/ws/T/+gHrv/gPH/wDHKP8AhZ+n/wDQD13/AMB4 /wD45XLUUeyp9guzM8PHb4fsITxLBBHDKh6o6qAQRXVeCf8Akodv/wBgq6/9G21c5c20izfa 7TAuAMOhOFlX0PofQ9vpW74AuY7vx7byR5GNLu1ZGGGRvNtsgjsa7KGtVMl7Hrlcb48v4tJm 0LU7mOdrW3vHErwxNIU3xOq5CgnliB9SK7Korm2hvLaW2uYklglUpJG4yrA9QRXbiKMa9GVG W0k195Kdnc87/wCFiaH/AM89T/8ABfN/8TR/wsTQ/wDnnqf/AIL5v/iayPEvhqbwzchlLy6X K22GZjloSekbn9Fbv0POC2RX55icmo4eo4TT+/f8DrVRtXR13/CxND/556n/AOC+b/4mj/hY mh/889T/APBfN/8AE1yNFYf2dhez+/8A4A+eR13/AAsTQ/8Annqf/gvm/wDiaP8AhYmh/wDP PU//AAXzf/E1yNFH9nYXs/v/AOAHPI67/hYmh/8APPU//BfN/wDE0f8ACxND/wCeep/+C+b/ AOJrkaKP7OwvZ/f/AMAOeR13/CxND/556n/4L5v/AImj/hYmh/8APPU//BfN/wDE1yNFH9nY Xs/v/wCAHPI67/hYmh/889T/APBfN/8AE0f8LE0P/nnqf/gvm/8Aia5Gij+zsL2f3/8AADnk dd/wsTQ/+eep/wDgvm/+Jo/4WJof/PPU/wDwXzf/ABNcjRR/Z2F7P7/+AHPI67/hYmh/889T /wDBfN/8TR/wsTQ/+eep/wDgvm/+JrkaKP7OwvZ/f/wA55HXf8LE0P8A556n/wCC+b/4mj/h Ymh/889T/wDBfN/8TXI0Uf2dhez+/wD4Ac8jrv8AhYmh/wDPPU//AAXzf/E0f8LE0P8A556n /wCC+b/4muRoo/s7C9n9/wDwA55HXf8ACxND/wCeep/+C+b/AOJo/wCFiaH/AM89T/8ABfN/ 8TXI0Uf2dhez+/8A4Ac8jrv+FiaH/wA89T/8F83/AMTXNeLPFGna3caMlol4vk3TM7T2rxKA YnUcsAMkkD8arU2SNJomjkQOjDDKwyCK1o4TD0ZqcU7+vdW7Ccm1YdXpfw1/5EHT/wDrpcf+ j5K8ljkexlW3uHLwMdsMzHJB7Ix9fQ9+h56+tfDX/kQdP/66XH/o+Svp8jjapP0RjU2Osooo r6QxCiiigAooooAK8b1TcngHwrMupwaZ5OoRyG8nKbYhtlGcOQGPPTrXsledaXb31z4D0pNP tNNuZRyU1Dd5YX5uRhT82cduhNZVehjWdkg8Jan9u1CdP+E4s9f2xZ+zwQRIY+R8xKEnHb8a w/F3/I+3H/YLtf8A0bcVveCdA1bw/ZxWWoW2jiOGHYtxaFzLIc5+bKjj/AVg+Lv+R9uP+wXa /wDo24rFfEc6tzOxzfiD/kWtV/685v8A0A19C189eIP+Ra1X/rzm/wDQDX0LW9PY6aWwUUUV oahRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUANkjSWNo5EV43BVlYZDA9QRXJN8N fDxclRqEak8Il9KFX2A3cCuvopNJ7gcf/wAK08P/AN/Uv/BhL/8AFUf8K08P/wB/Uv8AwYS/ /FV2FIzKiF3YKqjJJOABS5I9gOQ/4Vp4f/v6l/4MJf8A4qj/AIVp4f8A7+pf+DCX/wCKq7L4 qF4TF4ftTqLdDdFvLtV/7aYO/wD4AG9CRVRtGu74+dqusXklwOYxZytbRQn/AGVU5b/gZb8j iok6cehnKrGO43/hWnh/+/qX/gwl/wDiqP8AhWnh/wDv6l/4MJf/AIqrEeoa7pHF1H/bFoP+ WsKrHcqP9pOEk+q7T6Ka2tM1nT9Yid7G5WUxnEkZBWSI+jocMp9iBTioS2RUZqWzOd/4Vp4f /v6l/wCDCX/4qj/hWnh/+/qX/gwl/wDiq7Ciq5I9ijj/APhWnh/+/qX/AIMJf/iqP+FaeH/7 +pf+DCX/AOKrsKKOSPYDj/8AhWnh/wDv6l/4MJf/AIqj/hWnh/8Av6l/4MJf/iq7Cijkj2A4 /wD4Vp4f/v6l/wCDCX/4qj/hWnh/+/qX/gwl/wDiq7Cijkj2A4//AIVp4f8A7+pf+DCX/wCK o/4Vp4f/AL+pf+DCX/4quwoo5I9gOP8A+FaeH/7+pf8Agwl/+Ko/4Vp4f/v6l/4MJf8A4quw oo5I9gOP/wCFaeH/AO/qX/gwl/8AiqP+FaeH/wC/qX/gwl/+KrsKKOSPYDj/APhWnh/+/qX/ AIMJf/iqP+FaeH/7+pf+DCX/AOKrsKKOSPYDj/8AhWnh/wDv6l/4MJf/AIqj/hWnh/8Av6l/ 4MJf/iq7Cs/VNb0/R0Q3tyEeQ4ihUF5ZT6Ii5Zj9AaOSPYLnP/8ACtPD/wDf1L/wYS//ABVH /CtPD/8Af1L/AMGEv/xVTyX2vaxxAn9i2Z/jcLJdOPZeUj/HefYGok0a708+dpGrXcUx5dLy VrmKY+rBjlT7oV+hAxWblTTtYydeKdrjf+FaeH/7+pf+DCX/AOKo/wCFaeH/AO/qX/gwl/8A iquw+KltGEWv2p01ycC53b7Vz/10wNn0cL7ZrolZXUMpBUjIIPBFWoweyNFK+qOQ/wCFaeH/ AO/qX/gwl/8AiqP+FaeH/wC/qX/gwl/+KrsKKfJHsM4//hWnh/8Av6l/4MJf/iquaJ4G0Pw/ q8mq2Mdx9seA25kmuXk+QlWIwxPdV/KukopqKWyAKKKKYEVzbQ3ltLbXMSSwSqUkjcZVgeoI rim+FmlF2KatrEaE/KizxkKPQEoSfxJNd1WZqmv6do7JHdTk3MgzFbQqZJpP91Fyce/QdyKy qwpSV6qTS7jTfQ5f/hVemf8AQZ1r/v7F/wDG6P8AhVemf9BnWv8Av7F/8bq9Lea9rHG7+xbM /wAKFZLpx7tykf0G4+jCootOv9LPmaNqc47vbX8j3EUh7nLHepPqGxzkqa+dq53k9OqqVk/N RTS/ryuaqnUauVv+FV6Z/wBBnWv+/sX/AMbo/wCFV6Z/0Gda/wC/sX/xutm18W26SJb61btp VwxCq0rboJD/ALEvA57BtrH0roq9ujSwdaCnSjFp9UkZtyWjOE/4VXpn/QZ1r/v7F/8AG6P+ FV6Z/wBBnWv+/sX/AMbru6K0+qUP5F9yFzPucJ/wqvTP+gzrX/f2L/43R/wqvTP+gzrX/f2L /wCN13dFH1Sh/IvuQcz7nCf8Kr0z/oM61/39i/8AjdH/AAqvTP8AoM61/wB/Yv8A43Xd0UfV KH8i+5BzPucJ/wAKr0z/AKDOtf8Af2L/AON0f8Kr0z/oM61/39i/+N13dUtS1ew0eATX91HA rHagPLSN/dVRyx9gCaHhcOldwX3IOZnI/wDCq9M/6DOtf9/Yv/jdH/Cq9M/6DOtf9/Yv/jda E2sa1q2VsIP7KtD/AMvF0gedh6rH0T6uSfVKrppF3Zt9o07Wr+O7PLtdSm4jmP8AtxscD/gG z06cV4WIznKKFRU2k+7STS/ryuaqnUauV/8AhVemf9BnWv8Av7F/8bo/4VXpn/QZ1r/v7F/8 brVh8VtZYj8QWn2Ht9siJktm9y2Mx/8AAwB/tGukjkSaNZInV43G5WU5BHqDXr0I4LEQ9pRU ZLySM3zLRnDf8Kr0z/oM61/39i/+N0f8Kr0z/oM61/39i/8Ajdd3RW31Sh/IvuQuZ9zhP+FV 6Z/0Gda/7+xf/G6P+FV6Z/0Gda/7+xf/ABuu7oo+qUP5F9yDmfc4T/hVemf9BnWv+/sX/wAb o/4VXpn/AEGda/7+xf8Axuu7oo+qUP5F9yDmfc4KT4T6TNE0cmr6w6MMMrSxEEf9+66vQNEt fDuiW2k2bzPBbhgrTPuc5YsST3OSa0qK0hSp0/gil6A22FFFFaCCiiigAooooAK47wd/yKOn f9cz/wChGuxrjvB3/Io6d/1zP/oRrGvsjnxHwo3K8z8Xf8j7cf8AYLtf/RtxXpleZ+Lv+R9u P+wXa/8Ao24rCG5zw3Ob8Qf8i1qv/XnN/wCgGvoWvnrxB/yLWq/9ec3/AKAa+ha6aex10tgo oorQ1CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACvKPiRpHiAasupNrMr6 EdoW2MEbxW78D94pGHBPIZs4Jxxxn1emSxRzxPFLGskbqVdHGQwPBBHcUmriaurHmHgfWdYu tevtO1LUPtkMdpHNGTAkZQlmUj5QOMAV3tcjpPh6Lw98QtQitpWa1m06N4o35MQ8x/lz3A7E 8445xk9dXJUVpWOGorSsZPii/uNL8Kavf2rBbi2s5ZYmIyAyqSDjvzXkcl5r+p3am816SHUr cZSaG2ijk256o6qCVPdenYj19T8c/wDIha//ANg+f/0A15zdWq3KL8xjlQ7o5F6of89R3pw2 Kp6K56F4N8Xy3Rj0nWpw9+eIboqEFz3wQOA49BwRyO4HcV8+R3ZnMlrcW1w1zFtZxbQSSAZJ 2uCoO3JU47gj2zXp3gfxXdaoW0vUra9+1QpujupbSSNZkHHzEqAHHf16juB0Rbe51Qk3udrR RRVlhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAFXUre5u9NubezvWsrmSMrFcoiuYm7Ntbg/Sv D4oPFHh7Urm2n1qSPU+DNNJbRSvMueGEjLuZPT05GARiveqxvEfhy18RWIilPlXMWWt7lRlo m/qp7r39iARMldEzjzKxneGL6fU/CejX90wa4urGCaVgMAsyAk47cmtWsLwT/wAiF4d/7Bdt /wCilrdrje5573PNfHviHX7DxPFYaZemCzFis06JbpKzZdlJAYHOABwPfqeDkeHdU1nQbtb2 z1Y3dk/zNYeWkcEgP9wKMIec5XAz1BrT8Z/8lBT/ALBSf+jXrnpwdMMl1GCbTl54h/B3Lr/M jv1HPXaLstDeDstD3XR9Ys9c05L2ykLRsdrKww0bDqrDsR/9cZBBq/Xh+la7e6JfjUNPtL99 4AmgNlMEuE7AnZww7N29wSK9m02/j1PTbe+ijmjSdA4SeMxuuezKeQa3TudMXdFqiiimUFFF FAFTU7SW/wBMubSC9mspZYyiXMON8ZPcZGP89uteEXljrvhNtQgfWdQhv1jaZ5T5b/acA4fe ybnH1OR0r6CrnvGmgWev+GryG5BWSKGR4Z0+/G209PY9CO4rjxuEWJp8j/HVfMqMuVlXRriW 70LT7mZt0s1tHI7YxlioJP51erN8PDHhnSh/05w/+gCtKvx2skqkku7PQWx5N4s1nWR4t1a1 Gp3EWlQCKNooUjIUNGrFiGQ7hknPp9OlnwprV94TlBS9u9Q0x/v2kjKRGvrCAAFx/dHyn2OC IdY/5HvxB/vwf+iVrKfdpTBo0eS0dwvlRruaNmOBtA6gkgYHQnjjp9pga06EYew0do9N9Fv5 /wBbnNJXvc+gLG+ttSsoryzmWa3lXcjr0I/oexB5BqxXjnh3Vtc8Oahvi0DW5bGdx9ptvsEv Xp5iccMO/ZgOecEexKwZQwzgjPIwfyr7PD1nVgpOLi+zOdqzFooorcQUUUUAIwLKQGKkjG4d R+deHatoGt+GfEEslxr2pSy3JPkX7+W7SJ12bmQlSP7oOO47ge5VT1TS7TWNPlsr2ISQyDkZ wVPZgexB5BFc2LwyxFJ03/XyKi7O5xvge+u9S8JWlzfTtcXBknRpWABYLM6jOABnCjtXQ1z3 gi0Fh4YSzEjSCC7u497AAti5lGTiuhr8hx8FDFVYLpJ/mzvjrFHnPj/V9atfEVlaabfz29v9 keeWOAJuf5wvBZTyAenesfw5qF/oV0NR0vVLm4hkO6SzlZVgl/vfKqjY3+0BnPUHkVreNv8A keLL/sGv/wCjFrnrlGsWkvYBmPG6eEfxAdWX/ax+f5Gvpsuqyo0abpaSa3stdXuYTV27nuui a3Z6/py3tk5252yRvw8TjqrDsR+RGCMgg1o14fpGoa5pV5Hqul6Lq7+Yi74zYS+Xcx9QCdvB 5yG7Z7gkH2fT7z7fp8F35E9v5qBzDcRlJEJ/hZT0Ir7jC15Vqd5xcX1TOaSsyzRRRXSIKKKK ACiiigAooooAKKKKACiiigArjvB3/Io6d/1zP/oRrsa47wd/yKOnf9cz/wChGsa+yOfEfCjc rzPxd/yPtx/2C7X/ANG3FemV5n4u/wCR9uP+wXa/+jbisIbnPDc5vxB/yLWq/wDXnN/6Aa+h a+evEH/Itar/ANec3/oBr6Frpp7HXS2CiiitDUKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKAOWuf+Sgyf9gpP/Rr1qVl3P/JQZP8AsFJ/6NesPV/Hcmi3cVrceHNS eed9sEMMsEkkoz94IshbHuRgVy1FeehxVU3N2NHxz/yIWv8A/YPn/wDQDXAV33jg58Aa+SCC dPm4Pb5DXA0obChsdT8Mv+Q/4g/697P/ANCnr0qvNfhl/wAh/wAQf9e9n/6FPXpVdMdjsh8K CiiiqKCiiigAooooAKKKKACiiigAooooAKKKKACiiigDjfBP/IheHf8AsF23/opa3awvBP8A yIXh3/sF23/opa3a4XuebLc8x8Z/8lBT/sFJ/wCjXrD1b/kDX3/XvJ/6Ca3PGf8AyUFP+wUn /o16w9W/5A19/wBe8n/oJrWPQ2j0Pd7D/kHW3/XJP5CrFV7D/kHW3/XJP5CrFdJ2BRRRQAUU UUAFU9W/5A19/wBe8n/oJq5VPVv+QNff9e8n/oJoA4ex1hrGw8LadFbedLf26DcZNixokalm 6HJ5GB39RWlp2rS3etapps9qIXsjGyOsgcSxvu2noCp+Rsj6da4/xC8c3hXwzposLW6urm3D wtcXDweT5cG4srp8wPQcevNdJ4OtdIj0G3vNKhEf26KO5lLTmaQsyg4Z2JJx0/OvyLEUacaL quOruv8AyZ679k1a3md6bvY4rWP+R78Qf78H/olarTf6y0/6/Lb/ANHJVnWP+R78Qf78H/ol arTf6y0/6/Lb/wBHJX0GC/iUfSH5Iyl1PfKKKK+9OUKKKKACiiigAooooA4PQru3sfD91c3c 8cEEd/el5JWCqv8ApUvUmthb21e+eyW5hN3GgkeAON6qeASOuOK4y+toZ/A9xLNd2tsLXV7m 5R7sZhLJeSEK46kE8cc81b8OR6hrurW/iW+GlLElq9vbnT5GlMgZlLFnZRwChwuOCTX5PmGH jKtXrN29+a+d9F5319Dvg9EjG8bf8jxZf9g1/wD0YtYmof8AINuv+uL/AMjW342/5Hiy/wCw a/8A6MWsTUP+Qbdf9cX/AJGvRwn8Gl6fqzOW7PcNB/5F7TP+vSL/ANAFaFZ+g/8AIvaZ/wBe kX/oArQr9HOQKKKKACiiigAooooAKKKKACiiigAooooAK47wd/yKOnf9cz/6Ea7GuO8Hf8ij p3/XM/8AoRrGvsjnxHwo3K8z8Xf8j7cf9gu1/wDRtxXpleZ+Lv8Akfbj/sF2v/o24rCG5zw3 Ob8Qf8i1qv8A15zf+gGvoWvnrxB/yLWq/wDXnN/6Aa+ha6aex10tgooorQ1CiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDlrn/koMn/YKT/0a9eVvpTQXGqeJLCHx IdN82Q3F/Fq6LLJGjEOyx7MlRg4BYcDtXqlz/wAlBk/7BSf+jXry/VLm0YSpp412XSZmubu4 02K6jji+zxPiWUZUsEZy37sMM4PTNc8vjZyz+NnoXjQqfh7rhViynTZiCepHlmuDru/GTxy/ DvW5IseW2mysmOmDGcVwlRHYzhsdT8Mv+Q/4g/697P8A9Cnr0qvNfhl/yH/EH/XvZ/8AoU9e lV0x2OyHwoKKKKooKKKKACiiigAooooAKKKKACiiigAooooAKKKKAON8E/8AIheHf+wXbf8A opa3a4iw1Y6L8KvDt7/aNjYKmn2oaW9iaRWHkj5VVWUlicYxnoeKl8F+Idc1+4nl1Eaaljsz brEClw/P3mTe+1fqc8jpXE1uzz3F6sw/Gf8AyUFP+wUn/o16w9W/5A19/wBe8n/oJrc8Z/8A JQU/7BSf+jXrD1b/AJA19/17yf8AoJrSPQ0j0Pd7D/kHW3/XJP5CrFV7D/kHW3/XJP5CrFdJ 2BRRRQAUUUUAFU9W/wCQNff9e8n/AKCauVT1b/kDX3/XvJ/6CaAPIvE81v8A8I34WtZbHSbi aW0MiPqcPmIgjhDMAMjBbCjOfwNbPw+it3s7jULWw0rToLxInjs7ELvRcMQZSP4jnp2x65qL U7XSZfBmiXGq6hZ2SQWsfltd28MyOSi8bZFJJ46KQTUvgK6guxqD2WnWUNorKiXlrp5s1uSC wPyEknae5x1PFfldaV8FJRvo3fe3xfd22u9PNncviOc1j/ke/EH+/B/6JWq03+stP+vy2/8A RyVZ1j/ke/EH+/B/6JWq03+stP8Ar8tv/RyV6+C/iUfSH5Izl1PfKKKK+9OUKKKKACiiigAo oooA8k1NVHgWad7+OyFvrM8weS3acMy3shVNikFstgYFJ4Gv5F1J7BNds9ShnWa9aO2sHiML PJkhmLkLyWwpGfyqa5sL3UPCW3T/ADftEOt3FwvlIjnKXkrD5XdAeQOM0eCre50y7ktZ7yYC dpZ3t5tHa2ZpGbcW80MysRkjAJ4+lfmeNlDlxEW7vnnpbz3+Fv8AFHbHp6FDxt/yPFl/2DX/ APRi1iah/wAg26/64v8AyNbfjb/keLL/ALBr/wDoxaxNQ/5Bt1/1xf8Aka1wn8Gl6fqyZbs9 w0H/AJF7TP8Ar0i/9AFaFZ+g/wDIvaZ/16Rf+gCtCv0c5AooooAKKKKACiiigAooooAKKKKA CiiigArjvB3/ACKOnf8AXM/+hGuxrjvB3/Io6d/1zP8A6Eaxr7I58R8KNyvM/F3/ACPtx/2C 7X/0bcV6ZXmfi7/kfbj/ALBdr/6NuKwhuc8Nzm/EH/Itar/15zf+gGvoWvnrxB/yLWq/9ec3 /oBr6Frpp7HXS2CiiitDUKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KAOWuf8AkoMn/YKT/wBGvXAa7pMmjWWsX154V0ZdPmbfcsNYlRpkD7wgBTA3H+AEAk45rv7n /koMn/YKT/0a9ZOu6S+laPqWp2eq6iv2eF7r7NNKs8bFAXA/eqxUZHYjFc0375yVHaoyx41Y N8PddZVKqdNmIBGMfIa4Ou68YO8nw41p3ILtpkpYgYGfLNcLUx2IhsdT8Mv+Q/4g/wCvez/9 Cnr0qvNfhl/yH/EH/XvZ/wDoU9elV0x2OyHwoKKKKooKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKAPJmYN8L/AAfZi106ea9hsraJ9QhEsULGDO/aepwCAOMlgKveGLP+wvFlzo0tvpEk rWYuUu7GxW2kVd4Uo6qTwTgg57GqTXlrbfCrwnBfw2clnd29lBO15ny408ncW474XC8j5iKr fDa4WDVJLOLTtPtYr2yGoBLcOZoVL4jSVmYkkqdw6d+K5OjOF7Mb4z/5KCn/AGCk/wDRr1h6 t/yBr7/r3k/9BNbnjP8A5KCn/YKT/wBGvWHq3/IGvv8Ar3k/9BNVHoVHoe72H/IOtv8Arkn8 hViq9h/yDrb/AK5J/IVYrpOwKKKKACiiigAqnq3/ACBr7/r3k/8AQTVyqerf8ga+/wCveT/0 E0Aea6jZ2Vz4W8OyXui6hfiK3jMdxp5/fWjbFwwAIY59s9OlXfAws44L+Gw8QSapAJt5iuIw s9u7lmbzOATuJzyo6HrWfqt1p1v4U8PR6hq+pWazW0ax2umlhLdtsX5QVBbj2I68mr3gQWZt r+XT/D39k2pmMYaVw087ozK3mdSCDwMsepr8orc31SV72vp2+Lz6/wCH59TuXxHL6x/yPfiD /fg/9ErVab/WWn/X5bf+jkqzrH/I9+IP9+D/ANErVab/AFlp/wBflt/6OSvawX8Sj6Q/JGcu p75RRRX3pyhRRRQAUUUUAFFFFAHl7QQXPg65guNHm1ZX1O8C20LBW3fapcNuJG0D1zxTPCdh runaw6alqiQ2ksJaDR5bv7VNHggbvNYBsDpjkc9aWaKWfwTexQ68miSPqV4BeOQAP9Kl+XJI xn1BBrJ+H1rDp3iXUYWTS7qa4iV0vrK+W4OFADBt5MgyTu7jPfpX5lilf61r9qWlr9el3ZfJ OWnQ7Y/ZH+Nv+R4sv+wa/wD6MWsTUP8AkG3X/XF/5Gtvxt/yPFl/2DX/APRi1iah/wAg26/6 4v8AyNbYT+DS9P1ZMt2e4aD/AMi9pn/XpF/6AK0Kz9B/5F7TP+vSL/0AVoV+jnIFFFFABRRR QAUUUUAFFFFAHIwePoLuBJ7bQdZmgcZSRY4gGHqMyA1L/wAJt/1Lmt/9+4f/AI7WJ4R/5FLS v+vdf5VtV50sZNNqyO+OFg0ncX/hNv8AqXNb/wC/cP8A8do/4Tb/AKlzW/8Av3D/APHaSip+ uz7If1SHdi/8Jt/1Lmt/9+4f/jtVfBTb/B2mNgruizg9Ryas1W8Ff8ibpn/XL+pq415VVqcG PoqnGNjerzPxd/yPtx/2C7X/ANG3FemV5n4u/wCR9uP+wXa/+jbirhuedDc5vxB/yLWq/wDX nN/6Aa9c/wCE2/6lzW/+/cP/AMdryPxB/wAi1qv/AF5zf+gGvW6KtaVJK3U9PB0VUTuL/wAJ t/1Lmt/9+4f/AI7R/wAJt/1Lmt/9+4f/AI7SUVj9dn2R2/VId2L/AMJt/wBS5rf/AH7h/wDj tH/Cbf8AUua3/wB+4f8A47SUUfXZ9kH1SHdi/wDCbf8AUua3/wB+4f8A47R/wm3/AFLmt/8A fuH/AOO0lFH12fZB9Uh3Yv8Awm3/AFLmt/8AfuH/AOO0f8Jt/wBS5rf/AH7h/wDjtJRR9dn2 QfVId2L/AMJt/wBS5rf/AH7h/wDjtH/Cbf8AUua3/wB+4f8A47SUUfXZ9kH1SHdi/wDCbf8A Uua3/wB+4f8A47R/wm3/AFLmt/8AfuH/AOO0lFH12fZB9Uh3Yv8Awm3/AFLmt/8AfuH/AOO0 f8Jt/wBS5rf/AH7h/wDjtJRR9dn2QfVId2L/AMJt/wBS5rf/AH7h/wDjtH/Cbf8AUua3/wB+ 4f8A47SUUfXZ9kH1SHdi/wDCbf8AUua3/wB+4f8A47R/wm3/AFLmt/8AfuH/AOO0lFH12fZB 9Uh3Yv8Awm3/AFLmt/8AfuH/AOO0f8Jt/wBS5rf/AH7h/wDjtJRR9dn2QfVId2L/AMJt/wBS 5rf/AH7h/wDjtH/Cbf8AUua3/wB+4f8A47SUUfXZ9kH1SHdmdY6t/a/jq4l+wXdns01F23So C371uRtZuK8t18f2XrEy+IPD/h20NzOxWUwyT7wSfmZUm3DPX7uK9SsP+R6uP+wan/o1q8zM OiaRr93pltbana+J7i5ZUjt9XEcMpbJDGUHKjH8BG7oADXRTm5+8zya0VCtKKPUPGmP+Fea5 jGP7NmxgYH+rPbtXB13njUMvw910N94adMDznnYa4OiOxzw2NTwXrf8AY/iDWh/Zt9eebb2v /HqqHbhpuu5l657Z6V23/Cbf9S5rf/fuH/47XE+C/wDkYNa/697X/wBCmrtayqYqUJcqR7GH w8Z01JsX/hNv+pc1v/v3D/8AHaP+E2/6lzW/+/cP/wAdpKKj67Psjb6pDuxf+E2/6lzW/wDv 3D/8do/4Tb/qXNb/AO/cP/x2koo+uz7IPqkO7F/4Tb/qXNb/AO/cP/x2j/hNv+pc1v8A79w/ /HaSij67Psg+qQ7sX/hNv+pc1v8A79w//HaP+E2/6lzW/wDv3D/8dpKKPrs+yD6pDuxf+E2/ 6lzW/wDv3D/8do/4Tb/qXNb/AO/cP/x2koo+uz7IPqkO7F/4Tb/qXNb/AO/cP/x2j/hNv+pc 1v8A79w//HaSij67Psg+qQ7sX/hNv+pc1v8A79w//HaP+E2/6lzW/wDv3D/8dpKKPrs+yD6p Duxf+E2/6lzW/wDv3D/8do/4Tb/qXNb/AO/cP/x2koo+uz7IPqkO7MDTLSe++GHhq2t9Vh05 5LG0G+a3SYSfuR8m1+Ceh9eKm8Ow65Y+KdQs7+Y31sbdHa+OnrbZkGAqgqfnG0n6YxUWlXWh 2nwv8OP4g+y/Ym0+1XF1GHQt5QxwQeeDVbwzqGhzeNGtfDdwrWA055JIoZZPLWTzEAwhO0cZ 6Ct+54HczfGf/JQU/wCwUn/o16w9X40W/P8A07yf+gmtzxn/AMlBT/sFJ/6NesLV/wDkC3// AF7yf+gmrXQ0j0PULPxptsbdf+Ed1s4jUZEcODx/10qf/hNv+pc1v/v3D/8AHar2f/Hjb/8A XNf5VPXN9cn2R7f1SHcX/hNv+pc1v/v3D/8AHaP+E2/6lzW/+/cP/wAdpKKX12fZB9Uh3Yv/ AAm3/Uua3/37h/8AjtH/AAm3/Uua3/37h/8AjtJRR9dn2QfVId2L/wAJt/1Lmt/9+4f/AI7V XU/GfmaVeJ/wj2tLugcZMcOB8p/6aVZqrqf/ACCrz/rg/wD6Caaxk+yD6pDuY89tNe+ENFgT w9aaxG1pHvS5nWLy/kXBBKnk89MYxUHgJIrO81nTI7aW0a3aN2tf7R+1xRF95+UkAqSQcg57 Gkudam0bSPCUkt19j0p4k+23Pl7guIgURjg7VY5Bb2HIzV3wnqMeo6vrstjcx3emNLHJDcRw BAZGB3qGAG/ACc9fm6mvzioqiw1S69163vLfmt/hv+NtRK10cnrH/I9+IP8Afg/9ErVK9l8i OCby3k2XVu2xMbmxKnAz3q7rH/I9+IP9+D/0StUr3/Vwf9fVv/6NSvbwbtOi/KH5IzavdHq/ /Cbf9S5rf/fuH/47R/wm3/Uua3/37h/+O0lFfV/XZ9ka/VId2L/wm3/Uua3/AN+4f/jtH/Cb f9S5rf8A37h/+O0lFH12fZB9Uh3Yv/Cbf9S5rf8A37h/+O0f8Jt/1Lmt/wDfuH/47SUUfXZ9 kH1SHdi/8Jt/1Lmt/wDfuH/47R/wm3/Uua3/AN+4f/jtJRR9dn2QfVId2cl9qun+HV3d2cWn xTNe3bj+1yFiizdSctjI3DPTpmofA+j3Gka9dR6jaaUdUeASXFxFfebPgkYAj8tQkZweB6d6 bcxQv8PDLLMkX2fVZ7hGlgeWMsl3IwDqgJ2nGCe1WfC98/iTxEms3N1onm29o8McOnzmWVld kJZ9yqQoK8DHc18JinK2IdtHOd3r30Xmvy3ZKVmkUPG3/I8WX/YNf/0YtYmof8g26/64v/I1 t+Nv+R4sv+wa/wD6MWsTUP8AkG3X/XF/5Gt8J/Bpen6siW7PSdG8ZeVoenx/8I9rTbbaNdyx w4OFHI/eVe/4Tb/qXNb/AO/cP/x2qOjf8gPT/wDr2j/9BFXa+1eMnfZGqwkLbi/8Jt/1Lmt/ 9+4f/jtH/Cbf9S5rf/fuH/47SUUvrs+yD6pDuxf+E2/6lzW/+/cP/wAdo/4Tb/qXNb/79w// AB2koo+uz7IPqkO7F/4Tb/qXNb/79w//AB2kPjcKpJ8Oa3gDJ/dw/wDx2imTf6iT/dP8qf12 fZB9Uh3NvQde0/xLo8GqabN5lvMoOCMMhxnaw7EZ/qMgg1pV8/eDNYvfD9lp19Y4bdaxCe3Y 4WdQo4Pow7N29wSK9y0bWbLXdNS+sZC0bfKysMNGw6qw7Ef/AFxkEGu+E1I4pQcTivCP/Ipa V/17r/KtqsXwj/yKWlf9e6/yqpp2iafq+ra9NfwNPJHfiNCZGG1fIhOAAemST+NeVGnzzaPR nV9nBOx0tFZn/CH6D/z4f+RX/wDiqP8AhD9B/wCfD/yK/wD8VWn1XzMfri7GnVbwV/yJumf9 cv6mqv8Awh+g/wDPh/5Ff/4qrPglQngzS1UYAhwB+Jq40vZp6nBjq3tIrQ368z8Xf8j7cf8A YLtf/RtxXpleZ+Lv+R9uP+wXa/8Ao24rSG5wQ3Ob8Qf8i1qv/XnN/wCgGvW68k8Qf8i1qv8A 15zf+gGvSP8AhD9B/wCfD/yK/wD8VSq0vaJanpYSt7JPTc06KzP+EP0H/nw/8iv/APFUf8If oP8Az4f+RX/+KrH6r5nZ9cXY06KzP+EP0H/nw/8AIr//ABVH/CH6D/z4f+RX/wDiqPqvmH1x djTorM/4Q/Qf+fD/AMiv/wDFUf8ACH6D/wA+H/kV/wD4qj6r5h9cXY06KzP+EP0H/nw/8iv/ APFUf8IfoP8Az4f+RX/+Ko+q+YfXF2NOisz/AIQ/Qf8Anw/8iv8A/FUf8IfoP/Ph/wCRX/8A iqPqvmH1xdjTorM/4Q/Qf+fD/wAiv/8AFUf8IfoP/Ph/5Ff/AOKo+q+YfXF2NOisz/hD9B/5 8P8AyK//AMVR/wAIfoP/AD4f+RX/APiqPqvmH1xdjTorM/4Q/Qf+fD/yK/8A8VR/wh+g/wDP h/5Ff/4qj6r5h9cXY06KzP8AhD9B/wCfD/yK/wD8VR/wh+g/8+H/AJFf/wCKo+q+YfXF2NOi sz/hD9B/58P/ACK//wAVR/wh+g/8+H/kV/8A4qj6r5h9cXY06KzP+EP0H/nw/wDIr/8AxVH/ AAh+g/8APh/5Ff8A+Ko+q+YfXF2HWH/I9XH/AGDU/wDRrVof8IxoZ0qXSzpdsbKVi8kRT7zH ksT13c/ezmsfRdLs9K8bXMVlD5SPp0bMNxbJ8xvUmuurVLkVjx8VPmquSOe8bqE+H+vKowF0 6YD/AL4NcFXf+Of+RC1//sHz/wDoBrgK0hsZw2NTwX/yMGtf9e9r/wChTV2tcB4X0aw1bxDq 5vrfzfLt7bZ87LjLTZ6EegrrP+EP0H/nw/8AIr//ABVZVKHNLmuetQxKhTUbGnRWZ/wh+g/8 +H/kV/8A4qj/AIQ/Qf8Anw/8iv8A/FVn9V8zb64uxp0Vmf8ACH6D/wA+H/kV/wD4qj/hD9B/ 58P/ACK//wAVR9V8w+uLsadFZn/CH6D/AM+H/kV//iqP+EP0H/nw/wDIr/8AxVH1XzD64uxp 0Vmf8IfoP/Ph/wCRX/8Aiq5nxfpNtoUmi3OjhrO5a9KmRXZgR5MhwQTgjIGRR9VfRgsYux3N FY+g69HrELI6iG9iA86HOf8AgS+qn1/A81sVzSi4uzOuMlJXQUVy3hbwxpF94R0W7urVpbie wgllkaZ8uzRqSTz1JNa3/CHaD/z4f+RX/wDiq6fqvmcn1xdjTorM/wCEO0H/AJ8P/Ir/APxV H/CHaD/z4f8AkV//AIqj6r5h9cXY06KzP+EO0H/nw/8AIr//ABVH/CHaD/z4f+RX/wDiqPqv mH1xdjm9Rnjt/g74Ykk8RzaCBa2e25hR3Mh8jiPCEHB659qj+F2pXt/qV2Lq8vbpVhOySfVF mV/mXkQEb0Pufp3qzcS+R8I/C8qpazSra2flWlzZ/aRdN5P+qCgEhiMkMOmPTNT+Bro3fiK/ M+k2eg3EcOwaTHZhJdmQfNaUAbxngBeB35rq+yzxPsso+M/+Sgp/2Ck/9GvWFq//ACBb/wD6 95P/AEE1u+M/+Sgp/wBgpP8A0a9YWsc6Jf8A/XvJ/wCgmmuhUeh6fZ/8eNv/ANc1/lU9Y1p4 Q0JrKBjY5JjUn96/p/vVN/wh2g/8+H/kV/8A4quT6t5ns/XF2NOisz/hDtB/58P/ACK//wAV R/wh2g/8+H/kV/8A4qj6r5h9cXY06KzP+EO0H/nw/wDIr/8AxVH/AAh2g/8APh/5Ff8A+Ko+ q+YfXF2NOqup/wDIKvP+uD/+gmq3/CHaD/z4f+RX/wDiqraj4R0JNMu3WxwywuQfNf8Aun3p rDeYfXF2MPxFcy23g3w88NrrUrG2jBl02Zo1iXYmTLtVsr9VPQ9K1Ph/fXt7ZXf2zxBY6rsZ BHHbgb7cc8SYVDk+6joauWuhWut+GNES7mu1hjs48xQXLxLJlF+/tIJ6evc1p6P4f0nQIXi0 rT4LVZCDIY1+ZyOhZurdT1PevzaviaP1eVG3v3etl37vVfK3mNJ3ued6x/yPfiD/AH4P/RK1 Svf9XB/19W//AKNSrusf8j34g/34P/RK1Q1GJJ7eKKRdyPcwKwzjIMqV7uDV50fSH5Izbtdn rFFZn/CHaD/z4f8AkV//AIqj/hDtB/58P/Ir/wDxVfV/VfMv64uxp0Vwni7S7fQbrRLjRt1n cNdOpcOzBgInOGBOCMgcfyrpNC12LWIGVlEN5EB50Gc49GU91PY/geRWdSg4K+6NqVeNR22Z r0UVy3hbwxpF94R0W7urVpbiewgllkaZ8uzRqSTz1JNKlS9pfUK1ZUrabnU0Vmf8IdoP/Ph/ 5Ff/AOKo/wCEO0H/AJ8P/Ir/APxVa/VfMx+uLsYLu6/D2YR6rc6ZI2oXSrPbW7TSE/apflCr zz6iq3w+sr2PWbm5vfDMsMhjKnWLmWQSzcj5THKzOAcZ4OOK6fwXClv4bEMS7Y47y8VRnOAL mUCugr87xuMdOpXoJbylr8/K1/m2vIaV7SPN/G3/ACPFl/2DX/8ARi1iah/yDbr/AK4v/I1t +Nv+R4sv+wa//oxaxNQ/5Bt1/wBcX/ka9HCfwaXp+rM5bs9J0b/kB6f/ANe0f/oIq7WBpPhH Q5NGsXexyzW8ZJ81+TtHvVz/AIQ7Qf8Anw/8iv8A/FV9o8NruWsYuxp0Vmf8IdoP/Ph/5Ff/ AOKo/wCEO0H/AJ8P/Ir/APxVL6r5h9cXY06KzP8AhDtB/wCfD/yK/wD8VXL+LtLt9ButEuNG 3Wdw106lw7MGAic4YE4IyBx/Kj6q+jBYxdju6ZN/qJP90/yrL0LXYtYgZWUQ3kQHnQZzj0ZT 3U9j+B5Fak3+ok/3T/KuZxcXZnWpKSujx7RP+QDp3/XrF/6CKyvEuvat4fngbSNRuLJrgHzj A5XftxtzjrjJ/OtXRP8AkA6d/wBesX/oIrmfHv8ArLD6P/7LXoUv4hw1PgPcPCP/ACKWlf8A Xuv8ql8Of8f/AIi/7CY/9J4Ki8I/8ilpX/Xuv8ql8Of8f/iL/sJj/wBJ4Kxo/wASX9dS8T/C ib1MmSSSCRIpPKkZSFk252nHBweuKfRXUcB5oPEHiTSdVl0/xJqL26qS0V5a2KyxvH/eK/eH bOA2D1xxn0Lw1FZQeHbKHT75L62jj2rcIwIf1PHHXtUGsaPbazZ+RPlXU7opk+9E3qP6joRw a82ltbrQNYaNLl9M1N+RLbnEd0P72w5V/cEFh69CSS5jCrBs9lrzfx5BpY137X/btzBqLWyQ Gxs4EnkdVZ2UkH7n+sbliB71l3vinxFqEqWF7fR2UTDAksEMbXHqN5JKHHZcHuG6gV7a0gtI ykESoGO5iOrH1J6k+55qYxsZRjbU528sPEU+mX4a6SVZoHjjtJEUNhlIyXUABvbkds969ysr 221Gzju7SUSwyDKsP1BHUEHgg8g15rUllq8nhyeS+jYG0bm6gZgoYdN6k8BwPwI4PYi9zaE7 aM9OoqK1uYry0huoGLRTIJEJUqSpGRweR+NS0jYKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKK4nxH4q1zw/rqQzWNqukz/6i92ySbWxyrqvIPBPAPH0OGB0Fr/yPc// AGDE/wDRr10Vcx4bjuL/AFGTXZL7TbqCW2W3iNgzMvDFiST35xiunrKW5w1WnK6MDxz/AMiF r/8A2D5//QDXAV6b4g019Z8O6lpkcixPd20kKuwyFLKRk/nXkervfabO9pa3mnalfIcNBaK5 EZ/23J2r9Cc+xqobWHDVWOn8Df8AIwa3/wBe9p/6FNXdV558PZpxrurR3yRxXMltb7QjZWQK 0u4pnkgblz6ZHqM+h1bOuOwUUUUigooooAKKKKACuL+If3NC/wCv9v8A0RLXaVxfxD+5oX/X +3/oiWmtwOZBkjmjuLeUw3MRzHKBnHqCO4Pcd/yNd/oGqnWtFgvmiETuXR0ByAyOUOPbKnHt XA11ngP/AJFG3/6+Ln/0okrDFxXKn1OzByfM49DR8Gf8iL4e/wCwZbf+ilrcrD8Gf8iL4e/7 Blt/6KWtyt3ucYUUUUgCiiigDN8FAHwF4cJAJGmWxHt+6WtwopcOVG8AgNjkA4yP0H5VieCf +RC8O/8AYLtv/RS1u1k9zzpbnmPjP/koKf8AYKT/ANGvWFq//IFv/wDr3k/9BNbvjP8A5KCn /YKT/wBGvWFq/wDyBb//AK95P/QTWsehvHoesWX/AB4W/wD1yX+QqeoLL/jwt/8Arkv8hU9B 1BRRRQAUUUUAFVdT/wCQTef9cH/9BNOv5bqCwnlsrZLq5RC0cDy+WJD6bsHH5Vw+neNNT8SR z6cmmaVZX7q8TWl5qUscqnkHA+z4bH+yTWVatTox56jshpNuyOy8Pf8AItaV/wBecP8A6AK0 qqaXavY6TZWkjKzwQJExXoSqgHH5Vbr8fqtOpJruz0lseU6x/wAj34g/34P/AEStU7z7lv8A 9fdv/wCjUrX8WaRfadrmpa21zpEVldmPabu7eJ9yxhdoURtuJxwBz7VyY1K+lMJvNNFtb/a4 Ns6ylgQJVOSrKrKMA8kD6V9jl69o6U47LkW/VJXOeelz3OiiivtDkOJ+If8ArNB/6/H/APRM lc2DLFPHc20phuYjmOQDOPUEd1Pcf1ANdJ8Q/wDWaD/1+P8A+iZK5yrSurMabWqO+0HVP7a0 W3vzF5TSblZM5AZWKnB9Mg4pPBn/ACIvh7/sGW3/AKKWs/wJ/wAifaf9dJ//AEc9aHgz/kRf D3/YMtv/AEUtclBJSkl3/wAzrxLvGDf9bG5RSNnadoBOOATiuDt/H2qPq02lXujabpl7G+xY 77VJEEmehVxAVOewzk+la1KkacXObskciTeiOk8I/wDIBb/r+vP/AEplrdrK8O2FzpujLb3n lC4aaeZxC5dF8yV5MAkAnG7GcDpWrX5Jj5xqYqrODunKTX3s9GCtFI838bf8jxZf9g1//Ri1 iah/yDbr/ri/8jXU+N9FvpdVg1uCfTIrW3tGhmN9dNAFy4YHIRh2x2rgJ9T1Ce3ul/s2N7Ty mAuYJnIbI6qjxoxHPXHTpmvocAvaUabj0WuvmYz0bPZ9F/5AWn/9e0f/AKCKvVQ0Nlfw/pro wZWtYiCDkEbRV+vvTjCiiigArifiH/rNB/6/H/8ARMldtXE/EP8A1mg/9fj/APomSnHcDmwZ Yp47m2lMNzEcxyAZx6gjup7j+oBrvNH1T+2vD0d+YvKaRXVkzkBlJU4PpkHFcJXVeC/+RIg/ 3rj/ANGvWGLiuVPqdmEk+Zx6HA6J/wAgHTv+vWL/ANBFcz49/wBZYfR//Za6bRP+QDp3/XrF /wCgiuZ8e/6yw+j/APstVT/iBU+A9w8I/wDIpaV/17r/ACqXw5/x/wDiL/sJj/0ngqLwj/yK Wlf9e6/yrHnTzTqkBeVY5vEVvHJ5cjIWUxQZGVINc0Zqm5zeyTf3GmIV6UV6Hd0Vjf8ACIaP /cvP/Bhcf/F0f8Iho/8AcvP/AAYXH/xdeJ/rZg/5Jfcv8zn+ry7mzVe9sbTUbZra9toriBus cqBh9ee9Z3/CIaP/AHLz/wAGFx/8XR/wiGj/ANy8/wDBhcf/ABdH+tmD/kl9y/zD6vLuc9q/ gKTyXGlXHmQnn7JduTj02S8spHUZ3c9xXKC+l0y5NhrccllcKCUe5AQSqOuGHykjvtJHfjkD 0z/hENH/ALl5/wCDC4/+LpkngrQpgolgunCsGAa+nOCOh+/1p/624P8Akl9y/wAyHhGzjtP0 zVtZwbG18i2P/L3dqVUj1VOGf/x0Hsa6zSvB2nafKlzc7r+9Q5Wa4wQh/wBhPur9cZ9Sasf8 Iho/9y8/8GFx/wDF1zni7TU8P/2NdaPPdW1w9/5ZZrqWVWXyJm2srsQRlR/iK1ocT4StUVOM ZK/kv8w+quKud5RWPoGvxa1bsrKIb2IDzoM5x6Mp7qex/A8itivoYyUkpR2MgooopgFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVXvbK21GzktLuISwyDDKf0IPUEHkEcg1Yoo A8tv9Gu/DOr+ZBdz2ksxxBfwEL5/+xKuNrOPccjkY5A2I/iNf6ZZv/a+lfa2UYS4smCIx/6a K5+QerAsPYV2l3Z21/avbXcEc8Egw0cqhlP1BrkNQ8DywBn0W6yn/PneMWT6LJyy/juH0oaT 3Mp0kzG1LVdZ17cuo3nkWjf8uVkxRCOeHk4Z/wDx0exqCGGK3iWKGNIo14VEUKB9AKzHll0C 6W01C3ls4WOEScf6v/dYZV0+hO3vgfd0Z7mG2QPNIqBiFXPViegA7n2FOxm01oPdGLJJHI0U 0bb4pUOGRvUf4dCMg8Gu28O+Il1VTa3QWLUY1yyDhZV/vp7eo6g+xBPL6f4e1nVsP5f9m2p/ 5a3CZmYf7Mf8P1Ygj+6a6/R/DWm6KxmgjaW7ZdrXU7b5WHcZ6KPZQB7UGsFJbmvRRRSNAooo oAKKKKACuL+If3NC/wCv9v8A0RLXaVxfxD+5oX/X+3/oiWmtwOarrPAf/Io2/wD18XP/AKUS VyddZ4D/AORRt/8Ar4uf/SiSscX8C9Trwfxv0NHwZ/yIvh7/ALBlt/6KWtysPwZ/yIvh7/sG W3/opa3K2e5yBRRRSAKKKKAM7wT/AMiF4d/7Bdt/6KWt2sLwT/yIXh3/ALBdt/6KWt2snued Lc8x8Z/8lBT/ALBSf+jXrC1f/kC3/wD17yf+gmt3xn/yUFP+wUn/AKNesLV/+QLf/wDXvJ/6 Ca1j0N49D1iy/wCPC3/65L/IVPUFl/x4W/8A1yX+Qqeg6gooooAKKKKACuU8W+EYdaja7t4I nvABvifAW4A6Ans4/hb8Dxgjq6KmcIzjyy2GnY8v0rxFrekDbBM1/bISr2d+xEsZGcqJOSCO mHDfUVeu/H+o6mZLbSLP+zzHhZZr3a8ikj+CNSQR6MTj2NdNrPhTT9YlNyfMtb0gD7TbnDHH QMDlXH1Bx2xXC614b1nTGFw0IufKHyXlohPHpJFy2D/s7sdcivmMTkcVP2igpf11WzN41dLE AtQ10by5llu7w8G4uG3vj0HZR7KAPapmVXUqwDKRggjIIqrp+ow6jAXiZdy8OoYHafr3Hof/ AK4qxbfaNSnaDS7WS9lU7XZOI4z/ALTngfTk+1ccaNWc+RJtou6WpveHfER0to9P1CQmyJCw XDnmE9kc/wB30Pboexru643T/AiygSa7c/ac/wDLpBlIR7MfvP8AjgH+7XYqoVQqgBQMADtX 1mEjWjSSrPX+tzmla+hxXxD/ANZoP/X4/wD6JkrnK6P4h/6zQf8Ar8f/ANEyVzldq2JOt8Cf 8ifaf9dJ/wD0c9aHgz/kRfD3/YMtv/RS1n+BP+RPtP8ArpP/AOjnrQ8Gf8iL4e/7Blt/6KWu Sj8c/X/M68R8EPT/ACNysPxJ4btvEFpghEukUiORl3Ajujjup9PxHNblFbSipKzOQ8q0+91v w5O9rZzmPyCFk028JkiX02N95QexGV/2c5Fa1x8Rb6422dlpAtL7ZukkvJA0ajOMxhTmT8dm OM+ldXrHh7TtcVDdxMJowRHcRMUkT6MO3scj2rhta8H6taR7o86jAh3RzQAJcRH12dH99vXp tr5rGZHCU/aKKl+fz/m+ep0Rq6WKE0Mt7dLd6ndS390pyjzY2xn/AGEHyr9QM+pNTVQ0/Uku ne3kKrdRcOuCuffB5Hup5H5E2kla4ujaWUEt5dDrDAMlfQsTwg92Irg9jVc/ZqOq6F3W5qaH rknh+by3DSaW7ZeNRkwE9XUd19V/Ec5B9EiljnhSWJ1kjdQyOhyGB6EHuK4rT/BFzc4k1q68 uM/8ulm5Gf8Afl4Y/Rdv1NdlaWlvY2sVrawpDBEu1I0GAor6nAwrwpctb5f8E55tN6E1FFFd hAVxPxD/ANZoP/X4/wD6Jkrtq4n4h/6zQf8Ar8f/ANEyU47gc5XVeC/+RIg/3rj/ANGvXK11 Xgv/AJEiD/euP/Rr1ji/gXqdeE+N+hwOif8AIB07/r1i/wDQRXM+Pf8AWWH0f/2Wum0T/kA6 d/16xf8AoIrmfHv+ssPo/wD7LTp/xB1PgPcPCP8AyKWlf9e6/wAqyW/4+r7/ALGW2/8ARUFa 3hH/AJFLSv8Ar3X+VZLf8fV9/wBjLbf+ioK4av8ADq/4ZGtb+HH1R3tFFFflBZ5bf+N9csrx 7QSo76bqUzahmNdzWSyRhcADglZhzx92rWkeIvEHiXVfsFrqcdlHNHPfxXH2ZZG8gTGKOMA4 H8JYk5JyOa6SfSvC013qV7M9o0urgabcubgfvWAK+UOeG7YHPHtVHUNP8Exw2dnNqdrYvp8Z tYmi1H7PKiYG6MsGBI6ZB9c9a95V8NKKjGk1Lvyp9NdOtnt5fcZWl3My78Yazo3iGxh1GW0n 046ajXk9qMxxTPI6JKCedhKqD2G6ut8J6hcar4R0jULtw9zc2kcsrBQMsVBJwOlZRg8DQQiB rvSkhnsBaLE14oV7fLEYG7nkt83XPeuj02xtdM0y1sbJdtrbxLHEu4thQMDk9a5MZUouklGm 4yvva10r/jd/giop33LVcZ8RP+PbQv8AsJ/+209dnXGfET/j20L/ALCf/ttPWOX/AO8R+f5M J7HLq0sNxHdWsphuojmOQDOPUEd1Pcf1AI9E8P6t/bmiw35i8pmaSN0zkB0dkbB9Mqce2K88 roPArXOo+HF06xZogl3d/arsD/VA3MhCpnguQQfRQQT2B+8yiu4qUZP3UctSN9jtqK5/Srbx XpukWdjLpdndSW8KxNO2pNmQqMbjmMnnrVzzPE//AEArH/wZH/41XtfWKX8yMuVmpRWCmleJ rjV5NTdYLMxW6xxWq3ZljnO4lg3yDbxgBhkg+oyDW1WS21u68P2sqSCOTU3iurZ2KMrLazts fB7EKeuDwRkYNVCrCbai72Jl7quzp6Kzf+EL8P8A/QPH/f6T/wCKo/4Qvw//ANA8f9/pP/iq rnRh9Yj2NKis3/hC/D//AEDx/wB/pP8A4qj/AIQvw/8A9A8f9/pP/iqOdB9Yj2NKis3/AIQv w/8A9A8f9/pP/iqP+EL8P/8AQPH/AH+k/wDiqOdB9Yj2NKis3/hC/D//AEDx/wB/pP8A4qj/ AIQvw/8A9A8f9/pP/iqOdB9Yj2NKis3/AIQvw/8A9A8f9/pP/iqP+EL8P/8AQPH/AH+k/wDi qOdB9Yj2NKis3/hC/D//AEDx/wB/pP8A4qqOlaJ4O1y0N3pkcV1AHMZeOeQgMOo69eaOZB7e PY6CisKPw94Sl1ObTUt42vYY1kkhE0m5VPQnnvTLHRPB2p3F5b2UUU81lJ5VwiTyExPzwefY /lT5kP267HQUVy8dl4EltLW6ja3eG6n+zQMs8hLy5I2AZzng8Vrf8IX4f/6B4/7/AEn/AMVR zIXt12NKis3/AIQvw/8A9A8f9/pP/iqP+EL8P/8AQPH/AH+k/wDiqXOg+sR7Fu7s7XULZ7a8 t4riB/vRyoGU/gaztI8LaNoT+ZYWSpKAVWSR2kdF/uqzElV9hgVN/wAIX4f/AOgeP+/0n/xV H/CF+H/+geP+/wBJ/wDFUc6D28expUVm/wDCF+H/APoHj/v9J/8AFUf8IX4f/wCgeP8Av9J/ 8VRzoPrEexpUVm/8IX4f/wCgeP8Av9J/8VR/whfh/wD6B4/7/Sf/ABVHOg+sR7GlRWb/AMIX 4f8A+geP+/0n/wAVR/whfh//AKB4/wC/0n/xVHOg+sR7GlRXmngPxPNY6Jp1tqs7SWkkKeXc yHJhJH3XP9z0PboeOnpdWzZO4VxfxD+5oX/X+3/oiWu0ri/iH9zQv+v9v/REtC3Gc1XWeA/+ RRt/+vi5/wDSiSuTrrPAf/Io2/8A18XP/pRJWOL+Bep14P436Gj4M/5EXw9/2DLb/wBFLW5W H4M/5EXw9/2DLb/0UtblbPc5AooopAFFV7+xg1KwmsrlWaCZSjhWKnHsRyK8uOkTeENQFnqN iNasJCfs80krRzsP7u4EKzgZ+VgMjkN1AYm7K56R4J/5ELw7/wBgu2/9FLW7WD4b8QaHqVrF Y6XIsDW0SoLGRfLlhQAADYewGBkZHvW5LLHDE0srrHGg3M7HAUepNYvc4HueZ+M/+Sgp/wBg pP8A0a9YWr/8gW//AOveT/0E10HifXPD2t3Iex0eLWLpE8tb2RmjgQZJxvHMgzn7oI9xXHv4 YgmE8jzMlxKhRTBlI4gcjCpk5GDg7iT7itY7am0dtT2iy/48Lf8A65L/ACFT1h+Gtbi1OyW3 cCK9t0VZoc9ugZfVT+nQ81uUHUFFFFAGVf69DY34sRaXt1P5QmZbaHftUkgE8+qn8qh/4SM/ 9ATWf/AX/wCvSwf8j1d/9gyD/wBGy1vV8lmvENfB4qVCEE0rb36q/c6adFSjdmB/wkZ/6Ams /wDgL/8AXo/4SM/9ATWf/AX/AOvW+eR1xXlUHj3WoLrSReSRtb2Urwa45jAwzSvFGf8AZwUB 4xnNY4biHG4lN04R09fP87W9WhyowW7O2/4SM/8AQE1n/wABf/r0f8JGf+gJrP8A4C//AF65 TQdb8WeJLWWNNUttPns7OK6kkktlcTNNvdFPZUVAoJHPU5qLU/Her6RrGvQXkluLSKxT7PcR KCkN01uZAMnqrENjOeQB3rp/tjHuo6cYwclrb3vK333T/wCDoL2ULX1NTULLQtTv1vrnwpqx uP43jt2j80ekgVhvHA+9npWxBrkVrAkFv4f1WGFBtSOOzCqo9AAeK2dNme40qznlO6SSBHY4 xklQTVqvMlxXiYtr2cfx/wAy/q8e5zVz4wtLFElv7DUrOBpFjM89vtRSxwMnPAya6BWV1DKQ VIyCDwRXMfET/kV4/wDr+tf/AEctYmga+2hMLW6YtpZPyt1Nqf8A43/6D9Onv5VnX1uCdZKL baVtun+ZjUpcuxd+If8ArNB/6/H/APRMlc5XRfEFlc+H2UgqbtyCDwR5Mlc7X0S2MTrfAn/I n2n/AF0n/wDRz1oeDP8AkRfD3/YMtv8A0UtZ/gT/AJE+0/66T/8Ao560PBn/ACIvh7/sGW3/ AKKWuSj8c/X/ADOvEfBD0/yHTeJIUvbm1h0/UbpraQRyvb2+5QxVWxnPow/Ok/4SM/8AQE1n /wABf/r07w9/yEfEf/YTH/pPBW7XymP4lr4bEzoxgmou3X/MUKClFO5gf8JGf+gJrP8A4C// AF6P+EjP/QE1n/wF/wDr1a8SzX1v4Y1O402QR3sNs8sLFA3zKM4weucY/GvO7r4jaqZ7+7tX T+z7q1MOlr5YLC7Cw5z6jMp46fIarC57j8Ur04R/Hy/z/BilRhHdnR6vHpGuyRy3/hjV3njP yTx27RyAem9WDY5PGe9X7LVLXTbVbay8N6pbwLyEisgoz3PB6+9Zukah4j1ZrjUE1a0htrTU GsjaT24USqjBGZn6h2OSABjoMVjWXj3V2vhp96yRzTa2IrSUIuJ7YXBidMf3lwPfDA1cc5x0 m+WMG1v8X9aeX+Yeyh5nZ/8ACRn/AKAms/8AgL/9ej/hIz/0BNZ/8Bf/AK9b9Fed/rbif+fc fx/zL+rx7nOr4tsV1K0sby2vbGW7JWBruHYrsMfKDnrzx+XXFb1cF8SI0l1Tw9HIoZGNyCpH BGwVa8NeJXhki0vVJSwYhLa6c8se0bn+96N/F0PP3vpcszZYunF1FaUvu3a/QwqU+V6HZ1xP xD/1mg/9fj/+iZK7auJ+If8ArNB/6/H/APRMle1HcyOcrqvBf/IkQf71x/6NeuVrqvBf/IkQ f71x/wCjXrHF/AvU68J8b9DgdE/5AOnf9esX/oIrmfHv+ssPo/8A7LXTaJ/yAdO/69Yv/QRX M+Pf9ZYfR/8A2WnT/iDqfAe4eEf+RS0r/r3X+VZLf8fV9/2Mtt/6KgrW8I/8ilpX/Xuv8qyW /wCPq+/7GW2/9FQVw1f4dX/DI1rfw4+qO9oqC+vItPsLm9nJENvE0smBk7VBJ/QVzEPirWBp L6tdeH0SwbT5L6F47sMw2ruCSDaNpYd13Yr8vpYepVXNH03S1+e5TaRyWueFdUvPEOu20Vtc iytmk1ixlWP5ZLpkjwoPchlk/wC+qpxaNqS6rpmp3dnqFpJeW91c3bR6absxyyzBlRk2kA7Q B0yMV6TceIzFomjaitqD/aU1rH5Zf/ViYjnOOcZ9s1zuhfEG91mMXH2bRUh2TOYF1TNyBGG/ 5ZbO+316HNe9SxWMlSuoLljpuuzT33vvtuZOMb7mBrmlXNzr080cWpR20uixQJLHoZl8yQF9 wKFMRnnPbrXpXhlLiLwtpMd1bfZZ0tIleDcW8shQMZNczpPxEfXLfR1sdOjF9fpOJLeaYr5E kcYdQTtJwwZTnHQ0yHx3rCaVq2o3uiWqQadcmzbybxnPmh1Uk/uxhAGJLcnjpWGKpYutBUZQ Sat1V93Fdt2v8rIcXFO9zvq4z4if8e2hf9hP/wBtp62PDOuTa9ZTzyw2qiOXy0mtLtbiGZcA 7lYAEdcEEAisf4if8e2hf9hP/wBtp64cHTlSxahLdX/JlSd4nKzI0kDokhjZlIDgZKn1r0Xw Lren6loUVra2q2Ultvja3GcHa7IzqTyyllbk85688nz2ul8G2Iu/B9s6SNBdQ3t40E6D5o2+ 0y/mD0IPBFfZZbS9rzxOabsd+b21UkG5hBHBBkFJ9utP+fqD/v4K5HSPB2kWOj2VpdaZp1zc QwoksxtUzIwGC3IzyfWrn/CM6B/0A9N/8BI/8K9b+z1/N+Bn7Q6aOeGYExSo4XrtYHFcLqU8 Wp+NvDWpWkKi1F5JALnJBuT9luCGAzgouGAY5zuOMDlpj4Ttk1l57Zbe006a3WK4tbeER+eQ xIDEfw88jv06ZBXxNfWek33hu8vbiK1tIdSbfLIQqoDa3CjJ7ckD8a1oYNU5OV7kVJXg0ddR XOf8J/4R/wChj03/AMCFo/4T/wAI/wDQx6b/AOBC1vys87lfY6Oiuc/4T/wj/wBDHpv/AIEL R/wn/hH/AKGPTf8AwIWjlYcr7HR0Vzn/AAn/AIR/6GPTf/AhaP8AhP8Awj/0Mem/+BC0crDl fY6Oiuc/4T/wj/0Mem/+BC0f8J/4R/6GPTf/AAIWjlYcr7HR0Vzn/Cf+Ef8AoY9N/wDAhaP+ E/8ACP8A0Mem/wDgQtHKw5X2IfiHqV1YeELmDT0Z9R1BlsbRV6+ZIduc9sDcc+1cV4XutR8C axqFpe+HLi1sruxFza2ttKs5eWBFWTaRgbmUbiOvy13f/Cf+Ef8AoY9N/wDAhaP+E/8ACP8A 0Mem/wDgQtUrpWsUrpWscVB4mh/t7xb4z09JZrGLTIIYXaJl3z84QAgZwSoOOmao+ErbWfBX iTSZtX0c2FpqFubK9uTcrKJbjc0qyvt+6SSy89j1r0P/AIT/AMI/9DHpv/gQtH/Cf+Ef+hj0 3/wIWnd7WKu9rHnWlOkHj2PxhNpzx+G76+mhs97H/R52CqbkoeAJCrDPbrXtFc5/wn/hH/oY 9N/8CFo/4T/wj/0Mem/+BC0pXfQmV5dDo6K5z/hP/CP/AEMem/8AgQtH/Cf+Ef8AoY9N/wDA hanlZPK+x0dFc5/wn/hH/oY9N/8AAhaP+E/8I/8AQx6b/wCBC0crDlfY6Oiuc/4T/wAI/wDQ x6b/AOBC0f8ACf8AhH/oY9N/8CFo5WHK+x0dFc5/wn/hH/oY9N/8CFo/4T/wj/0Mem/+BC0c rDlfY6Oiuc/4T/wj/wBDHpv/AIELR/wn/hH/AKGPTf8AwIWjlYcr7HmHh4BvDWnqwBBt1BB7 8V2PhHVp4dQTQpSZYDA81u5PzRKhUFD6j5xj0wR0xjjvDhB8N6cQcjyF/lXQ+Gv+R3tP+vG5 /wDQ4a26nTB+8ei1xfxD+5oX/X+3/oiWu0ri/iH9zQv+v9v/AERLQtzc5qus8B/8ijb/APXx c/8ApRJXJ11ngP8A5FG3/wCvi5/9KJKxxfwL1OvB/G/Q0fBn/Ii+Hv8AsGW3/opa3Kw/Bn/I i+Hv+wZbf+ilrcrZ7nIFFFFIAqtf2FtqdlJaXcYkhccjOCD2IPUEHkEdKs0UAeWa5oU+mP8A 8TC2luLSJt0OoxDmP3Yr80bDuwwvfIzgZl3PNdNC2rajcappuFELTyBo4z2LAAB89nbJHr3r 2aua1XwTpt+ZJrTNhcyZ3tCoMchP9+M/K2e54PvTM3T7HJUVC+i6/oNwLW40+W9tGO2CeyUy bT2Vl+8o9zwOhY9a3NP8H6lf4k1Sf7BAefs9uwaY+zP0X6Ln2YUWM/Zu5hPctDewfY3l/tJf mgS3QvJ7/KOqnvnj3HWvT9Omu7jTreW+thbXTIDLCHDbG7jI4NR6Zo+n6PAYbC1SFWOXYcs5 9WY8sfck1eoNox5UFFFFIoxYP+R6u/8AsGQf+jZa3qwYP+R6u/8AsGQf+jZa3q/MuI/+RjU+ X5I76PwIK5i58NeFJLfxDDNHbiO+ZZdV/wBIIwQNwLHPyf3u3XNbupXUtjplzdQWkt3LDGXW 3ixvkx2HvXm+pQ6trc2qR2Oj3n2fWtQtwwuo2gBt4oVMm8lTsDEbBkc5OK5MBSnJuSnyrTW9 tmn36LVehUmjrL3w94Z1K4sy0ipLPaiGIW140RubdRnb8rDegBz360270XwlLp2rrcNZrZXH l2t7m4CohjAVEznCMMrxwelcnDYa5pnh23J0mZ9R8M6iGtY4dz/aLSTgxxvgbsK5U8cbB0ov vDWq32i6N4fOnPdCdZdT1Z5nMKPM+cIZNrZYM5OMZxGOldyoNNL27sn36L3rrXso2/vPyJv5 HqEEKW8EcEQ2xxqEUZzgAYFSVg+DptRk8M2sOrwSQ6ha5tp96kByh2h1J+8rAA575rerxK0H CpKDd7Pc0Tujk/iJ/wAixH/1/Wv/AKOWuRrrviJ/yLEf/X9a/wDo5a5Gvey7/dV6v9DKfxFJ 5ZH0vToWcmO31maKFT0RPsxbaPbLH6Vaqkf+PK2/7Ds3/pIKu1+i4Zt0IN9l+RxS3Ot8Cf8A In2n/XSf/wBHPWh4M/5EXw9/2DLb/wBFLWf4E/5E+0/66T/+jnrQ8Gf8iL4e/wCwZbf+ilrK j8c/X/M6sR8EPT/If4e/5CPiP/sJj/0ngrdrC8Pf8hHxH/2Ex/6TwVu1+Y51/wAjCr6mtL4E IQGBBAIPBB71yk/h/wAG6LZaTp901nZxWNz9qskmuRGfMyTnkgtyehz2rrK871u0ms/EviG6 utMluhf21uljONPN4ihQRJEVUgjJ56gc57YrHAqUpOKm1106vb8E2/S45G9P4d8MT6rPdyyJ 5kTre3NuLthFv6rLJHu254zkjHGaki0Dw1fC3igWCdrG7/tCLy59zRSyMZA2Qc4bJOOhGPSu GtotX06DUzqOiXaT6roMNrDFZWryJHIqyL5ZxnbgFTyeldN4I0q+0zVtWW8tpIh9l0+JXI+V 2SDawU9Dg8cV216U6VOUvbN8qVtd9k7a9LtEppvY7WiiivENTgPiJ/yGPDn+9cf+gLWFJGks bRyKGRhgqRwRW78RP+Qx4c/3rj/0BaxK+nwemGp+j/8ASmYS+Jnd+ELia78I6XPcStLK0A3O 5yW7cnuaxPiH/rNB/wCvx/8A0TJWv4I/5ErSf+uA/mayPiH/AKzQf+vx/wD0TJX6HE4znK6r wX/yJEH+9cf+jXrla6rwX/yJEH+9cf8Ao16xxfwL1OrCfG/Q4HRP+QDp3/XrF/6CK5nx7/rL D6P/AOy102if8gHTv+vWL/0EVzPj3/WWH0f/ANlp0/4g6nwHuHhH/kUtK/691/lWS3/H1ff9 jLbf+ioK1vCP/IpaV/17r/KsO8uoLL+07q5lSGCLxHbM8jnAUeVByTXDUTcKqX8sjWv/AA4/ I728tYr6yns7hd0M8bRSL6qwwR+RrloPBd8NOfT7rxHcz2aWMllbRCFYwqumwNJtP7wgYx0/ Or3/AAnXhX/oYNP/AO/4o/4Trwr/ANDBp/8A3/Ffm9KGMpK0IP8A8Bv+a0+QPlZSt/COpC00 6zvNeW4tNPlt5IY1sgh/dEEAnceoGPxpmj+C9Q0jTxpqa3FJYhJU2GwUPh938e7PBbP4YrQ/ 4Trwr/0MGn/9/wAUf8J14V/6GDT/APv+K1c8e048js9fgW/fbfUVolSz8CWllruiatFdOJ9N sxaSKEwtxiPYrHnggZ9eMDtUyeE5YNN1O2tNXuLae81F9QSeJQDGzMDsIzh14wQeoNS/8J14 V/6GDT/+/wCKP+E68K/9DBp//f8AFKUsfJpyjJ2t9ns2107v9Nh+6O8N+Gf7Bl1C5lulubu/ kV5mjgWGMbV2gKi9O+Tkk1l/ET/j20L/ALCf/ttPWl/wnXhX/oYNP/7/AIrmfGXiXRNYGiW+ napa3Uy6gXZIpAxC/Z5hn8yB+Na4aniZ4pVKsX11tbpbtYUmuWyMyuw8Af8AIoRf9fd5/wCl MtcfXYeAP+RQi/6+7z/0plr7DJfjn6HNV2Omooor6EwCvONM0LTdU00z31ubiSWaUuZJXO4i Vsd/YV6PXE+Hf+QKn/Xab/0a1b0Fqzvy+MZVGpK+hz6weEm09bsaZJlrz7F5J3eYJt+3aRu/ Hr05qTSrTwlrF08Frp7hghkRpA6rKgbaWU55GeKnj8M3SeNX1Dzo/wCyS32tbfnP2krsJx0x t5z6moPCnhrUNH1WW5ulgUGBo5HjmZzcSGTcH2kAIACRgdya3t5HoKn7yTgreg3XfDWj29xo yxWSoJdQWOTDt8y+XIcdfUCtj/hEdB/6B6f99t/jTfEf/HzoP/YTT/0XJV3VW1aNIX0qO2lY OfNinYruXBxhhnGDg9ORTsjRUqab91fcckJfCMkVs1to15dSzw/aBDbxu7pHkjc2GwOQcc5N W7O28IahdpBa2Xm77P7YrgttKbiuPvZzkHjFQ2PhvXvDkSyaQ1hc3ElnDBMJyyhZEYncMDJX DEYyD0PtUGleHdf0pLa7it7WW7NjLZzRSz7ArNM0gcEA5X5unBx70reRiou6vBfcM+1eFHkt 0tvD2o3bzWqXYW3iZysb5xn5+DxTrm58JWlxcRTaDqAFrGklxIsLssIZQw3YbI4PPHY0ieCb 21vLR3tbfUIodNgtMfbZLch0JyflU5HPep9S8F3mp3es3rNHHNci3e3i89zExRAGSVeAyk8Z xnv7UreQuSVvhV/QdIvhCOK6Y6dIZLeWOIQjdvlMmNhQbvmDZ4+h9KteI/DOj2vhbVrmCyEc 0VlNIjB2yrBCQevrVy50B7vxXo+svBbqLS2kSVc5KuQNu3jkDL88dateLP8AkTtc/wCwfP8A +i2p2Rr7KPLK8V9xkab4d0QeGLPUL1J/+PNJ55Tdzf3AzNw31NZ5l8GrZ3NzJa6lEtvEsxSV 7hGeNmCh1BbkZNdJp0Mtx4Hs4YBCZZNORUE6loyTGAAwHUetclL4U1u40jUrOG0Wxt5rZI0s vt7TIZRIrF13fcG0HjPelZdjOdKKS5YJ6dizLL4OhRt9pqgnWWOI2xNysu6QHZ8pYE52kcZq VE8Hs8aPDfQu0627rNLcIYnYZQOC3G7selWdW8FpItqbN7mWdtQt5rm4numMvlR7uFbORjcc Y9aWPwxcx6L4i0yRBcm7DNb3UspMkpK/IHJ5yhAwf5UcvkL2OusF9xPp+heG9T+0G1guXSCZ oGf7VMFZl67Tv5APGag0rwzpE2qa3FLamRILpEj3yuxVTBE2Mk56sT+NdDodj/ZmhWFkY1Ro YEV1Xpux8365qro3/IZ8Q/8AX7H/AOk0NPlXY2VGmuW8Vf08jM1rSvDOhWK3dzpUkqtKsSpA WZmZjgADcO9V7S18M3NzZ20mh3dpPdtIsUd0jIx2KGY/e6YPH0NbHivRZde0yC0iKALdwyyb mK5RWBbBHOcVRvfD1xZapot1ottFJFYm4LxXF04J8xQOGIY9qLEyppS0iradPPUz79PDNlq0 2mp4d1C7uIUV5PskbSBQ2cZ+b2NE3/CI28stvNpU6XiSRRranPmSGT7pUbsEdc88YOaddeHN SvPENzqt1pVpOLiCJBENSkj8tl3Z5VPmzkdqnv8Aw/rF74ij8QA2sd1ZMiWlvvyrxEHzA7be CdxxgcY96LEcm9orft0Nb/hEdB/6B6f99t/jWXpnhfRpdV1pHsVZYrpEQb2+VfJjbHX1Yn8a 6+sfSP8AkMa//wBfkf8A6TxU7I3lRp3Xur7vIyNV0/wxpM0Fu+lTXN1Pkx29qHeRlHVsZwAM jkmqiN4OeOR/7OlVY7OS7feGXaqNtdSC33we361tavpV8daj1fTljmk+yPaTQPM0RZCQwKOA drA+34iufn8Faxe29h9svUkkW7c3CvO8m22coTGrsMtgoOuOppW8jGcLN8sF9wPc+D/strPB o13dC4tjchIEZmSMNtJYbuMHI/A1o6FpvhzX7P7Xb6JcwQkAo1yrJ5gIyCvzHIp2leFbqwu9 ekkkhaO5V4rEAn91GzO5U8cfM/v0rb8PWE2leHNOsLgoZre3SJyhyMgYOKEiqdK796K+447x Vo1po19pD6TGLOWWWXcVJIfCZwwJ5Ga0/Bl8t540tQy+XPHY3AkjJzj54cEHuD2P9QRTPHX/ AB/aF/12m/8ARZrJt557K9ivrOTyrqHOx8ZBB6qw7qe4/HggGs5wT2OLFYaMptxVmv8AI9qr i/iH9zQv+v8Ab/0RLXR6Fqg1vQ7TUhEYvPj3FM52noRnvyK5v4hsANBXI3G/Ygf9sJa5lueY c3XWeA/+RRt/+vi5/wDSiSuTrrPAf/Io2/8A18XP/pRJWOL+Bep14P436Gj4M/5EXw9/2DLb /wBFLW5WH4M/5EXw9/2DLb/0UtbEc8MxkEUqOY22OFYHa2AcH0OCOPetnuchV1fVYdHsftU0 U0oMiRLHCAWZmYKAMkDqfWsv/hK2/wCgBrH/AHxF/wDHKd4v/wCQXZ/9hG1/9GrUtduFwsK0 W5HNXrSptJEH/CVt/wBADWP++Iv/AI5R/wAJW3/QA1j/AL4i/wDjlSu6RRtJI6oigszMcAAd STVWXVdOgs47ybULWO1kIEczzKEcnnhicHofyrq/s+l3Zj9an2Jf+Erb/oAax/3xF/8AHKP+ Erb/AKAGsf8AfEX/AMcqJtV05LIXr6harak4E5mUIT6bs4qSO/s5VgaO7gdbjPklZARJjrt5 5/Cj6hS7sPrU+wv/AAlbf9ADWP8AviL/AOOUf8JW3/QA1j/viL/45T/Ph+0fZ/Nj8/Zv8vcN 23OM464zxmoZ9TsLa6S1nvraK4kxsiklVXbPoCcmj6hS7sPrU+w//hK2/wCgBrH/AHxF/wDH KP8AhK2/6AGsf98Rf/HKnoo/s+n3Yvrc+yLWh65Y+ItJh1LT5S8Eqg4YYZDjO1h2PI/mMgit GvD/AAlqV3othpt7ZEFjaxLNCxwsy7RwfQjs3b3BIPsWk6taa1YLd2jkoTtdG4aNu6sOxH/1 xkEGvMq0nD0O6M1Ipwf8j1d/9gyD/wBGy1c8QazD4e0K71WeN5Et1B8tMAuxIVRz0ySBVOD/ AJHq7/7BkH/o2Wr2u6Pb6/ol1pd0zrFcJtLIfmUgghh7ggH8K/Ms95P7Wl7T4fdv6WVz0KV/ Z6GDqHirWND0m/vtW0CNFt1ieNoLzekm9whUkqCGXOehB9RWnruvto13YQC3EouhOSS+3b5c TSenfbisq+8Gajq+lX9pqniSe5kuo44kYW4SOII4fPlg4LEjBbPT0qebwtqV/cW82p64ty1u JRGEsxHjzImjOcMf72fwrjtg9G2tL3tza+6uW1/O972+4r3jBtPiTf3Hh641g2WjOkVl9q+z W+qeZOOmAybPl5YA+latr41uNZuo7XRLCCaeTTxd7bm4MexxL5bxthSQVwe3UVDD4Ev4/Dja DJr0T2P2UWy7dPVXAGMEtu56Vr2XhK10/wAZ3viK3mdWvLfypLfb8ofcCXB7E4GR681tWnl1 pOCV9bfFbpZO9vMS5zn7f4haifDNnrd5pVlbQX1wIYJGvG8uMfPuaVvL+UZTAwDnPauu8P6p NrGjxXs9tHBI5ZSsVws0bYYjcrrwVOM9j7VjW/g65sfDGm6TYa3NBLYu7CXyQ0cwYsSskZOG HzevBANafhnw/H4b0yS1Sfz3mne4lcRiNS7nJ2oOFHTisMXLByhJ0Uk+bT4ttbb6bW7v0Kjz X1Mz4if8ixH/ANf1r/6OWuRrrviJ/wAixH/1/Wv/AKOWuRruy7/dV6v9CJ/EZ5/48rb/ALDs 3/pIKu1SP/Hlbf8AYdm/9JBV2v0TC/wIei/I45bnW+BP+RPtP+uk/wD6OetDwZ/yIvh7/sGW 3/opaz/An/In2n/XSf8A9HPWh4M/5EXw9/2DLb/0UtZ0fjn6/wCZ04j4Ien+Q/w9/wAhHxH/ ANhMf+k8FS+IdcbRba2EFsLm8vLhba2hMgQM5BPzNzhQFJJANReHv+Qj4j/7CY/9J4Km8QaE uuW1sFuXtbq0uFuba4RAxjkXI5B6ggkEe9fm+Zez/tSp7X4b/wBba2721NIX9mrGc/ijUbG4 0+11TRRBNeah9iVo7kPGw2F/MU4yRwRggGq/ivxs/hq5vYVsUn+zact6GaXZkmYR7TwcDnOa W88G6hexWks3iKV9Rtr4XizvbhowQhQIse7Crg56nJyTUGqeA7rWxdPqOtiS4uLIWZkS0CAA TCUHG72xU01gPaRlUat1S5u/Tyt538hvmtoU7z4i3mmaUdQuLPSryMXUUBXS9S+0MAwYsSNg 5AXgd+auan44u4rLWb3SbC1vbXTFjmaR7kx+ZE0Ik3KAh55xirj+Fb+7Np/aGsRTra3sN4gi sViyU3fKcMc53de2Kgtfh9aWOkeI9MtbyRLbWd21SmfswK7cLzyBngcYHFXz5du0r6fzWtdX 7PRX+/0F75UvPHWpabDpq3+m6bbT30bzRvNqBjgKgKVQSGPHmHd0OAPX07PT7l73Tra6khMD zRLI0RcNsJGcZHBx6isPU/C95dxWiWestbrDai2khmtlnhlAxhvLY4DcdeeDitbRNKh0PRLP S4Hd4rWIRqz4ycdziuPEyw0qUXSSUr62vtr307d/kUua+px/xE/5DHhz/euP/QFrErb+In/I Y8Of71x/6AtYlexhP91p+j/9KZnL4mdv4I/5ErSf+uA/mayPiH/rNB/6/H/9EyVr+CP+RK0n /rgP5msj4h/6zQf+vx//AETJX6HE4znK6rwX/wAiRB/vXH/o165Wuq8F/wDIkQf71x/6Nesc X8C9Tqwnxv0OB0T/AJAOnf8AXrF/6CK5nx7/AKyw+j/+y102if8AIB07/r1i/wDQRXM+Pf8A WWH0f/2WnT/iDqfAe4eEf+RS0r/r3X+VGi28N3N4mt7iJZYZNR2ujjIYG3g4o8I/8ilpX/Xu v8ql8Of8f/iL/sJj/wBJ4Kxo/wASX9dS8T/CicnrGjzaBcqrM0thI22GdjkoT0Rz6+jd+h56 069RuLeG7tpLe4iWWGRSro4yGB7VxsvgK7ErC11wRwZ+RJbTzGUehbeM/XGfr1rzcZlTnPno 6X3RzRqaamBRW5/wgep/9DBD/wCAH/2yj/hA9T/6GCH/AMAP/tlcf9kYjy+8r2kTDorc/wCE D1P/AKGCH/wA/wDtlH/CB6n/ANDBD/4Af/bKP7IxHl94e0iYdRzwR3MLRSruRu3T6EHsfeug /wCED1P/AKGCH/wA/wDtlH/CB6n/ANDBD/4Af/bKaynErVW+8PaROWgnkt5ltLttxbiGY8eZ 7H0b+fUdwO98Af8AIoRf9fd5/wClMtY8/wAPL+5haKXXoWRu32DH0IPmcH3rqPDWinw9oMGm tdNdvG8jtOyBC7PIzk4HTljXqYDB1KEpSnbXsZzkmtDWooor0zMK8lvbzxP4XvX0spppgLyS W0rxyfvULFuobGRuwR2+hBPrVUdW0m01qwezvEJQncrrw0bdmU9iP/rHIJFXCfKzWjVdKV0e W/8ACU+Jf7mk/wDfuT/4qj/hKfEv9zSf+/cn/wAVUGsWU3h68NrqckaA8w3BO1Jl9RnofVe3 uCCc/wDtKw/5/bb/AL+r/jXUnfU9SNbmV1IsaprniS7W1m8vTGaznFwiIjgsQrLjlvRj6fWr cHjDxFcwrLF/ZDIf+mUox6gjdwfasz+0rD/n9tv+/q/41Snu7W3ma6tbu2Zj/rYRMo8z3HPD fz6HsQXF7Rp35jpP+Ep8S/3NJ/79yf8AxVH/AAlPiX+5pP8A37k/+KrGi1bTpolkW9t9rDIz IAfxB6U7+0rD/n9tv+/q/wCNFyvaP+Y1/wDhKfEv9zSf+/cn/wAVR/wlPiX+5pP/AH7k/wDi qyP7SsP+f22/7+r/AI0f2lYf8/tt/wB/V/xouHtH/Ma//CU+Jf7mk/8AfuT/AOKqrqWueItS 0u7sJBpax3MLwsyxyZAZSCR83vVL+0rD/n9tv+/q/wCNH9pWH/P7bf8Af1f8aLg5tqzkXNH8 Y6xBYQ6eumWPmWcaQssl04YhRgNgIeDjNaP/AAmOuf8AQL07/wAC3/8AjdcxeTWM5WaHULaK 6j/1cnmL/wB8nnlTUthqtvexsPMjWaM7ZEDg4Pse4PY0XFGrJe7zfkdF/wAJjrn/AEC9O/8A At//AI3R/wAJjrn/AEC9O/8AAt//AI3WR50X/PVP++hR50X/AD1T/voU7l+0n/N+Rr/8Jjrn /QL07/wLf/43WOnijXrDV7t/I02FNQlWRS/mSKHEapt3DbgkICOO5pfOi/56p/30KZN9luIX hmaN43GGUsOaRLnN/aNT/hKfE393Sf8Av1J/8VR/wlPiX+5pP/fuT/4queivVsJBbXdwrRHi G4Zhz/suf73v3+tWv7SsP+f22/7+r/jRcPaP+Y1/+Ep8S/3NJ/79yf8AxVH/AAlPiX+5pP8A 37k/+KrI/tKw/wCf22/7+r/jR/aVh/z+23/f1f8AGi4e0f8AMa//AAlPiX+5pP8A37k/+KrP i8S+IbDUbqRl0sC+lWTeY5NocIqBfvcZCjHqc+wqD+0rD/n9tv8Av6v+NNkvtNmjaOS7tWRh gqZVwR+dFxObf2jZ/wCEp8Tf3dJ/79Sf/FUf8JT4l/uaT/37k/8Aiq52HVLW2kEEt9DJEf8A VymUEj/Zbnr6Hv8AXrb/ALSsP+f22/7+r/jRcaqv+Y1/+Ep8S/3NJ/79yf8AxVH/AAlPiX+5 pP8A37k/+KrI/tKw/wCf22/7+r/jR/aVh/z+23/f1f8AGi4e0f8AMP1bUtY1KezuL5LNorRm bbao4Y7l2k8k5x1xUsciSxrJGwZGGQwPBFV/7SsP+f22/wC/q/41TkvrOzkaaG7t2hY5liWV cg92UZ6+o79Rz1CXJXu2eqeFdSi0zwBpLurSSyIUhhT70rbm4H8yegHJqjq/hy51xre8uL5Y tRil8xXEfmJGpVl8tQSOPmyT1JGT2Af4Y017vwVoupWDL9sht2VA5+SWMuSUPpnAIYdCO4yK tXHiHTrO0S4vJXg3S+SY2jZnWQAkoVUE5wCfTHOcEVrhIUZKTlufO4mVRSXLsY3/AAiOp/8A Qch/8Af/ALZV/StI1zR9PSyttbtjEru4L2GTl3Ln/lp6saP+E00H/n6m/wDASb/4ipYfFekX EQlgluZIySAyWUxGQcHnZ6git5UMI171vv8A+CZwrYmL92/3C6bY6/pel2mnwa1aGG1gSCMt YEnaqhRn951wKLLS73S57jUYLlJ9RnlMs42eXHOMAbCMnGMcNyQSexIKxeKNKnhSaF7uSKRQ yOtjOQwPIIOzkVMmt2k9sJLTzLiR5DDHAEKSNIOduGAI45JPAHJ4q1Sw1na33kOpX0vf7h+v 6jBqehWc8G4EalarJG4w8bCVcqw7H+fBGQQav1javpTWOmQ3Vy6vfXOoWfnMn3FCyjai+wye Tyck8cAbNRgVFRly7XHir3VznvGS31zoR07T7eSWa+kW3YqSojjPLlmAO0YBGf8AarkJdK1g Wdvoh01oltdcingYRtcQRwOHYjOF3BGJBzjqK9QorqlT5ne5jGpyqx5/N4ebw9qem3tzDLqd ms9zPcC3tARFLIqhWWJcnaAhHGcE571Sis7u11aw1NdIvYNP/tie4S3jtmZ4ozDs3FFBK7ny ce9em0UvYroP2r6nFtqBTxyurHT9UNpJpQgDCwlJD+cTgjbkcDP4is27gMdt4khutEvL281K RpLOZbMtuR0AjUsR8hQ9Q2MYr0aim6d+olUt0Kumwz2+lWcNy++4jgRJWznLBQCc/WrVFFaI g8h0T/kA6d/16xf+giur8DyOnjTykcrHLp8zyKDwzLJCFJ9wHbH1Ncpon/IB07/r1i/9BFdR 4J/5HqL/ALBlz/6NgrzK/wDBZ30/4h0vizRtVe5Gs6Nf3cE6QiGeC3CFpYwSwK7lPzAseO46 c9eUj1HWZo1kj8TakyMMgjyf/jder1x/iXw06ySappcRZ2O65tU/5aeroP7/AKj+L69flcxy +Nb97CKcvRanfCdtGc19s1z/AKGTU/yh/wDjdH2zXP8AoZNT/KH/AON1Fm8/6A2r/wDgBL/h Rm8/6A2r/wDgBL/hXhfUq3/Pr/yVf5GvMu5L9s1z/oZNT/KH/wCN0fbNc/6GTU/yh/8AjdRZ vP8AoDav/wCAEv8AhRm8/wCgNq//AIAS/wCFH1Kt/wA+v/JV/kHMu5L9s1z/AKGTU/yh/wDj dH2zXP8AoZNT/KH/AON1Fm8/6A2r/wDgBL/hRm8/6A2r/wDgBL/hR9Srf8+v/JV/kHMu5Ffr qmoWwhuddvp1V1lVJhGULKQy5CoDjIHQiltbr7QGR08uePiSMnOPQg9wex/qCKkzef8AQG1f /wAAJf8ACq11bXk5WWLSdXjuI/8AVyf2fKfqCMcqe4/qAa0jhKzXK6bS8lb8kHMu4w/8eVt/ 2HZv/SQVdqmIbyPSNOkvrGezkm1maQRTIVbH2XGcHnGQcVcr67DxcaMIvdJHNLc63wJ/yJ9p /wBdJ/8A0c9aHgz/AJEXw9/2DLb/ANFLWf4E/wCRPtP+uk//AKOetDwZ/wAiL4e/7Blt/wCi lrGj8c/X/M6sR8EPT/I57xRpmr6TfXWradq99BYXLiW6jhEZ8lwqpv8AmUkqQq59MZ6E4x/t uuEZHiXU/wDyD/8AG69VIBBBGQa4DXvDc2kSG50y2lnsHPNtChd4D/sqOSnsPu/T7vl5jlym 3WpxTfVWWv4GUJ20Zk/bNc/6GTU/yh/+N0fbNc/6GTU/yh/+N1Fm8/6A2r/+AEv+FGbz/oDa v/4AS/4V4/1Kt/z6/wDJV/kacy7kv2zXP+hk1P8AKH/43R9s1z/oZNT/ACh/+N1Fm8/6A2r/ APgBL/hRm8/6A2r/APgBL/hR9Srf8+v/ACVf5BzLuS/bNc/6GTU/yh/+N0fbNc/6GTU/yh/+ N1Fm8/6A2r/+AEv+FGbz/oDav/4AS/4UfUq3/Pr/AMlX+Qcy7la/j1K6mt7ubU7q+ltSxjiu CgUhhhgCqjBx3NWLa5juovMjJ64ZWGCp7gjsaXN5/wBAbV//AAAl/wAKp3EGoJN9rtNG1bzs YdDYygSj0PHB9D/StFhK8koum1bbSwcy7no/gj/kStJ/64D+ZrI+If8ArNB/6/H/APRMlbXg 6Ce28IaXDcwyQzLAN8ci4ZT6EdjWL8Q/9ZoP/X4//omSvsInKc5XVeC/+RIg/wB64/8ARr1y tdV4L/5EiD/euP8A0a9Y4v4F6nXhPjfocDon/IB07/r1i/8AQRXM+Pf9ZYfR/wD2Wum0T/kA 6d/16xf+giuZ8e/6yw+j/wDstOn/ABB1PgPcPCP/ACKWlf8AXuv8ql8Of8f/AIi/7CY/9J4K i8I/8ilpX/Xuv8ql8Of8f/iL/sJj/wBJ4Kxo/wASX9dS8T/Cib1FFFdRwBRRRQBVvr5LKNPk eWaVtkMEfLyv6D+ZJ4ABJwBVV31LSAtxq0kMtpLzJJCuBaN6E/xJ0+c4IOSQAflq6FJqMHjE watb2kk11azzQXEMrN5UcckS+WFKjGfMBJBJJXngKB1WoTra6bdXDRiRYoXcoejAAnH415+I xU6dVRS0/M0jFNFOisDwumprZl7qO1ispUSW0hhlaQwhhkpllHyjjA5xyOmAN+vQRmFFFFAB RRRQAUUUUAMkijlULJGrgHOGGaj+xWv/AD7Q/wDfsVPRQBB9itf+faH/AL9ij7Fa/wDPtD/3 7FT0UAQfYbQdLWD/AL9ij7Fa/wDPtD/37FT0UAQfYrX/AJ9of+/Yo+xWv/PtD/37FT0UAQfY rX/n2h/79ij7Fa/8+0P/AH7FT0UAQfYrX/n2h/79ioLnRdKvAoutMs59udvmwK2M+mRV6igD J/4Rfw//ANALTP8AwEj/AMKP+EX8P/8AQC0z/wABI/8ACtaincDJ/wCEX8P/APQC0z/wEj/w o/4Rfw//ANALTP8AwEj/AMK1qKLgZaeGtBikWSPRNNR1IKstqgIPqDirv2K1/wCfaH/v2Kno pAQfYrX/AJ9of+/Yo+xWv/PtD/37FT0UAQfYrX/n2h/79ij7Fa/8+0P/AH7FT0UAVzY2bDDW kBHoYxS/YrX/AJ9of+/YqeigCD7Fa/8APtD/AN+xR9itf+faH/v2KnooAg+xWv8Az7Q/9+xR 9itf+faH/v2KnooARVVFCqAqjgADAFcJ8QrG3W90O+VNtw120bMDjcvkSkZHcjnB7ZPrXeVx fxD+5oX/AF/t/wCiJaqO4HNV1ngP/kUbf/r4uf8A0okrk66zwH/yKNv/ANfFz/6USVhi/gXq deD+N+ho+DP+RF8Pf9gy2/8ARS1asdDstP1G9v4ldrm7fe7u2dvAyq+gOAT6nr0GKvgz/kRf D3/YMtv/AEUtblbXOQyvEWkS61o72kF21pcK6SwzKobZIjBlyCCCMivMZb3xJbXMtrda5fQ3 MRxJGYbY49CD5XIPY17HWJ4j8OQ69bBlYQ30QPkz4zj/AGW9VPp+I5rehXdN26GdSmpI81/t PXv+hhvf+/Fv/wDGqP7T17/oYb3/AL8W/wD8aps9tqFrO8E+kan5qHDeTYzSpn/ZdVIYe4/S o9t3/wBAnWf/AAV3H/xFej7WP834nN7N/wAv4E39p69/0MN7/wB+Lf8A+NUf2nr3/Qw3v/fi 3/8AjVQ7bv8A6BOs/wDgruP/AIijbd/9AnWf/BXcf/EUe1j/ADfiHI/5fwJv7T17/oYb3/vx b/8Axqj+09e/6GG9/wC/Fv8A/Gqh23f/AECdZ/8ABXcf/EUbbv8A6BOs/wDgruP/AIij2sf5 vxDkf8v4E39p69/0MN7/AN+Lf/41R/aevf8AQw3v/fi3/wDjVQ7bv/oE6z/4K7j/AOIo23f/ AECdZ/8ABXcf/EUe1j/N+Icj/l/Ao2X+gJDp8n3UQJBJ/fUDgH/aAH49R3A6jwT/AMj1F/2D Ln/0bBWDNbz3ERjk0fWSp/6hdyCD2IOzg+9bXw+t9SHjLfdaffxwxafMgubizkhVy0kJA+dR 82Fbp6Z9hhXnH2bSZpTi+a7R6rRRRXmnSFFFFABRRRQAUUUUAFFFFAHE/EP/AFmg/wDX4/8A 6JkrnK6P4h/6zQf+vx//AETJXOVotgOt8Cf8ifaf9dJ//Rz1oeDP+RF8Pf8AYMtv/RS1n+BP +RPtP+uk/wD6OetDwZ/yIvh7/sGW3/opa5KPxz9f8zrxHwQ9P8jcooorc5AooooAKKKKACii igAooooAK4n4h/6zQf8Ar8f/ANEyV21cT8Q/9ZoP/X4//omSnHcDnK6rwX/yJEH+9cf+jXrl a6rwX/yJEH+9cf8Ao16xxfwL1OvCfG/Q4HRP+QDp3/XrF/6CK5nx7/rLD6P/AOy102if8gHT v+vWL/0EVzPj3/WWH0f/ANlp0/4g6nwHuHhH/kUtK/691/lUvhz/AI//ABF/2Ex/6TwVF4R/ 5FLSv+vdf5VL4c/4/wDxF/2Ex/6TwVjR/iS/rqXif4UTeooorqOAKKKKAMtf+SgaV/2C73/0 ba1ta5/yL+pf9esv/oBrmdO1Ww1Xx/ZfYLuK5Fvpt6kpibcEYy22ASP91vyNdNrYLaDqKgEk 2soAHf5TXkYz+P8AcbQ2MvRf+QFp/wD17R/+gir1YnhnV9O1HSbaCzvIZ5re2iEqI2WTK45H bofyrbr1zEKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAri/iH9zQv8Ar/b/ANES12lcX8Q/uaF/1/t/6IlprcDm q6zwH/yKNv8A9fFz/wClElcnXWeA/wDkUbf/AK+Ln/0okrHF/AvU68H8b9DR8Gf8iL4e/wCw Zbf+ilrcrD8Gf8iL4e/7Blt/6KWtytnucgUUUUgCiiigBCQoJJAA5JNUNO1ux1V5UtZSzJyN yld6Ho65+8p5ww4rnX12y8U6hNp9vdxNZQE+ZCrfPc4ODkf88weP9r/d+9cvrdHjW4E32aa3 y8dwP+WfHOfVSByDwR9AR20sFKdPmv6HPPEKEuU6aisTw54ktPENtL5MkTXFuQs6xNuXJ6Mp 7qe35HkVt1xtNOzOgKKKKQBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHE/EP/AFmg/wDX4/8A 6JkrnK6P4h/6zQf+vx//AETJXOVotgOt8Cf8ifaf9dJ//Rz1oeDP+RF8Pf8AYMtv/RS1n+BP +RPtP+uk/wD6OetDwZ/yIvh7/sGW3/opa5KPxz9f8zrxHwQ9P8jcooorc5AooooAKKKKACii igAooooAK4n4h/6zQf8Ar8f/ANEyV21cT8Q/9ZoP/X4//omSnHcDnK6rwX/yJEH+9cf+jXrl a6rwX/yJEH+9cf8Ao16xxfwL1OvCfG/Q4HRP+QDp3/XrF/6CK5nx7/rLD6P/AOy102if8gHT v+vWL/0EVzPj3/WWH0f/ANlp0/4g6nwHuHhH/kUtK/691/lUvhz/AI//ABF/2Ex/6TwVF4R/ 5FLSv+vdf5VL4c/4/wDxF/2Ex/6TwVjR/iS/rqXif4UTeooorqOAKKKKAM5ln0e5kvbKNpba Rt11aIMknvJGP73qv8X+91uXmvxvDBHpLRXd1cp5kRzlI06eY+Og64HUkYGMEiWoYLO2tXme 3t4ommfzJSigF29T6muaphYVJqb/AOHKUmlYjsbFLKNyXaaeVt808n3pW9T/ACAHAGAKtUUV 0pW0RIUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABXF/EP7mhf8AX+3/AKIlrtK4v4h/c0L/AK/2/wDREtNbgc1X WeA/+RRt/wDr4uf/AEokrk66zwH/AMijb/8AXxc/+lElY4v4F6nXg/jfoaPgz/kRfD3/AGDL b/0UtblYfgz/AJEXw9/2DLb/ANFLW5Wz3OQKKKKQBRRRQBzOr/8AI6ab/wBg+5/9GQVHrn/I A1L/AK9Zf/QDUmr/API6ab/2D7n/ANGQVHrn/IA1L/r1l/8AQDXt4P8AgfeediP4p0Gmf8gm z/64J/6CKtVV0z/kE2f/AFwT/wBBFWq8Q9EKKKKACiiigAooooAKKKKACiiigAooooAKKKKA OJ+If+s0H/r8f/0TJXOV0fxD/wBZoP8A1+P/AOiZK5ytFsB1vgT/AJE+0/66T/8Ao560PBn/ ACIvh7/sGW3/AKKWs/wJ/wAifaf9dJ//AEc9aHgz/kRfD3/YMtv/AEUtclH45+v+Z14j4Ien +RuUUUVucgUUUUAFFFFABRRRQAUUUUAFcT8Q/wDWaD/1+P8A+iZK7auJ+If+s0H/AK/H/wDR MlOO4HOV1Xgv/kSIP964/wDRr1ytdV4L/wCRIg/3rj/0a9Y4v4F6nXhPjfocDon/ACAdO/69 Yv8A0EVzPj3/AFlh9H/9lrptE/5AOnf9esX/AKCK5nx7/rLD6P8A+y06f8QdT4D3Dwj/AMil pX/Xuv8AKpfDn/H/AOIv+wmP/SeCovCP/IpaV/17r/KpfDn/AB/+Iv8AsJj/ANJ4Kxo/xJf1 1LxP8KJvUUUV1HAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVxfxD+5oX/AF/t/wCiJa7S uL+If3NC/wCv9v8A0RLTW4HNV1ngP/kUbf8A6+Ln/wBKJK5Ous8B/wDIo2//AF8XP/pRJWOL +Bep14P436Gj4M/5EXw9/wBgy2/9FLW5WH4M/wCRF8Pf9gy2/wDRS1uVs9zkCiiikAUUUUAc zq//ACOmm/8AYPuf/RkFR65/yANS/wCvWX/0A1UgfU7zxQZdVS1t5rO3lhSCEsS6O6ESAnqv 7vt3JBwRWjqFv9r026tt4TzYXj3HouQRmvcwkWqFjzcQ17U2tM/5BNn/ANcE/wDQRVquf8J3 ep3enk3sVsLZFRLWWEt++UDBbB/hPGD35PTBPQV4jVnZnpJ3CiiikAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQBxPxD/1mg/9fj/+iZK5yuj+If8ArNB/6/H/APRMlc5Wi2A63wJ/yJ9p/wBd J/8A0c9aHgz/AJEXw9/2DLb/ANFLWf4E/wCRPtP+uk//AKOetDwZ/wAiL4e/7Blt/wCilrko /HP1/wAzrxHwQ9P8jcooorc5AooooAKKKKACiiigAooooAK4n4h/6zQf+vx//RMldtXE/EP/ AFmg/wDX4/8A6Jkpx3A5yuq8F/8AIkQf71x/6NeuVrqvBf8AyJEH+9cf+jXrHF/AvU68J8b9 DgdE/wCQDp3/AF6xf+giuZ8e/wCssPo//stdNon/ACAdO/69Yv8A0EVzPj3/AFlh9H/9lp0/ 4g6nwHuHhH/kUtK/691/lUvhz/j/APEX/YTH/pPBUXhH/kUtK/691/lUvhz/AI//ABF/2Ex/ 6TwVjR/iS/rqXif4USXU/EUWm6gliLG9u52i84i2VDtXOBncw7g1W/4Stv8AoX9Y/wC+Iv8A 45UN7/yPDf8AYNT/ANGNV2vcw+DhUpqTbPFq4iUJ8qRB/wAJW3/Qv6x/3xF/8co/4Stv+hf1 j/viL/45U9Fb/wBn0u7Mvrc+xB/wlbf9C/rH/fEX/wAco/4Stv8AoX9Y/wC+Iv8A45U9efWP jkP4wuBJfxSaXMZoILdSu+NogDv9cPiTGfQVEsFRja7ZccRUleyR3X/CVt/0L+sf98Rf/HKP +Erb/oX9Y/74i/8AjlcX/wAJnfx3kd9d2Ris5NK+1Q2scyuZGeWNULHA2n58HqAD3qfUPFGp G5t7OK0W31CHUoYJ4PPDRyJJG7D59vA45+XIx3qfqlDux+2q9kdb/wAJW3/Qv6x/3xF/8co/ 4Stv+hf1j/viL/45XInx+5mNrHo8r3sKytcwrKW27JNhCEKd5JBIzt+tP8Y6nqEGo6Fb2E+o RR3ZmMq2UUbTMFQEYEgxx3/Gn9Uo2umwVepezSOr/wCErb/oX9Y/74i/+OUf8JW3/Qv6x/3x F/8AHK4+LX77Sru7juZZ7lYrK1eOK9KRP5kkkgO4oDzgDgA/d4FLJ8QHjso7ltJaNN8sczyy OsaMjbdu7y85PX5gvSj6pQ6th7ar0SOv/wCErb/oX9Y/74i/+OUf8JW3/Qv6x/3xF/8AHK5O y8U3sWpXCXFuLiyl1gWUM4mAMe5FKgKB8w989+9dnVRwNKWzZMsTUjukQf8ACVt/0L+sf98R f/HKP+Erb/oX9Y/74i/+OVPRVf2fS7sn63PsQf8ACVt/0L+sf98Rf/HKWz8YWVxrEOlXFreW F1OheEXSoBJggEAqx556VNXA+M0WTxRYqw4+xSd8Y/eJyPQ1nUwMIxumXTxMpSs0es0VxvhT xW1w0el6pJ/pPSC4bjz/APZPo/8APr6iuyrzJwcHZnYmmroKKKKkZyEPxDsbiFJoNJ1aSJwG RxHHhgeh5en/APCe23/QF1f/AL9xf/HK5Dw9/wAi5pv/AF7R/wDoIrSr6WGT0JRTbf8AXyPi qvEuJhUlFRjo33/zN3/hPbb/AKAur/8AfuL/AOOUf8J7bf8AQF1f/v3F/wDHKwqKr+xaHd/h /kZ/6z4r+WP4/wCZu/8ACe23/QF1f/v3F/8AHKP+E9tv+gLq/wD37i/+OVhUUf2LQ7v8P8g/ 1nxX8sfx/wAzd/4T22/6Aur/APfuL/45R/wntt/0BdX/AO/cX/xysKij+xaHd/h/kH+s+K/l j+P+Zu/8J7bf9AXV/wDv3F/8co/4T22/6Aur/wDfuL/45WFRR/YtDu/w/wAg/wBZ8V/LH8f8 zd/4T22/6Aur/wDfuL/45R/wntt/0BdX/wC/cX/xysKij+xaHd/h/kH+s+K/lj+P+Zu/8J7b f9AXV/8Av3F/8co/4T22/wCgLq//AH7i/wDjlYVFH9i0O7/D/IP9Z8V/LH8f8zd/4T22/wCg Lq//AH7i/wDjlH/Ce23/AEBdX/79xf8AxysKij+xaHd/h/kH+s+K/lj+P+Zu/wDCe23/AEBd X/79xf8AxytnQNf0/wASaVHqGnSFom4ZXGHjburDsf8A9Y4ria4XwlrF5oK217ZMCSu2WFjh ZlyeD6H0Pb6Eg8eLyuNNL2Td9d/kepluezruXt0klbbzv/kfQdFZ2i61Z69pyXlm5Kk7Xjbh o27qw7H+fUcGtGvFaadmfSJpq6CuL+If3NC/6/2/9ES12lcX8Q/uaF/1/t/6IloW4zmq6zwH /wAijb/9fFz/AOlElcnXWeA/+RRt/wDr4uf/AEokrHF/AvU68H8b9DR8Gf8AIi+Hv+wZbf8A opa3Kw/Bn/Ii+Hv+wZbf+ilrcrZ7nIFFZ2oa9pOlTLDf6hb28rLvVJHAJGcZx6VV/wCEx8Of 9Bmz/wC/gpAbdFYn/CY+HP8AoM2f/fwUf8Jj4c/6DNn/AN/BQBc1TS49SiQhzDcxEtBOoyYz /VT3Hf64IybfS77U5dmrwJBaRHDwo4YXTDvntH/snk9CABhrX/CY+HP+gzZ/9/BR/wAJj4c/ 6DNn/wB/BWsa04xcU9GQ6cZNSaNvpRWJ/wAJj4c/6DNn/wB/BR/wmPhz/oM2f/fwVkWbdFYn /CY+HP8AoM2f/fwU+HxZ4fuLiKCLWLNpZWCRr5oyzHoB7mgDYooooAKKKKACiiigAooooAKK KKACiiigDifiH/rNB/6/H/8ARMlc5XR/EP8A1mg/9fj/APomSucrRbAdb4E/5E+0/wCuk/8A 6OetDwZ/yIvh7/sGW3/opaz/AAJ/yJ9p/wBdJ/8A0c9aHgz/AJEXw9/2DLb/ANFLXJR+Ofr/ AJnXiPgh6f5G5RRRW5yBRRRQAUUUUAFFFFABRRRQAVxPxD/1mg/9fj/+iZK7auJ+If8ArNB/ 6/H/APRMlOO4HOV1Xgv/AJEiD/euP/Rr1ytdV4L/AORIg/3rj/0a9Y4v4F6nXhPjfocDon/I B07/AK9Yv/QRXM+Pf9ZYfR//AGWum0T/AJAOnf8AXrF/6CK5nx7/AKyw+j/+y06f8QdT4D3D wj/yKWlf9e6/yqXw5/x/+Iv+wmP/AEngqLwj/wAilpX/AF7r/KpfDn/H/wCIv+wmP/SeCsaP 8SX9dS8T/CiZ+qXdva+Nybi4ihDaamDI4XP7xvWp/wC19N/6CFp/3+X/ABrM8TaDpmv+Mo4t UtRcRw6eGjUuy7SZGBPBHoPyrI1fwb4N0bSrjUbjRWeGBQziOVy2MgZ5cdM5r6TCOaopq1jw K6i6mt7nVf2vpv8A0ELT/v8AL/jR/a+m/wDQQtP+/wAv+NcDdab8PrS81S1k0eQyabEsspWR yHDYwEO/k5ZRzjk1oR+FvAZgM09jb2qh3TFxdlSdjbSfv9M4/MVupyfb7/8AgGfJHz+4606r pjKQdRtcEY4nUf1rOMHhk6fa2Hm2P2W1dZIY/tA+RlOQc5z3P51g6r4Y8BaRAJLjT4mc7CsM dyxkcMwUMFLjIyevsatN4L8CpLNE1raLJCu+VDdsDGvqw38DkdaG5PdL+vkCUV1f9fMtw6R4 Pt1lWMWAWSEwMrXG4eWSG2gFsAZAIx07U7+y/CX2T7MXszH5wuCTdEsZAMBi27cSAcDniqj+ B/BEbsj2Vsrqyoym6cEM33Qfm6nsO9Fr4H8D3ys1nZW1wqnDGG6dwD6HDUWltZf18guu7/r5 lp9J8IPBBAfsPlwhlQC5xkFtxDYb5gTyQ2ea0Zp9CuLy1u5buzae03eQ/ngbNww3GccivP3X 4dR6Pdam2h3Ijtrk2zx7n3lsE5A8zBXAbnP8JrpIfA/gmecwR2EBnCB2hFy+9VOMEruyOopR beyX9fIcklu3/XzNO9g8NahLLLdTWbySiNWcXO0/ISVwQ3BBY8j1qq2jeD2TZmzAy+dt2VLb jlgSG5BPODx+dYb6H4AF8bWDS1uSEjYyQXJZPnk8sDPmdQeo9PXpWnF4I8Dz3UltDZWslxH9 +JLpy6fUbsijV9F/XyDRdX/XzNQQeGQABLZAC6F4ALgACUAAN19AOOntWj/a+m/9BC0/7/L/ AI15/JpvgWK+ubd/Dd6IrW5W2mugXMSOcAZIfOPmXt3q/beG/AFxafaZLGG2jM8kC/ablkLM jFWxl+eRQpy6W/r5CcV1v/XzOx/tfTf+ghaf9/l/xo/tfTf+ghaf9/l/xrmx4H8EEAiytjmX yRi6fmT+59773B461GPB/gIwNOLeyMKvsaT7Y20N6E7+vtVc0/L7/wDgCtDz+46j+19N/wCg haf9/l/xrifFN1b3XiqyNvPFMFspATG4bHzr6Vrx/D3whLGskelxvG4DKyzyEMD0IO6uR8Ue GbPRvENougxCzkNq8hG9mWQh1GGyTxg1FRz5dUi6ahzaMkuxm0m9QhII6gjkEe+a9h0SaS40 DTppXLyyWsTux6klQSa8Tiv1vbC5BQxXEaMssLdUOP1Hoa9p8Pf8i1pX/XnD/wCgCvNxlnZn XR0uaVFFFcRueSeHv+Rc03/r2j/9BFaVZvh7/kXNN/69o/8A0EVpV93S/hx9EflGJ/jT9X+Y yWaKHZ5sqR72CLvYDcx6Ae59KiN9ZgSk3UAELBZCZB8hJwAfQ1R8S2st1oFytuha4jAmiCjJ LIQwwPXjH41zFppGo/2npzSW0ix6jIt5fEpwkiM7hW9M7lGP9msqtacJ8qjf+rHTh8LSq0nO U7NX09Nfyv8AM7eG8trhgsNxDKSu8BHDfLkjPHbII/CnpLHIzqkiM0Z2uFYEqcZwfTg1wdtb 6xFZ+YsF4k32NEdljIcL9ocsF/2thyO/IqSGC+huZyo1ZdOlvmaSRUcTuohUIem7buB7dhmo WJdleP8AX9bmssuheVp7fp/n07nd1EbmASpEZoxJISEUuMsR1AHfHeuPuJtYN7aGBNWAjNsP 3oJ8xSRvLBBtzg85JPsOaPD2mTW9xp3nw3ay291dljKjbQGzgg4xgjBz3Oaf1huXKo/1dEPA RjTc5T+S9G/8vvOwN1bq8iGeIPEu+RS4yi+p9BT0dZEV0YMjAFWU5BHqK4vXtKv5NU1jUbGG VpltUiVMELPGysHUepHyke496Yo1YXOnQRx6jFHGLWNwu/YUKgP0UKMZ5yScjjGKHiJKTTiN YCEoKUZrbXy0T/X+rHbSzRQRmSaRI0BALOwA5OByfen1xbR65Lp10tx9qZ7XyraPAP8ApBEw LS47/KF5/wB6opL/AFCPVo8zag9wb24RokP7lkVHKKnGM4C/j17UPE2tdf1sJZe5J8s02r/g kzuGZUGWYKPUnFLXnM1vq93aOk0epvAktpNhhIXUhjvxkAkgYPAxnkcVqs+sfapCh1E3JnmV 1KMIBAFbYVOMbvuYwd2c5ojir/ZKnl3KvjV/+AmdjRWdoUE0GjW32mW4knkjWSX7QxLKxUZH PTntWjXTF3SZ59SKjJxTvYK830r/AJBkH+7/AFr0ivN9K/5BkH+7/WuPFfFH5/oenlv8OfrH /wBuOz+HkskfjNY0dljltJfMUHhtpTbke2Tj6n1r16vHvh//AMjxB/16TfzSvYa+Zx38dn3O W/7tH5/mFcX8Q/uaF/1/t/6IlrtK4v4h/c0L/r/b/wBES1yrc7jmq6zwH/yKNv8A9fFz/wCl ElcnXWeA/wDkUbf/AK+Ln/0okrHF/AvU68H8b9DR8Gf8iL4e/wCwZbf+ilrcrD8Gf8iL4e/7 Blt/6KWtytnuchm6d/yPd9/2DIP/AEbLXT1zGnf8j3ff9gyD/wBGy109eJjf4z+X5G0NgrK1 LxDY6TqMNleGSNprea5WTb8m2IAuCc9cHP0zWrXH+P8AwpeeKLPT106aKC5gnZZJZD0t5EZJ QODyQRj6VhTUXK0timPtviN4fudO0/UPMmitr2G4nDyIB5KQ8OXAJI5wABnJIpk3xH0e0sL2 7vbTVLMWkSTtHcWpR5ImcIHQZ5GSM8g+1Ydz8Mbi61DxTi6iisr+DbpyAk+S7sskm4dh5iL0 7E1q6rpXizxHpN1Z6hHpltEywBYY5WkEjpMju5YqNqlVIC89eTW/LRurP8RanSWWvWOoapLY WztI8drFd+YB8jRyFtpB7/cP6Vp1xnhPwdc+GfE2sXAnjfSp4oorCIE74EVpGMZ46AyHHJ4x 6V2dYVFFStF6DQVxHxTjSXwxZxyKGRtStwwPcbq7euK+J/8AyLlj/wBhO2/9CqqH8RCexQ8P eIXhlj0zU5S24hba6c8v6I5/veh/i6Hn73X15hLEk0TRyKGRhgqehrrvBl/c32iSC6laV7e4 kgWRuWZVPG49zg4z3xzzXs0anMrMykrHQ0UUVsSFFFFABRRRQAUUUUAFFFFAHE/EP/WaD/1+ P/6JkrnK6P4h/wCs0H/r8f8A9EyVzlaLYDrfAn/In2n/AF0n/wDRz1oeDP8AkRfD3/YMtv8A 0UtZ/gT/AJE+0/66T/8Ao560PBn/ACIvh7/sGW3/AKKWuSj8c/X/ADOvEfBD0/yNyiiitzkC iiigAooooAKKKKACiiigArifiH/rNB/6/H/9EyV21cT8Q/8AWaD/ANfj/wDomSnHcDnK6rwX /wAiRB/vXH/o165Wuq8F/wDIkQf71x/6NescX8C9Trwnxv0OB0T/AJAOnf8AXrF/6CK5nx7/ AKyw+j/+y102if8AIB07/r1i/wDQRXM+Pf8AWWH0f/2WnT/iDqfAe4eEf+RS0r/r3X+VS+HP +P8A8Rf9hMf+k8FReEf+RS0r/r3X+VS+HP8Aj/8AEX/YTH/pPBWNH+JL+upeJ/hRKt7/AMjw 3/YNT/0Y1P1KyTUtLu7GT7lxC8R9gwI/rWH4zutYs/FdvJocKXM72W2eJ7ffsQOdrA+YnU5G Pasj+2vHn/QJg/8AAL/7pr6PCTSopNM8GvBupe5HB8P71bXRhNdwNPDcNJqRDNtuEMiOFHH/ AEzTrjvVuLwVcecr3Bs5VWO/UK2Thp5NynkdhkH696g/trx5/wBAmD/wC/8Aumj+2vHn/QJg /wDAL/7prVKHZk3n3QyTwRqYtGt0GmSebHZBppS2+JoFUME+U5B28HI6nirUXgu5eeGC6+x/ ZY5rqR7mIsLi4WUONr/L23nJ3HO0cCoP7a8ef9AmD/wC/wDumj+2vHn/AECYP/AL/wC6aLQ7 MPf7ogsPh/qUc0cl/eWtwJEZrtCXIklVXSE8YOArjPI5HFbnhHw7faC1yLl4fJdI1jRJDKy7 QQfnKK23kAKc4x1rK/trx5/0CYP/AAC/+6aP7a8ef9AmD/wC/wDumiPJF3SYpc0lZtFSb4da jLC8YurVVe2nV0yxDTM0ojY/L0CSkH3FXY/BF/8AaroST2wila6dJ1YmRfOQqBt2jpnruOQB wKb/AG148/6BMH/gF/8AdNH9tePP+gTB/wCAX/3TSSgujHefdCDwXqkk8cjppdsEis4ttuzf N5ModmPyDkgYH4D3q5pXhbU7TxPb6pdPZ7IvtAbyWILCQgrhAgAxgZ5JJ5zVT+2vHn/QJg/8 Av8A7po/trx5/wBAmD/wC/8AummuVdGJ83dGpZeDLb+1tSvtTjS4M999qgQSvsUBVA3JwpII J6Gsi+8E6tc2EloktiySfa8lmKlTNIWU7thJAB5UEc9zT/7a8ef9AmD/AMAv/umj+2vHn/QJ g/8AAL/7pofI1swXOuqK9l4ZnvPEF/bBpYrGG2LCQxsqi9ki8l2XcBvAVS2R3b3qxaeB75be CO5+wkRy2e9Q5ZZUhJLEjYBk54GD7mj+2vHn/QJg/wDAL/7po/trx5/0CYP/AAC/+6aSUOzG 3LujvERY0VEUKijCqBgAelcJ4x/5Gux/68ZP/Q0pP7a8ef8AQJg/8Av/ALprntY1bVv7ftZd ethBJ9ndEVIPL+UspJ/1j5wR04/GqqVE42sKnBp7kWr6eZoXuraQQ3ccZAfGQy45Vh3H8q9u 0EKPDumBCWX7JFgkYJGwdq8euGV7GVlYMpjJBByCMV6/4e/5FrSv+vOH/wBAFebjFsdlF6M0 qKKK4jY8k8Pf8i5pv/XtH/6CK0qzfD3/ACLmm/8AXtH/AOgitKvu6X8OPoj8oxP8afq/zKeq 6imladLduhfZgKgIBZiQAOfcisu812/0yxluL/TY49jRAOlxuRg7BTyQCCv0xWpqmnRarp0t nKzIr4IdeqsCCCPoQKzbjw9c31rLFfarJM7vGwIiCooRt3CA9T3NZ1fa3fJ28t9f+Ab4Z4fl Xte+u+2m1tO97/Ir3/i6O3+1GzS3uUhkgjWQTgITISOSAcAYoj8WO0cyfYo5LlZooIxb3AeK V3BPD4GMYOeKs33hqK9uZpTPsWWW3kKCMEfuiTjr3zSS+GUYTJBdPBGZ0uoEVARBKOpGeoPd ayaxF73/AC8/+AdEZYDlSa107+X/AAf06FTUvFV3pUM8dxpqm9iMZWOObKSI5IBDEDkEEYxU WoeNxa3NytvZrNBFbLMspl27ifLOOnHEimr58NPPcC6vb9ri682JyxiCqEjOQgXPGSTk5NUP +EFhFh9mW/fOyRS5jzncyEd+wjAqZrFa8v6f1/wxrSeXXXtF6/Fbp89LfibOjanPqPnGX7AQ mMG0u/O6568DFZVj4rub15GEGnqiNKPLN7++ITP8G3/Zz9K3NPtLu1Mn2q8juA2NoS3Ee38i c1l2fhy6soXt49TQ27tISptRu+ckn5t3vWjVa0bX632OaLwt58yXS3xW636em5DD4ruRZW1z eackSXdtJPbtHPuBKpv2tkDBIB9arC7mj1awntdB00T6jGZo5jLtfOwM+fk4POPersHhWRbW G3udSeaO2t3gt1WEIE3JsLHkljir6aKq3GkS+eT/AGdE0YG3/WZQLnrx0qFCtJLm8u3lf9Ta VXCQb5Fvf+a3W36X+ZTj8Rz3ckVtZ2SPdySTDDylURI32bicE88cAVC/jBLee0jurNod88lv cndkQsu3nPdTvHPGM1YHhpoGins79oLuOSZhL5QYMsjlipUnnBxg57UReF4AyNcTtckmc3G9 B++MoUHp90AKABTtiPnp2t0/4JKeBT1Wmve/W3lba3nv1NHStQOpWjzmPy9s8sWM5+45XP44 q9WdoekromlpYpM0yq7tvccncxPP51o11U+bkXNuefX5PaS9n8N9PQK830r/AJBkH+7/AFr0 ivN9K/5BkH+7/WuTFfFH5/oejlv8OfrH/wBuOw+H/wDyPEH/AF6TfzSvYa8e+H//ACPEH/Xp N/NK9hr5nHfx38j7nLf92j8/zYVxfxD+5oX/AF/t/wCiJa7SuL+If3NC/wCv9v8A0RLXKtzu OarrPAf/ACKNv/18XP8A6USVyddZ4D/5FG3/AOvi5/8ASiSscX8C9Trwfxv0NHwZ/wAiL4e/ 7Blt/wCilrcrD8Gf8iL4e/7Blt/6KWtytnuchm6d/wAj3ff9gyD/ANGy109cxp3/ACPd9/2D IP8A0bLXT14mN/jP5fkbQ2PPPiN42u/Dl/Y2unXdrBJFG2oXaTsg86BGC+Uu7+Jstjbz8tZ2 ueLNen8SanDoV/eyQx6fb3NjBaaatwszSBiN7YyqnA5JHBPpXcXcfhrTNVmvNQmsIL3UFSNj dzgGVVyFVVc4xyeAOSeaND0HQNFuriPSIo47iOKKCZBcNIyIuTGpDMSBgnHtSjOEYr3dR2Zz B1fxLqv/AAkN5BqsGlLoo8sWvkJIskixLIxkY5IUkkDaRwM1o+CvE194h1bV/tJVYI7ewmhi UD9350AkYZ6nk96NbsPAeo3P23Vr3T1e6Xa7HUfKW5VCVwwDgSAEEcg4xjtU40fwff3t1qVv dRec0SSzvZ6nJGojVdqMVjcKFCrgHGODQ3Bxtb8PQCnoviq/b4bal4gu8XN1aG8ZVCABhE7h RgY7KKjsdR1/S9T8NHUdai1KDWtySQ/Z0j8p/KMoaMryVG3B3Z6ipre28AaPcny9VsYCdztB Jq7GNvMBJJjaTaQwbPIwc5q1o2ieDdJ15YtNktf7UgRo47dr0yyW6kDcqRsx2DA5wB+VDcNd N/L+tgOrrivif/yLlj/2E7b/ANCrta4r4n/8i5Y/9hO2/wDQqzofxED2OTrovAP/ACB73/r/ AJv6VztdF4B/5A97/wBf839K9XD7szlsdVRRRXUQFFFFABRRRQAUUUUAFFFFAHE/EP8A1mg/ 9fj/APomSucro/iH/rNB/wCvx/8A0TJXOVotgOt8Cf8AIn2n/XSf/wBHPWh4M/5EXw9/2DLb /wBFLWf4E/5E+0/66T/+jnrQ8Gf8iL4e/wCwZbf+ilrko/HP1/zOvEfBD0/yNyiiitzkCiii gAooooAKKKKACiiigArifiH/AKzQf+vx/wD0TJXbVxPxD/1mg/8AX4//AKJkpx3A5yuq8F/8 iRB/vXH/AKNeuVrqvBf/ACJEH+9cf+jXrHF/AvU68J8b9DgdE/5AOnf9esX/AKCK5nx7/rLD 6P8A+y102if8gHTv+vWL/wBBFcz49/1lh9H/APZadP8AiDqfAe4eEf8AkUtK/wCvdf5VL4c/ 4/8AxF/2Ex/6TwVF4R/5FLSv+vdf5VL4c/4//EX/AGEx/wCk8FY0f4kv66l4n+FEq3v/ACPD f9g1P/RjVdrM1S7t7XxuTcXEUIbTUwZHC5/eN61P/a+m/wDQQtP+/wAv+NfTYNr2KPnsQn7R lTxPrA0Lw5e34KiVE2w7iMGRvlXr7kfhmud0TxjMdHW3eSLVNSj1AWAkWQIku4FlkJAOBtB6 A8iuku7jQ74wfabuzk+zzLPHm4A2uvQ8HnGe9Vby28MX80s1zLZPLKE3uLnacoSVIw3BGTyO ecdK2lzN3TIjy2s0Y+l+K9Ud7i0On/ar5Z7qRo3nWNYYo3ChdwU7jkgDj6kVXt/G9z9r1PUh bm40dI7OUBpAjwLKozhdvzHJ5BI6da2Do/g82qW2bIRIzuoW6IIL/e5DZwe46U6TS/CEt4Lp vsHmjy+lwAp8sAICu7BAwMDFTafcq8OwujeLDrGoLCmnypay+aIrgFmHyNj5xtAXODjBPTtX LX3ijW7bVtdsVuz/AKRcC201ti/uXVow4HHPyy7uf7tdfaW/hmxvnvLaWyjncsSwuAQNxy20 E4XJ5OAM0jWnhd7pbl5LFplne4VzcDIkZQrN17gAfhTak1vqJOKexh6D44uLi10+3ks5byZb e1N5OudwaVQchVUggAgnkdeAcVBf+MNRuTZXltC1rp01vfuhWVS8oijbaSCp2EEZH3uvOa3o 9N8JRS20iNYq1sqLHi54AT7mRuwxHYnJFM/sfwf57zD7CHcSg4ucACQEOAN2BnJziptO1uYd 4XvYrjxp5Op2Ni1oJUnkggaZZtzK8iBgWATaPoWBPUDFUPEmsa1D4svLLTrjUP3enJLBBaWq SgylmHz7lOBwOcitv+zvCgu1ug9mJkdJFIuuA6ABWxuxkAAZq8s+hpqUmord2Yu5IhC0nnjJ QEkDGcdSaq0mrNivFO6RzyeJ9SsLy/hu4o57hZbeNbfzNoRmgDuF2qzN82eAD17CpIPHqzxQ BdOK3F3FBJZxNNjzvMcowzt+XaQc8dOeK0rqz8L3ly9zPNZtM8gkaQXW0lgu0chv7vGOh71S j0rQ4tZ0y7TUrBLTTI3S0tlZcoXGCS5Y5HoMDFL31sw9x7oi/wCE9/0S7vF0qVrWKGeWKQO3 z+UTw3y4TODjluldTp89zc2MU11bJbyuMmJZfMCjtzgdqxP7M8JFrkk2P+kq6SD7Txhzl8Dd hc98YrXXVdLRQq6haAAYA89f8auPN9pkyt9lF2uA8bRJP4nso5FDI1jJkH/roldn/a+m/wDQ QtP+/wAv+NcT4pure68VWRt54pgtlICY3DY+dfSlVacR0k+Y5K5mfRIZknfdZurBXP8ACSP5 +o79RzkV7z4fBHhvSgRgizi4/wCACvILsZtJvUISCOoI5BHvmvYdEmkuNA06aVy8slrE7sep JUEmvKxatY76LumX6KKK4jY8k8Pf8i5pv/XtH/6CK0q5vRPEGkW+h2MM2pW0cscCK6NIAVIH INX/APhJtD/6Ctp/39Ffb0qtPkXvLbufl2Iw1Z1ptQe76PuatFZX/CTaH/0FbT/v6KP+Em0P /oK2n/f0Vftaf8y+8y+rV/5H9zNWisr/AISbQ/8AoK2n/f0Uf8JNof8A0FbT/v6KPa0/5l94 fVq/8j+5mrRWV/wk2h/9BW0/7+ij/hJtD/6Ctp/39FHtaf8AMvvD6tX/AJH9zNWisr/hJtD/ AOgraf8Af0Uf8JNof/QVtP8Av6KPa0/5l94fVq/8j+5mrRWV/wAJNof/AEFbT/v6KP8AhJtD /wCgraf9/RR7Wn/MvvD6tX/kf3M1aKyv+Em0P/oK2n/f0Uf8JNof/QVtP+/oo9rT/mX3h9Wr /wAj+5mrRWV/wk2h/wDQVtP+/oo/4SbQ/wDoK2n/AH9FHtaf8y+8Pq1f+R/czVrzfSv+QZB/ u/1rs/8AhJtD/wCgraf9/RXF6SQdLtyDkbf61yYmcZSjyu+/6Hp4ClOFOfPFrVb/APbx2Pw/ /wCR4g/69Jv5pXsNePfD/wD5HiD/AK9Jv5pXsNfN47+O/kfa5b/u0fn+bCuL+If3NC/6/wBv /REtdpXF/EP7mhf9f7f+iJa5VudxzVdZ4D/5FG3/AOvi5/8ASiSuTrrPAf8AyKNv/wBfFz/6 USVji/gXqdeD+N+ho+DP+RF8Pf8AYMtv/RS1uVh+DP8AkRfD3/YMtv8A0UtblbPc5DN07/ke 77/sGQf+jZa6euIfXtJ0PxzctqmoW9msumwiMzOF3YllzjP1Fan/AAn/AIR/6GPTf+/6142M hJ1m0u35G0Xoc1rEC2HizxLNqnhy71mDU7WBLFYrUzK2xGDRFgD5eW+bJwOc9RU+i3L6F4z8 RSXekanFDdrZCD7PZSzoNkADKHRSDtJxn2re/wCE/wDCP/Qx6b/3/Wj/AIT/AMI/9DHpv/f9 ai82rOL2t18v8hnm0ejalDf6HLPaalbRRWt8kkkelG6Ks12zKChU4yvIOOn1qfWfD2rzXOua 3o1pePcx6VBbJE9s1uLyJ45FmUR4GHB2uABwQBjkV6F/wn/hH/oY9N/7/rR/wn/hH/oY9N/7 /rWntat78v8AV7isjm4/D7Pq/wAP3m0kssNhKt6z2+QjfZ0VRIccHIIGfSsvT9OvYPGNqLTS 77YurzXE1rfWAMduHL7p47oAZB6hST1x2Fdx/wAJ/wCEf+hj03/v+tH/AAn/AIR/6GPTf+/6 1CnU/l/rX/MLI6OuK+J//IuWP/YTtv8A0KtL/hP/AAj/ANDHpv8A3/WuV8feK9A1fR7C107W LO6uDqVu3lxShmwG5OKijTmqibQ29DLrovAP/IHvf+v+b+lc7XReAf8AkD3v/X/N/SvTw+7M 5bHVUUUV1EBRRRQAUUUUAFFFFABRRRQBxPxD/wBZoP8A1+P/AOiZK5yuj+If+s0H/r8f/wBE yVzlaLYDrfAn/In2n/XSf/0c9aHgz/kRfD3/AGDLb/0UtZ/gT/kT7T/rpP8A+jnrQ8Gf8iL4 e/7Blt/6KWuSj8c/X/M68R8EPT/I3KKKK3OQKKKKACiiigAooooAKKKKACuJ+If+s0H/AK/H /wDRMldtXE/EP/WaD/1+P/6Jkpx3A5yuq8F/8iRB/vXH/o165Wuq8F/8iRB/vXH/AKNescX8 C9Trwnxv0OB0T/kA6d/16xf+giuZ8e/6yw+j/wDstdNon/IB07/r1i/9BFcz49/1lh9H/wDZ adP+IOp8B7h4R/5FLSv+vdf5VL4c/wCP/wARf9hMf+k8FReEf+RS0r/r3X+VS+HP+P8A8Rf9 hMf+k8FY0f4kv66l4n+FEw/EugaXr/jNItUtRcJDp6tGC7LtJkbPQj0FVf8AhXPhP/oEJ/3+ k/8Aiq3L3/keG/7Bqf8Aoxqu19Lg4RdFNo+fxE5Ko0mcD4g8NeBvDWnpe32jO0TyiIeVJIxy QT/fHHBqtPo/gODWLvTP7DnkuLWNJHMbuVIZkAwd/J/eKT7V1PivQpPEFnZWq7PLjvI5Zg5x mMBgwHvzXKWvgPWI7QefPbyXUkIWZy5xuE8TDnHTy4h+NXOFnpFW9BRldayf3m4PAPg1p2gX TYTMoy0YuH3AepG6mjwL4JMDTixtzEhw0gun2g+hO73qqfCWosdRtxDp6/aWu2XUd7G4/eg7 R90YxnB5PA4qtN4L1C5id/sNhaALbqLW0uCgZoyxMu7Zjd82ACp4zmnZfyBd/wAxqN4E8FJG kjWFuscmAjG5cBs9MHdzWLc6X8OrTV59On04I8BRZJTK+wO5AVM78559MDnJqw3g7VDZWwuL fTL51sprXyJcJHCzuWEi7UwWxgEhVyaiufAF2Y7krHZXEvmWLxmXgy+UAJdx2nG45PfPek12 ghp95Ms6t4W8F6Q1vE+gz3NxcbvKgtmkd2CjLH7wGBkd+9VG0fwCLNbtdFmaBoY5gwaQcPJ5 YXBcEMG6iuj8T6NcaqbDZp1jewQljJDNK0LqxA2tHIoyMYORjkfSsY+D9Zey8ue6hnm+xwQF 3kYnKXJlIyRkgJgAnk4olDV2ivuFGWivJ/eaC+AfBjhCunQMHJCEXDncR1A+bnofypn/AAg/ gjyRN9itvKJ2h/tT7c+md3tVe68FXtxdawkd3HFZyxTmwAJzFLOB5hPHAyDjGeHNR2vgq6YQ /aobXZ9ugnmgLqyFI4mQ8LGoySR25AGTT5f7iC/94fZ+E/BF/bXs9tpBdLOaSGTEkmSydcfN z7VLF4M8EPa2876dFAJ4llVJrh1YAjPI3+9S6fpGtadHrFjHZWTWt9eTzJL9qKlEk4HybD0+ tcjrujz2UUumtaxXl7PZWESExSFomjwpER2FSCck/MuOc0naKvyr7hq7duY6K28LeA7lLphp 0cf2WSWOQSTuD+7JDMBv+7weatWHgjwVqdjDe2emRy28yh0cTScj/vqoZPBc8kxlC2qSyald zyyfxGGVJFCk45+8uR0rf8K6bPo/hiw0+5ihjmt4hG4hbcrEfxZwOT1/GqjBN2cUTKTSupMz v+Fc+E/+gQn/AH+k/wDiq4/xR4Zs9G8Q2i6DELOQ2ryEb2ZZCHUYbJPGDXrNcH4x/wCRrsf+ vGT/ANDSirTio6IKc5OWrObiv1vbC5BQxXEaMssLdUOP1Hoa9p8Pf8i1pX/XnD/6AK8T1fTz NC91bSCG7jjID4yGXHKsO4/lXt2ghR4d0wISy/ZIsEjBI2DtXmYu+lzto21saFFFFcRscD40 8Fm4aXV9IizcH5ri2Qf631dR/f8AUfxfXr5urB1DKcg19DVxniL4fW+sagb2yvP7Pmk5nAh8 xZG/vYyMH1Pf65J9DC4z2a5Z7HlY7LvbPnp6S/M8toru/wDhVV1/0MK/+AP/ANso/wCFVXX/ AEMK/wDgD/8AbK7Pr9E87+ysR5fecJRXd/8ACqrr/oYV/wDAH/7ZR/wqq6/6GFf/AAB/+2Uf X6If2ViPL7zhKK7v/hVV1/0MK/8AgD/9so/4VVdf9DCv/gD/APbKPr9EP7KxHl95wlFd3/wq q6/6GFf/AAB/+2Uf8Kquv+hhX/wB/wDtlH1+iH9lYjy+84Siu7/4VVdf9DCv/gD/APbKP+FV XX/Qwr/4A/8A2yj6/RD+ysR5fecJRXd/8Kquv+hhX/wB/wDtlH/Cqrr/AKGFf/AH/wC2UfX6 If2ViPL7zhKK7v8A4VVdf9DCv/gD/wDbKP8AhVV1/wBDCv8A4A//AGyj6/RD+ysR5fecJVaS N4JDNCpZTzJGO/uPf+deif8ACqrr/oYV/wDAH/7ZR/wqq6/6GFf/AAB/+2UnjqLKjleIXb7z G+HciS+NLZ0YMps5iCPqlex1w/hf4eHw5r51VtWNyTC0flLb+WMsRlvvHn5a7ivLxNRVKjkj 28JRdGioPp/mFcX8Q/uaF/1/t/6IlrtK4v4h/c0L/r/b/wBES1itzpOarrPAf/Io2/8A18XP /pRJXJ11ngP/AJFG3/6+Ln/0okrHF/AvU68H8b9DR8Gf8iL4e/7Blt/6KWtysPwZ/wAiL4e/ 7Blt/wCilrcrZ7nIZmtaLBrVqEdjFcRktBOoy0bf1B7jv9cEcK6T2t1JZXsYiuoxllByrr2d T3U/p0PNem1m61otvrVqEkYxTxktBOo+aNv6g9x3+uCMqlNTXmNOxwtFa3/CEar/ANDBB/4L /wD7ZR/whGq/9DBB/wCC/wD+2Vz+wkXzIyaK1v8AhCNV/wChgg/8F/8A9so/4QjVf+hgg/8A Bf8A/bKPYSDmRk0Vrf8ACEar/wBDBB/4L/8A7ZR/whGq/wDQwQf+C/8A+2UewkHMjJpksUc8 TRSoHjcYZSOCK2f+EI1X/oYIP/Bf/wDbKP8AhCNV/wChgg/8F/8A9so9hMOZHNRSyWMq21y5 eFzthnY857Ix9fQ9/r17HwD/AMge9/6/5v6VQl8B6jPE0Uuu27xuMMp0/gj/AL+Vv+F9Abw5 pBsnvWvHaVpWmZNpJbtjJ9PWtqVNxbbJbubVFFFbEhRRRQAUUUUAFFFFABRRRQBxPxD/ANZo P/X4/wD6JkrnK6P4h/6zQf8Ar8f/ANEyVzlaLYDrfAn/ACJ9p/10n/8ARz1oeDP+RF8Pf9gy 2/8ARS1n+BP+RPtP+uk//o560PBn/Ii+Hv8AsGW3/opa5KPxz9f8zrxHwQ9P8jcooorc5Aoo ooAKKKKACiiigAooooAK4n4h/wCs0H/r8f8A9EyV21cT8Q/9ZoP/AF+P/wCiZKcdwOcrqvBf /IkQf71x/wCjXrla6rwX/wAiRB/vXH/o16xxfwL1OvCfG/Q4HRP+QDp3/XrF/wCgiuZ8e/6y w+j/APstdNon/IB07/r1i/8AQRXM+Pf9ZYfR/wD2WnT/AIg6nwHuHhH/AJFLSv8Ar3X+VS+H P+P/AMRf9hMf+k8FReEf+RS0r/r3X+VS+HP+P/xF/wBhMf8ApPBWNH+JL+upeJ/hRMnxnb61 YXq69pLWzRJb+RcpNA0hRQxYOArrkcnPp19ccwPFHiNgCLjSSDyCLKT/AOPV63XnXinwsdLM mpabGTYnLT26D/UerqP7nqO3UcdPXw2I5fcb0PJq0k/eRk/8JP4k/wCfjSf/AABk/wDj1H/C T+JP+fjSf/AGT/49WD/bek/9BOy/8CE/xo/tvSf+gnZf+BCf4138/mc/J5G9/wAJP4k/5+NJ /wDAGT/49R/wk/iT/n40n/wBk/8Aj1YP9t6T/wBBOy/8CE/xo/tvSf8AoJ2X/gQn+NHP5hye Rvf8JP4k/wCfjSf/AABk/wDj1H/CT+JP+fjSf/AGT/49WD/bek/9BOy/8CE/xo/tvSf+gnZf +BCf40c/mHJ5G9/wk/iT/n40n/wBk/8Aj1H/AAk/iT/n40n/AMAZP/j1YP8Abek/9BOy/wDA hP8AGj+29J/6Cdl/4EJ/jRz+Ycnkb3/CT+JP+fjSf/AGT/49R/wk/iT/AJ+NJ/8AAGT/AOPV g/23pP8A0E7L/wACE/xo/tvSf+gnZf8AgQn+NHP5hyeRvf8ACT+JP+fjSf8AwBk/+PUf8JP4 k/5+NJ/8AZP/AI9WD/bek/8AQTsv/AhP8aP7b0n/AKCdl/4EJ/jRz+Ycnkb3/CT+JP8An40n /wAAZP8A49R/wk/iT/n40n/wBk/+PVg/23pP/QTsv/AhP8aP7b0n/oJ2X/gQn+NHP5hyeRvf 8JP4k/5+NJ/8AZP/AI9WRqV9qV1qMOo6i9tIkULQkW0DR7ASDuILtnp2xUH9t6T/ANBOy/8A AhP8aP7b0n/oJ2X/AIEJ/jScr9RqNuhZuWDWUrKQVMZII6HivXvD3/ItaV/15w/+gCvB7nVt Ns4ZvI1C0kt3UgxJMpMZPdRnke35V7z4fBHhvSgRgizi4/4AK4cW72OiirXNGiiiuI2Ciiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAri/iH9zQv8Ar/b/ANES12lc X8Q/uaF/1/t/6IlprcDmq6zwH/yKNv8A9fFz/wClElcnXWeA/wDkUbf/AK+Ln/0okrHF/AvU 68H8b9DR8Gf8iL4e/wCwZbf+ilrcrD8Gf8iL4e/7Blt/6KWtytnucgUUUUgCiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDifiH/rNB/6/H/8ARMlc5XR/EP8A1mg/ 9fj/APomSucrRbAdb4E/5E+0/wCuk/8A6OetDwZ/yIvh7/sGW3/opaz/AAJ/yJ9p/wBdJ/8A 0c9aHgz/AJEXw9/2DLb/ANFLXJR+Ofr/AJnXiPgh6f5G5RXHfFG9vtP8B3k+nXUlrdebCqSx uVZcyKDyPrXLN4z1HUj4Rgeea01KLVxY6rbo23cw65A6q3X866UrnIetUVxOtfECXQruR7vw /eJpcdyLZrx5EQsScbkjPzMuT1FUY/FmsT/EDX9HntJ002ztCVaJkDRDaT5mepLYGPTPNKzA 9EorifDfi+DyvDWnSpfSDVbR5be8u5A7O65JRyMfNjn8aB8R7WeximstNuLme7vpLLT4FcKb rZ96TceFT3NFmB21FYnhzxJF4gjvENrLZ3tjMYLq1lIYxv14YcMCOhrl7k6v4w8e6rpMWsXm laRo6xLJ9icJLPI67vvckADI/D3osB6HRXl0OreKdKm8T+Fre7k1XUbKzW6065lVTIUbGVb+ 8wzxnqR9Kz/CWuef4i0uKDxZqi3jfJf6Zrit+8OORFxhTnOBnPT3p8oHsNcT8Q/9ZoP/AF+P /wCiZK7auJ+If+s0H/r8f/0TJSjuBzldV4L/AORIg/3rj/0a9crXVeC/+RIg/wB64/8ARr1j i/gXqdeE+N+hwOif8gHTv+vWL/0EVzPj3/WWH0f/ANlrptE/5AOnf9esX/oIrmfHv+ssPo// ALLTp/xB1PgPcPCP/IpaV/17r/KpfDn/AB/+Iv8AsJj/ANJ4Ki8I/wDIpaV/17r/ACqXw5/x /wDiL/sJj/0ngrGj/El/XUvE/wAKJvUUUV1HAFFFFABRRRQAUUUUAFFFFABRRXOeLPFg8LDT 1GnT3819P5EUUDAMWxkdaNwOjorldD8bLqmuHRb/AEe+0nUDCbiOO6CkSIDgkEHrXTLcQvJ5 aTRs+3ftDAnbnGcemadgJKKiiuredXaKeKRUOHKOCFPv6U/zEyo3r8/K89fpSAdRUUlzBFG0 kk0aRqcMzOAAfQmnCaIw+cJEMW3dvDDbj1z6UAPoqNLiGSATpNG0R6SBgVP40scscu7y5EfY xVtrA7WHUH3oAfRXn03xLvrfVINMk8G6qt5cKzww+YmXVepHNb9n4tin1saVdWcljMNOS/lM 7qBHubbsPuDTswOioqhe6jJa3NhHDZyXMd1JsaWNhtiGM7j6j6Vaa6t0ZVaeJWZtiguAS3oP f2pAS0UyaaO3gkmmcJFGpd2booAySa4M/FGLyF1MeHdWOgFtv9p7Bjrjds67c8Z//VTSbA7+ iuffxXCddudKt7WSeWHTP7RV0YYlUkgKPc+vvWnbaikmmW17dqLIzIrGOd1BRiM7Sc4zRYC7 RSFlBAJAJ4GT1rN1TX9N0jRLjWLm4DWcAyzxfPnnGBjqc0gNOiqkepWj2MF488cUU6hkMjhe ozjr1q2CCMjkUAFFFFABRRRQAUUUUAFFFFABRRRQAVxfxD+5oX/X+3/oiWu0ri/iH9zQv+v9 v/REtNbgc1XWeA/+RRt/+vi5/wDSiSuTrrPAf/Io2/8A18XP/pRJWOL+Bep14P436Gj4M/5E Xw9/2DLb/wBFLW5WH4M/5EXw9/2DLb/0UtblbPc5AooopAFFFYyeIYn8YyeHBA/nR2IvDNkb cF9u3Hr3oA2aKhjureaR44riKR4/vqrglfqO1P8ANj8vzN67P72ePzoAfRUTXVutwtu08QmY ZEZcbj+HWq2tanHouiX2pyxtIlpA8zIp5YKM4FAF6iuP0XxpqWsXFmP+ES1O3tLoKwu3dCiq RkNwc4rqxdW7XBtxPEZwMmMONwH0607AS0VlaV4i0/Wb/UbSydnk0+XyZiRgFu+PUD1ql4j8 XQaDd2unw2N1qOq3YLQWdsBuKjqzE8KOvPtRYDoqK460+IFvNpmszXemXllf6RAZ7mxmA3bc ZBVuhB9fetnT9cfULqxRNPmW3urBbwXBYbULYxGe+cHOaLMDYoqOO4hmeRIpo3aM4dVYEqfQ +lI1zArojTRh5CQilhliOoHrSAlorKg8Rafc+I7rQonZr21iWWXjCjd0APc454rQiured3SG eKR4zh1RwSp98dKAJaKKKACiiigDifiH/rNB/wCvx/8A0TJXOV0fxD/1mg/9fj/+iZK5ytFs B1vgT/kT7T/rpP8A+jnrQ8Gf8iL4e/7Blt/6KWs/wJ/yJ9p/10n/APRz1oeDP+RF8Pf9gy2/ 9FLXJR+Ofr/mdeI+CHp/kReNdAuPE3hmbTLWWKKV5YnDS524Vwx6A+lYniH4eHU/HukeJrGe KBreZJLyN8/vdh+UjH8WMj8q7yiuhNo5DyjU/hjrd8mrwm50iY3d79qjvbiN2udu4ERk4wqj H8P0xjp0c/hTVR421TWLW4svsWqWQt50l3eYjKhVduBjGduSe2eKZf8AxFEd5fRaPoOoavBp zFLy5t9oRGH3lXPLkdwK0R420+aHw/PaxSyw61KYomI2mMgEncD6EEcVV2BjXvgG+uPh3pWi wXsEGr6YUeC6XO0MCQecZwVJ7dcU7WPh2s+g+HrTTjaefoo+SK7QtBOGAEgcDnkjOfWut07U nvIbuW4tJLJbeeSL98w+ZV/jyOgNXFnheETJKjREZDhgVI+tK7A5/wAH+HZ9BtLo3aacl1cy 72WwtxHGij7q5xlsc8nnms/U/CutWni2fxH4YvrOKe8jWO9tb1GMUu0YVgV5BA/zzXYC4gZ5 EWaMvF/rFDDKfX0rN0TxHp2v6R/alnKRab3XfLhMbWKkn0HHeld7gczZeA9Re11y81PWmGv6 tGsZvLIGMW6r91U6HHAz6gY9zEfCPinWtT0STxHqGlG30m4W4V7KNxNOy9Nxb7ue+K76KWOe JZYZEkjboyMCD+Ip9F2AVxPxD/1mg/8AX4//AKJkrtq4n4h/6zQf+vx//RMlEdwOcrqvBf8A yJEH+9cf+jXrla6rwX/yJEH+9cf+jXrHF/AvU68J8b9DgdE/5AOnf9esX/oIrmfHv+ssPo// ALLXTaJ/yAdO/wCvWL/0EVzPj3/WWH0f/wBlp0/4g6nwHuHhH/kUtK/691/lUvhz/j/8Rf8A YTH/AKTwVF4R/wCRS0r/AK91/lUvhz/j/wDEX/YTH/pPBWNH+JL+upeJ/hRN6iiiuo4Aoooo AKKKKACiiigAooooAK8z+LpgWbws9zdXFpbpqO6W4tyRJEuOWUgEgj6V6ZRTTswPHPD9zav8 RlfQtT1DXLSXTJUvLq/Vne3AyVCuyrgE44qnpPh8wfAx9V0q2lOsXMDJPLGSZWgE/wA6D22r 0+te30U+YDx/S7fw1qnjXTLfwbARYPYzw6yIkZIzEyYRXz1fdmubt5NWtZYNRmSYjwO0drIm 4fvw0zK23/tntH4V9BhVXO0AZOTgdTS0cwHh9/pC2Xg/wzdX17Fa3d1PNqErXtsZ7SSSUB8T Y+6QoUA4POfemXNxdXXw0VLfTYLbTINcCXf2bznt54B1cKTuEe7GQOOOK9yIDAggEHgg96UA AYHAo5gPBruGMeCPG0+m3Nq9hILUCGxgkjgWXevMZbrkdcd8V7H4e0TT9C0tINOtxCsuJZTn JkcqAWJ7k4FaqqqKFUAAdABS0N3A4LWwT8Z/C5AOBZXOT6fKar3uh6frnxiuodTs0urdNERh HKMpu80jOOhIBP0zXotFK4HifhtpH0H4dhyxEeq3CLnsoL4pms6HYT+DvHmrPaiXUIdamWCV uWixIn3PTO45x1/Cvb6KfMBgahaXWs+ALi0hkJu7vTSisWwS7R9z7k1xWifETT9C8F6bpAsr q48Q2scdodJETLKzqdp52kAcZr1Sk2Lv37RuxjdjnFK4Hmetea/jjxE8kRR28JtuXOcNubIz 3rk7hdo8JHV1sf7J/sFFgOoxSSW4m/iyFIw+3GPw74r3mkZVYYYAj0IpqQHjEel/adB8AWN5 NJd2kmoybS6NGTCQxCsG5x291IqpreiWsOmfEqwtLILb2k1nPbQRg7Y2K/MyjtwW/wAivc6K OYDw3WI9EeLw7c6fe6fDaDTCkcGpWbvZyfORJtYcrJuLDgZ9+mfTPh9dNeeB9NmOn/YAUYLB vdgFDEAgv82D1GfWuk2IUCFV2joMcU6hu6AKKKKkAooooAKKKKACiiigAooooAK4v4h/c0L/ AK/2/wDREtdpXF/EP7mhf9f7f+iJaa3A5qus8B/8ijb/APXxc/8ApRJXJ11ngP8A5FG3/wCv i5/9KJKxxfwL1OvB/G/Q0fBn/Ii+Hv8AsGW3/opa3Kw/Bn/Ii+Hv+wZbf+ilrcrZ7nIFFFFI DK8Saw/h/wAP3eqpZS3htlDmGI4ZhkAnoegOfwrgLXW7XWvHOu6/pcFxf6fB4eMTGINGXkDl vLDcEMQD059K9UpFVVGFAA9AKadgPCvC/wDZsnjPwlcWQ0y3WeOdLiGyt5PlzGcRyyOTvbOR 04x71oafpV1J4otfh/LHKdL0vUJNS3sMq1vgNEmf99yD/wDWr2UAKMAAd+KWnzAfPXiy8sr1 9cu4rSz0/UoNUHBjlkvThwDIXJwiegAx29K9k8dfN4B17bzmwlxjv8proAqhiwAyepx1paGw OF8DeGLiy0vRtUbxDrFzGbKNxZTTgwjdGMADHQZ457CvN47nT7vUdE1G2gsdNuxrqGaFIpZb qJS5BM8rn6cYwc+1fQVIAASQAM8n3oUgPL/hvaaVp3jrxdZxwJBfpdOYU2kEW2R0PTGdtXPE dwPDPxSsfEmpeaujzac1k1wFLLBJvLfNjOAR/X0r0TAyTgZPGaCAwIIBB4IPei+oHnWq+Lo/ FfhHxeunWMx0y3spFiv2yq3DlDkKpAPHr9PWsh0v/wC2dO/s0OL3/hCmEBXIPmcYxjvnp716 4AFAAAAHAA7UtFwPD/AcFvJ4h8Ntp09lBeQxSfbI7a1mErjb84uGYkbs9D69O1UrnRbJfhfq mtfZs6nFrLGK553xDzwMKewwSfqc174FUEkAAnqcdaWnzAePz2Ok2vxZ8TxTxPBcXWnGSzeG NmkLtE3mvHjq2Nx+vA5ql4AngtPFejWtrFpmpeZDIpvLSGS3uLdNuf36/cJJOOcnPf19swMg 4GRxmgKoJIABPU460uYBaKKKkAooooA4n4h/6zQf+vx//RMlc5XR/EP/AFmg/wDX4/8A6Jkr nK0WwHW+BP8AkT7T/rpP/wCjnrQ8Gf8AIi+Hv+wZbf8Aopaz/An/ACJ9p/10n/8ARz1oeDP+ RF8Pf9gy2/8ARS1yUfjn6/5nXiPgh6f5G5RRRW5yHkvhPxJYfD6x1rRfEDXEV/FfS3EIMLN9 qVgCpRgCCTjv6/XGnrGoXGr3fgDULjT5LCSa/ZzbOctGNhxngdsHp3r0YorEFlBI5BI6UtVf qB4Tfx3h8K3WEzpo8WTtfh0dk8vIwZAvJjz1x7U+WFD8PPG8thPbSadK0HlRWVvJHbpIGXcY 95Oc8E4/wr3OkACgAAADgAdqfMB5Y2gadpvxM8PWdpaBLe/0qeO9Az/pA2H757k+tcbptros vw1t4BP9iv4dUVrxms2li3BpBGs46bcHrzjHTpX0NSBFGcKPm5PHWlzAef8Awtu1nj1mKKxs Io0nRvtOneYLa4ZlyxRX4XGBnbgcjjivQaQAKAAAAOAB2paTdwCuJ+If+s0H/r8f/wBEyV21 cT8Q/wDWaD/1+P8A+iZKI7gc5XVeC/8AkSIP964/9GvXK11Xgv8A5EiD/euP/Rr1ji/gXqde E+N+hwOif8gHTv8Ar1i/9BFcz49/1lh9H/8AZa6bRP8AkA6d/wBesX/oIrmfHv8ArLD6P/7L Tp/xB1PgPcPCP/IpaV/17r/KsLxFaa1ot7danpusXVvp104luUiihbyZAqpvO+NjtIVc8/KR noSRu+Ef+RS0r/r3X+VbJAYEEAg8EGuNVHCo2jqdNVKaTPNv7V8Rf9DNf/8Afi1/+M0f2r4i /wChmv8A/wAB7X/4zV3XNAk0ZzcWEE0+nseYII2keA/7KqCSnsB8v0+7i/aJf+gZrH/gquf/ AI3XowqQkro82dKUXZou/wBq+Iv+hmv/APwHtf8A4zR/aviL/oZr/wD8B7X/AOM1S+0S/wDQ M1j/AMFVz/8AG6PtEv8A0DNY/wDBVc//ABuqvEnll2Lv9q+Iv+hmv/8AwHtf/jNH9q+Iv+hm v/8AwHtf/jNUvtEv/QM1j/wVXP8A8bo+0S/9AzWP/BVc/wDxui8Q5Zdi7/aviL/oZr//AMB7 X/4zR/aviL/oZr//AMB7X/4zVL7RL/0DNY/8FVz/APG6PtEv/QM1j/wVXP8A8bovEOWXYu/2 r4i/6Ga//wDAe1/+M0f2r4i/6Ga//wDAe1/+M1S+0S/9AzWP/BVc/wDxuj7RL/0DNY/8FVz/ APG6LxDll2Lv9q+Iv+hmv/8AwHtf/jNH9q+Iv+hmv/8AwHtf/jNUvtEv/QM1j/wVXP8A8bo+ 0S/9AzWP/BVc/wDxui8Q5Zdi7/aviL/oZr//AMB7X/4zR/aviL/oZr//AMB7X/4zVL7RL/0D NY/8FVz/APG6PtEv/QM1j/wVXP8A8bovEOWXYu/2r4i/6Ga//wDAe1/+M0f2r4i/6Ga//wDA e1/+M1S+0S/9AzWP/BVc/wDxuj7RL/0DNY/8FVz/APG6LxDll2Lv9q+Iv+hmv/8AwHtf/jNH 9q+Iv+hmv/8AwHtf/jNUvtEv/QM1j/wVXP8A8bo+0S/9AzWP/BVc/wDxui8Q5Zdi7/aviL/o Zr//AMB7X/4zR/aviL/oZr//AMB7X/4zVL7RL/0DNY/8FVz/APG6PtEv/QM1j/wVXP8A8bov EOWXYu/2r4i/6Ga//wDAe1/+M0f2r4i/6Ga//wDAe1/+M1S+0S/9AzWP/BVc/wDxuj7RL/0D NY/8FVz/APG6LxDll2Lv9q+Iv+hmv/8AwHtf/jNH9q+Iv+hmv/8AwHtf/jNUvtEv/QM1j/wV XP8A8bo+0S/9AzWP/BVc/wDxui8Q5Zdi7/aviL/oZr//AMB7X/4zR/aviL/oZr//AMB7X/4z VL7RL/0DNY/8FVz/APG6PtEv/QM1j/wVXP8A8bovEOWXYu/2r4i/6Ga//wDAe1/+M0f2r4i/ 6Ga//wDAe1/+M1S+0S/9AzWP/BVc/wDxuj7RL/0DNY/8FVz/APG6LxDll2Lv9q+Iv+hmv/8A wHtf/jNH9q+Iv+hmv/8AwHtf/jNUvtEv/QM1j/wVXP8A8bo+0S/9AzWP/BVc/wDxui8Q5Zdi 7/aviL/oZr//AMB7X/4zR/aviL/oZr//AMB7X/4zVL7RL/0DNY/8FVz/APG6PtEv/QM1j/wV XP8A8bovEOWXYu/2r4i/6Ga//wDAe1/+M0f2r4i/6Ga//wDAe1/+M1S+0S/9AzWP/BVc/wDx uj7RL/0DNY/8FVz/APG6LxDll2Lv9q+Iv+hmv/8AwHtf/jNH9q+Iv+hmv/8AwHtf/jNUvtEv /QM1j/wVXP8A8bo+0S/9AzWP/BVc/wDxui8Q5Zdi7/aviL/oZr//AMB7X/4zR/aviL/oZr// AMB7X/4zVL7RL/0DNY/8FVz/APG6PtEv/QM1j/wVXP8A8bovEOWXYu/2r4i/6Ga//wDAe1/+ M0f2r4i/6Ga//wDAe1/+M1S+0S/9AzWP/BVc/wDxuj7RL/0DNY/8FVz/APG6LxDll2Lv9q+I v+hmv/8AwHtf/jNH9q+Iv+hmv/8AwHtf/jNUvtEv/QM1j/wVXP8A8bo+0S/9AzWP/BVc/wDx ui8Q5Zdi7/aviL/oZr//AMB7X/4zVHUX1i/FvJc6xcXjW0nmxRTxwohbaVOSkanoxHXjOcGl +0S/9AzWP/BVc/8Axuj7RL/0DNY/8FVz/wDG6OaIcsuwttcpdRllBVlO10bhkb0P+ffpXZeA /wDkUbf/AK+Ln/0okrgrkXHmC5ttN1ZbhRgg6XchZF/ut+7/ACPb6ZB7/wACxTxeELQXNtNb StJPIYp0KOoaZ2GQenBFc2KacFbudWEi1N37HMXEPiLwwbfS18Q3yWCIIrJ1gtiCijAQkxE7 gB3PIGR3AT+1fEX/AEM1/wD+A9r/APGa9CvrG31GzktbqISQyDkHjHoQexB5BHSvPdS0290W 58iW3vLyE8w3FtavMWHo4RTtYfgD1HcB0a6lpLcmvh3F3jsH9q+Iv+hmv/8AwHtf/jNH9q+I v+hmv/8AwHtf/jNUvtEv/QM1j/wVXP8A8bo+0S/9AzWP/BVc/wDxuui8Tn5Zdi7/AGr4i/6G a/8A/Ae1/wDjNH9q+Iv+hmv/APwHtf8A4zVL7RL/ANAzWP8AwVXP/wAbo+0S/wDQM1j/AMFV z/8AG6LxDll2Lv8AaviL/oZr/wD8B7X/AOM0f2r4i/6Ga/8A/Ae1/wDjNUvtEv8A0DNY/wDB Vc//ABuj7RL/ANAzWP8AwVXP/wAbovEOWXYu/wBq+Iv+hmv/APwHtf8A4zR/aviL/oZr/wD8 B7X/AOM1S+0S/wDQM1j/AMFVz/8AG6PtEv8A0DNY/wDBVc//ABui8Q5Zdi7/AGr4i/6Ga/8A /Ae1/wDjNH9q+Iv+hmv/APwHtf8A4zVL7RL/ANAzWP8AwVXP/wAbo+0S/wDQM1j/AMFVz/8A G6LxDll2Lv8AaviL/oZr/wD8B7X/AOM0f2r4i/6Ga/8A/Ae1/wDjNUvtEv8A0DNY/wDBVc// ABuj7RL/ANAzWP8AwVXP/wAbovEOWXYu/wBq+Iv+hmv/APwHtf8A4zR/aviL/oZr/wD8B7X/ AOM1S+0S/wDQM1j/AMFVz/8AG6PtEv8A0DNY/wDBVc//ABui8Q5Zdi7/AGr4i/6Ga/8A/Ae1 /wDjNH9q+Iv+hmv/APwHtf8A4zVL7RL/ANAzWP8AwVXP/wAbo+0S/wDQM1j/AMFVz/8AG6Lx Dll2Lv8AaviL/oZr/wD8B7X/AOM0f2r4i/6Ga/8A/Ae1/wDjNUvtEv8A0DNY/wDBVc//ABuj 7RL/ANAzWP8AwVXP/wAbovEOWXYu/wBq+Iv+hmv/APwHtf8A4zR/aviL/oZr/wD8B7X/AOM1 S+0S/wDQM1j/AMFVz/8AG6PtEv8A0DNY/wDBVc//ABui8Q5Zdi7/AGr4i/6Ga/8A/Ae1/wDj NH9q+Iv+hmv/APwHtf8A4zVL7RL/ANAzWP8AwVXP/wAbo+0S/wDQM1j/AMFVz/8AG6LxDll2 E1F9Xvzby3Or3F69q5kiinjhRSSpU8pGp6E+3tTra5S6i3pkEHa6MMMjdwR60n2iX/oGax/4 Krn/AON1UuRcCX7Va6bqwuAMMp0u5Cyr6H93+R7fTIo5l3Dll2O/8Cf8ifaf9dJ//Rz1zNxD 4i8MG30tfEN8lgiCKydYLYgoowEJMRO4AdzyBkdwOo8DxTw+ELJbi3mt5SZXMUyFHUNIxGQe hwRWzfWNvqNnJa3UQkhkHIPGPQg9iDyCOleeqvs6jfS56MqKqU0utjz3+1fEX/QzX/8A4D2v /wAZo/tXxF/0M1//AOA9r/8AGaNS0290W58iW3vLyE8w3FtavMWHo4RTtYfgD1HcCl9ol/6B msf+Cq5/+N13qcWro8905J2aLv8AaviL/oZr/wD8B7X/AOM0f2r4i/6Ga/8A/Ae1/wDjNUvt Ev8A0DNY/wDBVc//ABuj7RL/ANAzWP8AwVXP/wAbp3iLll2Lv9q+Iv8AoZr/AP8AAe1/+M0f 2r4i/wChmv8A/wAB7X/4zVL7RL/0DNY/8FVz/wDG6PtEv/QM1j/wVXP/AMbovEOWXYu/2r4i /wChmv8A/wAB7X/4zR/aviL/AKGa/wD/AAHtf/jNUvtEv/QM1j/wVXP/AMbo+0S/9AzWP/BV c/8Axui8Q5Zdi7/aviL/AKGa/wD/AAHtf/jNH9q+Iv8AoZr/AP8AAe1/+M1S+0S/9AzWP/BV c/8Axuj7RL/0DNY/8FVz/wDG6LxDll2Lv9q+Iv8AoZr/AP8AAe1/+M1R1F9Xvzby3Or3F69q 5kiinjhRSSpU8pGp6E+3tS/aJf8AoGax/wCCq5/+N0faJf8AoGax/wCCq5/+N0c0Q5Zdhba5 S6i3pkEHa6MMMjdwR612Hgv/AJEiD/euP/Rr1wdyLgS/arXTdWFwBhlOl3IWVfQ/u/yPb6ZF d94Ninh8E2y3FvNbykTOYpkKOoaRyMg9DgiubFNOCt3OrCRam79jz/RP+QDp3/XrF/6CK5nx 7/rLD6P/AOy102if8gHTv+vWL/0EVzPj3/WWH0f/ANlqqf8AECp8B7h4R/5FLSv+vdf5VtVi +Ef+RS0r/r3X+VbVcE/iZ3Q+FBRRRUlBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFc7qvjvwzoeoSWGparHb3UYBaNo3JAIyOgI6GmouWiQm0tzoqKzN F8Q6R4it3n0m/iu0jO19hIKntkHkVkT/ABI8H2961pJrtuJVbYcBmUH/AHgNv601CTdrC54p XudVRVHUNZ0/S9LOpXl0qWfy4lUFw24gLgLknJI6Vi3vxF8J6dez2d3rMUVxA5jkQxudrDgj haFCT2QOUVuzqKKy4PEej3WiS6zb6hDLp8Ss0k6HcECjJyByCB2xmsT/AIWj4L/6DsP/AH6k /wDiaFCT2QOcVuzr6KxdS8XaDo+nWt/f6lFBbXah4GYMTIpAIIUDOMEduM0ui+K9C8RRzPpO oxXIgGZAAVZR64IBx70ckrXsHNG9rmzRWXZeI9H1HRpNYtb+N9Pj3b7ggqq7eucgVmyfELwr FYQ38mrKtrO7JFKYZAHZcbgPl5xkUckn0Dnj3Omorl7P4jeEtQvYLO11mKS4ncRxoI3G5icA crVjWfG/hvw/d/ZNU1aGC4wCYgGdlB6ZCg4/Gj2c72sLnja9zoKKy7LxHo+paPLq1nfxT2MS M8kqZOwKMnI6g45xjNYyfE/wY7qg16AEnA3I4H5lcChQk9kNzit2dbRVG+1nT9Otbe5urlVh uZEihdQXEjP90DaDnNVNO8WaFq2rXGlWOoxzX1vu82EKwK7TtbqMHB9KXK7XsHMr2ubNFY0f ivQ5fEDaDHqEbampINuFbIIXcecY6e9V9Y8deGdBvTZ6lq8MNyBkxhWcr9doOPxp8km7WDnj vc6Gis208QaTf6NJq9pfRTWEas7zISQoUZbI6ggc4xmsNfih4LZgo16HJOOY5AP/AEGhQk9k DnFbs66is278QaVYy6fHcXsatqLhLTblhMTjGCAR/EOfenWWt6bqGo3un2t0sl3ZEC4jCkGM nOOoweh6UuV72HzLY0KKzNb8QaV4ctY7nVrxbWGR/LVmVjlsE44B7A1lWfxG8JahewWdrrMU lxO4jjQRuNzE4A5WmoSaukJzinZs6iisvUPEek6Vcy297diKWK2+1yAxsdsW7buJAx14x1rI g+JXg65nSGPXrcO5wN6sgz7lgAPxoUJPVIHOK0bOrorG1vxZofhwwDVtQjtvtAJiyrNuAxno D6iqNl8QvCuo3Bt7PV45pQjybFikztVSzH7vYAmhQk1dIOeKdrnT0VS0nV7DXNPS/wBMuVuL VyQsigjkHB4PNZY8ceGzB541SMxfavse8RuQZsZ2jjk/pS5ZbWDmXc6GisnW/E+i+G4kk1fU IrUSHCK2SzfRQCce+KbpPivQ9ds57rTNRiuIrcEy7QQyADOSpAP6UcsrXtoHMr2ubFFch/wt HwX/ANB2H/v1J/8AE1pXHjLw9aaJb6xPqkMdhcEiGVg37zBwcLjcenpTdOa3QueL6m7RWLoX i7QfEsksekalFcyRAM6AMrAeuGAJHvW1SaadmUmnqgooopDCiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKZN/qJP90/yp9Mm/1En+6f5UCPHtE/5AOnf9es X/oIrmfHv+ssPo//ALLXTaJ/yAdO/wCvWL/0EVzPj3/WWH0f/wBlr0af8Q4KnwHuHhH/AJFL Sv8Ar3X+VbVYvhH/AJFLSv8Ar3X+VbVcE/iZ3Q+FBRRRUlBRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFeK6zfTWHxw1KWDQpNadrKNPsyAcZWP5uQeB/Wv aq5q38IJB4/uvFX2xi9xbC3+z+XwuAozuz/s+netaU1G9+xlUi5Wt3PNrjS9c0/SvGnil9LG iR3tosMNmjAkAsqsxA6HGeePvHFdz4d8O+Hm+Gdlbz21r9imsVluJWC9SmWct2IJPPbHtXX3 VrBfWk1rcxLLBMhjkRujKRgivPn+FdyLJ9Jg8XalFobMf9B2AkKTnaHz059MVftFNWbsR7Nx d0rk2s2unO3gzw1pDJJp0l59pUrMZVMUALEbsnIJI/KsvwHaW138R/HQubeKYLdDAkQNj55P Wuy07wfZ6XrdlfWz7baxsDZW1ttzsy25n3Z5J6dKwJPhrfxa9qmqaZ4rutPbUZjLKkNuD3JA zu7ZNNTjZxv/AFcHCV07f1Y5SeKLTNe+JWl6eFTTjphmMSLhI5Ng4A6D7zf5FTeCm8Ujwfpw sPB+k31rsby7maZA7/Mc5B565H4V3Fj4AsrDw3q+mJe3E11qyOLq/nO+R2YEZx7ZPHv1rJsP hxrml2MVlY+Or6C2iBCRpbLhRnP971NV7WDVr9t79vIj2ck72/LuM8W6DqN14h0TV9Fl0v8A tmwttp0m5ZcMvP3R7ZYZ46DB4qv4b1SH/hMb611rwyujeJZ7Nz50MpMdygHOADt/hznnoea3 tY8Bvqo0u8j1y7tdc0+EQjUo1G6Vcc7lzjkknr3PWl0TwG1hrU+tarrNzq+pvEYY5pUCLEp6 7VBP+SeKnnjyWb/r/IvklzXS/r/M8T0271eXwRZxXFlcf8IpaXoN+8LbTNubJGfQADp3I9sf RlnZaRc6VZi1tbWSxWIG2AjBUIQMbcjjjFZHh3wTaaJ4Pl8N3E5vbWXzN7PGFyH9snp61P4O 8NTeE9G/sttSe+t0ctCXj2mMHqvU5Gee3U0VqkZ7dwpU5Q3OU+Ddnay+F7yaS2heVNTl2O0Y LLgIRg9qZ8IrS11Cy1rWLyKObVZ9RkWaSQBmUYBA56DLN/kV13g7wsnhHSZ7BLtrkS3L3G9k 2Y3ADGMn0rHvvh0663dap4e1670SW8O65jhjEkbt6gEjB5J/lih1IyclfcFCSUXbY5O4gi0j x94307TUEVlNoUs80EYIRJNgOcdP4j/31WPokmqax8NYtDsvA7Xbyo0UepuVVcmQ/OCQPu9O vavTdI+H9npWk6tAbye61HVYXiutQn+Z23AjgdhznGefWtnwvoS+GfDdno6XBuFtgwEpXaWy xbpk+tN1opaavT8CVSk3rpucdHps9vqPgTwtcSmR7CJr6628gGNdqc+gZiPwrgdFnGh+PZvE Tnbbpr89lcueirJnBP0wx/CvbodC2eLbnX5LoyPJaJaRQ7MCJA24855yeegrmLj4W2tzo2ua fJqLn+0777asnkjMDbicAZ54JHbrRCrFaPr/AEwnSluun9I4bwbHLN8QtC1yVAZ9Xa/u+OMr hlUe3Q/nXU/B2ztb/QdS1e8t459Sub+QTzSgO5GAcZPux+ua6Oz8DW9jq3h69huyq6NaNbLF 5f8ArdykFic8HJz3qhd/DiWHV7u/8OeIbvRPth3XEMUYeNm55AyMdT+fGKJ1Yzur2/4dhGnK Nna//DI5ZYIdL8afELTNOCx2DaNJO0Mf3Ek8sdB0H3249/asvSU8SzfDBYbXwpplzYNayAXr Ohl25bLbSQcjnH0FelaR4BstI0PVbNbqa4vtUidLq/n+aRyykZx6DJOM8+tYlv8ADDVrbSl0 qLxvqEenhShgjgCjaTyAd3fJ/OqVWHft36CdOXbuc/cy2Mtn8Lf7OmkmtkvBGHkUKxKsgbI7 cg8V0Xgf/kp/jn/rrD/7NWrJ8O7BY/DUNncvbwaHOZ0UoGMxLBjuORgkjr71Tufh3qH/AAkW p6vpniq6059QkDypFbg9OgyW571LnBpq/wDV7lKEk07f1axmfHDP/COaTtALf2iuAeh+Rq1d JPiltWtRfeDNHtLXzAZJ4pkZox6gDvRq3w7vNc8OQaXqXiW5uJ4bz7Ut28ALY27QmN3QcnPv U1p4N8R297BPL46v5445Fd4mt1AkAOSp579KXNHkUbrr3Hyy5+a35HOa+P7StPiLq5BKQxJp sJPYRgGQD/gTVd07RdLvvggj3Vlbs40t5RIYxuDqrEHPXOQK6GLwSieCr/w+9+Xlv3lknu/K wWd23E7c+mB17VhRfCy8OnRaTd+MNRl0lAFNpHGsYZQc7c5PH4U+eNrXtZi5JXva90cFd3N9 dab8NJUhS9vP3qRxTthZNsqqqkntgAV6l4d/4SJ9XQar4T0vT7bY3+kW8qM4OOBgevNM8R/D uLWG0Q6dqT6V/Y6Fbbyog+Pu4PJHI21Y0jwpr2n6rBdXfjK9v4IyS9tJAqrJkEcnPvn8KJ1I yjp59+4QhKMtfLscPYaz/wAK9g8baEWKfZv9K04ZA4kwq4PtuTj2NV9e0P8A4R/4deDbR1xc SapDPP6l3BJz7gYH4V3Xir4c2PirxFp+rT3LxG2CpNEqAidFbcFJyMdx36+1aXi3wqniq30+ J7trb7HdrdAiPduKg8dRjrQqsbp/eJ0pWa+45XSreHVfjhr7ajGsz2FrELNJRkICFyyg/U8/ 7VdDeaL4esdQ1i+tBBFrE9i4lijl2kptPJjB74HOO1J4j8DprGrw61pup3GkavGvlm6t1DeY noy5Gf8APXAqPQ/AUWly6lfXmp3GpavfwmCS9nXBVCMYVc8dB37DpUOUWr36bFqLTtbrued/ DtvEg8JRDTPCmmalbea+Li5mRXJzyMHsK6zxVoeo6mfDd1YPpVnr9gjSjSZ3UxuWALbR3wVP P1ORijS/hlrGi2Qs9N8b3ttbhiwjjtVxk9T96tPVPh++rabpfn67dLrWnMzRaqiASNlicMue R0HXt7mtJVI8/Mn+ZEYS5OVr8jD8Paqp+IVtB4l8LR6V4imgYW93by/upVAORgHBOM85PQdO K9RrjdF8CSWfiKPXtZ1y51i/hQx27SxiNYgcg4UE84J/OuyrCq4tqxtTTS1CiiiszQKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigApk3+ok/3T/Kn0yb/USf 7p/lQI8e0T/kA6d/16xf+giuZ8e/6yw+j/8AstdNon/IB07/AK9Yv/QRXM+Pf9ZYfR//AGWv Rp/xDgqfAepeHPGvhyx8O2FpdatBFcQxBJI2ByrDgg8Vqf8ACf8AhX/oNW//AI9/hWn4z8GN dNJq+kRf6X964tl4FwP7y+j/APoXQ84Neco6yKGU8e4wQe4I7H2rOrQUZXZpTrtqyOz/AOE/ 8K/9Bq3/APHv8KP+E/8ACv8A0Grf/wAe/wAK46isvZQNPaSOx/4T/wAK/wDQat//AB7/AAo/ 4T/wr/0Grf8A8e/wrjqKPZQD2kjsf+E/8K/9Bq3/APHv8KP+E/8ACv8A0Grf/wAe/wAK46ij 2UA9pI7H/hP/AAr/ANBq3/8AHv8ACj/hP/Cv/Qat/wDx7/CuOoo9lAPaSOx/4T/wr/0Grf8A 8e/wo/4T/wAK/wDQat//AB7/AArjqKPZQD2kjsf+E/8ACv8A0Grf/wAe/wAKP+E/8K/9Bq3/ APHv8K46ij2UA9pI7H/hP/Cv/Qat/wDx7/Cj/hP/AAr/ANBq3/8AHv8ACuOoo9lAPaSOx/4T /wAK/wDQat//AB7/AAo/4T/wr/0Grf8A8e/wrjqKPZQD2kjsf+E/8K/9Bq3/APHv8KP+E/8A Cv8A0Grf/wAe/wAK46ij2UA9pI7H/hP/AAr/ANBq3/8AHv8ACj/hP/Cv/Qat/wDx7/CuOoo9 lAPaSOx/4T/wr/0Grf8A8e/wo/4T/wAK/wDQat//AB7/AArjqKPZQD2kjsf+E/8ACv8A0Grf /wAe/wAKP+E/8K/9Bq3/APHv8K46ij2UA9pI7H/hP/Cv/Qat/wDx7/Cj/hP/AAr/ANBq3/8A Hv8ACuOoo9lAPaSOx/4T/wAK/wDQat//AB7/AAo/4T/wr/0Grf8A8e/wrjqKPZQD2kjsf+E/ 8K/9Bq3/APHv8KP+E/8ACv8A0Grf/wAe/wAK46ij2UA9pI7H/hP/AAr/ANBq3/8AHv8ACj/h P/Cv/Qat/wDx7/CuOoo9lAPaSOx/4T/wr/0Grf8A8e/wo/4T/wAK/wDQat//AB7/AArjqKPZ QD2kjsf+E/8ACv8A0Grf/wAe/wAKP+E/8K/9Bq3/APHv8K46ij2UA9pI7H/hP/Cv/Qat/wDx 7/Cj/hP/AAr/ANBq3/8AHv8ACuOoo9lAPaSOx/4T/wAK/wDQat//AB7/AAo/4T/wr/0Grf8A 8e/wrjqKPZQD2kjsf+E/8K/9Bq3/APHv8KP+E/8ACv8A0Grf/wAe/wAK46ij2UA9pI7H/hP/ AAr/ANBq3/8AHv8ACj/hP/Cv/Qat/wDx7/CuOoo9lAPaSOx/4T/wr/0Grf8A8e/wo/4T/wAK /wDQat//AB7/AArjqKPZQD2kjsf+E/8ACv8A0Grf/wAe/wAKP+E/8K/9Bq3/APHv8K46ij2U A9pI7H/hP/Cv/Qat/wDx7/Cj/hP/AAr/ANBq3/8AHv8ACuOoo9lAPaSOx/4T/wAK/wDQat// AB7/AAo/4T/wr/0Grf8A8e/wrjqKPZQD2kjsf+E/8K/9Bq3/APHv8KP+E/8ACv8A0Grf/wAe /wAK46ij2UA9pI7H/hP/AAr/ANBq3/8AHv8ACj/hP/Cv/Qat/wDx7/CuOoo9lAPaSOx/4T/w r/0Grf8A8e/wo/4T/wAK/wDQat//AB7/AArjqKPZQD2kjsf+E/8ACv8A0Grf/wAe/wAKP+E/ 8K/9Bq3/APHv8K46ij2UA9pI7H/hP/Cv/Qat/wDx7/Cj/hP/AAr/ANBq3/8AHv8ACuOoo9lA PaSOx/4T/wAK/wDQat//AB7/AAo/4T/wr/0Grf8A8e/wrjqKPZQD2kjsf+E/8K/9Bq3/APHv 8KP+E/8ACv8A0Grf/wAe/wAK46ij2UA9pI7H/hP/AAr/ANBq3/8AHv8ACj/hP/Cv/Qat/wDx 7/CuOoo9lAPaSOx/4T/wr/0Grf8A8e/wo/4T/wAK/wDQat//AB7/AArjqKPZQD2kjsf+E/8A Cv8A0Grf/wAe/wAKP+E/8K/9Bq3/APHv8K46ij2UA9pI7H/hP/Cv/Qat/wDx7/Cj/hP/AAr/ ANBq3/8AHv8ACuOoo9lAPaSOx/4T/wAK/wDQat//AB7/AAo/4T/wr/0Grf8A8e/wrjqKPZQD 2kjsf+E/8K/9Bq3/APHv8KP+E/8ACv8A0Grf/wAe/wAK46ij2UA9pI7H/hP/AAr/ANBq3/8A Hv8ACj/hP/Cv/Qat/wDx7/CuOoo9lAPaSOx/4T/wr/0Grf8A8e/wo/4T/wAK/wDQat//AB7/ AArjqKPZQD2kjsf+E/8ACv8A0Grf/wAe/wAKP+E/8K/9Bq3/APHv8K46ij2UA9pI7H/hP/Cv /Qat/wDx7/Cj/hP/AAr/ANBq3/8AHv8ACuOoo9lAPaSOx/4T/wAK/wDQat//AB7/AApkvj7w s0Lga1bklSB97/CuRoo9nEPaSKGiEHQdOwf+XaMf+OiuZ8e/6yw+j/8AstdPJG9nK1xbqWiY 5mhUc57so9fUd/r15XxxIk39nSRsGRlcqwPBHy100vjuc9T4LH1vXmXxH0K1t7mDUrVpLae6 YicR7dshAGGIIPzdsjr3oorrkk1qcsXZ6HCfZ5f+f2f/AL5T/wCJo+zy/wDP7P8A98p/8TRR WXLHsa8z7h9nl/5/Z/8AvlP/AImj7PL/AM/s/wD3yn/xNFFHLHsHM+4fZ5f+f2f/AL5T/wCJ o+zy/wDP7P8A98p/8TRRRyx7BzPuH2eX/n9n/wC+U/8AiaPs8v8Az+z/APfKf/E0UUcsewcz 7h9nl/5/Z/8AvlP/AImj7PL/AM/s/wD3yn/xNFFHLHsHM+4fZ5f+f2f/AL5T/wCJo+zy/wDP 7P8A98p/8TRRRyx7BzPuH2eX/n9n/wC+U/8AiaPs8v8Az+z/APfKf/E0UUcsewcz7h9nl/5/ Z/8AvlP/AImj7PL/AM/s/wD3yn/xNFFHLHsHM+4fZ5f+f2f/AL5T/wCJo+zy/wDP7P8A98p/ 8TRRRyx7BzPuH2eX/n9n/wC+U/8AiaPs8v8Az+z/APfKf/E0UUcsewcz7h9nl/5/Z/8AvlP/ AImj7PL/AM/s/wD3yn/xNFFHLHsHM+4fZ5f+f2f/AL5T/wCJo+zy/wDP7P8A98p/8TRRRyx7 BzPuH2eX/n9n/wC+U/8AiaPs8v8Az+z/APfKf/E0UUcsewcz7h9nl/5/Z/8AvlP/AImj7PL/ AM/s/wD3yn/xNFFHLHsHM+4fZ5f+f2f/AL5T/wCJo+zy/wDP7P8A98p/8TRRRyx7BzPuH2eX /n9n/wC+U/8AiaPs8v8Az+z/APfKf/E0UUcsewcz7h9nl/5/Z/8AvlP/AImj7PL/AM/s/wD3 yn/xNFFHLHsHM+4fZ5f+f2f/AL5T/wCJo+zy/wDP7P8A98p/8TRRRyx7BzPuH2eX/n9n/wC+ U/8AiaPs8v8Az+z/APfKf/E0UUcsewcz7h9nl/5/Z/8AvlP/AImj7PL/AM/s/wD3yn/xNFFH LHsHM+4fZ5f+f2f/AL5T/wCJo+zy/wDP7P8A98p/8TRRRyx7BzPuH2eX/n9n/wC+U/8AiaPs 8v8Az+z/APfKf/E0UUcsewcz7h9nl/5/Z/8AvlP/AImj7PL/AM/s/wD3yn/xNFFHLHsHM+4f Z5f+f2f/AL5T/wCJo+zy/wDP7P8A98p/8TRRRyx7BzPuH2eX/n9n/wC+U/8AiaPs8v8Az+z/ APfKf/E0UUcsewcz7h9nl/5/Z/8AvlP/AImj7PL/AM/s/wD3yn/xNFFHLHsHM+4fZ5f+f2f/ AL5T/wCJo+zy/wDP7P8A98p/8TRRRyx7BzPuH2eX/n9n/wC+U/8AiaPs8v8Az+z/APfKf/E0 UUcsewcz7h9nl/5/Z/8AvlP/AImj7PL/AM/s/wD3yn/xNFFHLHsHM+4fZ5f+f2f/AL5T/wCJ o+zy/wDP7P8A98p/8TRRRyx7BzPuH2eX/n9n/wC+U/8AiaPs8v8Az+z/APfKf/E0UUcsewcz 7h9nl/5/Z/8AvlP/AImj7PL/AM/s/wD3yn/xNFFHLHsHM+4fZ5f+f2f/AL5T/wCJo+zy/wDP 7P8A98p/8TRRRyx7BzPuH2eX/n9n/wC+U/8AiaPs8v8Az+z/APfKf/E0UUcsewcz7h9nl/5/ Z/8AvlP/AImj7PL/AM/s/wD3yn/xNFFHLHsHM+4fZ5f+f2f/AL5T/wCJo+zy/wDP7P8A98p/ 8TRRRyx7BzPuH2eX/n9n/wC+U/8AiaPs8v8Az+z/APfKf/E0UUcsewcz7h9nl/5/Z/8AvlP/ AImj7PL/AM/s/wD3yn/xNFFHLHsHM+4fZ5f+f2f/AL5T/wCJo+zy/wDP7P8A98p/8TRRRyx7 BzPuH2eX/n9n/wC+U/8AiaPs8v8Az+z/APfKf/E0UUcsewcz7h9nl/5/Z/8AvlP/AImj7PL/ AM/s/wD3yn/xNFFHLHsHM+4fZ5f+f2f/AL5T/wCJo+zy/wDP7P8A98p/8TRRRyx7BzPuH2eX /n9n/wC+U/8AiaPs8v8Az+z/APfKf/E0UUcsewcz7h9nl/5/Z/8AvlP/AImj7PL/AM/s/wD3 yn/xNFFHLHsHM+4fZ5f+f2f/AL5T/wCJqqfBtjrErvdXV58pyFRkUZPU4298CiiqjFJ6ImTb R//Z --------------060008000407010802090504-- From spf2@kitterman.com Wed Sep 12 11:44:53 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3192621F8714 for ; Wed, 12 Sep 2012 11:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91YFD7ynXBFV for ; Wed, 12 Sep 2012 11:44:52 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 78B6021F86B9 for ; Wed, 12 Sep 2012 11:44:52 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 763CD20E4166; Wed, 12 Sep 2012 14:44:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347475492; bh=Gpg9yRj1i/w2GDGhraaIZQUV3JKT83FiKazFi25RsUo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ohZBauENmc2vKbSU7sphKgOmYDMmDU3y5l0NmhJonE/yPAfnXWARLO2plVhG8Ns9Q CxDzN+4fgGwVXoQdSMnXfXfNIbYY8a8dLrXjjv5Oqen+GiTCg21WAd76PquDVgUqyo 9tIbEEazwCeCoc9j+ihQxDjVTWHPIbcxGFV1VvuQ= Received: from scott-latitude-e6320.localnet (11.sub-70-192-195.myvzw.com [70.192.195.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0679B20E4129; Wed, 12 Sep 2012 14:44:44 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 12 Sep 2012 14:44:41 -0400 Message-ID: <1868695.UVVp0ZHKnm@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20120911214905.09388488@elandnews.com> References: <064.8a6275919aba4fa5f4f9c983ff6041f6@tools.ietf.org> <6.2.5.6.2.20120911214905.09388488@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #60: Section 2.3 - Publishing Authorization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 18:44:53 -0000 On Tuesday, September 11, 2012 09:53:06 PM S Moonesamy wrote: > >#60: Section 2.3 - Publishing Authorization I don't see #60 listed: http://trac.tools.ietf.org/wg/spfbis/trac/report/1 It clearly existed at one point, because I got email about the issue being created, but it seems to have vanished. Scott K From hsantos@isdg.net Wed Sep 12 11:47:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F18121F845E for ; Wed, 12 Sep 2012 11:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.105 X-Spam-Level: X-Spam-Status: No, score=-102.105 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPWIbWbwhDys for ; Wed, 12 Sep 2012 11:47:47 -0700 (PDT) Received: from winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 580AB21F8629 for ; Wed, 12 Sep 2012 11:47:47 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1898; t=1347475656; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Qljmc/lOvVcVQeR+d9nVmCMk1pc=; b=kgfs1BDkG9liUIvGdkyz N0G4BAah3Y4Q9R7HA8qExhGoUB6EwTl1QWzoeMDWjIrUoYD/b9xmeqJM+rcxWARH nQNyEK4vwBXGYDTC+9br3gIKYgvE95ZsAg+0UA+Re4dOpcRiEe1PqTGvIEJti+ka NuuJVa8QduvIfcXyWb1xUAM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 14:47:36 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3497433162.6316.2448; Wed, 12 Sep 2012 14:47:35 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1898; t=1347475427; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ZihIEqy Ihiqzf+HVu9kBXVd2AoCng1Am9EsZfX0LXIk=; b=1eIvB1PEMLVyG84odYFCD7g Ore/ou++s4ZZMAcxu9IixiN43O3TUIf10IEf9CwYqIQSqGVWrLSm67705Y8GN/oJ NI36Y74YH8wtsgI4KDUbfXbEOjX3NwABRQDgHEBr0/XVmgmItZ2MQP3cQkvIyDUf FhGbuhOrYwZirYMrRQCw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 14:43:47 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4096225895.9.2904; Wed, 12 Sep 2012 14:43:47 -0400 Message-ID: <5050D8F2.9080907@isdg.net> Date: Wed, 12 Sep 2012 14:48:18 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <1347457847.27386.YahooMailClassic@web125103.mail.ne1.yahoo.com> <5050A8B3.5070301@isdg.net> <6815534.9ZX5Nr1ah6@scott-latitude-e6320> In-Reply-To: <6815534.9ZX5Nr1ah6@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 18:47:48 -0000 I see your response as being very unreasonable and a non-response but to create some negative view of something I didn't state. Are we being a bit technical about what was the outcome of the MARID work? Where these not the four documents that were produced from all the work in MARID? In fact, it is stated here in RFC4408: IESG Note The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) are published simultaneously as Experimental RFCs, although there is no general technical consensus and efforts to reconcile the two approaches have failed. As such these documents have not received full IETF review and are published "AS-IS" to document the different approaches as they were considered in the MARID working group. In in draft rev-07: 1.2. Experimental History This document updates and replaces RFC 4408 that was part of a group of simultaneously published Experimental RFCs (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) in 2006. At that time the IESG requested the community observe the success or failure of the two approaches documented in these RFCs during the two years following publication, in order that a community consensus could be reached in the future. My only point is that the production of RFC4408 did not work in ISOLATION. If it was the only isolated work, then it might have had a "Proposed Standard" Scott Kitterman wrote: > On Wednesday, September 12, 2012 11:22:27 AM Hector Santos wrote: > .... >> As a result, we had FOUR PRODUCTIONS FROM MARID: >> >> RFC4405 >> RFC4406 >> RFC4407 >> RFC4408 > ... > > This is factually incorrect. MARID was closed with no documents produced (and > let's not redebate it anyway). > > Scott K > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From srs0=1didp=hl=gathman.org=stuart@fairfax.gathman.org Wed Sep 12 11:49:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7302B21F8629 for ; Wed, 12 Sep 2012 11:49: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c03EGu+a4Mdo for ; Wed, 12 Sep 2012 11:49:38 -0700 (PDT) Received: from mail.bmsi.com (www.bmsi.com [IPv6:2001:4830:1659:911::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9282721F845E for ; Wed, 12 Sep 2012 11:49:38 -0700 (PDT) Authentication-Results: mail.bmsi.com; iprev=pass policy.iprev=192.168.10.1 (gathman); auth=pass (PLAIN sslbits=256) smtp.auth=stuart Received: from fairfax.gathman.org (gathman [192.168.10.1]) (authenticated bits=0) by mail.bmsi.com (8.14.3/8.14.3) with ESMTP id q8CInaMt006668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Sep 2012 14:49:36 -0400 Received: from silver.gathman.org ([192.168.10.211]) (authenticated bits=0) by fairfax.gathman.org (8.14.3/8.14.3) with ESMTP id q8CInNPS011899 for ; Wed, 12 Sep 2012 14:49:36 -0400 Message-ID: <5050D932.3020909@gathman.org> Date: Wed, 12 Sep 2012 14:49:22 -0400 From: Stuart Gathman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: spfbis@ietf.org References: <1347451838.27732.YahooMailClassic@web125106.mail.ne1.yahoo.com> In-Reply-To: <1347451838.27732.YahooMailClassic@web125106.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] FW: Secetion 4.6.4 DNS Lookup Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 18:50:38 -0000 On 09/12/2012 08:10 AM, Arthur Thisell wrote: >> To be precise, returning "permerror" based solely on the fact that the >> SPF policy might (or even will) exceed the DNS lookup counts is >> probably not valid. I might have 30 mechanisms listed, but if on >> evaluation it never gets past the fifth one, what's the harm? > The harm in having too many mechanisms, even if they never get evaluated, is basically the same as having syntax errors, even if they never get evaluated. > > Many script-type languages (unix shell scripts, JCL, etc.) don't detect syntax errors until they encounter them. Most other computer languages will complain. > > In the case of hilton.com, I could see the gut feel being that the extra mechanisms should be ignored, but in other cases, I could see the gut feel being that you should give consistent results, rather than authorized results sometimes getting permerror a small percentage of the time. > > In particular, is really common to hit the "end" of an SPF record. Having all unauthorized mail evaluated to permerror is not what people will expect. > The problem is that SPF policies form a tree, with include and redirect. Determining ahead of time whether the Dos limit might possibly be exceeded (for some connect IPs) requires fetching all the referenced SPF records - whether they are needed for this particular IP or not. This makes any Dos considerations worse. A similar problem comes up with include and redirect. The current SPF record might be syntactically valid, but some included record might not be. It would be counterproductive for an implementation to actually fetch the entire tree of SPF records in order to check them all for syntax errors. If you want consistent results, simply require that DoS limits be reported at the first mechanism that exceeds the limit. This will always give the same result for the same connect IP. As for syntax errors, only the SPF record currently being evaluated should be fully parsed for syntax errors. It is counter productive to prefetch the entire tree. While this is obvious from a common sense standpoint, if there is any confusion, 4408bis should make this explicit. From spf2@kitterman.com Wed Sep 12 11:57:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5403C21F86F3 for ; Wed, 12 Sep 2012 11:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lX+E54-a0LRv for ; Wed, 12 Sep 2012 11:57:57 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8A87321F869A for ; Wed, 12 Sep 2012 11:57:57 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0CC2320E4166; Wed, 12 Sep 2012 14:57:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347476277; bh=K2i1+zAbSrEFhqBGadjKHhD86eNuHWbQ6PgFma5+KQo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=g8Dn5zj+EhihEgxfuBR+sLDRQ0BIcvaN7pP6uVOpVHhQSaAvdOOOPQoZ45+x+CZMQ u+CGcJCyEidv7hDmztlzlSD4muSdEdeQaH4/2gf2yLeL1p44S+7UEr74xgyaLi0xgy 8FYgHPT8mzR3DJcK1feYcc1gVgGc72X9SM57Lwq0= Received: from scott-latitude-e6320.localnet (11.sub-70-192-195.myvzw.com [70.192.195.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 912C720E4129; Wed, 12 Sep 2012 14:57:56 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 12 Sep 2012 14:57:53 -0400 Message-ID: <1455898.oH7rCXgRVK@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <5050D8F2.9080907@isdg.net> References: <1347457847.27386.YahooMailClassic@web125103.mail.ne1.yahoo.com> <6815534.9ZX5Nr1ah6@scott-latitude-e6320> <5050D8F2.9080907@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 18:57:58 -0000 On Wednesday, September 12, 2012 02:48:18 PM Hector Santos wrote: Top posting fixed. > Scott Kitterman wrote: > > On Wednesday, September 12, 2012 11:22:27 AM Hector Santos wrote: > > .... > > > >> As a result, we had FOUR PRODUCTIONS FROM MARID: > >> RFC4405 > >> RFC4406 > >> RFC4407 > >> RFC4408 > > > > ... > > > > This is factually incorrect. MARID was closed with no documents produced > > (and let's not redebate it anyway). > I see your response as being very unreasonable and a non-response but > to create some negative view of something I didn't state. Are we > being a bit technical about what was the outcome of the MARID work? > Where these not the four documents that were produced from all the > work in MARID? > > In fact, it is stated here in RFC4408: > > IESG Note > > The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) > are published simultaneously as Experimental RFCs, although there is > no general technical consensus and efforts to reconcile the two > approaches have failed. As such these documents have not received > full IETF review and are published "AS-IS" to document the different > approaches as they were considered in the MARID working group. > > In in draft rev-07: > > 1.2. Experimental History > > This document updates and replaces RFC 4408 that was part of a group > of simultaneously published Experimental RFCs (RFC 4405, RFC 4406, > RFC 4407, and RFC 4408) in 2006. At that time the IESG requested the > community observe the success or failure of the two approaches > documented in these RFCs during the two years following publication, > in order that a community consensus could be reached in the future. > > My only point is that the production of RFC4408 did not work in > ISOLATION. If it was the only isolated work, then it might have had a > "Proposed Standard" No one in the SPF community wanted it to be linked to Microsoft's Sender ID efforts or to be experimental. Those were political choices of the day. Note that the element of the document you quoted says "considered in the MARID working group", not products of the MARID working group. This is because the MARID working group produced nothing. If you believe this is not true, go read the two appeals filed against Sender ID and then think again. The Sender ID RFCs are dependent on RFC 4408, but the reverse is not true. >From an SPF/RFC 4408 perspective Sender ID doesn't exist (RFC 4408 contains no references to any SenderID document outside the IESG note, which is paraphrased in 4408bis in the history section). You are entitled to your own opinions, but not your own facts. Scott K From barryleiba.mailing.lists@gmail.com Wed Sep 12 12:01:06 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0140E21F8733 for ; Wed, 12 Sep 2012 12:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.954 X-Spam-Level: X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnZyhosCz-mv for ; Wed, 12 Sep 2012 12:01:05 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 673E721F86F3 for ; Wed, 12 Sep 2012 12:00:57 -0700 (PDT) Received: by lahm15 with SMTP id m15so1453907lah.31 for ; Wed, 12 Sep 2012 12:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mf+JnO14RrCdg+5D9XBtcNM1jM2wBjzaaPn6HS/gQNU=; b=gFoE0cb5aMSWQvIshEc5JyQQXASxEqkB40wmciHCaeTQU3bMvewH8gG8om9AEvBXjY 3BpgueZugPweZvKw/nTIHqQ++AO1IhSPSRRuwyc2ApHvzLfVwJlrEJ7eoygE6Na05cG7 rjmj9Vxg5rIZFVO+i+vbmEVdaSwMyKWwlbyVryDGspfY3M/RLUjgwFSf7CyO6+T1OD5+ j7HwEy0NW7bf2rqpHVIa0Z0aICh6AGMc/LbOjqmFz0VSQrMtg3y54n2YU09sk8I5Warm PjT0Yrv4IONsH+9Rbmt7FouDetUErFWAhSe7/sCw8bBmh/7I297aJJkVG3ViE7KGeD6h fsHw== MIME-Version: 1.0 Received: by 10.152.108.206 with SMTP id hm14mr19828958lab.53.1347476456318; Wed, 12 Sep 2012 12:00:56 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Wed, 12 Sep 2012 12:00:56 -0700 (PDT) In-Reply-To: References: <20120912011024.20846.qmail@joyce.lan> <1469933.kpSdRM44Gj@scott-latitude-e6320> Date: Wed, 12 Sep 2012 15:00:56 -0400 X-Google-Sender-Auth: aaSYj6pvThk0XgMbAiw49UVR-Gw Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 19:01:06 -0000 > The debate, then, is about whether RFC2119 language can be used to > describe an operational practice (in this case, local policy) that > isn't part of the protocol proper. I believe the answer is "no". > Perhaps one of the co-chairs or an AD should weigh in on that point. The chairs have both said good things along this line; note Andrew's comment especially. As an AD, I'll add my agreement, but I'll also add some other comments. This is an important point, so note it well: Not all normative text has 2119 keywords in it. Let me say that again, in a different way: Just because you decide not to put MUST or SHOULD (with or without NOT) in doesn't mean that it's just fluff text that can be ignored on whim. AS A PARTICIPANT, I agree with Scott: if we have, by experience, determined that it's a really bad idea to do X (where X might be to silently delete mail purely on the basis of an SPF fail, or any other such thing), then it's a really good idea to say so, and to strongly advise against it. As both a participant and an AD, I think such advice should not be using 2119 language. And I think that doesn't, in itself, make it casual, non-normative advice. If you want to give strong advice in the form of an applicability statement, do so. You can even label the paragraph "Applicability Statement:", or put it in a section so titled. Barry From hsantos@isdg.net Wed Sep 12 12:06:11 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C891421F852D for ; Wed, 12 Sep 2012 12:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.824 X-Spam-Level: X-Spam-Status: No, score=-101.824 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oF9ZMjQCdvP3 for ; Wed, 12 Sep 2012 12:06:11 -0700 (PDT) Received: from winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E053721F870F for ; Wed, 12 Sep 2012 12:06:10 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3077; t=1347476766; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=a2H2fRBkrLVm7Yg8IkE96GM4+U4=; b=fn1zEHGo8ZcfsKX2pjo1 5B8pmXDIQP8W12AtTDynuxA4z+VWfjNXCKE18TzM96DnBbSkZQQQ8cM1RZ64Uf4z nY99hQLW5Urasob46KDuhL2BkDksbpukQupPZf7UO733CmDfcQDyRszUjKQEy8YC gNCdRuRHT9kLokgOOmgogaA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 15:06: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 opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3498543327.6316.4476; Wed, 12 Sep 2012 15:06:05 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3077; t=1347476539; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Q63Y8u2 cohdeztVmujuhDV3hdPMr9ZAb0uvu9+fCwwE=; b=2vBGScVYdseVWeZDW6DEB7I wWSZ7f1f1X6cEf4+VxmmFLFvK3LvZilx4zUYEisniEH1RXjgDv2Cy8PhD2Hpja7x uQHcZK2KqFl6nQTiWP+QWyhjtMunt16ztZx1sMrQeh+5oPLmDDM9DAj1H+O67GIg bgxbwMvhn95IuieSP9vI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 15:02:19 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4097337380.9.1236; Wed, 12 Sep 2012 15:02:18 -0400 Message-ID: <5050DD4A.4090906@isdg.net> Date: Wed, 12 Sep 2012 15:06:50 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Stuart Gathman References: <1347451838.27732.YahooMailClassic@web125106.mail.ne1.yahoo.com> <5050D932.3020909@gathman.org> In-Reply-To: <5050D932.3020909@gathman.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] FW: Secetion 4.6.4 DNS Lookup Limits X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 19:06:11 -0000 Stuart, One way to address this or add some automated "learning" is to perhaps use these limits or permerrors as Temporary "Greylisting-like" Rejects but over a 1-2 day period with the HOPE the remote operator (if its a real good person) will notice and take a look at its logs and see: 451-Your SPF is failed with a DNS Lookup limit exceeding 10. 451-Please adjust your SPF record so that less lookups are required. 451 This transaction will be expired in 2 days. I can see a DNS occurring, but it will need a serious tracking to limit the ACCEPT+FORCE BOUNCE per domain occurrence. Stuart Gathman wrote: > On 09/12/2012 08:10 AM, Arthur Thisell wrote: >>> To be precise, returning "permerror" based solely on the fact that the >>> SPF policy might (or even will) exceed the DNS lookup counts is >>> probably not valid. I might have 30 mechanisms listed, but if on >>> evaluation it never gets past the fifth one, what's the harm? >> The harm in having too many mechanisms, even if they never get >> evaluated, is basically the same as having syntax errors, even if they >> never get evaluated. >> >> Many script-type languages (unix shell scripts, JCL, etc.) don't >> detect syntax errors until they encounter them. Most other computer >> languages will complain. >> >> In the case of hilton.com, I could see the gut feel being that the >> extra mechanisms should be ignored, but in other cases, I could see >> the gut feel being that you should give consistent results, rather >> than authorized results sometimes getting permerror a small percentage >> of the time. >> >> In particular, is really common to hit the "end" of an SPF record. >> Having all unauthorized mail evaluated to permerror is not what people >> will expect. >> > The problem is that SPF policies form a tree, with include and > redirect. Determining ahead of time whether the Dos limit might > possibly be exceeded (for some connect IPs) requires fetching all the > referenced SPF records - whether they are needed for this particular IP > or not. This makes any Dos considerations worse. > > A similar problem comes up with include and redirect. The current SPF > record might be syntactically valid, but some included record might not > be. It would be counterproductive for an implementation to actually > fetch the entire tree of SPF records in order to check them all for > syntax errors. > > If you want consistent results, simply require that DoS limits be > reported at the first mechanism that exceeds the limit. This will > always give the same result for the same connect IP. > > As for syntax errors, only the SPF record currently being evaluated > should be fully parsed for syntax errors. It is counter productive to > prefetch the entire tree. While this is obvious from a common sense > standpoint, if there is any confusion, 4408bis should make this explicit. > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From superuser@gmail.com Wed Sep 12 12:24:30 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B797B21F863F for ; Wed, 12 Sep 2012 12:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnijNifwiS1m for ; Wed, 12 Sep 2012 12:24:30 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id F21FE21F853B for ; Wed, 12 Sep 2012 12:24:29 -0700 (PDT) Received: by lahm15 with SMTP id m15so1471143lah.31 for ; Wed, 12 Sep 2012 12:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5d7MExnVsX4mSdTI5zVjXA2bhSK2fJrU21I0GRP0/cU=; b=PRRLNmvgs39y03ryKdTgG2ZeUOp4dkVLwQz5H9yq87udEq2UHgElD5en6Uoa+lauLM ObVNQloJ+j/+TJmENmOzKItv45qVonLcxq4ay1F9637VaKHdvdZH5OMjWzVvYQdtZ4ZV J3enjz+zt+8XyD1RbkViXtMtemt4iKGT18nyQLcg8alrTD0PM8grSX/Sf/A4C7vTHn8w m/ffywGTOXmpEuMIzNMO5KutbtjkrxZlGj/QJurCKDIyEjHs7MEi4P9rNnbSmacRCpLA pW0r3UGcaAge3fWtZcgVcec346XVkZtEKfmdtAbsW5RoX2Mx5AMAcrKOdHQqfwKdNuQX OJWw== MIME-Version: 1.0 Received: by 10.112.9.133 with SMTP id z5mr43390lba.69.1347477868584; Wed, 12 Sep 2012 12:24:28 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Wed, 12 Sep 2012 12:24:28 -0700 (PDT) In-Reply-To: References: <20120912011024.20846.qmail@joyce.lan> <1469933.kpSdRM44Gj@scott-latitude-e6320> Date: Wed, 12 Sep 2012 12:24:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 19:24:30 -0000 On Wed, Sep 12, 2012 at 12:00 PM, Barry Leiba wrote: > This is an important point, so note it well: > Not all normative text has 2119 keywords in it. > > Let me say that again, in a different way: > Just because you decide not to put MUST or SHOULD (with or without > NOT) in doesn't mean that it's just fluff text that can be ignored on > whim. For further clarification: Is the distinction about when 2119 language is appropriate based on the main subject of the document? That is, since this document is supposed to define the SPF protocol, then 2119 language is only appropriate where something is defining an interoperability aspect of SPF itself, and not for adjacent stuff like applicability statements. Correct? > As both a participant and an AD, I think such advice should not be > using 2119 language. And I think that doesn't, in itself, make it > casual, non-normative advice. If you want to give strong advice in > the form of an applicability statement, do so. You can even label the > paragraph "Applicability Statement:", or put it in a section so > titled. I think that's fine for this document if the size of such a section is kept reasonable. Otherwise, making a separate AS document seems to me to be a much more palatable approach, and as a result that specific set of material and the core documentation each have more breathing room. -MSK From hsantos@isdg.net Wed Sep 12 12:26:51 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CAA21F86AA for ; Wed, 12 Sep 2012 12:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.131 X-Spam-Level: X-Spam-Status: No, score=-102.131 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZgZFKkthRZu for ; Wed, 12 Sep 2012 12:26:50 -0700 (PDT) Received: from winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A8F6E21F864A for ; Wed, 12 Sep 2012 12:26:50 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2622; t=1347478006; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=c6y28x2uaBmU8pi6IsL+PWDB/iA=; b=srn4969/n3h390bxK4tj +z4leb55R0i/SbOohXkRUHGpq/Ubwmd3uKX0VbzCMsi42iwrBGavhQKI8v+3FGP4 1KWJIXzk6DxFAk57ADBLqVLFnsB9lveR0YwAqbiXC7OU3suPLOVaCkmIR25Ici80 gDJ0oeIYGOll9QRKUAYbneU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 15:26:46 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3499783566.6316.3604; Wed, 12 Sep 2012 15:26:46 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2622; t=1347477780; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=olSxJH/ QbUaJBbJX4XblXajE8BCBXqvjQwlcArfkg5I=; b=thelH4bSKHfCAPsowVVRsFj W7tDHPlSheXmHZGoyWuoIyajr9ijFwV2x50PMfCjl4tEfsl1AJdZ/HB9lZlQj2gK 3nG/7DV/H5iBh01hCYMABqq2B1QW3Cw2QVVxbFMk571blzpZbtu+EBRmq4MlTy4W YZnUzzP7ypOe7YqE7Oqg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 15:22:59 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4098577786.9.3828; Wed, 12 Sep 2012 15:22:59 -0400 Message-ID: <5050E223.8060100@isdg.net> Date: Wed, 12 Sep 2012 15:27:31 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <1347457847.27386.YahooMailClassic@web125103.mail.ne1.yahoo.com> <6815534.9ZX5Nr1ah6@scott-latitude-e6320> <5050D8F2.9080907@isdg.net> <1455898.oH7rCXgRVK@scott-latitude-e6320> In-Reply-To: <1455898.oH7rCXgRVK@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 19:26:51 -0000 Scott Kitterman wrote: > No one in the SPF community wanted it to be linked to Microsoft's Sender ID > efforts or to be experimental. Those were political choices of the day. Note > that the element of the document you quoted says "considered in the MARID > working group", not products of the MARID working group. This is because the > MARID working group produced nothing. If you believe this is not true, go > read the two appeals filed against Sender ID and then think again. > > The Sender ID RFCs are dependent on RFC 4408, but the reverse is not true. >>From an SPF/RFC 4408 perspective Sender ID doesn't exist (RFC 4408 contains no > references to any SenderID document outside the IESG note, which is > paraphrased in 4408bis in the history section). > > You are entitled to your own opinions, but not your own facts. You keep saying this like its in style. Its pretty rude and unnecessary. You behave like I wasn't involved during the entire period. Thats neither here or there though. So lets try it again this way. If 4408 was isolated work, and yes I agree there was much animosity toward Microsoft and its key participation which I doubt MARID would had EXIST or SPF get any IETF review or an RFC if it wasn't for Microsoft, I didn't care or participated in any of that drama, then why did have the IESG NOTE in RFC 4408 and continue with the references in SPFBIS draft section 1.2? 1.2. Experimental History This document updates and replaces RFC 4408 that was part of a group of simultaneously published Experimental RFCs (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) in 2006. At that time the IESG requested the community observe the success or failure of the two approaches documented in these RFCs during the two years following publication, in order that a community consensus could be reached in the future. I agree, SPFv1 does not depends SPV2 or any part of it, as it is WRITTEN, but that is that the REALITY in practice in TOTAL. There are SPFV1 SUBMITTER supporters. The fact is, Scott, the majority of the work did include consideration for ALL the documents as a result or even conclusion, if we must, of the MARID working group. These are not myths and again my only point a group here is re-debating the theory of SPF like its all new. It isn't. In my view, the proper engineering is to see the entire scope as all products were framed to be. What is the point and goal of this issue anyway? What are we looking for? It seems people can answer pretty easily when all they need to look is at history - Occam's Razor. -- HLS From johnl@iecc.com Wed Sep 12 12:28:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6447121F8674 for ; Wed, 12 Sep 2012 12:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1LSg6+5rc-d for ; Wed, 12 Sep 2012 12:27:59 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id F2AAB21F8620 for ; Wed, 12 Sep 2012 12:27:58 -0700 (PDT) Received: (qmail 83153 invoked from network); 12 Sep 2012 19:27:57 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Sep 2012 19:27:57 -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:vbr-info; s=5050e23d.xn--30v786c.k1208; i=johnl@user.iecc.com; bh=C2TGh9cTlC5A+Zjgaf1P6JzhLF8Zn/vQg/xS8jifx6c=; b=uxjTPN3CgL32kSzFv66xf8BzAbFpRUj1UVI9c+xGtQsDmWpT3k9Eq10HzsN9HveXwM9OQaDJVOYa6RNsbsff2KwR5rEDOQlylz3wasFphfS1BCrChVdCW9JgtZjWYsSqmANF+0UvY1FxP8gnIdw1srZy7QQX4cHbSBz2wql0AMg= 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:vbr-info; s=5050e23d.xn--30v786c.k1208; olt=johnl@user.iecc.com; bh=C2TGh9cTlC5A+Zjgaf1P6JzhLF8Zn/vQg/xS8jifx6c=; b=NHTlOuANPQU+thFqTc9e2F+EESnW3Fx8tG508GXgkTWWesDOmSP2+zK+n5P03T52batjdCf3SCR3DbhNllV0+MBJYg74IT0pIJPmxHgHawFwFD1+vztRxAt+Va4nh0FbTfGErMe6APOwh6MbHZPkOHpWWyDvbNt0WZXYi+s8PVY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 12 Sep 2012 19:27:35 -0000 Message-ID: <20120912192735.82601.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1724450.r6cHBnbWLS@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: spf2@kitterman.com Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 19:28:00 -0000 >I guess I'll wait to see if there's anyone more greybeard around. My beard's pretty grey and I'm in full agreement with Murray here. Perhaps Dave or Barry or Pete Resnick (whose ponytail is an honorary beard) will chime in. R's, John From hsantos@isdg.net Wed Sep 12 12:55:15 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264B521F8624 for ; Wed, 12 Sep 2012 12:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.416 X-Spam-Level: X-Spam-Status: No, score=-101.416 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXtPovqwsDGc for ; Wed, 12 Sep 2012 12:55:14 -0700 (PDT) Received: from pop3.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 310EF21F85EF for ; Wed, 12 Sep 2012 12:55:13 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3954; t=1347479711; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=yOZ9+JiSGZywDuxqnfB/JV4R3bk=; b=lcJMNRZE9oqfEnqvPqHp WjSuu+PiDp9eMqZ25EP6qM1pmRRstvOd/IVly8MDHb+vHB+IUPmcMWoYSq7T3ppK ZZWpbdyBxdeKEE96e0XdhWTKKXb5Fyb0vfKHMadqmxdcHP43qzMv9J0P0IHPTyyJ KxfQbMvTHgC/7JXespPpR+o= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 15:55:11 -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 3501488704.6316.4144; Wed, 12 Sep 2012 15:55:11 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3954; t=1347479484; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=gWzGJG1 JbI4S2lg6shvtheEQePXR+vxamC2oDSKqgGI=; b=XxhOIhgONOaQImNJp35eZv2 tLSfuG3qzf4FYtKSb0ruShO4TwIi9afP0pAwuMVNoJNBXdgLqcwndS1qNGJhE4uO JNadlGjBjDeT0CDgLh7tl/54fARnEJeY0HdJeTTMns9SLCb6IHJzaqHqGZPULOO7 aL/kXQLsXzpX4mb59zPc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 15:51:24 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4100283083.9.6448; Wed, 12 Sep 2012 15:51:24 -0400 Message-ID: <5050E8CC.5040008@isdg.net> Date: Wed, 12 Sep 2012 15:55:56 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <20120912011024.20846.qmail@joyce.lan> <1469933.kpSdRM44Gj@scott-latitude-e6320> <1724450.r6cHBnbWLS@scott-latitude-e6320> In-Reply-To: <1724450.r6cHBnbWLS@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 19:55:15 -0000 I'm grey. For the record, Murray made an erroneous statement about I didn't say and just basically paraphrase what I did say. SPF is a MTA to MDA protocol. This is backed up by 4408 and also 5598 but then again, it depends how its read. Overall, the BACKEND must deal with the ACCEPT+MARK issue in order to be security on-par with its alternative mode - rejection. I said that in April 2012, after losing a tooth, it was made part of issue #29 with the wrong mail reference, ignored and supposedly closed, but resurfaced as Issue #33 this time from a security angle and that was still a problem because it "tells receivers" what to do, and it was also out of scope. No one likes Security Issues for RFC proposed standards works I guess. Now we debating what is the meaning of Local Policy, and RFC Technical Writing Styles arguing whether what is written wasn't really was intended! Good Luck with all this. Scott Kitterman wrote: > On Tuesday, September 11, 2012 10:54:46 PM Murray S. Kucherawy wrote: >> On Tue, Sep 11, 2012 at 7:40 PM, Scott Kitterman wrote: >>> I'm fine with not saying MUST NOT for that reason. OTOH, SHOULD NOT >>> stamps it a generally a bad idea (which I think is reasonable), but says >>> go ahead if you think you know better. I believe that's consistent with >>> what you say you want. >> The debate, then, is about whether RFC2119 language can be used to >> describe an operational practice (in this case, local policy) that >> isn't part of the protocol proper. I believe the answer is "no". >> Perhaps one of the co-chairs or an AD should weigh in on that point. >> >> To be specific: The protocol itself works if the receiver generates >> the result that the sender's published policy intended to provide. >> The normative terms are available to be used such that implementers >> will write something that works properly. That's interoperability. >> What the receiver does with the message afterwards doesn't change the >> fact that check_host() did precisely what it was supposed to do. The >> protocol, at that point, is done. No MUSTard we put on what happens >> after that has anything at all to do with interoperability of the >> protocol itself, and thus I'd say is inappropriate for a protocol >> document (but not necessarily for an applicability statement, which >> this is not). >> >> Now, that's all true if we agree that SPF is a protocol between the >> sending ADMD and the receiving MTA. Since there are people who want >> this MUSTard there, they must have something else in mind. >> >> Hector, I believe, claimed that SPF is more of a protocol between the >> sending ADMD and the MUA. I don't think that's right because the >> output of check_host() is not used anywhere as a signal to the MUA, >> since MUAs can't reject messages; the best they could do is apply an >> annotation (another kind of "mark") or simply decline to show the >> message. But we -- correctly, I believe -- shy away from making >> assertions about what MUAs should do. So what's left? At best, one >> could claim it's a protocol between the sending ADMD and the LDA. I >> don't think LDAs typically do rejection or "marking", though, and even >> if they did, the rejection would need to be in lockstep with SMTP, >> otherwise there's backscatter. So I don't really know what to do with >> this line of thinking. > >>From my POV, this is similar to the issue #33 thread, only more so. One of > primary drivers for development of SPF was to reduce "Joe job" bounces. In > this case, the MUSTard in play goes to achieving one of the main goals of the > protocol. It's not ancillary at all. > > I guess I'll wait to see if there's anyone more greybeard around. > > Scott K > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From barryleiba.mailing.lists@gmail.com Wed Sep 12 12:55:32 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC6621F86AF for ; Wed, 12 Sep 2012 12:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.954 X-Spam-Level: X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qI-B9pIwLKr for ; Wed, 12 Sep 2012 12:55:31 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 23D6F21F85EF for ; Wed, 12 Sep 2012 12:55:30 -0700 (PDT) Received: by lbky2 with SMTP id y2so1549480lbk.31 for ; Wed, 12 Sep 2012 12:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6y+E3tG1MOzO0y4o/ZmiDdawFr+LtV3PeFZ4FB6sf/k=; b=asf/tSlwksNHpahcKpLs1jQ70n6CTRi/MTrBfjcf+WTltLogwb+KZvdYfXZAHzRYIE m9PGE9ZBD5FAvYT80DjZFNFOHgJKA29XlchFKpQkN2UsjH8unes3L2Tj8E3Tm2e3P2pZ pkH3PA8nczDyGU+G2SGHjzsLcEIGrcgHj8zBXKcJL0eNT/i32yg5R2VDw0WY49vXXIM/ 3j1iHYB6q3Om4rMpk3CR8a3wHmmLph7307xagj9ubOW702iUNyw8xjjb81VC/K1PDrZ2 pPEW/LjrUUWCdMYzvLLjyxRf1dSpjlFB25PWgYJnBkqnXJirxIEt0PZ0PqpPP1B1zpi3 ui5Q== MIME-Version: 1.0 Received: by 10.112.51.228 with SMTP id n4mr74382lbo.55.1347479730095; Wed, 12 Sep 2012 12:55:30 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Wed, 12 Sep 2012 12:55:29 -0700 (PDT) In-Reply-To: References: <20120912011024.20846.qmail@joyce.lan> <1469933.kpSdRM44Gj@scott-latitude-e6320> Date: Wed, 12 Sep 2012 15:55:29 -0400 X-Google-Sender-Auth: z_KDH1tII9DBF9sGIsmxZ9aaUwk Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=f46d0401fd9da7876f04c986927a Cc: "spfbis@ietf.org" Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 19:55:32 -0000 --f46d0401fd9da7876f04c986927a Content-Type: text/plain; charset=ISO-8859-1 > For further clarification: Is the distinction about when 2119 language > is appropriate based on the main subject of the document? That is, > since this document is supposed to define the SPF protocol, then 2119 > language is only appropriate where something is defining an > interoperability aspect of SPF itself, and not for adjacent stuff like > applicability statements. Correct? Well, I don't think that's quite it. If there are choices to be made that affect interoperability of the protocol, use the 2119 language to specify the choices, whether that's in the TS or an AS. So, if the protocol requires it, you might say that some entity MUST retrieve the domain's MX record from DNS, snf SHOULD fall back to the A record if no MX exists. This would all specify how to operate the protocol. But when you're not talking about an interop-related choice, it's probably not 2119 territory (though I'm oversimplifying here). Language that talks about what to do with the results of the protocol... is, I think, not the place for 2119 key words. > I think that's fine for this document if the size of such a section is > kept reasonable. Otherwise, making a separate AS document seems > to me to be a much more palatable approach, and as a result that > specific set of material and the core documentation each have more > breathing room. That's for the WG to decide. There's value in keeping a TS clean, and there's value in including AS information in the TS document. Judgment. Barry --f46d0401fd9da7876f04c986927a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> For further clarification:= Is the distinction about when 2119 language
> is appropriate = based on the main subject of the document? =A0That is,
> since= this document is supposed to define the SPF protocol, then 2119
> language is only appropriate where something is defining an
=
> interoperability aspect of SPF itself, and not for adjacent stuff= like
> applicability statements. =A0Correct?

Well, I don't think that's quite it. =A0If there are cho= ices to be made that affect interoperability of the protocol, use the 2119 = language to specify the choices, whether that's in the TS or an AS. =A0= So, if the protocol requires it, you might say that some entity MUST retrie= ve the domain's MX record from DNS, snf SHOULD fall back to the A recor= d if no MX exists. =A0This would all specify how to operate the protocol.

But when you're not talking about an interop-relate= d choice, it's probably not 2119 territory (though I'm oversimplify= ing here). =A0Language that talks about what to do with the results of the = protocol... is, I think, not the place for 2119 key words.

> I think that's fine for this document if the s= ize of such a section is
> kept reasonable. =A0Otherwise, maki= ng a separate AS document seems
> to me=A0to be a much more palatable approach, and as a result th= at
> specific=A0set of material and the core documentation e= ach have more
> = breathing=A0room.

That's for the WG to decide. =A0There's value i= n keeping a TS clean, and there's value in including AS information in = the TS document. =A0Judgment.

Barry --f46d0401fd9da7876f04c986927a-- From spf2@kitterman.com Wed Sep 12 13:39:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3743821F864A for ; Wed, 12 Sep 2012 13:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esWV71Dh66Q0 for ; Wed, 12 Sep 2012 13:38:59 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8198A21F863F for ; Wed, 12 Sep 2012 13:38:59 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D8DCF20E4166; Wed, 12 Sep 2012 16:38:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347482336; bh=CGUmIVO0Hx1LSwdix5gUHUxMaBMViEu7ag0/WgtBKzo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fk10AyNMDip0khbUD7h/v59Rz8pxgefJXFswAxweTMmwy2UvfIW70MVIyv7X9V/zi Z/uGIZ8wuTf1R1LizUDz27RWv4OCYIB93ZEtWyq62A1P41gQv4wt9thDq/K5AmjU9C dZ8wdcSNCP7r1W2vraP+OTz2OvtpAyKtNujUGjC4= 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 B1B3320E4129; Wed, 12 Sep 2012 16:38:56 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 12 Sep 2012 16:38:56 -0400 Message-ID: <2835019.p0IRteJQ6q@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: References: <20120912011024.20846.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 20:39:00 -0000 On Wednesday, September 12, 2012 03:00:56 PM Barry Leiba wrote: > > The debate, then, is about whether RFC2119 language can be used to > > describe an operational practice (in this case, local policy) that > > isn't part of the protocol proper. I believe the answer is "no". > > Perhaps one of the co-chairs or an AD should weigh in on that point. > > The chairs have both said good things along this line; note Andrew's > comment especially. As an AD, I'll add my agreement, but I'll also > add some other comments. > > This is an important point, so note it well: > Not all normative text has 2119 keywords in it. > > Let me say that again, in a different way: > Just because you decide not to put MUST or SHOULD (with or without > NOT) in doesn't mean that it's just fluff text that can be ignored on > whim. > > AS A PARTICIPANT, I agree with Scott: if we have, by experience, > determined that it's a really bad idea to do X (where X might be to > silently delete mail purely on the basis of an SPF fail, or any other > such thing), then it's a really good idea to say so, and to strongly > advise against it. > > As both a participant and an AD, I think such advice should not be > using 2119 language. And I think that doesn't, in itself, make it > casual, non-normative advice. If you want to give strong advice in > the form of an applicability statement, do so. You can even label the > paragraph "Applicability Statement:", or put it in a section so > titled. Thank you. I think that clarifies it for me. Scott K From sm@elandsys.com Wed Sep 12 14:15:44 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353FD21F863F for ; Wed, 12 Sep 2012 14:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 116PzcadTZN7 for ; Wed, 12 Sep 2012 14:15:43 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9098A21F8624 for ; Wed, 12 Sep 2012 14:15:43 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.159]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8CLFKEU004011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Sep 2012 14:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347484540; bh=WISPA9RchmNf3/g0it3ZDNmBMuOSSefsvQ7qVl8KJSo=; h=Date:To:From:Subject:Cc; b=wRd0haSAyR5AmjOcbKVN8pZGCxHNj66phF84+Vb65v0uD987oJtWlyxvASpODX/2H JRzzH+xkZIk3ObRDjYokHK+Hof9TUgJRTRQAx9bbylnr9foZIoL4PSiNWyNol5PsCS HIev5o82U0Wg70s+6HvbX7nBKOtS0o+jucQeCJPM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347484540; i=@elandsys.com; bh=WISPA9RchmNf3/g0it3ZDNmBMuOSSefsvQ7qVl8KJSo=; h=Date:To:From:Subject:Cc; b=B2j17iwuue8wfmtmBqZ3n8RzMDLRgl/LHMejeJ3Wl0lV/iULweQr/r65vWIysBqqP iulaBRrldVGhkFibyJdPasl60n8TyI9mc0sWRE6HGZMOd+iYRk1F90NG8NtMU1Qx02 yvUHkLDKXeqLWcZCrQ40LI+rJao4B1yvQ8nMozF4= Message-Id: <6.2.5.6.2.20120912135850.0a591fb0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 12 Sep 2012 14:14:00 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis-chairs@tools.ietf.org Subject: [spfbis] Discussions about MARID X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 21:15:44 -0000 Hello, Discussions about MARID are controversial. The effect is disruption to the work of this working group. Discussions about MARID are off-topic. I strongly suggest that working group participants refrain from posting any comments about MARID or sending replies to messages about MARID to the SPFBIS mailing list. Thank you for your understanding. S. Moonesamy SPFBIS WG co-chair From hsantos@isdg.net Wed Sep 12 16:01:55 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F36721F85A3 for ; Wed, 12 Sep 2012 16:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVzsruLA6+YU for ; Wed, 12 Sep 2012 16:01:54 -0700 (PDT) Received: from catinthebox.net (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 806A521F858F for ; Wed, 12 Sep 2012 16:01:53 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1405; t=1347490902; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Ew75ysjwSOCB+lvJR0zyvtWTDl0=; b=epQGABehrbQXWTiJeyTI eGAfvJL8lDjbXfwZnUQIIJqr9uC+M6WjclIBbnYRoOehRGVEEZ5P/PWiLNIo/DLj LBcLwy/Ai3W1pqlFwT4k6PDIN/0ociq5LQ7W9SI/l4Vk3+pFJcamncxFHQC13DPS vISW2T9fMbhvAX27riYE4Nw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 19:01:42 -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 3512678999.6316.5252; Wed, 12 Sep 2012 19:01:41 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1405; t=1347490674; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=1REYG06 +LhyiqYssZi6WCVkTxd6iSFrWQ6W0g4GXZ6U=; b=RqHoHtVCZcEqcHJat51Ky+X larlptvIZK8w5RJdYjuthAghbU/8QK5Dq3XUat2m2kbvLZoAtsKNk9Of4PEOrlLJ 1ushiPPNklE7IlCmjfh/P4EvfJ9E1GvWEciToqphrUAKDTCRxWsKqHxOHCMlI6f1 C5CmqNyHx2eZ5mpr0W8w= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 18:57:54 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4111472708.9.1388; Wed, 12 Sep 2012 18:57:53 -0400 Message-ID: <50511484.2010009@isdg.net> Date: Wed, 12 Sep 2012 19:02:28 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20120912135850.0a591fb0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120912135850.0a591fb0@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Discussions about MARID X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 23:01:55 -0000 If you don't want discussions about MARID, then we should stop trying to redefine it with a new "Applicability Statement" and with rhetorical subjective new ideas long debated and defeated during the MARID working group. MARID is the only defense one has against the onslaught of a new wave of SPF application assessments that in my extremely strong engineering opinion as an early adopter will change the face of SPF, its value, its payoff and utility to not only domains publishing records but to receivers that support it. We don't need more doubt added to SPF and I don't quite see how it can be become a IETF standard document with such new doubt added long discussed and dealt with in the pass. One thing for sure, it is already an INTERNET standard. So why we trying to change that? Moonesamy wrote: > Hello, > > Discussions about MARID are controversial. The effect is disruption to > the work of this working group. Discussions about MARID are off-topic. > I strongly suggest that working group participants refrain from posting > any comments about MARID or sending replies to messages about MARID to > the SPFBIS mailing list. > > Thank you for your understanding. > > S. Moonesamy > SPFBIS WG co-chair > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From sm@elandsys.com Wed Sep 12 16:03:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462D121F85F4 for ; Wed, 12 Sep 2012 16:03:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-NJSHgV0VOh for ; Wed, 12 Sep 2012 16:03:44 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 397C621F85C3 for ; Wed, 12 Sep 2012 16:03:44 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.159]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8CN3RXb028778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Sep 2012 16:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347491022; bh=NO4SuovP+gMugcmiCWrp27OxEfv5a6Jzk+AdbW41RDo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=s6vi1YfhsJHm449yDC7qnRitHQuAcRHRGMEHYeUiXvVVn2loZnZC+oOokre58Eh8b 24kXcqOrQtPoxe9kayyJD3CqVB70evNndIiiyPnkUPxphilwMoVvig+Yc5su/FdkhL r3O4r9gKj5YVdFb9IRAVHKtL+lD7VMAW3LILuj2M= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347491022; i=@elandsys.com; bh=NO4SuovP+gMugcmiCWrp27OxEfv5a6Jzk+AdbW41RDo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VlswVgGLGX21GAUMKGCHJXio0ZwK1VHMsMc0uzOzkAlqOt7MbyVNGJt5iigv7CAni /dgkQxBPxEmb8qKZ3GsIXs+JdXZ36tAu6NmmlFE9eliheVI8ppUO9yjHVN1xGI7HyG cMW3/vrFDDL/cxxnVvLvSEaxa+KB90aSQvhgtsjA= Message-Id: <6.2.5.6.2.20120912153856.0a2453c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 12 Sep 2012 15:44:44 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <1868695.UVVp0ZHKnm@scott-latitude-e6320> References: <064.8a6275919aba4fa5f4f9c983ff6041f6@tools.ietf.org> <6.2.5.6.2.20120911214905.09388488@elandnews.com> <1868695.UVVp0ZHKnm@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #60: Section 2.3 - Publishing Authorization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 23:03:45 -0000 Hi Scott, At 11:44 12-09-2012, Scott Kitterman wrote: >I don't see #60 listed: > >http://trac.tools.ietf.org/wg/spfbis/trac/report/1 > >It clearly existed at one point, because I got email about the issue being >created, but it seems to have vanished. I don't see the ticket. I don't know why it vanished. I'll try and find out what happened. Regards, S. Moonesamy From sm@elandsys.com Wed Sep 12 16:19:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5AB21F8607 for ; Wed, 12 Sep 2012 16:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PK9-t6LA4tfv for ; Wed, 12 Sep 2012 16:19:21 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1CE21F8604 for ; Wed, 12 Sep 2012 16:19:20 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.159]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8CNJ74T003261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Sep 2012 16:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347491959; bh=rbVJnZXCM2KqdH8LdWVX4yrJJfIej/UbmVTpPwFndM0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Qsqv2SRfnuhc5GFpGsaUlRAO2j46ZNZ5DIANnpoLOJtkHDfgmbHyG5M72bZ3J5tSw itNYZhRfvSnu+LkyOmycFbW9FLzg1JtXXhl8YJLnKbZRVU0pjsuA50xAZDikaR+qi/ 9zIaRRU+pn+SNAJ04gQD7ND1DL/ydoH4XdF5o5zE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347491959; i=@elandsys.com; bh=rbVJnZXCM2KqdH8LdWVX4yrJJfIej/UbmVTpPwFndM0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=G5Y5kyiTXUNaeX/FtR54vUXCSne4PgcY+3Hq3YzpvvFS6uGRoQH01N9Vn4bXdGqnf TlgaohUMDU5DiwAXiHWufL/THFb21lsekobGslTR9d3Noj62TTix1Vw+8GmorXe2AJ 69mKOZiPUmpdVQGRh36wjQxnvObCLOrAlLpiE82A= Message-Id: <6.2.5.6.2.20120912160527.0a5a83e0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 12 Sep 2012 16:18:56 -0700 To: Hector Santos From: S Moonesamy In-Reply-To: <50511484.2010009@isdg.net> References: <6.2.5.6.2.20120912135850.0a591fb0@elandnews.com> <50511484.2010009@isdg.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Discussions about MARID X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 12 Sep 2012 23:19:22 -0000 Hi Hector, At 16:02 12-09-2012, Hector Santos wrote: >If you don't want discussions about MARID, then we should stop >trying to redefine it with a new "Applicability Statement" and with >rhetorical subjective new ideas long debated and defeated during the >MARID working group. > >MARID is the only defense one has against the onslaught of a new >wave of SPF application assessments that in my extremely strong >engineering opinion as an early adopter will change the face of SPF, >its value, its payoff and utility to not only domains publishing >records but to receivers that support it. We don't need more doubt >added to SPF and I don't quite see how it can be become a IETF >standard document with such new doubt added long discussed and dealt >with in the pass. One thing for sure, it is already an INTERNET >standard. So why we trying to change that? The above message is off-topic. In the message posted at http://www.ietf.org/mail-archive/web/spfbis/current/msg02823.html I suggested refraining from discussing MARID as it is a disruption to the work of this working group. It is unfortunate that the suggestion has been ignored. Regards, S. Moonesamy SPFBIS WG co-chair From hsantos@isdg.net Wed Sep 12 18:07:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526A421F86AB for ; Wed, 12 Sep 2012 18:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.706 X-Spam-Level: X-Spam-Status: No, score=-101.706 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efkRdizqyB23 for ; Wed, 12 Sep 2012 18:07:04 -0700 (PDT) Received: from mail.santronics.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3193821F869D for ; Wed, 12 Sep 2012 18:07:03 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3014; t=1347498412; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=AQRqNEHVZ+bM17AK7padVJMha0w=; b=bN8LDHIBnNdMVAXI5RN7 F3rV+udOe5yLQowtH+Bf2qr/wxosAAWiT4FB7SMWel2muhO0G4vcJ/W6PH4yK0nC 7HGt4hy4NXh1V499hZ8iKZKBz4eZgY8uRKfWwj/8x/FUsiNfqdoiF01ewr+kt5eW dxN5duV0mJW5oWtgoy39nCQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 21:06:52 -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 3520189308.6316.5144; Wed, 12 Sep 2012 21:06:52 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3014; t=1347498184; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=MosyYlX FHABHIOZz+B4fp9yZHv1huDnTcsCkquE8jUs=; b=K3qxa5O8iY6S3+NiySHkZwf yq9bqJuBDhmNX0O8LjpT7hMNlnbXzZNcN37t2LkUqDUzGo4PLdnOrHwL5XIE570T /jA3NRGS6Du9fqLF4KhbrCqeCYGQ0BJK7N/yaztd586Ph6Z6hvOXT1vQBVOozgkE InY33jxbKcdOU7gsE7/g= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Wed, 12 Sep 2012 21:03:04 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4118982349.9.296; Wed, 12 Sep 2012 21:03:03 -0400 Message-ID: <505131E2.5020906@isdg.net> Date: Wed, 12 Sep 2012 21:07:46 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20120912135850.0a591fb0@elandnews.com> <50511484.2010009@isdg.net> <6.2.5.6.2.20120912160527.0a5a83e0@elandnews.com> In-Reply-To: <6.2.5.6.2.20120912160527.0a5a83e0@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Barry Leiba , Pete Resnick Subject: [spfbis] Seeking AD clarification on what should be DISCUSSED in this WG X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 13 Sep 2012 01:07:05 -0000 S Moonesamy wrote: http://www.ietf.org/mail-archive/web/spfbis/current/msg02824.html > The above message is off-topic. In the message posted at > http://www.ietf.org/mail-archive/web/spfbis/current/msg02823.html I > suggested refraining from discussing MARID as it is a disruption to the > work of this working group. It is unfortunate that the suggestion has > been ignored. I wish to have a point of WG AD management clarification to address the many interrelated issues raised from single issue #29. Sorry, but I don't believe I am ignoring your request but it is unfair to just casll it a CALL without resolved any of the issue issues. You can't just leave it in limbo. You don't want any MARID engineering discussed, yet does that include 9 years of practical experience and field experience? Are we suppose to just ignore all that too? It is highly irregular to expect real implementators to toss out experience in using SPF while the CHAIRS allow the limited few who were always militantly against SPF (and still are) are now rehashing old MARID debates long settled via RFC documents as if it (SPFBIS) is a new timeline with suggestions the mode of SPF rejections was never part of the SPF fundamental design philosophy and protocol process and there is a new proposed the existence of a new different Applicability Statement, including one that touches based with Reputation. Further, all non-MARID statements are ignored: -ALL has a definition for rejection or marking ?ALL has RFC2119 language for no rejection The point people stated that if one wants no rejection, then use ?ALL. Not -ALL. Understand? IOW you don't need to change SPF because it already offers a more relaxed form of marking the message where there is no REJECTION. No, instead, they want -ALL to be relaxed as well and don't want to bother with the security impact that it WILL have (issue #33) and when its pointed out that SPF does indeed had have semantics for applying -ALL, a new issue #60 is created to begin questioning that. This is absolutely uncalled for. That is what should be OUT OF SCOPE - reinventing Applied SPF and it is completely unfair to long time SPF supporters that use SPF today in their product lines. I wish to have a point of WG AD management clarification to address the many interrelated issues among. How are we to discuss all there inter-related issues all having their genesis from issue #29 when the long time opponents of the inherent rejection concept in SPF is now being rehashed, disputed and SPFBIS being remodeled to a new Reporting Mechanism? ISSUE #29 Defining MARK-ON-FAIL unrequested morphing to: ISSUE #33 Marked Failed Mail Exposure (Security Issue) ISSUE #58 Local Policy in 4408BIS ISSUE #60 Publishing Authorization Why is all this in question now ll that was asked in issue #29 was to define what MARKING the mail meant as opposed to the RFC2219 language provided for REJECTION? -- HLS From spf2@kitterman.com Wed Sep 12 19:51:02 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A015C21E8064 for ; Wed, 12 Sep 2012 19:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G93CZEghX8SL for ; Wed, 12 Sep 2012 19:51:00 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 84EF521E8049 for ; Wed, 12 Sep 2012 19:51:00 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9D43D20E4166 for ; Wed, 12 Sep 2012 22:50:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347504659; bh=b6I1HFak4e+VDeQMu9DciEO//f8n5b+5/wTDOOtl8a0=; h=From:To:Subject:Date:References:In-Reply-To:From; b=d4hlAtkiViynO+sB9DQhbQfQp0ctbc+xinSuuqQUf7rsfwFNqr/J5N9RtgKRigGyx 81TqwUdKzWkPnlRUEmgewMwVxF6VQJe/+y5cojJs8dQo8o86Uu1EmJ4LJJn+OXHXwU +uS+p5AhWpZldOneu1sad1AiSaO6vrHEbUAIs/Uc= Received: from kitterma-desktop.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPS id 85CE720E4129 for ; Wed, 12 Sep 2012 22:50:59 -0400 (EDT) From: Scott Kitterman Organization: Kitterman Technical Services To: spfbis@ietf.org Date: Wed, 12 Sep 2012 22:51:01 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-42-generic; KDE/4.4.5; i686; ; ) References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> In-Reply-To: <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209122251.02375.spf2@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 02:51:02 -0000 On Monday, September 10, 2012 06:11:40 am S Moonesamy wrote: > Hi Alessandro, > > At 02:15 10-09-2012, Alessandro Vesely wrote: > >That seems to be consistent with Murray's vision of a split, as given > >in http://www.ietf.org/mail-archive/web/spfbis/current/msg02700.html > > > >Does this thread/issue include considerations about the contents of > >the revised charter? > > Sorry for not provide context. Barry Leiba responded to a comment I > made about a sentence in Section 2.5.4 ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02708.html > ). Text was suggested in the messages at: > > http://www.ietf.org/mail-archive/web/spfbis/current/msg02710.html > http://www.ietf.org/mail-archive/web/spfbis/current/msg02711.html > http://www.ietf.org/mail-archive/web/spfbis/current/msg02712.html > > and there was a comment from John Levine ( > http://www.ietf.org/mail-archive/web/spfbis/current/msg02716.html ). > > This is not directly related to a revised charter or any split. I > cannot tell whether there is agreement or not about whether a message > rejection or any other action following a SPF evaluation is a matter > of local policy. This thread is to get a sense of views about that. > > As a possibly bad example, is the action taken after a SPF evaluation > an operator decision or is it up to the implementation? We've spent a lot of time arguing over how not to give direction on local policy for SPF fail in RFC 4408bis when neither 4408 nor 4408bis do so (which seems like an odd place to expend resources to me). The only definitive piece of receiver policy MUSTard in 4408/4408bis is for neutral. It says: A "Neutral" result MUST be treated exactly like the "None" result; the distinction exists only for informational purposes. Treating "Neutral" more harshly than "None" would discourage domain owners from testing the use of SPF records (see Section 9.1). If you want to argue about receiver policy, let's start there. I think that should definitely stay because the MUST is part of the semantics of the result. Additionally, if we're going to say it's a matter of local policy, we have to, to some extent, say what that means. I don't think it makes any difference if we say see section 9 for a description of what that means or see 4408bis' for a descriptions ... We have to cover the information either way. If we end our definition of the protocol with an undefined term, that's just a bug. To answer your specific question (implementation or operator), my answer would be "yes". An operator is limited to the options an implementation supports. Since it's a matter of local policy, the operator should be the one making the determination and a good mail system that integrates SPF would make a range of choices available so that the system can be configured to correctly implement the policy. I don't think any of that goes in 4408bis or the possible 4408bis'. Scott K From agthisell@yahoo.com Wed Sep 12 21:50:04 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8E421F8501 for ; Wed, 12 Sep 2012 21:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDcLDBZ90Fo9 for ; Wed, 12 Sep 2012 21:50:03 -0700 (PDT) Received: from nm23.bullet.mail.ne1.yahoo.com (nm23.bullet.mail.ne1.yahoo.com [98.138.90.86]) by ietfa.amsl.com (Postfix) with SMTP id 0E3CC21F84FE for ; Wed, 12 Sep 2012 21:50:02 -0700 (PDT) Received: from [98.138.90.55] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2012 04:50:00 -0000 Received: from [98.138.89.174] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 13 Sep 2012 04:50:00 -0000 Received: from [127.0.0.1] by omp1030.mail.ne1.yahoo.com with NNFMP; 13 Sep 2012 04:50:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 20368.48185.bm@omp1030.mail.ne1.yahoo.com Received: (qmail 17393 invoked by uid 60001); 13 Sep 2012 04:49:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347511799; bh=tJjEf2SlavxanZprHvQhYrgSOaJJKqv6zgaB9Ef0miY=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=GBn03yRMxK/+Fh87XAtApkcCf3aB1n8CJq/tzTS60QgW0J/g+ChYeem+lNjeC2w3ScvZK+DAaCYQuAMe38iJUSC+pZtTsTawYkQASUp08RGRiUDsFgrZSuJtYFvW7kgQut2sWYB+cDL+QFTRAMigTy8PecxQS0iC1fL0C3xXjXw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=3w9QV8Cfq0GRd1WG5Rc3pm/hRafuPzhK0Iq31MGnt9rFOPfORkPFsy3hxU5adGXdvKh4oH6W6+MQdJUKyxylfnzNMCGUvYLD6EXAKmUV6txWjRk8nyr4m2PtVvOH8/GStiyr2J6sDU8rKo/nj0N/YYGCEegevzeq3Yju6P6YXoE=; X-YMail-OSG: mdKlLhQVM1kciLTMDE0QJHuuivSL1ZKEZFWIkFDTsa_MY_2 7VFCdpW33gXHZSEhROb5MLX72pcgFWIOxa4KNBTNCEYZoPAxGqYxM09uJ62i BepgLljsWl1VX3_4SnaSJ1gtB6GH.565tuqH5_NQkWvTN5hF11SM8UTq3ONe oWz43xXvXseuvZurp5p.K46BTb3lu65VPtR57ON2.ukaGbT6.cmSfsPc2ye8 .rtgAjlfADOYFmSB1CDWTQMHjWcsW_k3VjshZbUdfmS4xc7QM7k1uMQcbj4Z FWaF4ntkG.as7q09mGjW5fm0Tz.gsKmAe2wIemwWpqm.BEIKPJuGvf2eRAAs PzVagssOtnbl9nSro4sVHOcHUu_2k7VE1RDK4VoUynj6YtD_0qexsHw3DVHq J9DobuMFw28y9LMdIEWeym2EVfWWEJuz8pFScazfQFCRDKy9e7XDgyVmpQaO mIYtvq4xcfNg1tmeMiNdM6Wk.hyzVF5.VBMfJewqlyCwT1Eetw2XFKYSGosb 4iELY1WoZSzUTRf.XIhlUfLmdroc3tDdW5ISusMaEtQsthk0rr_02UA-- Received: from [71.61.133.134] by web125104.mail.ne1.yahoo.com via HTTP; Wed, 12 Sep 2012 21:49:59 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347511799.13281.YahooMailClassic@web125104.mail.ne1.yahoo.com> Date: Wed, 12 Sep 2012 21:49:59 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] Seeking AD clarification on what should be DISCUSSED in this WG X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 13 Sep 2012 04:50:04 -0000 Hector, you keep saying things like: > {...} as if it (SPFBIS) is a new timeline with suggestions the mode of SPF > rejections was never part of the SPF fundamental design philosophy and > protocol process {...} > No, instead, they want -ALL to be relaxed {...} > That is what should be OUT OF SCOPE - reinventing Applied SPF and it is > completely unfair to long time SPF supporters that use SPF today in their > product lines. My memory is rusty enough to go back and check things. I can find no evidence that SPFf has ever had a stronger policy than what 4408bis currently has. Nothing that says that it is expected that email that fails SPF checks should be not up to the receiver to decide if it should be rejected. The first post to the spf-discuss list from you that I could find was from 16 feb 2004, but I may have missed some. But feb 2004 is not much before MARID started and it is long after Meng Weng Wong changed the SPF documents to say "pass/fail" from "accept/deny". I can find Meng Weng Wong writing things like "SPF, in the best and worst traditions of Unix, aims to provide mechanism, not policy.", but nothing from him that backs up your claims. The SPF documents back then have contradictory language, some parts saying clearly that it up to the receiver, some parts saying that non-conformant messages SHOULD be rejected, but on balance most of each document say that up to the receiver. Can you please give some pointers to back up your claim? Obviously, I can't give pointers to stuff that isn't there. One public archive of spf-discuss that I could find is: http://www.mhonarc.org/archive/html/spf-discuss/ From spf2@kitterman.com Wed Sep 12 22:45:32 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5983221E8047 for ; Wed, 12 Sep 2012 22:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJ9pvH82xsUE for ; Wed, 12 Sep 2012 22:45:31 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id DBB7421E8048 for ; Wed, 12 Sep 2012 22:45:28 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 213AB20E4166; Thu, 13 Sep 2012 01:45:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347515127; bh=B8OAJOzTFq0f4J1SgVMKan3ZGXiYw0yegO2GVhSNUVw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=J0tqYvbn3ap6QrFYcmuFZD2zHIquGp0IepJwvyEgdbQIL/TS8nJwVXBkQVPi1ksD0 yq2IDd/gBH7+byQtZVHfjy80f1Dxj1PUXDpLEm+MDnNOpzUSDE2B5mkrq7ozHpA2l9 sLtn2TLyDWz8xKc5KVMH7Yh45jfpFPqJFXuJpguk= 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 ECF2020E4129; Thu, 13 Sep 2012 01:45:26 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 13 Sep 2012 01:45:26 -0400 Message-ID: <13893875.pFe5IcLtHn@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <1347511799.13281.YahooMailClassic@web125104.mail.ne1.yahoo.com> References: <1347511799.13281.YahooMailClassic@web125104.mail.ne1.yahoo.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] Seeking AD clarification on what should be DISCUSSED in this WG X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 13 Sep 2012 05:45:32 -0000 On Wednesday, September 12, 2012 09:49:59 PM Arthur Thisell wrote: > Hector, you keep saying things like: > > {...} as if it (SPFBIS) is a new timeline with suggestions the mode of SPF > > rejections was never part of the SPF fundamental design philosophy and > > protocol process {...} > > > > No, instead, they want -ALL to be relaxed {...} > > > > That is what should be OUT OF SCOPE - reinventing Applied SPF and it is > > completely unfair to long time SPF supporters that use SPF today in their > > product lines. > > My memory is rusty enough to go back and check things. I can find no > evidence that SPFf has ever had a stronger policy than what 4408bis > currently has. Nothing that says that it is expected that email that fails > SPF checks should be not up to the receiver to decide if it should be > rejected. > > The first post to the spf-discuss list from you that I could find was from > 16 feb 2004, but I may have missed some. But feb 2004 is not much before > MARID started and it is long after Meng Weng Wong changed the SPF documents > to say "pass/fail" from "accept/deny". I can find Meng Weng Wong writing > things like "SPF, in the best and worst traditions of Unix, aims to provide > mechanism, not policy.", but nothing from him that backs up your claims. > > The SPF documents back then have contradictory language, some parts saying > clearly that it up to the receiver, some parts saying that non-conformant > messages SHOULD be rejected, but on balance most of each document say that > up to the receiver. > > Can you please give some pointers to back up your claim? Obviously, I > can't give pointers to stuff that isn't there. > > One public archive of spf-discuss that I could find is: > http://www.mhonarc.org/archive/html/spf-discuss/ The archive at the actual host for the list, listbox, seems to be incomplete, since it starts in April 2004, clearly in mid conversation. The one you found is better. Scott K From sm@elandsys.com Thu Sep 13 02:41:32 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEEE221F8530 for ; Thu, 13 Sep 2012 02:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxhHBWU+lasB for ; Thu, 13 Sep 2012 02:41:32 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2033721F84B2 for ; Thu, 13 Sep 2012 02:41:32 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.104]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8D9fHd4014449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Sep 2012 02:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347529290; bh=7H+EYnWAmT6gN3uaB3Nex121mfSPz9FnC95hzgnAu+w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=o2Yo4+L0hZS6euPlR6SuXpDweM+wsQmELNiKDLJ3t2T/VNQgIb8owBjVgoSnqtMnd oIrILcrxpb25rA8FQSbTQjCk6p3shS4lVeEaH7qxpkuldNcBA0YvIgVMmCwwXcXIut 4wER+0n0hJl/k4wO7ttII39G/+re2uvA4Bg96/iY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347529290; i=@elandsys.com; bh=7H+EYnWAmT6gN3uaB3Nex121mfSPz9FnC95hzgnAu+w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JwKFXfGEOcRf7ziCm9qBP+CGzd3IEwmioyWW32nIcrgUoxQXOirtOU9xxcP5smbmV d2/jiiItW5osAEI2aRV/AoL89CFKWnftGS1i5pQ64jZlGVktNVVGWlO4NaOB1A34Gs RROcYv3P6lKfURIXNMoc77s8qbP7DJE0STp//7iQ= Message-Id: <6.2.5.6.2.20120913010849.098a6680@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 13 Sep 2012 02:36:59 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <6.2.5.6.2.20120824013510.08fb4170@resistor.net> References: <4F4503B1.6000202@isdg.net> <1421922.FmWU0zJib9@scott-latitude-e6320> <4F450EB2.4040305@isdg.net> <20120222162826.GA36084@crankycanuck.ca> <6.2.5.6.2.20120824013510.08fb4170@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Pete Resnick , spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] WG comportment X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 13 Sep 2012 09:41:32 -0000 Dear SPFBIS WG, A Working Group Chair is concerned with making forward progress through a fair and open process, and has wide discretion in the conduct of WG business. The Chair must ensure that a number of tasks are performed, either directly or by others assigned to the tasks. The SPFBIS Working Group Chairs have ultimate responsibility for ensuring that this working group achieves forward progress and meets its milestones. The SPFBIS Working Group Chairs are also responsible to ensure that the working group operates in an open and fair manner. It is up to the SPFBIS Working Group Chairs to attempt to ensure that the discussions on this mailing list are relevant and that they converge to consensus agreements. I rely on the understanding of working group participants to help in meeting the challenges faced by SPFBIS. The challenges are not about draft-ietf-spfbis-4408bis. They are about how to avoid the direct personalization of a discussion and manage off-topic comments. Andrew Sullivan posted a message about working group operation to this mailing list on February, 22 ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00520.html ). I posted a message to this mailing list about inappropriate behavior on August 24 ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02302.html ). Abusive postings can be reported to the SPFBIS WG Chairs. I suggest that you include an explanation in your report about what you consider as inappropriate or abusive together with a recommendation on what action to take. I communicate directly with an individual if the matter affects the operation of SPFBIS. All the parties involved are contacted; nobody is singled out. It takes more than one person to have a controversial discussion. As far as I am aware this working group is not a kindergarten. It is not for me to determine who started it. I have not discussed about this message with Andrew Sullivan. I will request an explanation, with a copy of the message to the SPFBIS mailing list, if there is an off-topic comment. If any working group participant is unhappy with this approach, it is entirely appropriate for the individual to contact Pete Resnick and ask for me to be fired as SPFBIS WG co-chair. Regards, S. Moonesamy SPFBIS WG co-chair From ajs@anvilwalrusden.com Thu Sep 13 08:17:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB5621F84A0 for ; Thu, 13 Sep 2012 08:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_40=-0.185, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0jWKA2Qwbqs for ; Thu, 13 Sep 2012 08:17:28 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9073F21F8437 for ; Thu, 13 Sep 2012 08:17:28 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id BA6B18A031 for ; Thu, 13 Sep 2012 15:17:26 +0000 (UTC) Date: Thu, 13 Sep 2012 11:17:25 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120913151724.GC89509@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] Moderation of posts from Hector Santos X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 13 Sep 2012 15:17:31 -0000 Dear colleagues, Under the procedures of BCP 94, the chairs have decided to moderate the access of Hector Santos to the mailing list, effective immediately, until 1 October. If Hector posts anything, it will come to us first, and we shall permit the message to be posted only if, in our opinion, it is a positive contribution to the WG discussion and is entirely on topic. Please do not post on Hector's behalf. If you are asked to post something on Hector's behalf and you do so, we will regard that as a violation of the chairs' decision, and will treat such acts as another vector of attack on the WG. We shall respond to such attacks using our discretion under BCP 94. Best regards, Andrew (SPFBIS co-chair). -- Andrew Sullivan ajs@anvilwalrusden.com From presnick@qualcomm.com Thu Sep 13 11:56:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED74B21F84E7 for ; Thu, 13 Sep 2012 11:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.892 X-Spam-Level: X-Spam-Status: No, score=-105.892 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYs8iVRfCTiJ for ; Thu, 13 Sep 2012 11:56:40 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 5739821F84E2 for ; Thu, 13 Sep 2012 11:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1347562600; x=1379098600; h=message-id:date:from:user-agent:mime-version:cc:subject: references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; bh=T7yoSBWH2QCJBoN/V+bsiLRx6iJ/S7nSvvuRkAyIaoY=; b=VDcIo/9zU1NA+vM2em2Dh4V0Qe2OplQ6GRM1pNcJY2bmsjo//SsTMcb6 L1nKMRJIoTFSrjWfSpCaXr6WVIatOR1ZvWGdQtbuUNsqyVDf9dri6DmYn BZv5OanNCLixCoSnOV8HeL45PkQVm8lxrWwg9IxZY1PXaZ1QDzGWj2Co8 o=; X-IronPort-AV: E=McAfee;i="5400,1158,6834"; a="236374469" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 13 Sep 2012 11:56:24 -0700 X-IronPort-AV: E=Sophos;i="4.80,418,1344236400"; d="scan'208";a="300310878" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Sep 2012 11:56:24 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 13 Sep 2012 11:56:24 -0700 Message-ID: <50522C52.1060701@qualcomm.com> Date: Thu, 13 Sep 2012 13:56:18 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 CC: References: <6.2.5.6.2.20120912135850.0a591fb0@elandnews.com> <50511484.2010009@isdg.net> <6.2.5.6.2.20120912160527.0a5a83e0@elandnews.com> <505131E2.5020906@isdg.net> In-Reply-To: <505131E2.5020906@isdg.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Subject: Re: [spfbis] Seeking AD clarification on what should be DISCUSSED in this WG X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 13 Sep 2012 18:56:41 -0000 On 9/12/12 8:07 PM, Hector Santos wrote: > I wish to have a point of WG AD management clarification... Just to close the loop on this since it was specifically addressed to me, even though the recent action by the chairs makes some of this moot: If you wish to discuss process issues (which topics are legitimate to discuss on the list, whether other participants are comporting themselves professionally or productively, whether the chairs are doing their jobs properly), those are *not* topics which should be discussed on the WG mailing list. Always start by going to the chairs if you have issues with the way things are going on the list. If you are not able to resolve an issue with the chairs or think the chairs themselves are doing something improper, you may contact me. If someone is misbehaving on the list, it is not your job to admonish them (publicly or privately), or to fire back with misbehavior of your own; we have chairs and ADs so that they can address such problems. But in particular, it is inappropriate to start any such discussions on the WG list itself. Participating on the mailing list takes a civil tongue and a thick skin. Please try to employ both. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From superuser@gmail.com Thu Sep 13 12:05:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA08921F859F for ; Thu, 13 Sep 2012 12:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJ7-si8Mt1li for ; Thu, 13 Sep 2012 12:05:47 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0043C21F85C3 for ; Thu, 13 Sep 2012 12:05:46 -0700 (PDT) Received: by lahm15 with SMTP id m15so2317452lah.31 for ; Thu, 13 Sep 2012 12:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y96cS3cLbDNjscjsREHcJe6MB8IN4uYReGbq48lmnJY=; b=NGGfvs7DQv3G07BkvWvZV92KLu9qLVvOm0m8KHVh3K+t+XxXBpJpqQMPtERLu68HdI xMNZpW+7LNsC/kOAsFd0fn8i5v3MnCn4shxhA+ccdZjQKRT9FVUkBPWHXfZH9yw3AEVv huFRiGxijW8oM6xuAZcgCs5pRdJCb7AAdsipA8amzt4B4GZ730x5928pP1FBaTG+3mir lWHfZUI4bUAuuYa2V9U/w/hav9JDgn5vTtwlsLkP/v98gQQGcyEHwIcasVY679W4Jvkn t4Ar7kk+pRfE3V4CHO38cMje9AWxnVH6YUmnCgZMEGaoUjjiIjwYI0H/fZZBVUI17fCL PoXw== MIME-Version: 1.0 Received: by 10.112.9.133 with SMTP id z5mr247663lba.69.1347563144509; Thu, 13 Sep 2012 12:05:44 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Thu, 13 Sep 2012 12:05:44 -0700 (PDT) In-Reply-To: <201209122251.02375.spf2@kitterman.com> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <201209122251.02375.spf2@kitterman.com> Date: Thu, 13 Sep 2012 12:05:44 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 19:05:47 -0000 On Wed, Sep 12, 2012 at 7:51 PM, Scott Kitterman wrote: > To answer your specific question (implementation or operator), my answer would > be "yes". An operator is limited to the options an implementation supports. > Since it's a matter of local policy, the operator should be the one making the > determination and a good mail system that integrates SPF would make a range of > choices available so that the system can be configured to correctly implement > the policy. I don't think any of that goes in 4408bis or the possible > 4408bis'. I agree, what lands in the hands of the operator is a function of the implementation, and what the implementation (assuming it's compliant) can make available is a function of what the protocol's outputs are. But both of those are at a level above what a protocol definition is supposed to say. SPF itself can't say "reject", it can only say "fail". It's up to the implementation to do something with that, whether it's rejection, "marking", logging, or something else altogether. We can and should also provide text that informs consumers (both implementers and operators) of the reasons each result can occur, so that reasonable implementation and operation (policy) decisions can be made for each result. Where it extends to an applicability statement would be defining a capability the protocol enables. Such an AS might say "Here's how to reject mail based on SPF if you're not worried about the false negatives." I think that's perfectly reasonable for us to do. I suppose the real issue is how much of that sort of thing do we need or want to say here, and also make it clear that such advice is not part of the protocol proper. To use an example, DKIM did it a little bit by saying a bad signature ought not be ascribed any particular value. With SPF we seem to want to be a lot more verbose and aggressive about interpretation, and that's what's leading us in this direction now. As for all the discussion about MARID and pre-MARID, we shouldn't hold those up as if they're a constitution for this work. It's entirely possible those people, despite good intentions, got some things plainly wrong. -MSK From dhc@dcrocker.net Thu Sep 13 12:14:42 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7426521F8499 for ; Thu, 13 Sep 2012 12:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxod8yqbUIln for ; Thu, 13 Sep 2012 12:14:42 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E53B121F8484 for ; Thu, 13 Sep 2012 12:14:41 -0700 (PDT) Received: from [192.168.1.8] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8DJEe3X000421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Sep 2012 12:14:41 -0700 Message-ID: <5052309D.8070806@dcrocker.net> Date: Thu, 13 Sep 2012 12:14:37 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Pete Resnick References: <6.2.5.6.2.20120912135850.0a591fb0@elandnews.com> <50511484.2010009@isdg.net> <6.2.5.6.2.20120912160527.0a5a83e0@elandnews.com> <505131E2.5020906@isdg.net> <50522C52.1060701@qualcomm.com> In-Reply-To: <50522C52.1060701@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 13 Sep 2012 12:14:41 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] Seeking AD clarification on what should be DISCUSSED in this WG X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 19:14:42 -0000 On 9/13/2012 11:56 AM, Pete Resnick wrote: > Participating on the mailing list takes a civil tongue and a thick skin. > Please try to employ both. which is much preferred, over a thick tongue and civil skin. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Thu Sep 13 13:41:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCDF21F85FC for ; Thu, 13 Sep 2012 13:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKYWwc0UQ-xl for ; Thu, 13 Sep 2012 13:41:00 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9F23721F859F for ; Thu, 13 Sep 2012 13:41:00 -0700 (PDT) Received: from [192.168.1.8] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8DKexvq002450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Sep 2012 13:41:00 -0700 Message-ID: <505244D9.8050108@dcrocker.net> Date: Thu, 13 Sep 2012 13:40:57 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <201209122251.02375.spf2@kitterman.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 13 Sep 2012 13:41:00 -0700 (PDT) Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 20:41:01 -0000 Folks, On 9/13/2012 12:05 PM, Murray S. Kucherawy wrote: > On Wed, Sep 12, 2012 at 7:51 PM, Scott Kitterman wrote: >> To answer your specific question (implementation or operator), my answer would >> be "yes". An operator is limited to the options an implementation supports. >> Since it's a matter of local policy, the operator should be the one making the >> determination ... > I agree, what lands in the hands of the operator is a function of the > implementation, and what the implementation (assuming it's compliant) > can make available is a function of what the protocol's outputs are. A thread that goes on this long often indicates either a lack of shared framework among participants, or a difference of opinion about a key point. I'm pretty sure the former is at work here. If we can all get on the same 'framework' page, we might yet find differences in opinion. (Gosh, that would be so unusual.) Various postings have, I think, tried to formulate a framework to share, but it does not seem to have completely succeeded. I'm a fan of diagrams, in such cases. I'm also a fan of having explicit statements about formal 'output'. Starting with Figure 1 of the DKIM Deployment document: http://www.dkim.org/specs/draft-ietf-dkim-deployment-11.html#trustseq I suggest a variant for SPF: (you need a fixed-width font for this, of course...) +------+------+ +------+------+ | Author | | Recipient | +------+------+ +------+------+ | ^ V | +-------------+ +------+------+ | Responsible |... -->| Handling |<-- | Identity | . -->| Filter |<-- +------+------+ . +-------------+ | . ^ | . | | . +------+------+ | . ++=====================| Identity |==++ | +........................>| Assessor | || | || Authorization +-------------+ || | || Identifier ^ ^ || V || | | || ++=====================++ ++======| |========++ || +------+------+ +-------------+ || | | +-----------+ || | Sending | | Identifier +--||------+ +--+ Assessment| || | Host +-------->| Validator | || | Databases | || +-------------+ +-------------+ || +-----------+ || SPF Service || ++==========================================++ The major variation is to include a portion of the Identity Assessor function to be /within/ SPF. This reflects the larger scope of SPF, compared with DKIM, in that it validates sending host authorization. Using the -07 version as reference: 1. SPF's output is defined in terms of the check_host() pseudo-function, as described in Section 4. Its possible output values are defined in Section 2.5. { aside: in documentation terms it would be nice to have results described after basic definition of the function... the simple form of this request is: references be in the document 'direction' that matches the functional relationship. In this case, output comes 'after' the function. } 2. Anything that happens after the output function and is normative needs to be essential for "interoperability". Otherwise, it is /strictly/ a matter of local preference. 3. A spec must not dictate local behaviors that are not essential for interoperability. On the other hand, it can often be helpful to have a discussion of possible or common choices and their implications. Sometimes this can be inside a specification document -- albeit highly separated from normative text -- and other times it needs to be in a separate document. The choice is sometimes a matter of taste and sometime a matter of what will make the spec more understandable to a typical reader. I'm going to claim that a receiving host's actions, after obtaining check_host() output, are always and only a matter of local preference. SPF cannot dictate any of that behavior. It can explain sender preferences (or "requests"). It can discuss implications. But it cannot dictate. Simply put, once we are outside of the realm of basic interoperability, we cannot have one ADMD dictating the behaviors of an independent ADMD. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Thu Sep 13 14:33:34 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94AE021F85FC for ; Thu, 13 Sep 2012 14:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kl3yokbwuVHf for ; Thu, 13 Sep 2012 14:33:33 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D709321F85F9 for ; Thu, 13 Sep 2012 14:33:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D8DCE20E4166; Thu, 13 Sep 2012 17:33:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347572012; bh=HCgroIHnxelXWlO0/W3129AO0J/q3+tC3w3EOdo+5ew=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YBbosLVdGl4639j5342jK4H82g3oIlzGrC+5Xj87HKonDwtQKNnSbr7KAAXXuBADm FpVBVXPrjXg0VNlXmj8Kyak4V1uTV3xQvNCK4k6QfeZ6ywXT7mKkHsRKg+ZlbXbEQp 39YEh+eTXtAA4HGQpG7S67KH17YLbPZ/2IgllrsU= 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 B0EBD20E409A; Thu, 13 Sep 2012 17:33:32 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 13 Sep 2012 17:33:32 -0400 Message-ID: <1367298.7yqF3eMnDC@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <505244D9.8050108@dcrocker.net> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <505244D9.8050108@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 21:33:34 -0000 On Thursday, September 13, 2012 01:40:57 PM Dave Crocker wrote: ... > I'm going to claim that a receiving host's actions, after obtaining > check_host() output, are always and only a matter of local preference. > SPF cannot dictate any of that behavior. It can explain sender > preferences (or "requests"). It can discuss implications. But it > cannot dictate. ... To focus in on this bit, as I think it's the core .... I believe this is generally, but not universally true. Specifically, as I mentioned up thread, I think the MUST treat the same as "none" language for "neutral" in RFC 4408 is part of the core semantics of what the "neutral" SPF result means. I don't think it's severable. If that can't stand, it'd be more technically correct to eliminate the "neutral" result and map "?" to none, but (of course) we can't do that. Yes, I know that nothing we write in 4408bis stops someone from doing the exact opposite of what it says, but that doesn't make it wrong to say it. Scott K From dhc@dcrocker.net Thu Sep 13 14:56:55 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7058021F8620 for ; Thu, 13 Sep 2012 14:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3qNwhesjS0n for ; Thu, 13 Sep 2012 14:56:54 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CF7B821F84F9 for ; Thu, 13 Sep 2012 14:56:54 -0700 (PDT) Received: from [192.168.1.8] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8DLuscC003758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Sep 2012 14:56:54 -0700 Message-ID: <505256A3.5040704@dcrocker.net> Date: Thu, 13 Sep 2012 14:56:51 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Scott Kitterman References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <505244D9.8050108@dcrocker.net> <1367298.7yqF3eMnDC@scott-latitude-e6320> In-Reply-To: <1367298.7yqF3eMnDC@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 13 Sep 2012 14:56:54 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 21:56:55 -0000 On 9/13/2012 2:33 PM, Scott Kitterman wrote: > On Thursday, September 13, 2012 01:40:57 PM Dave Crocker wrote: > ... >> I'm going to claim that a receiving host's actions, after obtaining >> check_host() output, are always and only a matter of local preference. >> SPF cannot dictate any of that behavior. It can explain sender >> preferences (or "requests"). It can discuss implications. But it >> cannot dictate. > ... > To focus in on this bit, as I think it's the core .... > > I believe this is generally, but not universally true. Specifically, as I > mentioned up thread, I think the MUST treat the same as "none" language for > "neutral" in RFC 4408 is part of the core semantics of what the "neutral" SPF > result means. I don't think it's severable. > > If that can't stand, it'd be more technically correct to eliminate the > "neutral" result and map "?" to none, but (of course) we can't do that. Well, it's certainly important to ask why it is important to have two different output values, if their semantics are the same. My impression is that it is considered useful to keep the separate values. Hence I think our job is to define the semantics in two parts. Perhaps one is authorization semantics; with the other being logging "semantics", if that distinction works for folk. > Yes, I know that nothing we write in 4408bis stops someone from doing the > exact opposite of what it says, but that doesn't make it wrong to say it. Classic point: operators are always free to do whatever they want. The issue with a spec is defining "the 4 walls of an environment" and then it owns the semantics within those walls. Hence, an operator that does something else is outside the scope of the spec, rather than 'violating' it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Thu Sep 13 15:09:57 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA94621F867C for ; Thu, 13 Sep 2012 15:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtoAqKed6vsH for ; Thu, 13 Sep 2012 15:09:57 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 13DC721F8600 for ; Thu, 13 Sep 2012 15:09:57 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 84DC020E409A; Thu, 13 Sep 2012 18:09:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347574196; bh=t2zC7P+4x8tnjUfRFgLCHQFsFB1oSmz62r8Rg3Is0wc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=deoAtnwxYkj60mq0hmruG7OScz9lCU+SasSmYuF8GiAizZSHbzEFHhg4v91m21HNU wwMpFuDZLYbiaTyXIN4mWH9DO+gsZl4m6xpYiFdnOCvJW7TRImsCSuAzMOkDC8bJxx bUX+4R+f9aPBMfjANAIJQZReCXpCGFvfETdT5png= 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 5599620E4062; Thu, 13 Sep 2012 18:09:55 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 13 Sep 2012 18:09:55 -0400 Message-ID: <1516105.Uvc9vP9JZz@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <505256A3.5040704@dcrocker.net> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <1367298.7yqF3eMnDC@scott-latitude-e6320> <505256A3.5040704@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 22:09:57 -0000 On Thursday, September 13, 2012 02:56:51 PM Dave Crocker wrote: > On 9/13/2012 2:33 PM, Scott Kitterman wrote: > > On Thursday, September 13, 2012 01:40:57 PM Dave Crocker wrote: > > ... > > > >> I'm going to claim that a receiving host's actions, after obtaining > >> check_host() output, are always and only a matter of local preference. > >> SPF cannot dictate any of that behavior. It can explain sender > >> preferences (or "requests"). It can discuss implications. But it > >> cannot dictate. > > > > ... > > To focus in on this bit, as I think it's the core .... > > > > I believe this is generally, but not universally true. Specifically, as I > > mentioned up thread, I think the MUST treat the same as "none" language > > for > > "neutral" in RFC 4408 is part of the core semantics of what the "neutral" > > SPF result means. I don't think it's severable. > > > > If that can't stand, it'd be more technically correct to eliminate the > > "neutral" result and map "?" to none, but (of course) we can't do that. > > Well, it's certainly important to ask why it is important to have two > different output values, if their semantics are the same. There are a number of places where SPF semantics are more verbose than they might be. If I were designing SPF from scratch, I'd probably combine the "a", "ip4", and "ip6" mechanisms into one. If we were the SPF3 WG and not SPFbis I'd probably suggest combining them and I'd think disposing of "neutral" in favor of "none" was worth discussing. > My impression is that it is considered useful to keep the separate > values. Hence I think our job is to define the semantics in two parts. > Perhaps one is authorization semantics; with the other being logging > "semantics", if that distinction works for folk. It is a useful distinction for forensics, but not normal operations, so your suggestion makes conceptual sense. My suspicion is trying to describe it that way will be more confusing than what we have now, but I'm certainly glad to explore to concept if you have ideas about how to characterize it. Scott K From barryleiba.mailing.lists@gmail.com Thu Sep 13 15:21:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DF821F8692 for ; Thu, 13 Sep 2012 15:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.954 X-Spam-Level: X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIU6Pd2t92L0 for ; Thu, 13 Sep 2012 15:21:57 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5C76921F8681 for ; Thu, 13 Sep 2012 15:21:57 -0700 (PDT) Received: by lbky2 with SMTP id y2so2491382lbk.31 for ; Thu, 13 Sep 2012 15:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xAfszG976BHkX+vtCTwK43LkDtb9Ig66EP62eUfKkgI=; b=q1JVeOG+XopgQit484KEfxjlnQmk/9Jz4CfvLmBIn+vobopGf7z2fYmLSPPJbQdSvg Umio058X5SrKT+IECHvgEYlBau4yZ8ZeFyu2B/mJZxxKQq6R9OVxwBFJjl0bfD5BzkP9 EeekZ/yctXcO/j8xUInQlFOX8M1a/yECG2M4kPQLreiv+g9fzngR8+8zKFEJFjzFlL1m 5uv3nHCc7AreqEPhcUrH4eAGMdpojbZe7CzBYDPeh9O8YZbIcvyBPanThpp4Vz7MxuII Gt7hLW8nSW8FX0vVQx8yo71kRpR7x8Do9qGe9t6NroiK9Xj3MGcGwKcV3US6zuQcoVfy /6gQ== MIME-Version: 1.0 Received: by 10.152.108.206 with SMTP id hm14mr499966lab.53.1347574916272; Thu, 13 Sep 2012 15:21:56 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Thu, 13 Sep 2012 15:21:56 -0700 (PDT) In-Reply-To: <50522C52.1060701@qualcomm.com> References: <6.2.5.6.2.20120912135850.0a591fb0@elandnews.com> <50511484.2010009@isdg.net> <6.2.5.6.2.20120912160527.0a5a83e0@elandnews.com> <505131E2.5020906@isdg.net> <50522C52.1060701@qualcomm.com> Date: Thu, 13 Sep 2012 18:21:56 -0400 X-Google-Sender-Auth: kntiLHwF4iHX9SIg4GLldsepHxI Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Seeking AD clarification on what should be DISCUSSED in this WG X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 13 Sep 2012 22:21:58 -0000 > Always start by going to the chairs if you have issues with > the way things are going on the list. If you are not able to resolve an > issue with the chairs or think the chairs themselves are doing something > improper, you may contact me. Adding to this: You may certainly address your concerns to me, as Pete's co-AD, as well as to Pete, but it's ultimately going to be Pete who handles the issue, because he's the responsible AD. I'm following this WG because I'm interested in it, but I am not the one managing its chairs: Pete is. Because of that, it's probably best to just go to Pete, and not to me, when you need AD intervention. If Pete is unresponsive, I'll be happy to help, but I think that will be needed rarely, if ever. Barry (the other AD) From dhc@dcrocker.net Thu Sep 13 15:34:01 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99A521F866C for ; Thu, 13 Sep 2012 15:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zgN97BlHgUf for ; Thu, 13 Sep 2012 15:34:01 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3087A21F866A for ; Thu, 13 Sep 2012 15:34:01 -0700 (PDT) Received: from [192.168.1.8] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8DMXwbF004584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Sep 2012 15:33:58 -0700 Message-ID: <50525F53.3090006@dcrocker.net> Date: Thu, 13 Sep 2012 15:33:55 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Barry Leiba References: <6.2.5.6.2.20120912135850.0a591fb0@elandnews.com> <50511484.2010009@isdg.net> <6.2.5.6.2.20120912160527.0a5a83e0@elandnews.com> <505131E2.5020906@isdg.net> <50522C52.1060701@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 13 Sep 2012 15:33:58 -0700 (PDT) Cc: Pete Resnick , spfbis@ietf.org Subject: Re: [spfbis] Seeking AD clarification on what should be DISCUSSED in this WG X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 22:34:01 -0000 On 9/13/2012 3:21 PM, Barry Leiba wrote: > You may certainly address your concerns to me, as Pete's co-AD, as > well as to Pete, but it's ultimately going to be Pete who handles the > issue, because he's the responsible AD. I'm following this WG because > I'm interested in it, but I am not the one managing its chairs: Pete > is. Hmmm. Maybe not. There's a nuance of formal concern here that might not make that such a wonderful idea: The non-cognizant AD is part of the IESG and hence is in the next level in the appeal chain, above the cognizant AD. If the non-cognizant AD has been consulting on the problem, they are not such a neutral participant in the IESG review. Personally, I'd rather have the second APPS AD stay available for the IESG process. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Thu Sep 13 15:36:24 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7D321F866D for ; Thu, 13 Sep 2012 15:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSxIjxIOa2U9 for ; Thu, 13 Sep 2012 15:36:23 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CE00321F866C for ; Thu, 13 Sep 2012 15:36:23 -0700 (PDT) Received: from [192.168.1.8] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8DMaMue004637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Sep 2012 15:36:23 -0700 Message-ID: <50525FE3.4030200@dcrocker.net> Date: Thu, 13 Sep 2012 15:36:19 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Scott Kitterman References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <1367298.7yqF3eMnDC@scott-latitude-e6320> <505256A3.5040704@dcrocker.net> <1516105.Uvc9vP9JZz@scott-latitude-e6320> In-Reply-To: <1516105.Uvc9vP9JZz@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 13 Sep 2012 15:36:23 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 22:36:24 -0000 On 9/13/2012 3:09 PM, Scott Kitterman wrote: >> Well, it's certainly important to ask why it is important to have two >> different output values, if their semantics are the same. > > There are a number of places where SPF semantics are more verbose than they > might be. If I were designing SPF from scratch, I'd probably combine the "a", > "ip4", and "ip6" mechanisms into one. If we were the SPF3 WG and not SPFbis > I'd probably suggest combining them and I'd think disposing of "neutral" in > favor of "none" was worth discussing. Let's see whether I have a particular bit of understanding correct: I think that the items you cite are part of the /internal/ SPF evaluation mechanism, rather than part of its semantic /output/. (For the moment, I'm ignoring the details of what might be listed in logging output.) >> My impression is that it is considered useful to keep the separate >> values. Hence I think our job is to define the semantics in two parts. >> Perhaps one is authorization semantics; with the other being logging >> "semantics", if that distinction works for folk. > > It is a useful distinction for forensics, but not normal operations, so your > suggestion makes conceptual sense. My suspicion is trying to describe it that > way will be more confusing than what we have now, but I'm certainly glad to > explore to concept if you have ideas about how to characterize it. What we have now is a tendency to confuse internal processing versus formal output. That strikes me as inherently worse than merely needing to refine the definition of the latter... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From barryleiba@gmail.com Thu Sep 13 15:47:42 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCE021F84A0 for ; Thu, 13 Sep 2012 15:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.955 X-Spam-Level: X-Spam-Status: No, score=-102.955 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXd7QWUZoG6Q for ; Thu, 13 Sep 2012 15:47:42 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF1B321F849B for ; Thu, 13 Sep 2012 15:47:41 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so4635111vbb.31 for ; Thu, 13 Sep 2012 15:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Z/yzh94cJCKpdmP5HicZpCGY3RbCPlE2qkP1SNVWpVg=; b=VBFmILEzJtFZWNUb7W5Y+fZIbPYpum6RC14rtlnLRuzsd3FuE3eGClrMxDhwY0XL/W z6HFjnqtFqr4e0E6LevFD1eC2U/75jRLRjSF5bnp2pF40M5x9jInUr3r51HZFKn93e75 VBPSZ7MRf08Wzgs45MhrpZOrfWv1db+jGvOmHajlhPMzMm3UAVNFbh2YsArTZbjLBvPR x2zOovfJ7eVarqGO3z/sjxjGA/Qm6/6CJElUqod7ZB1kf80urzWjHq73fZOa86H/Q0lF Bqbg0LGF1XUho+3Y7xFr4CF/5j0rF+t+6/BsIgQo/Z6zV+yk/WfD2dLgqUMAkAxpoRW+ 2hCQ== MIME-Version: 1.0 Received: by 10.52.38.65 with SMTP id e1mr354567vdk.110.1347576461187; Thu, 13 Sep 2012 15:47:41 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.58.41 with HTTP; Thu, 13 Sep 2012 15:47:41 -0700 (PDT) In-Reply-To: <50525F53.3090006@dcrocker.net> References: <6.2.5.6.2.20120912135850.0a591fb0@elandnews.com> <50511484.2010009@isdg.net> <6.2.5.6.2.20120912160527.0a5a83e0@elandnews.com> <505131E2.5020906@isdg.net> <50522C52.1060701@qualcomm.com> <50525F53.3090006@dcrocker.net> Date: Thu, 13 Sep 2012 18:47:41 -0400 X-Google-Sender-Auth: dqDEG5fSk72pixEUl8XrV9lpAoQ Message-ID: From: Barry Leiba To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Seeking AD clarification on what should be DISCUSSED in this WG X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 13 Sep 2012 22:47:42 -0000 > Hmmm. Maybe not. Well, of course, you clipped my second paragraph. > The non-cognizant AD is part of the IESG and hence is in the next level > in the appeal chain, above the cognizant AD. If the non-cognizant AD has > been consulting on the problem, they are not such a neutral participant in > the IESG review. > > Personally, I'd rather have the second APPS AD stay available for the > IESG process. Indeed. That's also part of what I was getting at. Thanks for bringing it up specifically. Barry From dhc@dcrocker.net Thu Sep 13 15:51:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7D021F86B5 for ; Thu, 13 Sep 2012 15:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NY9k2DlrvUcC for ; Thu, 13 Sep 2012 15:51:57 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B0B2C21F86B4 for ; Thu, 13 Sep 2012 15:51:57 -0700 (PDT) Received: from [192.168.1.8] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8DMpceu004979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Sep 2012 15:51:38 -0700 Message-ID: <50526377.1030905@dcrocker.net> Date: Thu, 13 Sep 2012 15:51:35 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Barry Leiba References: <6.2.5.6.2.20120912135850.0a591fb0@elandnews.com> <50511484.2010009@isdg.net> <6.2.5.6.2.20120912160527.0a5a83e0@elandnews.com> <505131E2.5020906@isdg.net> <50522C52.1060701@qualcomm.com> <50525F53.3090006@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 13 Sep 2012 15:51:38 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] Seeking AD clarification on what should be DISCUSSED in this WG X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 22:51:58 -0000 On 9/13/2012 3:47 PM, Barry Leiba wrote: >> Personally, I'd rather have the second APPS AD stay available for the >> IESG process. > > Indeed. That's also part of what I was getting at. Thanks for > bringing it up specifically. no. no. this horse isn't dead yet. but wait, maybe this will do it... you didn't actually say anything about being preempted in process terms and your opening sentence made the later points rather more marginal and, I think, missed the formal process concern that I focused on. (putting the shovel away.) there. fully buried. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From agthisell@yahoo.com Thu Sep 13 18:13:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA1E21F8694 for ; Thu, 13 Sep 2012 18:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoApQ8TwuE1O for ; Thu, 13 Sep 2012 18:13:44 -0700 (PDT) Received: from nm10-vm3.bullet.mail.ne1.yahoo.com (nm10-vm3.bullet.mail.ne1.yahoo.com [98.138.91.140]) by ietfa.amsl.com (Postfix) with SMTP id 3607F21F869F for ; Thu, 13 Sep 2012 18:13:44 -0700 (PDT) Received: from [98.138.90.53] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 14 Sep 2012 01:13:40 -0000 Received: from [98.138.88.234] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 14 Sep 2012 01:13:40 -0000 Received: from [127.0.0.1] by omp1034.mail.ne1.yahoo.com with NNFMP; 14 Sep 2012 01:13:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 454078.5315.bm@omp1034.mail.ne1.yahoo.com Received: (qmail 13892 invoked by uid 60001); 14 Sep 2012 01:13:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347585220; bh=Cy0S7/EVq27eWxSw38T8Lr12lKQoDxGp0RJUx4ZJIgU=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=SmfN3gvPuF/Man3sr9Pn14sBX+rn/0hT9Nofb/aw4Vad8i6Sxl78Y84+UCc5XIl1itMslmEXW+2eT3YIAcBzRl7eg+17FQ7jCJXpFsJeioWUUwpehrV6C3fIAUjGxY1TjXgUQeHuIzbXjJQbeFH5jW9qYIOq84O/9ELQ6D/0Qvg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=6XR/XwMXzlfewehCv0jUStJqVYeDAk5GiQNN3R3u5k1ZWODfz8f/S8/rrTR7gfNP8qxHrCo8JDNTgZCNHVWoIcPnZ2Zi8HzCGzuMRFIDyPbY2BS/R5M7sXdDWJYdd/8sqP1eX/feAielU7FNHC20bcklXkIox7brRcEOO3U+If4=; X-YMail-OSG: 6cVSaSgVM1nfcf1cRNp0G4GtG1i6tfcXo5fDqJL6gtgi_35 biI_y6stBbcJO7sA5OsXDQ13oEJOGTCtIJROf4i2g6JcuQJStbHPGWQwUGEh .k.AA4w4O9xh1JXJC2ZdzeKJFeq9BTWfbIhZ_WBUFCTZBzFhNx_Rj8ltTLll 5qLn_GvE67YAoafrenB9KglsKv.sWlpqCe6wV9lgfOUpMTA.7eF3WWnTEeb8 yUcYron9dA7wkMBBNMSeqtZK6C221y5ajHMoj5GoKuUGV9U.KIXDoI9jdzZ0 27doC3GlddYuXrcB1K2kUjYzJp9RDcydBzuQ3CVTAUGYuyHbG9lMd5DMnamY wcEc_ct8daMrogfsIIQX9PVQAKXAvvNC8DQIJJQso.zS5C4PGOlHQtES90Mg KrFaA23xXTe7cMwz5aXvxuPNRolXLMo7u.JEZB9qx0QzYPtx8Lqvna_9_uhf 085pKiLsszcnJPMUfmd0- Received: from [71.61.133.134] by web125103.mail.ne1.yahoo.com via HTTP; Thu, 13 Sep 2012 18:13:40 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347585220.39525.YahooMailClassic@web125103.mail.ne1.yahoo.com> Date: Thu, 13 Sep 2012 18:13:40 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 01:13:45 -0000 > A "Neutral" result MUST be treated exactly like the "None" result; Your daily history lesson: the SPF spec started as more of documentation for Meng Weng Wong's perl script, than vice versa. Sometimes running code is great, other times, not so much. The distinction between neutral and none is important for the best-guess system. If an evaluation of check_host(ip,domain,sender) returned neutral, then that was the result. If the result was none, then you called best guess. So, the spec has always been a lie, neutral wasn't treated exactly like none, the distinction was only not for informational purposes. And, no, I don't think the RFC should even mention best-guess. If I was writing SPF v3, I would just return a neutral result, and leave the rest up to diagnostic tools. Diagnostic tools can do a much better job of realizing that you didn't put the SPF record in the right place, or that "v=spf1a mx -all" isn't a valid record. Now, after some pondering, I do think we can get rid of the MUST, and say: ADMDs expect "neutral" to be treated exactly like "none", the distinction exists only for aiding in diagnosing SPF problems. While it is true that people can be pushed away from SPF if neutral is treated more harshly than none, I think SPF deployment is beyond the point where this is really critical. With ~70% deployment, people must be seeing a reasonable benefit to deploying SPF records, despite people treating neutral worse. And, any receiver that treats neutral much worse than none is almost certainly hurting themselves. *shrug* OK, there is a second local policy item that I know of. In the definition of softfail, it says A "softfail" result ought to be treated as somewhere between "fail" and "neutral"/"none". The domain owner believes the host is not authorized but is not willing to make a strong policy statement. Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal. Again, I think this is best rephrased as what the ADMD expects, e.g.: A "softfail" result says that the ADMD would like the result treated somewhere between "fail" and "neutral"/"none". The domain owner believes the host is not authorized but is not willing to make a strong policy statement. SPF verifies that treat "softfail" results as harshly as a "fail" can cause ADMDs not to publish such a strict SPF policy, or not to publish an SPF record at all. *shrug* I don't see this as that important of an issue, nothing is going to change what people actually do anyway. From spf2@kitterman.com Thu Sep 13 20:13:34 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E810C21F865E for ; Thu, 13 Sep 2012 20:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t33OxGjh+w2q for ; Thu, 13 Sep 2012 20:13:33 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EFFA021F8658 for ; Thu, 13 Sep 2012 20:13:32 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B1CDA20E40A6; Thu, 13 Sep 2012 23:13:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347592411; bh=qSnQfkG9TjKmesmjaGq91qHcG7Cg/HO7fjJDILjmgfk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=dPos97CtOGESiWJv1XTnkfn2GBPSb7r6+wrl+KqbJJrasnIHOZ6RgbZdYuD0ga1Hd LsTLD4mPwNdEWoLL3CiXDhf3SeEwVztn1qG2bVpeOHUnqKgbxTpsQLkJenOCS05dLd dFL1QMPvhSU10Nh8zNO5RLIyrDWELNm+vffUZM5k= 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 84F5D20E409A; Thu, 13 Sep 2012 23:13:31 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 13 Sep 2012 23:13:30 -0400 Message-ID: <2780518.1J1JaFnuYy@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <50525FE3.4030200@dcrocker.net> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <1516105.Uvc9vP9JZz@scott-latitude-e6320> <50525FE3.4030200@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 03:13:34 -0000 On Thursday, September 13, 2012 03:36:19 PM Dave Crocker wrote: > On 9/13/2012 3:09 PM, Scott Kitterman wrote: > >> Well, it's certainly important to ask why it is important to have two > >> different output values, if their semantics are the same. > > > > There are a number of places where SPF semantics are more verbose than > > they > > might be. If I were designing SPF from scratch, I'd probably combine the > > "a", "ip4", and "ip6" mechanisms into one. If we were the SPF3 WG and > > not SPFbis I'd probably suggest combining them and I'd think disposing of > > "neutral" in favor of "none" was worth discussing. > > Let's see whether I have a particular bit of understanding correct: > > I think that the items you cite are part of the /internal/ SPF > evaluation mechanism, rather than part of its semantic /output/. (For > the moment, I'm ignoring the details of what might be listed in logging > output.) Yes, but it's an example of more semantic variation than is strictly needed. > >> My impression is that it is considered useful to keep the separate > >> values. Hence I think our job is to define the semantics in two parts. > >> > >> Perhaps one is authorization semantics; with the other being logging > >> > >> "semantics", if that distinction works for folk. > > > > It is a useful distinction for forensics, but not normal operations, so > > your suggestion makes conceptual sense. My suspicion is trying to > > describe it that way will be more confusing than what we have now, but > > I'm certainly glad to explore to concept if you have ideas about how to > > characterize it. > What we have now is a tendency to confuse internal processing versus > formal output. That strikes me as inherently worse than merely needing > to refine the definition of the latter... I think part of what we have is a disagreement about how to draw the boundary around the edge of SPF. To say it's confusion implies one perspective is right and the other is wrong. I think it's more productive to characterize it as a disagreement. If I were to draw the line at a point that says that the SPF result is the end of the SPF protocol, then I would argue that the distinction between neutral and none is a piece of internal SPF structure that happens to leak into the outside world. To translate this into software terms, sometimes bits of private API leak into public view and it's appropriate to document that it's not appropriate to rely on that private API. Ideally we'd fix the bug, but there's no way to do it without breaking the ABI so we're stuck with the bug until we can do an ABI break. Programmers exploit private API that is incidentally visible, but when that breaks their software later, they get no sympathy from the library author. Scott K From spf2@kitterman.com Thu Sep 13 20:23:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D579B21F8624 for ; Thu, 13 Sep 2012 20:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySqcJRuFBS8o for ; Thu, 13 Sep 2012 20:23:45 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id C3CBE21F860B for ; Thu, 13 Sep 2012 20:23:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2EEBA20E40A6; Thu, 13 Sep 2012 23:23:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347593024; bh=+UjqeFlNCcbVR6VaoSY36O2p1meShwG5H4IiSyoqgxc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UPxQ110kRAqHs6MCnB0+Mnj6GcKVkm21X7viasFM6o7iLj8j3ZeSbQKhzkuIsNKO6 rqtfcna2YlmNTs6blFemYzHdMaXXp/1esEXgJMnVg/m1XYK0bokMGDxc2RCEwiqB1I RVGiN4xKP6i022GHFF0jSfgOLnIxfosbra9gq8ME= 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 F391E20E409A; Thu, 13 Sep 2012 23:23:43 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 13 Sep 2012 23:23:43 -0400 Message-ID: <3099891.9NrGQvIzIZ@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <1347585220.39525.YahooMailClassic@web125103.mail.ne1.yahoo.com> References: <1347585220.39525.YahooMailClassic@web125103.mail.ne1.yahoo.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] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 03:23:45 -0000 On Thursday, September 13, 2012 06:13:40 PM Arthur Thisell wrote: > > A "Neutral" result MUST be treated exactly like the "None" result; > > Your daily history lesson: the SPF spec started as more of documentation > for Meng Weng Wong's perl script, than vice versa. Sometimes running code > is great, other times, not so much. > > The distinction between neutral and none is important for the best-guess > system. If an evaluation of check_host(ip,domain,sender) returned neutral, > then that was the result. If the result was none, then you called best > guess. So, the spec has always been a lie, neutral wasn't treated exactly > like none, the distinction was only not for informational purposes. And, > no, I don't think the RFC should even mention best-guess. The spec wasn't a lie. Meng just had a poor Perl script. Even pyspf, which started life as a very faithful reimplementation of Mail::SPF::Query in Python has a best guess function hidden in it, but you have to try really hard to get it to do anything. Best guess may have been a reasonable bootstrap mechanism for the protocol, but I agree, it's time is long past. > If I was writing SPF v3, I would just return a neutral result, and leave the > rest up to diagnostic tools. Diagnostic tools can do a much better job of > realizing that you didn't put the SPF record in the right place, or that > "v=spf1a mx -all" isn't a valid record. > > Now, after some pondering, I do think we can get rid of the MUST, and say: > > ADMDs expect "neutral" to be treated exactly like "none", the > distinction exists only for aiding in diagnosing SPF problems. > > While it is true that people can be pushed away from SPF if neutral is > treated more harshly than none, I think SPF deployment is beyond the point > where this is really critical. With ~70% deployment, people must be seeing > a reasonable benefit to deploying SPF records, despite people treating > neutral worse. And, any receiver that treats neutral much worse than none > is almost certainly hurting themselves. > > *shrug* Shortly after RFC 4408 was published, I saw a lot of evidence of people treating neutral different than none. It seems, AFAICT, to have largely died out. What I do see people doing is treating the combination of mail from aol.com and neutral more negatively than they treat SPF none or SPF none from an unknown domain. To me that's part of a higher level process and exactly the kind of thing 4408bis has no business getting involved in. I agree it could be reworded without great harm, but I don't see why it should be changed. Every time we change something in 4408bis from what's in RFC 4408 we have created an opportunity for an implementer that's reviewing the new RFC to update their implementation to be confused. In general, I think the changes we've made have been improvements that added enough benefit to be worth that cost, but I don't think this qualifies at all. > OK, there is a second local policy item that I know of. In the definition > of softfail, it says > > A "softfail" result ought to be treated as somewhere between "fail" > and "neutral"/"none". The domain owner believes the host is not > authorized but is not willing to make a strong policy statement. > Receiving software SHOULD NOT reject the message based solely on this > result, but MAY subject the message to closer scrutiny than normal. > > Again, I think this is best rephrased as what the ADMD expects, e.g.: > > A "softfail" result says that the ADMD would like the result treated > somewhere between "fail" and "neutral"/"none". The domain owner > believes the host is not authorized but is not willing to make a > strong policy statement. SPF verifies that treat "softfail" results > as harshly as a "fail" can cause ADMDs not to publish such a strict > SPF policy, or not to publish an SPF record at all. > > *shrug* > > I don't see this as that important of an issue, nothing is going to change > what people actually do anyway. Softfail is somewhat like DKIM testing, IMO. Here's what RFC 6376 has to say about that: y This domain is testing DKIM. Verifiers MUST NOT treat messages from Signers in testing mode differently from unsigned email, even should the signature fail to verify. Verifiers MAY wish to track testing mode results to assist the Signer. Hey, it turns out that the great DKIM design that was so wonderfully done has just about as much local policy in it as RFC 4408 does. I wish we'd quit rewriting stuff to rewrite it and focus on actual issues that need to be resolved. Scott K From dhc@dcrocker.net Thu Sep 13 21:40:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B29921F86BA for ; Thu, 13 Sep 2012 21:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAsxNDF-o8Ww for ; Thu, 13 Sep 2012 21:40:02 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8F221F86C1 for ; Thu, 13 Sep 2012 21:40:02 -0700 (PDT) Received: from [192.168.1.8] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8E4dxW5009457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Sep 2012 21:40:00 -0700 Message-ID: <5052B518.2080104@dcrocker.net> Date: Thu, 13 Sep 2012 21:39:52 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Scott Kitterman References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <1516105.Uvc9vP9JZz@scott-latitude-e6320> <50525FE3.4030200@dcrocker.net> <2780518.1J1JaFnuYy@scott-latitude-e6320> In-Reply-To: <2780518.1J1JaFnuYy@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 13 Sep 2012 21:40:01 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 04:40:03 -0000 On 9/13/2012 8:13 PM, Scott Kitterman wrote: >> Let's see whether I have a particular bit of understanding correct: >> >> I think that the items you cite are part of the /internal/ SPF >> evaluation mechanism, rather than part of its semantic /output/. (For >> the moment, I'm ignoring the details of what might be listed in logging >> output.) > > Yes, but it's an example of more semantic variation than is strictly needed. Maybe. Maybe not. It's clearly necessary to have a core of semantic output that is the 'reason' for having SPF. This is the check_host() result. It is often helpful to facilitate debugging and forensics, especially in distributed systems which often are notoriously difficult to diagnose. So adding formal "semantics" to help this goal, but that are distinct for the core semantics is also reasonable. Hence I don't see this as semantic 'variation' as two streams of semantics. One for functional benefit. The other for operational benefit. >> What we have now is a tendency to confuse internal processing versus >> formal output. That strikes me as inherently worse than merely needing >> to refine the definition of the latter... > > I think part of what we have is a disagreement about how to draw the boundary > around the edge of SPF. To say it's confusion implies one perspective is > right and the other is wrong. I think it's more productive to characterize it > as a disagreement. A constructive debate can move the boundaries around. I might prefer them in one configuration; you another. Both of us might have good reasons. The debate produces consensus on a single, common configuration for the boundaries. Saying 'right' or 'wrong' in such a debate is typically counter-productive. A different issue is our not sharing the same model, so that my comments don't even have the same meaning as yours. At that point, it's not that your comments or mine are wrong, but that our failure to share the same model is what's wrong. Anyhow, I put forward a drawing that shows some lines and broadly explained why. If folk want to claim the diagram should look different, have at it and let's discuss it. > If I were to draw the line at a point that says that the SPF result is the end > of the SPF protocol, then I would argue that the distinction between neutral > and none is a piece of internal SPF structure that happens to leak into the > outside world. Well, I thought I was (merely) characterizing existing practice, especially since that's what the wg is supposed to do, except for fixing problems. This might qualify as involving a problem, but I haven't seen claims about that. Anyhow, as I say, if someone wants to propose a different diagram, let's see it and talk about it. > To translate this into software terms, sometimes bits of private API leak into > public view and it's appropriate to document that it's not appropriate to rely > on that private API. Ideally we'd fix the bug, but there's no way to do it > without breaking the ABI so we're stuck with the bug until we can do an ABI > break. Programmers exploit private API that is incidentally visible, but when > that breaks their software later, they get no sympathy from the library > author. As an abstract comment, sure. In terms of the current topic, I'm not sure what to do with what you've said. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Thu Sep 13 21:48:32 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052D421F84F0 for ; Thu, 13 Sep 2012 21:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwwnmUhembTV for ; Thu, 13 Sep 2012 21:48:31 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 18C4121F84D2 for ; Thu, 13 Sep 2012 21:48:31 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0CC9F20E409A; Fri, 14 Sep 2012 00:48:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347598110; bh=qAynmbJUja8a1sXyHh3hDJlvMf01bIcaoyC+BC0fnFY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RF3TDTGcIFt58hXQfRd8j6sFmsCD9lMZDW12NhHsZi88AqMc0gIhwggzvw7iDg4hX +O8zFz3sXoFNMashUCPZrs4pXbVv33lWa/+iPX0jH3yefsiDbPBR1f4+dDx+Vk1PYr u3hlE+hck48YNMbi7cUtJFvyKNKVlrbhw/nYmJoA= 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 ADFD320E4071; Fri, 14 Sep 2012 00:48:29 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 14 Sep 2012 00:48:28 -0400 Message-ID: <7975930.eGZpozudqC@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <5052B518.2080104@dcrocker.net> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <2780518.1J1JaFnuYy@scott-latitude-e6320> <5052B518.2080104@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 04:48:32 -0000 On Thursday, September 13, 2012 09:39:52 PM Dave Crocker wrote: > On 9/13/2012 8:13 PM, Scott Kitterman wrote: > >> Let's see whether I have a particular bit of understanding correct: > >> I think that the items you cite are part of the /internal/ SPF > >> > >> evaluation mechanism, rather than part of its semantic /output/. (For > >> the moment, I'm ignoring the details of what might be listed in logging > >> output.) > > > > Yes, but it's an example of more semantic variation than is strictly > > needed. > Maybe. Maybe not. > > It's clearly necessary to have a core of semantic output that is the > 'reason' for having SPF. This is the check_host() result. > > It is often helpful to facilitate debugging and forensics, especially in > distributed systems which often are notoriously difficult to diagnose. > So adding formal "semantics" to help this goal, but that are distinct > for the core semantics is also reasonable. > > Hence I don't see this as semantic 'variation' as two streams of > semantics. One for functional benefit. The other for operational benefit. > > >> What we have now is a tendency to confuse internal processing versus > >> formal output. That strikes me as inherently worse than merely needing > >> to refine the definition of the latter... > > > > I think part of what we have is a disagreement about how to draw the > > boundary around the edge of SPF. To say it's confusion implies one > > perspective is right and the other is wrong. I think it's more > > productive to characterize it as a disagreement. > > A constructive debate can move the boundaries around. I might prefer > them in one configuration; you another. Both of us might have good > reasons. The debate produces consensus on a single, common > configuration for the boundaries. Saying 'right' or 'wrong' in such a > debate is typically counter-productive. > > A different issue is our not sharing the same model, so that my comments > don't even have the same meaning as yours. At that point, it's not that > your comments or mine are wrong, but that our failure to share the same > model is what's wrong. > > Anyhow, I put forward a drawing that shows some lines and broadly > explained why. If folk want to claim the diagram should look different, > have at it and let's discuss it. > > > If I were to draw the line at a point that says that the SPF result is the > > end of the SPF protocol, then I would argue that the distinction between > > neutral and none is a piece of internal SPF structure that happens to > > leak into the outside world. > > Well, I thought I was (merely) characterizing existing practice, > especially since that's what the wg is supposed to do, except for fixing > problems. This might qualify as involving a problem, but I haven't seen > claims about that. > > Anyhow, as I say, if someone wants to propose a different diagram, let's > see it and talk about it. > > > To translate this into software terms, sometimes bits of private API leak > > into public view and it's appropriate to document that it's not > > appropriate to rely on that private API. Ideally we'd fix the bug, but > > there's no way to do it without breaking the ABI so we're stuck with the > > bug until we can do an ABI break. Programmers exploit private API that > > is incidentally visible, but when that breaks their software later, they > > get no sympathy from the library author. > > As an abstract comment, sure. In terms of the current topic, I'm not > sure what to do with what you've said. The analogy I'm trying to draw here is that the neutral/none is conceptually similar to a piece of internal API that happens to be visible. External entities ought not be using it and it is entirely appropriate to document that in strong terms. Scott K From agthisell@yahoo.com Thu Sep 13 22:55:18 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D43121F8722 for ; Thu, 13 Sep 2012 22:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6y+UTgMJbIDe for ; Thu, 13 Sep 2012 22:55:17 -0700 (PDT) Received: from nm33-vm7.bullet.mail.ne1.yahoo.com (nm33-vm7.bullet.mail.ne1.yahoo.com [98.138.229.71]) by ietfa.amsl.com (Postfix) with SMTP id 84BD421F8720 for ; Thu, 13 Sep 2012 22:55:17 -0700 (PDT) Received: from [98.138.90.56] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 14 Sep 2012 05:55:10 -0000 Received: from [98.138.89.171] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 14 Sep 2012 05:55:10 -0000 Received: from [127.0.0.1] by omp1027.mail.ne1.yahoo.com with NNFMP; 14 Sep 2012 05:55:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 907085.90067.bm@omp1027.mail.ne1.yahoo.com Received: (qmail 92041 invoked by uid 60001); 14 Sep 2012 05:55:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347602110; bh=IHJp0z80fXWXigBzJuagA1i7oGK+mpwIddxJm1/cfY8=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=Jh5TYNMCga/HrdGpoI5rGuejvw2QTH4sVaNvDluQVyX4t3tGJyCDwEWk9gPIXebbpne6az8878apMdZtpCA1d3q1Jb0Qrrzt+zOkHqSB+N6Z7A3U+hoPJADqlcp0CJBW3wWa7EfNCfZVQi0dcnMhkZnS3YW0P72VoY4HJv8qX8Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=cK1VK0uuVtJ8ffZQSgaicEkBB1PnmK5UkeKNPqIqBtGGaCbCXBUHg9pbvUQAstS4DDudi7e7lESd1fV5oxJCSrfXNlninHTZ5KRs1pOlYNYF6hODC5bkKLLtUwLiKSCFo03qsIuTR8qdLRo57uy5TjPPFOPKd0QseW9csLxnmns=; X-YMail-OSG: VZXkTJkVM1mhTj7JNpE8fjl.lnNnEa8.oy6yVnI5X434DCg UUuJ7Gmo2g0gPoYQ4uKlgs4TsS58RdGe7jFRmG46EeaEJ49rXQNAQRrMV4aZ A5uD5d1qG8uVS9djwoiDxKNTHnEUcyxl9v.B6S8Y0yLuxdeeaqktEyCR02nd H_qBbfoimT_b9j8KQLuXThFToZI_xo3CBrCSP6rZW9VUuTDaL0BEhQUEad8h 54ZGC7swMVRQ4g3rispD6c84d3VLy.YK1MTri.wVkYwfZzSEx2N2gmDsCiCI wjpPnmr_kpCLoxbiDeJrg5JQxbgHLcKQtJR_4UzQg3bVje43opBnq.VQG.TM .42SyVTjIxlBWScVnpC5qThjKqDGmhZMb2eSEQGLSeH9i8fen1a4XFFmjI6r ENVv5QtWdIYx2J3ZpUTONk23xneokFXbFR1ZSCJCHZeq3VPC0KeAxsLncwvB 0oDzUYrvEz52pAVvVR24- Received: from [71.61.133.134] by web125106.mail.ne1.yahoo.com via HTTP; Thu, 13 Sep 2012 22:55:10 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347602110.91658.YahooMailClassic@web125106.mail.ne1.yahoo.com> Date: Thu, 13 Sep 2012 22:55:10 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] general changes to RFC 4408 (was: #58: Local policy in 4408bis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 05:55:18 -0000 > I agree it could be reworded without great harm, but I don't see why it should > be changed. Every time we change something in 4408bis from what's in RFC 4408 > we have created an opportunity for an implementer that's reviewing the new RFC > to update their implementation to be confused. strongly agreed. > I wish we'd quit rewriting stuff to rewrite it and focus on actual issues that > need to be resolved. This too. There seems to be too many changes from RFC 4408 for the sake of changes. From superuser@gmail.com Thu Sep 13 23:28:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD7E21F85F3 for ; Thu, 13 Sep 2012 23:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lWmKDSIJ7Jh for ; Thu, 13 Sep 2012 23:28:21 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7A321F85F0 for ; Thu, 13 Sep 2012 23:28:20 -0700 (PDT) Received: by lbky2 with SMTP id y2so2683876lbk.31 for ; Thu, 13 Sep 2012 23:28: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=OB84s6lLcICumOZoXNywbwbHWo7a8zuj8o4dQtg8DFA=; b=PnlTZtoxZkj/HCMM5/GR9nAQA8chjaMArY8LbwyECHzS5edg/2AuXXY5ch1vejRBmP Q9B/4ApSveAfjmmzGQKLHlMvA66EUdN8ff+y/bUcmf91ImdI+f6sDL/IKXegisJwPwDJ qb1aBQYgJawGYgSpgFrepq9zWfBSlm+KKBxxV8oi1EXEshY9E5q25M31iQluxkkb0jc4 SL8+mCnYxqh+GpF7vnlm4kodaOnHhC3mpHVf+fK6WevGRQRcul0f9L4C3sLNSUNl5FWz EtOkbrkujLyhm3cAVkB70zqlOlgI515L7mSjl42xudUKQzHmhkDSaAZX0Ca/3CCTOx3X iUYg== MIME-Version: 1.0 Received: by 10.152.46.203 with SMTP id x11mr1336898lam.46.1347604099524; Thu, 13 Sep 2012 23:28:19 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Thu, 13 Sep 2012 23:28:19 -0700 (PDT) In-Reply-To: <1347602110.91658.YahooMailClassic@web125106.mail.ne1.yahoo.com> References: <1347602110.91658.YahooMailClassic@web125106.mail.ne1.yahoo.com> Date: Thu, 13 Sep 2012 23:28:19 -0700 Message-ID: From: "Murray S. Kucherawy" To: Arthur Thisell Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] general changes to RFC 4408 (was: #58: Local policy in 4408bis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 06:28:21 -0000 On Thu, Sep 13, 2012 at 10:55 PM, Arthur Thisell wrote: > There seems to be too many changes from RFC 4408 for the sake of changes. I think this posture is somewhat dismissive of a bigger picture. We've learned a lot since 2006 about a number of things, from how SPF is used to the way these kinds of documents ought to be written. Adapting RFC4408 to better fit either of those concerns doesn't qualify as "for the sake of changes" as far as I can tell. Remember, RFC4408 got through as Experimental which is the IETF's lowest bar. Altering the presentation of the material to make the document more likely to pass Standards Track IESG review is also something we need to undertake, whether or not we find it contrary to the idea of maximum preservation. There's also been a number of changes introduced as compromises to try to satisfy contentious positions. In my experience, that's not an uncommon tactic of working groups, nor is it improper. -MSK From superuser@gmail.com Thu Sep 13 23:29:32 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7778421F85F3 for ; Thu, 13 Sep 2012 23:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amxbxEqSzURT for ; Thu, 13 Sep 2012 23:29:32 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD01221F85F0 for ; Thu, 13 Sep 2012 23:29:31 -0700 (PDT) Received: by lahm15 with SMTP id m15so2627361lah.31 for ; Thu, 13 Sep 2012 23:29:30 -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=JjbRtEZtM4fxu43g+Mcw9fQXT5AB5efWmssnBAT59Pk=; b=h5oAk4GoL2/VUAFjNep8axQ+jc0sAxXH1d07W+RLzrdx+6ebgo+ECJqKKfXPXl5L79 HCDbrcQTUaGlRTxf8L1bjpF+m6vtBa5p13ISQHQZLu+X6Cd9AwDOGIcQlTGjJIhduwWq 3LVOWS8nlfAJV75fgRC36ATJwX52eBvQffqgzwluC2DX3AHulp3UXtQU1PAXD8n7YcfT 3OEc1nP+r2npkrhy5uOke9wFelZvAUsSn6N03qvdQnq1BOlriZs4siT8fGSYqf3NqxQH gsr9W4+Md2R7nk1bGTrtBBbeHmt+q4Q63sRe+wZkEILGXHatmPlMzrr5BeJhabxfsfK5 6xtw== MIME-Version: 1.0 Received: by 10.152.125.116 with SMTP id mp20mr1434256lab.19.1347604170577; Thu, 13 Sep 2012 23:29:30 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Thu, 13 Sep 2012 23:29:30 -0700 (PDT) In-Reply-To: <7975930.eGZpozudqC@scott-latitude-e6320> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <2780518.1J1JaFnuYy@scott-latitude-e6320> <5052B518.2080104@dcrocker.net> <7975930.eGZpozudqC@scott-latitude-e6320> Date: Thu, 13 Sep 2012 23:29:30 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 06:29:32 -0000 On Thu, Sep 13, 2012 at 9:48 PM, Scott Kitterman wrote: > The analogy I'm trying to draw here is that the neutral/none is conceptually > similar to a piece of internal API that happens to be visible. External > entities ought not be using it and it is entirely appropriate to document that > in strong terms. I think that's a fine thing to do, but what the document does now is say that they MUST produce the same outcome without explaining why. A sentence or two that lays out what you're saying here would be a good thing to add. -MSK From W.Doust@racingvictoria.net.au Thu Sep 13 23:43:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD5921F846B for ; Thu, 13 Sep 2012 23:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.409 X-Spam-Level: X-Spam-Status: No, score=-0.409 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_40=-0.185, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzyAdpCkGQ2e for ; Thu, 13 Sep 2012 23:43:45 -0700 (PDT) Received: from bareed.racingvictoria.net.au (bareed.racingvictoria.net.au [202.168.6.132]) by ietfa.amsl.com (Postfix) with ESMTP id 57F5421F842C for ; Thu, 13 Sep 2012 23:43:44 -0700 (PDT) Received: from XCHANGE.rvl.internal (Not Verified[172.16.17.112]) by bareed.racingvictoria.net.au with MailMarshal (v7, 1, 0, 4874) id ; Fri, 14 Sep 2012 16:43:39 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Sep 2012 16:43:30 +1000 Message-ID: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185399@XCHANGE.rvl.internal> In-Reply-To: <3099891.9NrGQvIzIZ@scott-latitude-e6320> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [spfbis] #58: Local policy in 4408bis Thread-Index: Ac2SKF22p1DTaw9nRvO3kIP/0I+fTwAGkpBg References: <1347585220.39525.YahooMailClassic@web125103.mail.ne1.yahoo.com> <3099891.9NrGQvIzIZ@scott-latitude-e6320> From: "Wayne Doust" To: Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 06:43:46 -0000 > Softfail is somewhat like DKIM testing, IMO. Here's what RFC 6376 has to say about that: I would say Neutral is somewhat like DKIM testing. Softfail is for those who either: 1. cannot guarantee mail will not forwarded by a non-SRS destination=20 2. haven't implemented DKIM or DMARC 3. aren't sure if mail is being sent on their behalf from elsewhere (rogue marketing dept for example) Fail is for those who can positively guarantee that IFF a Fail occurs THEN it did not come from us. The standard (but not manadatory) local policy is then: If FAIL: either reject with a 550 or mark and block If SoftFail: treat as greylist OR mark and accept OR both Since local policy is not specified, these are recommended with non-normative language. Regards, Wayne (BTW This is the last day of my contract at this place, so I will be using my gmail address in future) From vesely@tana.it Fri Sep 14 04:13:12 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8360E21F851C for ; Fri, 14 Sep 2012 04:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.648 X-Spam-Level: X-Spam-Status: No, score=-4.648 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRAt5L3tg8TX for ; Fri, 14 Sep 2012 04:13:11 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3389521F8518 for ; Fri, 14 Sep 2012 04:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347621185; bh=/8p/xCiwMOKQ49aX25atyO/YgeLH7LP9wG/KI/JcI5o=; l=4443; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=TXDcdFIiJBbbUMXCNKjvkPtr4McegwhEAW8kW5Pa4eop3upSBalW1MrKEgBZSCFKc JdBxjfxnFyg5wDxE9DIaRQc8oLVNV/vFwg72PfZSuzbBNL74EvzpJl32WL/sQjAf8Y 9GwUtSSYYzClOxI0atDxTmuWq5FEyj/rClQwyz38= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 14 Sep 2012 13:13:05 +0200 id 00000000005DC047.0000000050531141.0000571A Message-ID: <50531141.2020306@tana.it> Date: Fri, 14 Sep 2012 13:13:05 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <201209122251.02375.spf2@kitterman.com> <505244D9.8050108@dcrocker.net> In-Reply-To: <505244D9.8050108@dcrocker.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 11:13:12 -0000 On Thu 13/Sep/2012 22:40:57 +0200 Dave Crocker wrote: > I suggest a variant for SPF: > > (you need a fixed-width font for this, of course...) > > > +------+------+ +------+------+ > | Author | | Recipient | > +------+------+ +------+------+ > | ^ > V | > +-------------+ +------+------+ > | Responsible |... -->| Handling |<-- > | Identity | . -->| Filter |<-- > +------+------+ . +-------------+ > | . ^ > | . | > | . +------+------+ > | . ++=====================| Identity |==++ > | +........................>| Assessor | || > | || Authorization +-------------+ || > | || Identifier ^ ^ || > V || | | || > ++=====================++ ++======| |========++ > || +------+------+ +-------------+ || | | +-----------+ > || | Sending | | Identifier +--||------+ +--+ Assessment| > || | Host +-------->| Validator | || | Databases | > || +-------------+ +-------------+ || +-----------+ > || SPF Service || > ++==========================================++ I'm having some difficulties with that diagram, probably because ASCII art isn't so readable as it would be desired. I view SPF as follows, more or less: +------------+ +------------+ +------------+ | Author or | | Sending | <-->| Handling |<-- | Forwarder | | Host | <-->| Filter, Etc|<--+ +-----+------+ +-----+------+ +------------+ | | | ^ | V V | | +-----------+ +-----------+ ++=========|=============|=====++ | MAIL FROM | | HELO | || | | || | Identity | | Identity | || +-----+--------+ | || +-----------+ +-----------+ || | Local Policy | | || | | || +--------------+ | || | | || ^ ^ | || ++ =======|===============|==========++ | | | || || | | | | | || || V V | | | || || +----------------------------+ +-----+-----+ | | || || | SPF protocol | | SPF | | | || || |(the spec in a strict sense)|------->| Results | | | || || +----------------------------+ +-----------+ | | || || ^ | | || || | | | || || +----------------------------+ +----------------+----+-+ || || | DNS | | Assessment Databases | || || +----------------------------+ +----------------- -----+ || || || || SPF in some broader sense || ++==================================================================++ I'm not a good ASCII artist, but the above has the advantage to locate the local policy, thus adhering to this thread's subject. The box labeled "SPF protocol" would seem to be the check_host() function in a classical De Marco DFD, while the MAIL FROM/ HELO labels, which are semantically part of the SPF protocol, should be on the edges... > I'm going to claim that a receiving host's actions, after obtaining > check_host() output, are always and only a matter of local preference. > SPF cannot dictate any of that behavior. It can explain sender > preferences (or "requests"). It can discuss implications. But it > cannot dictate. > > Simply put, once we are outside of the realm of basic interoperability, > we cannot have one ADMD dictating the behaviors of an independent ADMD. How is "dictate" related to 2119-language? An AS that goes into the meaning of the results has to specify what behaviors an ADMD can request. To do that, it may say that "a receiver MUST/SHOULD do so and so" in order to comply with a given request. The point of separating AS from TS is that a receiver may want to comply with SPF as far as getting the correct result is concerned, but not with the request part. Within a single document, it is impossible to say to which part each 2119 term would be related. I'm not a connoisseur of the historical SPF versions, but all the ones I saw conflate those two parts, and blur the second one. For example, RFC 4408 does not specify how to build and maintain a local assessment database, which is a popular requisite for implementing sensible fail-related behaviors. My perception is that there has never been agreement on the details of local policies. Indeed, the adjective "local" suggests that such policies are the receivers', not the senders' ones --they don't match the P of SPF. Yet, the feeling that receivers must do something strong on "fail" has made it into RFC 4408. IMHO, that's an ambiguous standardization technique that we ought to overcome. We can even standardize a set of multiple behaviors that a receiver may choose from, e.g. mark on fail, reject on fail, classical or enhanced. Or none at all. We just need to know what we wanna do. From spf2@kitterman.com Fri Sep 14 05:24:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330A621F84B5 for ; Fri, 14 Sep 2012 05:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Agrk2tU6Pp1 for ; Fri, 14 Sep 2012 05:24:44 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 30A1621F8503 for ; Fri, 14 Sep 2012 05:24:43 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9A64420E40A6; Fri, 14 Sep 2012 08:24:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347625482; bh=PhmjGCAoh8l2Dax938dLqD/pMPTp2mEF92bt0iRKoYQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=AzSpWvHOtTkRUM0d8gwICGRXAmN6L43ClQL0M95NEQdBCAfu6vt3g9PUqZmscFZQW WtTHOpB5T6X2noc9+OsdCBPSZAKSzxtbQfAVjrB20PW3Kjx5QWzAbgu1JVejyaatzm iJzK44fLghk45z1lmkO26mtTHY5yZ1miE1n29avg= 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 6E10120E4089; Fri, 14 Sep 2012 08:24:41 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 14 Sep 2012 08:24:41 -0400 Message-ID: <1371515.7MF8nNOgi0@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-30-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <505244D9.8050108@dcrocker.net> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <505244D9.8050108@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 12:24:45 -0000 On Thursday, September 13, 2012 01:40:57 PM Dave Crocker wrote: > I suggest a variant for SPF: > > (you need a fixed-width font for this, of course...) > > > +------+------+ +------+------+ > | Author | | Recipient | > +------+------+ +------+------+ > | ^ > V | > +-------------+ +------+------+ > | Responsible |... -->| Handling |<-- > | Identity | . -->| Filter |<-- > +------+------+ . +-------------+ > | . ^ > | . | > | . +------+------+ > | . ++=====================| Identity |==++ > | +........................>| Assessor | || > | || Authorization +-------------+ || > | || Identifier ^ ^ || > V || | | || > ++=====================++ ++======| |========++ > > || +------+------+ +-------------+ || | | +-----------+ > || > || | Sending | | Identifier +--||------+ +--+ Assessment| > || | Host +-------->| Validator | || | Databases | > || > || +-------------+ +-------------+ || +-----------+ > || > || SPF Service || > > ++==========================================++ I'm not an ASCII artist, so I won't try (I'd also suggest that while ASCII art has it's place in RFCs for good reasons, it's generally more efficient to use more modern tools for diagrams to support more ephemeral discussions like this one). >From what I understand of the diagram, it represents one mode of operations, but not the only one. Alternately (and I'm sufficiently convinced I don't follow your terminology that I won't try and associate this with precise elements of your chart), there is a receiving MTA, with a policy component that gives an SPF library a set of inputs, gets an SPF result back, and then makes a policy decision whether or not to reject the mail based on the result. If the mail is rejected, that's the end of the story. As a real world reference, that's pretty precisely how the Postfix policy service works with SPF (and other MTAs have similar approaches). I understand the argument that SPF processing is an input of an email address/host name and an IP address and an output of an SPF result and everything else is cruft. I am not confused. I disagree with that view and so does the document that we've been tasked to update. That doesn't mean we can't change it, but I think it needs more rationale than not liking it that way. SPF does not operate in a vacuum and it's use famously has potential implications for the overall email architecture. A document that limited itself to this narrow scope would be virtually useless to implementers and operators trying to deploy SPF (note: I'm not arguing here that we need a more directive treatment of local policy than was present in RFC 4408 - I don't think we do). When RFC 4408 was being written there were several determined efforts to make it shorter. The topics that are covered are there because it was felt that they were important. Now that we know more, based on more experience, we had additional information that seems important. This is not surprising either. While things can be worded better, I think that generally what's in RFC 4408 is what's needed in RFC 4408bis. Trying too hard to draw a dark solid line about what is/is not SPF and removing/minimizing the things that are not SPF is not gong to result in a better product. I think we should not worry a lot about the page count. Splitting the document in two to reduce the page count doesn't help anything and is, I think, actively harmful to the ultimate customers of this document (not the IESG, the implementers). In a single document, I can be very fine grained about references and pointers so that (particularly in HTML versions of the document) it is easy to follow non-linear narrative when needed. I don't think I can do that into the body of a different document (if I can, someone please help me with the XML and that resolves some of my concerns about splitting). IMO, the group has wandered off into a bunch of minimally productive navel gazing instead of doing the work we were chartered to do. Scott K From ajs@anvilwalrusden.com Fri Sep 14 06:18:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8F121F84F5 for ; Fri, 14 Sep 2012 06:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.576 X-Spam-Level: X-Spam-Status: No, score=-0.576 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIJo8IM2zui6 for ; Fri, 14 Sep 2012 06:18:45 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 826C221F84A5 for ; Fri, 14 Sep 2012 06:18:45 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 2DB8E8A031 for ; Fri, 14 Sep 2012 13:18:44 +0000 (UTC) Date: Fri, 14 Sep 2012 09:18:45 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120914131844.GB91272@mx1.yitter.info> References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <201209122251.02375.spf2@kitterman.com> <505244D9.8050108@dcrocker.net> <50531141.2020306@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50531141.2020306@tana.it> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 13:18:46 -0000 No hat. On Fri, Sep 14, 2012 at 01:13:05PM +0200, Alessandro Vesely wrote: > I'm not a good ASCII artist, but the above has the advantage to locate > the local policy, thus adhering to this thread's subject. But your diagram has the local policy located _inside_ the "SPF in some broader sense" box. It seems to me there are two possibilities here: 1. You want the WG to focus on the narrow sense of SPF, in which case we need an "SPF proper" box on the diagram so we know what we're working on. 2. You want the local policy to be part of the SPF protocol. (2) is not on. The IETF cannot possibly specify local policy _by definition_. That's what it means for there to be local policy. We can say what the boundaries of conformant local policy are, but we can't say what it's going to be. > My perception is that there has never been agreement on the details of > local policies. Indeed, the adjective "local" suggests that such > policies are the receivers', not the senders' ones --they don't match > the P of SPF. Exactly. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From agthisell@yahoo.com Fri Sep 14 06:31:07 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE1221F84F2 for ; Fri, 14 Sep 2012 06:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.723 X-Spam-Level: X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plIg-FaY+3dq for ; Fri, 14 Sep 2012 06:31:06 -0700 (PDT) Received: from nm19.bullet.mail.ne1.yahoo.com (nm19.bullet.mail.ne1.yahoo.com [98.138.90.82]) by ietfa.amsl.com (Postfix) with SMTP id 78C9721F8491 for ; Fri, 14 Sep 2012 06:31:06 -0700 (PDT) Received: from [98.138.226.180] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 14 Sep 2012 13:31:00 -0000 Received: from [98.138.87.8] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 14 Sep 2012 13:31:00 -0000 Received: from [127.0.0.1] by omp1008.mail.ne1.yahoo.com with NNFMP; 14 Sep 2012 13:31:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 708726.56570.bm@omp1008.mail.ne1.yahoo.com Received: (qmail 90896 invoked by uid 60001); 14 Sep 2012 13:31:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347629460; bh=5ksL2/wg0VqRZKXYNPyhRzRQh3ba3upLtt7Hp5E6c6U=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=5wMIBo0LJkx9j57R/KFr7AESonXQifqeGl16GnbrTR5fZeEvl7mNISSLLvGfHmHiLoQBb6Dv0ftLznuJxlKlW08NfDmg45kwP8b2CIuBSbpmsI+lSs4187GUwbkGsZrc0ltNEeuwFjLPNqbhaSEE8M+DTkh4geXA+P78fjtt/5w= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=N864u5syzuQsvgS9p5jhoJBE/GfqN9prIMvwGFGpDw08DJ95FpBivPVh2gtlCdPU8mKsWb5PXHoGbh7gJ59XM8eioD/O0AQj6Y9wxVJ5ggQdEpjQnBrnkktdJUqYyxSv6Cu95o82auqUJzYIO/KFcgg728ds5sN2TDJ59EUA9NY=; X-YMail-OSG: Si_O57IVM1lnomaY38Tg4T6Ja3ClTg0vNw7r.e7QmK_Q079 pYOfW2hhsOtB2Bke2D0fhbFy2ZBzOdVBRV5GwRhF3_dxQrIkUMbHIWJ0wG8R PeNvFuoBWhQBPF51w.0iPoyjY1WRML6rS2jS7wwZH1GYxrvWPquiiSMmZKJw G.rfpZ9Jv1w_tqzQjkoqkmSkbT1XCduq4CZyELe3E3vP7wH02JrnEEbw.vTj dLb.FMEdKVbaz5LWDRIXGezeAu3Sjk9yLMIM1ynqweP5ks4G6TRj3Ap2K.Jz 8aphJnsFu3kPbUKdq9KSLddVtAiUZsiT8KMn1CHjNAENw9gTUchXmsxyY5WT 3Gu7FRahDnaOqOUXD1pdG60tQzBILq4kqNa7yLwq9Z_G4e4jhA1RNgU8JWIg EuxaU0B86gc3IMgdJBMrCs1PuoBCz8zWDbtx0XJt.etry4P.YJdOghC2BSCd wo65WueJvQgFSh5LUleE- Received: from [71.61.133.134] by web125104.mail.ne1.yahoo.com via HTTP; Fri, 14 Sep 2012 06:31:00 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347629460.89993.YahooMailClassic@web125104.mail.ne1.yahoo.com> Date: Fri, 14 Sep 2012 06:31:00 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 13:31:07 -0000 > When RFC 4408 was being written there were several determined efforts to make > it shorter. The topics that are covered are there because it was felt that > they were important. Now that we know more, based on more experience, we had > additional information that seems important. This is not surprising either. RFC 4408 also has a bunch of things that experience has shown that we don't need. There is a bunch of advocacy, how-to text and suggested workarounds for problems that had a little bit of traction back in 2005, but have never caught on. > I think we should not worry a lot about the page count. Splitting the > document in two to reduce the page count doesn't help anything and is, I > think, actively harmful to the ultimate customers of this document (not the > IESG, the implementers). In a single document, I can be very fine grained > about references and pointers so that (particularly in HTML versions of the > document) it is easy to follow non-linear narrative when needed. I agree that, all things being equal, splitting the document hurts since it forces people to pull together several things and splitting adds fluff/wrapping around the content. Sometimes splitting can help by removing/categorizing material, but there is always a cost that has to be overcome. I do think we need to worry about how large the total document is. People have a hard time digesting a lot of information. If something important to the spec is on page 5, it is a lot more likely to be read and understood than an equally important item on page 50. Every word/sentence carries a cost, and just because some point is useful to make, doesn't mean that is is useful enough to justify being included. In some ways, I think RFC 4408 is already too long, and it shows by how much of the new text added to 4408bis was actually already mentioned in 4408. That shows that people did not, or were not able to, read and digest all of RFC4408. If experts like us are not able to do that, how are others going to fare? I'm not sure if advocacy/how-to stuff is ever appropriate for an RFC, but if it is, that is prime material to be shifted to another document. From sm@elandsys.com Fri Sep 14 06:54:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC36021F852D for ; Fri, 14 Sep 2012 06:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGijc10bGR8j for ; Fri, 14 Sep 2012 06:54:22 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EF421F84F6 for ; Fri, 14 Sep 2012 06:54:22 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.223.139]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8EDs6WH003806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Sep 2012 06:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347630860; bh=HPACUVmZT+vP2ShU7LCOGXBGH0PflUwo7fQ7FeTkw4E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=u+gqSYF3NjhU5I4Ltq17aa5HKAd+ew4ebNvfEwvVAuHbc36Uh7CuLHVcIH/tL5Q8+ 0aPtEjBMQOuqtKZyovKY2n7NqZQEnqZntgeJm7JN0VCZKwVZGWjyrCqIN3MxqJ+8g4 WL0m/aWGlkA9+BajxYTOoHVyB8zw8HxL/WyOXoZ0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347630860; i=@elandsys.com; bh=HPACUVmZT+vP2ShU7LCOGXBGH0PflUwo7fQ7FeTkw4E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Iet92hGSMmzG4mVLmYKm613G2BFkV/uJRXk7EIOKO+nWafswInjfvSigxKNr46OXk qA2J9nXec/uTx4ada5vRx6vr/BfxCigMXdOY4q7+yeFaJSI4NXbXvluX6lBFa6qYuc mOe0Z9kzacaNjU0p8Yz+yuNsbMEOgfyA5UB8E954= Message-Id: <6.2.5.6.2.20120914064631.0a3b9eb8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 14 Sep 2012 06:52:20 -0700 To: Arthur Thisell From: S Moonesamy In-Reply-To: <1347629460.89993.YahooMailClassic@web125104.mail.ne1.yahoo .com> References: <1347629460.89993.YahooMailClassic@web125104.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: [spfbis] Advocacy/how-to in RFC 4408 (was: #58: Local policy in 4408bis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 13:54:23 -0000 Hi Arthur, At 06:31 14-09-2012, Arthur Thisell wrote: >I'm not sure if advocacy/how-to stuff is ever appropriate for an >RFC, but if it is, that is prime material to be shifted to another document. Which parts of RFC 4408 could be categorized as advocacy/how-to stuff? Regards, S. Moonesamy From vesely@tana.it Fri Sep 14 08:04:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C15721F8514 for ; Fri, 14 Sep 2012 08:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-PR5hcTXqZW for ; Fri, 14 Sep 2012 08:04:06 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 40AC821F84EA for ; Fri, 14 Sep 2012 08:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347635044; bh=lEP8c0lhehbqtapvTd3yaeMyURE5d+Kn0fVExWqtGX0=; l=1955; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=b6SVnwOShnKtK3GvP3Sfu0l5nPvpQ5QObAdMIwbJBBoQ8TjpV6d0pgfMqlJ6BEMsv E3tzV2o6kShobL95eZ2NnNVsCIMI3I5Wu0PF4sRqc9j0BzFCLG3KUxc1SFQc1KGp0l 0jI5ADwroh/HVBMZfuZh+ALXUpofi8mvFkHA+mwU= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 14 Sep 2012 17:04:04 +0200 id 00000000005DC035.0000000050534764.00000DAC Message-ID: <50534763.6040107@tana.it> Date: Fri, 14 Sep 2012 17:04:03 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: spfbis References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <201209122251.02375.spf2@kitterman.com> <505244D9.8050108@dcrocker.net> <50531141.2020306@tana.it> <20120914131844.GB91272@mx1.yitter.info> In-Reply-To: <20120914131844.GB91272@mx1.yitter.info> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 15:04:08 -0000 On Fri 14/Sep/2012 15:18:45 +0200 Andrew Sullivan wrote: No hat. > On Fri, Sep 14, 2012 at 01:13:05PM +0200, Alessandro Vesely wrote: > >> I'm not a good ASCII artist, but the above has the advantage to locate >> the local policy, thus adhering to this thread's subject. > > But your diagram has the local policy located _inside_ the "SPF in > some broader sense" box. It seems to me there are two possibilities > here: > > 1. You want the WG to focus on the narrow sense of SPF, in which > case we need an "SPF proper" box on the diagram so we know what > we're working on. > > 2. You want the local policy to be part of the SPF protocol. Both, actually. The "SPF proper" is check_host() plus the implied minimal additions, i.e. what the identities are, how to publish records to obtain a given result, and what time and site are recommended for computing results. 4408bis should be polished down to that. The second part could be an ambiguous AS that reflects RFC 4408's hints in a proper language. If we recharter, it can be something that can be used as specified, with a negligible amount of false negatives. Otherwise, it can be written later, by some other WG. > (2) is not on. The IETF cannot possibly specify local policy _by > definition_. That's what it means for there to be local policy. We > can say what the boundaries of conformant local policy are, but we > can't say what it's going to be. I don't fully understand that. Do you mean there is a (IETF-wide) definition of local policy? By "local policy" we mean all the stuff that, although important, is blurred behind that term. What if it were called "requested receiver behavior" instead? >> Indeed, the adjective "local" suggests that such policies are the >> receivers', not the senders' ones --they don't match the P of SPF. > > Exactly. And the term "policy" seems to have been chosen in order to match RFC 5321's policy reasons. From dhc@dcrocker.net Fri Sep 14 08:13:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E77F21F8532 for ; Fri, 14 Sep 2012 08:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F22GcUf-j0RE for ; Fri, 14 Sep 2012 08:13:38 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 33B6E21F852D for ; Fri, 14 Sep 2012 08:13:38 -0700 (PDT) Received: from [192.168.1.8] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8EFDaPc020231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 Sep 2012 08:13:37 -0700 Message-ID: <50534999.2030107@dcrocker.net> Date: Fri, 14 Sep 2012 08:13:29 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Arthur Thisell References: <1347602110.91658.YahooMailClassic@web125106.mail.ne1.yahoo.com> In-Reply-To: <1347602110.91658.YahooMailClassic@web125106.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 14 Sep 2012 08:13:38 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] general changes to RFC 4408 (was: #58: Local policy in 4408bis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 15:13:39 -0000 On 9/13/2012 10:55 PM, Arthur Thisell wrote: >> I agree it could be reworded without great harm, but I don't see why it should >> be changed. Every time we change something in 4408bis from what's in RFC 4408 >> we have created an opportunity for an implementer that's reviewing the new RFC >> to update their implementation to be confused. > > strongly agreed. > >> I wish we'd quit rewriting stuff to rewrite it and focus on actual issues that >> need to be resolved. > > This too. This seems to take the position that more clear, more complete, more precise writing of a specification is not an actual issue. I disagree. Writing matters. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Fri Sep 14 08:14:38 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44D621F8532 for ; Fri, 14 Sep 2012 08:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hx+yjR35qzxo for ; Fri, 14 Sep 2012 08:14:38 -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 13B3121F8514 for ; Fri, 14 Sep 2012 08:14:37 -0700 (PDT) Received: (qmail 37760 invoked from network); 14 Sep 2012 15:14:36 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Sep 2012 15:14:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=505349dc.xn--yuvv84g.k1208; i=johnl@user.iecc.com; bh=FknmnCCkSqVzsWDueH+lWKv92rHxnD8QtC3hsh8jPvY=; b=s0h9L4PmHHWmIKrK8JShndISOqJMteJavEaAT4HMaTjz6lfCYCeomY0fcqYT0fLFLPYhzVM6nY7xRNPh02zW8VLnWXPbTm0H862IOC+vM5M8tDRED4nVFXGXUkTZeHB192fehnBVy3D1TH2rXP61pz1hpPTSWwnrIAYhL6kiLsA= 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:vbr-info; s=505349dc.xn--yuvv84g.k1208; olt=johnl@user.iecc.com; bh=FknmnCCkSqVzsWDueH+lWKv92rHxnD8QtC3hsh8jPvY=; b=rAmtW02E5UoLjs0fKDZD/qjp1OkoJq/rGN5Gkhfaa/u3Sgat9AtQxd1UjAgn+Z/tFJpGZCMSvSrgOeb1yapt1ztUGrbqVPhpiWjljE/b//lD68YMWOcvJTh1RM/MjGtmqizor612AFzPw8BQ4aWNYVCR6askRNBNYTTovD1Pmck= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 14 Sep 2012 15:14:13 -0000 Message-ID: <20120914151413.29558.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185399@XCHANGE.rvl.internal> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: W.Doust@racingvictoria.net.au Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 15:14:39 -0000 We're going in circles here. I'm getting the impression that there's a fundamental lack of understanding about how much control senders have over their mail once it leaves their MTA. >Fail is for those who can positively guarantee that IFF a Fail occurs >THEN it did not come from us. But nobody can make such a guarantee, since there is no way to ensure that your mail won't be delivered via a path that SPF can't describe. As a matter of plain fact, people can and will deliver your real mail to the right recipient via paths you don't authorize, and there's nothing you can do about it. >The standard (but not manadatory) local policy is then: > >If FAIL: either reject with a 550 or mark and block >If SoftFail: treat as greylist OR mark and accept OR both Neither of these are "standard" in the sense of being widely implemented by mail systems that many people use. I don't see anything as being "standard", which I why I don't see any value in offering advice about local policy. R's, John From agthisell@yahoo.com Fri Sep 14 08:20:00 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BFD21F84EB for ; Fri, 14 Sep 2012 08:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPmMjroKeF9n for ; Fri, 14 Sep 2012 08:20:00 -0700 (PDT) Received: from nm7-vm0.bullet.mail.ne1.yahoo.com (nm7-vm0.bullet.mail.ne1.yahoo.com [98.138.91.66]) by ietfa.amsl.com (Postfix) with SMTP id 35A8321F8491 for ; Fri, 14 Sep 2012 08:20:00 -0700 (PDT) Received: from [98.138.90.53] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 14 Sep 2012 15:19:57 -0000 Received: from [98.138.87.10] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 14 Sep 2012 15:19:57 -0000 Received: from [127.0.0.1] by omp1010.mail.ne1.yahoo.com with NNFMP; 14 Sep 2012 15:19:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 54831.32143.bm@omp1010.mail.ne1.yahoo.com Received: (qmail 81682 invoked by uid 60001); 14 Sep 2012 15:19:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347635996; bh=jyTkK/tVbxhvsO21dTFZck05JVauoDP1RS8g4jX05I8=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BWJAdw12k/iULQw95lg/cJTM95ro+F7Ah8zhMpteqYEwjxtxLNlUFritW0ZJB+oQo4kdldPLS9IqbricA+iGVz4pjt+4XT469v1CcE/56ViVgPfNEKKEKdTG9DX9GsnvtnCYOq86uDJ9Ei2/ok08QN7VWHZZ4Fglk3GFFmo3NeQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mfq6/QEVBtIJ5vyQilbAlajqH6dOpjh/lXroZSw3cPlFe87Rup3DZ+/1YHreAXqDRtR9ZUODpuGxQBbK6KyEX+061e08vMynhE49IlVdYSm0sFgFxgYppRVOxF8p/eCPHfT+ZGmR5w8dkcBEq1HRbncWBrALkZvsEV3+CCCqKRY=; X-YMail-OSG: 1cG3SlsVM1lMPA1mfwCH7vufLyqEk1_bH4QDDgUHd8xfrsH ic9o8qDG_Ewe_tdjX5cfce_FM8XkVSG4YnYWw6DJsm5jJXh3wtwJi9xh8VUb ZXXLvFsbkskmLptZO5kWaBxLLBsGV6.w0pgvA4_iu36Z7vpNZ4EXOkesk1n3 Y8Pio44tKd1qKnyEcTT7sfJ0kMkTCvM1v09aVYP4HTQxuSjGdKFyiwcl_ZY5 nwIZTINCpxTCX__4XdRSyx_bQpQFHEKMk4xkRZnb2vgLiwn4uFlTD17Ym5dD zL5Osul6AhfksP98Vvki5GmHD4OTGRXEk35ZU9fvGGQ.dq2sZK3qI5RWUR9J bJPwtwG6TGpT6r1IRCv5a3VSNNYoBgUloyCEZIWVdq8_ZluCoujkonBM0HkR .WotWoyP9iwUPJbJZTeo8rPaV3s_ZugBuCpW8nemhG30ZcoiBebRlnpWkCZK WAzvhj5lnG6qzL4FSzSYIopqS3U5XcgfsNETeN4_8DA-- Received: from [71.61.133.134] by web125103.mail.ne1.yahoo.com via HTTP; Fri, 14 Sep 2012 08:19:56 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347635996.88716.YahooMailClassic@web125103.mail.ne1.yahoo.com> Date: Fri, 14 Sep 2012 08:19:56 -0700 (PDT) From: Arthur Thisell To: S Moonesamy In-Reply-To: <6.2.5.6.2.20120914064631.0a3b9eb8@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: spfbis@ietf.org Subject: Re: [spfbis] Advocacy/how-to in RFC 4408 (was: #58: Local policy in 4408bis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 15:20:00 -0000 > Which parts of RFC 4408 could be categorized as > advocacy/how-to stuff? Well, off the top of my head, stuff I have already mentioned on this list. Section 9.1.1. is all "how to optimize SPF records". The "protocol status" ahd "history" sections tries to establish SPF as an old and reliable protocol that everyone should adopt. To be far, I haven't recently completely read 4408bis's section, but that was what was put into 4408's equivalent section. At least in RFC 4408, a lot of section 9 was "hey, here is how-to deploy SPF rebutting all problems that people will bring up against SPF." A fair amount of effort was put into disguising how-to/advocacy as protocol specification. My point is really that while RFC 4408 might have been fairly tightly written, there are probably now opportunities, based on experience, to remove old text, not just add to it. From spf2@kitterman.com Fri Sep 14 08:22:51 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B2221F8539 for ; Fri, 14 Sep 2012 08:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMaR1F6Sjkwt for ; Fri, 14 Sep 2012 08:22:50 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id C3C8021F84D3 for ; Fri, 14 Sep 2012 08:22:49 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 5B2DBD04087; Fri, 14 Sep 2012 10:22:49 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347636169; bh=rZE9eVq9WO6IU2MoJRmWUUuPRt7uSpWplSp2gp+n7EA=; h=In-Reply-To:References:Subject:From:Date:To:From; b=N0Wh3Kz2eBhsou4FmJTkB+cEA5xFnnmldLcHlXZ7uWL7b23JMvqH2RS6dBqk/YZ9z /z6ofi7zbYZmorYFV2UHd7Pyv/HD6aKwdgMb8jExiB53CAbY4PfGyBO//UC1wxNfZV 32sIYHr2BNQE7TEhdRIIpR5BiNk5eXTepB1v76hc= Received: from [IPV6:2600:1003:b017:2425:8415:15c:24bb:b16a] (unknown [IPv6:2600:1003:b017:2425:8415:15c:24bb:b16a]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id D91DDD04005; Fri, 14 Sep 2012 10:22:48 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <50534999.2030107@dcrocker.net> References: <1347602110.91658.YahooMailClassic@web125106.mail.ne1.yahoo.com> <50534999.2030107@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 14 Sep 2012 11:22:46 -0400 To: spfbis@ietf.org Message-ID: <77f91c56-d6c5-4059-9f16-bd3862893333@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] general changes to RFC 4408 (was: #58: Local policy in 4408bis) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 15:22:51 -0000 Dave Crocker wrote: > > >On 9/13/2012 10:55 PM, Arthur Thisell wrote: >>> I agree it could be reworded without great harm, but I don't see why >it should >>> be changed. Every time we change something in 4408bis from what's >in RFC 4408 >>> we have created an opportunity for an implementer that's reviewing >the new RFC >>> to update their implementation to be confused. >> >> strongly agreed. >> >>> I wish we'd quit rewriting stuff to rewrite it and focus on actual >issues that >>> need to be resolved. >> >> This too. > > >This seems to take the position that more clear, more complete, more >precise writing of a specification is not an actual issue. > >I disagree. Writing matters. > No. It doesn't. It takes the position that we're spending a lot of time on text and structural changes that don't make things better. Scott K From vesely@tana.it Fri Sep 14 08:39:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0620F21F8523 for ; Fri, 14 Sep 2012 08:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.655 X-Spam-Level: X-Spam-Status: No, score=-4.655 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecyS-98qACjy for ; Fri, 14 Sep 2012 08:39:46 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2A00921F8522 for ; Fri, 14 Sep 2012 08:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347637185; bh=5q1UAubTA1QROZPjJRSltMcmEH5R0MSASloznkytNP0=; l=2270; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=IXF+/HVWWxQtPu5kR395GjKtTg2r6pZBI2voZ0sEk8l8+ZuCQ85rUZgNPzWpGq0ne 1RLLN1zRLR7zk37GFKbjycHelJPSGHWCs+f8TxwVX8EE8s1Yp6yIycTWqh6oBi3FcR ATXwXESHspzr6r7YtU2XEM5l/ICMp1Kw5RiElezA= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 14 Sep 2012 17:39:45 +0200 id 00000000005DC035.0000000050534FC1.00001654 Message-ID: <50534FC0.1080206@tana.it> Date: Fri, 14 Sep 2012 17:39:44 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <1347629460.89993.YahooMailClassic@web125104.mail.ne1.yahoo.com> <6.2.5.6.2.20120914064631.0a3b9eb8@resistor.net> In-Reply-To: <6.2.5.6.2.20120914064631.0a3b9eb8@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] Advocacy/how-to in RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 Sep 2012 15:39:47 -0000 On Fri 14/Sep/2012 15:52:20 +0200 S Moonesamy wrote: > At 06:31 14-09-2012, Arthur Thisell wrote: >> I'm not sure if advocacy/how-to stuff is ever appropriate for an >> RFC, but if it is, that is prime material to be shifted to another >> document. > > Which parts of RFC 4408 could be categorized as advocacy/how-to stuff? The following are some snippets from 4408bis where receiver behavior is explicit: 1. *Introduction* Furthermore, if a claimed identity fails verification, local policy can take stronger action against such email, such as rejecting it. 2.2. *The "MAIL FROM" Identity* a definitive policy result 2.4. *Checking Authorization* Although invalid, malformed, or non-existent domains cause SPF checks to return "none" because no SPF record can be found, it has long been the policy of many MTAs to reject email from such domains, especially in the case of invalid "MAIL FROM". Rejecting email will prevent one method of circumventing of SPF records. 2.5.4. *Fail* All except the first two lines. 2.5.5. *Softfail* All except The domain owner believes the host is not authorized but is not willing to make a strong policy statement. 2.5.6. *Temperror* All except the first two lines. 2.5.7. *Permerror* If the message is rejected during the SMTP transaction for this reason, the software SHOULD use an SMTP reply code of 550 and, if supported, the 5.5.2 enhanced status code. 4.4. *Record Lookup* This alternative is intended to shorten the queue time of messages that cannot be accepted, by returning a permanent negative completion reply code to the client, instead of a transient one. 6.2. *exp: Explanation* Since the explanation string is intended for an SMTP response 9. *Implications* This section outlines the major implications that adoption of this document will have on various entities involved in Internet email. It is intended to make clear to the reader where this document knowingly affects the operation of such entities. 9.2.2. *Forwarding Services and Aliases* Almost all. 9.3. *Receivers* Almost all, including subsections. 10.5.1. *Recorded Results* All, except if reworded. 10.5.2. *External Explanations* The concept itself. From dhc@dcrocker.net Fri Sep 14 08:52:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6802C21F84F8 for ; Fri, 14 Sep 2012 08:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX1b6N7hY2o8 for ; Fri, 14 Sep 2012 08:52:04 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5A521F84C4 for ; Fri, 14 Sep 2012 08:52:04 -0700 (PDT) Received: from [192.168.1.8] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8EFq2UE020919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 Sep 2012 08:52:03 -0700 Message-ID: <5053529B.1070803@dcrocker.net> Date: Fri, 14 Sep 2012 08:51:55 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Alessandro Vesely References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <201209122251.02375.spf2@kitterman.com> <505244D9.8050108@dcrocker.net> <50531141.2020306@tana.it> In-Reply-To: <50531141.2020306@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 14 Sep 2012 08:52:04 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 15:52:05 -0000 On 9/14/2012 4:13 AM, Alessandro Vesely wrote: > On Thu 13/Sep/2012 22:40:57 +0200 Dave Crocker wrote: >> I view SPF as follows, > more or less: ... > || || > || SPF in some broader sense || I think that "in some broader sense" nicely characterizes the difference in our views. Unfortunately, what I think you mean by it is "more than" SPF. I think that what you mean is the entire set of authentication, authorization and assessment mechanisms that produce input to the handling filter. The handling filter is where message disposition is decided; that, of course, is the ultimate local policy. However inside your box would be where assessment values, such as "this is a spammer" or "this is a trusted sender" get determined. As such, there's still quite a bit of local policy included inside your box. That's a point for debate. However I think the core point is understanding the difference between "SPF" and "SPF and a lot more", which means the latter shouldn't have the label "SPF" in it. It should have a broader label. Then there would be the question of having such a diagram in an SPF-specific document. The diagram I offered is meant to be SPF-specific. I think there's some benefit in having it echo a DKIM-related diagram, but of course it has to be tailored for differences in SPF architecture at the network level. > I'm not a good ASCII artist, Actually, the diagram you produced looks like perfectly good ascii art to me. > but the above has the advantage to locate > the local policy, thus adhering to this thread's subject. The box > labeled "SPF protocol" would seem to be the check_host() function in a > classical De Marco DFD, while the MAIL FROM/ HELO labels, which are You seem to be confusing a host-side, local state diagram with a distributed protocol exchange. check_host() is a component function in a distributed system that is the SPF protocol. However if you want to do some form of state diagram/graph model representation of SPF as a protocol, that might be interesting to discuss. However I doubt that it would be, since SPF is a uni-directional protocol. There's no interaction sequence. > semantically part of the SPF protocol, should be on the edges... > >> I'm going to claim that a receiving host's actions, after obtaining >> check_host() output, are always and only a matter of local preference. >> SPF cannot dictate any of that behavior. It can explain sender >> preferences (or "requests"). It can discuss implications. But it >> cannot dictate. >> >> Simply put, once we are outside of the realm of basic interoperability, >> we cannot have one ADMD dictating the behaviors of an independent ADMD. > > How is "dictate" related to 2119-language? It pertains to the activity /within/ the protocol that is needed for successful operation of the protocol itself. So, normative language only makes sense "within the 4 walls" of the world defined by the protocol. Once we move outside those walls -- creating input to feed into the protocol or taking ouotput from it -- we cannot apply normative language, because the actions are not required for interoperability. To be clear: there certainly is a world that /could/ be defined that would have a sender dictating receiver actions. That is, it's theoretically possible and might be reasonable. But it requires a world in which we can get receivers to agree to being told how to dispose of messages by senders. A military internet might be an example where this would be possible. But that's not the open Internet and we don't have receivers eager to get disposition directives from senders. An AS that goes into the > meaning of the results has to specify what behaviors an ADMD can > request. To do that, it may say that "a receiver MUST/SHOULD do so > and so" in order to comply with a given request. > > The point of separating AS from TS is that a receiver may want to > comply with SPF as far as getting the correct result is concerned, but > not with the request part. Within a single document, it is impossible > to say to which part each 2119 term would be related. Having a /separate/ document that specifies message disposition based on SPF results might be quite reasonable. It would depend on the details of the document. > I'm not a connoisseur of the historical SPF versions, but all the ones > I saw conflate those two parts, and blur the second one. That matches my perception, also. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From john@jlc.net Fri Sep 14 08:58:54 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880C921F84DD for ; Fri, 14 Sep 2012 08:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.206 X-Spam-Level: X-Spam-Status: No, score=-106.206 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HNsYGlsrnYc for ; Fri, 14 Sep 2012 08:58:54 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id ECC5621F84D3 for ; Fri, 14 Sep 2012 08:58:53 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id C769F33C21; Fri, 14 Sep 2012 11:58:51 -0400 (EDT) Date: Fri, 14 Sep 2012 11:58:51 -0400 From: John Leslie To: John Levine Message-ID: <20120914155851.GJ21618@verdi> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185399@XCHANGE.rvl.internal> <20120914151413.29558.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120914151413.29558.qmail@joyce.lan> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org, W.Doust@racingvictoria.net.au Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 15:58:54 -0000 John Levine wrote: > Cc: W.Doust@racingvictoria.net.au > >> Fail is for those who can positively guarantee that IFF a Fail occurs >> THEN it did not come from us. > > But nobody can make such a guarantee, since there is no way to ensure > that your mail won't be delivered via a path that SPF can't describe. This is true; but a sender policy "forbidding" forwarding _is_ possible, and could be argued to be reasonable. > As a matter of plain fact, people can and will deliver your real mail > to the right recipient via paths you don't authorize, Modulo a definition of "right recipient", this is quite true. > and there's nothing you can do about it. That is less true; and we shouldn't confuse these two clauses. If indeed the intended sender policy were "please reject email arriving from any other MTA" (which it may well be, whether we like that or not) _and_ receiver policy did so, the sender would have succeeded in exactly what John Levine said is impossible. >> The standard (but not manadatory) local policy is then: >> >> If FAIL: either reject with a 550 or mark and block >> If SoftFail: treat as greylist OR mark and accept OR both > > Neither of these are "standard" in the sense of being widely > implemented by mail systems that many people use. I don't believe that was the intended meaning of "standard". :^( (We do indeed seem to be talking past each other much of the time.) > I don't see anything as being "standard", which I why I don't see any > value in offering advice about local policy. I fully believe John Levine doesn't see any such value. I also believe others do see some such value. Our actual problem isn't our differing beliefs, but an inadequate _definition_ of what a sender policy of "-all" means. Consider the current language: ] ] 2.5.4. Fail ] A "fail" result is an explicit statement that the client is not ] authorized to use the domain in the given identity. It's really easy to interpret this to mean that forwarding is not authorized except through a limited number of explicitly authorized forwarders. Indeed, I don't see any other reasonable interpretation. :^( 4408bis _does_ go on to say: ] Disposition of SPF fail messages is a matter of local policy. See ] Section 9.3.2 for considerations on developing local policy. but this doesn't change the definition. There are indeed arguments to be made, based on other RFCs, that the nature of email is such that the sender disclaims control of what happens to any email once it leaves his/her MTA. But such implicit arguments don't negate a "no-forwarding" policy. And SPF _seems_ to be a mechanism for providing out-of-band policy. Is it, or isn't it? (IMHO, we need to say one way or the other.) -- John Leslie From agthisell@yahoo.com Fri Sep 14 09:19:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA8621F84FD for ; Fri, 14 Sep 2012 09:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2f-ffQEJ-ru for ; Fri, 14 Sep 2012 09:19:30 -0700 (PDT) Received: from nm35.bullet.mail.ne1.yahoo.com (nm35.bullet.mail.ne1.yahoo.com [98.138.229.28]) by ietfa.amsl.com (Postfix) with SMTP id AD58621F84EA for ; Fri, 14 Sep 2012 09:19:30 -0700 (PDT) Received: from [98.138.90.56] by nm35.bullet.mail.ne1.yahoo.com with NNFMP; 14 Sep 2012 16:19:25 -0000 Received: from [98.138.89.250] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 14 Sep 2012 16:19:25 -0000 Received: from [127.0.0.1] by omp1042.mail.ne1.yahoo.com with NNFMP; 14 Sep 2012 16:19:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 892451.72703.bm@omp1042.mail.ne1.yahoo.com Received: (qmail 64253 invoked by uid 60001); 14 Sep 2012 16:19:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347639565; bh=mGvX8ch4eDwvcvstVQ5kTOW5SNwionbAX4erNwBN5eE=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=PvkF1hhFl+CGSWS2FayV82XmEXpkvnf1A4PjZqpbwJzgoKVU+vTFNB8X6CNNE4MKouuwNDEB72QprbMpbjxPrUCivYBw0rwO7+xw8mI05YrLTjsNvNOUq5H5lf5mcBBg87K4U608k9FDZnDEwfi2OAiUgx7mABXeH4Pbwgfsgzo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=fTLrWuE/aYca2CuwNK7/b3nK8+rjx3RFrAOuneSd4GrzSOd3IEA3nt7O/uc1Q0TBNOB/VZz9m8bakZf3O0SUZHnQjJYexrX/4agcrFwuycp0l3m0V0RZMJsKYIZVop80zwiBxJVW3jW/0vFXYi5vWuZZf+0sdwzck7dkGrIWBno=; X-YMail-OSG: VYX.f3YVM1k8u_lzMr.LKTJuZvbjWAn9jKu2iSZVEKbKuA0 HBzQFXWxAPIJa3YZjr2Td02SVMYDGSTQ1nge6acJQi0Rlgnq4qjcRDgeZ.Zf _4Zn.xPwuetwc1t6KjaJNqzcf7tsg5oDfV0IPVvaUjwfr3qpzUhYOmtdc93l __iqz.LppqlCljSeZ55xoW4Ic9EzB5N6SK0.qX2TgOJM6wbZlSxo4NX7gKq4 _EFnSP5wRveV_.wJZsDAa_fwRFpTKaAeETd7DztIRCLFD7pFzKJa43xMtZIm kbgH1Amx7bVwWEwhyuJMpZu41Y_8ir8Xn9iTvEK.MY_nRh1kB4ewjEFjHg7X 3DfDBUyijqaEPWU6h4bc010lwznRCNnb4m_MBZ85oz41MUGmgXUUlfwfhJm6 rG.GGpavqQXlp.o5Umm04naawYxsAPdvooaj4HsxzivTl6563bTN8GtlH6z1 4wrtHaAvCj0pIFHYjsGI- Received: from [71.61.133.134] by web125104.mail.ne1.yahoo.com via HTTP; Fri, 14 Sep 2012 09:19:25 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347639565.63274.YahooMailClassic@web125104.mail.ne1.yahoo.com> Date: Fri, 14 Sep 2012 09:19:25 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] Advocacy/how-to in RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 Sep 2012 16:19:31 -0000 >> Which parts of RFC 4408 could be categorized as advocacy/how-to stuff? > > The following are some snippets from 4408bis where receiver behavior > is explicit: first, "receiver behavior" is not the same as "advocacy/how-to stuff" second, receiver behavior is fine as long as it helps the protocol. In particular, the SPF specs are not just about the communication needed for check_hosts() evaluation, they have also always included communication to the sender of the email (via SMTP reply codes and exp= info) and to the receiver of the email (via Received-SPF). Whether SPF should have ventured into those areas is debatable, but RFC 4408 did and changing it would be outside the charter of the WG. From johnl@taugh.com Fri Sep 14 09:24:55 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1056721F845F for ; Fri, 14 Sep 2012 09:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41rUUcngq9J7 for ; Fri, 14 Sep 2012 09:24:54 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id DFD2521F8484 for ; Fri, 14 Sep 2012 09:24:53 -0700 (PDT) Received: (qmail 57996 invoked from network); 14 Sep 2012 16:24:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=e28b.50535a54.k1209; bh=eJig0nUP9xYEZcl/Y7iLkk23tM40yGkizoTYQ4yTqyo=; b=pIP4IXsVAY9nXsLOiM7apuKZdNQpiKmKjphGRzBBFvXzd7hsIKDbx84+Kdw7cUxG+7X2FgJTnI/l9dEvzJ4URMZ8upn3zAAyjBx26YH5Slh79Ps3bqB90pC4nYAJSUpsww706TePmvlFpI9Fq1hsBf8ktmkkPbZvATyTMiukMDE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=e28b.50535a54.k1209; bh=eJig0nUP9xYEZcl/Y7iLkk23tM40yGkizoTYQ4yTqyo=; b=k7gepywqL98cG0JdbuPSxCa0p7wj5HU9gXlP9Uc4a1R6aCFkkOhghKZW2bazqg79H+37DRqsXYZm6DHrL8K3tuDW5D3Pye6YC7YjnFlNfaMxoie7AxjpyB40r/VNABDD1qv7EMmLpQY/VcQdCG5H2ovvrNkB6nRrXsrKunE/+qc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 14 Sep 2012 16:24:30 -0000 Date: 14 Sep 2012 12:24:52 -0400 Message-ID: From: "John R Levine" To: "John Leslie" In-Reply-To: <20120914155851.GJ21618@verdi> References: <0D2A0D5F64179F4F9556D3DEDE39F9AF01185399@XCHANGE.rvl.internal> <20120914151413.29558.qmail@joyce.lan> <20120914155851.GJ21618@verdi> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 16:24:55 -0000 Can you give a step by step explanation of how you plan to keep people to whom you send mail from forwarding it wherever they want and otherwise implementing arbitrary local policies of which you disapprove? Assume that we are fully aware of your published policy, and we choose to ignore it. R's, John On Fri, 14 Sep 2012, John Leslie wrote: > John Levine wrote: >> Cc: W.Doust@racingvictoria.net.au >> >>> Fail is for those who can positively guarantee that IFF a Fail occurs >>> THEN it did not come from us. >> >> But nobody can make such a guarantee, since there is no way to ensure >> that your mail won't be delivered via a path that SPF can't describe. > > This is true; but a sender policy "forbidding" forwarding _is_ > possible, and could be argued to be reasonable. > >> As a matter of plain fact, people can and will deliver your real mail >> to the right recipient via paths you don't authorize, > > Modulo a definition of "right recipient", this is quite true. > >> and there's nothing you can do about it. > > That is less true; and we shouldn't confuse these two clauses. > > If indeed the intended sender policy were "please reject email > arriving from any other MTA" (which it may well be, whether we like > that or not) _and_ receiver policy did so, the sender would have > succeeded in exactly what John Levine said is impossible. > >>> The standard (but not manadatory) local policy is then: >>> >>> If FAIL: either reject with a 550 or mark and block >>> If SoftFail: treat as greylist OR mark and accept OR both >> >> Neither of these are "standard" in the sense of being widely >> implemented by mail systems that many people use. > > I don't believe that was the intended meaning of "standard". :^( > > (We do indeed seem to be talking past each other much of the time.) > >> I don't see anything as being "standard", which I why I don't see any >> value in offering advice about local policy. > > I fully believe John Levine doesn't see any such value. > > I also believe others do see some such value. > > Our actual problem isn't our differing beliefs, but an inadequate > _definition_ of what a sender policy of "-all" means. > > Consider the current language: > ] > ] 2.5.4. Fail > ] A "fail" result is an explicit statement that the client is not > ] authorized to use the domain in the given identity. > > It's really easy to interpret this to mean that forwarding is not > authorized except through a limited number of explicitly authorized > forwarders. > > Indeed, I don't see any other reasonable interpretation. :^( > > 4408bis _does_ go on to say: > > ] Disposition of SPF fail messages is a matter of local policy. See > ] Section 9.3.2 for considerations on developing local policy. > > but this doesn't change the definition. > > There are indeed arguments to be made, based on other RFCs, that > the nature of email is such that the sender disclaims control of > what happens to any email once it leaves his/her MTA. > > But such implicit arguments don't negate a "no-forwarding" policy. > And SPF _seems_ to be a mechanism for providing out-of-band policy. > > Is it, or isn't it? > > (IMHO, we need to say one way or the other.) > > -- > John Leslie > Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From agthisell@yahoo.com Fri Sep 14 10:03:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF28921F851E for ; Fri, 14 Sep 2012 10:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksSOyMeve5X8 for ; Fri, 14 Sep 2012 10:03:21 -0700 (PDT) Received: from nm19-vm0.bullet.mail.ne1.yahoo.com (nm19-vm0.bullet.mail.ne1.yahoo.com [98.138.91.59]) by ietfa.amsl.com (Postfix) with ESMTP id 302EE21F850D for ; Fri, 14 Sep 2012 10:03:21 -0700 (PDT) Received: from [98.138.90.50] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 14 Sep 2012 17:03:16 -0000 Received: from [98.138.89.170] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 14 Sep 2012 17:03:16 -0000 Received: from [127.0.0.1] by omp1026.mail.ne1.yahoo.com with NNFMP; 14 Sep 2012 17:03:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 363720.70758.bm@omp1026.mail.ne1.yahoo.com Received: (qmail 64499 invoked by uid 60001); 14 Sep 2012 17:03:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347642196; bh=48pJ5DDkRFInQiX4HIniucfnpv+0UNqu9/aUxq2UQXo=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=SvpmCs1LZw52opWR4r6TM7o6UK8kv4iyxDvKwlS6KI9AcRr9DMKLKVRHTBsnFIMnGHKSKti8HW0XBB3PIYUeK/TwwOb29JNkjuttH2MVxYKasW5hkOfqcc0GSVYSot2edEyMVdT/nCjJkQdPpUNjJz2hARU8gZrw1SDUVyWZXBY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=nF2A7OYH4MJ2S7W0W1sTRKyUkRSjCb8Bydlc1aVhPmaK9+fHTe7LVSk3FQAadO55Khma+JwrpebKhtMtrwVHwH9+aKU1dqbpEmWIU2N5wxtk5tfpWk/C9fNRMZoE9ZFFOmI/kOa2QBTXImSjPP97IXfEgQAkS1PoaF8wHrefcGw=; X-YMail-OSG: cdSX_1oVM1kIWGbrRC35riQsv6D7L2ng9cVbMcLIcimR8R. 5F7_FTap7GAXPD.GLgWHziUvnveO79feTANZ6Jf5yhtBFhPNSSr7gYq9Z.aL fIdRVWF.9MDZjRGV_w3k5Dal1EVM0RxRbQfghTaS60k6p1tCUb2l93kV3s1f HNO9hprqr8lzcR_9bXXSTRDTH9w2KTdHR8N4yGBph1C50I8QlPM2msUA2.KS 82pHrKiFnhCOlK.1e9wUrVxztyUtLMQD3XSePFlWVhL8FO9ekKEjw.1K8tVJ M8dWT_Rgr4xu.7FnYt7pu6cuaSeiH7aL9ouNXbdFPVRB9W8chdE0Nlr5Yyjr vBQHNr2Ehwz8Jr0AGbV5wUKF9iSN0qGvJX0RR5ahra6MOrAWGTFfsBE0X_Sa vTt30v2V2QqkamgfbL5350OzUrHj8fbGQjEsdrBZT_U.QHpFrPC1Zx6OQ_nL _j9LsEUMGiJ0BoQvxb8s- Received: from [71.61.133.134] by web125106.mail.ne1.yahoo.com via HTTP; Fri, 14 Sep 2012 10:03:16 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347642196.46246.YahooMailClassic@web125106.mail.ne1.yahoo.com> Date: Fri, 14 Sep 2012 10:03:16 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 17:03:21 -0000 > Can you give a step by step explanation of how you plan to keep people to > whom you send mail from forwarding it wherever they want and otherwise > implementing arbitrary local policies of which you disapprove? SPF isn't any sort of DRM, so no, you can't stop people from forwarding email. That doesn't mean that an ADMD can't choose to make a sender policy that is more (or less) friendly to forwarders. Several such examples of how to do so can be found in RFC 4408. (I'm not sure the "how to" part is appropriate for 4408bis, but that's another subject.) SPF is not strictly path-authorization, although that is the most common way it is used. From vesely@tana.it Fri Sep 14 10:40:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D0E21F851C for ; Fri, 14 Sep 2012 10:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.658 X-Spam-Level: X-Spam-Status: No, score=-4.658 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4S3XzAPd1smo for ; Fri, 14 Sep 2012 10:40:04 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1C88E21F8532 for ; Fri, 14 Sep 2012 10:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347644403; bh=Wbi/PyZ/LJcron6c32ibP3r+viI/8gQAr32SfBhSXQ8=; l=3578; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=OuefONQUJVX/ytoB/g2I+H/Qph5LFuiyBquR5kgdRk/m1eukf4c6GX+3gnGZROrkG AYYZ9/6ykAqQiQODc+SbibqM4ngR5spuE4DPH9Ut3vMUOORef4k543DJI+lRh+68se M79zg/aAumc+Ttcq0nXWiE8TyYBwtRfD1k8W9/oA= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 14 Sep 2012 19:40:03 +0200 id 00000000005DC035.0000000050536BF3.000032AD Message-ID: <50536BF2.7030106@tana.it> Date: Fri, 14 Sep 2012 19:40:02 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <064.ca19ed73e26b0c3a4b6628c728c259ac@tools.ietf.org> <504DAFCB.9010207@tana.it> <6.2.5.6.2.20120910025729.0a4fee48@resistor.net> <201209122251.02375.spf2@kitterman.com> <505244D9.8050108@dcrocker.net> <50531141.2020306@tana.it> <5053529B.1070803@dcrocker.net> In-Reply-To: <5053529B.1070803@dcrocker.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 17:40:05 -0000 On Fri 14/Sep/2012 17:51:55 +0200 Dave Crocker wrote: > On 9/14/2012 4:13 AM, Alessandro Vesely wrote: >> || || >> || SPF in some broader sense || > > I think that "in some broader sense" nicely characterizes the > difference in our views. > > Unfortunately, what I think you mean by it is "more than" SPF. Yes. > I think that what you mean is the entire set of authentication, > authorization and assessment mechanisms that produce input to the > handling filter. Some of it. > The handling filter is where message disposition is decided; that, of > course, is the ultimate local policy. However inside your box would > be where assessment values, such as "this is a spammer" or "this is a > trusted sender" get determined. I'd be happy with "this comes from where it says it's coming". No connotation of spam or trust, just DNS, but taking non-rewriting forwarders into account. A well defined problem, consistent with the original SPF catch of requiring a registered domain to send mail. The handling filter may make further considerations and assessments. > As such, there's still quite a bit of local policy included inside > your box. That's a point for debate. However I think the core point > is understanding the difference between "SPF" and "SPF and a lot > more", which means the latter shouldn't have the label "SPF" in it. > It should have a broader label. It might include DNSxL, but not DKIM. That way, it would be worth against bursts of unauthorized mail. Such attacks are possible, albeit IME unusual. To accept and verify the DATA may require so much resources as to turn them into DoS attacks. >> I'm not a good ASCII artist, > > Actually, the diagram you produced looks like perfectly good ascii art > to me. Thanks. However, as you say, it confuses a host-side, local state diagram with a distributed protocol exchange. BTW, are there formal rules for the latter ones? >> How is "dictate" related to 2119-language? > > It pertains to the activity /within/ the protocol that is needed for > successful operation of the protocol itself. So, normative language > only makes sense "within the 4 walls" of the world defined by the > protocol. > > Once we move outside those walls -- creating input to feed into the > protocol or taking ouotput from it -- we cannot apply normative > language, because the actions are not required for interoperability. > > To be clear: there certainly is a world that /could/ be defined that > would have a sender dictating receiver actions. That is, it's > theoretically possible and might be reasonable. But it requires a > world in which we can get receivers to agree to being told how to > dispose of messages by senders. A military internet might be an > example where this would be possible. > > But that's not the open Internet and we don't have receivers eager to > get disposition directives from senders. I'm happy the Internet is open the way it is. The point is not who dictates what to whom, but what are the most effective ways that legitimate MTAs can cooperate. > Having a /separate/ document that specifies message disposition based > on SPF results might be quite reasonable. Yes. > It would depend on the details of the document. Yes, and they in turn depend on how well /we/ can cooperate. Another possibility is to write a dummy document, possibly still experimental, that just repeats RFC 4408's hints, for the mere purpose of not changing the overall specification, to be obsoleted as soon as possible. From johnl@iecc.com Fri Sep 14 11:28:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB17221F84DD for ; Fri, 14 Sep 2012 11:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxoP-EK7+Xsm for ; Fri, 14 Sep 2012 11:28:26 -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 E7D7021F84D8 for ; Fri, 14 Sep 2012 11:28:25 -0700 (PDT) Received: (qmail 91763 invoked from network); 14 Sep 2012 18:28:24 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Sep 2012 18:28:24 -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:vbr-info; s=50537748.xn--btvx9d.k1208; i=johnl@user.iecc.com; bh=r0MyftS/pPoWs35U7h4enquFb0gh05K1FeAnTpcdj6E=; b=O7nMhgkEhEhokcwcjAz3ETole4xnn9OmLzWeUFuJHTDh4oZs/bvohbG3nZuS2uBZOKpodgUkMTy46leRZHIZz5FQAKtmZoxkNWaym0XXx6dCcZi0p6wqmz5LqCQmVmmDTDa/KyUZILCABFWbs/irFgjGOxSxVWqzXNyT0IdgUYw= 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:vbr-info; s=50537748.xn--btvx9d.k1208; olt=johnl@user.iecc.com; bh=r0MyftS/pPoWs35U7h4enquFb0gh05K1FeAnTpcdj6E=; b=tOhgLkmT9mHDPhCjYosoCVg8162r3PjJsZ1eBlXvYl97a/32NGQowcySQlSZiYVI58UiwE02YWchPAjxt8RYPJndr3LbEAyE7KfBywU5QM1mTYeYvzendlG8/w1w0l3St0NrdN/ZWu3zaEUKAV1uRvtRvFvsS719eFV8hxQ1+CE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 14 Sep 2012 18:28:02 -0000 Message-ID: <20120914182802.94107.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1347642196.46246.YahooMailClassic@web125106.mail.ne1.yahoo.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: agthisell@yahoo.com Subject: Re: [spfbis] #58: Local policy in 4408bis X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 18:28:26 -0000 In article <1347642196.46246.YahooMailClassic@web125106.mail.ne1.yahoo.com> you write: >> Can you give a step by step explanation of how you plan to keep people to >> whom you send mail from forwarding it wherever they want and otherwise >> implementing arbitrary local policies of which you disapprove? > >SPF isn't any sort of DRM, so no, you can't stop people from forwarding email. That doesn't mean >that an ADMD can't choose to make a sender policy that is more (or less) friendly to forwarders. I think we agree here -- the sender can publish any policy it wants, but the receiver isn't bound by that policy. R's, John From superuser@gmail.com Fri Sep 14 12:12:06 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA54C21F8550 for ; Fri, 14 Sep 2012 12:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4MTbi2glJqF for ; Fri, 14 Sep 2012 12:12:06 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A095A21F8493 for ; Fri, 14 Sep 2012 12:12:05 -0700 (PDT) Received: by lahm15 with SMTP id m15so3145425lah.31 for ; Fri, 14 Sep 2012 12:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=NGgBefFhiK1GKzf6aENQSRKAMTj4Lr0qbEiFCrbDL3U=; b=yKcijYCbvo7/b7thGqHGeNC7xlTjYW9b0dsCDzvrxyTQngchlVLds6ixQekJWFTz0x mCxhwN7u4bqkXvx879yI0I5MhtGfenfPdKE4b5nLQkBBELdBkZiwGzQQiukMDYa9Ifqq XcvmXPiqUefYdlS6TCYOI/b8x/fm7i4g61QkZj1ysgGU+9GO+OzMSSPnDDqSQ4xt3S1Q fdYVq33St1XTDRaO6esJDWFvmZfjvmQLIsr7FxUrg3v3N5aKORHwtENL1bc+14eYjNOl 06eolq0xa1Rm3pDOqvjfwac7/3PJdk/GWFeUiI57OoQcriYzQII5OdERJyQ+tDxqWPAn GO7A== MIME-Version: 1.0 Received: by 10.152.46.203 with SMTP id x11mr3250210lam.46.1347649924451; Fri, 14 Sep 2012 12:12:04 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Fri, 14 Sep 2012 12:12:04 -0700 (PDT) Date: Fri, 14 Sep 2012 12:12:04 -0700 Message-ID: From: "Murray S. Kucherawy" To: spfbis@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 Sep 2012 19:12:06 -0000 I've taken some time to construct a proposed restructuring of the current spfbis draft. Since we're ruminating now about the idea of splitting the document, it seems like we might benefit from having an example to consider. I have showed this already to Scott, who is of the opinion that it doesn't bring enough benefit to be worth doing (I'm sure he'll provide more detail about that on this thread). On the other hand, I rather like the proposed arrangement, for reasons described below. The point of posting this now is to get other opinions. I recently conducted a high-level review of the -07 draft of spfbis, as compared to a more detailed technical review I did earlier. The focus here was thus more on organization and presentation of the material rather than getting the technical details right. SPF is a protocol, and this is the document that defines it. It has however become somewhat bloated with documentation of nuance and other text that has nothing to do with interoperability, security, or other topics critical to defining a protocol and enabling interoperability. Much of that bloat may well have been there in RFC4408 itself, and the working group has focused on developing it rather than cleaning it up. I've taken a stab here at doing the latter. It's important to note that absolutely nothing has been removed from -07 here, though while hacking on it I did reword a few things along the way to improve the presentation. This is simply a proposed rearrangement of the material. I also added one or two paragraphs that have already had some discussion on the list to see if they fit, and I think they do. Of course, the whole thing has to have consensus to carry forward. I've tried to arrange it the way I believe protocols and algorithms are generally described, like a man page or an RFC would be, in this sort of order: INTRODUCTION: Section 1: Problem Statement/Introduction, Terminology Section 2: Basic Inputs, Basic Outputs, Establish Context DETAILS: Section 3: Policy Statement Syntax Section 4: Function Definition, i.e. How To Write check_host() Section 5: Enumerate and Describe Mechanisms Section 6: Enumerate and Describe Modifiers Section 7: Macros OPERATION: Section 8: Details about Outputs, Pedagogy, Interpretation Section 9: Recording Results in Headers Section 10: Affects on Infrastructure Section 11: Security Considerations REQUIRED STUFF: Section 12: Acknowledgements Section 13: IANA Considerations Section 14: References EXTRA BITS: Appendices A number of sections in the -07 draft have been carved up and moved into Appendices C through I because they appear to be detailed operational advice or even vague suggestions rather than core protocol material. Those, I believe, are candidates for being moved out into an Informational operations guide to reduce the size of the core specification. I believe some of what's now Sections 8 and 10 could also go if we want to be more aggressive about this kind of cleanup work. Or if we want to be less aggressive, just leave them all as appendices of the core document. While talking to Pete about some charter topics in one of my other working groups, I did broach the subject of the split of spfbis into a proposed standard and an informational, and he appeared to agree that it would only be a milestone change and not a full charter update that would need IESG approval. Thus, procedurally, this is a lightweight move if we choose to make it. The co-chairs just need to decide upon editor(s) and away we go. The diff is at http://www.blackops.org/~msk/spfbis/reorg.html. I look forward to your comments. -MSK From superuser@gmail.com Fri Sep 14 13:00:33 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFDA21F853D for ; Fri, 14 Sep 2012 13:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imrpDkXmviGv for ; Fri, 14 Sep 2012 13:00:33 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E84BE21F84C4 for ; Fri, 14 Sep 2012 13:00:32 -0700 (PDT) Received: by lahm15 with SMTP id m15so3172680lah.31 for ; Fri, 14 Sep 2012 13:00: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:content-transfer-encoding; bh=XuyBhlu4Up9Slq3x3p4sCN+3HSCZ7M9BoUo3QY/YBVU=; b=cSXa32b25g3ZaDhXOIyj+uaLf/EXPGOa5O1GjmDpSQvwofWZQ4JAGDdZC7GEqnRV5w HBSSEW668W9Jidj6VEW7jy2Y/sb1IYXnTc7sLPvRNMOtSoe66bGz5C+CAWRwm20dYFFS TP86d79sHJel+EdYRDaAsDABxjwf9iELV7/OVnmvpbdk0kHAM9DSWoOPk/+zFMFmsOf3 McXrMzmsyqpouc0marEP1hqmZDqK/hl+DBpewPoC6Sth841hvlJu6Le99v4J56nA7Uq3 XFsMnTOt8VBj65WM6En4JYktThybyhSmfF85Idh3rvSSnRjv/5YIoU+vsOGt0so0lXn/ YIEQ== MIME-Version: 1.0 Received: by 10.112.24.101 with SMTP id t5mr1477329lbf.123.1347652831811; Fri, 14 Sep 2012 13:00:31 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Fri, 14 Sep 2012 13:00:31 -0700 (PDT) In-Reply-To: <1347639565.63274.YahooMailClassic@web125104.mail.ne1.yahoo.com> References: <1347639565.63274.YahooMailClassic@web125104.mail.ne1.yahoo.com> Date: Fri, 14 Sep 2012 13:00:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: Arthur Thisell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org Subject: Re: [spfbis] Advocacy/how-to in RFC 4408 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 Sep 2012 20:00:33 -0000 On Fri, Sep 14, 2012 at 9:19 AM, Arthur Thisell wrote= : > second, receiver behavior is fine as long as it helps the protocol. In p= articular, the SPF specs are not just about the communication needed for ch= eck_hosts() evaluation, they have also always included communication to the= sender of the email (via SMTP reply codes and exp=3D info) and to the rec= eiver of the email (via Received-SPF). Whether SPF should have ventured i= nto those areas is debatable, but RFC 4408 did and changing it would be out= side the charter of the WG. It is possible to alter the presentation of the material to resolve the debate; make those things not part of the core specification, but rather make them available in an adjunct fashion. -MSK From john@jlc.net Fri Sep 14 13:19:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A6F21F8540 for ; Fri, 14 Sep 2012 13:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.237 X-Spam-Level: X-Spam-Status: No, score=-106.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nc06IURhkDE for ; Fri, 14 Sep 2012 13:19:36 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id A96E121F853E for ; Fri, 14 Sep 2012 13:19:29 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 4C90733C23; Fri, 14 Sep 2012 16:19:29 -0400 (EDT) Date: Fri, 14 Sep 2012 16:19:29 -0400 From: John Leslie To: "Murray S. Kucherawy" Message-ID: <20120914201929.GK21618@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 Sep 2012 20:19:37 -0000 Murray S. Kucherawy wrote: > > I've tried to arrange it the way I believe protocols and algorithms > are generally described, like a man page or an RFC would be, in this > sort of order: > > INTRODUCTION: > Section 1: Problem Statement/Introduction, Terminology > Section 2: Basic Inputs, Basic Outputs, Establish Context > > DETAILS: > Section 3: Policy Statement Syntax > Section 4: Function Definition, i.e. How To Write check_host() > Section 5: Enumerate and Describe Mechanisms > Section 6: Enumerate and Describe Modifiers > Section 7: Macros > > OPERATION: > Section 8: Details about Outputs, Pedagogy, Interpretation > Section 9: Recording Results in Headers > Section 10: Affects on Infrastructure > Section 11: Security Considerations > > REQUIRED STUFF: > Section 12: Acknowledgements > Section 13: IANA Considerations > Section 14: References > > EXTRA BITS: > Appendices It's hard to know what to make of this... My initial impression is that we'd do better to consider what could be split off into an Applicability Statement. For example, I would guess that Sections 9 and 10 deserve to be split off, and I'm confused about Section 8. There would have to be a Security Considerations as part of the protocol specification; but there might also be Security Considerations that belong to an Applicability Statement. > While talking to Pete about some charter topics in one of my other > working groups, I did broach the subject of the split of spfbis into a > proposed standard and an informational, and he appeared to agree that > it would only be a milestone change and not a full charter update that > would need IESG approval. Thus, procedurally, this is a lightweight > move if we choose to make it. The co-chairs just need to decide upon > editor(s) and away we go. For purposes of discussion, I strongly recommend that we consider any possible need to "recharter" to do a split out-of-scope here. I'm 100% confident that Pete would take care of any such need if we show him that the WG wants to split the document. IMHO, we're going 'round in circles largely because we have differing opinions on what is protocol and what is operational advice. -- John Leslie From superuser@gmail.com Fri Sep 14 13:22:55 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9F021F847D for ; Fri, 14 Sep 2012 13:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68Kx9pWVTKIe for ; Fri, 14 Sep 2012 13:22:55 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE2121F8476 for ; Fri, 14 Sep 2012 13:22:54 -0700 (PDT) Received: by lbky2 with SMTP id y2so3242961lbk.31 for ; Fri, 14 Sep 2012 13:22:53 -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=8ntmR6yO1/2LxugtT+bGVeB7V6Q75CNbnX76nEUHYEs=; b=vUeyFWDjS8XWmLjKsx4ZKUPzwOpD7prJ7ZRf63lrpH/I7oh2KAGI2uNDfrFftzcoB0 WTn5fVqErPoNFWSWokHB1u+IXrTUNfUd2Tkhjzdjx/obOCC/NSPSux1IbiiwFN1gHx1e Urf+/1eipTNMqG8lUJdrwmswOYIrMPR8aDhBub9MelGX0yayQa1eekIJeFrhSXmpulWs YDd0exCFp+5nlcC80Frur8kLvBrCPwmWpCPFsOl4lcBGys/983JCnZlZwXR7WcJnUXq+ YCk9OedS2orwAenKZIIwwsFE977wGkQE7pa2QBXx+35iKA/iwjXoOObKFB5QZGuAIaAZ 4H1g== MIME-Version: 1.0 Received: by 10.112.30.34 with SMTP id p2mr1517031lbh.85.1347654173268; Fri, 14 Sep 2012 13:22:53 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Fri, 14 Sep 2012 13:22:53 -0700 (PDT) In-Reply-To: <20120914201929.GK21618@verdi> References: <20120914201929.GK21618@verdi> Date: Fri, 14 Sep 2012 13:22:53 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Leslie Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 Sep 2012 20:22:55 -0000 On Fri, Sep 14, 2012 at 1:19 PM, John Leslie wrote: > It's hard to know what to make of this... My initial impression is > that we'd do better to consider what could be split off into an > Applicability Statement. Exactly, and one of the goals of this exercise is to "group" that text in such a way that extracting it, or imagining what that would look like, is much easier. > For example, I would guess that Sections 9 and 10 deserve to be > split off, and I'm confused about Section 8. There would have to be > a Security Considerations as part of the protocol specification; but > there might also be Security Considerations that belong to an > Applicability Statement. I think parts of Section 8 probably also qualify. That's for us to discuss here as a group. Have at it. -MSK From dhc@dcrocker.net Fri Sep 14 13:27:15 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C371E21F84D5 for ; Fri, 14 Sep 2012 13:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5q4u4rhViQWB for ; Fri, 14 Sep 2012 13:27:14 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E389521F8476 for ; Fri, 14 Sep 2012 13:27:14 -0700 (PDT) Received: from [192.168.1.8] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8EKRCLk024908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 Sep 2012 13:27:13 -0700 Message-ID: <50539318.5050206@dcrocker.net> Date: Fri, 14 Sep 2012 13:27:04 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 14 Sep 2012 13:27:13 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 20:27:15 -0000 On 9/14/2012 12:12 PM, Murray S. Kucherawy wrote: > Section 10: Affects on Infrastructure Effects. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Fri Sep 14 13:32:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F9D21F84AF for ; Fri, 14 Sep 2012 13:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcyaMitTQUiN for ; Fri, 14 Sep 2012 13:32:43 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 226AE21F84AE for ; Fri, 14 Sep 2012 13:32:42 -0700 (PDT) Received: by lbky2 with SMTP id y2so3248075lbk.31 for ; Fri, 14 Sep 2012 13:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EDcC/iT37s7EMOuWibNzEI7qFjTyq880pc3GTA8galg=; b=zmR0FQY+YfsKj0uxP8CefEp0cvgCCy8VRf/ztadUcT+tKXxbxFlCDbVrpPwSM7A/Gn 2PAksOlrlOhOvNAe7DNW05OCU6ulr2zQ+t17bKwzwJ3I+OXzAO/jW57jSQZgFgowQTxx 1DpcDz2IYoVdZGKMsyOWpaOn2Sj16ZqGhqu4Bke4yBqjrXj1SGutI11Hn+cG/TaYcvXu Va/fkSoGz++ja0IF4hb3W/Be+qu0wcpDS05eiy11I0G6VKzRXDhrObPUUoU1vPG06Kmk /LxnsBAchYka8goEWpiN2GBT1LEubS1WaXH/XNGePcauXX/PDOb0oX++oXOB+WKq6V4Y 3qlQ== MIME-Version: 1.0 Received: by 10.152.125.116 with SMTP id mp20mr3586908lab.19.1347654761981; Fri, 14 Sep 2012 13:32:41 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Fri, 14 Sep 2012 13:32:41 -0700 (PDT) In-Reply-To: <50539318.5050206@dcrocker.net> References: <50539318.5050206@dcrocker.net> Date: Fri, 14 Sep 2012 13:32:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 Sep 2012 20:32:43 -0000 On Fri, Sep 14, 2012 at 1:27 PM, Dave Crocker wrote: >> Section 10: Affects on Infrastructure > > Effects. Stop that! From leibzon@gmail.com Fri Sep 14 13:41:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B96421F8568 for ; Fri, 14 Sep 2012 13:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glP74kwTJiyN for ; Fri, 14 Sep 2012 13:41:30 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9BC21F8567 for ; Fri, 14 Sep 2012 13:41:29 -0700 (PDT) Received: by bkty12 with SMTP id y12so1377175bkt.31 for ; Fri, 14 Sep 2012 13:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=GwJ4VEeMgOsY0NnHHsTy4lauaAcwKFrrSwld9m0pQO4=; b=rUGt4y4V/YXP4Y5icGwksPOn5BJUPWfA+jyuZwQrLXPH1ueiygegOtn5Enzbl/EY21 6iSoYRQahvV1xRMtrCcKbTX6X1LjP7R+VFw8obRdRDU4zbHBzJx1UVNwVCpPrLUqHj8l MOhbaez8sqr4aVKqewjwvSyOCBEftZAlyx7f2TbpoGV9LIJA2fMlg2wwPXvw9siJFhKi ldFBAiHf51zRmgoqbAUzKwq+5oU347SAz+z7tMku9TGyywCfOwEEEUIkHzfbQBiPjCP3 txJ9I4ryquemTG12x1md/p4o90eHFvNuT9X9ZjhgoSjhEykGc3dL7qanRQLZD92wf/gl S3bA== Received: by 10.204.129.24 with SMTP id m24mr1978719bks.134.1347655288016; Fri, 14 Sep 2012 13:41:28 -0700 (PDT) MIME-Version: 1.0 Sender: leibzon@gmail.com Received: by 10.204.13.7 with HTTP; Fri, 14 Sep 2012 13:41:07 -0700 (PDT) In-Reply-To: References: From: William Leibzon Date: Fri, 14 Sep 2012 13:41:07 -0700 X-Google-Sender-Auth: 46WJ-pgKU3_rCEawQq6XeKcppxc Message-ID: To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=0015173fefecb8d0c304c9af7204 Cc: spfbis@ietf.org Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 Sep 2012 20:42:50 -0000 --0015173fefecb8d0c304c9af7204 Content-Type: text/plain; charset=ISO-8859-1 I've been lurking and not posting but here I'd like to note that such re-organization is likely to go against original intent of SPF. The intent was to have it published as a standard document and if part of it is split into "informational" type document that is very different especially given that SPF was published as experimental standard already. In general I'm actually under the impression that instead of doing real "SPFbis" and polishing a doc (which we already did quite a bit of work on before) for proposed standard you're in fact starting back on MARID-like discussions that chair himself regarded as inappropriate. This also very reminds me of when original SPF was sent to publication and then area director tried to change important SHOULD to some non-capitalized word right before it was to be published hoping we'd not notice. This appears to be somewhat similar on larger scale. Please keep in mind original intent of the document to provide a standard way to protect your from abuse of MAIL FROM by spammers and fraudsters. On Fri, Sep 14, 2012 at 12:12 PM, Murray S. Kucherawy wrote: > I've taken some time to construct a proposed restructuring of the > current spfbis draft. Since we're ruminating now about the idea of > splitting the document, it seems like we might benefit from having an > example to consider. > > I have showed this already to Scott, who is of the opinion that it > doesn't bring enough benefit to be worth doing (I'm sure he'll provide > more detail about that on this thread). On the other hand, I rather > like the proposed arrangement, for reasons described below. The point > of posting this now is to get other opinions. > > I recently conducted a high-level review of the -07 draft of spfbis, > as compared to a more detailed technical review I did earlier. The > focus here was thus more on organization and presentation of the > material rather than getting the technical details right. > > SPF is a protocol, and this is the document that defines it. It has > however become somewhat bloated with documentation of nuance and other > text that has nothing to do with interoperability, security, or other > topics critical to defining a protocol and enabling interoperability. > Much of that bloat may well have been there in RFC4408 itself, and the > working group has focused on developing it rather than cleaning it up. > I've taken a stab here at doing the latter. > > It's important to note that absolutely nothing has been removed from > -07 here, though while hacking on it I did reword a few things along > the way to improve the presentation. This is simply a proposed > rearrangement of the material. I also added one or two paragraphs > that have already had some discussion on the list to see if they fit, > and I think they do. Of course, the whole thing has to have consensus > to carry forward. > > I've tried to arrange it the way I believe protocols and algorithms > are generally described, like a man page or an RFC would be, in this > sort of order: > > INTRODUCTION: > Section 1: Problem Statement/Introduction, Terminology > Section 2: Basic Inputs, Basic Outputs, Establish Context > > DETAILS: > Section 3: Policy Statement Syntax > Section 4: Function Definition, i.e. How To Write check_host() > Section 5: Enumerate and Describe Mechanisms > Section 6: Enumerate and Describe Modifiers > Section 7: Macros > > OPERATION: > Section 8: Details about Outputs, Pedagogy, Interpretation > Section 9: Recording Results in Headers > Section 10: Affects on Infrastructure > Section 11: Security Considerations > > REQUIRED STUFF: > Section 12: Acknowledgements > Section 13: IANA Considerations > Section 14: References > > EXTRA BITS: > Appendices > > A number of sections in the -07 draft have been carved up and moved > into Appendices C through I because they appear to be detailed > operational advice or even vague suggestions rather than core protocol > material. Those, I believe, are candidates for being moved out into > an Informational operations guide to reduce the size of the core > specification. I believe some of what's now Sections 8 and 10 could > also go if we want to be more aggressive about this kind of cleanup > work. Or if we want to be less aggressive, just leave them all as > appendices of the core document. > > While talking to Pete about some charter topics in one of my other > working groups, I did broach the subject of the split of spfbis into a > proposed standard and an informational, and he appeared to agree that > it would only be a milestone change and not a full charter update that > would need IESG approval. Thus, procedurally, this is a lightweight > move if we choose to make it. The co-chairs just need to decide upon > editor(s) and away we go. > > The diff is at http://www.blackops.org/~msk/spfbis/reorg.html. I look > forward to your comments. > > -MSK > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > --0015173fefecb8d0c304c9af7204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I've been lurking and not posting but here I'd like = to note that such re-organization is likely to go against original intent o= f SPF. The intent was to have it published as a standard document and if pa= rt of it is split into "informational" type document that is very= different especially given that SPF was published as experimental standard= already. In general I'm actually under the impression that instead of = doing real "SPFbis" and polishing a doc (which we already did qui= te a bit of work on before) for proposed standard you're in fact starti= ng back on MARID-like discussions that chair himself regarded as inappropri= ate. This also very reminds me of when original SPF was sent to publication= and then area director tried to change important SHOULD to some non-capita= lized word right before it was to be published hoping we'd not notice. = This appears to be somewhat similar on larger scale. Please keep in mind or= iginal intent of the document to provide a standard way to protect your fro= m abuse of MAIL FROM by spammers and fraudsters.

On Fri, Sep 14, 2012 at 12:12 PM, Murray S. = Kucherawy <superuser@gmail.com> wrote:
I've taken some time to construct a proposed restructuring of the
current spfbis draft. =A0Since we're ruminating now about the idea of splitting the document, it seems like we might benefit from having an
example to consider.

I have showed this already to Scott, who is of the opinion that it
doesn't bring enough benefit to be worth doing (I'm sure he'll = provide
more detail about that on this thread). =A0On the other hand, I rather
like the proposed arrangement, for reasons described below. =A0The point of posting this now is to get other opinions.

I recently conducted a high-level review of the -07 draft of spfbis,
as compared to a more detailed technical review I did earlier. =A0The
focus here was thus more on organization and presentation of the
material rather than getting the technical details right.

SPF is a protocol, and this is the document that defines it. =A0It has
however become somewhat bloated with documentation of nuance and other
text that has nothing to do with interoperability, security, or other
topics critical to defining a protocol and enabling interoperability.
Much of that bloat may well have been there in RFC4408 itself, and the
working group has focused on developing it rather than cleaning it up.
=A0I've taken a stab here at doing the latter.

It's important to note that absolutely nothing has been removed from -07 here, though while hacking on it I did reword a few things along
the way to improve the presentation. =A0This is simply a proposed
rearrangement of the material. =A0I also added one or two paragraphs
that have already had some discussion on the list to see if they fit,
and I think they do. =A0Of course, the whole thing has to have consensus to carry forward.

I've tried to arrange it the way I believe protocols and algorithms
are generally described, like a man page or an RFC would be, in this
sort of order:

INTRODUCTION:
Section 1: Problem Statement/Introduction, Terminology
Section 2: Basic Inputs, Basic Outputs, Establish Context

DETAILS:
Section 3: Policy Statement Syntax
Section 4: Function Definition, i.e. How To Write check_host()
Section 5: Enumerate and Describe Mechanisms
Section 6: Enumerate and Describe Modifiers
Section 7: Macros

OPERATION:
Section 8: Details about Outputs, Pedagogy, Interpretation
Section 9: Recording Results in Headers
Section 10: Affects on Infrastructure
Section 11: Security Considerations

REQUIRED STUFF:
Section 12: Acknowledgements
Section 13: IANA Considerations
Section 14: References

EXTRA BITS:
Appendices

A number of sections in the -07 draft have been carved up and moved
into Appendices C through I because they appear to be detailed
operational advice or even vague suggestions rather than core protocol
material. =A0Those, I believe, are candidates for being moved out into
an Informational operations guide to reduce the size of the core
specification. =A0I believe some of what's now Sections 8 and 10 could<= br> also go if we want to be more aggressive about this kind of cleanup
work. =A0Or if we want to be less aggressive, just leave them all as
appendices of the core document.

While talking to Pete about some charter topics in one of my other
working groups, I did broach the subject of the split of spfbis into a
proposed standard and an informational, and he appeared to agree that
it would only be a milestone change and not a full charter update that
would need IESG approval. =A0Thus, procedurally, this is a lightweight
move if we choose to make it. =A0The co-chairs just need to decide upon
editor(s) and away we go.

The diff is at http://www.blackops.org/~msk/spfbis/reorg.html. =A0I l= ook
forward to your comments.

-MSK
_______________________________________________
spfbis mailing list
spfbis@ietf.org = https://www.ietf.org/mailman/listinfo/spfbis

--0015173fefecb8d0c304c9af7204-- From superuser@gmail.com Fri Sep 14 13:59:07 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5601221F8554 for ; Fri, 14 Sep 2012 13:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7u2k3wF4rDyl for ; Fri, 14 Sep 2012 13:59:06 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8665221F854F for ; Fri, 14 Sep 2012 13:59:06 -0700 (PDT) Received: by lahm15 with SMTP id m15so3205743lah.31 for ; Fri, 14 Sep 2012 13:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uAZlZKns70MA3rIwqtJSW7s61cl0tAu25o+aod4T5yg=; b=eclTHWUJJLdqh2Z3ln/CMuxkZ955s159yCgubLEF4EGC6Aa6h8uhIiuWZl8KF1B4NS QKTdzfhHZ84wP7TRXsDPNTSsianCSKhZQ2a9s/3ht9oAi1B8vF7fygP0F4ewy9Avo0Je XxEl0qxpMOuJYKcAmSy4cJ+kuyUoaljqAh6nScmvEM90gF+2q4LG57HKIo/uxaC3zQ9X as8ybT6ZVqPURxvK8KX7Ylgum2jpTl0AOBbVnuyurG9LIRq6UU/fpVHcNHG0gpiMYcs1 Oo7Y2uPjsHr6mGrtK0lsxtvyHArbakbbSrukXJ+KvvxcUjobkVxqeLYIA5YDYYru0+Pi GQ0w== MIME-Version: 1.0 Received: by 10.112.51.228 with SMTP id n4mr1571141lbo.55.1347656345508; Fri, 14 Sep 2012 13:59:05 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Fri, 14 Sep 2012 13:59:05 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Sep 2012 13:59:05 -0700 Message-ID: From: "Murray S. Kucherawy" To: William Leibzon Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 Sep 2012 20:59:07 -0000 On Fri, Sep 14, 2012 at 1:41 PM, William Leibzon wrote: > I've been lurking and not posting but here I'd like to note that such > re-organization is likely to go against original intent of SPF. The intent > was to have it published as a standard document and if part of it is split > into "informational" type document that is very different especially given > that SPF was published as experimental standard already. What's an "experimental standard"? In IETF terms, it's either Experimental or Proposed Standard. SPF is the former. > In general I'm > actually under the impression that instead of doing real "SPFbis" and > polishing a doc (which we already did quite a bit of work on before) for > proposed standard you're in fact starting back on MARID-like discussions > that chair himself regarded as inappropriate. That's manifestly not what I'm proposing here. As I said, there's complete preservation of the material with a couple of minor things that I believe the WG was already trying on for size. I'm proposing what I believe is an improvement in the presentation of the very same material. How could that be construed as a re-hashing of off-topic discussions? > This also very reminds me of > when original SPF was sent to publication and then area director tried to > change important SHOULD to some non-capitalized word right before it was to > be published hoping we'd not notice. This appears to be somewhat similar on > larger scale. Please keep in mind original intent of the document to provide > a standard way to protect your from abuse of MAIL FROM by spammers and > fraudsters. I don't think any of the intent or the technical details have been obscured. The material has just been reorganized. Let me put the challenge back to you: Why should we presume that the organization and presentation of RFC4408 is optimal? Will the IESG, now reviewing this as a Proposed Standard instead of the lower bar of Experimental, agree that the older document got it completely right? -MSK From spf2@kitterman.com Fri Sep 14 14:02:19 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF1D21F8568 for ; Fri, 14 Sep 2012 14:02:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBC7QZ4UUPPa for ; Fri, 14 Sep 2012 14:02:18 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7060121F8567 for ; Fri, 14 Sep 2012 14:02:18 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id CA96FD04087; Fri, 14 Sep 2012 16:02:17 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347656537; bh=fEgoLVMkaKstUeU9hx0rdCaYVKENHEE5P+qS7xX02yg=; h=In-Reply-To:References:Subject:From:Date:To:From; b=Okl3OmDXwZSPRMZzIr45b23hhnOhqTx4JSjhJljQivkthTLiR+tRaxAtbOYxctq5B NoY9mlBn2EHd5vpoxvm4sS+B8sq6tq4W37IKS9VV6vN9SuojF0diKOHULfTlK5RBrP 5M6FgUHpE7m8Z1MQi/4Hkd5NMZqOgW2n/Mp6bF84= Received: from [IPV6:2600:1003:b02e:15a2:d2a8:4e7:7fa4:d831] (unknown [IPv6:2600:1003:b02e:15a2:d2a8:4e7:7fa4:d831]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 024BBD04085; Fri, 14 Sep 2012 16:02:16 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <20120914201929.GK21618@verdi> References: <20120914201929.GK21618@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 14 Sep 2012 17:01:44 -0400 To: spfbis@ietf.org Message-ID: <45165b8b-d5c2-4128-ab31-0f7f180e35d3@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 Sep 2012 21:02:19 -0000 John Leslie wrote: >Murray S. Kucherawy wrote: >> >> I've tried to arrange it the way I believe protocols and algorithms >> are generally described, like a man page or an RFC would be, in this >> sort of order: >> >> INTRODUCTION: >> Section 1: Problem Statement/Introduction, Terminology >> Section 2: Basic Inputs, Basic Outputs, Establish Context >> >> DETAILS: >> Section 3: Policy Statement Syntax >> Section 4: Function Definition, i.e. How To Write check_host() >> Section 5: Enumerate and Describe Mechanisms >> Section 6: Enumerate and Describe Modifiers >> Section 7: Macros >> >> OPERATION: >> Section 8: Details about Outputs, Pedagogy, Interpretation >> Section 9: Recording Results in Headers >> Section 10: Affects on Infrastructure >> Section 11: Security Considerations >> >> REQUIRED STUFF: >> Section 12: Acknowledgements >> Section 13: IANA Considerations >> Section 14: References >> >> EXTRA BITS: >> Appendices > > It's hard to know what to make of this... My initial impression is >that we'd do better to consider what could be split off into an >Applicability Statement. > > For example, I would guess that Sections 9 and 10 deserve to be >split off, and I'm confused about Section 8. There would have to be >a Security Considerations as part of the protocol specification; but >there might also be Security Considerations that belong to an >Applicability Statement. > >> While talking to Pete about some charter topics in one of my other >> working groups, I did broach the subject of the split of spfbis into >a >> proposed standard and an informational, and he appeared to agree that >> it would only be a milestone change and not a full charter update >that >> would need IESG approval. Thus, procedurally, this is a lightweight >> move if we choose to make it. The co-chairs just need to decide upon >> editor(s) and away we go. > > For purposes of discussion, I strongly recommend that we consider >any possible need to "recharter" to do a split out-of-scope here. I'm >100% confident that Pete would take care of any such need if we show >him that the WG wants to split the document. > > IMHO, we're going 'round in circles largely because we have differing >opinions on what is protocol and what is operational advice. I see a split between people significant implementation/operational experience with SPF and standards professionals. My primary audience is not the IESG. It's the people who have to implement and deploy SPF based on 4408bis. If we can make a better document for them, some additional work to explain and evangelize doesn't bother me a bit. Scott K From dhc@dcrocker.net Fri Sep 14 14:59:51 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEEC21F8444 for ; Fri, 14 Sep 2012 14:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oI73UrqWYVRD for ; Fri, 14 Sep 2012 14:59:50 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B7BE621F8443 for ; Fri, 14 Sep 2012 14:59:50 -0700 (PDT) Received: from [192.168.1.8] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8ELxmiM026155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 14 Sep 2012 14:59:49 -0700 Message-ID: <5053A8CC.9050100@dcrocker.net> Date: Fri, 14 Sep 2012 14:59:40 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------070400050509090008030700" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 14 Sep 2012 14:59:50 -0700 (PDT) Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 21:59:51 -0000 This is a multi-part message in MIME format. --------------070400050509090008030700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/14/2012 12:12 PM, Murray S. Kucherawy wrote: > I've taken some time to construct a proposed restructuring of the > current spfbis draft. ... > SPF is a protocol, and this is the document that defines it. It has > however become somewhat bloated with documentation of nuance and other ... > It's important to note that absolutely nothing has been removed from > -07 here, ... > While talking to Pete about some charter topics in one of my other > working groups, I did broach the subject of the split of spfbis into a > proposed standard and an informational, and he appeared to agree that > it would only be a milestone change and not a full charter update that > would need IESG approval. Thus, procedurally, this is a lightweight > move if we choose to make it. I've attached a side-by-side of the existing and proposed tables of contents, so that it is possible to compare the two directly. Here's the way it looks to me: 1. Is it generally 'legal' to reorganize a specification document during an effort like spfbis and specifically legal for spfbis? My experience is that these sorts of efforts always permit reorganization of the specification document. And Murray's gotten specific agreement from our AD that it's legal. My experience also has been that part of gaining experience with a specification is learning how to make the document more helpful to new readers. And I think that's the interesting target audience for a spec. Not the current workers and not IETF management, but rather folk who are outside the SPF culture but who want to implement it. 2. Does the existing organization have some issues? A specification that has its first substantial section be "Operations" almost certainly can benefit from a better logical sequence. Operations needs to come after technical foundation and after protocol specification. Operation is about /use/. As another example, the current version has Macros coming after Recording the Result. Yet macros are part of the protocol engine, whereas Recording the Result refers to some that is done /after/ the protocol engine is completed. In other words, I think there is a pretty strong case to be made for trying to improve the document's organization. 3. Does the proposed reorganization increase clarity or otherwise improve the document? Murray's proposal looks pretty reasonable to me. It's always possible to debate some details. For example, I'm wondering whether his Section 7, Macros, shouldn't come two or three places earlier in the sequence, such as right after his 3 or 4. But that's a question, not a suggestion. Or maybe I'm wondering why check_host() doesn't come after Macros? But these are very narrow points. Overall the proposal looks like an improvement to me. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------070400050509090008030700 Content-Type: text/html; charset=UTF-8; name="Proposed-Reorg-Comparison.html" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Proposed-Reorg-Comparison.html" PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNl IiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxu cz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1l cXVpdj1Db250ZW50LVR5cGUgIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCIg Pjx0aXRsZT4xLkludHJvZHVjdGlvbjwvdGl0bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ PHc6V29yZERvY3VtZW50Pjx3OkJyb3dzZXJMZXZlbD5NaWNyb3NvZnRJbnRlcm5ldEV4cGxv cmVyNDwvdzpCcm93c2VyTGV2ZWw+PHc6RGlzcGxheUhvcml6b250YWxEcmF3aW5nR3JpZEV2 ZXJ5PjA8L3c6RGlzcGxheUhvcml6b250YWxEcmF3aW5nR3JpZEV2ZXJ5Pjx3OkRpc3BsYXlW ZXJ0aWNhbERyYXdpbmdHcmlkRXZlcnk+MjwvdzpEaXNwbGF5VmVydGljYWxEcmF3aW5nR3Jp ZEV2ZXJ5Pjx3OkRvY3VtZW50S2luZD5Eb2N1bWVudE5vdFNwZWNpZmllZDwvdzpEb2N1bWVu dEtpbmQ+PHc6RHJhd2luZ0dyaWRWZXJ0aWNhbFNwYWNpbmc+Ny44PC93OkRyYXdpbmdHcmlk VmVydGljYWxTcGFjaW5nPjx3OlZpZXc+V2ViPC93OlZpZXc+PHc6Q29tcGF0aWJpbGl0eT48 L3c6Q29tcGF0aWJpbGl0eT48dzpab29tPjA8L3c6Wm9vbT48L3c6V29yZERvY3VtZW50Pjwv eG1sPjwhW2VuZGlmXS0tPjxzdHlsZT4NCkBmb250LWZhY2V7DQpmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjsNCn0NCg0KQGZvbnQtZmFjZXsNCmZvbnQtZmFtaWx5OiLlrovkvZMi Ow0KfQ0KDQpAZm9udC1mYWNlew0KZm9udC1mYW1pbHk6IlNpbVN1biI7DQp9DQoNCkBmb250 LWZhY2V7DQpmb250LWZhbWlseToiU3ltYm9sIjsNCn0NCg0KQGZvbnQtZmFjZXsNCmZvbnQt ZmFtaWx5OiJBcmlhbCI7DQp9DQoNCkBmb250LWZhY2V7DQpmb250LWZhbWlseToiU2ltSGVp IjsNCn0NCg0KQGZvbnQtZmFjZXsNCmZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQp9DQoN CkBmb250LWZhY2V7DQpmb250LWZhbWlseToiV2luZ2RpbmdzIjsNCn0NCg0KQGZvbnQtZmFj ZXsNCmZvbnQtZmFtaWx5OiJCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8iOw0KfQ0KDQpwLnAw ew0KbWFyZ2luOjBwdDsNCm1hcmdpbi1ib3R0b206MC4wMDAxcHQ7DQptYXJnaW4tYm90dG9t OjBwdDsNCm1hcmdpbi10b3A6MHB0Ow0KdGV4dC1hbGlnbjpsZWZ0Ow0KZm9udC1zaXplOjEy LjAwMDBwdDsgZm9udC1mYW1pbHk6J1RpbWVzIE5ldyBSb21hbic7IH0NCg0KaDF7DQptYXJn aW4tYm90dG9tOjMuMDAwMHB0Ow0KbWFyZ2luLXRvcDoxMi4wMDAwcHQ7DQpwYWdlLWJyZWFr LWFmdGVyOnZvaWQ7DQp0ZXh0LWFsaWduOmxlZnQ7DQpmb250LXdlaWdodDpib2xkOyBmb250 LXN0eWxlOm5vcm1hbDsgZm9udC1zaXplOjE2LjAwMDBwdDsgZm9udC1mYW1pbHk6J0FyaWFs JzsgfQ0KDQpoMnsNCm1hcmdpbi1ib3R0b206My4wMDAwcHQ7DQptYXJnaW4tdG9wOjEyLjAw MDBwdDsNCnBhZ2UtYnJlYWstYWZ0ZXI6dm9pZDsNCnRleHQtYWxpZ246bGVmdDsNCmZvbnQt d2VpZ2h0OmJvbGQ7IGZvbnQtc3R5bGU6aXRhbGljOyBmb250LXNpemU6MTQuMDAwMHB0OyBm b250LWZhbWlseTonQXJpYWwnOyB9DQoNCmgzew0KbWFyZ2luLWJvdHRvbTozLjAwMDBwdDsN Cm1hcmdpbi10b3A6MTIuMDAwMHB0Ow0KcGFnZS1icmVhay1hZnRlcjp2b2lkOw0KdGV4dC1h bGlnbjpsZWZ0Ow0KZm9udC13ZWlnaHQ6Ym9sZDsgZm9udC1zaXplOjEzLjAwMDBwdDsgZm9u dC1mYW1pbHk6J0FyaWFsJzsgfQ0KDQpoNHsNCm1hcmdpbi1ib3R0b206My4wMDAwcHQ7DQpt YXJnaW4tdG9wOjEyLjAwMDBwdDsNCnBhZ2UtYnJlYWstYWZ0ZXI6dm9pZDsNCnRleHQtYWxp Z246bGVmdDsNCmZvbnQtd2VpZ2h0OmJvbGQ7IGZvbnQtc2l6ZToxNC4wMDAwcHQ7IGZvbnQt ZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nOyB9DQoNCmg1ew0KbWFyZ2luLWJvdHRvbTozLjAw MDBwdDsNCm1hcmdpbi10b3A6MTIuMDAwMHB0Ow0KcGFnZS1icmVhay1hZnRlcjp2b2lkOw0K dGV4dC1hbGlnbjpsZWZ0Ow0KZm9udC13ZWlnaHQ6Ym9sZDsgZm9udC1zdHlsZTppdGFsaWM7 IGZvbnQtc2l6ZToxMy4wMDAwcHQ7IGZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nOyB9 DQoNCmg2ew0KbWFyZ2luLWJvdHRvbTozLjAwMDBwdDsNCm1hcmdpbi10b3A6MTIuMDAwMHB0 Ow0KcGFnZS1icmVhay1hZnRlcjp2b2lkOw0KdGV4dC1hbGlnbjpsZWZ0Ow0KZm9udC13ZWln aHQ6Ym9sZDsgZm9udC1zaXplOjExLjAwMDBwdDsgZm9udC1mYW1pbHk6J1RpbWVzIE5ldyBS b21hbic7IH0NCg0KcC5wN3sNCm1hcmdpbi1ib3R0b206My4wMDAwcHQ7DQptYXJnaW4tdG9w OjEyLjAwMDBwdDsNCnBhZ2UtYnJlYWstYWZ0ZXI6dm9pZDsNCnRleHQtYWxpZ246bGVmdDsN CmZvbnQtd2VpZ2h0Om5vcm1hbDsgZm9udC1zaXplOjEyLjAwMDBwdDsgZm9udC1mYW1pbHk6 J1RpbWVzIE5ldyBSb21hbic7IH0NCg0KcC5wOHsNCm1hcmdpbi1ib3R0b206My4wMDAwcHQ7 DQptYXJnaW4tdG9wOjEyLjAwMDBwdDsNCnBhZ2UtYnJlYWstYWZ0ZXI6dm9pZDsNCnRleHQt YWxpZ246bGVmdDsNCmZvbnQtc3R5bGU6aXRhbGljOyBmb250LXNpemU6MTIuMDAwMHB0OyBm b250LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJzsgfQ0KDQpwLnA5ew0KbWFyZ2luLWJvdHRv bTozLjAwMDBwdDsNCm1hcmdpbi10b3A6MTIuMDAwMHB0Ow0KcGFnZS1icmVhay1hZnRlcjp2 b2lkOw0KdGV4dC1hbGlnbjpsZWZ0Ow0KZm9udC1zaXplOjExLjAwMDBwdDsgZm9udC1mYW1p bHk6J0FyaWFsJzsgfQ0KDQpzcGFuLjEwew0KZm9udC1zaXplOjEwLjAwMDBwdDsgZm9udC1m YW1pbHk6J1RpbWVzIE5ldyBSb21hbic7IH0NCg0KcC5wMTV7DQptYXJnaW4tYm90dG9tOjBw dDsNCm1hcmdpbi10b3A6MHB0Ow0KdGV4dC1hbGlnbjpsZWZ0Ow0KZm9udC1zaXplOjkuMDAw MHB0OyBmb250LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJzsgfQ0KDQpwLnAxNnsNCm1hcmdp bi1ib3R0b206MHB0Ow0KbWFyZ2luLXRvcDowcHQ7DQp0ZXh0LWFsaWduOmxlZnQ7DQpmb250 LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidUaW1lcyBOZXcgUm9tYW4nOyB9DQpAcGFn ZXttc28tcGFnZS1ib3JkZXItc3Vycm91bmQtaGVhZGVyOm5vOw0KCW1zby1wYWdlLWJvcmRl ci1zdXJyb3VuZC1mb290ZXI6bm87fUBwYWdlIFNlY3Rpb24wew0KbWFyZ2luLXRvcDo3Mi4w MDAwcHQ7DQptYXJnaW4tYm90dG9tOjcyLjAwMDBwdDsNCm1hcmdpbi1sZWZ0Ojg5Ljg1MDBw dDsNCm1hcmdpbi1yaWdodDo4OS44NTAwcHQ7DQpzaXplOjYxMi4zNTAwcHQgNzkwLjk1MDBw dDsNCmxheW91dC1ncmlkOjE0LjM1MDBwdDsNCn0NCmRpdi5TZWN0aW9uMHtwYWdlOlNlY3Rp b24wO308L3N0eWxlPjwvaGVhZD48Ym9keSBzdHlsZT0idGFiLWludGVydmFsOjIxcHQ7ICIg PjwhLS1TdGFydEZyYWdtZW50LS0+PGRpdiBjbGFzcz0iU2VjdGlvbjAiICBzdHlsZT0ibGF5 b3V0LWdyaWQ6MTQuMzUwMHB0Ow0KIiA+PHRhYmxlIHN0eWxlPSJib3JkZXItY29sbGFwc2U6 Y29sbGFwc2U7DQptc28tdGFibGUtbGF5b3V0LWFsdDpmaXhlZDsNCnBhZGRpbmc6MC4wMDAw cHQgNS40MDAwcHQgMC4wMDAwcHQgNS40MDAwcHQgOyAiID48dHI+PHRkIHdpZHRoPTI5NSAg dmFsaWduPXRvcCAgc3R5bGU9IndpZHRoOjIyMS43MDAwcHQ7IHBhZGRpbmc6MC4wMDAwcHQg NS40MDAwcHQgMC4wMDAwcHQgNS40MDAwcHQgOyBib3JkZXItbGVmdDowLjUwMDBwdCBzb2xp ZCByZ2IoMCwwLDApOyBtc28tYm9yZGVyLWxlZnQtYWx0OjAuNTAwMHB0IHNvbGlkIHJnYigw LDAsMCk7IGJvcmRlci1yaWdodDowLjUwMDBwdCBzb2xpZCByZ2IoMCwwLDApOyBtc28tYm9y ZGVyLXJpZ2h0LWFsdDowLjUwMDBwdCBzb2xpZCByZ2IoMCwwLDApOyBib3JkZXItdG9wOjAu NTAwMHB0IHNvbGlkIHJnYigwLDAsMCk7IG1zby1ib3JkZXItdG9wLWFsdDowLjUwMDBwdCBz b2xpZCByZ2IoMCwwLDApOyBib3JkZXItYm90dG9tOjAuNTAwMHB0IHNvbGlkIHJnYigwLDAs MCk7IG1zby1ib3JkZXItYm90dG9tLWFsdDowLjUwMDBwdCBzb2xpZCByZ2IoMCwwLDApOyAi ID48cCBjbGFzcz1wMCAgc3R5bGU9Im1hcmdpbi1ib3R0b206MHB0OyBtYXJnaW4tdG9wOjBw dDsgdGV4dC1hdXRvc3BhY2U6aWRlb2dyYXBoLW90aGVyOyAiID48c3BhbiBzdHlsZT0ibXNv LXNwYWNlcnVuOid5ZXMnOyBmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRz dHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID4xLkludHJvZHVjdGlvbjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEg U2FucyBNb25vJzsgIiA+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPXAwICBzdHls ZT0ibWFyZ2luLWJvdHRvbTowcHQ7IG1hcmdpbi10b3A6MHB0OyB0ZXh0LWF1dG9zcGFjZTpp ZGVvZ3JhcGgtb3RoZXI7ICIgPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46J3llcyc7IGZv bnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9u byc7ICIgPiZuYnNwOzIuT3BlcmF0aW9uJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8n OyAiID48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9cDAgIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjBwdDsgbWFyZ2luLXRvcDowcHQ7IHRleHQtYXV0b3NwYWNlOmlkZW9ncmFwaC1v dGhlcjsgIiA+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoneWVzJzsgZm9udC1zaXplOjku MDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+Jm5i c3A7My5TUEYmbmJzcDtSZWNvcmRzJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAi ID48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9cDAgIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjBwdDsgbWFyZ2luLXRvcDowcHQ7IHRleHQtYXV0b3NwYWNlOmlkZW9ncmFwaC1vdGhl cjsgIiA+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoneWVzJzsgZm9udC1zaXplOjkuMDAw MHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+Jm5ic3A7 NC5UaGUmbmJzcDtjaGVja19ob3N0KCkmbmJzcDtGdW5jdGlvbiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZl cmEgU2FucyBNb25vJzsgIiA+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPXAwICBz dHlsZT0ibWFyZ2luLWJvdHRvbTowcHQ7IG1hcmdpbi10b3A6MHB0OyB0ZXh0LWF1dG9zcGFj ZTppZGVvZ3JhcGgtb3RoZXI7ICIgPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46J3llcyc7 IGZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMg TW9ubyc7ICIgPiZuYnNwOzUuTWVjaGFuaXNtJm5ic3A7RGVmaW5pdGlvbnM8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBW ZXJhIFNhbnMgTW9ubyc7ICIgPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1wMCAg c3R5bGU9Im1hcmdpbi1ib3R0b206MHB0OyBtYXJnaW4tdG9wOjBwdDsgdGV4dC1hdXRvc3Bh Y2U6aWRlb2dyYXBoLW90aGVyOyAiID48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOid5ZXMn OyBmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5z IE1vbm8nOyAiID4mbmJzcDs2Lk1vZGlmaWVyJm5ic3A7RGVmaW5pdGlvbnM8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBW ZXJhIFNhbnMgTW9ubyc7ICIgPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1wMCAg c3R5bGU9Im1hcmdpbi1ib3R0b206MHB0OyBtYXJnaW4tdG9wOjBwdDsgdGV4dC1hdXRvc3Bh Y2U6aWRlb2dyYXBoLW90aGVyOyAiID48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOid5ZXMn OyBmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5z IE1vbm8nOyAiID4mbmJzcDs3LlJlY29yZGluZyZuYnNwO1RoZSZuYnNwO1Jlc3VsdCZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTon Qml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPXAwICBzdHlsZT0ibWFyZ2luLWJvdHRvbTowcHQ7IG1hcmdpbi10b3A6MHB0OyB0 ZXh0LWF1dG9zcGFjZTppZGVvZ3JhcGgtb3RoZXI7ICIgPjxzcGFuIHN0eWxlPSJtc28tc3Bh Y2VydW46J3llcyc7IGZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVh bSBWZXJhIFNhbnMgTW9ubyc7ICIgPiZuYnNwOzguTWFjcm9zPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5z IE1vbm8nOyAiID48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9cDAgIHN0eWxlPSJt YXJnaW4tYm90dG9tOjBwdDsgbWFyZ2luLXRvcDowcHQ7IHRleHQtYXV0b3NwYWNlOmlkZW9n cmFwaC1vdGhlcjsgIiA+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoneWVzJzsgZm9udC1z aXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsg IiA+Jm5ic3A7OS5JbXBsaWNhdGlvbnM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1wMCAgc3R5bGU9Im1hcmdpbi1ib3R0b206 MHB0OyBtYXJnaW4tdG9wOjBwdDsgdGV4dC1hdXRvc3BhY2U6aWRlb2dyYXBoLW90aGVyOyAi ID48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOid5ZXMnOyBmb250LXNpemU6OS4wMDAwcHQ7 IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID4mbmJzcDsxMC4m bmJzcDtTZWN1cml0eSZuYnNwO0NvbnNpZGVyYXRpb25zJm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBT YW5zIE1vbm8nOyAiID48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9cDAgIHN0eWxl PSJtYXJnaW4tYm90dG9tOjBwdDsgbWFyZ2luLXRvcDowcHQ7IHRleHQtYXV0b3NwYWNlOmlk ZW9ncmFwaC1vdGhlcjsgIiA+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoneWVzJzsgZm9u dC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25v JzsgIiA+Jm5ic3A7MTEuJm5ic3A7Q29udHJpYnV0b3JzJm5ic3A7YW5kJm5ic3A7QWNrbm93 bGVkZ2VtZW50cyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMDAwMHB0 OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPXAwICBzdHlsZT0ibWFyZ2luLWJvdHRvbTowcHQ7IG1h cmdpbi10b3A6MHB0OyB0ZXh0LWF1dG9zcGFjZTppZGVvZ3JhcGgtb3RoZXI7ICIgPjxzcGFu IHN0eWxlPSJtc28tc3BhY2VydW46J3llcyc7IGZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1m YW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPiZuYnNwOzEyLiZuYnNwO0lB TkEmbmJzcDtDb25zaWRlcmF0aW9ucyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsg IiA+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPXAwICBzdHlsZT0ibWFyZ2luLWJv dHRvbTowcHQ7IG1hcmdpbi10b3A6MHB0OyB0ZXh0LWF1dG9zcGFjZTppZGVvZ3JhcGgtb3Ro ZXI7ICIgPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46J3llcyc7IGZvbnQtc2l6ZTo5LjAw MDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPiZuYnNw OzEzLiZuYnNwO1JlZmVyZW5jZXM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjAw MDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1wMCAgc3R5bGU9Im1hcmdpbi1ib3R0b206MHB0 OyBtYXJnaW4tdG9wOjBwdDsgdGV4dC1hdXRvc3BhY2U6aWRlb2dyYXBoLW90aGVyOyAiID48 c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOid5ZXMnOyBmb250LXNpemU6OS4wMDAwcHQ7IGZv bnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID4mbmJzcDtBcHBlbmRp eCZuYnNwO0EuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQt ZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoneWVzJzsgZm9udC1zaXplOjkuMDAwMHB0OyBmb250 LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+Q29sbGVjdGVkJm5ic3A7 QUJORjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWls eTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPXAwICBzdHlsZT0ibWFyZ2luLWJvdHRvbTowcHQ7IG1hcmdpbi10b3A6MHB0 OyB0ZXh0LWF1dG9zcGFjZTppZGVvZ3JhcGgtb3RoZXI7ICIgPjxzcGFuIHN0eWxlPSJtc28t c3BhY2VydW46J3llcyc7IGZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0 cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPiZuYnNwO0FwcGVuZGl4Jm5ic3A7Qi48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVh bSBWZXJhIFNhbnMgTW9ubyc7ICIgPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLXNw YWNlcnVuOid5ZXMnOyBmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJl YW0gVmVyYSBTYW5zIE1vbm8nOyAiID5FeHRlbmRlZCZuYnNwO0V4YW1wbGVzJm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRz dHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9cDAgIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBwdDsgbWFyZ2luLXRvcDowcHQ7IHRleHQt YXV0b3NwYWNlOmlkZW9ncmFwaC1vdGhlcjsgIiA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOid5ZXMnOyBmb250LXNpemU6 OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID4m bmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoneWVzJzsgZm9u dC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25v JzsgIiA+Qi4xLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMDAwMHB0OyBmb250 LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJtc28tc3BhY2VydW46J3llcyc7IGZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9u dC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPlNpbXBsZSZuYnNwO0V4 YW1wbGVzJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wMDAwcHQ7IGZv bnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9cDAgIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBwdDsgbWFyZ2lu LXRvcDowcHQ7IHRleHQtYXV0b3NwYWNlOmlkZW9ncmFwaC1vdGhlcjsgIiA+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNh bnMgTW9ubyc7ICIgPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOid5 ZXMnOyBmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBT YW5zIE1vbm8nOyAiID4mbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1zcGFj ZXJ1bjoneWVzJzsgZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFt IFZlcmEgU2FucyBNb25vJzsgIiA+Qi4yLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46J3llcyc7IGZvbnQtc2l6 ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIg Pk11bHRpcGxlJm5ic3A7RG9tYWluJm5ic3A7RXhhbXBsZSZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEg U2FucyBNb25vJzsgIiA+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPXAwICBzdHls ZT0ibWFyZ2luLWJvdHRvbTowcHQ7IG1hcmdpbi10b3A6MHB0OyB0ZXh0LWF1dG9zcGFjZTpp ZGVvZ3JhcGgtb3RoZXI7ICIgPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wMDAwcHQ7IGZv bnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoneWVzJzsgZm9udC1zaXplOjkuMDAwMHB0OyBm b250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+Jm5ic3A7Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46J3llcyc7IGZvbnQtc2l6ZTo5LjAw MDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPkIuMy48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0Jp dHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i bXNvLXNwYWNlcnVuOid5ZXMnOyBmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidC aXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID5ETlNCTCZuYnNwO1N0eWxlJm5ic3A7RXhh bXBsZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWls eTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPXAwICBzdHlsZT0ibWFyZ2luLWJvdHRvbTowcHQ7IG1hcmdpbi10b3A6MHB0 OyB0ZXh0LWF1dG9zcGFjZTppZGVvZ3JhcGgtb3RoZXI7ICIgPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8n OyAiID4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoneWVzJzsgZm9u dC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25v JzsgIiA+Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46J3ll cyc7IGZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNh bnMgTW9ubyc7ICIgPkIuNC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjAwMDBw dDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOid5ZXMnOyBmb250LXNpemU6OS4wMDAw cHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID5NdWx0aXBs ZSZuYnNwO1JlcXVpcmVtZW50cyZuYnNwO0V4YW1wbGUmbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNh bnMgTW9ubyc7ICIgPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L3RkPjx0ZCB3aWR0aD0yOTUg IHZhbGlnbj10b3AgIHN0eWxlPSJ3aWR0aDoyMjEuNzUwMHB0OyBwYWRkaW5nOjAuMDAwMHB0 IDUuNDAwMHB0IDAuMDAwMHB0IDUuNDAwMHB0IDsgYm9yZGVyLWxlZnQ6bm9uZTsgOyBtc28t Ym9yZGVyLWxlZnQtYWx0Om5vbmU7IDsgYm9yZGVyLXJpZ2h0OjAuNTAwMHB0IHNvbGlkIHJn YigwLDAsMCk7IG1zby1ib3JkZXItcmlnaHQtYWx0OjAuNTAwMHB0IHNvbGlkIHJnYigwLDAs MCk7IGJvcmRlci10b3A6MC41MDAwcHQgc29saWQgcmdiKDAsMCwwKTsgbXNvLWJvcmRlci10 b3AtYWx0OjAuNTAwMHB0IHNvbGlkIHJnYigwLDAsMCk7IGJvcmRlci1ib3R0b206MC41MDAw cHQgc29saWQgcmdiKDAsMCwwKTsgbXNvLWJvcmRlci1ib3R0b20tYWx0OjAuNTAwMHB0IHNv bGlkIHJnYigwLDAsMCk7ICIgPjxwIGNsYXNzPXAwICBzdHlsZT0ibWFyZ2luLWJvdHRvbTow cHQ7IG1hcmdpbi10b3A6MHB0OyB0ZXh0LWF1dG9zcGFjZTppZGVvZ3JhcGgtb3RoZXI7ICIg PjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46J3llcyc7IGZvbnQtc2l6ZTo5LjAwMDBwdDsg Zm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPklOVFJPRFVDVElP Tjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTon Qml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25v JzsgIiA+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPXAwICBzdHlsZT0ibWFyZ2lu LWJvdHRvbTowcHQ7IG1hcmdpbi10b3A6MHB0OyB0ZXh0LWF1dG9zcGFjZTppZGVvZ3JhcGgt b3RoZXI7ICIgPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5 OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID4xPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1v bm8nOyAiID4uPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46J3llcyc7IGZvbnQt c2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7 ICIgPiZuYnNwO1Byb2JsZW0mbmJzcDtTdGF0ZW1lbnQvSW50cm9kdWN0aW9uLCZuYnNwO1Rl cm1pbm9sb2d5PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQt ZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9cDAgIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBwdDsgbWFyZ2luLXRv cDowcHQ7IHRleHQtYXV0b3NwYWNlOmlkZW9ncmFwaC1vdGhlcjsgIiA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMg TW9ubyc7ICIgPjI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9u dC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPi48L3NwYW4+PHNwYW4g c3R5bGU9Im1zby1zcGFjZXJ1bjoneWVzJzsgZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZh bWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+Jm5ic3A7QmFzaWMmbmJzcDtJ bnB1dHMsJm5ic3A7QmFzaWMmbmJzcDtPdXRwdXRzLCZuYnNwO0VzdGFibGlzaCZuYnNwO0Nv bnRleHQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1p bHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1wMCAgc3R5bGU9Im1hcmdpbi1ib3R0b206MHB0OyBtYXJnaW4tdG9wOjBw dDsgdGV4dC1hdXRvc3BhY2U6aWRlb2dyYXBoLW90aGVyOyAiID48c3BhbiBzdHlsZT0ibXNv LXNwYWNlcnVuOid5ZXMnOyBmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRz dHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID5ERVRBSUxTPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1v bm8nOyAiID4uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQt ZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9cDAgIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBwdDsgbWFyZ2luLXRv cDowcHQ7IHRleHQtYXV0b3NwYWNlOmlkZW9ncmFwaC1vdGhlcjsgIiA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMg TW9ubyc7ICIgPjM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9u dC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPi48L3NwYW4+PHNwYW4g c3R5bGU9Im1zby1zcGFjZXJ1bjoneWVzJzsgZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZh bWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+Jm5ic3A7UG9saWN5Jm5ic3A7 U3RhdGVtZW50Jm5ic3A7U3ludGF4PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w MDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9cDAgIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBw dDsgbWFyZ2luLXRvcDowcHQ7IHRleHQtYXV0b3NwYWNlOmlkZW9ncmFwaC1vdGhlcjsgIiA+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVh bSBWZXJhIFNhbnMgTW9ubyc7ICIgPjQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPi48 L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoneWVzJzsgZm9udC1zaXplOjkuMDAw MHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+Jm5ic3A7 RnVuY3Rpb24mbmJzcDtEZWZpbml0aW9uLCZuYnNwO2kuZS4mbmJzcDtIb3cmbmJzcDtUbyZu YnNwO1dyaXRlJm5ic3A7Y2hlY2tfaG9zdCgpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAi ID48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9cDAgIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjBwdDsgbWFyZ2luLXRvcDowcHQ7IHRleHQtYXV0b3NwYWNlOmlkZW9ncmFwaC1vdGhl cjsgIiA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0Jp dHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPjU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7 ICIgPi48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoneWVzJzsgZm9udC1zaXpl OjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+ Jm5ic3A7RW51bWVyYXRlJm5ic3A7YW5kJm5ic3A7RGVzY3JpYmUmbmJzcDtNZWNoYW5pc21z PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidC aXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9cDAgIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBwdDsgbWFyZ2luLXRvcDowcHQ7IHRl eHQtYXV0b3NwYWNlOmlkZW9ncmFwaC1vdGhlcjsgIiA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIg PjY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6 J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPi48L3NwYW4+PHNwYW4gc3R5bGU9Im1z by1zcGFjZXJ1bjoneWVzJzsgZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0 c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+Jm5ic3A7RW51bWVyYXRlJm5ic3A7YW5kJm5i c3A7RGVzY3JpYmUmbmJzcDtNb2RpZmllcnM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIg PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1wMCAgc3R5bGU9Im1hcmdpbi1ib3R0 b206MHB0OyBtYXJnaW4tdG9wOjBwdDsgdGV4dC1hdXRvc3BhY2U6aWRlb2dyYXBoLW90aGVy OyAiID48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0 c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+Nzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsg IiA+Ljwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOid5ZXMnOyBmb250LXNpemU6 OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID4m bmJzcDtNYWNyb3M8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9u dC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1wMCAgc3R5bGU9Im1hcmdpbi1ib3R0b206MHB0OyBtYXJnaW4t dG9wOjBwdDsgdGV4dC1hdXRvc3BhY2U6aWRlb2dyYXBoLW90aGVyOyAiID48c3BhbiBzdHls ZT0ibXNvLXNwYWNlcnVuOid5ZXMnOyBmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5 OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID5PUEVSQVRJT048L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJh IFNhbnMgTW9ubyc7ICIgPi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjAwMDBw dDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1wMCAgc3R5bGU9Im1hcmdpbi1ib3R0b206MHB0OyBt YXJnaW4tdG9wOjBwdDsgdGV4dC1hdXRvc3BhY2U6aWRlb2dyYXBoLW90aGVyOyAiID48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZl cmEgU2FucyBNb25vJzsgIiA+ODwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMDAw MHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+Ljwvc3Bh bj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOid5ZXMnOyBmb250LXNpemU6OS4wMDAwcHQ7 IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID4mbmJzcDtEZXRh aWxzJm5ic3A7YWJvdXQmbmJzcDtPdXRwdXRzLCZuYnNwO1BlZGFnb2d5LCZuYnNwO0ludGVy cHJldGF0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQt ZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9cDAgIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBwdDsgbWFyZ2luLXRv cDowcHQ7IHRleHQtYXV0b3NwYWNlOmlkZW9ncmFwaC1vdGhlcjsgIiA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMg TW9ubyc7ICIgPjk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9u dC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPi48L3NwYW4+PHNwYW4g c3R5bGU9Im1zby1zcGFjZXJ1bjoneWVzJzsgZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZh bWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+Jm5ic3A7UmVjb3JkaW5nJm5i c3A7UmVzdWx0cyZuYnNwO2luJm5ic3A7SGVhZGVyczwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25v JzsgIiA+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPXAwICBzdHlsZT0ibWFyZ2lu LWJvdHRvbTowcHQ7IG1hcmdpbi10b3A6MHB0OyB0ZXh0LWF1dG9zcGFjZTppZGVvZ3JhcGgt b3RoZXI7ICIgPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46J3llcyc7IGZvbnQtc2l6ZTo5 LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPjEw PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidC aXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID4uPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28t c3BhY2VydW46J3llcyc7IGZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0 cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPiZuYnNwO0FmZmVjdHMmbmJzcDtvbiZuYnNwO0lu ZnJhc3RydWN0dXJlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wMDAwcHQ7IGZv bnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9cDAgIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBwdDsgbWFyZ2lu LXRvcDowcHQ7IHRleHQtYXV0b3NwYWNlOmlkZW9ncmFwaC1vdGhlcjsgIiA+PHNwYW4gc3R5 bGU9Im1zby1zcGFjZXJ1bjoneWVzJzsgZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWls eTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+MTE8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMg TW9ubyc7ICIgPi48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoneWVzJzsgZm9u dC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25v JzsgIiA+Jm5ic3A7U2VjdXJpdHkmbmJzcDtDb25zaWRlcmF0aW9uczwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEg U2FucyBNb25vJzsgIiA+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPXAwICBzdHls ZT0ibWFyZ2luLWJvdHRvbTowcHQ7IG1hcmdpbi10b3A6MHB0OyB0ZXh0LWF1dG9zcGFjZTpp ZGVvZ3JhcGgtb3RoZXI7ICIgPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46J3llcyc7IGZv bnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9u byc7ICIgPlJFUVVJUkVEJm5ic3A7U1RVRkY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIg Pi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6 J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1wMCAgc3R5bGU9Im1hcmdpbi1ib3R0b206MHB0OyBtYXJnaW4tdG9wOjBwdDsg dGV4dC1hdXRvc3BhY2U6aWRlb2dyYXBoLW90aGVyOyAiID48c3BhbiBzdHlsZT0ibXNvLXNw YWNlcnVuOid5ZXMnOyBmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJl YW0gVmVyYSBTYW5zIE1vbm8nOyAiID4xMjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+ Ljwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOid5ZXMnOyBmb250LXNpemU6OS4w MDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID4mbmJz cDtBY2tub3dsZWRnZW1lbnRzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wMDAw cHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVyYSBTYW5zIE1vbm8nOyAiID48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9cDAgIHN0eWxlPSJtYXJnaW4tYm90dG9tOjBwdDsg bWFyZ2luLXRvcDowcHQ7IHRleHQtYXV0b3NwYWNlOmlkZW9ncmFwaC1vdGhlcjsgIiA+PHNw YW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoneWVzJzsgZm9udC1zaXplOjkuMDAwMHB0OyBmb250 LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+MTM8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9udC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJh IFNhbnMgTW9ubyc7ICIgPi48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoneWVz JzsgZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2Fu cyBNb25vJzsgIiA+Jm5ic3A7SUFOQSZuYnNwO0NvbnNpZGVyYXRpb25zPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wMDAwcHQ7IGZvbnQtZmFtaWx5OidCaXRzdHJlYW0gVmVy YSBTYW5zIE1vbm8nOyAiID48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9cDAgIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjBwdDsgbWFyZ2luLXRvcDowcHQ7IHRleHQtYXV0b3NwYWNl OmlkZW9ncmFwaC1vdGhlcjsgIiA+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjoneWVzJzsg Zm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBN b25vJzsgIiA+MTQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjAwMDBwdDsgZm9u dC1mYW1pbHk6J0JpdHN0cmVhbSBWZXJhIFNhbnMgTW9ubyc7ICIgPi48L3NwYW4+PHNwYW4g c3R5bGU9Im1zby1zcGFjZXJ1bjoneWVzJzsgZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZh bWlseTonQml0c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+Jm5ic3A7UmVmZXJlbmNlczwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0 c3RyZWFtIFZlcmEgU2FucyBNb25vJzsgIiA+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPXAwICBzdHlsZT0ibWFyZ2luLWJvdHRvbTowcHQ7IG1hcmdpbi10b3A6MHB0OyAiID48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMDAwMHB0OyBmb250LWZhbWlseTonQml0c3RyZWFt IFZlcmEgU2FucyBNb25vJzsgIiA+PG86cD48L286cD48L3NwYW4+PC9wPjwvdGQ+PC90cj48 L3RhYmxlPjxwIGNsYXNzPXAwICBzdHlsZT0ibWFyZ2luLWJvdHRvbTowcHQ7IG1hcmdpbi10 b3A6MHB0OyAiID48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOid5ZXMnOyBmb250LXNpemU6 MTIuMDAwMHB0OyBmb250LWZhbWlseTonVGltZXMgTmV3IFJvbWFuJzsgIiA+PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjwhLS1FbmRGcmFnbWVudC0tPjwvYm9keT48L2h0bWw+ --------------070400050509090008030700-- From superuser@gmail.com Fri Sep 14 15:07:07 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DA221F84A7 for ; Fri, 14 Sep 2012 15:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQg73Jp0ixgL for ; Fri, 14 Sep 2012 15:07:06 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 290D721F84DC for ; Fri, 14 Sep 2012 15:07:05 -0700 (PDT) Received: by lahm15 with SMTP id m15so3235685lah.31 for ; Fri, 14 Sep 2012 15:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W1X0N0wbfovJO8LUFHmpL4mvmS4cxMcyWv8Q8w++aV8=; b=01o4Fz1OxdexaVVQGNr2Q1zvgOLIn0jjldeNqjqXMmbIefeI5SLnFkLdIuwiWaNFBK NWzqtamTvzM0KOypNNAuk2yP3QAb3CxuN4Z5EHFZbUp6548pqaCvoJWm5o/mAVBwWSon uLVu/VJ7uMzMU6qQXvsqxSaxzrPgnOHVkok4JU0QsM+mhPO0EQKTr6LxtIw0Efc8aUjX szkQW7Yt2CHfRe2kX3BRNml1rhIXPh2CWeuM1hSH3Qc0OI28Q/61eExx36QebrgMvdLD kYAdB8vNgBjaqy29a0/6Eo5tQbexTgD2cgyveWW+uGnZj1ooiQtx9vFcHgdck1yH8Xv7 F7HQ== MIME-Version: 1.0 Received: by 10.112.88.73 with SMTP id be9mr1619197lbb.72.1347660425128; Fri, 14 Sep 2012 15:07:05 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Fri, 14 Sep 2012 15:07:05 -0700 (PDT) In-Reply-To: <5053A8CC.9050100@dcrocker.net> References: <5053A8CC.9050100@dcrocker.net> Date: Fri, 14 Sep 2012 15:07:05 -0700 Message-ID: From: "Murray S. Kucherawy" To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 Sep 2012 22:07:07 -0000 On Fri, Sep 14, 2012 at 2:59 PM, Dave Crocker wrote: > My experience also has been that part of gaining experience with a > specification is learning how to make the document more helpful to new > readers. And I think that's the interesting target audience for a spec. > Not the current workers and not IETF management, but rather folk who are > outside the SPF culture but who want to implement it. To clarify that point: I'm not trying to make it readable for the IESG. I'm pretty sure they'll get the material. Rather, the IESG is going to ask themselves this same question: Is the format of this document optimal for new readers? So I believe they and I have the same audience in mind. And given that, I think the layout of -07 can be improved, hence this work. > Or maybe I'm wondering why check_host() doesn't come after Macros? I considered that as well, inasmuch as check_host() implements macros, so defining them first makes sense. A valid suggestion. -MSK From spf2@kitterman.com Fri Sep 14 15:56:12 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A385721F84D5 for ; Fri, 14 Sep 2012 15:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xTFFxUweype for ; Fri, 14 Sep 2012 15:56:12 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 028AF21F84AE for ; Fri, 14 Sep 2012 15:56:12 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2DEEF20E40A6; Fri, 14 Sep 2012 18:56:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347663371; bh=kBAC5r38XaD67/WCG8+6Pf6ZShTAvVPENMhH8m1GSKs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iTCanhRYtybSWiGOTC/OyiNmK+FWepY0bKTuejv22/CoVor4upUkELXUWAZphu80W gqdDg0IpMvPvAJlCRYVaFgG4TNzrU14wRyXgYySX80rDWLB3fjuWi+p0ZwitArYEJ5 dj+OoAcHUgqqot7afQqpIQAANLNMCUOpz6z7fylA= Received: from scott-latitude-e6320.localnet (unknown [209.144.63.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DE50320E4089; Fri, 14 Sep 2012 18:56:10 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 14 Sep 2012 18:56:06 -0400 Message-ID: <2175624.gp8vsO4HOS@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-31-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: References: <5053A8CC.9050100@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 Sep 2012 22:56:12 -0000 "Murray S. Kucherawy" wrote: >On Fri, Sep 14, 2012 at 2:59 PM, Dave Crocker wrote: >> My experience also has been that part of gaining experience with a >> specification is learning how to make the document more helpful to >new >> readers. And I think that's the interesting target audience for a >spec. >> Not the current workers and not IETF management, but rather folk who >are >> outside the SPF culture but who want to implement it. > >To clarify that point: I'm not trying to make it readable for the >IESG. I'm pretty sure they'll get the material. Rather, the IESG is >going to ask themselves this same question: Is the format of this >document optimal for new readers? So I believe they and I have the >same audience in mind. And given that, I think the layout of -07 can >be improved, hence this work. > >> Or maybe I'm wondering why check_host() doesn't come after Macros? > >I considered that as well, inasmuch as check_host() implements macros, >so defining them first makes sense. A valid suggestion. The current document (4408) is the basis for multiple, interoperable implementations. Most of them done by people with little or no interaction with the SPF community. I once did a small consulting project for a large vendor to help them figure out how to implement SPF (I reviewed their design) and it turned out that virtually everything that was unclear to them was how Sender ID and SPF relate. SPF itself they were able to develop a design to implement just fine using RFC 4408. http://james.apache.org/jspf/ is a free software example. They had a few questions that they asked, but fundamentally, they implemented it on their own based on the specification and the associated test suite. Given the success of the current document, I think it deserves a certain degree of presumption of correctness. We have data to support it being effective. For any alternative arrangement or splitting it is a matter of speculation if it would better or not. Even if you think a new arrangement is better, I don't think that's enough. While new implementers are certainly A target audience, they are certainly not the only one. People updating existing implementations are also a target audience. I believe this will be much larger, but even if it's not, it will certainly exist. The more difficult we make it to understand what's changed between 4408 and 4408bis, the more difficult it will be for this class of users to correctly update to match what's in 4408bis. Any reorganization has a presumptive negative value that it needs to overcome. Finally, splitting into two documents makes things much harder to use. Not only does it require the reader to jump between documents, it substantially constrains our ability to make specific references between text (I'd be glad to be proven wrong on this if someone knows how). Currently in 4408bis there are links between various areas in the core protocol piece of SPF and the supporting information (section 9) that are to targets within the section. An HTML representation of 4408bis will have hyperlinks to the specific location. If some or all of what's in section 9 were in a separate document, such links could only be made to the document and not to specific targets within the document. This will make it more difficult, particularly for new people to navigate their way through the specs. IF my understanding is correct, I think it's a good reason NOT to split and sufficient on it's own, so there's no point in a document reorg that makes splitting easier. In the mean time, we're going to lose more time spinning our wheels on a decision that doesn't have a lot of potential to add significant value. In the mean time, so that Murray's diff will apply if there is rough consensus for his organization, I'm going to hold off on making local changes. I'd hate for him (or me) to have to redo the work. Even though I'm not supporting the result, I appreciate the effort he went to. Scott K From leibzon@gmail.com Fri Sep 14 16:41:13 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13FE21F84D8 for ; Fri, 14 Sep 2012 16:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMUbKcr85eJ7 for ; Fri, 14 Sep 2012 16:41:13 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7720B21F84B6 for ; Fri, 14 Sep 2012 16:41:12 -0700 (PDT) Received: by bkty12 with SMTP id y12so1426242bkt.31 for ; Fri, 14 Sep 2012 16:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=x6zkaSoI+ovhYIFqkZV5xXo6JQ+nWfH8oa/W23n6i5E=; b=Z1OIx7Np63lZLKqaBMdKO+5ZSr3TW+jNjIr6rNmgjWjFWQnDgvxdUuXcYplqFamicg LtXSC8k/nSAmy8NzDU7NOV57q6zn+NSpYgfKoaOs7YbQ7h/HPXHaWB6ud/hzVUw8KLks DnqmlVTGmo2AdKOg60trpqtfj9PLSKzbNA/4SJZlPAPn7u57I6c4G/bEbGfsHhfo0bu+ wIEtvPKgUtF2B+mEti/KvF1XqpPRslI/Yt+pdY7NsepPBoKlYSxHxm/Ojw8sHVSoppIw f9Lm8Fk879B87MTSlyHsVxGeTuL1gvkzQwUsjgz/P5VZ4ymDaH8u19a5i3jjMtpzaThz c60g== Received: by 10.204.156.73 with SMTP id v9mr2243469bkw.116.1347666071488; Fri, 14 Sep 2012 16:41:11 -0700 (PDT) MIME-Version: 1.0 Sender: leibzon@gmail.com Received: by 10.204.13.7 with HTTP; Fri, 14 Sep 2012 16:40:51 -0700 (PDT) In-Reply-To: References: From: William Leibzon Date: Fri, 14 Sep 2012 16:40:51 -0700 X-Google-Sender-Auth: TnZRN1uHZjftyVA8dKcv2bpW_OU Message-ID: To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=000e0ce038cc778b0a04c9b1f5c0 Cc: spfbis@ietf.org Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 14 Sep 2012 23:41:14 -0000 --000e0ce038cc778b0a04c9b1f5c0 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 14, 2012 at 1:59 PM, Murray S. Kucherawy wrote: > On Fri, Sep 14, 2012 at 1:41 PM, William Leibzon > wrote: > > I've been lurking and not posting but here I'd like to note that such > > re-organization is likely to go against original intent of SPF. The > intent > > was to have it published as a standard document and if part of it is > split > > into "informational" type document that is very different especially > given > > that SPF was published as experimental standard already. > > What's an "experimental standard"? > > In IETF terms, it's either Experimental or Proposed Standard. SPF is > the former. > I know what IETF terms are. But the use of SPF has been equivalent to proposed standard despite its official experimental status which was you know a political decision when disbanding MARID. That is why I think this group should treat changes from RFC4408 as somewhat similar to proposed to draft. And originally when I heard, I thought you would just bring SPF into official status and get errata in instead of doing so many changes and additions. > > In general I'm > > actually under the impression that instead of doing real "SPFbis" and > > polishing a doc (which we already did quite a bit of work on before) for > > proposed standard you're in fact starting back on MARID-like discussions > > that chair himself regarded as inappropriate. > > That's manifestly not what I'm proposing here. As I said, there's > complete preservation of the material with a couple of minor things > that I believe the WG was already trying on for size. I'm proposing > what I believe is an improvement in the presentation of the very same > material. How could that be construed as a re-hashing of off-topic > discussions? > I've heard of others calling to split it into multiple docs. I'm totally against this. But I'd like to cut down on so much language in current doc though. > This also very reminds me of > > when original SPF was sent to publication and then area director tried to > > change important SHOULD to some non-capitalized word right before it was > to > > be published hoping we'd not notice. This appears to be somewhat similar > on > > larger scale. Please keep in mind original intent of the document to > provide > > a standard way to protect your from abuse of MAIL FROM by spammers and > > fraudsters. > > I don't think any of the intent or the technical details have been > obscured. The material has just been reorganized. > Not picking specifically on this proposal, but I've had a problem with some of the things I could see from discussions (though I've only had enough time for quick-reading from July). You should not be downgrading language related to SPF FAIL results because fail is exactly what the original intent of SPF as a way to stop spoofing for those who want it. Its also exactly why there is a softer ~ which I happen to use myself more often. And though I'm not at all a fan of ptr macros either, they are part of original specification and implementations and removing them is only if there are security considerations (which I happen to think there are so here I agree). Let me put the challenge back to you: Why should we presume that the > organization and presentation of RFC4408 is optimal? Will the IESG, > now reviewing this as a Proposed Standard instead of the lower bar of > Experimental, agree that the older document got it completely right? > The material has been used and understood by countless developers. Unless there is a strong reason to believe the material is not clear and structure is bad, and such complaints come from developers rather than from folks here, the current structure should be considered good. William --000e0ce038cc778b0a04c9b1f5c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 14, 2012 at 1:59 PM, Murray S. Kucherawy <= superuser@gmail.co= m> wrote:
On Fri, Sep 14, 2012 at 1:41 PM, William Leibzon <william@leibzon.org> wrote:
> I've been lurking and not posting but here I'd like to note th= at such
> re-organization is likely to go against original intent of SPF. The in= tent
> was to have it published as a standard document and if part of it is s= plit
> into "informational" type document that is very different es= pecially given
> that SPF was published as experimental standard already.

What's an "experimental standard"?

In IETF terms, it's either Experimental or Proposed Standard. =A0SPF is=
the former.

I know what IETF terms are.= But the use of SPF has been equivalent to proposed standard despite its of= ficial experimental status which was you know a political decision when dis= banding MARID. That is why I think this group should treat changes from RFC= 4408 as somewhat similar to proposed to draft. And originally when I heard,= I thought you would just bring SPF into official status and get errata in = instead of doing so many changes and additions.
=A0
> In general I'm
> actually under the impression that instead of doing real "SPFbis&= quot; and
> polishing a doc (which we already did quite a bit of work on before) f= or
> proposed standard you're in fact starting back on MARID-like discu= ssions
> that chair himself regarded as inappropriate.

That's manifestly not what I'm proposing here. =A0As I said, = there's
complete preservation of the material with a couple of minor things
that I believe the WG was already trying on for size. =A0I'm proposing<= br> what I believe is an improvement in the presentation of the very same
material. =A0How could that be construed as a re-hashing of off-topic
discussions?

I've heard of others c= alling to split it into multiple docs. I'm totally against this. But I&= #39;d like to cut down on so much language in current doc though.

> This also very reminds me of
> when original SPF was sent to publication and then area director tried= to
> change important SHOULD to some non-capitalized word right before it w= as to
> be published hoping we'd not notice. This appears to be somewhat s= imilar on
> larger scale. Please keep in mind original intent of the document to p= rovide
> a standard way to protect your from abuse of MAIL FROM by spammers and=
> fraudsters.

I don't think any of the intent or the technical details have bee= n
obscured. =A0The material has just been reorganized.
<= br>
Not picking specifically on this proposal, but I've had a= problem with some of the things I could see from discussions (though I'= ;ve only had enough time for quick-reading from July).

You should not be downgrading language related to SPF F= AIL results because fail is exactly what the original intent of SPF as a wa= y to stop spoofing for those who want it. Its also exactly why there is a s= ofter ~ which I happen to use myself more often.

And though I'm not at all a fan of ptr macros eithe= r, they are part of original specification and implementations and removing= them is only if there are security considerations (which I happen to think= there are so here I agree).

Let me put the challenge back= to you: Why should we presume that the
organization and presentation of RFC4408 is optimal? =A0Will the IESG,
now reviewing this as a Proposed Standard instead of the lower bar of
Experimental, agree that the older document got it completely right?

The material has been used and understood by = countless developers. Unless there is a strong reason to believe the materi= al is not clear and structure is bad, and such complaints come from develop= ers rather than from folks here, the current structure should be considered= good.
=A0
William
--000e0ce038cc778b0a04c9b1f5c0-- From dhc@dcrocker.net Fri Sep 14 16:58:02 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B13821F84DC for ; Fri, 14 Sep 2012 16:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuHgqwcKD4l5 for ; Fri, 14 Sep 2012 16:58:02 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 080B521F84D5 for ; Fri, 14 Sep 2012 16:58:02 -0700 (PDT) Received: from [192.168.1.8] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8ENvxof028963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 Sep 2012 16:57:59 -0700 Message-ID: <5053C47F.60209@dcrocker.net> Date: Fri, 14 Sep 2012 16:57:51 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: William Leibzon References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 14 Sep 2012 16:58:00 -0700 (PDT) Cc: spfbis@ietf.org, "Murray S. Kucherawy" Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 23:58:02 -0000 On 9/14/2012 4:40 PM, William Leibzon wrote: > I know what IETF terms are. But the use of SPF has been equivalent to > proposed standard despite its official experimental status which was you > know a political decision when disbanding MARID. That is why I think > this group should treat changes from RFC4408 as somewhat similar to > proposed to draft. And originally when I heard, I thought you would just > bring SPF into official status and get errata in instead of doing so > many changes and additions. 1. We aren't doing "so many changes and additions". 2. It's a bit dangerous to impose additional rules on an IETF working group, based on your own assessment, given that there is already quite a bit of constraint on the process. 3. Your assessment -- or rather, the truth of it -- doesn't matter for the question at hand. For example, we made significant changes to the DKIM doc when moving from Proposed. The rationale for some of the changes was the same as here: documentation clarity. > The material has been used and understood by countless developers. > Unless there is a strong reason to believe the material is not clear and > structure is bad, and such complaints come from developers rather than > from folks here, the current structure should be considered good. > William I suspect you haven't done a survey of all the actual or potential readers of the documents. We can't know who has had troubles with the document. Rather than resorting to "lots of people were able to use it in its current form", it would be useful to focus on the issues that have been cited and the improvements in Murray's proposal. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Fri Sep 14 17:00:42 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAAF21F8528 for ; Fri, 14 Sep 2012 17:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtK7QIth3S-n for ; Fri, 14 Sep 2012 17:00:41 -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 5276B21F84F1 for ; Fri, 14 Sep 2012 17:00:41 -0700 (PDT) Received: (qmail 69747 invoked from network); 15 Sep 2012 00:00:40 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Sep 2012 00:00:40 -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:vbr-info; s=5053c528.xn--btvx9d.k1208; i=johnl@user.iecc.com; bh=k7IkUZbnVbWK2jIngXFsa/JiH1QjenjPKyeL0Gcdvhc=; b=k9fAXglful0gNrJEuwJV0Sob7qykmn618T99WF2qfbv5CNFc/TnjCJ8D2fiQvS6ZSrHaL64BUh97e8GBxQjoOzS5c3NbfHkTUFyXivxdQiro77kW9ER/fHGWB8MHSaVqjyIdt4ihV9R2n/ayeVSIT21sF2VxXtBIPmKqmpjkutE= 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:vbr-info; s=5053c528.xn--btvx9d.k1208; olt=johnl@user.iecc.com; bh=k7IkUZbnVbWK2jIngXFsa/JiH1QjenjPKyeL0Gcdvhc=; b=bs3BMf0tcWN9YiBshd7dVCsIVV02T3bWJlHVmzgPHKRq9l+qthq6pFbTQFXyj096UIIebeyb2ihXHhPxxe9EObMp8fGpzCFoKSw3pehbqcV5vlTCOUkq7n6knEuSPuxYmX85rYJrOw1RxKmRGNxeNelAlnQ0ZYHIAmPp4cDjofU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 15 Sep 2012 00:00:18 -0000 Message-ID: <20120915000018.81836.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: superuser@gmail.com Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 00:00:42 -0000 I'm with Dave, the reorg is easier to follow. I have some niggles, e.g. the section on "fail" result still has some local policy stuff that needs to either move to the end or disappear, but it's definitely an improvement. R's, John From spf2@kitterman.com Fri Sep 14 19:20:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4909B21E8039 for ; Fri, 14 Sep 2012 19:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ulv5I4nmPx8R for ; Fri, 14 Sep 2012 19:20:42 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC0121E8037 for ; Fri, 14 Sep 2012 19:20:42 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 86CE820E40A6; Fri, 14 Sep 2012 22:20:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347675641; bh=1GLcztL63/+GCc/V5BYnc+hQVZkc/z42bROdVUIW5Sg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=F4+rACLr6Rb1YVfvirl7jUoabth5EA/OqLfOR4PTAqMg+YsmktasRMgf7iYlcUhEt /ZRRpPjNG7jp6HmwoEZGmBg6p4XGeaRftGwVmAm9AOfNopPVAfEdwSnOWHMqTa1giX /O9NqaXPtP0MLWrYK/cK+YvA93TzePOHUYinxYSE= 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 5FEBC20E4089; Fri, 14 Sep 2012 22:20:40 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 14 Sep 2012 22:20:37 -0400 Message-ID: <1643479.U6Efqag6vq@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-31-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <5053C47F.60209@dcrocker.net> References: <5053C47F.60209@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 02:20:43 -0000 Dave Crocker wrote: > > >On 9/14/2012 4:40 PM, William Leibzon wrote: >> I know what IETF terms are. But the use of SPF has been equivalent to >> proposed standard despite its official experimental status which was >you >> know a political decision when disbanding MARID. That is why I think >> this group should treat changes from RFC4408 as somewhat similar to >> proposed to draft. And originally when I heard, I thought you would >just >> bring SPF into official status and get errata in instead of doing so >> many changes and additions. > >1. We aren't doing "so many changes and additions". > >2. It's a bit dangerous to impose additional rules on an IETF working >group, based on your own assessment, given that there is already quite >a >bit of constraint on the process. > >3. Your assessment -- or rather, the truth of it -- doesn't matter for >the question at hand. For example, we made significant changes to the >DKIM doc when moving from Proposed. The rationale for some of the >changes was the same as here: documentation clarity. > It was called that for process convenience, but at least some of this so called clarifications were substantiation semantic changes that changed DKIM. I am trying very hard to avoid a similar success with SPF. >> The material has been used and understood by countless developers. >> Unless there is a strong reason to believe the material is not clear >and >> structure is bad, and such complaints come from developers rather >than >> from folks here, the current structure should be considered good. >> William > >I suspect you haven't done a survey of all the actual or potential >readers of the documents. We can't know who has had troubles with the >document. > >Rather than resorting to "lots of people were able to use it in its >current form", it would be useful to focus on the issues that have been >cited and the improvements in Murray's proposal. > Having invested significant personal time over the course of seven years answering questions for both implementors and domain owners trying to deploy SPF, in addition to working on both SPF library implementations and code/process into integrate SPF into a variety of mail systems, I think I have at least as much experience as anyone on the list trying to help people through problems with RFC 4408 and more than most. Record publishers with questions typically have a hard time conceptualizing that the SPF record is intended to describe the outbound mail architecture of their domain(s). This is as foreign a concept to many of them as controlling open relays was in the 1990's. Many domain owners are very non-technical and they end up needing to have basic DNS concepts explained to them. I don't recall, except for making processing limits clearer (which we are doing) thinking the spec needed improvement from a publisher's perspective. I'm thinking back and I don't recall any issues for implementers that aren't documented in errata. That's the primary source for them. You'll also notice that it's been some years since new erratum were filed. Of course no one has done a survey of all actual or potential readers. It's a nonsense point. I don't know why you mention it. The fact is that the existing text and structure has demonstrated considerable success. Any alternative, by definition, has not. I had a chance to review Murray's proposal before it was published. It is different than the organization in RFC 4408. I don't find it better in any significant respect. Moving things like experimental history and such to the end make sense, but in terms of the reorganization of sections 2 through 9 into more sections and an additional stack of new appendices, I don't find it an improvement. It spreads things out over several sections so there is much more need to hop around the document when focusing on a single concept. I don't think it's an unreasonable way to go about things, I just don't think it's overall an improvement. The only issue I see is some people don't like the way RFC 4408 was structured and some others are convinced the IESG won't like it. Balanced against a demonstrated record of success, I think opinions of people who've never actually implemented or operated this (or particularly helped a broad base of others to do so) should not merit a lot of weight. Scott K From spf2@kitterman.com Fri Sep 14 19:22:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E7421E8039 for ; Fri, 14 Sep 2012 19:22:22 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAG4NauTHY7T for ; Fri, 14 Sep 2012 19:22:22 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CDEA821E8037 for ; Fri, 14 Sep 2012 19:22:21 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5DA2F20E40A6; Fri, 14 Sep 2012 22:22:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347675736; bh=OSi27HyBwwYwuXf1gKvur3WVO8ESi2XsSYSgt1Ip3Q8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=e+ahT+QbLPsdRR8TimZ1AqqRa7hTuwgMr4YutOIdHbBCeXCIa2XfEMcZBeQgo37Eu uCi07V3eBUrzUM6h4JK6UyiMkt1WYr3Ku+NJpzlqYW8kdurfw7lu7gTz221Nwo97DK FLRHpUaGf0TKRs9GRYyQnH3LxX7ylLHwdhedvjYU= 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 45E1920E4089; Fri, 14 Sep 2012 22:22:16 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 14 Sep 2012 22:22:15 -0400 Message-ID: <1487834.3pbuUXDoL2@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-31-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <20120915000018.81836.qmail@joyce.lan> References: <20120915000018.81836.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 02:22:22 -0000 On Saturday, September 15, 2012 12:00:18 AM John Levine wrote: > I'm with Dave, the reorg is easier to follow. I have some niggles, > e.g. the section on "fail" result still has some local policy stuff > that needs to either move to the end or disappear, but it's definitely > an improvement. Let's focus on one thing at at time. I understand you want to morph SPF into something other than what it was in RFC 4408, but let's focus on Murray's arrangement and not your issues with the content. Scott K From johnl@iecc.com Fri Sep 14 20:34:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD59B21F859E for ; Fri, 14 Sep 2012 20:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxJooDPop7Ed for ; Fri, 14 Sep 2012 20:34:47 -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 8C07921F859C for ; Fri, 14 Sep 2012 20:34:39 -0700 (PDT) Received: (qmail 12328 invoked from network); 15 Sep 2012 03:34:38 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Sep 2012 03:34:38 -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:vbr-info; s=5053f74e.xn--30v786c.k1208; i=johnl@user.iecc.com; bh=Ha2tuOvpDw16saYQAYfWrCXsZy1evZ8NEHfEWFBt1Qc=; b=d6WXWGohzSHqHNeg+xJ8jmMJEmbWI9kBUoBatiVqSrwBmlNwydSY39ow/dOk670k0B3lae399JT0HZdurCyk+vKrIqkHZ8bKqFHqq/+PBRqQKyCW0EwYxAQOg6tnaqn3fTPOoO2jmcTKtUi70iYkIySrLoD2RH1MGSncyrbfNeA= 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:vbr-info; s=5053f74e.xn--30v786c.k1208; olt=johnl@user.iecc.com; bh=Ha2tuOvpDw16saYQAYfWrCXsZy1evZ8NEHfEWFBt1Qc=; b=COGMauVnAE7HfV7JsZjrw8miSSXyYy7uXTfgcHZb9RiM2up8NqAQGYokwX439hhOH2HBX3kyELrwSIeBvx83I0jo8WH65eObbwD90YlW7dogZM5Xdf0a3nJHpc160wHOsJ12Ea6pvwtTMXMSfiwaKcGGbDyxSHOOSAS96LRSb1E= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 15 Sep 2012 03:34:15 -0000 Message-ID: <20120915033415.93367.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1487834.3pbuUXDoL2@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: spf2@kitterman.com Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 03:34:47 -0000 >> I'm with Dave, the reorg is easier to follow. I have some niggles, >> e.g. the section on "fail" result still has some local policy stuff >> that needs to either move to the end or disappear, but it's definitely >> an improvement. > >Let's focus on one thing at at time. I understand you want to morph SPF into >something other than what it was in RFC 4408, but let's focus on Murray's >arrangement and not your issues with the content. Like I said, the arrangement is an improvement, but there's still more that needs reorganizing. The item I mentioned is in the description of "fail" status, where there's a lengthy discussion of how to do an SMTP code 550 reject. That's local policy, so it belongs in the back, not in the normative part. R's, John From spf2@kitterman.com Fri Sep 14 20:41:25 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A85E21F85AA for ; Fri, 14 Sep 2012 20:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tr7UtBxTvMPn for ; Fri, 14 Sep 2012 20:41:24 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 92B9421F85A4 for ; Fri, 14 Sep 2012 20:41:24 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 138D920E40A6; Fri, 14 Sep 2012 23:41:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347680484; bh=n5D1L3vgzYBjHU71SP9/qT+M6uoafFTJqxS96j2E1Gc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=B6thDk1G3H5Rg+LtApUpUXlyREzKfXt/I4Nne3ZlTwZd0ast1hkQPAs8EjYi6FXiL HeG+JHi84jL6v5Mt3XnDjuiogwc3mUanfnTitzUYnkIJDNbYGndmdT/OQehaCCKo5U 2mtNEek6GGwumXysiPWSxyuZRCe+Y9Wn4aMxeKHk= 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 DECA420E4089; Fri, 14 Sep 2012 23:41:23 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 14 Sep 2012 23:41:22 -0400 Message-ID: <9232662.30p8krCyIe@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-31-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <20120915033415.93367.qmail@joyce.lan> References: <20120915033415.93367.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 03:41:25 -0000 On Saturday, September 15, 2012 03:34:15 AM John Levine wrote: > >> I'm with Dave, the reorg is easier to follow. I have some niggles, > >> e.g. the section on "fail" result still has some local policy stuff > >> that needs to either move to the end or disappear, but it's definitely > >> an improvement. > > > >Let's focus on one thing at at time. I understand you want to morph SPF > >into something other than what it was in RFC 4408, but let's focus on > >Murray's arrangement and not your issues with the content. > > Like I said, the arrangement is an improvement, but there's still more > that needs reorganizing. > > The item I mentioned is in the description of "fail" status, where > there's a lengthy discussion of how to do an SMTP code 550 reject. > That's local policy, so it belongs in the back, not in the normative > part. If you want to redefine what SPF is, that's true. I don't think we're chartered to do that. Despite what several people are saying SPF has always been more than address/hostname/IP in and result code out. Others have equally overstated what it was. RFC 4408 carefully takes no position on what action local policy should prefer. I think we're much better off to leave things like this alone and focus on finishing fixing actual errors and issues. The reorg is going to suck up a week or two and then I suspect that we'll argue about whether to narrow what SPF is or not until the chairs tell us to stop. Once both of those are done, maybe some actual work will get done. Scott K From agthisell@yahoo.com Fri Sep 14 21:09:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E3121F8512 for ; Fri, 14 Sep 2012 21:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqFRNdj9SEHI for ; Fri, 14 Sep 2012 21:09:02 -0700 (PDT) Received: from nm18-vm2.bullet.mail.ne1.yahoo.com (nm18-vm2.bullet.mail.ne1.yahoo.com [98.138.91.94]) by ietfa.amsl.com (Postfix) with SMTP id BDA7121F84E2 for ; Fri, 14 Sep 2012 21:09:01 -0700 (PDT) Received: from [98.138.90.57] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 15 Sep 2012 04:08:54 -0000 Received: from [98.138.89.170] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 15 Sep 2012 04:08:54 -0000 Received: from [127.0.0.1] by omp1026.mail.ne1.yahoo.com with NNFMP; 15 Sep 2012 04:08:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 87202.62491.bm@omp1026.mail.ne1.yahoo.com Received: (qmail 5517 invoked by uid 60001); 15 Sep 2012 04:08:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347682133; bh=u7nS2PO3x4kHBQvJaygIFt2AyqP5s9ut3Z3ouzRBRL8=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=ilnlaK06wUdW8HPDUwVCzTLOZN3lgLRCe5B4q+MTu6HlJ8Px345WS/MLrFfbdpaX5aC+sGLfBfoMz9sz+YXz0PJOfqh09hWXruBDwxun1DbDjv2rv05w7/Y5CsCHs3ZzlHV44JRGwLhfJD3JJSwUE6Sl/SZk5DDB/71eXh3Nlec= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=UiZdNQGmGfepj/FqqPrkxdYqTp/Io3ZVwBo9HWtruHFXP2t2xw1/rUAKLsQOPCWTaGMgeJICjgMVsqticOla4Kgv9/PjNboRxeZc4768oZRaHuktUrn9gWh2lQ1fCqg32Xtr29CXBniUSuiyj6ua9mdyNOO2icS4yyEos/0wnEU=; X-YMail-OSG: LsImAxsVM1ljvhUgcSff8nwxgWLiUIaCQKDx3C__ga4scLn cybJLA.VyoNWGYiOUB7mKfFy1tz8YaRaO2jPA.9i6TZUnyfWjDZx16oCdMhi nC8OdO2QOz.ZN4ETT0ZPrPjiFffLbVMrdy_ydRbv5KAEi1ZHF5T3FAZsCLmO kWMn4JNz5ehx7JFaILLeLe7qLpGZS6Nv0eqispy___yccpYYb4kueAPGG1zn 3MMwrrDBJfuwGmdTKkysFGOnqNQq0agXvieA.nEOHynJud4IadS073jw9tkU aWTFwiqRKGwfLnxlChLsb0EiUhtz0kB8gWPziI349AvHqB5DItEKpZgaQnq0 nmCsHPTqWRALZM2k4ihprOzM2jGzCPx5ev4L_fpPPrEXUwTjrfI_ZqYa8xMe r.Pg3DNDsnbNfrEPGT0NE3fGx_LiHVd3PQuBCKx4SKsNcj4J4WLwPrYdZj26 0mFo4qgeSbtDtfuk7NwM- Received: from [71.61.133.134] by web125104.mail.ne1.yahoo.com via HTTP; Fri, 14 Sep 2012 21:08:53 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347682133.5413.YahooMailClassic@web125104.mail.ne1.yahoo.com> Date: Fri, 14 Sep 2012 21:08:53 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 04:09:03 -0000 I'm trying to keep an open mind about reorganizing the draft, so I haven't responded sooner. That said, it appears that once again, Scott has said what I would have said, only clearer and less snide. I do not know the logic Mark Lentczner used when he reorganized Meng's draft, but over all, I think his editing made a significant improvement. Even things like the ordering of the Received-SPF section and the macro section in draft-lentczner can be easily justified in that macros are less important to most people. I've seen a lot of programmers who, when given new code to deal with, want to reorganize code so that "it makes sense". Different people learn stuff different ways, some what to know the results, some want to know the process, some want an over-view. I'm not convinced that any reorganization would be enough "better" to justify the change. I'll try sleeping on this, re-read stuff, and make more thoughtful responses tomorrow. Oh, I William, I really hope you stick around, you were always found your input to be very insightful/rational. From superuser@gmail.com Fri Sep 14 21:24:41 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB5721F848F for ; Fri, 14 Sep 2012 21:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tK+mi-9S-yRP for ; Fri, 14 Sep 2012 21:24:40 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 40F2021F8466 for ; Fri, 14 Sep 2012 21:24:40 -0700 (PDT) Received: by lbky2 with SMTP id y2so3401366lbk.31 for ; Fri, 14 Sep 2012 21:24:39 -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=KM9vY5ud4egSFHCkgVKWUtocO61PqYVlEfr+DGelBbg=; b=U0mWLZyuDTmx3TUSJPiRBSZCr0QA/JdmcWlKWKRYZwoVoRk2TXULeq3lOIdvhsPrjh Q/wh/S6137kciqXxHJnxg4GzcwEW8qNKszS1n80x2Rv3rn55DfjnrBJerV8ZAoOI40Io tg7uRB+Al9UlW2YV0Wn/4lF7FAD8RRnXOdISZWB10zLoiuK2pZvLiG/5PsWmg7lwCzWK isswlg6rJye/UD/kH6ckzjgc3G5V8qmAnGEHIKu/2KDXholQTrrrrWVOuxTexoJDwNwQ bAeHKU6KnEsKt8GRlp+PjXwDWfxzRh7aE7hmkRo2+oZe0pf2I76Y1CKi0sTPIHDhCzHI RiDg== MIME-Version: 1.0 Received: by 10.112.31.233 with SMTP id d9mr1807069lbi.116.1347683079134; Fri, 14 Sep 2012 21:24:39 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Fri, 14 Sep 2012 21:24:38 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Sep 2012 21:24:38 -0700 Message-ID: From: "Murray S. Kucherawy" To: William Leibzon Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 04:24:41 -0000 On Fri, Sep 14, 2012 at 4:40 PM, William Leibzon wrote: > I know what IETF terms are. But the use of SPF has been equivalent to > proposed standard despite its official experimental status which was you > know a political decision when disbanding MARID. That is why I think this > group should treat changes from RFC4408 as somewhat similar to proposed to > draft. And originally when I heard, I thought you would just bring SPF into > official status and get errata in instead of doing so many changes and > additions. I don't know of any restrictions on upgrades from Proposed to Draft that forbid reorganization of the material if there's consensus around a better presentation. > I've heard of others calling to split it into multiple docs. I'm totally > against this. But I'd like to cut down on so much language in current doc > though. Some of this work could also be used if that's the goal. > You should not be downgrading language related to SPF FAIL results because > fail is exactly what the original intent of SPF as a way to stop spoofing > for those who want it. Its also exactly why there is a softer ~ which I > happen to use myself more often. In my view, we've settled on the notion that SPF shouldn't be dictating what "fail" means to any given receiver. If that means downgrading the language from RFC4408, then that's the right thing to do. > The material has been used and understood by countless developers. Unless > there is a strong reason to believe the material is not clear and structure > is bad, and such complaints come from developers rather than from folks > here, the current structure should be considered good. That nobody has complained doesn't mean it can't be improved. -MSK From vesely@tana.it Sat Sep 15 02:54:40 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6660E21F84E2 for ; Sat, 15 Sep 2012 02:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.661 X-Spam-Level: X-Spam-Status: No, score=-4.661 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nicmDS4vqFID for ; Sat, 15 Sep 2012 02:54:39 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 84EBF21F84A7 for ; Sat, 15 Sep 2012 02:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347702876; bh=+2raPIrwQd3mLHDJFZaxM2QQH4gLAJckDhNNqw5USMY=; l=1013; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=NpO8QuAU3Tg7If+8CIMfoctld1jNVUZw6MiHrLKmUcv3Fx2KvOtzXxICVWm4KoONN 5TlHTviJ/J9C/vEfaqrRcj5HVkE2N2ZSm7pXdrprYJCj+BkcTZAP1MgNcvGZNtgfsy vBwEbkwjKNd5VBrlhu+zRQ+l+wq2Tu2yrzCEJh9k= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 15 Sep 2012 11:54:35 +0200 id 00000000005DC039.000000005054505B.00000874 Message-ID: <5054505B.8070800@tana.it> Date: Sat, 15 Sep 2012 11:54:35 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 09:54:40 -0000 On Fri 14/Sep/2012 21:12:04 +0200 Murray S. Kucherawy wrote: > > The diff is at http://www.blackops.org/~msk/spfbis/reorg.html. I look > forward to your comments. I think Murray's work is an important step in the right direction. Version -07 was still organized according to RFC 4408, with such idiosyncrasies as putting macros after Received-SPF rather than along with mechanisms and modifiers where they pertain. Separating filter handling from the result computation is a needed cleanup that this reorganization opens nicely. Since the early SPF drafts, which provided the actual basis for development, the passages about local policy have been progressively blurred and enlarged until RFC 4408. The result is only comprehensible by the developers who followed the whole history, and transmitted by word of mouth ever since --one of the recurring "mantra" was recently mentioned on this list. A Proposed Standard is not an esoteric cult scripture, though. +1 for adopting this change. From hsantos@isdg.net Sat Sep 15 01:16:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9E121F8566 for ; Sat, 15 Sep 2012 01:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.693 X-Spam-Level: X-Spam-Status: No, score=-101.693 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS8qwW1zmLPW for ; Sat, 15 Sep 2012 01:16:44 -0700 (PDT) Received: from ftp.catinthebox.net (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1B321F854A for ; Sat, 15 Sep 2012 01:16:41 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=645; t=1347696992; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=vf9eKR2xKek0/Ng5i2I0+GtFBsw=; b=izSsm3YkienaUuPrjzpD YgPxH6+DhF47kmRLV/HxqBAp0Ifn7g9OB3f9nM9k6lcV38ncZ8u0INA0BnvAH1as hF53u0gaaldsz7fdSuwzmWcAI7Pf9UHY2lWgqiyedZais6V5E8yPiAFA6mtgOZDs h6KFhLIpzqreA6wskGbkPJQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 15 Sep 2012 04:16:32 -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 3718767006.8753.2684; Sat, 15 Sep 2012 04:16:31 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=645; t=1347696763; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=XIHuDQs oOILqyBWBBdevN+MVDoX0qUOo3I6i/SKYc6o=; b=ijmY8NwSAcQ3BjJAwsVz5tc b2+DCK3kRDu1sPLUJ/SBGtim6AHYoGYyLol9OubEbACmArQ09g6ajjxlEsUQE6e6 Imleef6C5OzcO8RyJitbhg/col1vxnkeJX+ySR5z+P13qIvfwMeyhTA1y9xOUrNh ONvF5gWWe8u2HsnicOuY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sat, 15 Sep 2012 04:12:43 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 22594584.9.4444; Sat, 15 Sep 2012 04:12:43 -0400 Message-ID: <50543975.6040001@isdg.net> Date: Sat, 15 Sep 2012 04:16:53 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 15 Sep 2012 09:48:09 -0700 Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 08:16:45 -0000 Murray S. Kucherawy wrote: >> William Liebzon: >> >> You should not be downgrading language related to SPF FAIL results because >> fail is exactly what the original intent of SPF as a way to stop spoofing >> for those who want it. Its also exactly why there is a softer ~ which I >> happen to use myself more often. +1 > In my view, we've settled on the notion that SPF shouldn't be > dictating what "fail" means to any given receiver. -1. Who is we? Was there a consensus call? > If that means downgrading the language from RFC4408, then that's > the right thing to do. -1. It is not the right thing to do. -- HLS From agthisell@yahoo.com Sat Sep 15 14:00:30 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE54021F850D for ; Sat, 15 Sep 2012 14:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.294 X-Spam-Level: X-Spam-Status: No, score=-1.294 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdKYO69QxK1H for ; Sat, 15 Sep 2012 14:00:30 -0700 (PDT) Received: from nm29-vm4.bullet.mail.ne1.yahoo.com (nm29-vm4.bullet.mail.ne1.yahoo.com [98.138.91.189]) by ietfa.amsl.com (Postfix) with SMTP id 1830C21F84F2 for ; Sat, 15 Sep 2012 14:00:30 -0700 (PDT) Received: from [98.138.226.177] by nm29.bullet.mail.ne1.yahoo.com with NNFMP; 15 Sep 2012 21:00:27 -0000 Received: from [98.138.88.232] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 15 Sep 2012 21:00:26 -0000 Received: from [127.0.0.1] by omp1032.mail.ne1.yahoo.com with NNFMP; 15 Sep 2012 21:00:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 977640.68606.bm@omp1032.mail.ne1.yahoo.com Received: (qmail 96920 invoked by uid 60001); 15 Sep 2012 21:00:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347742826; bh=JGViF9rhE+NriAAincE06c5b98IDpJWs3hWKCP65ee8=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=DrDj1svi98hd295/c+EiwDoJikjGq7Mz00iYRzE33O5IfL46mkejD7CqrOJXy9sY6KRTW/vDF3Wngca6uXUKk80JFMs+RJ/um1pXJ+i8luoGojdyoqSun2RKt6ciYzIjXk6L59yLiY7b9lI2UWvfmt9438IKgEIvbFyeiq8r/dk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=vOxzjRn9MBExTf7rZj8c7z/IvZiaSiwN/q1DvVz1tK54RkDJ30reX8tHv01PUGiDs1mOZmWWTlviFalUSiHZ2Bs6cQIqIS2ryRcnaCv6jK91VPApW2ckAD51KmlM75CrGoV4VrMR07O+a9o2viWAgaCCYuZNEWrV3KmDKomF25k=; X-YMail-OSG: 9ZVBSaEVM1lreVKuxpuTioifqHmQFcbX1QaepcyhAyIPVgd Sa2TzZ25jATV_IXIgcgWcBpW9OkIDucwxjE_SSDS_LECHLjwDnJTVZ6BVqcW f0YnkcG7dlBsRSp.omXHWJ02UqzYXElhZFcEcQUJ63cc87nJetppjhIa8A16 BM22tuaXG967pieIBvbD6BbdWbkhnww.KeMmwt3lHg5fMwNqFxKQw4Xpq6xs rTdF50P72SbuCGuFYAEBLdjZiVvQ2S2NSpMN3VoB.xtQzDgxJLMIYi_sQD_x C8Ou1fzU2FR9cEb9_xIY_j2V3J5jVXVo0FWoh3F0RhzdRNC1KYEqxRCwAY46 1rXFJFyZNB9P2uYHR29J0F2bwONghw5EoZaJx.Bj5JORVk5DkoO9mZmv551T YEwUKX8UbkkVwIslNfvb4_t0xH5M_K97eoJkH6qKAiUy6N0C7c2_PqpclIdT Xantp6TIOoTKgB8eVB04- Received: from [71.61.133.134] by web125105.mail.ne1.yahoo.com via HTTP; Sat, 15 Sep 2012 14:00:26 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347742826.80986.YahooMailClassic@web125105.mail.ne1.yahoo.com> Date: Sat, 15 Sep 2012 14:00:26 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] reorganization, splitting and a wandering WG X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 21:00:30 -0000 OK, I've ponder this more, and to sum it up: * I do not think that we should reorganize the text. * I do not think that we should split the text. * I think the WG is wandering, addressing superficial items while there are technical problems with the draft. --- OK, as far as reorganization goes, I reviewed the changes between RFC 4408 and 4408bis-06(?) and found that it was already very hard to make sure that "simple changes" didn't actually change the semantics of RFC 4408. Sadly, I found quite a few things that did change RFC 4408. A wholesale reorganization of any kind would make impractical. Our charter says we aren't supposed to change RFC 4408. The particular proposed reorganization, I do not think it makes things dramatically better. Mark Lentzcner thought the Meng drafts needed reorganization, and with Mengs approval, did that. I don't think anyone thought it was perfect, but while developing RFC 4408, no one thought it was worth changing. Now, we have a new set of people who think that the spec should be reorganized. I'm sure 5 years down the line, someone else will propose reorganizing the text. The proposed reorganization also slips in a lot of editorial changes, and a lot of changes that I can't verify that it isn't making technical changes. It adds another 6 pages to the spec, I don't know why. --- I do not think we need to split the text. I would much rather see text eliminated than splitting. In particular, I think most of the new text (and a lot of the old text) in section 9 makes the spec worse. --- I think this WG is not making headway. I think any reorganization will burn a lot of time. Deciding if invalid domains should cause a permerror or not match is important. Deciding whether ptr: with too many PTR records causes a permerror or doesn't match is important. Deciding how too many mechanisms should be checked is important. Deciding the order of the macro and received-spf headers is not important. From vesely@tana.it Sun Sep 16 03:41:57 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6793121F848B for ; Sun, 16 Sep 2012 03:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.663 X-Spam-Level: X-Spam-Status: No, score=-4.663 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21gbtgGExIxc for ; Sun, 16 Sep 2012 03:41:56 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8454921F84C2 for ; Sun, 16 Sep 2012 03:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347792111; bh=Z+pd2RuIu8rbd/h4VCMwf5+zhjr/DaJ02trkYcyn7p4=; l=2341; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=QaLErZrbxFJooSMolQZTQe2oduTrx7vL2kmXwSCUV/rdo4yv+/EhaSh/AF9S3sWK6 pDyflTWNj3xJzQutStAF9/oYhh3N7pz/dwl/q4YuYhIDrl3H+GNPKVmyfErhZd9p5w 8rqZ9By5Xzo3QF+aKWifMFlYyB9Vj0wP90c61guw= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 16 Sep 2012 12:41:51 +0200 id 00000000005DC039.000000005055ACEF.00004D39 Message-ID: <5055ACEE.2000509@tana.it> Date: Sun, 16 Sep 2012 12:41:50 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <50543975.6040001@isdg.net> In-Reply-To: <50543975.6040001@isdg.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 10:41:57 -0000 Hector and all, particularly those of us who Scott identifies as having "significant implementation/operational experience with SPF" (as opposed to "standards professionals".) On Sat 15/Sep/2012 10:16:53 +0200 Hector Santos wrote: > Murray S. Kucherawy wrote: >> On Fri, Sep 14, 2012 at 4:40 PM, William Leibzon wrote: >> >>> You should not be downgrading language related to SPF FAIL >>> results because fail is exactly what the original intent of SPF >>> as a way to stop spoofing for those who want it. Its also >>> exactly why there is a softer ~ which I happen to use myself >>> more often. > > +1 Do we realize that, in order to downgrade something, that has to be resting at a status higher than zero? I've been told for years that SPF has no shadow of a mandated receiver behavior whatsoever, because it is a sender and not a receiver policy. OTOH, standards professionals say that specifying message disposition based on SPF results might be quite reasonable. That means it is possible to formulate the specification such that each part spells its topic straight, clear, and with the adequate amount of MUSTard. Who is preventing SPF from expressing its original intent, then? >> In my view, we've settled on the notion that SPF shouldn't be >> dictating what "fail" means to any given receiver. > > -1. Who is we? Was there a consensus call? That's not a new opinion, it's a fact. You know better than I that neither RFC 4408 nor bis-07 dictate anything to receivers. One has to read between the lines in order to grasp that meaning. You had to resort to a 2004 draft to find a "MAY reject". It is also a fact in terms of deployment. Since the +1 above was not meant for publishing ~, you know that -all is almost never honored. >> If that means downgrading the language from RFC4408, then that's >> the right thing to do. > > -1. It is not the right thing to do. Murray didn't downgrade, but insulate that text. A necessary step if we aim at making it sharp. Clearness matters more than page number. By denying consensus, neither Murray's step nor the split will occur. That's the wide and easy road to have our job done quickly, but it's a lost opportunity for SPF, and probably not the reason why you joined this WG. Please breath and, please, consider carefully. From spf2@kitterman.com Sun Sep 16 06:18:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDEB21F8510 for ; Sun, 16 Sep 2012 06:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pC6WHo42TypN for ; Sun, 16 Sep 2012 06:18:45 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7429821F84DC for ; Sun, 16 Sep 2012 06:18:45 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id A5774D04085; Sun, 16 Sep 2012 08:18:43 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347801523; bh=kY92qtBl2BRYPPlbneiQTLtw7ukJhMWbU/mhjxSe5sk=; h=In-Reply-To:References:Subject:From:Date:To:From; b=MQcIcmQKbfRPD5D0y4Q3RhE0zb0pDatq9K/XKYR6yaGFZBtLd70s19zVgLFZqUlXU VlydQW4qIhjsfAMKsDrt+wVD/uFIHCTR4BrNUGGXtb1eNbUyvEUw/590W/WavasRqc G/5QoLOnUrN5pPOIUENBBGM5E2LV1ZpU6CNzHQpo= Received: from [192.168.111.104] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id CB7DDD04005; Sun, 16 Sep 2012 08:18:42 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <5055ACEE.2000509@tana.it> References: <50543975.6040001@isdg.net> <5055ACEE.2000509@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 16 Sep 2012 09:18:41 -0400 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 13:18:46 -0000 Alessandro Vesely wrote: >Hector and all, particularly those of us who Scott identifies as >having "significant implementation/operational experience with SPF" >(as opposed to "standards professionals".) > >On Sat 15/Sep/2012 10:16:53 +0200 Hector Santos wrote: >> Murray S. Kucherawy wrote: >>> On Fri, Sep 14, 2012 at 4:40 PM, William Leibzon wrote: >>> >>>> You should not be downgrading language related to SPF FAIL >>>> results because fail is exactly what the original intent of SPF >>>> as a way to stop spoofing for those who want it. Its also >>>> exactly why there is a softer ~ which I happen to use myself >>>> more often. >> >> +1 > >Do we realize that, in order to downgrade something, that has to be >resting at a status higher than zero? I've been told for years that >SPF has no shadow of a mandated receiver behavior whatsoever, because >it is a sender and not a receiver policy. > >OTOH, standards professionals say that specifying message disposition >based on SPF results might be quite reasonable. That means it is >possible to formulate the specification such that each part spells its >topic straight, clear, and with the adequate amount of MUSTard. > >Who is preventing SPF from expressing its original intent, then? > >>> In my view, we've settled on the notion that SPF shouldn't be >>> dictating what "fail" means to any given receiver. >> >> -1. Who is we? Was there a consensus call? > >That's not a new opinion, it's a fact. You know better than I that >neither RFC 4408 nor bis-07 dictate anything to receivers. One has to >read between the lines in order to grasp that meaning. You had to >resort to a 2004 draft to find a "MAY reject". > >It is also a fact in terms of deployment. Since the +1 above was not >meant for publishing ~, you know that -all is almost never honored. Not quite. 4408/4408bis avoid specifying what receivers should DO with SPF fail. That's very different than not defining what SPF fail means. I agree that the current draft is equivalent to 4408 on the topic of what to do about SPF fail, after all, I wrote it. What I object to is the current jihad against anything that even vaguely looks like it might be receiver policy that will make the specification different than RFC 4408 and different than what we were chartered to produce. That set of objections is somewhat independent of my dislike of the reorg, although the reorg is related because it's a first step to removing things that I think should not be removed. Even if it weren't though, I still don't think it improves the document and we shouldn't do it. Scott K >>> If that means downgrading the language from RFC4408, then that's >>> the right thing to do. >> >> -1. It is not the right thing to do. > >Murray didn't downgrade, but insulate that text. A necessary step if >we aim at making it sharp. Clearness matters more than page number. > >By denying consensus, neither Murray's step nor the split will occur. > That's the wide and easy road to have our job done quickly, but it's >a lost opportunity for SPF, and probably not the reason why you joined >this WG. Please breath and, please, consider carefully. > >_______________________________________________ >spfbis mailing list >spfbis@ietf.org >https://www.ietf.org/mailman/listinfo/spfbis From johnl@iecc.com Sun Sep 16 10:52:10 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F71D21F8527 for ; Sun, 16 Sep 2012 10:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CWRnVsVKiCE for ; Sun, 16 Sep 2012 10:52:09 -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 8FE7721F8525 for ; Sun, 16 Sep 2012 10:52:09 -0700 (PDT) Received: (qmail 2658 invoked from network); 16 Sep 2012 17:52:06 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 16 Sep 2012 17:52:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=505611c5.xn--9vv.k1208; i=johnl@user.iecc.com; bh=jsWrKUSBsmiu64uhsh8bY6g57kWBXKmIdP0ZXXhkH1c=; b=HOUf+2Wbcrd8n0Q4oJfUz6iSyviSAveCz5P/LYV7mlE7dTxg2CwdPu7xGtLRYb14YxbmStax1N0OINVF0P7PR5gGzsC6gtHE/pj51XStM73Vp7CsUGEvwTSBJbYmECXhZ9z/pRD8M+rbOKW/8tFjDIENDIMb5asJ45FgB0UDTLw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=505611c5.xn--9vv.k1208; olt=johnl@user.iecc.com; bh=jsWrKUSBsmiu64uhsh8bY6g57kWBXKmIdP0ZXXhkH1c=; b=oNsfRNjbc2B4pikbfxgTexuhvxclSZeeTgIxJfpOpRa41FnMz3NBXX+mNLUYyn5KR2fB9kMjf4c/QtAEPDL0Rk5AoJijQEJXNPAYdVusvVkKIrgyaiY4FVGaT3+aPXBoMWpfq1eNpX2+SRwAHRvkhS8x7gt1TyAzV1EV4DTgdWw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 16 Sep 2012 17:51:43 -0000 Message-ID: <20120916175143.45136.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 17:52:10 -0000 >Not quite. 4408/4408bis avoid specifying what receivers should DO with SPF fail. That's >very different than not defining what SPF fail means. I agree that the current draft is >equivalent to 4408 on the topic of what to do about SPF fail, after all, I wrote it. Well, except that 2/3 of the text in the fail section is a description of how to do an SMTP time reject. I don't think it's totally off the wall to worry that people would misinterpret that to mean that it's the recommended receiver behavior, or what everyone does, rather than a fairly unusual receiver policy used only by a handful of small mail systems. Like I keep saying, if the example belongs anywhere, it belongs back with the other examples, not in the middle of the normative text. R's, John From superuser@gmail.com Sun Sep 16 11:22:41 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E2721F8440 for ; Sun, 16 Sep 2012 11:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbG5sKBjFt-8 for ; Sun, 16 Sep 2012 11:22:40 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2D821F8421 for ; Sun, 16 Sep 2012 11:22:39 -0700 (PDT) Received: by lahm15 with SMTP id m15so3959347lah.31 for ; Sun, 16 Sep 2012 11:22:39 -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=sA9CeQa6ixzdVQKuGvDJr6I4dd4ryqRs9KQVpfEWNIk=; b=qthskeNe8w9pODbNP1ktrxPDcBlLaM3jIA2Cb58kgwIdlzEEgPVFCldqEXGl5Lt5fM mAKHknCqvzxxk9HJuNRQ/s4Zp60XpodgWU1w9z1bM/HakgipMp3waxVFVkWe4aqKlnDA EkYeXz6j61T+zzqWOQbE1XLsMOF7KzbDLHjni0VO2j1JiFjHda0HMRDSsDvUNXAzkRFR Q8LxWu54/Uw28/j5k+NPK85HRWkMeRVNwY9hKKsLxw2sUi98t+u/TVJjW0EmS/XxTYDn o3qEzLErpQh2SHgEWYY6Y0QB5LQ4ucC8gtklbBhULOiHP8H+uhqbnJADfoYRzUaV5rxW jUTQ== MIME-Version: 1.0 Received: by 10.152.102.137 with SMTP id fo9mr7856592lab.35.1347819758936; Sun, 16 Sep 2012 11:22:38 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Sun, 16 Sep 2012 11:22:38 -0700 (PDT) In-Reply-To: References: <50543975.6040001@isdg.net> <5055ACEE.2000509@tana.it> Date: Sun, 16 Sep 2012 11:22:38 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 18:22:42 -0000 On Sun, Sep 16, 2012 at 6:18 AM, Scott Kitterman wrote: > What I object to is the current jihad against anything that even vaguely looks like it might be receiver policy that will make the specification different than RFC 4408 and different than what we were chartered to produce. Hyperbole aside, I don't believe any of the proposed changes fail to meet the charter. We are expressly chartered to fix errors and clarify things that need clarification. If there are participants who feel that the available text is in need of such, and are offering contributions to that end, then stomping all over those contributions and waving the charter at them isn't appropriate. Disagreement is fine, of course -- I fully realize that it's on me to garner consensus for a change like this -- but all of this aggressive dismissal is going just a bit too far. -MSK From spf2@kitterman.com Sun Sep 16 11:50:34 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0099D21F84E1 for ; Sun, 16 Sep 2012 11:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6Av6NIelypn for ; Sun, 16 Sep 2012 11:50:32 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 357AE21F84DD for ; Sun, 16 Sep 2012 11:50:32 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 65F2CD04085; Sun, 16 Sep 2012 13:50:29 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347821429; bh=Go1BF/ZTkKgPTKFyJHFj2JL2602/hcyuIzbVLi3lZ5M=; h=In-Reply-To:References:Subject:From:Date:To:From; b=gaMbt7H31UTh8KLkdF0mNYhmR5iOsOaYs3DXr9PZLwvimTX1G0wasqooS+nz4wdeT EIDeVg5xDyYoWcjgbzOiztzcn/2A4cuU1Imz3/gc8yYSKjNSvR0Pp5BFRCzKNsUB7z K3POBO4XYj+jGXIh/toIuPDrtH4roB9xigWYwvR8= Received: from [IPV6:2600:1007:b015:5166:ca52:f6fe:e326:eb86] (unknown [IPv6:2600:1007:b015:5166:ca52:f6fe:e326:eb86]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 9CF9AD04081; Sun, 16 Sep 2012 13:50:28 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <20120916175143.45136.qmail@joyce.lan> References: <20120916175143.45136.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 16 Sep 2012 14:50:25 -0400 To: spfbis@ietf.org Message-ID: <3f5b317e-9118-491d-8936-c17d57ebbe0c@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 18:50:34 -0000 John Levine wrote: >>Not quite. 4408/4408bis avoid specifying what receivers should DO >with SPF fail. That's >>very different than not defining what SPF fail means. I agree that >the current draft is >>equivalent to 4408 on the topic of what to do about SPF fail, after >all, I wrote it. > >Well, except that 2/3 of the text in the fail section is a description >of how to do an SMTP time reject. I don't think it's totally off the >wall to worry that people would misinterpret that to mean that it's >the recommended receiver behavior, or what everyone does, rather than >a fairly unusual receiver policy used only by a handful of small mail >systems. > >Like I keep saying, if the example belongs anywhere, it belongs back >with the other examples, not in the middle of the normative text. > I think the question of where best to put examples is both reasonable and well in scope. It does sound to me like you're worried people will believe the spec means things it doesn't say. We can't stop that. I think you worry too much. Approximately all the people I'm aware of that have been confused by this are active on this list, so I think it may bias your perspective of the risk. Scott K From hsantos@isdg.net Sun Sep 16 12:06:05 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D37A21F8510 for ; Sun, 16 Sep 2012 12:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.854 X-Spam-Level: X-Spam-Status: No, score=-101.854 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0Qy2SuYVOdY for ; Sun, 16 Sep 2012 12:06:04 -0700 (PDT) Received: from groups.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8C49F21F84A6 for ; Sun, 16 Sep 2012 12:06:04 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1618; t=1347822361; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=GT7YQTQkuNaG6q5+CJCG8jOuL4Q=; b=rR0Es7iYXBqGzv1f/ycG PLbLCrmbLVquwfyKG6nPM16XAXtXNctz7niNI4J3P4hBI6QWeDmehBlDCsfsxOZp gXLFWX1Pc4c2cq4wTINRZedVsd+BqkBK2PmHSExtY7zqUmct4tJK4hPWjhKeK8pv YC12uQUC8hw63GylkfJNY4Y= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 16 Sep 2012 15:06:01 -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 3844133450.9398.5276; Sun, 16 Sep 2012 15:05:59 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1618; t=1347822126; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=dt0rtNl NB3UdKTPtrCzsDz5QXXNGNV4ReljNxv3rGNQ=; b=UthPSw4bGjFB7M7PojAANCd b51wAt4LmkFolEYsQt6B2icVTAPtAhTff7ePE4REnLp9nXT4Jes7XXz2Fr054LhK 7TvHvidCUmGEIBiFPKhp3p2iUikwg6iTzeWgJQrNI7opD2mSTEs5rFL9MuGrm3Bl nKD1dsXSbJqZVznAE0EY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 16 Sep 2012 15:02:06 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 147957865.9.6216; Sun, 16 Sep 2012 15:02:06 -0400 Message-ID: <50562368.8070002@isdg.net> Date: Sun, 16 Sep 2012 15:07:20 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Scott Kitterman References: <20120916175143.45136.qmail@joyce.lan> <3f5b317e-9118-491d-8936-c17d57ebbe0c@email.android.com> In-Reply-To: <3f5b317e-9118-491d-8936-c17d57ebbe0c@email.android.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org Subject: [spfbis] Receiver-SPF Examples X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 19:06:05 -0000 Scott Kitterman wrote: >> Levine: >> Like I keep saying, if the example belongs anywhere, it belongs back >> with the other examples, not in the middle of the normative text. >> > I think the question of where best to put examples is both reasonable > and well in scope. For the record, there are already examples in section 7.1, in fact, only for a PASS and FAIL for a Received-SPF where the latter would only fit a accept+mark optional protocol behavior: Received-SPF: pass (mybox.example.org: domain of myname@example.com designates 192.0.2.1 as permitted sender) receiver=mybox.example.org; client-ip=192.0.2.1; envelope-from="myname@example.com"; helo=foo.example.com; Received-SPF: fail (mybox.example.org: domain of myname@example.com does not designate 192.0.2.1 as permitted sender) identity=mailfrom; client-ip=192.0.2.1; envelope-from="myname@example.com"; I was going to post an issue regarding providing additional realistic examples for each possible Received-SPF result (like pre-4408 had). It should be noted for the fail Received-SPF trace may not, in fact, exist when a rejection optional protocol behavior is active. Suggestion: For starter text, look at the pre-4408 draft where it has an example for each possible result and use something similar for 4408BIS. In fact, I recall using the comments in the trace as default text for our SPF API "check_host()". Finally, Add the note regarding the specific fail trace may not exist for SPF receivers deploying rejection at SMTP level before the DATA (Mail is not accepted and marked). -- HLS From spf2@kitterman.com Sun Sep 16 12:06:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E92E21F8510 for ; Sun, 16 Sep 2012 12:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4BG+c3y87kv for ; Sun, 16 Sep 2012 12:06:57 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 89BA921F84A6 for ; Sun, 16 Sep 2012 12:06:57 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id CC863D04085; Sun, 16 Sep 2012 14:06:56 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347822416; bh=zYX/5aE1NRn+ulsyEpvfS4biCZk0V9FPe9aAk5TeqA0=; h=In-Reply-To:References:Subject:From:Date:To:From; b=TzrOYrHO9LiJIzthcOoMhTmVYWNIJsGYmkTGAgvsm5t0FdxXLnZh8h746xkkBwqMR O+yhHufnTzrdRTvC3NGNJNWT8a85FJbZKx/hmY3f/KsizRkEi1uoKH0WCeZoh/nHNT Ffb7Krt5vV/QFuiLHZyBGwq+a298m5iKQbch9Pb0= Received: from [IPV6:2600:1007:b015:5166:6194:5c4f:592d:805f] (unknown [IPv6:2600:1007:b015:5166:6194:5c4f:592d:805f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E7A70D04081; Sun, 16 Sep 2012 14:06:53 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <50543975.6040001@isdg.net> <5055ACEE.2000509@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 16 Sep 2012 15:00:14 -0400 To: spfbis@ietf.org Message-ID: <17351d1f-f265-4a27-89d0-a29345a6e0eb@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 19:06:58 -0000 "Murray S. Kucherawy" wrote: >On Sun, Sep 16, 2012 at 6:18 AM, Scott Kitterman >wrote: >> What I object to is the current jihad against anything that even >vaguely looks like it might be receiver policy that will make the >specification different than RFC 4408 and different than what we were >chartered to produce. > >Hyperbole aside, I don't believe any of the proposed changes fail to >meet the charter. We are expressly chartered to fix errors and >clarify things that need clarification. If there are participants who >feel that the available text is in need of such, and are offering >contributions to that end, then stomping all over those contributions >and waving the charter at them isn't appropriate. Disagreement is >fine, of course -- I fully realize that it's on me to garner consensus >for a change like this -- but all of this aggressive dismissal is >going just a bit too far. > >-MSK The message you replied to wasn't about the reorganization. I'm not in favor of the reorganization for reasons I've specified, but I agree it's within the scope of our charter. It gets conflated with the local policy discussion for a variety of reasons. Sorry for not being clearer. Scott K From hsantos@isdg.net Sun Sep 16 12:42:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F90121F845A for ; Sun, 16 Sep 2012 12:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.858 X-Spam-Level: X-Spam-Status: No, score=-101.858 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzQkcXTS+y0Y for ; Sun, 16 Sep 2012 12:42:38 -0700 (PDT) Received: from groups.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id EE48021F8455 for ; Sun, 16 Sep 2012 12:42:37 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2388; t=1347824551; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=RezrO+FhQSkQALc1zgVLeu0MCaU=; b=uJfRyHe8eXZjqDeHgEtx +RobpKeNR8VitS3VSgH+yeha0V+WVHnMsHiw+ueC45d46AaK3YGwqmIprfPkahmz YHyc1h4cubIjNdxpUpBID8LTYoaxIf5jrOmhuyYC2Htd8mQw5AjH8bYnXgT9ZDTp F6Eh/hTW4Unz5Yd+UWJATE8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 16 Sep 2012 15:42:31 -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 3846323735.9398.6020; Sun, 16 Sep 2012 15:42:30 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2388; t=1347824316; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=1gaxKyi Dz02uqWVP9AqPbLvIv3jZm354qhq+KtX2iSI=; b=cvPJJFL3wVS7j7HiQA4aN+B goHJya+sfdC727bF1gBSMcVOKasBIYYoYR+Ffo/aB8sndveJwo9bdqCd4U7FQ0vn aUvRbK9WDi15UC0oYqtIlpKvLySUmu22guJEQ2yd7P21z130a0T2K7QSqAYKDh3l Ix5Uq9NDyTskz78RpvQg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Sun, 16 Sep 2012 15:38:36 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 150147021.9.6168; Sun, 16 Sep 2012 15:38:35 -0400 Message-ID: <50562BF5.1030000@isdg.net> Date: Sun, 16 Sep 2012 15:43:49 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 References: <20120916175143.45136.qmail@joyce.lan> <3f5b317e-9118-491d-8936-c17d57ebbe0c@email.android.com> <50562368.8070002@isdg.net> In-Reply-To: <50562368.8070002@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] Receiver-SPF Examples X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 19:42:39 -0000 BTW Scott, do you think the two Received-SPF examples of using a private IP subnet address (192) may be poor examples of a realistic SPF client/server transaction? In other words, this leads itself to the forwarding problem where the internal network (private side relay) erroneously continues to perform a check_host() and thus a guarantee to create a multi-hop changed DOMAIN::IP assertion failure. The examples should illustrate public IP address examples. Unless of course, the "Received-SPF: fail" trace example itself was to suppose to illustrate the forwarding problem that is should be avoided by the internal ADMD (no additional SPF checks internally). -- HLS Hector Santos wrote: > Scott Kitterman wrote: > >>> Levine: >>> Like I keep saying, if the example belongs anywhere, it belongs back >>> with the other examples, not in the middle of the normative text. >>> >> I think the question of where best to put examples is both reasonable >> and well in scope. > > For the record, there are already examples in section 7.1, in fact, only > for a PASS and FAIL for a Received-SPF where the latter would only fit a > accept+mark optional protocol behavior: > > Received-SPF: pass (mybox.example.org: domain of > myname@example.com designates 192.0.2.1 as permitted sender) > receiver=mybox.example.org; client-ip=192.0.2.1; > envelope-from="myname@example.com"; helo=foo.example.com; > > Received-SPF: fail (mybox.example.org: domain of > myname@example.com does not designate > 192.0.2.1 as permitted sender) > identity=mailfrom; client-ip=192.0.2.1; > envelope-from="myname@example.com"; > > > I was going to post an issue regarding providing additional realistic > examples for each possible Received-SPF result (like pre-4408 had). It > should be noted for the fail Received-SPF trace may not, in fact, exist > when a rejection optional protocol behavior is active. > > Suggestion: > > For starter text, look at the pre-4408 draft where it has an example for > each possible result and use something similar for 4408BIS. In fact, I > recall using the comments in the trace as default text for our SPF API > "check_host()". Finally, Add the note regarding the specific fail > trace may not exist for SPF receivers deploying rejection at SMTP level > before the DATA (Mail is not accepted and marked). > > -- > HLS From spf2@kitterman.com Sun Sep 16 13:22:12 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA2021F84EC for ; Sun, 16 Sep 2012 13:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0R6bGVckOQ6Z for ; Sun, 16 Sep 2012 13:22:11 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id A688F21F84EB for ; Sun, 16 Sep 2012 13:22:11 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id BAF44D04085; Sun, 16 Sep 2012 15:22:10 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347826930; bh=vgIyvijeB6li6209PMriO1Obz0wCROeaBA9WJDHkIeU=; h=In-Reply-To:References:Subject:From:Date:To:From; b=bnaPh9RzjHkerEeYuT4A2C1qXY2JCLgo8d2mjk+KTII2xfbUvpQBoKFnBOnXM3q9A fwG2teoA4tXa3bcw4eygFCTpFswaa4a3bguFP8n3abVnRnGBxdtA+rRUzYDVYuZyH6 Puonep0ugya6+5yr/2y5zkUKQSTH+pTEGLiKB5+Y= Received: from [IPV6:2600:1007:b026:a5db:ee92:9342:f6d9:d4c3] (unknown [IPv6:2600:1007:b026:a5db:ee92:9342:f6d9:d4c3]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 2DF21D04005; Sun, 16 Sep 2012 15:22:09 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <50562BF5.1030000@isdg.net> References: <20120916175143.45136.qmail@joyce.lan> <3f5b317e-9118-491d-8936-c17d57ebbe0c@email.android.com> <50562368.8070002@isdg.net> <50562BF5.1030000@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Sun, 16 Sep 2012 16:22:06 -0400 To: spfbis@ietf.org Message-ID: <4c2c2d38-d8be-4035-b8c0-542e3c0d446a@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Receiver-SPF Examples X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 20:22:12 -0000 Hector Santos wrote: >BTW Scott, do you think the two Received-SPF examples of using a >private IP subnet address (192) may be poor examples of a realistic >SPF client/server transaction? > >In other words, this leads itself to the forwarding problem where the >internal network (private side relay) erroneously continues to perform >a check_host() and thus a guarantee to create a multi-hop changed >DOMAIN::IP assertion failure. > >The examples should illustrate public IP address examples. Unless of >course, the "Received-SPF: fail" trace example itself was to suppose >to illustrate the forwarding problem that is should be avoided by the >internal ADMD (no additional SPF checks internally). > >-- >HLS > >Hector Santos wrote: >> Scott Kitterman wrote: >> >>>> Levine: >>>> Like I keep saying, if the example belongs anywhere, it belongs >back >>>> with the other examples, not in the middle of the normative text. >>>> >>> I think the question of where best to put examples is both >reasonable >>> and well in scope. >> >> For the record, there are already examples in section 7.1, in fact, >only >> for a PASS and FAIL for a Received-SPF where the latter would only >fit a >> accept+mark optional protocol behavior: >> >> Received-SPF: pass (mybox.example.org: domain of >> myname@example.com designates 192.0.2.1 as permitted sender) >> receiver=mybox.example.org; client-ip=192.0.2.1; >> envelope-from="myname@example.com"; helo=foo.example.com; >> >> Received-SPF: fail (mybox.example.org: domain of >> myname@example.com does not designate >> 192.0.2.1 as permitted sender) >> identity=mailfrom; client-ip=192.0.2.1; >> envelope-from="myname@example.com"; >> >> >> I was going to post an issue regarding providing additional realistic > >> examples for each possible Received-SPF result (like pre-4408 had). >It >> should be noted for the fail Received-SPF trace may not, in fact, >exist >> when a rejection optional protocol behavior is active. >> >> Suggestion: >> >> For starter text, look at the pre-4408 draft where it has an example >for >> each possible result and use something similar for 4408BIS. In fact, >I >> recall using the comments in the trace as default text for our SPF >API >> "check_host()". Finally, Add the note regarding the specific fail >> trace may not exist for SPF receivers deploying rejection at SMTP >level >> before the DATA (Mail is not accepted and marked). >> Those are the designated example IP addresses, not private addresses. Scott K From vesely@tana.it Mon Sep 17 02:37:02 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658BD21F85B8 for ; Mon, 17 Sep 2012 02:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.665 X-Spam-Level: X-Spam-Status: No, score=-4.665 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNS88mPHgg2A for ; Mon, 17 Sep 2012 02:37:01 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 51F6A21F85B4 for ; Mon, 17 Sep 2012 02:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347874616; bh=JmKk54PTxOlXaPRGKwl4F2KQlI1w5i9zxjQnlW1bads=; l=1545; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=c4eHQuuCcNDyYXQMORmtr+YVYU4hJISEvbaqxZux8Q/qvJcg00suqWypG647hswth OPyRwE5lO7W63raJoG1Ghyw85aa8HL8cFmUd5qucNQWnQq4vd5ajEmR5ImS63GU4MJ QFell9A/kZk7u87386IjZ3Iej2YIvw7dsDXuT7FE= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 17 Sep 2012 11:36:55 +0200 id 00000000005DC039.000000005056EF38.00007C7F Message-ID: <5056EF37.3030903@tana.it> Date: Mon, 17 Sep 2012 11:36:55 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <50543975.6040001@isdg.net> <5055ACEE.2000509@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 09:37:02 -0000 On Sun 16/Sep/2012 15:18:41 +0200 Scott Kitterman wrote: > > 4408/4408bis avoid specifying what receivers should DO with SPF > fail. That's very different than not defining what SPF fail > means. Hm... it means the receiver should do something with it, no? A quite elusive stance, really. > What I object to is the current jihad against anything that even > vaguely looks like it might be receiver policy that will make the > specification different than RFC 4408 and different than what we > were chartered to produce. s/even/only/ and I'm with it. We should either specify something clearly or not mention it at all, no matter how important it is. Now that brings up an interesting question on charter interpretation, where it limits changes to the SPF specification: I'm unable to contradict Hector when he says SPF always implied a domain intent and expectation for using a hard -ALL failure policy. Indeed, based on the I-D, we'd be charged for abetting behavior, if that were a crime, and convicted. I mean, SPF does specify receiver behavior, albeit between the lines. So, when the charter talks about clarifying the spec, what does it mean? We can pretend that SPF says nothing about it, and do that jihad. Or we can translate SPF's true meaning into clear text, for example as touched upon in the last sentence of http://www.ietf.org/mail-archive/web/spfbis/current/msg02870.html AFAICS, other approaches will result in a specification prone to misinterpretation, which I'd avoid if at all possible. From dhc@dcrocker.net Mon Sep 17 09:46:13 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6A021F8720 for ; Mon, 17 Sep 2012 09:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWY8PnpFMDIq for ; Mon, 17 Sep 2012 09:46:12 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 02F1321F8522 for ; Mon, 17 Sep 2012 09:46:12 -0700 (PDT) Received: from [192.168.1.7] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8HGkACf028404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Sep 2012 09:46:11 -0700 Message-ID: <505753D0.6010109@dcrocker.net> Date: Mon, 17 Sep 2012 09:46:08 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Scott Kitterman References: <5053C47F.60209@dcrocker.net> <1643479.U6Efqag6vq@scott-latitude-e6320> In-Reply-To: <1643479.U6Efqag6vq@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 17 Sep 2012 09:46:11 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 16:46:13 -0000 Scott, On 9/14/2012 7:20 PM, Scott Kitterman wrote: > Dave Crocker wrote: >> On 9/14/2012 4:40 PM, William Leibzon wrote: >>> I know what IETF terms are. But the use of SPF has been >>> equivalent to proposed standard despite its official >>> experimental status which was you know a political decision when >>> disbanding MARID. That is why I think this group should treat >>> changes from RFC4408 as somewhat similar to proposed to draft. >>> And originally when I heard, I thought you would just bring SPF >>> into official status and get errata in instead of doing so many >>> changes and additions. >> >> 1. We aren't doing "so many changes and additions". >> >> 2. It's a bit dangerous to impose additional rules on an IETF >> working group, based on your own assessment, given that there is >> already quite a bit of constraint on the process. >> >> 3. Your assessment -- or rather, the truth of it -- doesn't matter >> for the question at hand. For example, we made significant >> changes to the DKIM doc when moving from Proposed. The rationale >> for some of the changes was the same as here: documentation >> clarity. >> > > It was called that for process convenience, but at least some of > this so called clarifications were substantiation semantic changes > that changed DKIM. I am trying very hard to avoid a similar success > with SPF. 1. I cannot quite figure out what your use of "It" refers to. My guess is that it refers to the document status, but would appreciate your clarifying or at least confirming. 2. My point was that the 'Experimental' vs. 'Proposed' status difference does not matter with respect to the document reorganization being proposed. There is (typically) no restriction against such changes and certainly isn't one that I see in the SPFbis wg charter. 3. You appear to believe that changing document organization somehow changes SPF syntax or semantics. Please explain that view. 4. You assert that there are "substantial semantic changes that changed DKIM". First, DKIMbis had a significantly different charter, and second if you are going to invoke DKIM work as somehow relevant to SPFbis work, please provide direct explanation of the relevance. Presumably you are making a claim of substantial changes to DKIM semantics as a sort of justification for not making some sort of change to the SPF specification, but I can't tell how to apply it, since there are no specifics offered. >>> The material has been used and understood by countless >>> developers. Unless there is a strong reason to believe the >>> material is not clear >> and >>> structure is bad, and such complaints come from developers >>> rather >> than >>> from folks here, the current structure should be considered good. >>> William >> >> I suspect you haven't done a survey of all the actual or potential >> readers of the documents. We can't know who has had troubles >> with the document. >> >> Rather than resorting to "lots of people were able to use it in its >> current form", it would be useful to focus on the issues that have >> been cited and the improvements in Murray's proposal. >> > Having invested significant personal time over the course of seven > years answering questions for both implementors and domain owners > trying to deploy SPF, in addition to working on both SPF library > implementations and code/process into integrate SPF into a variety > of mail systems, I think I have at least as much experience as anyone > on the list trying to help people through problems with RFC 4408 and > more than most. This is called an appeal to authority: http://en.wikipedia.org/wiki/Argument_from_authority It has its uses, but typically is problematic. It often is used in place of providing meaningful justification for a view. And indeed I can't tell how you mean it to be applied here. In the extreme, it might be your assertion that because you have not seen certain issues over the course of your extended experience, they are not real or significant issues. Taken to its logical conclusion, that probably would mean ignoring all errata, except the ones that you have encountered. > Record publishers with questions typically have a hard time > conceptualizing that the SPF record is intended to describe the > outbound mail architecture of their domain(s). This is as foreign a > concept to many of them as controlling open relays was in the > 1990's. "outbound mail architecture" is an interesting phrase. I think I haven't heard it before, but it sounds potentially useful. The only caution I'd raise is the difference between protocol architecture, software architecture and operations (or deployment) architecture. In practical terms, people often get confused about the word 'architecture'. To avoid that confusion in this case, I might suggest saying 'outbound mail configuration', but that doesn't sound a sexy. > Many domain owners are very non-technical and they end up needing to > have basic DNS concepts explained to them. Of course, your comment is correct, but I am not understanding its relevance to the current discussion. One use that is probably not what you intended is that readers of RFCs also often do not understand some basic issues. Indeed, one of the things I like about IETF specification style is that we have a freedom to include tutorial material and, more general, to attend to the pedagogic aspects of specifications more than most other standards groups. This happens to be why I'm in favor of the proposed re-organization: It is cleaner and follows a better logical sequence. That makes is more helpful to a broader base of readers. > I don't recall, except for making processing limits clearer (which > we are doing) thinking the spec needed improvement from a > publisher's perspective. > > I'm thinking back and I don't recall any issues for implementers > that aren't documented in errata. That's the primary source for > them. You'll also notice that it's been some years since new erratum > were filed. > > Of course no one has done a survey of all actual or potential > readers. It's a nonsense point. I don't know why you mention it. It was my way of suggesting that your apparently relying only on your personal experience is a form of statistics sampling error. When making claims about a population -- such as the entire set of existing and potential readers of SPFbis -- it is almost never sufficient to cite only one's own experience, no matter how extensive. It's relevant, but not sufficient. > The fact is that the existing text and structure has demonstrated > considerable success. Any alternative, by definition, has not. The original DKIM spec also demonstrated quite a bit of success. So when we began its -bis effort, it was interesting to discover massive specification errors in parts of its formal details. Success of a document version is important, but, again, not definitive. > I had a chance to review Murray's proposal before it was published. > It is different than the organization in RFC 4408. I don't find it > better in any significant respect. Moving things like experimental > history and such to the end make sense, but in terms of the > reorganization of sections 2 through 9 into more sections and an > additional stack of new appendices, I don't find it an improvement. > It spreads things out over several sections so there is much more > need to hop around the document when focusing on a single concept. I > don't think it's an unreasonable way to go about things, I just don't > think it's overall an improvement. Please explain the claim that it requires more hopping around to use. My own reading is that it provides more tightly coherent sequences -- although I and others have noted possible ways to improve the proposed organization further -- which is exactly the opposite interpretation from yours. > The only issue I see is some people don't like the way RFC 4408 was > structured and some others are convinced the IESG won't like it. I think you've made the IESG reference a few times. While there are some cases of possibly needing to pay attention to likely IESG issues, this hasn't been one of them, as I recall. So I don't know why you are citing it. > Balanced against a demonstrated record of success, I think opinions > of people who've never actually implemented or operated this (or > particularly helped a broad base of others to do so) should not > merit a lot of weight. Perhaps we can focus on the substance of suggested changes, rather than purported attributes of the speakers? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@elandsys.com Mon Sep 17 10:08:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B088C21F8605 for ; Mon, 17 Sep 2012 10:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXEcNwPiKUMs for ; Mon, 17 Sep 2012 10:08:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2B421F85FC for ; Mon, 17 Sep 2012 10:08:02 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.146]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8HH7nQp003915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Sep 2012 10:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347901681; bh=PrTmKe/5Ap0+kXp4h3SZUvG4Pj5iWCcGbq7sQeDTgNI=; h=Date:To:From:Subject:Cc; b=NeCXedw2sQO+Wcwer76+6rfrjFqT5senByWR/LT8Z1zsjsgRpY/ZKSIZlD6Bc9dRX umtZsHU+jLjtcRkHQgtnZWnf/V8VbaDXTbN5lj4HiqlJeHixaTm/dPJAvFcj8mbikv Q48VVez5WmsD86WT3iCBGNk+6eqeF58G2Qj8ZvGs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347901681; i=@elandsys.com; bh=PrTmKe/5Ap0+kXp4h3SZUvG4Pj5iWCcGbq7sQeDTgNI=; h=Date:To:From:Subject:Cc; b=0j6dICjhJyEOD1tzA10ts4VCmS/mSU7fpY64iH+of+AGwxcmhn9+pELNsVFFd1k6G ih1Y5eICriz97VC57I8RBW8GfPJt/q+4yCYeh9PtU9XqncpkVqwPiAHq2JvZ1U0M/E GrIRhbQwgOjRIA6K25vDdMzub+2mzc87/SwMGnMo= Message-Id: <6.2.5.6.2.20120917100318.0aa2a480@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 17 Sep 2012 10:07:19 -0700 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis-chairs@tools.ietf.org Subject: [spfbis] SPFBIS guidance X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 17:08:03 -0000 Our guidance to the WG is to review draft-ietf-spfbis-4408bis and see that it: 1. Uses consistent terminology. 2. Is in line with the RFCs cited as normative references. 3. Does not restate material from other RFCs as normative text. 4. Does not contain advocacy material. 5. Does not discuss about "best practices" or "how-to". 6. Does not promote any method under the disguise of interoperability or security. Receiver policy is out of scope for a specification about "Sender Policy Framework". Andrew Sullivan & S. Moonesamy, SPFBIS WG co-chairs From dotzero@gmail.com Mon Sep 17 10:12:51 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB7F21F84D5 for ; Mon, 17 Sep 2012 10:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gefooQa+oIeE for ; Mon, 17 Sep 2012 10:12:49 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA4EC21F84D3 for ; Mon, 17 Sep 2012 10:12:48 -0700 (PDT) Received: by qafi29 with SMTP id i29so1771454qaf.10 for ; Mon, 17 Sep 2012 10:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z3U+uu4bzVheMQII8RcmuPW69panldn6zRqDJvPmebY=; b=HbSK2bZsCZ9voI8vIBqZvw2CClKeoVPQSYkQHisfI39eS6j45jzInPqew4pW4vNHOb cwMPaVxEVH8c7uFMVTJaa+Tjsz3I0dhE/ayc8eYawD0nEYzoz7x6uBcpkv1qFFa9zAk5 bZKeLUKYVDRphP5oL9Vhq5iW+3lxvJaIGw6z61zYlojh5nw3lGM/EeAqNW0le758pv+E dm6IdjBkiGEyqPra157j62wjqlExtdQGF5bcTL2mxmDKdbtKKJQDC/utOR1bxUJ+cbXU xuyx/0DWR3E8FWrz9BHtrw8PZcrUHoQ9HJbQH4NahALYEEnlduJpvEeWHRPFQw2kDkc5 JyXw== MIME-Version: 1.0 Received: by 10.224.189.12 with SMTP id dc12mr28920475qab.59.1347901968393; Mon, 17 Sep 2012 10:12:48 -0700 (PDT) Received: by 10.49.133.168 with HTTP; Mon, 17 Sep 2012 10:12:48 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120917100318.0aa2a480@elandnews.com> References: <6.2.5.6.2.20120917100318.0aa2a480@elandnews.com> Date: Mon, 17 Sep 2012 13:12:48 -0400 Message-ID: From: Dotzero To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] SPFBIS guidance X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 17:12:51 -0000 Thank you for providing this guidance to the group. Mike On Mon, Sep 17, 2012 at 1:07 PM, S Moonesamy wrote: > Our guidance to the WG is to review draft-ietf-spfbis-4408bis and see that > it: > > 1. Uses consistent terminology. > > 2. Is in line with the RFCs cited as normative references. > > 3. Does not restate material from other RFCs as normative text. > > 4. Does not contain advocacy material. > > 5. Does not discuss about "best practices" or "how-to". > > 6. Does not promote any method under the disguise of interoperability > or security. > > Receiver policy is out of scope for a specification about "Sender Policy > Framework". > > Andrew Sullivan & S. Moonesamy, SPFBIS WG co-chairs > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From superuser@gmail.com Mon Sep 17 13:37:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD4B21F84D5 for ; Mon, 17 Sep 2012 13:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImXZuXq0y8FO for ; Mon, 17 Sep 2012 13:37:08 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C106F21F8628 for ; Mon, 17 Sep 2012 13:37:07 -0700 (PDT) Received: by lahm15 with SMTP id m15so4787417lah.31 for ; Mon, 17 Sep 2012 13:37:06 -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=YaRImwqdhywC9YY1IugLJKv9Jo+kusq+A1wmDyjNiH8=; b=layqelTmy5tMdCFY1Ys0Ofe0Cv3JK3KQ7PCd6/4XpwnZzQmVIUyfPlZaOE3arWFOQ4 5PnyXCHJg2nLWSX8iSFz79xTVQfcJkgA9sg18s3lAOri4mxUA3R9bRfEPdYHE63b/Bg7 tem3/pqwOTMm0Pt3Si2/hcbxHs6NoGN6f3mH7pNaPUwsjynfk6uGjeg1JhUoeSXgggfw 5krokuu+aI+3t0azQ+lzRNC6w2gzer4tpRJXDqzp9dtjVFFvsqk2DFs8EoXqfz5xvBXz GI2P/1PCNXyMwaPu5gpGESpYz4BjV3QEvHMBu1mYc/7+jlLrOo15iBM33Q+BfCKEl/uQ QGxQ== MIME-Version: 1.0 Received: by 10.152.104.145 with SMTP id ge17mr10708464lab.34.1347914226413; Mon, 17 Sep 2012 13:37:06 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Mon, 17 Sep 2012 13:37:06 -0700 (PDT) In-Reply-To: <505753D0.6010109@dcrocker.net> References: <5053C47F.60209@dcrocker.net> <1643479.U6Efqag6vq@scott-latitude-e6320> <505753D0.6010109@dcrocker.net> Date: Mon, 17 Sep 2012 13:37:06 -0700 Message-ID: From: "Murray S. Kucherawy" To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org, Scott Kitterman Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 20:37:08 -0000 On Mon, Sep 17, 2012 at 9:46 AM, Dave Crocker wrote: >> The only issue I see is some people don't like the way RFC 4408 was >> structured and some others are convinced the IESG won't like it. > > I think you've made the IESG reference a few times. While there are some > cases of possibly needing to pay attention to likely IESG issues, this > hasn't been one of them, as I recall. So I don't know why you are citing > it. I'm the one who first raised that concern. In my experience with getting documents through IESG review, the flow of a document, especially a proposed standard, is actually a common thing upon which they push back or request improvement. Considering that sooner rather than during IESG evaluation seems a worthwhile optimization to me. On reviewing the -07 draft I observed that the flow could be improved, and that's thus one of the things I tried to do in the proposal. >> Balanced against a demonstrated record of success, I think opinions >> of people who've never actually implemented or operated this (or >> particularly helped a broad base of others to do so) should not >> merit a lot of weight. I would think people who have actually implemented this in the past are going to have the least amount of difficulty with whatever this group produces, and thus people who are new to it are in fact the very people about whom we should be most concerned. -MSK From spf2@kitterman.com Mon Sep 17 13:54:15 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58D021F8687 for ; Mon, 17 Sep 2012 13:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCjQkhZvGPYC for ; Mon, 17 Sep 2012 13:54:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2165B21F8682 for ; Mon, 17 Sep 2012 13:54:14 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6981220E40BD; Mon, 17 Sep 2012 16:54:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347915253; bh=7Dq+0zpuhPgPouXHxP7xygcxs7MdqmSe/2CpyRwSQ3g=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JOUS61b5czV3dqXh3kCs2hCwLzUIQWN4hNIMmrsOWCkCJHLCcY5cwk6bBxFvypZVh F1KjFrvYbTyx0CoaHK33XekDRFsNXxn3Lyyl4TsXLJ+znCpbWsF8BK83sdhZP8ftYy A75U2OvPm7F/bgY7DSBzSca+jPLw+sgqEkVgbA1Y= 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 415F320E4064; Mon, 17 Sep 2012 16:54:12 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 17 Sep 2012 16:54:12 -0400 Message-ID: <2313224.Yyxubt5dZV@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-31-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <505753D0.6010109@dcrocker.net> References: <1643479.U6Efqag6vq@scott-latitude-e6320> <505753D0.6010109@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 20:54:16 -0000 On Monday, September 17, 2012 09:46:08 AM Dave Crocker wrote: > Scott, > > On 9/14/2012 7:20 PM, Scott Kitterman wrote: > > Dave Crocker wrote: > >> On 9/14/2012 4:40 PM, William Leibzon wrote: > >>> I know what IETF terms are. But the use of SPF has been > >>> equivalent to proposed standard despite its official > >>> experimental status which was you know a political decision when > >>> disbanding MARID. That is why I think this group should treat > >>> changes from RFC4408 as somewhat similar to proposed to draft. > >>> And originally when I heard, I thought you would just bring SPF > >>> into official status and get errata in instead of doing so many > >>> changes and additions. > >> > >> 1. We aren't doing "so many changes and additions". > >> > >> 2. It's a bit dangerous to impose additional rules on an IETF > >> working group, based on your own assessment, given that there is > >> already quite a bit of constraint on the process. > >> > >> 3. Your assessment -- or rather, the truth of it -- doesn't matter > >> for the question at hand. For example, we made significant > >> changes to the DKIM doc when moving from Proposed. The rationale > >> for some of the changes was the same as here: documentation > >> clarity. > > > > It was called that for process convenience, but at least some of > > this so called clarifications were substantiation semantic changes > > that changed DKIM. I am trying very hard to avoid a similar success > > with SPF. > > 1. I cannot quite figure out what your use of "It" refers to. My guess > is that it refers to the document status, but would appreciate your > clarifying or at least confirming. It is the process whereby DKIM was advanced in maturity status and simultaneously redefined. It doesn't really matter though. What was done with DKIM is, correctly, not directly relevant here. > 2. My point was that the 'Experimental' vs. 'Proposed' status difference > does not matter with respect to the document reorganization being > proposed. There is (typically) no restriction against such changes and > certainly isn't one that I see in the SPFbis wg charter. > > 3. You appear to believe that changing document organization somehow > changes SPF syntax or semantics. Please explain that view. No. I think the reorganization makes it harder to understand things. It's the contemporaneous effort to expunge all mention of receiver policy that I believe changes things. > 4. You assert that there are "substantial semantic changes that changed > DKIM". First, DKIMbis had a significantly different charter, and second > if you are going to invoke DKIM work as somehow relevant to SPFbis work, > please provide direct explanation of the relevance. Presumably you are > making a claim of substantial changes to DKIM semantics as a sort of > justification for not making some sort of change to the SPF > specification, but I can't tell how to apply it, since there are no > specifics offered. Go read the original and current definitions for i=. That will get you started, but we can drop it here. It's not particularly relevant. > >>> The material has been used and understood by countless > >>> developers. Unless there is a strong reason to believe the > >>> material is not clear > >> > >> and > >> > >>> structure is bad, and such complaints come from developers > >>> rather > >> > >> than > >> > >>> from folks here, the current structure should be considered good. > >>> William > >> > >> I suspect you haven't done a survey of all the actual or potential > >> > >> readers of the documents. We can't know who has had troubles > >> > >> with the document. > >> > >> Rather than resorting to "lots of people were able to use it in its > >> current form", it would be useful to focus on the issues that have > >> been cited and the improvements in Murray's proposal. > > > > Having invested significant personal time over the course of seven > > years answering questions for both implementors and domain owners > > trying to deploy SPF, in addition to working on both SPF library > > implementations and code/process into integrate SPF into a variety > > of mail systems, I think I have at least as much experience as anyone > > on the list trying to help people through problems with RFC 4408 and > > more than most. > > This is called an appeal to authority: > > http://en.wikipedia.org/wiki/Argument_from_authority > > It has its uses, but typically is problematic. It often is used in > place of providing meaningful justification for a view. And indeed I > can't tell how you mean it to be applied here. First, while it's generally problematic, the page you says states that is is usually problematic because "either the Authority is not a subject-matter expert, or there is no consensus among experts in the subject matter". I suggest that I am a subject matter expert (on SPF) and that among such subject matter experts this is general consensus on the points I'm making, so you objection generally good, is specifically not appropriate in this case. It's also an appeal to authority itself. > In the extreme, it might be your assertion that because you have not > seen certain issues over the course of your extended experience, they > are not real or significant issues. Taken to its logical conclusion, > that probably would mean ignoring all errata, except the ones that you > have encountered. My assertion is that it's evidence that there are not real or significant issues. I don't claim it's dispositive on it's own, but I think operational experience and evidence should be weighed heavily. I think more than opinions of people who've just read the spec. > > Record publishers with questions typically have a hard time > > conceptualizing that the SPF record is intended to describe the > > outbound mail architecture of their domain(s). This is as foreign a > > concept to many of them as controlling open relays was in the > > 1990's. > > "outbound mail architecture" is an interesting phrase. I think I > haven't heard it before, but it sounds potentially useful. It's one I've used for a long time. > The only caution I'd raise is the difference between protocol > architecture, software architecture and operations (or deployment) > architecture. In practical terms, people often get confused about the > word 'architecture'. To avoid that confusion in this case, I might > suggest saying 'outbound mail configuration', but that doesn't sound a sexy. > > Many domain owners are very non-technical and they end up needing to > > have basic DNS concepts explained to them. > > Of course, your comment is correct, but I am not understanding its > relevance to the current discussion. If we're reorganizing the document to deal with problems, I think it's useful to point out the problems I have seen. Hopefully an improved document would help address though. > One use that is probably not what you intended is that readers of RFCs > also often do not understand some basic issues. Indeed, one of the > things I like about IETF specification style is that we have a freedom > to include tutorial material and, more general, to attend to the > pedagogic aspects of specifications more than most other standards groups. > > This happens to be why I'm in favor of the proposed re-organization: It > is cleaner and follows a better logical sequence. That makes is more > helpful to a broader base of readers. I disagree. It makes splits information about related topics up and makes it harder to find. For example, if you're interested in getting feedback on your SPF deployment, 4408bis (both organizations) suggests two methods. In -07 they are together. In the reorg, they are not. I think this is the opposite of clarity. > > I don't recall, except for making processing limits clearer (which > > we are doing) thinking the spec needed improvement from a > > publisher's perspective. > > > > I'm thinking back and I don't recall any issues for implementers > > that aren't documented in errata. That's the primary source for > > them. You'll also notice that it's been some years since new erratum > > were filed. > > > > Of course no one has done a survey of all actual or potential > > readers. It's a nonsense point. I don't know why you mention it. > > It was my way of suggesting that your apparently relying only on your > personal experience is a form of statistics sampling error. > > When making claims about a population -- such as the entire set of > existing and potential readers of SPFbis -- it is almost never > sufficient to cite only one's own experience, no matter how extensive. > It's relevant, but not sufficient. Of course not. I'm interested in other people's experiences as well. I'm much less interested in comments grounded in lack of experience. They aren't all of equal value. > > The fact is that the existing text and structure has demonstrated > > considerable success. Any alternative, by definition, has not. > > The original DKIM spec also demonstrated quite a bit of success. So > when we began its -bis effort, it was interesting to discover massive > specification errors in parts of its formal details. > > Success of a document version is important, but, again, not definitive. > > > I had a chance to review Murray's proposal before it was published. > > It is different than the organization in RFC 4408. I don't find it > > better in any significant respect. Moving things like experimental > > history and such to the end make sense, but in terms of the > > reorganization of sections 2 through 9 into more sections and an > > additional stack of new appendices, I don't find it an improvement. > > > > It spreads things out over several sections so there is much more > > need to hop around the document when focusing on a single concept. I > > don't think it's an unreasonable way to go about things, I just don't > > think it's overall an improvement. > > Please explain the claim that it requires more hopping around to use. I gave one example above. > My own reading is that it provides more tightly coherent sequences -- > although I and others have noted possible ways to improve the proposed > organization further -- which is exactly the opposite interpretation > from yours. Section 2.5 would be split in two and some information further split into appendicies. You may find each individual bit more coherent, but I think that as a whole it's more scattershot. snipped the IESG reference, since I replied to that already. > Perhaps we can focus on the substance of suggested changes, rather than > purported attributes of the speakers? If one person says a spec is usable and they've actually implemented stuff from the spec and one person say it is not, but they haven't, I don't think those opinions are inherently equal. I believe the guidance from the chairs has made discussion of most of my concerns OBE. Scott K From ajs@anvilwalrusden.com Mon Sep 17 14:55:53 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E6C21E8063 for ; Mon, 17 Sep 2012 14:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeKyqECeOGEd for ; Mon, 17 Sep 2012 14:55:53 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 21B7821E8053 for ; Mon, 17 Sep 2012 14:55:53 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 59BD78A031 for ; Mon, 17 Sep 2012 21:55:52 +0000 (UTC) Date: Mon, 17 Sep 2012 17:55:44 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120917215544.GA59832@crankycanuck.ca> References: <6.2.5.6.2.20120917100318.0aa2a480@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20120917100318.0aa2a480@elandnews.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] SPFBIS guidance X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 21:55:53 -0000 Colleagues, Please note that the Subject: line and the message below both say "guidance", not "instructions". What SM sent is not intended as any sort of final decision; we just think these are useful things to take into account. Best, A On Mon, Sep 17, 2012 at 10:07:19AM -0700, S Moonesamy wrote: > Our guidance to the WG is to review draft-ietf-spfbis-4408bis and see that it: > > 1. Uses consistent terminology. > > 2. Is in line with the RFCs cited as normative references. > > 3. Does not restate material from other RFCs as normative text. > > 4. Does not contain advocacy material. > > 5. Does not discuss about "best practices" or "how-to". > > 6. Does not promote any method under the disguise of interoperability > or security. > > Receiver policy is out of scope for a specification about "Sender > Policy Framework". > > Andrew Sullivan & S. Moonesamy, SPFBIS WG co-chairs > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Mon Sep 17 15:00:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289A421F8503 for ; Mon, 17 Sep 2012 15:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.625 X-Spam-Level: X-Spam-Status: No, score=-0.625 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0RmhRULciTB for ; Mon, 17 Sep 2012 15:00:42 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id A54D721F84FE for ; Mon, 17 Sep 2012 15:00:42 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 1F0298A031 for ; Mon, 17 Sep 2012 22:00:42 +0000 (UTC) Date: Mon, 17 Sep 2012 18:00:40 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120917220040.GB59832@crankycanuck.ca> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 22:00:43 -0000 Dear colleagues, On Fri, Sep 14, 2012 at 12:12:04PM -0700, Murray S. Kucherawy wrote: > I've taken some time to construct a proposed restructuring of the > current spfbis draft. Murray's suggestion has sparked a lot of conversation, some of it quite heated (there have been some irrelevant and in some cases personalizing remarks, too; we're dealing with those off-list). It seems to me there are several different issues here, and I'm not entirely convinced we are attending to the central problems. Indeed, I'm having a hard time following some of the arguments (though SM is less muddle-headed than I, and seems to me to have a better grasp of matters). So I'd like to sort out a couple of basic goals first, and then see whether that gives us a clear direction. The proposed reorganization depends on three basic premises: first, that the current 4408-bis draft has grown and is a little unwieldy. Second, it's not obvious that RFC 4408 was organized as well as it could have been, nor even that it limited itself appropriately for something that is on the standards track. Third (and related to the second), this document is moving to the standards track, and therefore material that isn't really appropriate to a standards track document should either be removed (possibly being moved into another document -- leave aside the disposition for the moment) or moved into an appendix or other clearly-marked, non-normative section. These premises seem to me to be at least plausible, if perhaps not uncontroversially true. The counter-argument to the proposed reorganization also, conveniently, depends on three basic premises. First, the WG is in effect chartered to move SPF from the experimental to the standards track, making as few changes to the protocol as technically possible along the way. Second, with large changes to the text, it is easy to make accidental protocol changes that will go overlooked; it is also possible for someone intending a change to the protocol to "sneak one in" this way. Third, by cleaving to the organization in RFC 4408, we make it possible to compare the two documents easily, which defends against the accidental (or intentional) changes going unnoticed. These premises also seem to me to be plausible, if perhaps not uncontroversially true. Before going further, I'd like for participants in this debate to state where they stand with respect to the above arguments, and to clarify what trade-offs they think are acceptable as a result. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From dhc@dcrocker.net Mon Sep 17 15:58:07 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DA221E808C for ; Mon, 17 Sep 2012 15:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cns76CUG76xG for ; Mon, 17 Sep 2012 15:58:06 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1C421E8063 for ; Mon, 17 Sep 2012 15:58:06 -0700 (PDT) Received: from [192.168.1.8] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8HMw4V0003075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 17 Sep 2012 15:58:05 -0700 Message-ID: <5057AAFA.6010007@dcrocker.net> Date: Mon, 17 Sep 2012 15:58:02 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Scott Kitterman References: <1643479.U6Efqag6vq@scott-latitude-e6320> <505753D0.6010109@dcrocker.net> <2313224.Yyxubt5dZV@scott-latitude-e6320> In-Reply-To: <2313224.Yyxubt5dZV@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 17 Sep 2012 15:58:06 -0700 (PDT) Cc: spfbis@ietf.org Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 22:58:07 -0000 Scott, On 9/17/2012 1:54 PM, Scott Kitterman wrote: >> 1. I cannot quite figure out what your use of "It" refers to. My guess >> is that it refers to the document status, but would appreciate your >> clarifying or at least confirming. > > It is the process whereby DKIM was advanced in maturity status and > simultaneously redefined. It doesn't really matter though. The fact that you continue to make such an assertion -- and to make it in this forum -- remains problematic. I assume that the specific is as you cited farther down, about i=. Unfortunately, for its supposed relevance to the current -bis effort, fixing that specification error was in response to an errata, AND it was /before/ DKIMbis was started. It also didn't really change DKIM, except for resolving a fundamental ambiguity in output semantics. >> 3. You appear to believe that changing document organization somehow >> changes SPF syntax or semantics. Please explain that view. > > No. I think the reorganization makes it harder to understand things. It's > the contemporaneous effort to expunge all mention of receiver policy that I > believe changes things. The proposal concerns reorganizing the text. A proposal to alter receiver policy language is -- or should be, IMO -- a separate topic. As for being harder to understand, there have been specific observations about lack of logical sequence to the existing organization and even to possible layering violations in the way things are documented. The latter was noted as inviting reader confusion, such as about 'fail' and an implied requirement for doing a specific SMTP failure code. > Go read the original and current definitions for i=. That will get you > started, but we can drop it here. It's not particularly relevant. Indeed, fundamental bugs the defininition of DKIM output, and common, disparate interpretations of i= and d= semantics were fixed. But again, that was before the DKIMbis effort... >> This is called an appeal to authority: >> >> http://en.wikipedia.org/wiki/Argument_from_authority >> >> It has its uses, but typically is problematic. It often is used in >> place of providing meaningful justification for a view. And indeed I >> can't tell how you mean it to be applied here. > > First, while it's generally problematic, the page you says states that is is > usually problematic because "either the Authority is not a subject-matter > expert, or there is no consensus among experts in the subject matter". We can go with the latter, for the current purposes. But you might also want to review the later section in the article, about Bias and prejudice. > I suggest that I am a subject matter expert (on SPF) and that among such > subject matter experts this is general consensus on the points I'm making, I'll assume that you are not dismissing other 'subject matter experts' present in this forum, or rejecting their expertise? And even if you are, you are now offering yourself as the expert about experts. That repeats the problem of appeal to authority. > so > you objection generally good, is specifically not appropriate in this case. > It's also an appeal to authority itself. Wow. That last sentence confuses the heck out of me. In what way does it qualify as an appeal to authority? >> In the extreme, it might be your assertion that because you have not >> seen certain issues over the course of your extended experience, they >> are not real or significant issues. Taken to its logical conclusion, >> that probably would mean ignoring all errata, except the ones that you >> have encountered. > > My assertion is that it's evidence that there are not real or significant > issues. I don't claim it's dispositive on it's own, but I think operational > experience and evidence should be weighed heavily. I think more than opinions > of people who've just read the spec. For a topic like document reorganization, a relevant area of expertise is technical editing. Specific examples have been provided about aspects of the current draft that suffer in the terms of good technical writing and especially good specification writing. I thought that Murray's comments on this also quite useful. >> One use that is probably not what you intended is that readers of RFCs >> also often do not understand some basic issues. Indeed, one of the >> things I like about IETF specification style is that we have a freedom >> to include tutorial material and, more general, to attend to the >> pedagogic aspects of specifications more than most other standards groups. >> >> This happens to be why I'm in favor of the proposed re-organization: It >> is cleaner and follows a better logical sequence. That makes is more >> helpful to a broader base of readers. > > I disagree. It makes splits information about related topics up and makes it > harder to find. For example, if you're interested in getting feedback on your > SPF deployment, 4408bis (both organizations) suggests two methods. In -07 > they are together. In the reorg, they are not. I think this is the opposite > of clarity. Examples of the current document organization's conflating topics have been provided. Feedback on the proposed change suggested refinements to it. Certainly the kind of issue you cite would be something I'd expect a new and improved document organization to attend to carefully. >> When making claims about a population -- such as the entire set of >> existing and potential readers of SPFbis -- it is almost never >> sufficient to cite only one's own experience, no matter how extensive. >> It's relevant, but not sufficient. > > Of course not. I'm interested in other people's experiences as well. I'm > much less interested in comments grounded in lack of experience. They aren't > all of equal value. Forgive me, but I haven't noticed any process for assessing empirical knowledge being offered by others. More significantly, what you describe is a process of deciding whether the person speaking is 'worthy' of their view, as opposed to a process of evaluating the view itself. >> My own reading is that it provides more tightly coherent sequences -- >> although I and others have noted possible ways to improve the proposed >> organization further -- which is exactly the opposite interpretation >> from yours. > > Section 2.5 would be split in two and some information further split into > appendicies. You may find each individual bit more coherent, but I think that > as a whole it's more scattershot. Actually, Section 2.5 is a really good example of problematic conflating. The section defines its scope as "interpret[ing] the results of the check_host() function". Yet Section 2,5,4 has /normative/ text about a specific form of reporting AND it points elsewhere for another. The section should confine itself to its stated goal. Discussion of reporting mechanisms should be separate and later. > snipped the IESG reference, since I replied to that already. > >> Perhaps we can focus on the substance of suggested changes, rather than >> purported attributes of the speakers? > > If one person says a spec is usable and they've actually implemented stuff from > the spec and one person say it is not, but they haven't, I don't think those > opinions are inherently equal. Except "one person say[s] it is not" hasn't been asserted; this suggests that you've misunderstood the concern about document organization. > I believe the guidance from the chairs has made discussion of most of my > concerns OBE. oh? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Mon Sep 17 16:10:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F61521E808C for ; Mon, 17 Sep 2012 16:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0SRZxXwY4TF for ; Mon, 17 Sep 2012 16:10:47 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 604E421E8063 for ; Mon, 17 Sep 2012 16:10:47 -0700 (PDT) Received: by lahm15 with SMTP id m15so4862351lah.31 for ; Mon, 17 Sep 2012 16:10:46 -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=+BgRXFvKHClQFvFlE+VJc3j8CdAOw9Ph38D1U8tgQUE=; b=lscAPdoYER6kQJgL/5BgYdSUc66qmdepWEt94HWFe+/bQavayEk45xb4gZSyZrSqxz QoeT147eOShUOt6CkVkXFTR01WWVZv85C9FiHnfu+Zn/RHx4L8y+tQbDTuvHeAOhdT/d HdmhGqnRVCSnu4mBNC7szusSjqT1r+kswQ8QNCoGP6aVcYAtcJTAuAwGQrPsntK3Fw6Q JU4uTYrWSHT9bDIY2DosKlAntlOPRSsWu2CmiNNO3AZs3+7g8+NJqHMeGun5WwsRzCSM 6KfNmFaxXkRAjSBYwBwZAKtuD9CklR3KeMDIKyS+ZFmgPL4y0Q80oJdskTp95bH/J3iC hWAw== MIME-Version: 1.0 Received: by 10.112.24.101 with SMTP id t5mr4360161lbf.123.1347923446316; Mon, 17 Sep 2012 16:10:46 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Mon, 17 Sep 2012 16:10:46 -0700 (PDT) In-Reply-To: <20120917220040.GB59832@crankycanuck.ca> References: <20120917220040.GB59832@crankycanuck.ca> Date: Mon, 17 Sep 2012 16:10:46 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 23:10:48 -0000 On Mon, Sep 17, 2012 at 3:00 PM, Andrew Sullivan wrote: > The counter-argument to the proposed reorganization also, > conveniently, depends on three basic premises. First, the WG is in > effect chartered to move SPF from the experimental to the standards > track, making as few changes to the protocol as technically possible > along the way. Second, with large changes to the text, it is easy to > make accidental protocol changes that will go overlooked; it is also > possible for someone intending a change to the protocol to "sneak one > in" this way. Third, by cleaving to the organization in RFC 4408, we > make it possible to compare the two documents easily, which defends > against the accidental (or intentional) changes going unnoticed. > These premises also seem to me to be plausible, if perhaps not > uncontroversially true. 1: I don't believe the proposed reorganization makes any changes to the protocol itself (or if it does, they were identified for discussion and not intended as a covert maneuver), so I find the first argument unconvincing. 2: Given that there was one tweak to normative text I made in earlier versions of the proposed reorganization (for discussion, I reiterate) and that Scott found this pretty much immediately, I have no misconceptions that anything could be "snuck in" by me or anyone else. In fact, Scott is probably the only one that could do that since the rest of us don't have "the pen" and have to argue for consensus to get things changed. The SPF proponents among us are watching for those very carefully already. I also find that this premise presupposes malicious intent by other contributors, and I hope we haven't reached a level of distrust that would impede the potential for improving the work. 3: I recognize the convenience of being able to use "rfcdiff" to see what changed between two versions of a document, but I don't find that convenience to be, on its own, large enough to outweigh the value of potentially better presentation of the material. We have enough thorough reviewers among us, as well as several that will see this before it reaches IESG evaluation (not to mention during). That's a pretty tight net indeed for catching changes, accidental or intentional. -MSK From agthisell@yahoo.com Mon Sep 17 16:20:02 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB78321E8063 for ; Mon, 17 Sep 2012 16:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.287 X-Spam-Level: X-Spam-Status: No, score=-1.287 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWDrh9XDrw2Z for ; Mon, 17 Sep 2012 16:20:02 -0700 (PDT) Received: from nm40-vm6.bullet.mail.ne1.yahoo.com (nm40-vm6.bullet.mail.ne1.yahoo.com [98.138.229.182]) by ietfa.amsl.com (Postfix) with SMTP id C319A21E804A for ; Mon, 17 Sep 2012 16:20:01 -0700 (PDT) Received: from [98.138.226.178] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 17 Sep 2012 23:19:57 -0000 Received: from [98.138.89.196] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 17 Sep 2012 23:19:56 -0000 Received: from [127.0.0.1] by omp1054.mail.ne1.yahoo.com with NNFMP; 17 Sep 2012 23:19:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 972528.67419.bm@omp1054.mail.ne1.yahoo.com Received: (qmail 57101 invoked by uid 60001); 17 Sep 2012 23:19:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347923996; bh=aLiuCTTX6r5IiDKSzIuC0XpBs8fef+ntq2v3L+apomU=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=01n7v9cqYZ590uNhHGVlAGe8fGVPoJFCl+9eAOGiLBLmFsbE06r6niLbI7MBb2KI3NgvxIaDxwiESeaaGCa6+OdLo/2pD9tkCNPrGiE/ncnMBsPzVn0r1/0kXMDKyTuisvPEzwK49xa/jWMWwgsYk6tM0C1NnlofJRy3tcJK6EY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=GrbqnMDiX1AgodkvR2pS93ZmUdyAlPh9iYJOMexhTvsRHH/MZEnpjrB4eH9VIaoiqGdzgiUngcU1hTYK/9/qxV+bHRKbAT94IiF1wHzdkkdTGCTWlSKBp8C+anqdhh/Ex82kxhWE6JR+lhwcvrC68wOa98HvDITtHd765nj4/Ak=; X-YMail-OSG: hcW222oVM1kgYrof8rw5xgyL1ZPSNwML56oYD.HmIo.Z09s Lt.29bFJ3 Received: from [71.61.133.134] by web125105.mail.ne1.yahoo.com via HTTP; Mon, 17 Sep 2012 16:19:56 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347923996.36792.YahooMailClassic@web125105.mail.ne1.yahoo.com> Date: Mon, 17 Sep 2012 16:19:56 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 23:20:03 -0000 > The counter-argument to the proposed reorganization also, > conveniently, depends on three basic premises. I think you missed one counter-argument, and that doing a reorganization looks to be a major time suck. There isn't just two choices of how to organize a draft, and once the subject is really opened up, everyone can try to propose changes that, in their humble opinion, make the most sense. This is a classic bike-shed problem (see http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality ). While trying to decide the harder technical problems with 4408 require specialized knowledge, anyone can debate which sentence is "clearer", which extra text "makes the spec more complete", what word should be substituted to make the draft "more polished". If Mark Lentczner had decided to re-arrange the SPF spec to something similar to what Murry proposed, I doubt that we would have changed it for RFC 4408. We had more important goals, mostly technical ones. It has been quite a while since we closed a ticket. I actually have a few more that I want to open once this WG gets back on track. Oh, any I think my opinions were summed up with this post: http://www.ietf.org/mail-archive/web/spfbis/current/msg02895.html From spf2@kitterman.com Mon Sep 17 18:23:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211D721E80A0 for ; Mon, 17 Sep 2012 18:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6cVWkTYFUlb for ; Mon, 17 Sep 2012 18:23:57 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EC02F21E803D for ; Mon, 17 Sep 2012 18:23:56 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 05EF220E40BD; Mon, 17 Sep 2012 21:23:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347931436; bh=OFzg8u5kyRK/uiZ60T8qoDKRkK/7hY4e+ebkEUgzswI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZJWee/GqD5mcYH3++9zobs2uWiuPIoItChrj8S4ujSnaj/52eDnncfuyOHyBp04el IEOTeF3Kc9rh+uStuMZrUqcBSsneokzeLzIblP0S8XKCxQVgQQmPisk4N5bDO01fQK rd6Tf0CrMllUnUjw/d47QzHcWMgaxzHP2vV7giu8= 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 C907520E4064; Mon, 17 Sep 2012 21:23:55 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 17 Sep 2012 21:23:54 -0400 Message-ID: <2066271.XDCiDRdmGb@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-31-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <5057AAFA.6010007@dcrocker.net> References: <2313224.Yyxubt5dZV@scott-latitude-e6320> <5057AAFA.6010007@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 01:23:58 -0000 On Monday, September 17, 2012 03:58:02 PM Dave Crocker wrote: > Scott, > > On 9/17/2012 1:54 PM, Scott Kitterman wrote: > >> 1. I cannot quite figure out what your use of "It" refers to. My guess > >> is that it refers to the document status, but would appreciate your > >> clarifying or at least confirming. > > > > It is the process whereby DKIM was advanced in maturity status and > > simultaneously redefined. It doesn't really matter though. > > The fact that you continue to make such an assertion -- and to make it > in this forum -- remains problematic. > > I assume that the specific is as you cited farther down, about i=. > Unfortunately, for its supposed relevance to the current -bis effort, > fixing that specification error was in response to an errata, AND it was > /before/ DKIMbis was started. It also didn't really change DKIM, except > for resolving a fundamental ambiguity in output semantics. I'm glad to stop claiming the DKIM development process is a bad example as long as people don't claim it was a good one. > >> 3. You appear to believe that changing document organization somehow > >> changes SPF syntax or semantics. Please explain that view. > > > > No. I think the reorganization makes it harder to understand things. > > It's > > the contemporaneous effort to expunge all mention of receiver policy that > > I > > believe changes things. > > The proposal concerns reorganizing the text. A proposal to alter > receiver policy language is -- or should be, IMO -- a separate topic. > > As for being harder to understand, there have been specific observations > about lack of logical sequence to the existing organization and even to > possible layering violations in the way things are documented. The > latter was noted as inviting reader confusion, such as about 'fail' and > an implied requirement for doing a specific SMTP failure code. This continues to mystify me. If people are going to read "If you choose to do A, here is how you communicate that choice" as "You must do A", then there's no hope. Whether the example belongs there or not, I think this is a poor reason t move it. It might better be in (from -07) the Section 9 discussion of local policy since there's where we discuss rejection, but I think it's useful to have a normative statement of what SMTP and enhanced status codes to use (since you can't unambiguously figure out the correct enhanced status code to use just from reading references). So maybe it's better where it is. I think there are reasonable alternatives here, but I don't think that people getting confused about rejection being required is a good reason to change anything. snipped more DKIM references. > >> This is called an appeal to authority: > >> http://en.wikipedia.org/wiki/Argument_from_authority > >> > >> It has its uses, but typically is problematic. It often is used in > >> place of providing meaningful justification for a view. And indeed I > >> can't tell how you mean it to be applied here. > > > > First, while it's generally problematic, the page you says states that is > > is usually problematic because "either the Authority is not a > > subject-matter expert, or there is no consensus among experts in the > > subject matter". > We can go with the latter, for the current purposes. > > But you might also want to review the later section in the article, > about Bias and prejudice. I'm quite familiar with confirmation bias. > > I suggest that I am a subject matter expert (on SPF) and that among such > > subject matter experts this is general consensus on the points I'm making, > > I'll assume that you are not dismissing other 'subject matter experts' > present in this forum, or rejecting their expertise? And even if you > are, you are now offering yourself as the expert about experts. That > repeats the problem of appeal to authority. Not at all. > > so > > > > you objection generally good, is specifically not appropriate in this > > case. > > It's also an appeal to authority itself. > > Wow. That last sentence confuses the heck out of me. In what way does > it qualify as an appeal to authority? It rejects my argument that I have appropriate expertise to have an authority position (i.e. this fits the exception case where it's OK) not by assessing the merits, but by referring to another authority and asserts that by definition any claim of authority is wrong. > >> In the extreme, it might be your assertion that because you have not > >> seen certain issues over the course of your extended experience, they > >> are not real or significant issues. Taken to its logical conclusion, > >> that probably would mean ignoring all errata, except the ones that you > >> have encountered. > > > > My assertion is that it's evidence that there are not real or significant > > issues. I don't claim it's dispositive on it's own, but I think > > operational experience and evidence should be weighed heavily. I think > > more than opinions of people who've just read the spec. > > For a topic like document reorganization, a relevant area of expertise > is technical editing. Specific examples have been provided about > aspects of the current draft that suffer in the terms of good technical > writing and especially good specification writing. > > I thought that Murray's comments on this also quite useful. I think it's reasonable, on the basis of a claim to expertise to discuss what expertise is relevant. I believe that, while technical writing experience is an important expertise for this discussion, it is less significant than experience implementing RFC 4408 and with operational use of the protocol. Running code is important. http://www.rfc- editor.org/errata_search.php?rfc=5965 is out there now because when I was participating in the MARF working group, I hadn't implemented it yet and so it wasn't until I starting trying to do so, I discovered the error. > >> One use that is probably not what you intended is that readers of RFCs > >> also often do not understand some basic issues. Indeed, one of the > >> things I like about IETF specification style is that we have a freedom > >> to include tutorial material and, more general, to attend to the > >> pedagogic aspects of specifications more than most other standards > >> groups. > >> > >> This happens to be why I'm in favor of the proposed re-organization: It > >> is cleaner and follows a better logical sequence. That makes is more > >> helpful to a broader base of readers. > > > > I disagree. It makes splits information about related topics up and makes > > it harder to find. For example, if you're interested in getting feedback > > on your SPF deployment, 4408bis (both organizations) suggests two > > methods. In -07 they are together. In the reorg, they are not. I think > > this is the opposite of clarity. > > Examples of the current document organization's conflating topics have > been provided. Feedback on the proposed change suggested refinements to > it. Certainly the kind of issue you cite would be something I'd expect > a new and improved document organization to attend to carefully. Except I think it's fundamentally flawed, so moving to the new organization and then bug fixing it won't get back to as good as what we have now. > >> When making claims about a population -- such as the entire set of > >> existing and potential readers of SPFbis -- it is almost never > >> sufficient to cite only one's own experience, no matter how extensive. > >> It's relevant, but not sufficient. > > > > Of course not. I'm interested in other people's experiences as well. I'm > > much less interested in comments grounded in lack of experience. They > > aren't all of equal value. > > Forgive me, but I haven't noticed any process for assessing empirical > knowledge being offered by others. > > More significantly, what you describe is a process of deciding whether > the person speaking is 'worthy' of their view, as opposed to a process > of evaluating the view itself. If 5 people agree on something, but have little experience with the topic, but two people, who have great experience the topic disagree, then, while both views should certainly be considered and evaluated, I think it's more likely the two with experience will have the more correct view. > >> My own reading is that it provides more tightly coherent sequences -- > >> although I and others have noted possible ways to improve the proposed > >> organization further -- which is exactly the opposite interpretation > >> from yours. > > > > Section 2.5 would be split in two and some information further split into > > appendicies. You may find each individual bit more coherent, but I think > > that as a whole it's more scattershot. > > Actually, Section 2.5 is a really good example of problematic > conflating. The section defines its scope as "interpret[ing] the > results of the check_host() function". > > Yet Section 2,5,4 has /normative/ text about a specific form of > reporting AND it points elsewhere for another. > > The section should confine itself to its stated goal. Discussion of > reporting mechanisms should be separate and later. Or change the title to match the text. > > snipped the IESG reference, since I replied to that already. > > > >> Perhaps we can focus on the substance of suggested changes, rather than > >> purported attributes of the speakers? > > > > If one person says a spec is usable and they've actually implemented stuff > > from the spec and one person say it is not, but they haven't, I don't > > think those opinions are inherently equal. > > Except "one person say[s] it is not" hasn't been asserted; this suggests > that you've misunderstood the concern about document organization. Clearly there are several people on the list who believe the current organization is sufficiently deficient that it's worth making life more difficult for the known set of implementors to improve it. > > I believe the guidance from the chairs has made discussion of most of my > > concerns OBE. > > oh? At the time I wrote that, I read guidance == direction, so nevermind. Scott K From spf2@kitterman.com Mon Sep 17 18:39:49 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14E021E805A for ; Mon, 17 Sep 2012 18:39: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IbUka7WmJ6r for ; Mon, 17 Sep 2012 18:39:49 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACDA21E803D for ; Mon, 17 Sep 2012 18:39:36 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 976F420E40BD; Mon, 17 Sep 2012 21:39:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347932375; bh=liRnxUdpCA3dMO0cSuVzExKNdHZpcSgXO4bvs5kcG6k=; h=From:To:Subject:Date:In-Reply-To:References:From; b=X29su9dTdi3z/scoS/vhMsMH97yIXS971+UEmgU9V5T2NNupyAPgTXQ1JQMseDl+Y mbTxP3FiutMCMGPLOOLS0MZoU1L7A+K8rChGlXDFsczPFrVHserAvVbYKpO7k5rPZb PxyvoyM8TeMWKbiYevAggqNzDMnLgsNkm8wUL8Rk= 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 5657B20E4064; Mon, 17 Sep 2012 21:39:34 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 17 Sep 2012 21:39:34 -0400 Message-ID: <2130292.uRXqCVZiUA@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-31-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <20120917220040.GB59832@crankycanuck.ca> References: <20120917220040.GB59832@crankycanuck.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 01:39:50 -0000 On Monday, September 17, 2012 06:00:40 PM Andrew Sullivan wrote: > Dear colleagues, > > On Fri, Sep 14, 2012 at 12:12:04PM -0700, Murray S. Kucherawy wrote: > > I've taken some time to construct a proposed restructuring of the > > current spfbis draft. > > Murray's suggestion has sparked a lot of conversation, some of it > quite heated (there have been some irrelevant and in some cases > personalizing remarks, too; we're dealing with those off-list). > > It seems to me there are several different issues here, and I'm not > entirely convinced we are attending to the central problems. Indeed, > I'm having a hard time following some of the arguments (though SM is > less muddle-headed than I, and seems to me to have a better grasp of > matters). So I'd like to sort out a couple of basic goals first, and > then see whether that gives us a clear direction. > > The proposed reorganization depends on three basic premises: first, > that the current 4408-bis draft has grown and is a little unwieldy. > Second, it's not obvious that RFC 4408 was organized as well as it > could have been, nor even that it limited itself appropriately for > something that is on the standards track. Third (and related to the > second), this document is moving to the standards track, and therefore > material that isn't really appropriate to a standards track document > should either be removed (possibly being moved into another document > -- leave aside the disposition for the moment) or moved into an > appendix or other clearly-marked, non-normative section. These > premises seem to me to be at least plausible, if perhaps not > uncontroversially true. > > The counter-argument to the proposed reorganization also, > conveniently, depends on three basic premises. First, the WG is in > effect chartered to move SPF from the experimental to the standards > track, making as few changes to the protocol as technically possible > along the way. Second, with large changes to the text, it is easy to > make accidental protocol changes that will go overlooked; it is also > possible for someone intending a change to the protocol to "sneak one > in" this way. Third, by cleaving to the organization in RFC 4408, we > make it possible to compare the two documents easily, which defends > against the accidental (or intentional) changes going unnoticed. > These premises also seem to me to be plausible, if perhaps not > uncontroversially true. There is more to it than this. - While the draft may not be in the typical organization for a standards track document, I think that if the diff is in fact kept minimal, most questions about this can be sufficiently answered along the lines of "Yes, but our focus was minimal change to RFC 4408 and the organization didn't seem to be a literal error that we had to fix." Once we reorganize it, all bets are off and we'll need to bring everything up to the current documentation standard. I think this is rather more than we set out to do and will take us longer and not provide end users benefit at all proportionate to the effort it takes to produce it. - Myself, I'm not particularly concerned about people sneaking something in. I am concerned that we're discussing removal of the small local policy elements that are present in RFC 4408 in conjunction with the reorg as if this were non-controversial, but no one is sneaking anything. - I am much more concerned with the impact of the reorganization on maintainers of SPF libraries that want to update them to match 4408bis when it's published. If they are organizaed similarly, then this audience can easily compare (even if they don't directly diff the text) 4408 and 4408bis. If we do the reorganization, then I think we'll need an appendix telling people what's changed (with another chance to get things wrong). - The proposed reorganization divides topics up (find the two options in the proposed reorg for getting feedback data on SPF deployment) in ways that are arbitrary and will be hard for implementers to follow. - The proposed reorganization is clearly a precursor effort to splitting the document in two. I think that it will be much better to have one document, even if it's somewhat long, with proper anchors and links within it where needed than to be constrained to external links to a document with no ability to link to specific sections of that document (I've asked someone to tell me if I'm wrong about this limitation and no one has spoken up). So I think that doing a pre-split to make the split easier is an error. - The organization of 4408bis has proven itself good enough to foster multiple independent, interoperable implementations. So there should be a certain caution in monkeying with it. In software and specification maintenance efforts I've been involved in, it has always seemed to me that change equated to risk and there ought to be a clear and substantial benefit to taking that risk. RFC 4408 is provably usable as is. Any alternative is not, so we should be conservative about what we do. > Before going further, I'd like for participants in this debate to state > where they stand with respect to the above arguments, and to clarify > what trade-offs they think are acceptable as a result. Thanks for pulling this together and trying to sort it out. Scott K From john@jlc.net Mon Sep 17 18:40:43 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C1C21E804B for ; Mon, 17 Sep 2012 18:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.262 X-Spam-Level: X-Spam-Status: No, score=-106.262 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c23vHc45CczO for ; Mon, 17 Sep 2012 18:40:43 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C040021E803D for ; Mon, 17 Sep 2012 18:40:42 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id F2E7233C22; Mon, 17 Sep 2012 21:40:42 -0400 (EDT) Date: Mon, 17 Sep 2012 21:40:42 -0400 From: John Leslie To: Andrew Sullivan Message-ID: <20120918014042.GN21618@verdi> References: <20120917220040.GB59832@crankycanuck.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120917220040.GB59832@crankycanuck.ca> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 01:40:43 -0000 Andrew Sullivan wrote: > > Before going further, I'd like for participants in this debate to state > where they stand with respect to the above arguments, and to clarify > what trade-offs they think are acceptable as a result. Not sure I can help; but I'll give it a try... > The proposed reorganization depends on three basic premises: > - first, that the current 4408-bis draft has grown and is a little > unwieldy. I indeed find it unwieldy. > - Second, it's not obvious that RFC 4408 was organized as well as > it could have been, nor even that it limited itself appropriately > for something that is on the standards track. I am not among those who think RFC 4408 approached the "ideal". > - Third (and related to the second), this document is moving to > the standards track, and therefore material that isn't really > appropriate to a standards track document should either be removed > (possibly being moved into another document I find a lot of room for confusion about what portion is protocol vs. what is advice for receiver policy & practices. > The counter-argument to the proposed reorganization also, > conveniently, depends on three basic premises. > - First, the WG is in effect chartered to move SPF from the > experimental to the standards track, making as few changes to > the protocol as technically possible along the way. Clearly the charter has language discouraging changes to the protocol: presumably some folks wanted to avoid wandering in the weeds. Alas, this doesn't work well. It's generally better to give folks with serious concerns some other place to discuss them than to suggest they are bad people trying, consciously or unconsciously, to impede progress. I freely admit to being concerned about a bunch of issues where IMHO SPF failed the crispness test. I don't expect to fix them in this WG -- at least not before rechartering. If I post something about one of these when the issue comes up, it is not an attempt to settle the issue now: it's an attempt to lay ground for fixing it later. > - Second, with large changes to the text, it is easy to make > accidental protocol changes that will go overlooked; it is > also possible for someone intending a change to the protocol > to "sneak one in" this way. "Sneak one in" is a paranoid attitute which should be strongly discouraged. RFC 4408 was Experimental for several reasons: prime among them was an IESG (of the time) perception that SPF had many rough edges. We have a very different IESG today, but I expect them to read carefully enough to discover some rough edges. If we have good answers to how these can be fixed, I expect RFC4408bis to sail through easily enough -- if we don't, the charter limitations won't save us. (The charter limitations are there because the proponents wanted them, not because the IESG wanted them.) > - Third, by cleaving to the organization in RFC 4408, we make it > possible to compare the two documents easily, which defends > against the accidental (or intentional) changes going unnoticed. The IESG won't be comparing diffs; and frankly the implementors won't compare diffs either. The implementors will want a section listing issues they should check in existing 4408 implementations. Hope this helps... -- John Leslie From spf2@kitterman.com Mon Sep 17 18:44:16 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B6021E804B for ; Mon, 17 Sep 2012 18:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3idMSM45hyA6 for ; Mon, 17 Sep 2012 18:44:15 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8AA21E803D for ; Mon, 17 Sep 2012 18:44:15 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C943B20E40BD; Mon, 17 Sep 2012 21:44:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347932654; bh=1zmZC6CsCH8L4XYqIsCie1ZPWPw4dax0CzYXD2+7WYo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=E66W3Qo7npuB9U+Fcsr35xIpbkcmgDbCZ21K1Hlclzxq8WcgAxqKzMPmH3gboHhHR gCnZDS2Tz3X8+ThIzYSR5YlBDfmgseu3kdgDOEdpEEDGlW4sGBLKdf2gxIMUMW2n+O v9RvNcUYTMJ+CdZm2GBkDX/teqXPAHXhqGDaAzaY= 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 9A0BE20E4064; Mon, 17 Sep 2012 21:44:14 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 17 Sep 2012 21:44:13 -0400 Message-ID: <10634494.TKFlndshoM@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-31-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <20120918014042.GN21618@verdi> References: <20120917220040.GB59832@crankycanuck.ca> <20120918014042.GN21618@verdi> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 01:44:16 -0000 On Monday, September 17, 2012 09:40:42 PM John Leslie wrote: > > - Third, by cleaving to the organization in RFC 4408, we make it > > > > possible to compare the two documents easily, which defends > > against the accidental (or intentional) changes going unnoticed. > > The IESG won't be comparing diffs; and frankly the implementors > won't compare diffs either. The implementors will want a section > listing issues they should check in existing 4408 implementations. Would you please clarify what you meant by this? How does checking existing implementations tell anything about what's changed in 4408bis? I'm confused. Scott K From ajs@anvilwalrusden.com Mon Sep 17 19:37:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABED521F8527 for ; Mon, 17 Sep 2012 19:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.638 X-Spam-Level: X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVsjltlzA0CV for ; Mon, 17 Sep 2012 19:37:21 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 4097B21F84DF for ; Mon, 17 Sep 2012 19:37:21 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 716DC8A031 for ; Tue, 18 Sep 2012 02:37:20 +0000 (UTC) Date: Mon, 17 Sep 2012 22:37:18 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120918023717.GC61793@mx1.yitter.info> References: <20120917220040.GB59832@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 02:37:21 -0000 No hat. On Mon, Sep 17, 2012 at 04:10:46PM -0700, Murray S. Kucherawy wrote: > 1: I don't believe the proposed reorganization makes any changes to > the protocol itself (or if it does, they were identified for > discussion and not intended as a covert maneuver), so I find the first > argument unconvincing. That argument (and your others about reorganized text) I think puts the burden of proof in the wrong place. Whenever you open a protocol to produce a new document for it, you run the risk that there will be changes introduced to the protocol. Some of those changes will be intentional (e.g. we have decided to ditch RRTYPE 99 in SPF). But some of those changes will be accidental. The more you change the document, the greater the risk that you will introduce such an inadvertent change. Worse, since it is the WG that is performing this work, there is every possibility that the WG will not notice that the change it is making might in future be read by someone not familiar with the discussion in the WG as meaning a change to the protocol. We would not be the first people to make that mistake. Therefore, especially given our charter, the burden of proof that a given alteration in no way unintentionally alters the meaning of the overall document is not on those who wish to stick with the older organization, but on those who propose the change. Scott has been making this argument in another form: RFC 4408 has in fact produced independent implementations that interoperate. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From superuser@gmail.com Mon Sep 17 21:37:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F08C21F8427 for ; Mon, 17 Sep 2012 21:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnkShsM+1Mmd for ; Mon, 17 Sep 2012 21:37:44 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF9621F841D for ; Mon, 17 Sep 2012 21:37:43 -0700 (PDT) Received: by lahm15 with SMTP id m15so4991221lah.31 for ; Mon, 17 Sep 2012 21:37:43 -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=CyZFma0Uu2oE03kW1uIXFr6mXKohcphgdY/5QN2r9uA=; b=fHQWIfDgO2LOCN6t0xxqVfTGtQC+OuNXQapYiSsoQTvcxtJyPjnhaRv59LGAey+NBE u2nI++lHEy+Gmk86zcXg5tG+RWaopTX74gd2OaVMsiU95qXiH4wd6fWMkwPPCjyHs5g4 4f/82VR/mhj4UK2txEA3fo9Ra98Vfedb/ZAAYIXgissDOvfXqPsQKxk+uuNX70eaOWsA G4IEBlcG6P2EQm/okciQ4BQvXrQ9BzPdvymJDCbiUYIN6xLIFYFgLEUipfhaayD6rxOw xCjPZzzWdJYDpIxv+nmNcmxaADUCcjlKW4tL7dp03CdQTTR/eSR8mwA6EW3vKQnJ0QFq 5v9w== MIME-Version: 1.0 Received: by 10.152.144.67 with SMTP id sk3mr6185529lab.19.1347943063133; Mon, 17 Sep 2012 21:37:43 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Mon, 17 Sep 2012 21:37:43 -0700 (PDT) In-Reply-To: <20120917220040.GB59832@crankycanuck.ca> References: <20120917220040.GB59832@crankycanuck.ca> Date: Mon, 17 Sep 2012 21:37:43 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 04:37:45 -0000 On Mon, Sep 17, 2012 at 3:00 PM, Andrew Sullivan wrote: > The proposed reorganization depends on three basic premises: first, > that the current 4408-bis draft has grown and is a little unwieldy. > Second, it's not obvious that RFC 4408 was organized as well as it > could have been, nor even that it limited itself appropriately for > something that is on the standards track. Third (and related to the > second), this document is moving to the standards track, and therefore > material that isn't really appropriate to a standards track document > should either be removed (possibly being moved into another document > -- leave aside the disposition for the moment) or moved into an > appendix or other clearly-marked, non-normative section. These > premises seem to me to be at least plausible, if perhaps not > uncontroversially true. Just to be explicit, I think all of these are valid points and I support them as reasons for considering the rearrangement of the work to be a useful step. -MSK From spf2@kitterman.com Mon Sep 17 21:57:25 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA7221E80AC for ; Mon, 17 Sep 2012 21:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEgg4pxwl9Gb for ; Mon, 17 Sep 2012 21:57:24 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EA0D811E808A for ; Mon, 17 Sep 2012 21:57:23 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 39B0320E40BD; Tue, 18 Sep 2012 00:57:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347944243; bh=es2BXVnelt0TDdO7n4RlXwCI+RSkNkTp2Js9siLAnRk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fitcSrWzCPBNcwFeCVpgB9hURqJ2aM0/Ynf9lk+G+P0WBenkEfxsFxOFP8bajJDBj 3knxDFeIAqERLAvuvOcbLpjJ/ooL3dr3AfjBzUeWJSsPgkrhnE+/YfWH4SLJkYw9Z7 Mg43QkEfvg7b5y7QuSGlWsP0hYsX8Emd6u7dvTC8= 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 1065620E4064; Tue, 18 Sep 2012 00:57:22 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 18 Sep 2012 00:57:22 -0400 Message-ID: <2332934.GsfE9s5YZ9@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-31-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: References: <20120917220040.GB59832@crankycanuck.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 04:57:25 -0000 On Monday, September 17, 2012 09:37:43 PM Murray S. Kucherawy wrote: > On Mon, Sep 17, 2012 at 3:00 PM, Andrew Sullivan wrote: > > The proposed reorganization depends on three basic premises: first, > > that the current 4408-bis draft has grown and is a little unwieldy. > > Second, it's not obvious that RFC 4408 was organized as well as it > > could have been, nor even that it limited itself appropriately for > > something that is on the standards track. Third (and related to the > > second), this document is moving to the standards track, and therefore > > material that isn't really appropriate to a standards track document > > should either be removed (possibly being moved into another document > > -- leave aside the disposition for the moment) or moved into an > > appendix or other clearly-marked, non-normative section. These > > premises seem to me to be at least plausible, if perhaps not > > uncontroversially true. > > Just to be explicit, I think all of these are valid points and I > support them as reasons for considering the rearrangement of the work > to be a useful step. I don't disagree with any of these premises either. I don't think that reorganizing (or potentially splitting) provides enough benefit to overcome the inherent disruptiveness of reorganizing. If there's material that better belongs in a standards track applicability statement than a protocol document, I'm not opposed to renaming section 9 SPF applicability statement can focusing the here's how you do stuff information there. I believe that would be much preferable to a stripped down document that's approximately sections 1-8 with stuff removed. In other words, re item 3, if there's a lot of material that's inappropriate as the document is defined, then let's adjust the definition. Scott K From superuser@gmail.com Mon Sep 17 22:07:39 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D430A21F84A2 for ; Mon, 17 Sep 2012 22:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0d070UBeWkUJ for ; Mon, 17 Sep 2012 22:07:39 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A7B5821F8443 for ; Mon, 17 Sep 2012 22:07:38 -0700 (PDT) Received: by lahm15 with SMTP id m15so5003747lah.31 for ; Mon, 17 Sep 2012 22:07:37 -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=d0MvOSyqQ7c7hhY53WIxZdRRdn8sa3x3kfnHEFzx6WA=; b=xY6DX8x1G6Es4fm/1ik3z5KXqeH+HtQdV4s20be0RrQcVxxCghgT3aHZqszsLHY+JL P+TOHAd29BTqENqsaMUVM5hqizU4vt2E6Yxd0jgZNgcRPsnEATHE9cByw1G6SfKr/khS JEeEi+jPVy0BdnTNsfxX9w2HcX1XSyi/pK0aKr4MFDhHlM1zzDcWWF2kLSsJ/iOR7I8D 3AuLHyfUcL8jKrZHBpZoiVbj4LZ122bYC8OWB9J6LR1S86C/K9rWsgohcAgDu09LCyTv zpgmLOlSicExFKNMqA6REq8qsOQrJaKOFL2lRsgwOpNZ0vZtoi1fb4vxMdEU0kfKWVd7 qqGQ== MIME-Version: 1.0 Received: by 10.152.102.137 with SMTP id fo9mr11597531lab.35.1347944857347; Mon, 17 Sep 2012 22:07:37 -0700 (PDT) Received: by 10.112.44.230 with HTTP; Mon, 17 Sep 2012 22:07:37 -0700 (PDT) In-Reply-To: <2130292.uRXqCVZiUA@scott-latitude-e6320> References: <20120917220040.GB59832@crankycanuck.ca> <2130292.uRXqCVZiUA@scott-latitude-e6320> Date: Mon, 17 Sep 2012 22:07:37 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Cc: spfbis@ietf.org Subject: Re: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 05:07:39 -0000 On Mon, Sep 17, 2012 at 6:39 PM, Scott Kitterman wrote: > - While the draft may not be in the typical organization for a standards > track document, I think that if the diff is in fact kept minimal, most > questions about this can be sufficiently answered along the lines of "Yes, but > our focus was minimal change to RFC 4408 and the organization didn't seem to > be a literal error that we had to fix." Once we reorganize it, all bets are off > and we'll need to bring everything up to the current documentation standard. > I think this is rather more than we set out to do and will take us longer and > not provide end users benefit at all proportionate to the effort it takes to > produce it. I don't think the "minimal changes" thing can be used as an excuse to leave SPF, as John Leslie just put it, "rough around the edges." If we can do a good job morphing the document into something stronger and more appropriate for the standards track, I believe we really need to take this opportunity to do so even if the cost is uncomfortable. > - I am much more concerned with the impact of the reorganization on > maintainers of SPF libraries that want to update them to match 4408bis when > it's published. If they are organizaed similarly, then this audience can > easily compare (even if they don't directly diff the text) 4408 and 4408bis. > If we do the reorganization, then I think we'll need an appendix telling > people what's changed (with another chance to get things wrong). This can be mitigated by doing another thing John suggested: Include a "Changes since 4408" section. You already have that, though it's possibly more detailed that what would be needed to cover the implementer audience you're talking about here. > - The proposed reorganization divides topics up (find the two options in the > proposed reorg for getting feedback data on SPF deployment) in ways that are > arbitrary and will be hard for implementers to follow. They are hardly arbitrary. They distinguish between what's critical for the protocol to be interoperable and what amounts to guidance for operators using the protocol. That's a pretty meaningful division, not an arbitrary one. > - The proposed reorganization is clearly a precursor effort to splitting the > document in two. I think that it will be much better to have one document, > even if it's somewhat long, with proper anchors and links within it where > needed than to be constrained to external links to a document with no ability > to link to specific sections of that document (I've asked someone to tell me if > I'm wrong about this limitation and no one has spoken up). So I think that > doing a pre-split to make the split easier is an error. This over-states one of the goals. As I think I said when I first proposed it, the reorganization makes it easier to see what text could be split if the working group wants to go that way. It would also be fine to leave those sections in the same document if that earns rough consensus. The main value I see in the proposal is the separation described above. > - The organization of 4408bis has proven itself good enough to foster > multiple independent, interoperable implementations. So there should be a > certain caution in monkeying with it. In software and specification > maintenance efforts I've been involved in, it has always seemed to me that > change equated to risk and there ought to be a clear and substantial benefit to > taking that risk. RFC 4408 is provably usable as is. Any alternative is not, > so we should be conservative about what we do. The due caution I exercised is in preservation of the original text, apart from its ordering. I'm not immune to the point that there's an audience that "got" RFC4408 as-is. -MSK From spf2@kitterman.com Mon Sep 17 22:28:15 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073BA21F84DE for ; Mon, 17 Sep 2012 22:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oc7OGlHOwoAs for ; Mon, 17 Sep 2012 22:28:14 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E0BFE21F84DC for ; Mon, 17 Sep 2012 22:28:13 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0CC6120E40BD; Tue, 18 Sep 2012 01:28:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347946093; bh=FHckIwWhykL1otje6rr9J+P/FlfRPAmpWItilZsoWCo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VltPiGrJC/J0hbNGL2Zyfu1QX2Z7MQy6UdnfaJCfrw/seUMPR2htNM7iYHVsCL7/6 Jme2HMn8dCyuMPGhr8MFobCXxfRqvQIAQT1da1FFZTrQVygza9u1Hg3pnYXWCeUROo vlefWbHBi0YbWm3sCPeeM6zUChuR9nw0Xzk8v6w4= 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 D596720E4064; Tue, 18 Sep 2012 01:28:12 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 18 Sep 2012 01:28:12 -0400 Message-ID: <5369844.VrlRnrPTAT@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-31-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: References: <2130292.uRXqCVZiUA@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 05:28:15 -0000 On Monday, September 17, 2012 10:07:37 PM Murray S. Kucherawy wrote: > On Mon, Sep 17, 2012 at 6:39 PM, Scott Kitterman wrote: > > - While the draft may not be in the typical organization for a standards > > track document, I think that if the diff is in fact kept minimal, most > > questions about this can be sufficiently answered along the lines of "Yes, > > but our focus was minimal change to RFC 4408 and the organization didn't > > seem to be a literal error that we had to fix." Once we reorganize it, > > all bets are off and we'll need to bring everything up to the current > > documentation standard. I think this is rather more than we set out to do > > and will take us longer and not provide end users benefit at all > > proportionate to the effort it takes to produce it. > > I don't think the "minimal changes" thing can be used as an excuse to > leave SPF, as John Leslie just put it, "rough around the edges." If > we can do a good job morphing the document into something stronger and > more appropriate for the standards track, I believe we really need to > take this opportunity to do so even if the cost is uncomfortable. There were a lot of things going on related to SPF in 2005 that just aren't relevant today. I don't think John's characterization of the IESG of 2005's views on it is strong relevant to what we need to do. I have assumed that if the IESG didn't want us to do minimal changes, they'd have approved a different charter, but it's certainly not something I have a lot of experience with. > > - I am much more concerned with the impact of the reorganization on > > maintainers of SPF libraries that want to update them to match 4408bis > > when > > it's published. If they are organizaed similarly, then this audience can > > easily compare (even if they don't directly diff the text) 4408 and > > 4408bis. If we do the reorganization, then I think we'll need an > > appendix telling people what's changed (with another chance to get things > > wrong). > > This can be mitigated by doing another thing John suggested: Include a > "Changes since 4408" section. You already have that, though it's > possibly more detailed that what would be needed to cover the > implementer audience you're talking about here. Yes. We'd have to have this, I think. Of course then we run the risk of different parts of the document conflicting. > > - The proposed reorganization divides topics up (find the two options in > > the> > > proposed reorg for getting feedback data on SPF deployment) in ways that > > are arbitrary and will be hard for implementers to follow. > > They are hardly arbitrary. They distinguish between what's critical > for the protocol to be interoperable and what amounts to guidance for > operators using the protocol. That's a pretty meaningful division, > not an arbitrary one. I think that's true for a very narrow view of interoperability. If every email domain owner published an SPF record that said "v=spf1 ?all" and every MTA operator on the internet implemented SPF checking, there would be 100% SPF deployment and it would be fully interoperable based on what I understand your definition to be. It wouldn't actually do anything though. As long as operator goals aren't being met, then I don't think interoperability exists. The kind of interoperability you're focused on is absolutely necessary, but I don't believe it's sufficient. So I think there is a certain amount of arbitrariness about where you drew the line and how you sliced things up that will lead to more confusing and more problems, not less. > > - The proposed reorganization is clearly a precursor effort to splitting > > the> > > document in two. I think that it will be much better to have one > > document, > > even if it's somewhat long, with proper anchors and links within it where > > needed than to be constrained to external links to a document with no > > ability to link to specific sections of that document (I've asked someone > > to tell me if I'm wrong about this limitation and no one has spoken up). > > So I think that doing a pre-split to make the split easier is an error. > > This over-states one of the goals. As I think I said when I first > proposed it, the reorganization makes it easier to see what text could > be split if the working group wants to go that way. It would also be > fine to leave those sections in the same document if that earns rough > consensus. The main value I see in the proposal is the separation > described above. I agree that overstates your immediate goals, but there's a high correlation between people I've seen argue for a split (of just flat removal of information) and those supporting the split, so while your statement is correct, I can also look more than one step ahead and see where this likely heads. > > - The organization of 4408bis has proven itself good enough to foster > > multiple independent, interoperable implementations. So there should be a > > certain caution in monkeying with it. In software and specification > > maintenance efforts I've been involved in, it has always seemed to me that > > change equated to risk and there ought to be a clear and substantial > > benefit to taking that risk. RFC 4408 is provably usable as is. Any > > alternative is not, so we should be conservative about what we do. > > The due caution I exercised is in preservation of the original text, > apart from its ordering. I'm not immune to the point that there's an > audience that "got" RFC4408 as-is. Getting the text right is important, but I think it's not sufficient. I think we ought to start with a presumption that the current structure is adequate and only change it based on a really firm basis that it's going to improve understanding. Just to be clear, I don't see anything in the structure of the reorganization that is outside the scope of what it's reasonable for the working group to consider, I just don't particularly see it helping that much. Scott K From hsantos@isdg.net Mon Sep 17 23:32:32 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADBE21F8476 for ; Mon, 17 Sep 2012 23:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -85.523 X-Spam-Level: X-Spam-Status: No, score=-85.523 tagged_above=-999 required=5 tests=[AWL=-16.202, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, URIBL_BLACK=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Of9+7lh0+WY for ; Mon, 17 Sep 2012 23:32:30 -0700 (PDT) Received: from ntbbs.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 96A2521F8471 for ; Mon, 17 Sep 2012 23:32:29 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1139; t=1347949944; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=+TNCgQOgaycD08kAYMYkYyalfp8=; b=EoltsUiP49HWFIq3ez/X rzntcVTa9ID0HBu+xmwLcoqjewrhVPxJ7/C/Tmmlqi6rKSEdyqUGX8eY3UqLkL7X mcGuh4NApSxeTlTiLA3jhAQ1l7lKqul6mhuDvi8/nwPWR/4LFhjZsZ448W7bJYVJ eMe/V8tLn76Go6kIQb0Tt+Q= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 18 Sep 2012 02:32:24 -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 3971715217.11476.2036; Tue, 18 Sep 2012 02:32:23 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1139; t=1347949706; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=q3zuDOJ /q/1RThd/zZ4j8fdqYDo+Kk0A/FkRsF/SCuQ=; b=oFsgdp7+qMncmPWNKbyETVI PoaslKO2O6oPCSIjhlS7zu9JPCqhm5JKc2yQ6iDjX5u+sX2uVR5SVryQ7W2M30DA ISmkPkFlHOzyEH90LpGJ1PxyAoaPWfrjTAXDj2qyJW4C/yy5COhDbpOuEUAvvL/Q yy4NH/mYGcacQFU8pVQk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 18 Sep 2012 02:28:26 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 275537006.9.1804; Tue, 18 Sep 2012 02:28:25 -0400 Message-ID: <50581597.1090605@isdg.net> Date: Tue, 18 Sep 2012 02:32:55 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: spfbis@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [spfbis] Issue: Add IP4/IP6 Input check in section 5.6 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 06:32:32 -0000 Proposal, add the following (starter text) to 5.6. Receivers SHOULD check the ip4/ip6 and corresponding cidr malicious values which will always return a true masking match despite the client IP address. For example, a policy as follows will also return a true masking match: v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1 -all Background: I found the domain freepaylesscoupons.com in my recent logs the above SPF policy. IMO, this is an example of a malicious sender providing the illusion of a strong domain policy SPF holder with -ALL directive, yet provides an IP4 address that will always yield a positive IP4 masking match against algorithms that do not check the input. I check our SPF API IP4 match function and it does not do this check. I also check the 2004 and current versions of the open source libspf2 and my quick reading shows they do not do input checks. 4408 has semantics for returning a PermError for an illegal IP4 address. IMTO, the values 128.0.0.0 and 0.0.0.0 and/or any IP4/CIDR pairs should be considered illegal/invalid addresses if they always return a true masking match. -- HLS From vesely@tana.it Tue Sep 18 00:52:12 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3238021F877C for ; Tue, 18 Sep 2012 00:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.667 X-Spam-Level: X-Spam-Status: No, score=-4.667 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id netL7IA6idu3 for ; Tue, 18 Sep 2012 00:52:07 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id B808921F877B for ; Tue, 18 Sep 2012 00:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1347954723; bh=j2jEYpc/0c2WQ5Sc/Fv82Mnw+CfIp9LMR0Y2D28X66s=; l=1641; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=gXQYWYkPYCNCYOM3R3tzLBa1L+lIP2COmU5hsTAKqyt61/JtP+/Y9yw+I7Jg4uPdi ec2V4qeoFTPO9DXkxx5IXWP0vg5f/dHpTs0XLY6d5RvG85yNA8uzS1cdipjTty85XX +QL4wkPAVkx3v2Hnpdi8woS6KsQ+HdyaJDHY9pRU= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 18 Sep 2012 09:52:03 +0200 id 00000000005DC039.0000000050582823.00000D82 Message-ID: <50582823.4000704@tana.it> Date: Tue, 18 Sep 2012 09:52:03 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: spfbis@ietf.org References: <2313224.Yyxubt5dZV@scott-latitude-e6320> <5057AAFA.6010007@dcrocker.net> <2066271.XDCiDRdmGb@scott-latitude-e6320> In-Reply-To: <2066271.XDCiDRdmGb@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [spfbis] A proposed reorganization X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 07:52:13 -0000 On Tue 18/Sep/2012 03:23:54 +0200 Scott Kitterman wrote: > On Monday, September 17, 2012 03:58:02 PM Dave Crocker wrote: >> On 9/17/2012 1:54 PM, Scott Kitterman wrote: >>> Dave Crocker wrote: >>>> 3. You appear to believe that changing document organization >>>> somehow changes SPF syntax or semantics. Please explain that >>>> view. >>> >>> No. I think the reorganization makes it harder to understand >>> things. It's the contemporaneous effort to expunge all mention >>> of receiver policy that I believe changes things. >> >> The proposal concerns reorganizing the text. A proposal to >> alter receiver policy language is -- or should be, IMO -- a >> separate topic. > > This continues to mystify me. If people are going to read "If you > choose to do A, here is how you communicate that choice" as "You > must do A", then there's no hope. Curiously, there's plenty of people reading it that way. Is there any hope that we admit it? > Whether the example belongs there or not, I think this is a poor > reason t move it. > > [...] > > I think there are reasonable alternatives here, but I don't think > that people getting confused about rejection being required is a > good reason to change anything. Let me ask the reverse question: If that example hadn't been there, would confusing people have been a good reason to add it? And isn't that a deliberate attempt at confusing people? Having little experience with the topic, I think it's enough to look at what was written in that place in previous versions of SPF to learn what the example in question is trying to say. From john@jlc.net Tue Sep 18 01:49:25 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282AE21F878B for ; Tue, 18 Sep 2012 01:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.285 X-Spam-Level: X-Spam-Status: No, score=-106.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kz1BjrWzQgil for ; Tue, 18 Sep 2012 01:49:24 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 817F321F878A for ; Tue, 18 Sep 2012 01:49:24 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 0879833C23; Tue, 18 Sep 2012 04:49:23 -0400 (EDT) Date: Tue, 18 Sep 2012 04:49:23 -0400 From: John Leslie To: Scott Kitterman Message-ID: <20120918084922.GP21618@verdi> References: <20120917220040.GB59832@crankycanuck.ca> <20120918014042.GN21618@verdi> <10634494.TKFlndshoM@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10634494.TKFlndshoM@scott-latitude-e6320> User-Agent: Mutt/1.4.1i Cc: spfbis@ietf.org Subject: Re: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 08:49:25 -0000 Scott Kitterman wrote: > On Monday, September 17, 2012 09:40:42 PM John Leslie wrote: >>> - Third, by cleaving to the organization in RFC 4408, we make it >>> possible to compare the two documents easily, which defends >>> against the accidental (or intentional) changes going unnoticed. >> >> The IESG won't be comparing diffs; and frankly the implementors >> won't compare diffs either. The implementors will want a section >> listing issues they should check in existing 4408 implementations. > > Would you please clarify what you meant by this? I'm guessing you mean "IESG won't be comparing diffs". What I meant by that is that the IESG will properly look at RFC4408 as an Individual submission which received essentially zero review; and will be looking at 4408bis de novo. Does it meet today's standards for a Proposed Standard? > How does checking existing implementations tell anything about what's > changed in 4408bis? I'm confused. That makes two of us... The second sentence was trying to say that implementors of 4408 (not bis) will want a short section pointing out things they should check in their existing implementations to ensure that they are also compliant with 4408bis. -- John Leslie From sm@resistor.net Tue Sep 18 02:32:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589B021F844E for ; Tue, 18 Sep 2012 02:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDp4r7pkOSwx for ; Tue, 18 Sep 2012 02:32:45 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE3421F844F for ; Tue, 18 Sep 2012 02:32:45 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8I9Wbjv008671; Tue, 18 Sep 2012 02:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347960764; bh=QbfDSyEzzd0wnVYVNRa24vWDSI/P3v3TTyzxlVzw4Go=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=lIIu1Uqrz4Nz48qng0a5wKi4OkEYJu0ZO4cH+IdaC6fpN2P9FnDF6np/Sov0zuBGM c50Alis5WJLc7QiIF67MwppCRfmRQHrgd49iE0q8KGN34OX74AqOkUJkd3TIVIFGRW WUpqPEmdRYABSYSUSIccZM+3wLs2ta4UB39ZkT7k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1347960764; i=@resistor.net; bh=QbfDSyEzzd0wnVYVNRa24vWDSI/P3v3TTyzxlVzw4Go=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=DowCAYH7f9sJFEI/kPKaJbekyUKpi34ObptgavWdI+mjRXk7RFjk1H+90vQD2WDl3 6uRn7F8NUrJhXEo8CCUqG60idSWn7yguvx2syIgXcLGrj9+U6TWiXFp8bus2nYcxOD Qu410veotzkvyN2oSq0yz4ZiL8BPP2O0bmAqaL/0= Message-Id: <6.2.5.6.2.20120918002236.0772db20@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 18 Sep 2012 02:12:16 -0700 To: spfbis@ietf.org From: SM In-Reply-To: <20120918014042.GN21618@verdi> References: <20120917220040.GB59832@crankycanuck.ca> <20120918014042.GN21618@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: John Leslie Subject: Re: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 09:32:46 -0000 At 18:40 17-09-2012, John Leslie wrote: >carefully enough to discover some rough edges. If we have good >answers to how these can be fixed, I expect RFC4408bis to sail >through easily enough -- if we don't, the charter limitations >won't save us. (The charter limitations are there because the >proponents wanted them, not because the IESG wanted them.) One of the effects of having a discussion is to have good answers to know a problem can be fixed. It may happen that there are good answers explaining why a problem cannot be fixed. > The IESG won't be comparing diffs; and frankly the implementors >won't compare diffs either. The implementors will want a section >listing issues they should check in existing 4408 implementations. Yes. I'll borrow a line from Andrew; there are no hard and fast rules. Andrew Thisell mentioned that any reorganization will burn a lot of time. Dave Crocker mentioned layering. There are multiple implementations of RFC 4408. There aren't any implementations of 4408bis. This gets me back to John Leslie's comment about changes. Here's the diff I looked at: http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/rfc/rfc4408.txt&url2=http://tools.ietf.org/id/draft-ietf-spfbis-4408bis-07.txt Any work on a specification can introduce accidental changes. The message [1] posted by Andrew asked participants to clarify what trade-offs they think are acceptable as a result. My personal opinion is that it's not a matter of choosing between two alternatives. I went through this thread and I did not find trade-offs. Maybe I missed them. Regards, -sm 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02912.html From spf2@kitterman.com Tue Sep 18 04:24:42 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80EA221F8767 for ; Tue, 18 Sep 2012 04:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FS56b4rr-r+E for ; Tue, 18 Sep 2012 04:24:41 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id D48E321F8764 for ; Tue, 18 Sep 2012 04:24:41 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id ECC44D04085; Tue, 18 Sep 2012 06:24:40 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1347967481; bh=3tNoQY62ogJJs5hcNW1cBFyfYxjtBTRyAY281XJhiOw=; h=In-Reply-To:References:Subject:From:Date:To:From; b=ECd92R5Pf9yOAW0fAy5Y9Rtu21F0KqG/IjbP5bCBKbimlbttCK9INgzOF/L2ITeuB 5CZwPdFJtS277KbqgIfZqM/28WX+Sb5HWMjWtbk7VIkzk3TyaxFO1Vc+Q7xKTojZUI Rf/TQ1uwtPDz+fXmDMCiaaSBAI9O11NQ+S/VZSEc= Received: from [IPV6:2600:1003:b023:bd61:7754:f4eb:c951:4971] (unknown [IPv6:2600:1003:b023:bd61:7754:f4eb:c951:4971]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 746CAD04081; Tue, 18 Sep 2012 06:24:40 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <20120918084922.GP21618@verdi> References: <20120917220040.GB59832@crankycanuck.ca> <20120918014042.GN21618@verdi> <10634494.TKFlndshoM@scott-latitude-e6320> <20120918084922.GP21618@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 18 Sep 2012 07:24:36 -0400 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 11:24:42 -0000 John Leslie wrote: >Scott Kitterman wrote: >> On Monday, September 17, 2012 09:40:42 PM John Leslie wrote: >>>> - Third, by cleaving to the organization in RFC 4408, we make it >>>> possible to compare the two documents easily, which defends >>>> against the accidental (or intentional) changes going unnoticed. >>> >>> The IESG won't be comparing diffs; and frankly the implementors >>> won't compare diffs either. The implementors will want a section >>> listing issues they should check in existing 4408 implementations. >> >> Would you please clarify what you meant by this? > > I'm guessing you mean "IESG won't be comparing diffs". > > What I meant by that is that the IESG will properly look at RFC4408 >as an Individual submission which received essentially zero review; >and will be looking at 4408bis de novo. Does it meet today's standards >for a Proposed Standard? > >> How does checking existing implementations tell anything about what's >> changed in 4408bis? I'm confused. > > That makes two of us... The second sentence was trying to say that >implementors of 4408 (not bis) will want a short section pointing out >things they should check in their existing implementations to ensure >that they are also compliant with 4408bis. > OK. Thanks for clarifying. Scott K From agthisell@yahoo.com Tue Sep 18 04:25:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055EA21F876C for ; Tue, 18 Sep 2012 04:25:23 -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.574, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jwao4nuNVgxC for ; Tue, 18 Sep 2012 04:25:22 -0700 (PDT) Received: from nm36-vm5.bullet.mail.ne1.yahoo.com (nm36-vm5.bullet.mail.ne1.yahoo.com [98.138.229.117]) by ietfa.amsl.com (Postfix) with SMTP id 6383821F8764 for ; Tue, 18 Sep 2012 04:25:22 -0700 (PDT) Received: from [98.138.90.57] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 11:25:19 -0000 Received: from [98.138.226.165] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 11:25:19 -0000 Received: from [127.0.0.1] by omp1066.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 11:25:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 305824.18844.bm@omp1066.mail.ne1.yahoo.com Received: (qmail 71151 invoked by uid 60001); 18 Sep 2012 11:25:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347967519; bh=h9b8GQhACjET9n7ETeiD5+3NgItiXDj+m2kD0f0e2V4=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=fCxdfw82lCr/SnkG7MrmRcyi6Qj4UoHaPvBm4/4F2h+EN9TwPG02IDFTX4x4izho4frGhzvybymsZsCrvSQ4quGyNuFupJDzzSK9oiT4N4/LVwGfLcVnP0Nugd3RnNIF/vFwOe7+lcFjvTaaMmhIZ25aRm34XxqeiwhEtJ8Rd3U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=YkKOPZZlDtDDDvgmk2XgEwuDpmh12mJaVzFfSRr6qf6KYoZkI+OzRdaKfNirY1gYyFTkcRTVHyd2o3VNCJEPp0J3eahqXC0oQaSn0aNM135OYgf9b5LxHuo6h+WiisUp19JRmBPzA88lePgbd8LM7gF3984I6OprwKf4ehB34UI=; X-YMail-OSG: 7ytGBAsVM1mVHzyFTgq88Jm2HS_mseVCg5N6sVu7JvRsWMI Z.qTM9UIgtjnjw1otgkBQ0O2N8ZsZVBDJny8_d_x_y0yQnnQXY0XNJ.VKNxr 9WijiA4t4UcX.UmSKseCAs5rRAFkddwNyxwaJ3V2EG3R6kdOBMuk.R9.co3i YMleP9.WggzjkLXimKQyl1Lv6j9N_awdRG.CAY9fGJfuEY1OvJAUybAs.DFZ xRY8FVllRv8KZbf1wRalpAplgroMpD5q5DZ5WfcIEbmxNCUPPaIGJaZjmzVB bjNcq7MCHFN6bdQT46hq3QwxYt2rqKcykyFIZlDihzF.w4sVhM2K22WBu9mx HA9Q9fiwwacSky5.yC22Ut9GYrRhBLyszraqK8OzfV3ayI2g.inyTZh5r4ag gPmXgxb6qHev5komEkFn6d11Bg3X0mA41PzxXTBufMBWPPKEoggJJ9xmUtYX oHdKf2OzETnqqhzWCs4w- Received: from [71.61.133.134] by web125105.mail.ne1.yahoo.com via HTTP; Tue, 18 Sep 2012 04:25:18 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347967518.67067.YahooMailClassic@web125105.mail.ne1.yahoo.com> Date: Tue, 18 Sep 2012 04:25:18 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 11:25:23 -0000 > What I meant by that is that the IESG will properly look at RFC4408 > as an Individual submission which received essentially zero review; What color is the sky in your world? RFC 4408 got vastly more review that the vast majority of proposed standards. If DKIM had gotten as much review as SPF, it would never have made it to an RFC. Both the use of the underscore domain and the DNS tree walking were considered killers for SPF. From agthisell@yahoo.com Tue Sep 18 04:33:23 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC94C21F8608 for ; Tue, 18 Sep 2012 04:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kn5AZ8HRazx0 for ; Tue, 18 Sep 2012 04:33:23 -0700 (PDT) Received: from nm1-vm1.bullet.mail.ne1.yahoo.com (nm1-vm1.bullet.mail.ne1.yahoo.com [98.138.91.36]) by ietfa.amsl.com (Postfix) with SMTP id 61DA321F8602 for ; Tue, 18 Sep 2012 04:33:23 -0700 (PDT) Received: from [98.138.90.54] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 11:33:16 -0000 Received: from [98.138.87.5] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 11:33:16 -0000 Received: from [127.0.0.1] by omp1005.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 11:33:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 136017.446.bm@omp1005.mail.ne1.yahoo.com Received: (qmail 44597 invoked by uid 60001); 18 Sep 2012 11:33:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347967995; bh=VKUJvNjV5hpc9Iyvo5NVbCvyO9dABDnlGN3gjzhRL/Y=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=2vvydpG87PhScTvqohhkVPN71QZs9pT9Wizdd29cyn2nGbvuBDrmVXtPWzgqs5KIcEnjRbLWKgCW/k/6t8iqKMurncoh66n3FFVWDXZvC9qPJfqyd2Q3C+EpNiapHN3wCzvKLkeykB4WHkleEq8B92rTupttWbMxkX9nE01im4I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=s+Ln+XIm+CTHx8WKtm9Qbt9GkFlzYNzno7sJCAzWVCW6nSRYDI+h83W0e3A0/7LTQc/B+EN6LZwJKU6dMEUpmhJEm38VfWBrhdTrMvwq3r/Xe2rWpnzu0BXF5l9S81D009XHew/3PZC3hMjqLJlRYmQpI66gIiBn+ZzlKbeNJ+Y=; X-YMail-OSG: cMjKmMcVM1nyScK6.cTh4gdoD.hiGTNyGBtIL79uPK8hb.G ccefQjM38FG_sp9ytuRn2bdVhGaL4O10oSRctiEGWJV.Hn.4.4PqJkCsCyDh B6XHcq1I82PIN37AtzAnSm14RwfaTtfm06Q8QCbRyQAe55RY7uHL.oVBzsd3 LrB_RStL4cf96SuSEUBrzrmVKp6qV_xmRLiqSwfec7zwD34ME6PnwJ3Hpt_b PttFm924ahNVvaP6tUMUMt9vYrn6s41RgbbNw_vp8pA0aSgpYyAADOb6yfzd sm.refbtYkdXi2tvl_OB1HeA_49ECKlAiY4O.t6xJQayhSh09cfLxKhXfzLM mTDxNktblhDC_.vY19JlaIGaCxN4xtcR1RkpMhG5u7q6kacJOEcdhGa.WmdU 2NY8WhS.se0QJEjCudG2JZNEQ9PthALvQunhll5FFxN3NX46yFR0Km5HqgdI IZc6xN7iNw4Z_8_.OEMVbKF0KOWYqo6c4n3GQZlsucAtZHp9VlMZkr97usJM f4Fy7cZb5VxKnq6iL3nIYpqRX5Y0nr.7LRiabdkbqZQEPyyKx2tdeYZoaVC2 Rfco- Received: from [71.61.133.134] by web125106.mail.ne1.yahoo.com via HTTP; Tue, 18 Sep 2012 04:33:15 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347967995.23242.YahooMailClassic@web125106.mail.ne1.yahoo.com> Date: Tue, 18 Sep 2012 04:33:15 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [spfbis] Issue: Add IP4/IP6 Input check in section 5.6 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 11:33:24 -0000 > v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1 -all This kind of thing was discussed some while SPF was being developed. The conclusion was: so what? an SPF pass doesn't mean te email is good, it means you can accurately use (and create) a reputation for that domain. Trying to prevent the creation of an SPF record that always passes was never a design goal, so no effort was taken to even try to prevent this particular trick, or a dozen other variations. From sm@elandsys.com Tue Sep 18 04:45:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC6F21F86FC for ; Tue, 18 Sep 2012 04:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQItpmQ4qHlg for ; Tue, 18 Sep 2012 04:45:25 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C18721F86FA for ; Tue, 18 Sep 2012 04:45:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.41]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8IBjA5k002599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2012 04:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347968723; bh=CLGG1qWyWNIVwJVpTXRdgw7aMjzFDUMuID3Ha9hL6Hw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=d3XTWatvMb6PZGHMlxeeqmPREoOeI0NOS4kbsm50f0GJbIsX06iOpv7oen1McZbP6 diWfpMhaGvAFu0kLFeHt/1IgcBLostEnClhv94/9MMeXyzs0WdOX6nKIec/zw3CowU RPtYu3u0HtHXqY0a3dKsm6teLyFFPvuOitbqs2hQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347968723; i=@elandsys.com; bh=CLGG1qWyWNIVwJVpTXRdgw7aMjzFDUMuID3Ha9hL6Hw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=lJDywcIL/TrhP0PIewF7DrAL+QtwlK+24f32FFuciUk3vRpq2tRddxYEnLEUzz7fP 6azExLhpaqkdLrA/cJAsIdhnWUwB+gv5Kg+thPD567tesvcW84QgQzPHxCOZ1/UKr5 q8IF16iKbSiU1iMYpEB+0yqk1qZCSvcCcbiVrp1s= Message-Id: <6.2.5.6.2.20120918023453.0772db20@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 18 Sep 2012 04:21:10 -0700 To: Scott Kitterman From: S Moonesamy In-Reply-To: <5369844.VrlRnrPTAT@scott-latitude-e6320> References: <2130292.uRXqCVZiUA@scott-latitude-e6320> <5369844.VrlRnrPTAT@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 11:45:26 -0000 Hi Scott, At 22:28 17-09-2012, Scott Kitterman wrote: >As long as operator goals aren't being met, then I don't think >interoperability exists. The kind of interoperability you're focused on is >absolutely necessary, but I don't believe it's sufficient. I'll comment on the IETF perspective as the draft is intended to document IETF Consensus. This is the guidance provided in RFC 2119: "Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability." It can be argued that the above takes a narrow view of interoperability. Having the interoperability only does solve the problem. In my short experience RFC authors usually follow the guidance in RFC 2119 for usage of RFC 2119 key words. If I had to describe interoperability, I would say that it is about the required bits for two ends to "talk" to each other. It takes more than that to solve a problem. However, the interoperability aspect is no longer a problem to solve. From an IETF perspective it is a step forward as the user can have a product from one vendor at one end and a product from another vendor at the other end. I hope I am not mistaken in saying that all operators do not have the same requirements, i.e. there are different use cases. I define what problem I am trying to solve and then see how to solve it. I should also work on building consensus so that my proposed solution gains IETF Consensus. Regards, S. Moonesamy From hsantos@isdg.net Tue Sep 18 05:26:04 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C9A21F870F for ; Tue, 18 Sep 2012 05:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.712 X-Spam-Level: X-Spam-Status: No, score=-101.712 tagged_above=-999 required=5 tests=[AWL=0.887, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugC5UZP0O2wx for ; Tue, 18 Sep 2012 05:26:03 -0700 (PDT) Received: from mail.santronics.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7283521F8735 for ; Tue, 18 Sep 2012 05:26:03 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1493; t=1347971154; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=HM7GmX21laUKS/KEx45gKXuO6Bg=; b=mmitUABaddRDosgciDNc LfJMpVXyNU6x2pUojCOOBgLY7LRUV7VmVbKe3kUEGkSwiUkm4pKoyuSDUlaUV/In 6ATnndi6OgCk7HcoZyrhU8cP8bj4/z0jDdj8XUXPMxH975RYnkAxg0CQE52Gg3qi hT0ozQv/M+CtPdxoGHVdp6o= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 18 Sep 2012 08:25:54 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3992925456.11476.2596; Tue, 18 Sep 2012 08:25:53 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1493; t=1347970918; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=JbvMbff 28yQ1RpbOn2v+aUcQtvTVYe7jy9wXm1UCc4w=; b=rNb+yts3khNtjdKn+gxcyXC NfKs6VN6pCTOpnLkNEzsUaEVftkSKhZaNE+d8nyyJdsjOMlX99spKdNhBgvBQ8au 9vg3L6/yzc4DmHiodpnICLcQj4jyvt1vMHzim8iot/He+3aMUvCIw+C8DzfOudLg Zol9vcYZIOQb3TggfqDc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for spfbis@ietf.org; Tue, 18 Sep 2012 08:21:58 -0400 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 296749428.9.4888; Tue, 18 Sep 2012 08:21:57 -0400 Message-ID: <50586873.8040907@isdg.net> Date: Tue, 18 Sep 2012 08:26:27 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: spfbis@ietf.org References: <1347967995.23242.YahooMailClassic@web125106.mail.ne1.yahoo.com> In-Reply-To: <1347967995.23242.YahooMailClassic@web125106.mail.ne1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: spfbis@ietf.org Subject: Re: [spfbis] Issue: Add IP4/IP6 Input check in section 5.6 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 12:26:04 -0000 In general, I'm of the opinion that in the 9+ years of empirical operations, 4408BIS "SHOULD" include learned optimization methods that will minimize DNS operations. So it would be one method to learn it (a domain reputation) after the fact, but the protocol itself should/can be improved with deterministic error checking. Think of a neural network and/or fuzzy logic where the closer you get (with added weights) to a whole number the more confident you have in yields. Query dissemination is when our brains no longer has to calculate that 10 x 10 is 100 - no more learning is required, it zooms into the answer. Anyway, another view Arthur is where 0.0.0.0 or 128.0.0.1 are considered invalid IP4 addresses and therefore, if so, then 4408 has already semantics for returning PermError. Thanks for your input -- HLS Arthur Thisell wrote: >> v=spf1 ip4:128.0.0.0/1 ip4:0.0.0.0/1 -all > > This kind of thing was discussed some while SPF was being developed. The conclusion was: so what? an SPF pass doesn't mean te email is good, it means you can accurately use (and create) a reputation for that domain. > > Trying to prevent the creation of an SPF record that always passes was never a design goal, so no effort was taken to even try to prevent this particular trick, or a dozen other variations. > > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis > > -- HLS From ajs@anvilwalrusden.com Tue Sep 18 05:58:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9B721F8691 for ; Tue, 18 Sep 2012 05:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbfWEQkBsAit for ; Tue, 18 Sep 2012 05:58:35 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id F285221F8503 for ; Tue, 18 Sep 2012 05:58:34 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 85A098A031 for ; Tue, 18 Sep 2012 12:58:33 +0000 (UTC) Date: Tue, 18 Sep 2012 08:58:29 -0400 From: Andrew Sullivan To: spfbis@ietf.org Message-ID: <20120918125810.GA62712@mx1.yitter.info> References: <1347967518.67067.YahooMailClassic@web125105.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1347967518.67067.YahooMailClassic@web125105.mail.ne1.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [spfbis] moderator message (was: Goals of this discussion) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 12:58:35 -0000 Dear colleagues, I'm hanging this on Arthur's mail because it's a convenient example this morning, but this is a general remark to everyone. On Tue, Sep 18, 2012 at 04:25:18AM -0700, Arthur Thisell wrote: > What color is the sky in your world? In the event you feel compelled to make a snide remark in your response to someone, I strongly suggest you save the draft, go have a cup of whatever relaxes you, and then re-read your draft before sending it. How would you react if you received such a message? If the answer is "badly", perhaps you can find another way to make the same point. This issue is charged enough on its own without people speaking insultingly to one another. > RFC 4408 got vastly more review that the vast majority of proposed > standards. If DKIM had gotten as much review as SPF, it would never > have made it to an RFC. Both the use of the underscore domain and > the DNS tree walking were considered killers for SPF. The analogies with DKIM on this list seem almost never to be doing any real work. Arguments from analogy always depend critically on an agreement about ways in which the analogue and the primary subject are similar. Since the very fact of the matter about what happened with DKIM is going to be hard to establish, these analogies are either doomed to failure (because we don't agree on the similarities), or else they are question-begging (because they are assuming the relevant difference, and then using the difference in a reductio argument to show that SPF should be treated some way. I knew that philosophy degree would come in handy some day). Please stop with the DKIM-based arguments. They do nothing to advance any useful argument about SPFBIS and they're a distraction to the work. Thanks, A (as moderator) -- Andrew Sullivan ajs@anvilwalrusden.com From agthisell@yahoo.com Tue Sep 18 06:37:46 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498A821F8621 for ; Tue, 18 Sep 2012 06:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.766 X-Spam-Level: X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Kcm5EvqqM85 for ; Tue, 18 Sep 2012 06:37:45 -0700 (PDT) Received: from nm4-vm4.bullet.mail.ne1.yahoo.com (nm4-vm4.bullet.mail.ne1.yahoo.com [98.138.91.164]) by ietfa.amsl.com (Postfix) with SMTP id BB4CC21F860D for ; Tue, 18 Sep 2012 06:37:45 -0700 (PDT) Received: from [98.138.226.177] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 13:37:35 -0000 Received: from [98.138.89.240] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 13:37:35 -0000 Received: from [127.0.0.1] by omp1013.mail.ne1.yahoo.com with NNFMP; 18 Sep 2012 13:37:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 660234.35417.bm@omp1013.mail.ne1.yahoo.com Received: (qmail 91453 invoked by uid 60001); 18 Sep 2012 13:37:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1347975455; bh=HYeFN1FHa835PDypnnBInwVlt0T5bBi36RWpSxcYv8E=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=nZUppXCjjJAExG1ygxjvcUR8/43gncwsU4VTmacfSZlf+BdpvzyhhiYikeoDXKT3mbA0x2o5hcCw2tnzO16YiGDyqZSoJelZu4N2ZlLztOsNf2tTQqeVP7rK0BBViBA/Qx9EYSUYf94oY2B7O5ft8DuNdjp1ZLDIfgQZ4uBBN5A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=1Q3eE+ZUyNclMNrwsxUQDCz87TKhhodj3x0nQWst4U8USV5l+4skXYg1foPpegXDQ2AM8DJsnmO8QgEo0BNjf2ZRZQKHf3nvOUbneclhFlVmWEWtZ5OxmzYqw7UqYjbV4ZKFInV5/vFZkZ5/gM8Xzunij6OiHEIYn4WaixLXohM=; X-YMail-OSG: N9NKI_gVM1m3EkHtC_kBkPHKnc5z4vzIDSASc.cdpngYEXa TvtBl6Nsck5JvqkDvdfQFn4V.I.O3ID_sb84ZKlj20OmMZZ9F.A5KM1vZlzx cP5bcMgz3lFHmQ6qyRMTIdAtHNr4Uv55_WakYhsevipvpPJ74ItZ.9aYF_ID PPN42o9O4_bVW9u4nGw2cUtNTu.i2W6qACXLytv8GF5qL0ci6vZbbfx.I7fE hjz.4ud0uHDx7m3ApctDutIjUMiTJo2Xk9Ggc1w.YaVsQWCCBz2xVsbDvJva D0ajxOo56t2n7P3fMttoYIPomRKH6WVGwu4bVeLP0w0Z_zNhMQsRj9d13vsP Zy7wftdAGrCkM0xlFl93GIaE9x9tQhoNpueasJMZ.aw.MGmgxhGD_D6X_NT4 udnTxZbxGEKMgZSXFEkQkOCRRNwbOqTDPnjHtZDEFIW__hJ_F3h2RMCGJ4Sz DcTQn_3Xzol_wxVLlmi6zeLSZM3spYpEAc0qS8Qjw Received: from [71.61.133.134] by web125103.mail.ne1.yahoo.com via HTTP; Tue, 18 Sep 2012 06:37:35 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1347975455.79005.YahooMailClassic@web125103.mail.ne1.yahoo.com> Date: Tue, 18 Sep 2012 06:37:35 -0700 (PDT) From: Arthur Thisell To: spfbis@ietf.org In-Reply-To: <20120918130142.87013.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 13:37:46 -0000 > Did anyone seriously suggest an _spf prefix? IIRC, SPF used _smtp_client early on (similar to, IIRC, DMP), but it was changed because DNS folks objected that it broke wildcards. From sm@elandsys.com Tue Sep 18 11:54:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361F021E8106 for ; Tue, 18 Sep 2012 11:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FR012BeWJaIj for ; Tue, 18 Sep 2012 11:54:57 -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 6FBCE21E8034 for ; Tue, 18 Sep 2012 11:54:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.41]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8IIshep004768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Sep 2012 11:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347994495; bh=hyE97YrSU6I59ueexDjrAmjM5JsyxQzwYcTZfMkpolM=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=fLJ5inu8URuHqdla9CBVkgfp4M2xgBMGj0X+v86IQLerTIfGG99kKULYvLWN/kyZb sKJzN2Q2IuYiTcMfQ7gJxCscX6D7BsNgkzvpYtU0C5bKT9AowNQnFREzjiXv0gxdFR 06CpqhOPgTimRC0eJYrQeyykjCQ2ksihXzMZSdHk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1347994495; i=@elandsys.com; bh=hyE97YrSU6I59ueexDjrAmjM5JsyxQzwYcTZfMkpolM=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=M/kynmk2qfAFb+agFLaryne2FSd7+j10OjLAaM5ZFkEA7bHHa7mj/GMWPFGnfrSvL f8gvRJwS/JFmgE4r9qH4cGzvBDkS4iQz6aqxPa8p8mfu6ASQxpav4x9PtVix4Iho9i Jp/DGg7d509j0OQb1PWMGuPK3B9jNg5BblF42p2g= Message-Id: <6.2.5.6.2.20120918112836.0a148190@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 18 Sep 2012 11:52:48 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1372205.frOhBsbhem@scott-latitude-e6320> References: <503B8A4C.9030701@tana.it> <7967888.2HlpJJ7FlH@scott-latitude-e6320> <20120827235904.GI72831@verdi> <1372205.frOhBsbhem@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 18:54:58 -0000 Hello, At 20:55 27-08-2012, Scott Kitterman wrote: >Upon reflection, I could have put this more clearly. The sender >policy is the >list of authorized sources published in the SPF record. The output of >check_host() is an assessment of a message relative to that policy. Is it >policy conformant, policy non-conformant, or unknown (of some variety). > >That assessment is not an action. It's an input into receiver policy. The >receiver policy is entirely a local matter of how to dispose of the message. >There are a number of things that can be done with it. John Leslie mentioned that '"sender policy" should reflect what the sender _does_ - not what the sender hopes some other MTA will do'. If there is agreement on the above arguments, the WG could look at this in from an angle where issues are identified. For example, Alessandro Vesely commented on receiver behavior in a message at http://www.ietf.org/mail-archive/web/spfbis/current/msg02864.html If the WG agree that an issue is indeed a problem that has to be fixed, the next step is to find the fix. For example, Arthur Thisell proposed the following text: 'A "softfail" result says that the ADMD would like the result treated somewhere between "fail" and "neutral"/"none". The domain owner believes the host is not authorized but is not willing to make a strong policy statement. SPF verifies that treat "softfail" results as harshly as a "fail" can cause ADMDs not to publish such a strict SPF policy, or not to publish an SPF record at all.' Is this an acceptable approach to tackle Section 2 of draft-ietf-spfbis-4408bis? Regards, S. Moonesamy From WebMaster@Commerco.Net Tue Sep 18 12:39:13 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D1611E808E for ; Tue, 18 Sep 2012 12:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.523 X-Spam-Level: X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyHzwqCTD6zx for ; Tue, 18 Sep 2012 12:39:12 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 45BB311E80A6 for ; Tue, 18 Sep 2012 12:39:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Net; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=25xA+2urZ7yC6uTCUrhBVNYrRENMc/V/sj/EzO4MN9Le+OsX4fcy0PRNs/vB+nomlkHG9kdv3+lLiD0jYLAYN/BTwIOIHv7sO/oiosseTPg+RtDyaeYcm5skjYqw4lGwp5AV0Iy1JHWGhvHUV/L6Je7O95bFQeb+KfPSKhXRDw4= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]); Tue, 18 Sep 2012 19:39:03 +0000 Message-ID: <5058CDD1.2060805@Commerco.Net> Date: Tue, 18 Sep 2012 13:38:57 -0600 From: Commerco WebMaster User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: S Moonesamy References: <503B8A4C.9030701@tana.it> <7967888.2HlpJJ7FlH@scott-latitude-e6320> <20120827235904.GI72831@verdi> <1372205.frOhBsbhem@scott-latitude-e6320> <6.2.5.6.2.20120918112836.0a148190@resistor.net> In-Reply-To: <6.2.5.6.2.20120918112836.0a148190@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 19:39:13 -0000 SM, On 9/18/2012 12:52 PM, S Moonesamy wrote: > Hello, > At 20:55 27-08-2012, Scott Kitterman wrote: >> Upon reflection, I could have put this more clearly. The sender policy >> is the >> list of authorized sources published in the SPF record. The output of >> check_host() is an assessment of a message relative to that policy. Is it >> policy conformant, policy non-conformant, or unknown (of some variety). >> >> That assessment is not an action. It's an input into receiver policy. The >> receiver policy is entirely a local matter of how to dispose of the >> message. >> There are a number of things that can be done with it. > > John Leslie mentioned that '"sender policy" should reflect what the > sender _does_ - not what the sender hopes some other MTA will do'. That seems reasonable, however, because SPF has a number of possible options available to publishers, it seems rather important to explain what the consequence of one option is over another within the specification for SPFbis. The publishing of an SPF record simply indicates what a DOMAIN owner claims are one or more authorized machines that can send email out on behalf of the DOMAIN. Perhaps I am stumbling over a case of semantics (because SPF is "Sender Policy Framework" rather than "Domain Policy Framework"), but when I read "sender" in John Leslie's quote, I started thinking the sending MTA. I am pretty sure the spirit of John Leslie's words are right on target, but we might want to clarify wording to avoid confusion with an actual sending MTA in the discussions. Of course, a sending MTA does not even need to be SPF aware. Also, if the expectation is that some syntax be published in order to make a declarative statement about what a publisher contends is true of their domain (e.g., "v=spf1 -all" = The domain for which this txt record is published should not be sending email), then it seems like it would be minimally helpful for a publisher to understand and have an expectation for what the rough result of their publishing choices might be from the receiver's perspective in order to correctly choose an SPF syntax to implement. Some expectation of what a receiver might do with the publisher's syntax is ultimately not telling the receiver what to do, but rather help the publisher understand what they should be putting in those DNS TXT records in order to achieve their desired result from publishing SPF TXT records in the first place. > > If there is agreement on the above arguments, the WG could look at this > in from an angle where issues are identified. For example, Alessandro > Vesely commented on receiver behavior in a message at > http://www.ietf.org/mail-archive/web/spfbis/current/msg02864.html > > If the WG agree that an issue is indeed a problem that has to be fixed, > the next step is to find the fix. For example, Arthur Thisell proposed > the following text: > > 'A "softfail" result says that the ADMD would like the result treated > somewhere between "fail" and "neutral"/"none". The domain owner > believes the host is not authorized but is not willing to make a > strong policy statement. SPF verifies that treat "softfail" results > as harshly as a "fail" can cause ADMDs not to publish such a strict > SPF policy, or not to publish an SPF record at all.' > > Is this an acceptable approach to tackle Section 2 of > draft-ietf-spfbis-4408bis? > > Regards, > S. Moonesamy > _______________________________________________ Best, Alan M. From sm@elandsys.com Tue Sep 18 14:40:41 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA6F21E8041 for ; Tue, 18 Sep 2012 14:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WszbJiDgzgBH for ; Tue, 18 Sep 2012 14:40:40 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B42C21E8037 for ; Tue, 18 Sep 2012 14:40:39 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.41]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8ILeOsM002359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Sep 2012 14:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1348004436; bh=+bBDcSBjC5mbf7DZS0so7xk5SSx0oRsD4Ao1Psc/Jn0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=E/dX5ik6YBvxrmex8N315qgqn96HJxVfFAQIoWJJA/0KglOZUAflZyXxkIgy+AOjU GHTQhoS/r7gCH0ahnOS/GrUSR9NqFX23zbrHAbrlYrhQ/0zh9mgHEF8pi9yWszY+no jHpzKtqiKG35j3Pvi57eIZgXliPzcvY+wilpQ2VY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1348004436; i=@elandsys.com; bh=+bBDcSBjC5mbf7DZS0so7xk5SSx0oRsD4Ao1Psc/Jn0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=sIhzZOPOgy/cVJrpZ2v0F14NJlKI8MN6Sqd1va5+36zWUChEyLwQ+XQ8WVnXCGI4C j3tcnngHcmsCut27z2ra8oVQIGqBbJ2pocNeLt3g0B0MFrLgqGb8apXe64KA59Er6w Pkm6Q31SEhTgCcUPtBsS+e1umQcHhGo8uV+Wyem4= Message-Id: <6.2.5.6.2.20120918131824.07703248@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 18 Sep 2012 14:40:04 -0700 To: Commerco WebMaster From: S Moonesamy In-Reply-To: <5058CDD1.2060805@Commerco.Net> References: <503B8A4C.9030701@tana.it> <7967888.2HlpJJ7FlH@scott-latitude-e6320> <20120827235904.GI72831@verdi> <1372205.frOhBsbhem@scott-latitude-e6320> <6.2.5.6.2.20120918112836.0a148190@resistor.net> <5058CDD1.2060805@Commerco.Net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 21:40:41 -0000 Hi Alan, At 12:38 18-09-2012, Commerco WebMaster wrote: >That seems reasonable, however, because SPF has a number of possible >options available to publishers, it seems rather important to >explain what the consequence of one option is over another within >the specification for SPFbis. Let's talk about that when we get there. In other words it is easier to solve one problem at a time. >The publishing of an SPF record simply indicates what a DOMAIN owner >claims are one or more authorized machines that can send email out >on behalf of the DOMAIN. Perhaps I am stumbling over a case of >semantics (because SPF is "Sender Policy Framework" rather than >"Domain Policy Framework"), but when I read "sender" in John >Leslie's quote, I started thinking the sending MTA. I am pretty >sure the spirit of John Leslie's words are right on target, but we >might want to clarify wording to avoid confusion with an actual >sending MTA in the discussions. Of course, a sending MTA does not >even need to be SPF aware. May I suggest that we focus on Section 2 first? I picked that section as Arthur Thisell proposed some text. If it seems to follow the spirit of John Leslie's words, it is an alternative worth considering. >Also, if the expectation is that some syntax be published in order >to make a declarative statement about what a publisher contends is >true of their domain (e.g., "v=spf1 -all" = The domain for which >this txt record is published should not be sending email), then it >seems like it would be minimally helpful for a publisher to >understand and have an expectation for what the rough result of >their publishing choices might be from the receiver's perspective in >order to correctly choose an SPF syntax to implement. The above sounds helpful to me. Let's see how to make productive use of it. >Some expectation of what a receiver might do with the publisher's >syntax is ultimately not telling the receiver what to do, but rather >help the publisher understand what they should be putting in those >DNS TXT records in order to achieve their desired result from >publishing SPF TXT records in the first place. How important is it for me to believe the above? :-) It's going to be difficult to sell that line to the IETF community. Regards, S. Moonesamy From spf2@kitterman.com Tue Sep 18 15:33:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB64B21F851C for ; Tue, 18 Sep 2012 15:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20O4xy9aRL1j for ; Tue, 18 Sep 2012 15:33:17 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5AF21F8522 for ; Tue, 18 Sep 2012 15:33:17 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 296D7D04085; Tue, 18 Sep 2012 17:33:16 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1348007596; bh=DPKZklOlctkf+mPu5yx8KTxXMGs13oPV6H3rsKidyTU=; h=In-Reply-To:References:Subject:From:Date:To:From; b=iSxiIO0rd1FeLpx9Wwa9PwzcPrfWzkoXvenK3euzc2GWSt+oTEpnuOdaPdFO3qKIQ RC23A+RuuHt18Q1YkbLt1peaS9Q0E9KnUzNbjjX1Cvp0XPqlGMDJTt8K/JSBi8JVHz rf2LJNy2N4LiL83/tg5sz7g89Z3oMd0gw05JZ7+U= Received: from [192.168.111.104] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 78518D04005; Tue, 18 Sep 2012 17:33:14 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20120918112836.0a148190@resistor.net> References: <503B8A4C.9030701@tana.it> <7967888.2HlpJJ7FlH@scott-latitude-e6320> <20120827235904.GI72831@verdi> <1372205.frOhBsbhem@scott-latitude-e6320> <6.2.5.6.2.20120918112836.0a148190@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 18 Sep 2012 18:33:12 -0400 To: spfbis@ietf.org Message-ID: <1881d150-6e27-4df8-b4e5-266f51c3cee1@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 22:33:18 -0000 S Moonesamy wrote: >Hello, >At 20:55 27-08-2012, Scott Kitterman wrote: >>Upon reflection, I could have put this more clearly. The sender >>policy is the >>list of authorized sources published in the SPF record. The output of >>check_host() is an assessment of a message relative to that policy. >Is it >>policy conformant, policy non-conformant, or unknown (of some >variety). >> >>That assessment is not an action. It's an input into receiver policy. > The >>receiver policy is entirely a local matter of how to dispose of the >message. >>There are a number of things that can be done with it. > >John Leslie mentioned that '"sender policy" should reflect what the >sender _does_ - not what the sender hopes some other MTA will do'. > >If there is agreement on the above arguments, the WG could look at >this in from an angle where issues are identified. For example, >Alessandro Vesely commented on receiver behavior in a message at >http://www.ietf.org/mail-archive/web/spfbis/current/msg02864.html > >If the WG agree that an issue is indeed a problem that has to be >fixed, the next step is to find the fix. For example, Arthur Thisell >proposed the following text: > > 'A "softfail" result says that the ADMD would like the result treated > somewhere between "fail" and "neutral"/"none". The domain owner > believes the host is not authorized but is not willing to make a > strong policy statement. SPF verifies that treat "softfail" results > as harshly as a "fail" can cause ADMDs not to publish such a strict > SPF policy, or not to publish an SPF record at all.' > >Is this an acceptable approach to tackle Section 2 of >draft-ietf-spfbis-4408bis? RFC 4408 has normative requirements for some aspects of receiver policy for neutral and softfail results. I believe that removing these requirements would represent a change to the protocol. Scott K From johnl@iecc.com Tue Sep 18 16:25:57 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D530D21E8040 for ; Tue, 18 Sep 2012 16:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8SChHoEm96o for ; Tue, 18 Sep 2012 16:25:57 -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 E894821E8037 for ; Tue, 18 Sep 2012 16:25:56 -0700 (PDT) Received: (qmail 94626 invoked from network); 18 Sep 2012 23:25:51 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Sep 2012 23:25:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=505902ff.xn--btvx9d.k1208; i=johnl@user.iecc.com; bh=HQ7PRXn3xKfGnf2RvvYjgB9cbvz38jrpUm7ObVNdJgk=; b=OK7CxWl/BtWNIXpCCMyImP5RM7qm75SAQXMA8RV+4wFRcs3xHa6lZi6CSMy2qoz0DhsnoOtUETjOpQjP6Q9Wu+M3zUCnVDkE0M1Im7mHMc7ARpp3eVEGuIjKENhiMhra7E3U2okIj2Borbaj/4OPoPhONl7ODe54rZzbf+bA/vw= 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:vbr-info; s=505902ff.xn--btvx9d.k1208; olt=johnl@user.iecc.com; bh=HQ7PRXn3xKfGnf2RvvYjgB9cbvz38jrpUm7ObVNdJgk=; b=Op6qKzLZxBwZ+6eKX2XNLdkZHNerEU2VqOoE3RZbhZVC8cHN1DA9jESOmay09+7q1DNymoqwH4bQ2uIFjpKXCaElwYoqj6PW9+Amf6134d0AFhl5TerALmIOFOpZCs1RxgFgpAhoNk7W6VXSgd772fqyGoHNClyGD9oaLWPJMPQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Sep 2012 23:25:29 -0000 Message-ID: <20120918232529.33522.qmail@joyce.lan> From: "John Levine" To: spfbis@ietf.org In-Reply-To: <1881d150-6e27-4df8-b4e5-266f51c3cee1@email.android.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: spf2@kitterman.com Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 18 Sep 2012 23:25:58 -0000 > RFC 4408 has normative requirements for some aspects of receiver > policy for neutral and softfail results. I believe that removing > these requirements would represent a change to the protocol. If you mean the part that says that neutral and softfail mean the same thing, that seems fine. To split hairs a little, that is telling readers what the sender's policy is, not what receivers should do with the result. It seems analogous to the part of RFC 5321 that says that for most SMTP reply codes, only the code matters, not the text after it. R's, John From spf2@kitterman.com Tue Sep 18 19:59:25 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396B511E80D2 for ; Tue, 18 Sep 2012 19:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myOOSSJq2zRR for ; Tue, 18 Sep 2012 19:59:24 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0AB11E808D for ; Tue, 18 Sep 2012 19:59:24 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id AFDF820E408E; Tue, 18 Sep 2012 22:59:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1348023563; bh=FaqryXUZ+JNXG9lYLBRMLaswYL1pkAfAhiPnezzOWoU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ll+rzAIxr+A6QF/PpvJg+Vesd0806K3N2iu+cC5rYCFymV4eIv19E6mM//0RK7dXU vqRV4/7XX9Dja+Mg0P/IdVeCBVsGjxHtT060nhOQRr209IRO+D8hwV0IPUrzGOjMYo z+N+7bbHinKzZekWh2tMyS0wE+fEM0FwD/A3dLrg= 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 7F29B20E4062; Tue, 18 Sep 2012 22:59:23 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Tue, 18 Sep 2012 22:59:22 -0400 Message-ID: <1579260.4qBiHljsex@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-31-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <20120918232529.33522.qmail@joyce.lan> References: <20120918232529.33522.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] What is a sender policy? X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Sep 2012 02:59:25 -0000 On Tuesday, September 18, 2012 11:25:29 PM John Levine wrote: > > RFC 4408 has normative requirements for some aspects of receiver > > policy for neutral and softfail results. I believe that removing > > these requirements would represent a change to the protocol. > > If you mean the part that says that neutral and softfail mean the same > thing, that seems fine. To split hairs a little, that is telling > readers what the sender's policy is, not what receivers should do with > the result. > > It seems analogous to the part of RFC 5321 that says that for most > SMTP reply codes, only the code matters, not the text after it. Close. There's two items: 1. Neutral and None mean the same thing so you MUST treat the the same. 2. Receivers SHOULD NOT reject based on an SPF softfail result alone. The second one is appropriate because softfail is supposed to be used for testing and rejecting based on a test failure alone will interfere with interoperability and deployment. Scott K From spf2@kitterman.com Tue Sep 18 22:40:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A898021F86AA for ; Tue, 18 Sep 2012 22:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfJxwp+oEztu for ; Tue, 18 Sep 2012 22:40:29 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id AB83221F86A5 for ; Tue, 18 Sep 2012 22:40:29 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DCB7920E408E; Wed, 19 Sep 2012 01:40:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1348033228; bh=ecj2sInmFDG4DwXoA+U0hkq4557cgGTpF0gdDZmLZ5o=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KhkaC9f0KGawtAYEzl1bynGUtOdfUopPxI/7k3nPIU4u0Ui//uLNJ3zYAwWUAa/a1 +P8sO/Ki19QQr6sDvI82wCyAnt1A8DodySpfBPHGjDqC88+/akV4MMjYocSVzUyQhX sPg0uG4egV2T5jgDnwI7h4KyAchAB7sU8zGwAJl4= 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 B369220E4062; Wed, 19 Sep 2012 01:40:28 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Wed, 19 Sep 2012 01:40:27 -0400 Message-ID: <4168646.NXTNr2vqio@scott-latitude-e6320> User-Agent: KMail/4.8.5 (Linux/3.2.0-31-generic-pae; KDE/4.8.5; i686; ; ) In-Reply-To: <6.2.5.6.2.20120918023453.0772db20@resistor.net> References: <5369844.VrlRnrPTAT@scott-latitude-e6320> <6.2.5.6.2.20120918023453.0772db20@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 19 Sep 2012 05:40:31 -0000 On Tuesday, September 18, 2012 04:21:10 AM S Moonesamy wrote: > Hi Scott, > > At 22:28 17-09-2012, Scott Kitterman wrote: > >As long as operator goals aren't being met, then I don't think > >interoperability exists. The kind of interoperability you're focused on is > >absolutely necessary, but I don't believe it's sufficient. > > I'll comment on the IETF perspective as the draft is intended to > document IETF Consensus. This is the guidance provided in RFC 2119: > > "Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability." > > It can be argued that the above takes a narrow view of > interoperability. Having the interoperability only does solve the > problem. In my short experience RFC authors usually follow the > guidance in RFC 2119 for usage of RFC 2119 key words. If I had to > describe interoperability, I would say that it is about the required > bits for two ends to "talk" to each other. It takes more than that > to solve a problem. However, the interoperability aspect is no > longer a problem to solve. From an IETF perspective it is a step > forward as the user can have a product from one vendor at one end and > a product from another vendor at the other end. > > I hope I am not mistaken in saying that all operators do not have the > same requirements, i.e. there are different use cases. I define what > problem I am trying to solve and then see how to solve it. I should > also work on building consensus so that my proposed solution gains > IETF Consensus. There are certainly varying use cases among operators, but there are general sets of goals that are reasonably common and the path to achieving them can be specified reasonably well. I agree that it's a good thing to be able to have a product from one vendor on one end and another product from another vendor on the other end, but it's often not sufficient to make a protocol/system operationally useful. I hope you noticed in the passage of RFC 2119 you quoted that there are two reasons given for use of RFC 2119 key words. I'm glad you quoted it, because I think that the two elements of receiver policy that exist in RFC 4408 and that I believe need to be carried forward into 4408bis (SPF neutral MUST be treated the same as none and receivers SHOULD NOT reject based solely on SPF softfail) are both well within the scope of "limit behavior which has potential for causing harm". Scott K From sm@elandsys.com Tue Sep 25 10:24:26 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8610A21F8824 for ; Tue, 25 Sep 2012 10:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnzGXnqVKACe for ; Tue, 25 Sep 2012 10:24:26 -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 EE6B921F8822 for ; Tue, 25 Sep 2012 10:24:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.101]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8PHOCxC013736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2012 10:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1348593864; bh=WaGr2QHIiw0BE39OQJkbg+jCWNUqpPLXdzNYlElDIzE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OCoXgOd7MM4RM4yrfP/m5/npb05o7Ygck9GUt958Escp/aL7VTCvjoSVjf7qNXhJa JlfiBTPamvMCTiqZgz1IIVnYG/4SLY8CmCTdjOpGuCH7ERAWu4YPiWipkd50itXncx +pgmXeLC+xkw0+Mo7c6DsbFONyPXhoCiqc79JmUE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1348593864; i=@elandsys.com; bh=WaGr2QHIiw0BE39OQJkbg+jCWNUqpPLXdzNYlElDIzE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=v0RWAK6RlYPI2lbM/CniFJdhMnsA58Kv/WFBqZv6tTSDSPiz7j85rl4T7jnawzspR Fn1k+c6cbYBD6PzlJMSxh4aqaq8amtpQkeJJxuMaD1GkhaUP45i7tj6FxSNXAuxdxo 5U3PoLc+7II4MUiyOpUhW8xgtTIeb0h4pCn+caCE= Message-Id: <6.2.5.6.2.20120925101355.09e80db0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 25 Sep 2012 10:17:13 -0700 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4168646.NXTNr2vqio@scott-latitude-e6320> References: <5369844.VrlRnrPTAT@scott-latitude-e6320> <6.2.5.6.2.20120918023453.0772db20@resistor.net> <4168646.NXTNr2vqio@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis-chairs@tools.ietf.org Subject: Re: [spfbis] Goals of this discussion (was: A proposed reorganization) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 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, 25 Sep 2012 17:24:26 -0000 The current state of the discussion is a stalemate. The WG can take up this issue at the next meeting as it is easier to find a path forward through face-to-face discussions. Meanwhile, it is suggested that the WG addresses the existing issues. Andrew Sullivan & S. Moonesamy, SPFBIS WG co-chairs